[U-Boot] [PATCH v2 2/4] board: ti: am57xx: Fix USB configuration

[Roger Quadros]

On 16/05/16 14:10, Kishon Vijay Abraham I wrote:
> Hi Roger,
> 
> On Monday 16 May 2016 04:01 PM, Roger Quadros wrote:
>> On 16/05/16 13:03, Kishon Vijay Abraham I wrote:
>>> Hi Roger,
>>>
>>> On Monday 16 May 2016 03:19 PM, Roger Quadros wrote:
>>>> On 16/05/16 12:26, Roger Quadros wrote:
>>>>> On 16/05/16 12:06, Roger Quadros wrote:
>>>>>> On 13/05/16 15:45, Marek Vasut wrote:
>>>>>>> On 05/13/2016 02:36 PM, Roger Quadros wrote:
>>>>>>>> Currently CONFIG_USB_DWC3 is not selected so doing a usb start
>>>>>>>> command results in a serious error [1].
>>>>>>>
>>>>>>> Why does this error happen ? That is what should be fixed. Selecting
>>>>>>> some random options seems like papering over a bug.
>>>>>>
>>>>>> Agreed. I was lazy :P.
>>>>>
>>>>> OK. The issue is like this.
>>>>>
>>>>> CONFIG_CMD_USB and CONFIG_USB_XHCI is defined, so usb_init() calls
>>>>> usb_lowlevel_init() in xhci.c which calls xhci_hcd_init in xhci-omap.c which calls
>>>>> board_usb_init().
>>>
>>> IIRC, board_usb_init for xhci (omap) is mostly a NOP.
>>
>> Then who will call board_usb_init() for host case?
>>
>>>>>
>>>>> But board_usb_init() in am57xx/board.c is defined only if CONFIG_USB_DWC3 is defined
>>>>> and that is missing in am57xx_evm.h leading to the serious error. We're trying to
>>>>> access the IP without turning on the necessary clocks.
>>>
>>> clocks are not turned on in board_usb_init() right? The board_usb_init() in
>>> am57xx/board.c is used only for gadget mode.
>>>>>
>>>>> So it looks like we need to define it based on CONFIG_USB_XHCI_OMAP or something else.
>>>
>>> right, but before that we might have to cleanup xhci-omap.
>>>>>
>>>>> But then again looking into the future, what if we want only gadget operation?
>>>>> That would not define XHCI, but we still need board_usb_init(). So board_usb_init()
>>>>> should be defined based on CONFIG_CMD_USB=y?
>>>>>
>>>>> What do you suggest?
>>>>
>>>> But board_usb_init() calls 
>>>>
>>>>                 ti_usb_phy_uboot_init(&usb_phy1_device);
>>>>                 dwc3_omap_uboot_init(&usb_otg_ss1_glue);
>>>>                 dwc3_uboot_init(&usb_otg_ss1);
>>>>
>>>> which depend on CONFIG_USB_DWC3_PHY_OMAP, CONFIG_USB_DWC3_OMAP and CONFIG_USB_DWC3
>>>> respectively.
>>>
>>> IMO we should cleanup xhci-omap so that all the initializations are done using
>>> ti_usb_phy_uboot_init, dwc3_omap_uboot_init and dwc3_uboot_init. Then modify
>>> dwc3_uboot_init to initialize host or device based on CONFIG_*.
>>>
>>
>> I'm still trying to get a grip of how USB works in u-boot.
>> Is CONFIG_CMD_USB only meant for host mode or gadget mode as well?
> 
> IIRC it is only for host. Commands like usb start, usb stop are used to start
> and stop host.
>> Is dual-role even required in u-boot? probably it is not a good idea and we just
>> ignore it for simplicity.
> 
> yeah.
>>
>> What determines whether a USB port is meant for Host or device operation? Is it
>> the CONFIG_ or caller of board_usb_init()?
> It should be the caller of board_usb_init(). The same port can be used as
> device or host based on command used (the command determines the caller of
> board_usb_init).

Then it is upto board_usb_init() to complain if it is called for some mode
and the respective drivers are not enabled.

board_usb_init() must be defined in the board if CONFIG_CMD_USB || USB_GADGET

But there is no single config option for USB_GADGET. people seem to be calling
board_usb_init() from all over the place without any dependency on USB_GADGET.
e.g. dfu.c, ether.c, fastboot.c, thordown.c, usb_mass_storage.c, ether.c

So things will break with various configurations.
So probably for now board_usb_init() has to be always defined.

cheers,
-roger