From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukasz Majewski Date: Wed, 21 Jun 2017 10:09:01 +0200 Subject: [U-Boot] [PATCH v2 06/13] drivers: usb: dwc3: add ti dwc3 peripheral driver with driver model support In-Reply-To: <6bb10110-255d-c320-d47e-430902ab90f7@ti.com> References: <20170613121009.25860-1-vigneshr@ti.com> <20170613121009.25860-7-vigneshr@ti.com> <391181e2-ff73-9750-3262-d719d27a58f2@denx.de> <3a3739bf-4ad0-1474-2896-ccfbf3ac9ed5@denx.de> <7c6aa856-08b0-b9b4-a52a-d5f75660fd9f@ti.com> <20170620154442.343fb64d@jawa> <6bb10110-255d-c320-d47e-430902ab90f7@ti.com> Message-ID: <20170621100901.035e3b6f@jawa> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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*). 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)..... 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.... > > > I will do my best to provide some ideas for this task..... > > > > Thanks! > > 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