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

Wei Ni wni at nvidia.com
Tue Jun 19 05:13:47 EDT 2012


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)





More information about the linux-arm-kernel mailing list