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

[Vignesh R]

On Thursday 22 June 2017 06:30 PM, Lukasz Majewski wrote:
> On Thu, 22 Jun 2017 17:42:38 +0530
> Vignesh R <vigneshr at ti.com> wrote:
> 
>>
>>
>> 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? 
> 
> The "composite" layer was supposed to provide that.
> 
>> Like a single defconfig may want to
>> have both f_dfu and f_mass_storage enabled?
> 
> When we developed the g_dnl/f_* code we wanted to have support for many
> functions.
> 
> However, finally, we only implemented the single function since u-boot
> is a single thread SW (and we had some problems with DFU/ODIN endpoints
> assignment, IIRC).
> 
> Theoretically it should be possible to have many functions enabled.
> 

Ok.

>>
>>> 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.
> 
> I would opt for latter option (f_rndis*).
> 

I agree...

>>
>>> 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. 
> 
> Ok.
> 
>> 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.
> 
> And other UDCs should be moved as well.... (like dwc[23]).
> 

yes, all UDCs needs to moved..
BTW, what platform would you be starting these migration on?


-- 
Regards
Vignesh