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

[Vignesh R]

Hi Lukasz,

Revisiting this old thread...
On 21-Jun-17 1:39 PM, Lukasz Majewski wrote:
> Hi Vignesh,
[...]
 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...
> 

Did you get a chance to work on DM conversion of USB gadget framework?
Are there any plans to work on it as such?

> 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.
>>>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [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  wrote:

> 
> 
> On Thursday 22 June 2017 06:30 PM, Lukasz Majewski wrote:
> > On Thu, 22 Jun 2017 17:42:38 +0530
> > Vignesh R  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: w...@denx.de
___

Re: [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  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

Re: [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  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: w...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Vignesh R]

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? Like a single defconfig may want to have
both f_dfu and f_mass_storage 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.

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

Thanks for looking into this!

-- 
Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Lukasz Majewski]

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: w...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Vignesh R]

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 will do my best to provide some ideas for this task.
> 

Thanks!


-- 
Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Lukasz Majewski]

Hi Marek, Vignesh,

> On 06/20/2017 02:00 PM, Vignesh R wrote:
> > Hi Marek,
> > 
> > On Thursday 15 June 2017 10:27 PM, Marek Vasut wrote:
> >> On 06/14/2017 02:25 PM, Vignesh R wrote:
> >> [...]
> >  /**
> >   * dwc3_omap_uboot_init - dwc3 omap uboot initialization code
> >   * @dev: struct dwc3_omap_device containing initialization data
> > @@ -462,3 +487,145 @@ MODULE_ALIAS("platform:omap-dwc3");
> >  MODULE_AUTHOR("Felipe Balbi ");
> >  MODULE_LICENSE("GPL v2");
> >  MODULE_DESCRIPTION("DesignWare USB3 OMAP Glue Layer");
> > +
> > +#else
> > +
> > +int usb_gadget_handle_interrupts(int index)
> 
>  Can this be made somehow more generic , so that the core code
>  would contain the basic interrupt handling and probe routines
>  and the various SoC-specific drivers would add their specific
>  bits to it ?
> 
> >>>
> >>> How about moving this to drivers/usb/dwc3/gadget.c and then
> >>> provide a callback to each of SoC specific drivers?
> >>>
> >> That could work.
> > 
> > Sorry, looking at this further I dont see a easy way of doing this.
> > 
> > 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.

I will do my best to provide some ideas for this task.

> 
> > I see MUSB driver uses a global pointer to musb struct (see
> > drivers/usb/musb-new/musb_uboot.c::usb_gadget_handle_interrupts()),
> > but I dont think thats a good option.
> 
> Nope, that's not a good option, just like any global stuff in drivers.
> 
> > Let me know your preference. Any suggestion appreciated. 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: w...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Marek Vasut]

On 06/20/2017 02:00 PM, Vignesh R wrote:
> Hi Marek,
> 
> On Thursday 15 June 2017 10:27 PM, Marek Vasut wrote:
>> On 06/14/2017 02:25 PM, Vignesh R wrote:
>> [...]
>  /**
>   * dwc3_omap_uboot_init - dwc3 omap uboot initialization code
>   * @dev: struct dwc3_omap_device containing initialization data
> @@ -462,3 +487,145 @@ MODULE_ALIAS("platform:omap-dwc3");
>  MODULE_AUTHOR("Felipe Balbi ");
>  MODULE_LICENSE("GPL v2");
>  MODULE_DESCRIPTION("DesignWare USB3 OMAP Glue Layer");
> +
> +#else
> +
> +int usb_gadget_handle_interrupts(int index)

 Can this be made somehow more generic , so that the core code would
 contain the basic interrupt handling and probe routines and the various
 SoC-specific drivers would add their specific bits to it ?

>>>
>>> How about moving this to drivers/usb/dwc3/gadget.c and then provide a
>>> callback to each of SoC specific drivers?
>>>
>> That could work.
> 
> Sorry, looking at this further I dont see a easy way of doing this.
> 
> 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.

> I see MUSB driver uses a global pointer to musb struct (see
> drivers/usb/musb-new/musb_uboot.c::usb_gadget_handle_interrupts()), but
> I dont think thats a good option.

Nope, that's not a good option, just like any global stuff in drivers.

> Let me know your preference. Any suggestion appreciated. Thanks!
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Vignesh R]

Hi Marek,

On Thursday 15 June 2017 10:27 PM, Marek Vasut wrote:
> On 06/14/2017 02:25 PM, Vignesh R wrote:
> [...]
  /**
   * dwc3_omap_uboot_init - dwc3 omap uboot initialization code
   * @dev: struct dwc3_omap_device containing initialization data
 @@ -462,3 +487,145 @@ MODULE_ALIAS("platform:omap-dwc3");
  MODULE_AUTHOR("Felipe Balbi ");
  MODULE_LICENSE("GPL v2");
  MODULE_DESCRIPTION("DesignWare USB3 OMAP Glue Layer");
 +
 +#else
 +
 +int usb_gadget_handle_interrupts(int index)
>>>
>>> Can this be made somehow more generic , so that the core code would
>>> contain the basic interrupt handling and probe routines and the various
>>> SoC-specific drivers would add their specific bits to it ?
>>>
>>
>> How about moving this to drivers/usb/dwc3/gadget.c and then provide a
>> callback to each of SoC specific drivers?
>>
> That could work.

Sorry, looking at this further I dont see a easy way of doing this.

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.

I see MUSB driver uses a global pointer to musb struct (see
drivers/usb/musb-new/musb_uboot.c::usb_gadget_handle_interrupts()), but
I dont think thats a good option.


Let me know your preference. Any suggestion appreciated. Thanks!

-- 
Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Marek Vasut]

On 06/14/2017 02:25 PM, Vignesh R wrote:
[...]
>>>  /**
>>>   * dwc3_omap_uboot_init - dwc3 omap uboot initialization code
>>>   * @dev: struct dwc3_omap_device containing initialization data
>>> @@ -462,3 +487,145 @@ MODULE_ALIAS("platform:omap-dwc3");
>>>  MODULE_AUTHOR("Felipe Balbi ");
>>>  MODULE_LICENSE("GPL v2");
>>>  MODULE_DESCRIPTION("DesignWare USB3 OMAP Glue Layer");
>>> +
>>> +#else
>>> +
>>> +int usb_gadget_handle_interrupts(int index)
>>
>> Can this be made somehow more generic , so that the core code would
>> contain the basic interrupt handling and probe routines and the various
>> SoC-specific drivers would add their specific bits to it ?
>>
> 
> How about moving this to drivers/usb/dwc3/gadget.c and then provide a
> callback to each of SoC specific drivers?
> 
That could work.


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Vignesh R]

On Tuesday 13 June 2017 07:33 PM, Marek Vasut wrote:
> On 06/13/2017 02:10 PM, Vignesh R wrote:
>> From: Mugunthan V N 
>>
>> Add a TI DWC3 peripheral driver with driver model support and the
>> driver will be bound by the DWC3 wrapper driver based on the
>> dr_mode device tree entry.
>>
>> Signed-off-by: Mugunthan V N 
>> Signed-off-by: Vignesh R 
>> ---
>>  drivers/usb/dwc3/core.c  |  57 +++
>>  drivers/usb/dwc3/core.h  |   6 ++
>>  drivers/usb/dwc3/dwc3-omap.c | 167 
>> +++
>>  3 files changed, 230 insertions(+)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 98102bd6b00a..a895f8fbddd3 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -603,6 +603,8 @@ static void dwc3_core_exit_mode(struct dwc3 *dwc)
>>  
>>  #define DWC3_ALIGN_MASK (16 - 1)
>>  
>> +#ifndef CONFIG_DM_USB
>> +
>>  /**
>>   * dwc3_uboot_init - dwc3 core uboot initialization code
>>   * @dwc3_dev: struct dwc3_device containing initialization data
>> @@ -789,3 +791,58 @@ MODULE_ALIAS("platform:dwc3");
>>  MODULE_AUTHOR("Felipe Balbi ");
>>  MODULE_LICENSE("GPL v2");
>>  MODULE_DESCRIPTION("DesignWare USB3 DRD Controller Driver");
>> +
>> +#else
>> +
>> +int dwc3_init(struct dwc3 *dwc)
>> +{
>> +int ret;
>> +
>> +dwc3_cache_hwparams(dwc);
>> +
>> +ret = dwc3_alloc_event_buffers(dwc, DWC3_EVENT_BUFFERS_SIZE);
>> +if (ret) {
>> +dev_err(dwc->dev, "failed to allocate event buffers\n");
>> +return -ENOMEM;
>> +}
>> +
>> +ret = dwc3_core_init(dwc);
>> +if (ret) {
>> +dev_err(dev, "failed to initialize core\n");
>> +goto err0;
>> +}
>> +
>> +ret = dwc3_event_buffers_setup(dwc);
>> +if (ret) {
>> +dev_err(dwc->dev, "failed to setup event buffers\n");
>> +goto err1;
>> +}
>> +
>> +ret = dwc3_core_init_mode(dwc);
>> +if (ret)
>> +goto err2;
>> +
>> +return 0;
>> +
>> +err2:
> 
> Use more descriptive label names please ...

Ok, will do in next version.

> 
>> +dwc3_event_buffers_cleanup(dwc);
>> +
>> +err1:
>> +dwc3_core_exit(dwc);
>> +
>> +err0:
>> +dwc3_free_event_buffers(dwc);
>> +
>> +return ret;
>> +}
>> +
>> +void dwc3_remove(struct dwc3 *dwc)
>> +{
>> +dwc3_core_exit_mode(dwc);
>> +dwc3_event_buffers_cleanup(dwc);
>> +dwc3_free_event_buffers(dwc);
>> +dwc3_core_exit(dwc);
>> +kfree(dwc->mem);
>> +}
>> +
>> +#endif
>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>> index 72d2fcdd3f42..972628751697 100644
>> --- a/drivers/usb/dwc3/core.h
>> +++ b/drivers/usb/dwc3/core.h
>> @@ -713,7 +713,11 @@ struct dwc3 {
>>  /* device lock */
>>  spinlock_t  lock;
>>  
>> +#ifndef CONFIG_DM_USB
>>  struct device   *dev;
>> +#else
>> +struct udevice  *dev;
>> +#endif
>>  
>>  struct platform_device  *xhci;
>>  struct resource xhci_resources[DWC3_XHCI_RESOURCES_NUM];
>> @@ -988,6 +992,8 @@ struct dwc3_gadget_ep_cmd_params {
>>  
>>  /* prototypes */
>>  int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc);
>> +int dwc3_init(struct dwc3 *dwc);
>> +void dwc3_remove(struct dwc3 *dwc);
>>  
>>  #ifdef CONFIG_USB_DWC3_HOST
>>  int dwc3_host_init(struct dwc3 *dwc);
>> diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
>> index f18884f13392..b4dde726c6f3 100644
>> --- a/drivers/usb/dwc3/dwc3-omap.c
>> +++ b/drivers/usb/dwc3/dwc3-omap.c
>> @@ -27,6 +27,23 @@
>>  #include 
>>  
>>  #include "linux-compat.h"
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "core.h"
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include "gadget.h"
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>>  
>>  /*
>>   * All these registers belong to OMAP's Wrapper around the
>> @@ -135,6 +152,12 @@ struct dwc3_omap {
>>  u32 index;
>>  };
>>  
>> +struct omap_dwc3_priv {
>> +struct dwc3_omap omap;
>> +struct dwc3 dwc3;
>> +struct ti_usb_phy_device phy_device;
>> +};
>> +
>>  static LIST_HEAD(dwc3_omap_list);
>>  
>>  static inline u32 dwc3_omap_readl(void __iomem *base, u32 offset)
>> @@ -362,6 +385,8 @@ static void dwc3_omap_set_utmi_mode(struct dwc3_omap 
>> *omap, int utmi_mode)
>>  dwc3_omap_write_utmi_status(omap, reg);
>>  }
>>  
>> +#ifndef CONFIG_DM_USB
>> +
>>  /**
>>   * dwc3_omap_uboot_init - dwc3 omap uboot initialization code
>>   * @dev: struct dwc3_omap_device containing initialization data
>> @@ -462,3 +487,145 @@ MODULE_ALIAS("platform:omap-dwc3");
>>  MODULE_AUTHOR("Felipe Balbi ");
>>  MODULE_LICENSE("GPL v2");
>>  MODULE_DESCRIPTION("DesignWare USB3 OMAP Glue Layer");
>> +
>> +#else
>> +
>> +int usb_gadget_handle_interrupts(int index)
> 
> Can this be made somehow more generic , so that the 

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

[Marek Vasut]

On 06/13/2017 02:10 PM, Vignesh R wrote:
> From: Mugunthan V N 
> 
> Add a TI DWC3 peripheral driver with driver model support and the
> driver will be bound by the DWC3 wrapper driver based on the
> dr_mode device tree entry.
> 
> Signed-off-by: Mugunthan V N 
> Signed-off-by: Vignesh R 
> ---
>  drivers/usb/dwc3/core.c  |  57 +++
>  drivers/usb/dwc3/core.h  |   6 ++
>  drivers/usb/dwc3/dwc3-omap.c | 167 
> +++
>  3 files changed, 230 insertions(+)
> 
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 98102bd6b00a..a895f8fbddd3 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -603,6 +603,8 @@ static void dwc3_core_exit_mode(struct dwc3 *dwc)
>  
>  #define DWC3_ALIGN_MASK  (16 - 1)
>  
> +#ifndef CONFIG_DM_USB
> +
>  /**
>   * dwc3_uboot_init - dwc3 core uboot initialization code
>   * @dwc3_dev: struct dwc3_device containing initialization data
> @@ -789,3 +791,58 @@ MODULE_ALIAS("platform:dwc3");
>  MODULE_AUTHOR("Felipe Balbi ");
>  MODULE_LICENSE("GPL v2");
>  MODULE_DESCRIPTION("DesignWare USB3 DRD Controller Driver");
> +
> +#else
> +
> +int dwc3_init(struct dwc3 *dwc)
> +{
> + int ret;
> +
> + dwc3_cache_hwparams(dwc);
> +
> + ret = dwc3_alloc_event_buffers(dwc, DWC3_EVENT_BUFFERS_SIZE);
> + if (ret) {
> + dev_err(dwc->dev, "failed to allocate event buffers\n");
> + return -ENOMEM;
> + }
> +
> + ret = dwc3_core_init(dwc);
> + if (ret) {
> + dev_err(dev, "failed to initialize core\n");
> + goto err0;
> + }
> +
> + ret = dwc3_event_buffers_setup(dwc);
> + if (ret) {
> + dev_err(dwc->dev, "failed to setup event buffers\n");
> + goto err1;
> + }
> +
> + ret = dwc3_core_init_mode(dwc);
> + if (ret)
> + goto err2;
> +
> + return 0;
> +
> +err2:

Use more descriptive label names please ...

> + dwc3_event_buffers_cleanup(dwc);
> +
> +err1:
> + dwc3_core_exit(dwc);
> +
> +err0:
> + dwc3_free_event_buffers(dwc);
> +
> + return ret;
> +}
> +
> +void dwc3_remove(struct dwc3 *dwc)
> +{
> + dwc3_core_exit_mode(dwc);
> + dwc3_event_buffers_cleanup(dwc);
> + dwc3_free_event_buffers(dwc);
> + dwc3_core_exit(dwc);
> + kfree(dwc->mem);
> +}
> +
> +#endif
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 72d2fcdd3f42..972628751697 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -713,7 +713,11 @@ struct dwc3 {
>   /* device lock */
>   spinlock_t  lock;
>  
> +#ifndef CONFIG_DM_USB
>   struct device   *dev;
> +#else
> + struct udevice  *dev;
> +#endif
>  
>   struct platform_device  *xhci;
>   struct resource xhci_resources[DWC3_XHCI_RESOURCES_NUM];
> @@ -988,6 +992,8 @@ struct dwc3_gadget_ep_cmd_params {
>  
>  /* prototypes */
>  int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc);
> +int dwc3_init(struct dwc3 *dwc);
> +void dwc3_remove(struct dwc3 *dwc);
>  
>  #ifdef CONFIG_USB_DWC3_HOST
>  int dwc3_host_init(struct dwc3 *dwc);
> diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
> index f18884f13392..b4dde726c6f3 100644
> --- a/drivers/usb/dwc3/dwc3-omap.c
> +++ b/drivers/usb/dwc3/dwc3-omap.c
> @@ -27,6 +27,23 @@
>  #include 
>  
>  #include "linux-compat.h"
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "core.h"
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include "gadget.h"
> +
> +DECLARE_GLOBAL_DATA_PTR;
>  
>  /*
>   * All these registers belong to OMAP's Wrapper around the
> @@ -135,6 +152,12 @@ struct dwc3_omap {
>   u32 index;
>  };
>  
> +struct omap_dwc3_priv {
> + struct dwc3_omap omap;
> + struct dwc3 dwc3;
> + struct ti_usb_phy_device phy_device;
> +};
> +
>  static LIST_HEAD(dwc3_omap_list);
>  
>  static inline u32 dwc3_omap_readl(void __iomem *base, u32 offset)
> @@ -362,6 +385,8 @@ static void dwc3_omap_set_utmi_mode(struct dwc3_omap 
> *omap, int utmi_mode)
>   dwc3_omap_write_utmi_status(omap, reg);
>  }
>  
> +#ifndef CONFIG_DM_USB
> +
>  /**
>   * dwc3_omap_uboot_init - dwc3 omap uboot initialization code
>   * @dev: struct dwc3_omap_device containing initialization data
> @@ -462,3 +487,145 @@ MODULE_ALIAS("platform:omap-dwc3");
>  MODULE_AUTHOR("Felipe Balbi ");
>  MODULE_LICENSE("GPL v2");
>  MODULE_DESCRIPTION("DesignWare USB3 OMAP Glue Layer");
> +
> +#else
> +
> +int usb_gadget_handle_interrupts(int index)

Can this be made somehow more generic , so that the core code would
contain the basic interrupt handling and probe routines and the various
SoC-specific drivers would add their specific bits to it ?

> +{
> + struct omap_dwc3_priv *priv;
> + struct dwc3_omap *omap;
> 

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

[Vignesh R]

From: Mugunthan V N 

Add a TI DWC3 peripheral driver with driver model support and the
driver will be bound by the DWC3 wrapper driver based on the
dr_mode device tree entry.

Signed-off-by: Mugunthan V N 
Signed-off-by: Vignesh R 
---
 drivers/usb/dwc3/core.c  |  57 +++
 drivers/usb/dwc3/core.h  |   6 ++
 drivers/usb/dwc3/dwc3-omap.c | 167 +++
 3 files changed, 230 insertions(+)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 98102bd6b00a..a895f8fbddd3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -603,6 +603,8 @@ static void dwc3_core_exit_mode(struct dwc3 *dwc)
 
 #define DWC3_ALIGN_MASK(16 - 1)
 
+#ifndef CONFIG_DM_USB
+
 /**
  * dwc3_uboot_init - dwc3 core uboot initialization code
  * @dwc3_dev: struct dwc3_device containing initialization data
@@ -789,3 +791,58 @@ MODULE_ALIAS("platform:dwc3");
 MODULE_AUTHOR("Felipe Balbi ");
 MODULE_LICENSE("GPL v2");
 MODULE_DESCRIPTION("DesignWare USB3 DRD Controller Driver");
+
+#else
+
+int dwc3_init(struct dwc3 *dwc)
+{
+   int ret;
+
+   dwc3_cache_hwparams(dwc);
+
+   ret = dwc3_alloc_event_buffers(dwc, DWC3_EVENT_BUFFERS_SIZE);
+   if (ret) {
+   dev_err(dwc->dev, "failed to allocate event buffers\n");
+   return -ENOMEM;
+   }
+
+   ret = dwc3_core_init(dwc);
+   if (ret) {
+   dev_err(dev, "failed to initialize core\n");
+   goto err0;
+   }
+
+   ret = dwc3_event_buffers_setup(dwc);
+   if (ret) {
+   dev_err(dwc->dev, "failed to setup event buffers\n");
+   goto err1;
+   }
+
+   ret = dwc3_core_init_mode(dwc);
+   if (ret)
+   goto err2;
+
+   return 0;
+
+err2:
+   dwc3_event_buffers_cleanup(dwc);
+
+err1:
+   dwc3_core_exit(dwc);
+
+err0:
+   dwc3_free_event_buffers(dwc);
+
+   return ret;
+}
+
+void dwc3_remove(struct dwc3 *dwc)
+{
+   dwc3_core_exit_mode(dwc);
+   dwc3_event_buffers_cleanup(dwc);
+   dwc3_free_event_buffers(dwc);
+   dwc3_core_exit(dwc);
+   kfree(dwc->mem);
+}
+
+#endif
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 72d2fcdd3f42..972628751697 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -713,7 +713,11 @@ struct dwc3 {
/* device lock */
spinlock_t  lock;
 
+#ifndef CONFIG_DM_USB
struct device   *dev;
+#else
+   struct udevice  *dev;
+#endif
 
struct platform_device  *xhci;
struct resource xhci_resources[DWC3_XHCI_RESOURCES_NUM];
@@ -988,6 +992,8 @@ struct dwc3_gadget_ep_cmd_params {
 
 /* prototypes */
 int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc);
+int dwc3_init(struct dwc3 *dwc);
+void dwc3_remove(struct dwc3 *dwc);
 
 #ifdef CONFIG_USB_DWC3_HOST
 int dwc3_host_init(struct dwc3 *dwc);
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index f18884f13392..b4dde726c6f3 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -27,6 +27,23 @@
 #include 
 
 #include "linux-compat.h"
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include "gadget.h"
+
+DECLARE_GLOBAL_DATA_PTR;
 
 /*
  * All these registers belong to OMAP's Wrapper around the
@@ -135,6 +152,12 @@ struct dwc3_omap {
u32 index;
 };
 
+struct omap_dwc3_priv {
+   struct dwc3_omap omap;
+   struct dwc3 dwc3;
+   struct ti_usb_phy_device phy_device;
+};
+
 static LIST_HEAD(dwc3_omap_list);
 
 static inline u32 dwc3_omap_readl(void __iomem *base, u32 offset)
@@ -362,6 +385,8 @@ static void dwc3_omap_set_utmi_mode(struct dwc3_omap *omap, 
int utmi_mode)
dwc3_omap_write_utmi_status(omap, reg);
 }
 
+#ifndef CONFIG_DM_USB
+
 /**
  * dwc3_omap_uboot_init - dwc3 omap uboot initialization code
  * @dev: struct dwc3_omap_device containing initialization data
@@ -462,3 +487,145 @@ MODULE_ALIAS("platform:omap-dwc3");
 MODULE_AUTHOR("Felipe Balbi ");
 MODULE_LICENSE("GPL v2");
 MODULE_DESCRIPTION("DesignWare USB3 OMAP Glue Layer");
+
+#else
+
+int usb_gadget_handle_interrupts(int index)
+{
+   struct omap_dwc3_priv *priv;
+   struct dwc3_omap *omap;
+   struct dwc3 *dwc;
+   struct udevice *dev;
+   u32 status;
+   int ret;
+
+   ret = uclass_first_device(UCLASS_USB_DEV_GENERIC, );
+   if (!dev || ret) {
+   error("No USB device found\n");
+   return -ENODEV;
+   }
+
+   priv = dev_get_priv(dev);
+   omap = >omap;
+   dwc = >dwc3;
+
+   status = dwc3_omap_interrupt(-1, omap);
+   if (status)
+   dwc3_gadget_uboot_handle_interrupt(dwc);
+
+   return 0;
+}
+
+static int dwc3_omap_peripheral_probe(struct