[U-Boot] [PATCH v2 06/13] drivers: usb: dwc3: add ti dwc3 peripheral driver with driver model support

[Vignesh R]

On Wednesday 21 June 2017 01:39 PM, Lukasz Majewski wrote:
> Hi Vignesh,
> 
>> Hi,
>>
>> On Tuesday 20 June 2017 07:14 PM, Lukasz Majewski wrote:
>>> Hi Marek, Vignesh,
>> [...]
>>>>>
>>>>> All gadget drivers like ether.c or f_mass_storage.c call
>>>>> usb_gadget_handle_interrupts() just passing the index of the USB
>>>>> instance. This does not help at all in dm case. What we would need
>>>>> is usb_gadget_handle_interrupts() to provide at least the
>>>>> usb_gadget instance as parameter from which we could derive
>>>>> controller specific structure using container_of(). And then, we
>>>>> could call the SoC specific isr callback.
>>>>> This would require modifying all gadget driver like ether.c to
>>>>> call a different function instead of
>>>>> usb_gadget_handle_interrupts() when DM_USB is used.
>>>>
>>>> This is something to consult with Lukasz then.
>>>
>>> And it seems that we are heading to adding "gadget" infrastructure
>>> to DM.....
>>>
>>
>> Yes, U-Boot is moving to DM for good and this has cascading effect.
>> I was actually trying to enable DM_ETH on some TI platforms which
>> forced me to move USB_ETH to DM as well and therefore seems like USB
>> gadget framework needs tweaks to adapt to DM...
> 
> I've sketched following plan for gadget conversion:
> 
> 1. Each u-boot command (dfu, ums, thor and in the future rockchip I
> hope), which uses gadget goes through g_dnl_{register|unregister}, so
> the idea is to add this driver first to DM.
> 
> 2. Afterwards, we could add functions as children of g_dnl.
> 
> This would be easily modeled in Kconfig (to have g_dnl - gadget - menu
> with submenu to chose the USB function - e.g. f_dfu*).
> 

Wondering, if there is case where more than one functions may be used
like f_dfu and f_mass_storage? Like a single defconfig may want to have
both f_dfu and f_mass_storage enabled?

> However, we also need to take care of several UDC (USB device
> controller) drivers including also the "composite" usb layer.
> 
> This would be tougher to do since there are many udc drivers - but it
> should be possible to separate DM's UDC drivers and g_dnl/function
> code. 
> 
> Another problem is that some archs use gadgets (RNDIS?) without g_dnl
> and composite - on top of UDC driver (like musb).....
> 

Yes, rndis does not use g_dnl. Both MUSB and DWC3 gadget seem to use UDC
w/o g_dnl/composite. I guess, we will have to either support RNDIS
directly with UDC or convert MUSB/DWC3 gadget interface as well as
convert ether.c to g_dnl function.

> For example:
> 
> board/ti/beagle/beagle.c -> board_eth_init()
> 		|
> 	       \|/
> drivers/usb/gadget/ether.c -> usb_eth_initialize()
> [ether.c seems to partially support DM]
> 		|
> 	       \|/
> (also in the ether.c)
> 	_usb_eth_init() in which we loop on
> 	usb_gadget_handle_interrupts()
> 
> 
> From what I see, the ether.c now supports DM and legacy code, so some
> work has been already done for DM....
> 

Yeah, I think this was done as part of making MUSB DM conversion.
RNDIS boot is one the boot mode for many TI platforms and is used quite
often. Legacy code is what is largely in use, am335x has been recently
moved to use DM based RNDIS(although I feel its not complete and working
yet). I guess once UDC is moved DM, we can see how ether.c can be
integrated with it.

Thanks for looking into this!

-- 
Regards
Vignesh