Skip to content

zephyr-master_fork #1

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.

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

Closed
wants to merge 2 commits into from
Closed

zephyr-master_fork #1

wants to merge 2 commits into from

Conversation

kartmpk
Copy link

@kartmpk kartmpk commented Nov 9, 2016

No description provided.

Prasanna Karthik added 2 commits November 1, 2016 17:32
Signed-off-by: Prasanna Karthik <pkarthik@intrinsyc.com>
Signed-off-by: Prasanna Karthik <pkarthik@intrinsyc.com>
@kartmpk kartmpk closed this Nov 9, 2016
zephyr-github pushed a commit that referenced this pull request Mar 15, 2017
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, #15
 8000c9c:       2301            movs    r3, #1
 8000c9e:       b902            cbnz    r2, 8000ca2 <stm32_gpio_set+0xa>
 8000ca0:       3110            adds    r1, #16
 8000ca2:       408b            lsls    r3, r1
 8000ca4:       6183            str     r3, [r0, #24]
 8000ca6:       2000            movs    r0, #0
 8000ca8:       4770            bx      lr

and the old one:

08000c98 <stm32_gpio_set>:
 8000c98:       2301            movs    r3, #1
 8000c9a:       f001 010f       and.w   r1, r1, #15
 8000c9e:       fa03 f101       lsl.w   r1, r3, r1
 8000ca2:       6943            ldr     r3, [r0, #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, #20]
 8000cb0:       2000            movs    r0, #0
 8000cb2:       4770            bx      lr

Change-Id: Ie5800d1c345016028d1b9a099f5d74cac35f592a
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
zephyr-github pushed a commit that referenced this pull request Mar 17, 2017
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, #15
 8000c9c:       2301            movs    r3, #1
 8000c9e:       b902            cbnz    r2, 8000ca2 <stm32_gpio_set+0xa>
 8000ca0:       3110            adds    r1, #16
 8000ca2:       408b            lsls    r3, r1
 8000ca4:       6183            str     r3, [r0, #24]
 8000ca6:       2000            movs    r0, #0
 8000ca8:       4770            bx      lr

and the old one:

08000c98 <stm32_gpio_set>:
 8000c98:       2301            movs    r3, #1
 8000c9a:       f001 010f       and.w   r1, r1, #15
 8000c9e:       fa03 f101       lsl.w   r1, r3, r1
 8000ca2:       6943            ldr     r3, [r0, #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, #20]
 8000cb0:       2000            movs    r0, #0
 8000cb2:       4770            bx      lr

Change-Id: Ie5800d1c345016028d1b9a099f5d74cac35f592a
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
zephyr-github pushed a commit that referenced this pull request Mar 21, 2017
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, #15
 8000c9c:       2301            movs    r3, #1
 8000c9e:       b902            cbnz    r2, 8000ca2 <stm32_gpio_set+0xa>
 8000ca0:       3110            adds    r1, #16
 8000ca2:       408b            lsls    r3, r1
 8000ca4:       6183            str     r3, [r0, #24]
 8000ca6:       2000            movs    r0, #0
 8000ca8:       4770            bx      lr

and the old one:

08000c98 <stm32_gpio_set>:
 8000c98:       2301            movs    r3, #1
 8000c9a:       f001 010f       and.w   r1, r1, #15
 8000c9e:       fa03 f101       lsl.w   r1, r3, r1
 8000ca2:       6943            ldr     r3, [r0, #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, #20]
 8000cb0:       2000            movs    r0, #0
 8000cb2:       4770            bx      lr

Change-Id: Ie5800d1c345016028d1b9a099f5d74cac35f592a
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
zephyr-github pushed a commit that referenced this pull request Mar 27, 2017
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, #15
 8000c9c:       2301            movs    r3, #1
 8000c9e:       b902            cbnz    r2, 8000ca2 <stm32_gpio_set+0xa>
 8000ca0:       3110            adds    r1, #16
 8000ca2:       408b            lsls    r3, r1
 8000ca4:       6183            str     r3, [r0, #24]
 8000ca6:       2000            movs    r0, #0
 8000ca8:       4770            bx      lr

and the old one:

08000c98 <stm32_gpio_set>:
 8000c98:       2301            movs    r3, #1
 8000c9a:       f001 010f       and.w   r1, r1, #15
 8000c9e:       fa03 f101       lsl.w   r1, r3, r1
 8000ca2:       6943            ldr     r3, [r0, #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, #20]
 8000cb0:       2000            movs    r0, #0
 8000cb2:       4770            bx      lr

Change-Id: Ie5800d1c345016028d1b9a099f5d74cac35f592a
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
mark-inderhees pushed a commit to mark-inderhees/zephyr that referenced this pull request Nov 7, 2024
With introduction of Raw modes, nRF70 driver now advertises get_c
onfig OP, but doesn't implement all types.

This causes problems two-fold with checksum calculations:
  1. The "config" isn't uninitialized, so, every call returns differnet
     values. So, for UDP header checksum would be done and
     pkt->chksumdone would be set. But for IPv4 header checksum might be
     skipped.
  2. Even if we initialize to zero, then network stack gets all zeros
     and calculates checksum by itself rendering offload moot.

There is another problem in zephyrproject-rtos#1, as there is only single flag for pkt for
all checksum, nRF70 driver sees this and tells UMAC to skip checksum for
the entire packet. The design isn't coherent, and should be converted to
communicate per-type checksum status (some are filled by network stack
and some HW).

But as nRF70 support all checksum offloads, advertise all types for both
RX and TX.

Upstream PR #: 80882

Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
ppryga-nordic pushed a commit to ppryga-nordic/zephyr that referenced this pull request Nov 20, 2024
With introduction of Raw modes, nRF70 driver now advertises get_c
onfig OP, but doesn't implement all types.

This causes problems two-fold with checksum calculations:
  1. The "config" isn't uninitialized, so, every call returns differnet
     values. So, for UDP header checksum would be done and
     pkt->chksumdone would be set. But for IPv4 header checksum might be
     skipped.
  2. Even if we initialize to zero, then network stack gets all zeros
     and calculates checksum by itself rendering offload moot.

There is another problem in zephyrproject-rtos#1, as there is only single flag for pkt for
all checksum, nRF70 driver sees this and tells UMAC to skip checksum for
the entire packet. The design isn't coherent, and should be converted to
communicate per-type checksum status (some are filled by network stack
and some HW).

But as nRF70 support all checksum offloads, advertise all types for both
RX and TX.

Upstream PR #: 80882

Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
stig-bjorlykke pushed a commit to stig-bjorlykke/zephyr that referenced this pull request Dec 11, 2024
With introduction of Raw modes, nRF70 driver now advertises get_c
onfig OP, but doesn't implement all types.

This causes problems two-fold with checksum calculations:
  1. The "config" isn't uninitialized, so, every call returns differnet
     values. So, for UDP header checksum would be done and
     pkt->chksumdone would be set. But for IPv4 header checksum might be
     skipped.
  2. Even if we initialize to zero, then network stack gets all zeros
     and calculates checksum by itself rendering offload moot.

There is another problem in zephyrproject-rtos#1, as there is only single flag for pkt for
all checksum, nRF70 driver sees this and tells UMAC to skip checksum for
the entire packet. The design isn't coherent, and should be converted to
communicate per-type checksum status (some are filled by network stack
and some HW).

But as nRF70 support all checksum offloads, advertise all types for both
RX and TX.

Upstream PR #: 80882

Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
(cherry picked from commit 3017425)
ilhanates pushed a commit to ilhanates/zephyr that referenced this pull request Dec 13, 2024
With introduction of Raw modes, nRF70 driver now advertises get_c
onfig OP, but doesn't implement all types.

This causes problems two-fold with checksum calculations:
  1. The "config" isn't uninitialized, so, every call returns differnet
     values. So, for UDP header checksum would be done and
     pkt->chksumdone would be set. But for IPv4 header checksum might be
     skipped.
  2. Even if we initialize to zero, then network stack gets all zeros
     and calculates checksum by itself rendering offload moot.

There is another problem in zephyrproject-rtos#1, as there is only single flag for pkt for
all checksum, nRF70 driver sees this and tells UMAC to skip checksum for
the entire packet. The design isn't coherent, and should be converted to
communicate per-type checksum status (some are filled by network stack
and some HW).

But as nRF70 support all checksum offloads, advertise all types for both
RX and TX.

Upstream PR #: 80882

Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
(cherry picked from commit 3017425)
ndrs-pst added a commit to DDC-NDRS/zephyr_rtos that referenced this pull request Jan 20, 2025
DBG_PIN9: usbd_ep_ctrl_enqueue zephyrproject-rtos#1
DBG_PIN10: usbd_ep_ctrl_enqueue zephyrproject-rtos#2
DBG_PIN11: usbd_ctrl_feed_dout(dev, 0);
DBG_PIN12: reserved
clamattia pushed a commit to clamattia/zephyr that referenced this pull request Mar 6, 2025
…tty-uart

drivers: uart: uart_native_tty: allow multiple instances
ArteryTek added a commit to Maxjta/zephyr that referenced this pull request Mar 11, 2025
Add Support Artery Technology AT32F405 soc,
kartben pushed a commit that referenced this pull request May 19, 2025
Current code does not build on Cortex-M0, seems like it does not like
subs:

Error: instruction not supported in Thumb16 mode -- `subs r3,#1'

Adding a unified assembler language declaration in the snippet seems to
fix the problem, also add an M0+ board so this is tested in CI.

Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
avolmat-st pushed a commit to avolmat-st/zephyr that referenced this pull request Jun 18, 2025
Add possibility to perform crop and compose (downscale) on
pixel pipes (endpoint zephyrproject-rtos#1 and endpoint zephyrproject-rtos#2).
Rework the code in order to move the downscale control from
the set_fmt into the set_selection (compose).

Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
avolmat-st pushed a commit to avolmat-st/zephyr that referenced this pull request Jun 19, 2025
Add possibility to perform crop and compose (downscale) on
pixel pipes (endpoint zephyrproject-rtos#1 and endpoint zephyrproject-rtos#2).
Rework the code in order to move the downscale control from
the set_fmt into the set_selection (compose).

Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
avolmat-st pushed a commit to avolmat-st/zephyr that referenced this pull request Jun 20, 2025
Add possibility to perform crop on all pipes and compose (downscale) on
pixel pipes (endpoint zephyrproject-rtos#1 and endpoint zephyrproject-rtos#2).
Rework the code in order to move the downscale control from
the set_fmt into the set_selection (compose).

Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
avolmat-st pushed a commit to avolmat-st/zephyr that referenced this pull request Jun 20, 2025
Add possibility to perform crop on all pipes and compose (downscale) on
pixel pipes (endpoint zephyrproject-rtos#1 and endpoint zephyrproject-rtos#2).
Rework the code in order to move the downscale control from
the set_fmt into the set_selection (compose).

Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
avolmat-st pushed a commit to avolmat-st/zephyr that referenced this pull request Jun 20, 2025
Add possibility to perform crop on all pipes and compose (downscale) on
pixel pipes (endpoint zephyrproject-rtos#1 and endpoint zephyrproject-rtos#2).
Rework the code in order to move the downscale control from
the set_fmt into the set_selection (compose).

Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
avolmat-st pushed a commit to avolmat-st/zephyr that referenced this pull request Jun 23, 2025
Add possibility to perform crop on all pipes and compose (downscale) on
pixel pipes (endpoint zephyrproject-rtos#1 and endpoint zephyrproject-rtos#2).
Rework the code in order to move the downscale control from
the set_fmt into the set_selection (compose).

Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
dkalowsk pushed a commit that referenced this pull request Jun 26, 2025
Add possibility to perform crop on all pipes and compose (downscale) on
pixel pipes (endpoint #1 and endpoint #2).
Rework the code in order to move the downscale control from
the set_fmt into the set_selection (compose).

Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants