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@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:

quoted

quoted

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.

quoted

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.

quoted

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.

quoted

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