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

[Wei Ni]

On Tue, Jun 19, 2012 at 09:23:35, Philip Rakity wrote:
>Why can't you use the regulator notify to get called back on power or 
>voltage change options to plumb in the manipulation of the gpio. I can 
>imagine you might need to add a notify call in core.c if you need to 
>assert the gpio before power is applied

Yes, we can use the regulator notify, but the Tegra30 support is via device tree, I think there have no special board file to run the call back.

>
>
>________________________________________
>From: linux-mmc-owner at vger.kernel.org [linux-mmc-owner at vger.kernel.org] 
>On Behalf Of Wei Ni [wni at nvidia.com]
>Sent: Sunday, June 17, 2012 11:20 PM
>To: 'Stephen Warren'; Rakesh Kumar
>Cc: Mark Brown; 'frankyl at broadcom.com'; Thierry Reding; Mursalin Akon; 
>'linux-mmc at vger.kernel.org'; devicetree-discuss at lists.ozlabs.org; 
>'linux-wireless at vger.kernel.org'; linux-tegra at vger.kernel.org; 
>linux-arm-kernel at lists.infradead.org
>Subject: RE: Where to power on the wifi device before loading the driver.
>
>On Fri, Jun 15, 2012 at 23:49:10, Stephen Warren wrote:
>>> I talked with Franky, this power sequence is generally for 4329, so 
>>> it mean this sequence can be put into the wifi driver.
>>> We can use the virtual platform device both for OOB and non OOB.
>>> I will send out patches later.
>>
>>Can you please expand on what a "virtual platform device" is; device 
>>tree typically represents real
>hardware rather than anything "virtual".
>
>The "virtual platform device" is created before the real wifi device, 
>so that it can pass the gpios to the driver, and power up the device before calling sdio_register_driver.
>But as Franky said, this power sequence is only generally for 4329, not 
>for the USB dongle chips. So it's not a good idea to add this "power up" in brcmfmac.
>
>>
>>Now if this means adding a child node under the SDIO controller to 
>>represent the attached device, and
>storing any settings required by that device in that child node, that's 
>probably a reasonable basic approach.
>>
>>BTW, which GPIO is the power GPIO; is it WF_EN on the schematic? That 
>>seems reasonable to represent
>as a GPIO rather than a regulator since it connects directly into the 
>WiFi device as a GPIO, and its use within the WiFi device can indeed be 
>governed purely internally to the WiFi driver/HW. However, if this is some GPIO that controls the power to e.g.
>>VBAT3V3_IN_WF, VDDIO_WF, or other power supply to the WiFi card, then 
>>it'd be better represented as a
>regulator, since the control point is outside the WiFi device.
>
>I think Rakesh may can answer this.
>
>Wei.
>---
>nvpublic