[U-Boot] [PATCH] usb: new board-specific USB init interface

[Mateusz Zalega <m.zalega@samsung.com>]

On 08/22/13 21:37, Marek Vasut wrote:
> Dear Mateusz Zalega,
> 
>>>>> The EHCI supports multi-bus thing (passing the controller *), will this
>>>>> be viable to pass in this case too, so the busses can be inited
>>>>> selectively in host/gadget functions?
>>>>
>>>> Hello, Marek.
>>>> I need more context. Could you show me the part of code in which you'd
>>>> like to pass/use additional arguments?
>>>
>>> Please grep the 'controller' pointer that is passed to various functions
>>> at least in the EHCI case. It would be nice to pass that to the init
>>> functions too, no?
>>
>> It may be possible, but note that board_usb_init() is not used solely by
>> EHCI code (please grep or cscope function calls). In order to do that,
>> we would need to devise some generic interface.
>>
>> Is it worth the time? Are there targets that would benefit from this
>> change?
> 
> In case you want to separatelly init one port for USB peripheral mode and one 
> for Host mode, yes.

We could add another argument: "int controller_index" (or maybe "const
char* controller_id"), which would correspond to node names or aliases
defined in devicetree source files (ie. see: tegra30.dtsi). List of
available controllers would be accesible via ie. "usb list" command.
Implementations of board_usb_init() would lookup applicable hardware in
gd_t.

We would need to find a way to differentiate between these controllers
in cases when it would be expected from u-boot to automatically
initialize devices it needs. It looks easy in case of ehci-tegra.c.

Devicetree-agnostic boards would have their own "usb list"
implementation, and those of them that can't initialize their
controllers selectively would be left the way they are with just one
additional, unused board_usb_init() argument.

-- 
Mateusz Zalega
Samsung R&D Institute Poland