From mboxrd@z Thu Jan  1 00:00:00 1970
From: Roger Quadros <rogerq@ti.com>
Date: Mon, 16 May 2016 13:31:11 +0300
Subject: [U-Boot] [PATCH v2 2/4] board: ti: am57xx: Fix USB configuration
In-Reply-To: <57399B00.7030800@ti.com>
References: <1463141873-10604-1-git-send-email-rogerq@ti.com>
 <1463141873-10604-3-git-send-email-rogerq@ti.com> <5735CA6A.2070005@ti.com>
 <5735CC80.3090900@denx.de> <57398D92.1060709@ti.com>
 <5739923A.2040706@ti.com> <573997A6.9020709@ti.com> <57399B00.7030800@ti.com>
Message-ID: <5739A16F.2000403@ti.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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?
Is dual-role even required in u-boot? probably it is not a good idea and we just
ignore it for simplicity.

What determines whether a USB port is meant for Host or device operation? Is it
the CONFIG_ or caller of board_usb_init()?
I see board_usb_init() being used by gadget drivers, host drivers, dfu.c, etc.

cheers,
-roger