Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix various issues with CI job #20

Merged
merged 3 commits into from
Apr 30, 2017
Merged

Fix various issues with CI job #20

merged 3 commits into from
Apr 30, 2017

Conversation

nashif
Copy link
Member

@nashif nashif commented Apr 30, 2017

  • Run compliance tests
  • Build Documentation and check for new warnings
  • Post results to AWS S3 storage

@nashif nashif added the In progress For PRs: is work in progress and should not be merged yet. For issues: Is being worked on label Apr 30, 2017
@nashif nashif merged commit ee254da into zephyrproject-rtos:master Apr 30, 2017
@nashif nashif removed the In progress For PRs: is work in progress and should not be merged yet. For issues: Is being worked on label Apr 30, 2017
rsalveti pushed a commit to rsalveti/zephyr that referenced this pull request May 3, 2017
@galak
gpio: stm32: Use atomic set/reset in stm32_gpio_set()
632a07d 
The current implementation of stm32_gpio_set() uses the GPIO output data
register to change the state of individual GPIOs. The generated
assembler needs at least 3 instructions: load / modify / store.

This opens a small race window, for example if a thread and an
interrupt both try to change the state of the same GPIO bank.

Use the GPIO bit set/reset register to perform the atomic change without
locking.

This also has the benefit of a more optimised implementation, which can
be useful for GPIO-intensive work. Compare the new version:

08000c98 <stm32_gpio_set>:
 8000c98:       f001 010f       and.w   r1, r1, zephyrproject-rtos#15
 8000c9c:       2301            movs    r3, zephyrproject-rtos#1
 8000c9e:       b902            cbnz    r2, 8000ca2 <stm32_gpio_set+0xa>
 8000ca0:       3110            adds    r1, zephyrproject-rtos#16
 8000ca2:       408b            lsls    r3, r1
 8000ca4:       6183            str     r3, [r0, zephyrproject-rtos#24]
 8000ca6:       2000            movs    r0, #0
 8000ca8:       4770            bx      lr

and the old one:

08000c98 <stm32_gpio_set>:
 8000c98:       2301            movs    r3, zephyrproject-rtos#1
 8000c9a:       f001 010f       and.w   r1, r1, zephyrproject-rtos#15
 8000c9e:       fa03 f101       lsl.w   r1, r3, r1
 8000ca2:       6943            ldr     r3, [r0, zephyrproject-rtos#20]
 8000ca4:       b10a            cbz     r2, 8000caa <stm32_gpio_set+0x12>
 8000ca6:       4319            orrs    r1, r3
 8000ca8:       e001            b.n     8000cae <stm32_gpio_set+0x16>
 8000caa:       ea23 0101       bic.w   r1, r3, r1
 8000cae:       6141            str     r1, [r0, zephyrproject-rtos#20]
 8000cb0:       2000            movs    r0, #0
 8000cb2:       4770            bx      lr

Change-Id: Ie5800d1c345016028d1b9a099f5d74cac35f592a
Signed-off-by: Florian Vaussard <[email protected]>
frasa pushed a commit to blik-GmbH/zephyr that referenced this pull request Mar 25, 2019
fix: SPI Flash: default SPI clk config
6f89e0d 
* Adds a default configuration of the SPI Flash SPI clock which is
500000.

Closes zephyrproject-rtos#20
frasa added a commit to blik-GmbH/zephyr that referenced this pull request Mar 25, 2019
@frasa
Merge branch 'fix-flash-default-spi-clock' into 'dev'
4604f89 
Fix: Flash default spi clock

Closes zephyrproject-rtos#20

See merge request blik/embedded/zephyr!29
@xiaoliang314 xiaoliang314 mentioned this pull request Jun 17, 2019
Closed
@xiaoliang314 xiaoliang314 mentioned this pull request Jun 26, 2019
Closed
@carlescufi carlescufi mentioned this pull request Apr 24, 2020
Merged
carlescufi added a commit to carlescufi/zephyr that referenced this pull request Apr 30, 2020
@carlescufi
doc: Bluetooth: Document issue with certain controllers
f225f19 
Certain Qualcomm controllers do not accept our settings for Host Buffer
Size:

< HCI Command: Host Buffer Size (0x03|0x0033) plen 7       zephyrproject-rtos#19 [hci0]
22.391048
        ACL MTU: 27   ACL max packet: 6
        SCO MTU: 0    SCO max packet: 0
> HCI Event: Command Complete (0x0e) plen 4                zephyrproject-rtos#20 [hci0]
22.391525
      Host Buffer Size (0x03|0x0033) ncmd 1
        Status: Invalid HCI Command Parameters (0x12)

Likely due to the fact that we do not reserve space for any SCO packets
in the Host.

Other Controllers (Realtek) seem to not transmit any data at all in the
Controller to Host direction if Controller to Host flow control is
enabled.

Document this fact in the User Guide so that users know what to do when
this happens.

Signed-off-by: Carles Cufi <[email protected]>
jhedberg pushed a commit that referenced this pull request Apr 30, 2020
@carlescufi @jhedberg
doc: Bluetooth: Document issue with certain controllers
3d16bda 
Certain Qualcomm controllers do not accept our settings for Host Buffer
Size:

< HCI Command: Host Buffer Size (0x03|0x0033) plen 7       #19 [hci0]
22.391048
        ACL MTU: 27   ACL max packet: 6
        SCO MTU: 0    SCO max packet: 0
> HCI Event: Command Complete (0x0e) plen 4                #20 [hci0]
22.391525
      Host Buffer Size (0x03|0x0033) ncmd 1
        Status: Invalid HCI Command Parameters (0x12)

Likely due to the fact that we do not reserve space for any SCO packets
in the Host.

Other Controllers (Realtek) seem to not transmit any data at all in the
Controller to Host direction if Controller to Host flow control is
enabled.

Document this fact in the User Guide so that users know what to do when
this happens.

Signed-off-by: Carles Cufi <[email protected]>
hakehuang referenced this pull request in hakehuang/zephyr Jun 20, 2020
@carlescufi @hakehuang
doc: Bluetooth: Document issue with certain controllers
c68f5d4 
Certain Qualcomm controllers do not accept our settings for Host Buffer
Size:

< HCI Command: Host Buffer Size (0x03|0x0033) plen 7       #19 [hci0]
22.391048
        ACL MTU: 27   ACL max packet: 6
        SCO MTU: 0    SCO max packet: 0
> HCI Event: Command Complete (0x0e) plen 4                #20 [hci0]
22.391525
      Host Buffer Size (0x03|0x0033) ncmd 1
        Status: Invalid HCI Command Parameters (0x12)

Likely due to the fact that we do not reserve space for any SCO packets
in the Host.

Other Controllers (Realtek) seem to not transmit any data at all in the
Controller to Host direction if Controller to Host flow control is
enabled.

Document this fact in the User Guide so that users know what to do when
this happens.

Signed-off-by: Carles Cufi <[email protected]>
@anchao anchao mentioned this pull request Jul 30, 2020
Merged
@RafaelLeeImg RafaelLeeImg mentioned this pull request Jan 19, 2022
Closed
@piotrParf piotrParf mentioned this pull request Feb 9, 2022
Closed
@zephyrbot zephyrbot mentioned this pull request May 22, 2022
Merged
1 task
@sjanc sjanc mentioned this pull request May 16, 2023
Closed
cdesjardins pushed a commit to Arch-Embedded/zephyr that referenced this pull request Oct 22, 2024
Merged in feature/UVSMART-fatfs-rtc (pull request zephyrproject-rtos#20)
f84f55d 
Make the fatfs use the RTC

Approved-by: Fabian van den IJssel
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@nashif