Skip to content

Conversation

@e-rk
Copy link
Contributor

@e-rk e-rk commented Oct 24, 2024

PR consists of 3 changes:

  • Add option to select 8-bit UTMI+ PHY interface
  • Add DTS nodes to nRF54L20
  • Add quirks for nRF54L20

#endif /*DT_HAS_COMPAT_STATUS_OKAY(st_stm32f4_fsotg) */

#if DT_HAS_COMPAT_STATUS_OKAY(nordic_nrf_usbhs)
#if DT_HAS_COMPAT_STATUS_OKAY(nordic_nrf_usbhs_nrfs)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no point in renaming it or postfixing it with -nrfs. And there is no reason to break someone else's work with a compatible rename. You will need to communicate with us internally to find a suitable compatible.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a direct need for solving the compatible naming issue. Both nRF54H20 and nRF54L20 do have USBHS peripheral. Yet, the nRF54H20 requires nrfs to get information about VBUS and nRF54L20 has USBREG peripheral for that. Therefore I think the nordic,nrf-usbhs-nrfs and nordic,nrf-usbhs-usbreg is probably the cleanest approach.

Copy link
Contributor Author

@e-rk e-rk Oct 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no strong opinion, although I think the -nrfs suffix makes the difference clear. I'll leave it up to your preference, just please confirm that this is what you want after reading Tomasz's comment.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not convinced to approve changes that break other people's work for no reason. "nordic, nrf-usbhs" should not be renamed. Also, new compatilbe needs a better name, something like "nordic, nrf-usbhs-fancy-soc-family". (nrfs is some software, usbreg is ambiguous)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have removed the nordic,nrf-usbhs change and the nRF54L20 now has nordic,nrf-usbhs-nrf54l compatible instead.

Comment on lines 51 to 58
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can not see any justification why 8-bit should be preferred. And Kconfig is just the wrong place to configure it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there is UTMI+ PHY capable of both 8-bit and 16-bit operation connected to DWC2 controller then there is very little need to use 8-bit (clocking is different between the two, so there hardware behavior changes slightly).

However, it is also possible that there is only 8-bit capable UTMI+ PHY connected to DWC2 controller that supports both 8-bit and 16-bit. In such case this is a killer feature (because 16-bit simply won't work).

Comment on lines 336 to 386
Copy link
Contributor

@jfischer-no jfischer-no Oct 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The existing can be move within #if DT_HAS_COMPAT_STATUS_OKAY(x) || DT_HAS_COMPAT_STATUS_OKAY(y) ... #endif and reused.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you meant || instead of &&.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have moved the common parts to a common #if

@e-rk e-rk force-pushed the usbhs-upstream branch 3 times, most recently from f00d54a to 09fe93b Compare October 25, 2024 10:52
@e-rk e-rk requested a review from jfischer-no November 8, 2024 15:07
@e-rk
Copy link
Contributor Author

e-rk commented Nov 19, 2024

@tmon-nordic @jfischer-no could you take a look?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think LOG_DBG("Using 8-bit UTMI+"); would be more appropriate here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@e-rk e-rk force-pushed the usbhs-upstream branch 2 times, most recently from 901e981 to 9a34724 Compare November 25, 2024 13:41
masz-nordic
masz-nordic previously approved these changes Nov 27, 2024
@e-rk
Copy link
Contributor Author

e-rk commented Nov 28, 2024

It looks like the tests are consistently failing in

 141/697 nrf54l20pdk/nrf54l20/cpuapp drivers.uart.async_api.rtt                         ERROR Build failure (build)

due to

drivers__serial.dir/uart_nrfx_uarte.c.obj -c /__w/zephyr/zephyr/drivers/serial/uart_nrfx_uarte.c
In file included from /__w/zephyr/zephyr/drivers/serial/uart_nrfx_uarte.c:15:
In function 'nrf_uarte_configure',
    inlined from 'uarte_nrfx_configure' at /__w/zephyr/zephyr/drivers/serial/uart_nrfx_uarte.c:504:2:
/__w/zephyr/modules/hal/nordic/nrfx/hal/nrf_uarte.h:877:23: error: 'uarte_cfg.frame_timeout' may be used uninitialized [-Werror=maybe-uninitialized]
  877 |                     | (uint32_t)p_cfg->frame_timeout
      |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/__w/zephyr/zephyr/drivers/serial/uart_nrfx_uarte.c: In function 'uarte_nrfx_configure':
/__w/zephyr/zephyr/drivers/serial/uart_nrfx_uarte.c:443:28: note: 'uarte_cfg.frame_timeout' was declared here
  443 |         nrf_uarte_config_t uarte_cfg;
      |                            ^~~~~~~~~
cc1: all warnings being treated as errors

which is weird, because I haven't done anything with UARTE. Has adding a new node to DTS enabled some new tests in twister?

@e-rk
Copy link
Contributor Author

e-rk commented Jan 16, 2025

CI is green. @tmon-nordic @jfischer-no @masz-nordic could you review?

kl-cruz
kl-cruz previously approved these changes Jan 29, 2025
@e-rk
Copy link
Contributor Author

e-rk commented Feb 19, 2025

CI is green. @tmon-nordic @jfischer-no @masz-nordic could you review?

Ping

masz-nordic
masz-nordic previously approved these changes Feb 21, 2025
@carlescufi carlescufi requested a review from tmon-nordic March 20, 2025 13:21
e-rk added 2 commits March 20, 2025 16:51
Added USBHS device tree node for nRF54L20.

Signed-off-by: Rafał Kuźnia <[email protected]>
The nRF54L20 does not have the NRFS layer and the set of quirks will be
different than in nRF54H20. Added new set of quirks for the nRF54L20
SoC.

Signed-off-by: Rafał Kuźnia <[email protected]>
@e-rk e-rk dismissed stale reviews from masz-nordic and kl-cruz via b056f38 March 20, 2025 15:52
@e-rk
Copy link
Contributor Author

e-rk commented Mar 20, 2025

I have removed the commit that introduced CONFIG_UDC_DWC2_PREFER_8BIT_UTMI.

@github-actions
Copy link

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

@github-actions github-actions bot added the Stale label May 20, 2025
@tmon-nordic
Copy link
Contributor

Initial quirks implementation with the changes necessary to work on actual silicon is downstream at nrfconnect/sdk-zephyr#2770

Support will be upstreamed together with rest of nRF54L20 support.

@e-rk e-rk deleted the usbhs-upstream branch May 29, 2025 09:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: USB Universal Serial Bus platform: nRF Nordic nRFx Stale

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants