• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 100 subscribers
  • Views 364 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM5748: DWC3 Linux kernel initialization after U-boot usage of USB

Marcel Hamer1
Prodigy 30 points
Part Number: AM5748

Hello,

After using the DWC3 USB controller both in U-boot and the Linux kernel for the AM5748 device I have several questions. Unfortunately I do not have the documentation of the Synopsis DWC3 IP, which I believe is only available under NDA. Therefore I would like to inform if my findings, after a lot of testing and debugging, are correct.

One of the major issues seen is that the configuring of the DWC3 in U-boot has an impact on the usage in the Linux environment. When the USB is used in U-boot, using an 'usb start', this has an impact on the configuration and usage in Linux. Eventually resulting in a kernel oops.

U-boot related questions:

1. In U-boot it seems like the device is always configured to be in peripheral mode if the utmi-mode is software (DWC3_OMAP_UTMI_MODE_SW). We want to use the device in USB host mode in U-boot, is there a reason it defaults to peripheral mode in the driver?
2. It seems 2 drivers are compiled in for some evaluation boards, but in the end only the dwc3-generic.c glue driver is used. Is the define in the board header file, as can be seen here, a left over?
3. In the Linux kernel driver the USBOTGSS_UTMI_OTG_STATUS_POWERPRESENT flag has been removed as mentioned here. In U-boot this flag is still actively set here. Does this have an impact on the functionality of the device?
4. It seems cleanup functionality is completely missing before Linux is started. It seems like a USB configuration has been performed, but just before Linux boots using bootm, the usb_stop() call does not seem to do a proper cleanup. Is this a side effect of using the CLASS_NOP class for the glue layer or was this intentional?

Linux kernel related questions:

1. In the Linux driver I noticed that during the registration of the extcon driver, only two scenarios are checked. What I am missing here is the case when both if statements are not valid, in which case I guess dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_OFF); should be called to initialize the DWC3 for that specific case where VBUS is not valid. It is done like this in the dwc3_omap_vbus_notifier() function in case VBUS is not valid. This missing initialization seems to be causing trouble in our specific scenario, especially since the DWC3 had been configured in U-boot and it cannot be assumed in the Linux kernel none of the registers have been touched.

In case we boot Linux without using USB in U-boot we do not see any issues. Only after U-boot has configured the DWC3 registers, specifically the UTMI_OTG_STATUS register, issues start to occur during initialization. It seems specifically related to the missing dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_OFF); in the Linux kernel driver during initialization. Once that call is added in the driver, the issues do indeed disappear.

Before proposing such a change I would like to get feedback from TI, since as stated earlier I do not have sufficient documentation to judge if any of the above is absolutely correct.

Thank you in advance.

Kind regards,

Marcel

  • 0
    TI__Mastermind 27111 points

    Hello Marcel.

    Can you please confirm the version of the Processor SDK Linux release that you are using for the above analysis? Is it 06_03_00_xx? Also what AM57xx evaluation board is being built for?

    Regarding the queries, we are checking on this. will respond back.

    Thanks.

  • 0 in reply to Praveen Rao
    Prodigy 30 points

    Hello,

    Thank you for your answer. Currently I have only been testing this on custom hardware based on the AM5748, I have not tested on any evaluation board.

    As such we are running software based on the TI SDK release but not exactly the TI SDK release on an evaluation board.

    I think the parts of the drivers I am referring to in my initial post have not changed and are identical.

    Kind regards,


    Marcel

  • 0
    Prodigy 30 points

    For information, my proposed patch would be the following to properly initialize the registers during initialization.

    	---
 drivers/usb/dwc3/dwc3-omap.c | 5 +++++
 1 file changed, 5 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 8c3de2d258bf..e8acad49a53a 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -437,8 +437,13 @@ static int dwc3_omap_extcon_register(struct dwc3_omap *omap)
 
 		if (extcon_get_state(edev, EXTCON_USB) == true)
 			dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_VALID);
+		else
+			dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_OFF);
+
 		if (extcon_get_state(edev, EXTCON_USB_HOST) == true)
 			dwc3_omap_set_mailbox(omap, OMAP_DWC3_ID_GROUND);
+		else
+			dwc3_omap_set_mailbox(omap, OMAP_DWC3_ID_FLOAT);
 
 		omap->edev = edev;
 	}
--

  • 0 in reply to Marcel Hamer1
    TI__Prodigy 110 points

    Hi Marcel,

    Marcel Hamer1 said:

    U-boot related questions:

    1. This is a bug, check should probably be utmi_mode != DWC3_OMAP_UTMI_MODE_SW. Ie Default to peripheral mode in case HW OTG or unknown mode is specified. 

    2. Yes, this is left over when we migrated USB driver to use Device model and DT in U-Boot.

    3. Yes, this is a bug and should be fixed in U-Boot. 

    4. No, its not intentional. Code to clean up settings done as part of dr_mode selection is absent. This is a gap

    Marcel Hamer1 said:

    Linux kernel related questions:

    1. Yes, I agree with your change as proposed above. Would you be willing to submit a patch to mainline kernel? 

    Thanks
    Vignesh

  • 0 in reply to Vigneshr
    Prodigy 30 points

    Hello Vignesh,

    Thank you for the clarifications.

    Yes, I can propose a patch to the mainline Linux kernel. I will do this as soon as possible.

    Regarding the U-boot changes, will there be patches published from TI towards U-boot?

    Kind regards,

    Marcel

  • +1 in reply to Marcel Hamer1
    TI__Prodigy 110 points

    Hello,

    Thank you for taking up kernel side fix. 

    We will work towards U-Boot fixes but don't have timelines for the SDK with these fixes.
    If you would like to fix these in upstream U-Boot, do feel free to post patches to U-Boot mailing list and I can help in reviewing and getting the fixes accepted by USB maintainer.

    Thanks
    Vignesh