On Fri, Jan 17, 2014 at 5:39 PM, Alexandre Belloni
[off-list ref] wrote:

On Thu, Jan 16, 2014 at 12:00:47PM -0800, Olof Johansson wrote :

quoted

On Thu, Jan 16, 2014 at 11:58 AM, Russell King - ARM Linux
[off-list ref] wrote:

quoted

On Thu, Jan 16, 2014 at 09:15:17AM -0800, Olof Johansson wrote:

quoted

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