RE: Where to power on the wifi device before loading the driver. |
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: RE: Where to power on the wifi device before loading the driver.
- From: Wei Ni <wni@xxxxxxxxxx>
- Date: Tue, 19 Jun 2012 17:13:47 +0800
- Accept-language: en-US
- Acceptlanguage: en-US
- Cc: Rakesh Kumar <krakesh@xxxxxxxxxx>, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>, "'frankyl@xxxxxxxxxxxx'" <frankyl@xxxxxxxxxxxx>, Thierry Reding <thierry.reding@xxxxxxxxxxxxxxxxx>, Mursalin Akon <makon@xxxxxxxxxx>, "'linux-mmc@xxxxxxxxxxxxxxx'" <linux-mmc@xxxxxxxxxxxxxxx>, "devicetree-discuss@xxxxxxxxxxxxxxxx" <devicetree-discuss@xxxxxxxxxxxxxxxx>, "'linux-wireless@xxxxxxxxxxxxxxx'" <linux-wireless@xxxxxxxxxxxxxxx>, "linux-tegra@xxxxxxxxxxxxxxx" <linux-tegra@xxxxxxxxxxxxxxx>, "linux-arm-kernel@xxxxxxxxxxxxxxxxxxx" <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>
- In-reply-to: <4FDF42D9.2050305@wwwdotorg.org>
- Thread-index: Ac1NY0wG8X/BUT4BSvGRFgy2+2jhMgAl84Yw
- Thread-topic: Where to power on the wifi device before loading the driver.
On Mon, Jun 18, 2012 at 23:01:45, Stephen Warren wrote:
>On 06/18/2012 02:03 AM, Laxman Dewangan wrote:
>> Rakesh Kumar wrote at Monday, June 18, 2012 1:11 PM:
>> > Stephen Warren wrote:
>> >> 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.
>> >
>> > Tegra uses two GPIO (WF_EN and WF_RST) to power on and reset
>> > bcm4329 card. In case of bcm4329, these two lines are shorted.
>> > Tegra does not control VBAT3V3_IN_WF, VDDIO_WF, or other power
>> > supply to the WiFi card based on these GPIO. Uses of these GPIO are
>> > internal to WiFi HW. It is reasonable to represent as a GPU rather
>> > than regulator.
>>
>> If it is for power then it has to go via regulator. It does not make
>> sense to directly control the gpio inside the wifi driver.
>
>As far as the board goes, WF_EN is just a GPIO signal to the WiFi card;
>it doesn't gate power to the card. If it gates power inside the card,
>that's an internal implementation detail of the card, and something I'd
>be fine with the driver knowing directly, and hence I'm OK with representing
>this as a GPIO rather than a regulator - that's what it is externally to the WiFi device.
Because these gpio is just for wifi device, could we use the rfkill-gpio driver for this isse? We just need to add DT support in rfkill-gpio driver and add a device node in the DT. And the user also can use the rfkill interface to control the wifi device.
>
>(BTW everyone, many of the emails in this thread are awfully formatted
>- top-posted and not word- wrapped. It's very hard to read them... I tried to reformat everything and fix it in this email)
--
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
[ARM Kernel]
[Linux USB Devel]
[Video for Linux]
[Linux Audio Users]
[Photo]
[Yosemite News]
[Yosemite Photos]
[Free Online Dating]
[Linux Kernel]
[Linux SCSI]
[XFree86]