On Thursday 22 June 2017 06:30 PM, Lukasz Majewski wrote: > On Thu, 22 Jun 2017 17:42:38 +0530 > Vignesh R <vigne...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot