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

[Lukasz Majewski]

On Tue, 27 Jun 2017 14:38:38 +0530
Vignesh R <vigneshr at ti.com> wrote:

> 
> 
> 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?
> 
> 

I do have two available:

- Beagle Bone Blach

- Odroid XU3


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