Skip to content

Enable nxp usb host controllers #68232

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 4 commits into from
Closed

Enable nxp usb host controllers #68232

wants to merge 4 commits into from

Conversation

MarkWangChinese
Copy link
Collaborator

@MarkWangChinese MarkWangChinese commented Jan 29, 2024

Create the mcux usb host controller driver (uhc_mcux.c) based on NXP SDK USB Host controller drivers (usb_host_ehci.c, usb_host_khci.c etc).
Support EHCI and KHCI controllers. Basic setup transfers (set_address and get_device_descriptor) are verified on frdm_k22f and mimxrt1060_evk boards.

@zephyrbot
Copy link
Collaborator

zephyrbot commented Jan 29, 2024

The following west manifest projects have been modified in this Pull Request:

Name Old Revision New Revision Diff
hal_nxp zephyrproject-rtos/hal_nxp@f6c7108 zephyrproject-rtos/hal_nxp#327 zephyrproject-rtos/hal_nxp#327/files

Note: This message is automatically posted and updated by the Manifest GitHub Action.

@zephyrbot zephyrbot added manifest manifest-hal_nxp DNM This PR should not be merged (Do Not Merge) labels Jan 29, 2024
Copy link
Collaborator

@danieldegrasse danieldegrasse left a comment

Choose a reason for hiding this comment

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

Thanks for the work here!

@zephyrbot zephyrbot added area: ARM ARM (32-bit) Architecture area: Architectures labels Feb 20, 2024
tmon-nordic
tmon-nordic previously approved these changes Mar 1, 2024
Copy link
Collaborator

@danieldegrasse danieldegrasse left a comment

Choose a reason for hiding this comment

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

A few additional comments from my side- thanks again for all the work here!

} else {
pipe_init.direction = USB_OUT;
}
pipe_init.numberPerUframe = 0; /* TODO: need right way to implement it. */
Copy link
Collaborator

Choose a reason for hiding this comment

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

Could you add a broader comment here explaining:

  • what we are working around here
  • why this workaround is required

Is the issue that the UHC stack does not provide ways to set these parameters?

return 0;
}

usb_status_t USB_HostAttachDevice(usb_host_handle hostHandle,
Copy link
Collaborator

Choose a reason for hiding this comment

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

I believe I made this comment earlier but I wanted to suggest it again- could we add comments above each of the USB_Hostxxx functions, like the following:

/*
 * Note- this function will be called by the MCUX SDK host controller layer when...
 */

For example:

/*
 * Note- this function will be called by the MCUX SDK host controller layer when a USB device is attached
 */

I think this will help future developers working with the driver understand the use of these functions, since the fact that they are callbacks is not immediately obvious.

@MarkWangChinese
Copy link
Collaborator Author

A few additional comments from my side- thanks again for all the work here!

Hi Daniel, appreciate your comments, I have fixed all your new comments.

danieldegrasse
danieldegrasse previously approved these changes Mar 12, 2024
@danieldegrasse
Copy link
Collaborator

@mmahadevan108 could you take a look at this?

@tmon-nordic
Copy link
Collaborator

Are the commits in this PR bisectable? Isn't the nxp hal commit supposed to go before the drivers are introduced?

@danieldegrasse
Copy link
Collaborator

Are the commits in this PR bisectable? Isn't the nxp hal commit supposed to go before the drivers are introduced?

That's a good catch- @MarkWangChinese please insure that the HAL NXP update is first in this PR. The goal is that each commit should build cleanly. So for example, board support for the UHC driver cannot be added before the driver itself is present, and the driver cannot be added until the HAL support is available.

@danieldegrasse danieldegrasse dismissed their stale review March 12, 2024 16:38

Dismissing approval until bisectability is addressed

@dleach02
Copy link
Member

@jfischer-no can you provide some feedback here.

 - add usb host controller items to device tree
 - add usb phy items to device tree.
 - add yaml support for usb controller device tree items.

Signed-off-by: Mark Wang <yichang.wang@nxp.com>
 - add NXP_FSL_OSA to control OSA
 - add event
 - add mutex
 - add OSA_MemoryAllocate
   define NXP_FSL_OSA_HEAP to enable the OSA heap.
   the different modules can select NXP_FSL_OSA_HEAP to enable it.
   define NXP_FSL_OSA_HEAP_CACHEABLE to enable cacheable heap.
   the different modules can select NXP_FSL_OSA_HEAP_CACHEABLE
   to enable it.

Signed-off-by: Mark Wang <yichang.wang@nxp.com>
 - uhc_mcux.c is based on SDK USB Host controller driver.
 - support EHCI (usb_host_ehci.c) and KHCI (usb_host_khci.c) now.
 - add related Kconfig.
 - add usb_host_config.h
 - update modules/hal_nxp and modules/hal_nxp/usb cmake file for usb host.
 - update hal_nxp revision to contain the support of usb host controllers.

Signed-off-by: Mark Wang <yichang.wang@nxp.com>
 - add uhc related items to dts.
 - add clock initialization
 - add BM4 if CONFIG_USB_UHC_NXP_KHCI is enabled

Signed-off-by: Mark Wang <yichang.wang@nxp.com>

#ifdef CONFIG_NXP_FSL_OSA_HEAP
/* calculate the required heap size of mcux usb host controller */
#ifdef CONFIG_USB_UHC_NXP_MCUX
Copy link
Collaborator

Choose a reason for hiding this comment

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

OSA should not have IP specific code or configuration.
Please remove the USB code from the Common OSA, and find other solution.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Thanks Andrej, My thought is: The osa can define the heap size based on all the enabled modules that uses the osa heap. Do you have any suggestions?

Copy link
Collaborator

Choose a reason for hiding this comment

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

It should be a project configuration parameter.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I think it is better to put the similar logic to Kconfig as follow.

config NXP_FSL_OSA_HEAP_SIZE
	int
	default 2500 if CONFIG_USB_UHC_NXP_MCUX && CONFIG_NXP_OTHER_MODULE
	default 1500 if CONFIG_USB_UHC_NXP_MCUX
	default 1000 if CONFIG_NXP_OTHER_MODULE
	default 0

since there is no CONFIG_NXP_OTHER_MODULE now. the code is:

config NXP_FSL_OSA_HEAP_SIZE
	int
	default 1500 if CONFIG_USB_UHC_NXP_MCUX
	default 0

What do you think?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we use already existing Zephyr heap definitions?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Do you mean the CONFIG_HEAP_MEM_POOL_ADD_SIZE_ ${DOTCONFIG}? Different modules can increase the heap size by module's self macro. If we don't need the osa heap to be non-cachable (usb controller driver doesn't need it now) I think we can do it. In current USB stack, the system heap (k_malloc) is not enabled default, so I need to enable it if nxp usb controller is enabled. I can change the PR for review if this is your suggestion.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Probably, you all (Radim, USB, Wi-Fi) have to cooperate on the Zephyr OSA already available in MCUx SDK and do not create new not compatible forks.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Thanks Andrej

Copy link
Contributor

@Radimli Radimli Apr 25, 2024

Choose a reason for hiding this comment

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

  1. There is already fsl_os_abstraction.h in our SDK repository. This file is supposed to be independent and all implementation should be put inside fsl_os_abstraction_zephyr.h/c.
    Do you want to achieve higher speed using macros?

  2. Why don't you want to include fsl_os_abstraction.h from our SDK repository (NXP HAL) and put implementation for Zephyr abstraction in there?

  3. How are you planning to maintain two APIs (fsl_os_abstraction.h) if one of them is changed? Imagine - someone will change the API in Zephyr OR SDK and this will break our middleware, since code of middlewares is shared between both Zephyr and SDK.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Thanks Radim, Firstly The fsl_os_abstraction.h and fsl_os_abstraction_zephyr.c are already there before this PR. I add mutex, event and heap support because USB host controller drivers need them. I am totally OK to replace this osa with hal_nxp/mcux/mcux-sdk/components/osa, but zephyr is still not supported in hal_nxp/mcux/mcux-sdk/components/osa.

Copy link
Contributor

Choose a reason for hiding this comment

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

Alright, I just noticed, there is already Zephyr port implementation in our SDK. See https://bitbucket.sw.nxp.com/projects/MCUCORE/repos/mcu-sdk-component/browse/osa
So the thing is how to get this version working with our project inside Zephyr.

@github-actions github-actions bot added the Stale label Jun 25, 2024
@zephyrproject-rtos zephyrproject-rtos deleted a comment from github-actions bot Jul 5, 2024
@jfischer-no jfischer-no added this to the v4.0.0 milestone Jul 5, 2024
@jfischer-no
Copy link
Collaborator

jfischer-no commented Aug 19, 2024

@MarkWangChinese Please rebase and align a bit with design of the NXP UDC drivers.

@MarkWangChinese, @dleach02 Since the EHCI specification is also implemented by other vendors, would you consider adding a native implementation (providing only the fsl interface)? Perhaps others are also interested on native EHCI driver. It is not a blocker given the complexity of EHCI.

@MarkWangChinese
Copy link
Collaborator Author

@MarkWangChinese Please rebase and align a bit with design of the NXP UDC drivers.

@MarkWangChinese, @dleach02 Since the EHCI specification is also implemented by other vendors, would you consider adding a native implementation (providing only the fsl interface)? Perhaps others are also interested on native EHCI driver. It is not a blocker given the complexity of EHCI.

@jfischer-no , Sure, I will update this PR recently (early of Sep).
For your second question, my thought is as follow: Currently the usb host stack is not mature and is only part-implemented, if we develop a native controller from scratch, it would be too complicated to stabilize both EHCI controller driver and usb host stack. NXP EHCI controller driver is already qualified with many times of NXP SDK releases, if we could use it, we could focus on the USB Host stack development. After we get a stabilized and qualified usb host stack, we could begin a native controller driver development. So, my suggestion is using the shim now and switching to native driver in future.

@nxp-zephyr nxp-zephyr closed this by deleting the head repository Aug 26, 2024
@MarkWangChinese
Copy link
Collaborator Author

nxp-zephyr/zephyr repo is never used in NXP, so this PR is closed. I will use new repo to create new PR and mention it here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Architectures area: ARM ARM (32-bit) Architecture area: Devicetree Binding PR modifies or adds a Device Tree binding area: USB Universal Serial Bus DNM This PR should not be merged (Do Not Merge) manifest manifest-hal_nxp platform: NXP Drivers NXP Semiconductors, drivers platform: NXP NXP
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants