From: swarren@wwwdotorg•org (Stephen Warren)
To: linux-arm-kernel@lists•infradead.org
Subject: Where to power on the wifi device before loading the driver.
Date: Tue, 26 Jun 2012 16:38:32 -0600 [thread overview]
Message-ID: <4FEA39E8.6090502@wwwdotorg.org> (raw)
In-Reply-To: <4FEA28EC.2080906@gmail.com>
On 06/26/2012 03:26 PM, Rob Herring wrote:
> On 06/26/2012 11:53 AM, Stephen Warren wrote:
>> (I'm adding everyone on thread "ARM: imx6q: add config-on-boot gpios" to
>> the CC of this similar thread. Sorry if you think that's spam.)
>>
>> On 06/26/2012 02:56 AM, Dong Aisheng wrote:
>>> On Tue, Jun 19, 2012 at 06:01:54PM -0600, Stephen Warren wrote:
>> ...
>>>> I think what we need is some way of matching a DT node to a device even
>>>> when that device was instantiated through some probing mechanism such as
>>>> SDIO or USB (and I've heard hints that one can already do this for PCI;
>>>> I should investigate).
>>>>
>>>> So, we start off with the plain SDHCI controller node:
>>>>
>>>> sdhci at 78000000 {
>>>> compatible = "nvidia,tegra30-sdhci", "nvidia,tegra20-sdhci";
>>>> reg = <0x78000000 0x200>;
>>>> interrupts = <0 14 0x04>;
>>>> };
>>>>
>>>> Then, we add a child node to represent the device that's attached:
>>>>
>>>> sdhci at 78000000 {
>>>> compatible = "nvidia,tegra30-sdhci", "nvidia,tegra20-sdhci";
>>>> reg = <0x78000000 0x200>;
>>>> interrupts = <0 14 0x04>;
>>>>
>>>> sdio-device {
>>>> reset-gpios = <...>;
>>>> enable-gpios = <...>;
>>>> };
>>>> };
>>>>
>>>> When the SDHCI controller/core instantiates the child device it finds on
>>>> the HW bus, it initializes that struct device's of_node with a pointer
>>>> to the sdio-device node above. From there, the child device can get DT
>>>> properties such as GPIOs in the usual way.
>>>>
>>>> However, there are still some issues that need thought here; what if (as
>>>> is I believe the case on Cardhu) we can in fact plug in multiple
>>>> different types of device into the socket? Might we end up with
>>>> something like:
>>>>
>>>> sdhci at 78000000 {
>>>> compatible = "nvidia,tegra30-sdhci", "nvidia,tegra20-sdhci";
>>>> reg = <0x78000000 0x200>;
>>>> interrupts = <0 14 0x04>;
>>>>
>>>> sdio-device-option at 0 {
>>>> compatible = "broadcom,bcm4239";
>>>> reset-gpios = <...>;
>>>> enable-gpios = <...>;
>>>> };
>>>>
>>>> sdio-device-option at 1 {
>>>> compatible = "broadcom,bcm4330";
>>>> reset-gpios = <...>;
>>>> enable-gpios = <...>;
>>>> };
>>>> };
>>>>
>>>> and match on compatible value?
>>>>
>>> I like this idea.
>>> We may extend the sdio_device_id to contain a compatible string,
>>> then sdio core is responsible to pass the corresponding device node to the
>>> sdio function driver once a match device found, this is sdio function independent.
>>> The sdio function driver then are responsible to parse the device node to
>>> fetch the needed information like reset-gpios and enable-gpios to do correct
>>> initialization sequence.
>>>
>>> However, one known question for this model is that some WiFi may need reset the chip
>>> via gpio first before being able to be enumerated.
>>
>> Yes, that's exactly the issue that makes the above binding incorrect.
>>
>> In another thread on a very similar topic, I proposed a binding that
>> would address this issue:
>>
>> http://www.spinics.net/lists/linux-usb/msg66013.html
>>
>>> sdhci at 78000000 {
>>> compatible = "nvidia,tegra30-sdhci", "nvidia,tegra20-sdhci";
>>> reg = <0x78000000 0x200>;
>>> interrupts = <0 14 0x04>;
>>>
>>> sdio-device {
>>> reset-gpios = <...>;
>>> enable-gpios = <...>;
>>> };
>
> These are really no different than CD and WP on gpio lines. So I don't
> think a child node is even necessary. They are really properties of the
> host controller as you have to know how to handle them before enumeration.
>
> One question is do the gpios have strict timing or ordering
> requirements. If so then that would be difficult to describe generically.
There certainly are some timing requirements specified in our downstream
kernels, although as I mentioned earlier in the thread, I think the code
is a bit confused since it controls two GPIOs but only one is hooked up,
at least on the one plugin WiFi card I looked at. Even with just one
GPIO, there's still potentially a delay needed between GPIO assertion
and device enumeration.
>>> };
>>
>>> ehci {
>>> /* The following node is dynamically detected, although the hub
>>> * IC is physically soldered onto the board
>>> */
>>> hub {
>>> hub { /* also dynamic */
>>> port at 2 {
>>> child-supply = <®ulator>;
>>> reset-gpios = <&gpio 0 0>;
>>> };
>>> };
>>> };
>>> }
>>
>
> Considering the same enumeration ordering requirement as above and that
> this is probably limited to a single hub/device on the root hub, I think
> the simple solution of just adding the gpio's to the ehci node and
> handling in the ehci driver is sufficient.
>
>> Presumably something similar could be set up with platform data.
>>
>> Basically, the SD controller or USB host/hub node contains a child that
>> represents the socket/port/... that needs some services provided to it
>> (power, reset de-asserted, even clocks). The services provided by that
>> node are set up before enumeration, so that the device will respond to
>> enumeration. Hopefully, the DT representation of this socket/port/..
>> could be shared across arbitrary types of controller (so both SD and
>> USB) and the driver the "implements" that node would be common code that
>> SD and USB call into, rather than having them both re-implement it from
>> scratch.
>
> While I think this can be handled generically with SD and USB drivers,
> I'm not so sure there would be benefit across them. It is just getting a
> gpio and toggling it. But really that's a detail that doesn't matter
> until we're closer to an implementation...
Well, power-gpios should really be a regulator not a GPIO if it really
represents power (although on the one WiFi board I looked at, it was
really an enable/reset signal not a power signal), and we also need to
enable a clock out to the card too, so it gets a bit more complex than
just a couple GPIOs...
next prev parent reply other threads:[~2012-06-26 22:38 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
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
2012-06-14 12:12 ` Mark Brown
2012-06-14 15:54 ` Stephen Warren
2012-06-15 6:09 ` Wei Ni
2012-06-15 15:49 ` Stephen Warren
2012-06-18 6:20 ` Wei Ni
2012-06-18 7:40 ` Rakesh Kumar
2012-06-18 8:03 ` Laxman Dewangan
2012-06-18 15:01 ` Stephen Warren
2012-06-19 9:13 ` Wei Ni
2012-06-19 1:23 ` Philip Rakity
2012-06-19 4:25 ` Wei Ni
2012-06-19 9:17 ` Mark Brown
2012-06-19 9:44 ` Wei Ni
2012-06-20 0:01 ` Stephen Warren
2012-06-20 10:47 ` Mark Brown
2012-06-20 11:28 ` Wei Ni
2012-06-20 16:51 ` Stephen Warren
2012-06-26 8:56 ` Dong Aisheng
2012-06-26 16:53 ` Stephen Warren
2012-06-26 21:26 ` Rob Herring
2012-06-26 22:38 ` Stephen Warren [this message]
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
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=4FEA39E8.6090502@wwwdotorg.org \
--to=swarren@wwwdotorg$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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