
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