bcma USB Host driver

bcma USB Host driver

[Hauke Mehrtens]

Hi,

I am thinking on how to implement the usb host driver for the bcma bus
correctly. bcma is the driver for Broadcom's AMBA implementation (see
drivers/bcma/ ) and on SoCs it also provides a core with an USB Host
controller. This USB host controller has an OHCI and an EHCI interface
on different addresses, but it is on core on this bus, just with two
address spaces [0]. For the software developers point of view it is
pretty similar to Braodcoms SSB bus, for which I have the same problem.

The bcma bus driver exposes one device for this core which is
responsibility for EHCI and OHCI at the same time. Now I implemented a
driver for ehci and one for ohci but just one gets registered, because
only one is able to claim this device. I based my work on how it is done
for the ssb bus, which is similar to the bcma bus implementation and
there is already a ohci driver for ssb in the kernel (see
drivers/usb/host/ohci-ssb.c ), but no ehci driver (I want to add that
also, for now we only have some hacky think in OpenWrt).

The Broadcom hardware uses a standard ehci and ohci interface, there are
just some register reads and writes needed at startup to work around
some hardware bugs. In the Braodcom SDK they are registering the USB
core as two PCI device and are using the normal pci drivers.

To provide ehci and ohci at the same time I came up with some solutions:

1. The OHCI driver also initializes the EHCI driver, when it gets load
and is an USB 2.0 device. This is how it is done in OpenWrt and I do not
like it [1].
2. bcma provides two devices with different identification and there are
two independ drivers working with it.
3. bcma handles the usb registration directly and all code goes to
drivers/bcma/
4. Is there some way like a platform device with a memory address which
I could register and which is then handled by the usb system?

Are there any better approaches on how to do this? I do not think I am
the first person with such a problem.

Hauke

[0]:
https://github.com/hauke/openwrt/commit/43e4344b7b8b4d7fb5a6220066effde30cb00501#diff-4
[1]:
https://dev.openwrt.org/browser/trunk/target/linux/brcm47xx/patches-3.0/023-usb_ehci_ohci.patch

Re: bcma USB Host driver

[Arend van Spriel]

On 11/21/2011 10:56 PM, Hauke Mehrtens wrote:
> Hi,
> 
> To provide ehci and ohci at the same time I came up with some solutions:
> 
> 1. The OHCI driver also initializes the EHCI driver, when it gets load
> and is an USB 2.0 device. This is how it is done in OpenWrt and I do not
> like it [1].
> 2. bcma provides two devices with different identification and there are
> two independ drivers working with it.

When doing this the wrapper access (bcma_aread/awrite) will have effect
on both not-so-independent drivers.

> 3. bcma handles the usb registration directly and all code goes to
> drivers/bcma/

Sound like mixing device driver functionality in a bus driver. It does
not feel right to me, but bcma is already handling chipcommon, and
pci(e) cores.

Main question would be whether a linux device driver can provide
multiple system functions. I tend to say it can. So I would suggest to
have a single device driver providing OHCI and EHCI functionality.

> 4. Is there some way like a platform device with a memory address which
> I could register and which is then handled by the usb system?
> 
> Are there any better approaches on how to do this? I do not think I am
> the first person with such a problem.
> 
> Hauke
> 

Gr. AvS

ps.: I polled again internally about et driver support. Keep you posted.

Re: bcma USB Host driver

[Hauke Mehrtens]

Hi Arend,

On 11/22/2011 12:50 PM, Arend van Spriel wrote:
> On 11/21/2011 10:56 PM, Hauke Mehrtens wrote:
>> Hi,
>>
>> To provide ehci and ohci at the same time I came up with some solutions:
>>
>> 1. The OHCI driver also initializes the EHCI driver, when it gets load
>> and is an USB 2.0 device. This is how it is done in OpenWrt and I do not
>> like it [1].
>> 2. bcma provides two devices with different identification and there are
>> two independ drivers working with it.
> 
> When doing this the wrapper access (bcma_aread/awrite) will have effect
> on both not-so-independent drivers.
Yes that will be a workaround for this problem and will probably cause
problems when some other new features are added as we have an additional
corner case to handle.

>> 3. bcma handles the usb registration directly and all code goes to
>> drivers/bcma/
> 
> Sound like mixing device driver functionality in a bus driver. It does
> not feel right to me, but bcma is already handling chipcommon, and
> pci(e) cores.
> 
> Main question would be whether a linux device driver can provide
> multiple system functions. I tend to say it can. So I would suggest to
> have a single device driver providing OHCI and EHCI functionality.

@USB guys, how do I design a driver for a linux device providing ohci
and ehci functionality at the same time. The device has two address
spaces one for ehci and one for ohci functions.
I thought about registering one controller (ehci or ohci) with
usb_create_shared_hcd(). The code then will be in an own module and not
in echi_hcd.ko and ochi_hcd.ko like for pci, I hope this works.
Is there a better solution to do this, is there an other driver with the
same problem already solved?

>> 4. Is there some way like a platform device with a memory address which
>> I could register and which is then handled by the usb system?
>>
>> Are there any better approaches on how to do this? I do not think I am
>> the first person with such a problem.
>>
>> Hauke
>>
> 
> Gr. AvS
> 
> ps.: I polled again internally about et driver support. Keep you posted.
> 

Re: bcma USB Host driver

[Alan Stern]

On Sat, 26 Nov 2011, Hauke Mehrtens wrote:

> > Main question would be whether a linux device driver can provide
> > multiple system functions. I tend to say it can. So I would suggest to
> > have a single device driver providing OHCI and EHCI functionality.
> 
> @USB guys, how do I design a driver for a linux device providing ohci
> and ehci functionality at the same time. The device has two address
> spaces one for ehci and one for ohci functions.

How many IRQ lines?

And incidentally, in what sense is this _one_ device?  Are you sure 
it's not _two_ devices in one package?

> I thought about registering one controller (ehci or ohci) with
> usb_create_shared_hcd(). The code then will be in an own module and not
> in echi_hcd.ko and ochi_hcd.ko like for pci, I hope this works.
> Is there a better solution to do this, is there an other driver with the
> same problem already solved?

I don't know of any other driver that does this.  Your best solution is 
probably write a driver that registers two child platform devices, and 
write two corresponding platform drivers, one for the EHCI part and one 
for the OHCI part.

Alan Stern

Re: bcma USB Host driver

[Hauke Mehrtens]

Hi Alan,

On 11/26/2011 02:27 AM, Alan Stern wrote:
> On Sat, 26 Nov 2011, Hauke Mehrtens wrote:
> 
>>> Main question would be whether a linux device driver can provide
>>> multiple system functions. I tend to say it can. So I would suggest to
>>> have a single device driver providing OHCI and EHCI functionality.
>>
>> @USB guys, how do I design a driver for a linux device providing ohci
>> and ehci functionality at the same time. The device has two address
>> spaces one for ehci and one for ohci functions.
> 
> How many IRQ lines?
The ehci and ohci controller are sharing one IRQ line.
> 
> And incidentally, in what sense is this _one_ device?  Are you sure 
> it's not _two_ devices in one package?
This is an SoC, so in hardware it is a chip with many functionality. On
the internal bus it is connected as one device, which offers two address
spaces. I do not have access to the detailed hardware specs just some
other driver source code.
> 
>> I thought about registering one controller (ehci or ohci) with
>> usb_create_shared_hcd(). The code then will be in an own module and not
>> in echi_hcd.ko and ochi_hcd.ko like for pci, I hope this works.
>> Is there a better solution to do this, is there an other driver with the
>> same problem already solved?
> 
> I don't know of any other driver that does this.  Your best solution is 
> probably write a driver that registers two child platform devices, and 
> write two corresponding platform drivers, one for the EHCI part and one 
> for the OHCI part.
Thanks for this tip. I did this and it is working nicely. It has an
other advantage, for the ssb bus I was able to use the same platform
drivers as used for the bcma bus.
> 
> Alan Stern
> 

Hauke