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: Stephen Warren <swarren@xxxxxxxxxxxxx>
- Date: Fri, 15 Jun 2012 09:49:10 -0600
- Cc: 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>, Rakesh Kumar <krakesh@xxxxxxxxxx>, "linux-arm-kernel@xxxxxxxxxxxxxxxxxxx" <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>
- In-reply-to: <6B4D417B830BC44B8026029FD256F7F1C377BFFE8D@HKMAIL01.nvidia.com>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
On 06/15/2012 12:09 AM, Wei Ni wrote:
> On Thu, Jun 14, 2012 at 23:54:22, Stephen Warren wrote:
>>>>> The core of the issue is that:
>>>
>>>>> * Tegra30 support is via device tree. * We have an SDIO bus, and
>>>>> the WiFi device attached to that bus is enumerable. * Since the
>>>>> WiFi device is enumerable, no node exists in the DT to represent
>>>>> it. * However, the driver for the WiFi device needs certain
>>>>> information, such as the reset GPIO ID and perhaps power GPIO.
>>>
>>>> PCI devices are also enumerable and yet they can be matched up with
>>>> nodes in the device tree. Perhaps something similar could be added
>>>> for the SDIO bus?
>>>
>>> This seems to make the most sense - pushing this through the
>>> regulator API is just a bodge.
>>
>> Yes, that seems reasonable.
>>
>> Presumably the power GPIO should be a fixed regulator though, since it
>> is a power control not just a plain old GPIO? That said, the current driver apparently deals with this as a GPIO already.
>>
>> The reset GPIO can separately/directly controlled by the WiFi driver though.
>
> 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".
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.
--
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]