Where to power on the wifi device before loading the driver.
wni at nvidia.com
Tue Jun 19 00:25:58 EDT 2012
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.
More information about the linux-arm-kernel