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

[Lukasz Majewski]

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.

> 
> > 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*).

> 
> > 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]).

> 
> Thanks for looking into this!
> 

No problem.


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de