From: Stephen Warren <swarren@wwwdotorg.org>
To: Wei Ni <wni@nvidia.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>,
"'frankyl@broadcom.com'" <frankyl@broadcom.com>,
Thierry Reding <thierry.reding@avionic-design.de>,
Mursalin Akon <makon@nvidia.com>,
"'linux-mmc@vger.kernel.org'" <linux-mmc@vger.kernel.org>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"'linux-wireless@vger.kernel.org'"
<linux-wireless@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Rakesh Kumar <krakesh@nvidia.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: Where to power on the wifi device before loading the driver.
Date: Fri, 15 Jun 2012 09:49:10 -0600 [thread overview]
Message-ID: <4FDB5976.20809@wwwdotorg.org> (raw)
In-Reply-To: <6B4D417B830BC44B8026029FD256F7F1C377BFFE8D@HKMAIL01.nvidia.com>
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.
next prev parent reply other threads:[~2012-06-15 15:49 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-13 10:40 Where to power on the wifi device before loading the driver Wei Ni
[not found] ` <6B4D417B830BC44B8026029FD256F7F1C377BFFE88-Q4EWCATADntDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2012-06-13 17:33 ` Franky Lin
2012-06-14 4:17 ` Wei Ni
2012-06-14 16:45 ` Franky Lin
2012-06-13 21:17 ` Stephen Warren
2012-06-14 6:31 ` Thierry Reding
[not found] ` <20120614063120.GA20167-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-06-14 12:12 ` Mark Brown
[not found] ` <20120614121234.GC3913-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-06-14 15:54 ` Stephen Warren
2012-06-15 6:09 ` Wei Ni
2012-06-15 15:49 ` Stephen Warren [this message]
[not found] ` <4FDB5976.20809-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-18 6:20 ` Wei Ni
2012-06-18 7:40 ` Rakesh Kumar
[not found] ` <96C9D994977DD0439FB6D3FE3B13DD907DE14CB4DF-kdsAE/FnitNDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2012-06-18 8:03 ` Laxman Dewangan
[not found] ` <96C9D994977DD0439FB6D3FE3B13DD907DE14CB4E8-kdsAE/FnitNDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2012-06-18 15:01 ` Stephen Warren
2012-06-19 9:13 ` Wei Ni
[not found] ` <6B4D417B830BC44B8026029FD256F7F1C6EE2DD61F-Q4EWCATADntDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2012-06-19 1:23 ` Philip Rakity
2012-06-19 4:25 ` Wei Ni
[not found] ` <6B4D417B830BC44B8026029FD256F7F1C6EE2DD622-Q4EWCATADntDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2012-06-19 9:17 ` Mark Brown
[not found] ` <20120619091719.GZ3974-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-06-19 9:44 ` Wei Ni
[not found] ` <6B4D417B830BC44B8026029FD256F7F1C6EE2DD626-Q4EWCATADntDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2012-06-20 0:01 ` Stephen Warren
[not found] ` <4FE112F2.7000506-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-20 10:47 ` Mark Brown
2012-06-20 11:28 ` Wei Ni
[not found] ` <6B4D417B830BC44B8026029FD256F7F1C6EE2DD629-Q4EWCATADntDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2012-06-20 16:51 ` Stephen Warren
2012-06-26 8:56 ` Dong Aisheng
[not found] ` <20120626085605.GA6047-Fb7DQEYuewWctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2012-06-26 16:53 ` Stephen Warren
[not found] ` <4FE9E907.6050803-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-26 21:26 ` Rob Herring
[not found] ` <4FEA28EC.2080906-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-06-26 22:38 ` Stephen Warren
2012-06-27 2:19 ` Dong Aisheng
2012-06-27 2:16 ` Dong Aisheng
2012-06-15 16:24 ` Franky Lin
2012-06-18 6:00 ` Wei Ni
2012-06-14 11:27 ` Wei Ni
[not found] ` <6B4D417B830BC44B8026029FD256F7F1C377BFFE8A-Q4EWCATADntDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2012-06-14 11:44 ` Wei Ni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FDB5976.20809@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=frankyl@broadcom.com \
--cc=krakesh@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=makon@nvidia.com \
--cc=thierry.reding@avionic-design.de \
--cc=wni@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).