RE: Where to power on the wifi device before loading the driver.

On Thu, Jun 14, 2012 at 19:27:50, Wei Ni wrote:

On Thu, Jun 14, 2012 at 05:17:06, Stephen Warren wrote:

quoted

On 06/13/2012 04:40 AM, Wei Ni wrote:

quoted

Hi, all
I'm working on the tegra30 wifi upstream issue.

The tegra30 board (Cardhu) use Broadcom 4329 as wifi device, and use brcmfmac as the wifi driver.

In the brcmfmac init routine, it call sdio_register_driver() to 
register driver, if the wifi device

is powered on, then the mmc driver will enumerate it, and call the probe callback routine.

quoted

quoted

On the Cardhu, the wifi's power is controlled by two gpios 
(power-gpio and reset-gpio), the default state is power-off. So we 
need to power on it before

calling sdio_register_driver(), if not, the mmc driver can't enumerate 
it, and will not call the probe routine.

quoted

quoted

This power on sequence is:
set power-gpio to 1 ;
mdelay(100) ;
set reset-gpio to 1 ;
mdelay(200);

My question is where to power on the wifi. We may have three places to power on it:
1. power on it in the brcmfmac driver before calling 
sdio_register_driver(). But I think this power sequence is special 
for tegra30 cardhu, it's not

good to add it in the generic wifi driver, because different board may 
use the different way to power on the wifi.

quoted

quoted

2. power on it in the mmc driver. In our tegra SD driver, it has 
power-gpios property, which allow the slot to be powered. But this 
power is for mmc slot, could we

add this wifi power sequence in the tegra SD driver?

quoted

quoted

3. hard-coded into DT. Set these gpios in the DT, something like 
pinmux settings, but in this way,

it's not good to put the mdelay() value in the DT.

quoted

quoted

I have no good idea for it, does anyone has suggestion?

The core of the issue is that:

* Tegra30 support is via device tree.
* We have an SDIO bus, and the WiFi device attached to that bus is enumerable.
* Since the WiFi device is enumerable, no node exists in the DT to represent it.
* However, the driver for the WiFi device needs certain information, 
such as the reset GPIO ID and perhaps power GPIO.

For the power GPIO, it seems reasonable to either use the existing 
Tegra SD controller's power-gpios DT property, or replace that 
property with a real regulator binding. The SD driver would then control this.
Still, that approach would mean the WiFi driver wouldn't be able to 
control power to the device

directly, which might not be a good thing.

quoted

However, I'm not sure that the reset GPIO is also something that 
should be controlled by the SD card driver; it seems like it's much 
more closely related to the WiFi

device/driver.

quoted

I wonder if the power and reset GPIO shouldn't be represented as a 
combined custom regulator type, which knows how to sequence multiple GPIOs.

Perhaps SDIO "client" devices also need a way to communicate with 
their "host port" to obtain services such as power and reset control?

This is all very similar to the WiFi rfkill discussion we have re: the 
Toshiba AC100 a little while back, although that was USB rather than SDIO.

In the rfkill-gpio, it already have the reset-gpio and shutdown-gpio.
I test it, add a device node in the DT to pass the gpio properties.
It will use these gpios to power up/off , but its default power sequence is different with the 4329.
It block==0, it mean power up, it will set reset-gpio first, then set power-gpio next.
I think it should set power-gpio first, is it right?

I test with the rfkill-gpio's default power sequence just now, it also can power up the device.
It seems we can use this rfkill-gpio driver.

---
nvpublic