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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx [linux-mmc-owner@xxxxxxxxxxxxxxx] 
>On Behalf Of Wei Ni [wni@xxxxxxxxxx]
>Sent: Sunday, June 17, 2012 11:20 PM
>To: 'Stephen Warren'; Rakesh Kumar
>Cc: Mark Brown; 'frankyl@xxxxxxxxxxxx'; Thierry Reding; Mursalin Akon; 
>'linux-mmc@xxxxxxxxxxxxxxx'; devicetree-discuss@xxxxxxxxxxxxxxxx; 
>'linux-wireless@xxxxxxxxxxxxxxx'; linux-tegra@xxxxxxxxxxxxxxx; 
>linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
>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

--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux