How to support SDIO wifi/bt in DT

How to support SDIO wifi/bt in DT

[Russell King - ARM Linux]

Okay, I'm hitting something of a dead end with trying to work out how to
support this in DT.

The Wifi/BT (bcrmfmac) device has multiple connections to the host device
- it has a SDIO connection, a UART connection, and an audio connection.
In addition, a series of GPIOs are wired to control this device:

- Reset for bluetooth plus two additional GPIOs (unused I think)
- Reset for Wifi plus two additional GPIOs (again, I think unused)
- GPIO to control regulator supplying power to the Wifi/BT chip
- GPIO to control regulator supplying power to the oscillator for
  the Wifi/BT chip.

The Wifi/BT chip can only be detected via probing the SDIO connection, and
only when the device has been powered up and released from reset - so we
have to power up and reset the bcrm device before we probe via the SDIO
bus.

While it's possible to attach the power supply for the Wifi/BT chip to the
vmmc-supply property of the host, it's not possible to do that with the
oscillator supply.  Neither is there any provision for manipulating the
GPIOs to deal with the resets.

I can't find any examples of anything similar in our existing set of DT
files, so I suspect either this is a device which no one supports on any
DT platform, or there's some clever way to handle this.

How do other people support this in DT?  Do they hack up some platform
specific code (which isn't nice)?  What other solutions are there to get
around this problem?  How does this kind of thing get represented in DT?

(Don't suggest adding DT support to the bcrmfmac driver - this is a
chicken-and-egg problem.  The driver isn't being probed at the moment
because the device is powered down and/or held in reset, so is
undetectable.  The kernel needs to power it up and release the reset
so it becomes detectable.)

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

How to support SDIO wifi/bt in DT

[Chen-Yu Tsai]

Hi,

On Thu, Jan 16, 2014 at 9:36 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> Okay, I'm hitting something of a dead end with trying to work out how to
> support this in DT.
>
> The Wifi/BT (bcrmfmac) device has multiple connections to the host device
> - it has a SDIO connection, a UART connection, and an audio connection.
> In addition, a series of GPIOs are wired to control this device:
>
> - Reset for bluetooth plus two additional GPIOs (unused I think)

The other 2 are wake and host wake (interrupts in either direction) I suppose?
The device should support in-band signaling over the UART as well, and
we have no way to tie these 2 interrupts to the bluetooth device anyway.

> - Reset for Wifi plus two additional GPIOs (again, I think unused)

Again, should be out-of-band interrupts in both directions.

> - GPIO to control regulator supplying power to the Wifi/BT chip
> - GPIO to control regulator supplying power to the oscillator for
>   the Wifi/BT chip.
>
> The Wifi/BT chip can only be detected via probing the SDIO connection, and
> only when the device has been powered up and released from reset - so we
> have to power up and reset the bcrm device before we probe via the SDIO
> bus.
>
> While it's possible to attach the power supply for the Wifi/BT chip to the
> vmmc-supply property of the host, it's not possible to do that with the
> oscillator supply.  Neither is there any provision for manipulating the
> GPIOs to deal with the resets.

Android devices would probably use a custom rfkill device.

> I can't find any examples of anything similar in our existing set of DT
> files, so I suspect either this is a device which no one supports on any
> DT platform, or there's some clever way to handle this.
>
> How do other people support this in DT?  Do they hack up some platform
> specific code (which isn't nice)?  What other solutions are there to get
> around this problem?  How does this kind of thing get represented in DT?

AFAIK, there is none at the moment.

I am working on a patch series that adds DT support to rfkill-gpio.
rfkill-gpio takes at most 2 GPIOs and 1 clock for each rfkill control.
You would register one for wifi, and one for bluetooth. The patches
should be posted by tomorrow, hopefully.

But the brcmfmac driver also registers one itself, so you would have
2 wifi rfkills in the system. So I register my wifi power as a regulator
that is always on, using fixed-regulator with the regulator-always-on DT
property.

> (Don't suggest adding DT support to the bcrmfmac driver - this is a
> chicken-and-egg problem.  The driver isn't being probed at the moment
> because the device is powered down and/or held in reset, so is
> undetectable.  The kernel needs to power it up and release the reset
> so it becomes detectable.)

The brcmfmac driver also has a platform device component, which one can
give power on/off callbacks through platform data. Maybe we can add DT
support to this bit as well.

I'v already completed device tree support for the SDIO device part, to
be able to use out-of-band interrupt signaling. However the sunxi GPIO
driver isn't well tested, and I am not getting interrupts. Still have to
sort this out to actually test my work.


Cheers,
ChenYu

How to support SDIO wifi/bt in DT

[Arnd Bergmann]

On Thursday 16 January 2014 13:36:49 Russell King - ARM Linux wrote:

> 
> The Wifi/BT chip can only be detected via probing the SDIO connection, and
> only when the device has been powered up and released from reset - so we
> have to power up and reset the bcrm device before we probe via the SDIO
> bus.

This is indeed a common problem, and while we've talked about solving
it in the past, nothing has happened code-wise. It indeed needs an
implementation in the sdio framework.

> While it's possible to attach the power supply for the Wifi/BT chip to the
> vmmc-supply property of the host, it's not possible to do that with the
> oscillator supply.  Neither is there any provision for manipulating the
> GPIOs to deal with the resets.
> 
> I can't find any examples of anything similar in our existing set of DT
> files, so I suspect either this is a device which no one supports on any
> DT platform, or there's some clever way to handle this.

The former.

> How do other people support this in DT?  Do they hack up some platform
> specific code (which isn't nice)?  What other solutions are there to get
> around this problem?  How does this kind of thing get represented in DT?
> 
> (Don't suggest adding DT support to the bcrmfmac driver - this is a
> chicken-and-egg problem.  The driver isn't being probed at the moment
> because the device is powered down and/or held in reset, so is
> undetectable.  The kernel needs to power it up and release the reset
> so it becomes detectable.)

The problem is two-fold:

a) we need to add a generic mechanism to the SDIO probe code to
allow specifying clocks, regulators and resets (possibly more)
for an SDIO endpoint that get enabled before the probe starts.
This parts needs a DT binding for SDIO slots as well as code.

b) We need to add a way to attach a device_node to an sdio_func,
so that a function driver can find additional DT properties.
This part should be relatively simple once (a) is done and
should only need a little code but no new binding. The code
would be similar to what we do for amba, i2c or spi devices.

Note that the same problem exists for a number of other discoverable
buses that get used in nondiscoverable ways, e.g. USB, PCI, 
or even SCSI. It's normally a spec violation if those devices
are wired up like this, but of course we still want to support
the hardware.

	Arnd

How to support SDIO wifi/bt in DT

[Olof Johansson]

[adding devicetree and mmc lists]

On Thu, Jan 16, 2014 at 6:02 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 16 January 2014 13:36:49 Russell King - ARM Linux wrote:
>
>>
>> The Wifi/BT chip can only be detected via probing the SDIO connection, and
>> only when the device has been powered up and released from reset - so we
>> have to power up and reset the bcrm device before we probe via the SDIO
>> bus.
>
> This is indeed a common problem, and while we've talked about solving
> it in the past, nothing has happened code-wise. It indeed needs an
> implementation in the sdio framework.

Yeah, this is what's keeping wifi from working on the ARM Chromebook
upstream as well, and it's been on my list to deal with for a long
time. So now is as good a time as any.

Generic SDIO framework solution/binding would be great, since these
constructs are quite common on systems these days (even x86 is
starting to get peripherals on SDIO).

>> While it's possible to attach the power supply for the Wifi/BT chip to the
>> vmmc-supply property of the host, it's not possible to do that with the
>> oscillator supply.  Neither is there any provision for manipulating the
>> GPIOs to deal with the resets.
>>
>> I can't find any examples of anything similar in our existing set of DT
>> files, so I suspect either this is a device which no one supports on any
>> DT platform, or there's some clever way to handle this.
>
> The former.

We've dealt with it with local code in our tree for Chrome OS, and I
suspect everyone else has too. It's definitely time to solve
generically.

>> How do other people support this in DT?  Do they hack up some platform
>> specific code (which isn't nice)?  What other solutions are there to get
>> around this problem?  How does this kind of thing get represented in DT?
>>
>> (Don't suggest adding DT support to the bcrmfmac driver - this is a
>> chicken-and-egg problem.  The driver isn't being probed at the moment
>> because the device is powered down and/or held in reset, so is
>> undetectable.  The kernel needs to power it up and release the reset
>> so it becomes detectable.)
>
> The problem is two-fold:
>
> a) we need to add a generic mechanism to the SDIO probe code to
> allow specifying clocks, regulators and resets (possibly more)
> for an SDIO endpoint that get enabled before the probe starts.
> This parts needs a DT binding for SDIO slots as well as code.

"for SDIO slots" is somewhat misleading; nearly all controllers only
do one slot/device per controller. The designware controller can do
multiple slots, and that adds a bit of driver and binding complexity
for something that seemingly not a single vendor has actually
implemented.

So we can likely assume to keep these reset/power/clock lines per host
controller, no need to add a slot construct.

> b) We need to add a way to attach a device_node to an sdio_func,
> so that a function driver can find additional DT properties.
> This part should be relatively simple once (a) is done and
> should only need a little code but no new binding. The code
> would be similar to what we do for amba, i2c or spi devices.

This isn't actually needed for this functionality, but might be needed
for other things...

> Note that the same problem exists for a number of other discoverable
> buses that get used in nondiscoverable ways, e.g. USB, PCI,
> or even SCSI. It's normally a spec violation if those devices
> are wired up like this, but of course we still want to support
> the hardware.

... such as these. :)

-Olof

How to support SDIO wifi/bt in DT

[Russell King - ARM Linux]

On Thu, Jan 16, 2014 at 09:15:17AM -0800, Olof Johansson wrote:
> We've dealt with it with local code in our tree for Chrome OS, and I
> suspect everyone else has too. It's definitely time to solve
> generically.

As there's no code for any Cubox-i or Hummingboard (they're both purely
DT), what this means is that the answer to Wifi/BT support in mainline is
that this is "impossible at the moment"...

I guess this is becoming a higher priority issue which really needs to be
solved somehow. :)

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

How to support SDIO wifi/bt in DT

[Olof Johansson]

On Thu, Jan 16, 2014 at 11:58 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Jan 16, 2014 at 09:15:17AM -0800, Olof Johansson wrote:
>> We've dealt with it with local code in our tree for Chrome OS, and I
>> suspect everyone else has too. It's definitely time to solve
>> generically.
>
> As there's no code for any Cubox-i or Hummingboard (they're both purely
> DT), what this means is that the answer to Wifi/BT support in mainline is
> that this is "impossible at the moment"...
>
> I guess this is becoming a higher priority issue which really needs to be
> solved somehow. :)

I'm looking at it right now actually, might as well sort it out while
people are paying attention. Patches a little later today unless I get
distrac^Winterrupted. :)


-Olof

How to support SDIO wifi/bt in DT

[Russell King - ARM Linux]

On Thu, Jan 16, 2014 at 12:00:47PM -0800, Olof Johansson wrote:
> On Thu, Jan 16, 2014 at 11:58 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Thu, Jan 16, 2014 at 09:15:17AM -0800, Olof Johansson wrote:
> >> We've dealt with it with local code in our tree for Chrome OS, and I
> >> suspect everyone else has too. It's definitely time to solve
> >> generically.
> >
> > As there's no code for any Cubox-i or Hummingboard (they're both purely
> > DT), what this means is that the answer to Wifi/BT support in mainline is
> > that this is "impossible at the moment"...
> >
> > I guess this is becoming a higher priority issue which really needs to be
> > solved somehow. :)
> 
> I'm looking at it right now actually, might as well sort it out while
> people are paying attention. Patches a little later today unless I get
> distrac^Winterrupted. :)

I'll look forward to them, but I may not be able to do much more this
evening.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

How to support SDIO wifi/bt in DT

[Alexandre Belloni]

On Thu, Jan 16, 2014 at 12:00:47PM -0800, Olof Johansson wrote :
> On Thu, Jan 16, 2014 at 11:58 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Thu, Jan 16, 2014 at 09:15:17AM -0800, Olof Johansson wrote:
> >> We've dealt with it with local code in our tree for Chrome OS, and I
> >> suspect everyone else has too. It's definitely time to solve
> >> generically.
> >
> > As there's no code for any Cubox-i or Hummingboard (they're both purely
> > DT), what this means is that the answer to Wifi/BT support in mainline is
> > that this is "impossible at the moment"...
> >
> > I guess this is becoming a higher priority issue which really needs to be
> > solved somehow. :)
> 
> I'm looking at it right now actually, might as well sort it out while
> people are paying attention. Patches a little later today unless I get
> distrac^Winterrupted. :)
> 

Maybe it is not completely related but I think it needs to be thought
about while you are it:

The TI wilink chips (TiWi, wl12xx, wl18xx) have wifi on SDIO and BT on
UART but they share the same clock. So, the next question would be what
if I just want to enable one or the other (and take that decision at
runtime) ?

Where do I put the pinctrl/clocks/regulators in the DT ? I guess it can
become an issue to enable both WiFi and BT at the same time if both SDIO
and UART are trying to handle the same pinctrl and regulators.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140117/4f42f4b4/attachment.sig>

How to support SDIO wifi/bt in DT

[Chen-Yu Tsai]

On Fri, Jan 17, 2014 at 5:39 PM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
> On Thu, Jan 16, 2014 at 12:00:47PM -0800, Olof Johansson wrote :
>> On Thu, Jan 16, 2014 at 11:58 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Thu, Jan 16, 2014 at 09:15:17AM -0800, Olof Johansson wrote:
>> >> We've dealt with it with local code in our tree for Chrome OS, and I
>> >> suspect everyone else has too. It's definitely time to solve
>> >> generically.
>> >
>> > As there's no code for any Cubox-i or Hummingboard (they're both purely
>> > DT), what this means is that the answer to Wifi/BT support in mainline is
>> > that this is "impossible at the moment"...
>> >
>> > I guess this is becoming a higher priority issue which really needs to be
>> > solved somehow. :)
>>
>> I'm looking at it right now actually, might as well sort it out while
>> people are paying attention. Patches a little later today unless I get
>> distrac^Winterrupted. :)
>>
>
> Maybe it is not completely related but I think it needs to be thought
> about while you are it:
>
> The TI wilink chips (TiWi, wl12xx, wl18xx) have wifi on SDIO and BT on
> UART but they share the same clock. So, the next question would be what
> if I just want to enable one or the other (and take that decision at
> runtime) ?

Some Broadcom chips (BCM4329/4330) and the AP6210 found on CubieTruck
are like this as well. In our case, the SD/MMC host driver hasn't been
mainlined yet. But BT on UART is independent and usable.

> Where do I put the pinctrl/clocks/regulators in the DT ? I guess it can
> become an issue to enable both WiFi and BT at the same time if both SDIO
> and UART are trying to handle the same pinctrl and regulators.

Shouldn't the clocks and regulators be registered in the DT _AS_ clocks
and regulators? fixed-regulator already accepts GPIO lines. fixed-rate-clock
mentions GPIOs in DT bindings, but doesn't seem to use them in the code.
We'd still need a device to tie them to, especially in the UART use case.

Or we could try rfkill devices. Not saying it's the correct way, but it is
a solution.


Cheers,
ChenYu

How to support SDIO wifi/bt in DT

[Alexandre Belloni]

On Fri, Jan 17, 2014 at 06:06:41PM +0800, Chen-Yu Tsai wrote :
> On Fri, Jan 17, 2014 at 5:39 PM, Alexandre Belloni
> <alexandre.belloni@free-electrons.com> wrote:
> > Maybe it is not completely related but I think it needs to be thought
> > about while you are it:
> >
> > The TI wilink chips (TiWi, wl12xx, wl18xx) have wifi on SDIO and BT on
> > UART but they share the same clock. So, the next question would be what
> > if I just want to enable one or the other (and take that decision at
> > runtime) ?
> 
> Some Broadcom chips (BCM4329/4330) and the AP6210 found on CubieTruck
> are like this as well. In our case, the SD/MMC host driver hasn't been
> mainlined yet. But BT on UART is independent and usable.
> 
> > Where do I put the pinctrl/clocks/regulators in the DT ? I guess it can
> > become an issue to enable both WiFi and BT at the same time if both SDIO
> > and UART are trying to handle the same pinctrl and regulators.
> 
> Shouldn't the clocks and regulators be registered in the DT _AS_ clocks
> and regulators? fixed-regulator already accepts GPIO lines. fixed-rate-clock
> mentions GPIOs in DT bindings, but doesn't seem to use them in the code.
> We'd still need a device to tie them to, especially in the UART use case.
> 

Yeah, I meant if you tie your clock/pinctrl/reset/regulator to both the
BT and the WiFI nodes because it is shared, you'll at least get a
warning or one of the two won't be working.

> Or we could try rfkill devices. Not saying it's the correct way, but it is
> a solution.
> 

You'll get the same issue there. Two rfkill devices sharing the same
clock or reset for example.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140117/d440c2f6/attachment.sig>

How to support SDIO wifi/bt in DT

[Andrew Lunn]

> The TI wilink chips (TiWi, wl12xx, wl18xx) have wifi on SDIO and BT on
> UART but they share the same clock. So, the next question would be what
> if I just want to enable one or the other (and take that decision at
> runtime) ?

At least for the clock is it not an issue. The generic clock framework
does "reference" counting. It will only turn the clock off when all
users have said to turn it off. So put a phandle to the clock in all
nodes which use it.

I've not looked at regulators, but i would hope it also does reference
counting of a regulators users.

	 Andrew

How to support SDIO wifi/bt in DT

[Mark Brown]

On Fri, Jan 17, 2014 at 11:44:23AM +0100, Andrew Lunn wrote:

> I've not looked at regulators, but i would hope it also does reference
> counting of a regulators users.

Yes, it does.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140205/3a80d2b9/attachment.sig>

How to support SDIO wifi/bt in DT

[Arnd Bergmann]

On Thursday 16 January 2014 09:15:17 Olof Johansson wrote:
> 
> > b) We need to add a way to attach a device_node to an sdio_func,
> > so that a function driver can find additional DT properties.
> > This part should be relatively simple once (a) is done and
> > should only need a little code but no new binding. The code
> > would be similar to what we do for amba, i2c or spi devices.
> 
> This isn't actually needed for this functionality, but might be needed
> for other things...
> 

There is at least one sdio driver (cw1200) that needs to get
a MAC address from DT and has the same kind of hack that
you mention to work around it at the moment (actually worse,
it's not even using auxdata). The MAC address is certainly
a property of the device, not the host. This is of course
the same problem that we have on various development boards
with USB ethernet controllers lacking an EEPROM.

Getting the device to probe in the first place is more important,
and this is a much simpler problem though.

	Arnd

How to support SDIO wifi/bt in DT

[Olof Johansson]

On Thu, Jan 16, 2014 at 1:46 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 16 January 2014 09:15:17 Olof Johansson wrote:
>>
>> > b) We need to add a way to attach a device_node to an sdio_func,
>> > so that a function driver can find additional DT properties.
>> > This part should be relatively simple once (a) is done and
>> > should only need a little code but no new binding. The code
>> > would be similar to what we do for amba, i2c or spi devices.
>>
>> This isn't actually needed for this functionality, but might be needed
>> for other things...
>>
>
> There is at least one sdio driver (cw1200) that needs to get
> a MAC address from DT and has the same kind of hack that
> you mention to work around it at the moment (actually worse,
> it's not even using auxdata). The MAC address is certainly
> a property of the device, not the host. This is of course
> the same problem that we have on various development boards
> with USB ethernet controllers lacking an EEPROM.

Yeah, definitely overlap with the on-board usb ethernet adapters where
the vendor hasn't bothered with an eeprom.

> Getting the device to probe in the first place is more important,
> and this is a much simpler problem though.

Yes, agreed -- both needs solving but they're separate issues.


-Olof

How to support SDIO wifi/bt in DT

[Marcel Holtmann]

Hi Arnd,

>>> b) We need to add a way to attach a device_node to an sdio_func,
>>> so that a function driver can find additional DT properties.
>>> This part should be relatively simple once (a) is done and
>>> should only need a little code but no new binding. The code
>>> would be similar to what we do for amba, i2c or spi devices.
>> 
>> This isn't actually needed for this functionality, but might be needed
>> for other things...
>> 
> 
> There is at least one sdio driver (cw1200) that needs to get
> a MAC address from DT and has the same kind of hack that
> you mention to work around it at the moment (actually worse,
> it's not even using auxdata). The MAC address is certainly
> a property of the device, not the host. This is of course
> the same problem that we have on various development boards
> with USB ethernet controllers lacking an EEPROM.

there are plenty of these devices. It is not just Ethernet or WiFi. You can add Bluetooth devices addresses to this as well. The Nokia N900 drivers for example. Even the Nexus 4 devices are in this boat as well.

The addresses are either stored in some magic place or plain simple on the host filesystem. Maybe this whole magic persistent IEEE addresses thing need its own subsystem. So drivers needing an address can just request it from the subsystem and the subsystem deals with the nasty storage details on how to get the addresses into the kernel in the first place. Currently it is a big mess.

I have seen nasty workaround with delayed initialization from probe or other crazy sysfs settings to just make this work.

Regards

Marcel

How to support SDIO wifi/bt in DT

[Nicolas Pitre]

On Thu, 16 Jan 2014, Olof Johansson wrote:

> "for SDIO slots" is somewhat misleading; nearly all controllers only
> do one slot/device per controller. The designware controller can do
> multiple slots, and that adds a bit of driver and binding complexity
> for something that seemingly not a single vendor has actually
> implemented.

The Marvell 8688, just to name one, does both WIFI and BlueTooth over 
the same SDIO controller using separate functions/slots.

Or maybe I'm misunderstanding you?


Nicolas

How to support SDIO wifi/bt in DT

[Arnd Bergmann]

On Friday 17 January 2014, Nicolas Pitre wrote:
> On Thu, 16 Jan 2014, Olof Johansson wrote:
> 
> > "for SDIO slots" is somewhat misleading; nearly all controllers only
> > do one slot/device per controller. The designware controller can do
> > multiple slots, and that adds a bit of driver and binding complexity
> > for something that seemingly not a single vendor has actually
> > implemented.
> 
> The Marvell 8688, just to name one, does both WIFI and BlueTooth over 
> the same SDIO controller using separate functions/slots.
> 
> Or maybe I'm misunderstanding you?
> 

I wasn't aware of this but I just checked (in mmc_attach_sdio) that
there can be multiple functions on a slot. I assume the sd8688 has
a single slot with two functions, so that potentially extends the
problem space if we need to supply clocks and regulators per
function rather than just per slot.

	Arnd

How to support SDIO wifi/bt in DT

[Rob Herring]

On Thu, Jan 16, 2014 at 9:08 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Thu, 16 Jan 2014, Olof Johansson wrote:
>
>> "for SDIO slots" is somewhat misleading; nearly all controllers only
>> do one slot/device per controller. The designware controller can do
>> multiple slots, and that adds a bit of driver and binding complexity
>> for something that seemingly not a single vendor has actually
>> implemented.
>
> The Marvell 8688, just to name one, does both WIFI and BlueTooth over
> the same SDIO controller using separate functions/slots.

But that is logical functions within a chip, not multiple discrete
chips (i.e. slots) with their own reset, regulators, etc. There would
still be a single set of external controls per host controller I
think.

Rob

How to support SDIO wifi/bt in DT

[Nicolas Pitre]

On Fri, 17 Jan 2014, Rob Herring wrote:

> On Thu, Jan 16, 2014 at 9:08 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Thu, 16 Jan 2014, Olof Johansson wrote:
> >
> >> "for SDIO slots" is somewhat misleading; nearly all controllers only
> >> do one slot/device per controller. The designware controller can do
> >> multiple slots, and that adds a bit of driver and binding complexity
> >> for something that seemingly not a single vendor has actually
> >> implemented.
> >
> > The Marvell 8688, just to name one, does both WIFI and BlueTooth over
> > the same SDIO controller using separate functions/slots.
> 
> But that is logical functions within a chip, not multiple discrete
> chips (i.e. slots) with their own reset, regulators, etc.

OK.  If that's the definition of a slot in this context then I agree.


Nicolas

How to support SDIO wifi/bt in DT

[Olof Johansson]

On Fri, Jan 17, 2014 at 8:58 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Fri, 17 Jan 2014, Rob Herring wrote:
>
>> On Thu, Jan 16, 2014 at 9:08 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> > On Thu, 16 Jan 2014, Olof Johansson wrote:
>> >
>> >> "for SDIO slots" is somewhat misleading; nearly all controllers only
>> >> do one slot/device per controller. The designware controller can do
>> >> multiple slots, and that adds a bit of driver and binding complexity
>> >> for something that seemingly not a single vendor has actually
>> >> implemented.
>> >
>> > The Marvell 8688, just to name one, does both WIFI and BlueTooth over
>> > the same SDIO controller using separate functions/slots.
>>
>> But that is logical functions within a chip, not multiple discrete
>> chips (i.e. slots) with their own reset, regulators, etc.
>
> OK.  If that's the definition of a slot in this context then I agree.

Correct -- the device that I've been doing the work in is actually the
combined wifi/bluetooth module on the Samsung Chromebook, which is a
Marvell 8797. It has multiple functions which still work well.

The "multi-slot" concept I was talking about was one host controller
for several physical slots. Seems like at91 implements _and_ uses this
but nobody else. However, it seems that they allocate one mmc host per
slot, so the same model still works.


-Olof

How to support SDIO wifi/bt in DT

[Arnd Bergmann]

On Sunday 19 January 2014, Olof Johansson wrote:
> The "multi-slot" concept I was talking about was one host controller
> for several physical slots. Seems like at91 implements and uses this
> but nobody else. However, it seems that they allocate one mmc host per
> slot, so the same model still works.
> 

IIRC dw-mci also has multiple slots, and it's a common host controller
in a number of SoCs. I don't know how many of them actually support
multiple slots rather than a simplified single-slot version of
that controller.

	Arnd

How to support SDIO wifi/bt in DT

[Olof Johansson]

On Sun, Jan 19, 2014 at 09:28:53PM +0100, Arnd Bergmann wrote:
> On Sunday 19 January 2014, Olof Johansson wrote:
> > The "multi-slot" concept I was talking about was one host controller
> > for several physical slots. Seems like at91 implements and uses this
> > but nobody else. However, it seems that they allocate one mmc host per
> > slot, so the same model still works.
> > 
> 
> IIRC dw-mci also has multiple slots, and it's a common host controller
> in a number of SoCs. I don't know how many of them actually support
> multiple slots rather than a simplified single-slot version of
> that controller.

Right, that's the main one i had in mind -- the binding, and the driver, allow
for multiple slots but we've been searching high and low for an actual SoC that
implements that, and none seem to do it. So the additional overhead is just
wasted, and there's been talk of bringing the binding more in line with
a single-slot driver instead. It makes a lot of sense to do.


-Olof

How to support SDIO wifi/bt in DT

[Alexandre Belloni]

On Sun, Jan 19, 2014 at 11:29:55AM -0800, Olof Johansson wrote :
> The "multi-slot" concept I was talking about was one host controller
> for several physical slots. Seems like at91 implements _and_ uses this
> but nobody else. However, it seems that they allocate one mmc host per
> slot, so the same model still works.
> 

I think we need to be extra careful about the DT bindings then because
adding a property in a slot is requiring handling that in the at91
driver whereas adding a common property for the various mmc hosts can be
done in the core code.

>From what I remember, it would be really good to put the DT parsing for
the slots in the core code but I only had a really quick look at that.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

How to support SDIO wifi/bt in DT

[Olof Johansson]

On Mon, Jan 20, 2014 at 12:09:25AM +0100, Alexandre Belloni wrote:
> On Sun, Jan 19, 2014 at 11:29:55AM -0800, Olof Johansson wrote :
> > The "multi-slot" concept I was talking about was one host controller
> > for several physical slots. Seems like at91 implements _and_ uses this
> > but nobody else. However, it seems that they allocate one mmc host per
> > slot, so the same model still works.
> > 
> 
> I think we need to be extra careful about the DT bindings then because
> adding a property in a slot is requiring handling that in the at91
> driver whereas adding a common property for the various mmc hosts can be
> done in the core code.
> 
> From what I remember, it would be really good to put the DT parsing for
> the slots in the core code but I only had a really quick look at that.

The patches I have here do it all in the core per host with common
bindings. I hope to post them tonight. They should fit the at91 model
just fine as well, since they do each slot as a mmc_host, not as a separate
slot with a shared host controller.

(Some drivers don't seem to call mmc_of_parse(), which they will need to do to
take advantage of the common implementation. But that can be addressed driver
by driver as someone has a chance to test it).


-Olof

How to support SDIO wifi/bt in DT

[Olof Johansson]

On Sun, Jan 19, 2014 at 3:30 PM, Olof Johansson <olof@lixom.net> wrote:
> On Mon, Jan 20, 2014 at 12:09:25AM +0100, Alexandre Belloni wrote:
>> On Sun, Jan 19, 2014 at 11:29:55AM -0800, Olof Johansson wrote :
>> > The "multi-slot" concept I was talking about was one host controller
>> > for several physical slots. Seems like at91 implements _and_ uses this
>> > but nobody else. However, it seems that they allocate one mmc host per
>> > slot, so the same model still works.
>> >
>>
>> I think we need to be extra careful about the DT bindings then because
>> adding a property in a slot is requiring handling that in the at91
>> driver whereas adding a common property for the various mmc hosts can be
>> done in the core code.
>>
>> From what I remember, it would be really good to put the DT parsing for
>> the slots in the core code but I only had a really quick look at that.
>
> The patches I have here do it all in the core per host with common
> bindings. I hope to post them tonight.

Done. See RFC series at:

http://marc.info/?l=linux-mmc&m=139019015915702&w=2


-Olof

How to support SDIO wifi/bt in DT

[Alexandre Belloni]

On Thu, Jan 16, 2014 at 09:15:17AM -0800, Olof Johansson wrote :
> "for SDIO slots" is somewhat misleading; nearly all controllers only
> do one slot/device per controller. The designware controller can do
> multiple slots, and that adds a bit of driver and binding complexity
> for something that seemingly not a single vendor has actually
> implemented.
> 
> So we can likely assume to keep these reset/power/clock lines per host
> controller, no need to add a slot construct.
> 

Actually, the atmel chips have two slots per controller so it would
probably be better to think about that now.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140117/7e539c1a/attachment.sig>

How to support SDIO wifi/bt in DT

[Nicolas Ferre]

On 17/01/2014 10:02, Alexandre Belloni :
> On Thu, Jan 16, 2014 at 09:15:17AM -0800, Olof Johansson wrote :
>> "for SDIO slots" is somewhat misleading; nearly all controllers only
>> do one slot/device per controller. The designware controller can do
>> multiple slots, and that adds a bit of driver and binding complexity
>> for something that seemingly not a single vendor has actually
>> implemented.
>>
>> So we can likely assume to keep these reset/power/clock lines per host
>> controller, no need to add a slot construct.
>>
> 
> Actually, the atmel chips have two slots per controller so it would
> probably be better to think about that now.

Moreover, we have DT description for this.
Cf. Documentation/devicetree/bindings/mmc/atmel-hsmci.txt

Best regards,
-- 
Nicolas Ferre

How to support SDIO wifi/bt in DT

[Alexandre Belloni]

On Thu, Jan 16, 2014 at 01:36:49PM +0000, Russell King - ARM Linux wrote :
> Okay, I'm hitting something of a dead end with trying to work out how to
> support this in DT.
> 
> The Wifi/BT (bcrmfmac) device has multiple connections to the host device
> - it has a SDIO connection, a UART connection, and an audio connection.
> In addition, a series of GPIOs are wired to control this device:
> 
> - Reset for bluetooth plus two additional GPIOs (unused I think)
> - Reset for Wifi plus two additional GPIOs (again, I think unused)
> - GPIO to control regulator supplying power to the Wifi/BT chip
> - GPIO to control regulator supplying power to the oscillator for
>   the Wifi/BT chip.
> 
> The Wifi/BT chip can only be detected via probing the SDIO connection, and
> only when the device has been powered up and released from reset - so we
> have to power up and reset the bcrm device before we probe via the SDIO
> bus.
> 
> While it's possible to attach the power supply for the Wifi/BT chip to the
> vmmc-supply property of the host, it's not possible to do that with the
> oscillator supply.  Neither is there any provision for manipulating the
> GPIOs to deal with the resets.
> 
> I can't find any examples of anything similar in our existing set of DT
> files, so I suspect either this is a device which no one supports on any
> DT platform, or there's some clever way to handle this.
> 
> How do other people support this in DT?  Do they hack up some platform
> specific code (which isn't nice)?  What other solutions are there to get
> around this problem?  How does this kind of thing get represented in DT?
> 
> (Don't suggest adding DT support to the bcrmfmac driver - this is a
> chicken-and-egg problem.  The driver isn't being probed at the moment
> because the device is powered down and/or held in reset, so is
> undetectable.  The kernel needs to power it up and release the reset
> so it becomes detectable.)

I hit exactly the same issue trying to support a TiWi chip on SDIO. On
my side, I used vmmc-supply to drive the reset GPIO with a fixed
regulator. The other thing needed was the clock. That one, I put it in
the board file. I guess we need a way to describe children of the SDIO
host and the host driver would be responsible to manage power supplies,
resets and clocks...

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

How to support SDIO wifi/bt in DT

[Russell King - ARM Linux]

On Thu, Jan 16, 2014 at 03:08:58PM +0100, Alexandre Belloni wrote:
> I hit exactly the same issue trying to support a TiWi chip on SDIO. On
> my side, I used vmmc-supply to drive the reset GPIO with a fixed
> regulator. The other thing needed was the clock. That one, I put it in
> the board file. I guess we need a way to describe children of the SDIO
> host and the host driver would be responsible to manage power supplies,
> resets and clocks...

I thought about doing that, but the issue I run into is that I need
four regulators in total, and some way to combine them so that I get
the right sequence.

The sequence currently being done in the board in the FSL v3.0.35
kernel is:

- drive both reset gpio low
- power up wifi/bt via gpio
- power up oscillator via gpio
- wait 2ms
- drive both reset gpios high
- wait 2ms
- detect sdio device

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".