All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Dong Aisheng <aisheng.dong-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: USB list <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"alexander.shishkin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org"
	<alexander.shishkin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	b29397-KZfg59tc24xl57MIdRCFDg@public.gmane.org,
	Mursalin Akon <makon-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	r64343-KZfg59tc24xl57MIdRCFDg@public.gmane.org,
	Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Alan Stern
	<stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>,
	"'linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org'"
	<linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	'Philip Rakity' <prakity-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
	Li Frank-B20596 <B20596-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	"devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
	<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
	Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
	"'frankyl-dY08KVG/lbpWk0Htik3J/w@public.gmane.org'"
	<frankyl-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
	"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Rakesh Kumar <krakesh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	ARM kernel mailing list
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	r65037-KZfg59tc24xl57MIdRCFDg@public.gmane.org,
	Wei Ni <wni-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	Estevam Fabio-R49496
	<r49496-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	'Mark Brown'
	<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>'linu
Subject: Re: Where to power on the wifi device before loading the driver.
Date: Tue, 26 Jun 2012 10:53:27 -0600	[thread overview]
Message-ID: <4FE9E907.6050803@wwwdotorg.org> (raw)
In-Reply-To: <20120626085605.GA6047-Fb7DQEYuewWctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>

(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@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@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@78000000 {
>> 	compatible = "nvidia,tegra30-sdhci", "nvidia,tegra20-sdhci";
>> 	reg = <0x78000000 0x200>;
>> 	interrupts = <0 14 0x04>;
>>
>> 	sdio-device-option@0 {
>> 		compatible = "broadcom,bcm4239";
>> 		reset-gpios = <...>;
>> 		enable-gpios = <...>;
>> 	};
>>
>> 	sdio-device-option@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@78000000 {
> 	compatible = "nvidia,tegra30-sdhci", "nvidia,tegra20-sdhci";
> 	reg = <0x78000000 0x200>;
> 	interrupts = <0 14 0x04>;
>
> 	sdio-device {
> 		reset-gpios = <...>;
> 		enable-gpios = <...>;
> 	};
> };

> ehci {
>     /* The following node is dynamically detected, although the hub
>      * IC is physically soldered onto the board
>      */
>     hub {
>         hub { /* also dynamic */
>             port@2 {
>                 child-supply = <&regulator>;
>                 reset-gpios = <&gpio 0 0>;
>             };
>         };
>     };
> }

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.

WARNING: multiple messages have this Message-ID (diff)
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 10:53:27 -0600	[thread overview]
Message-ID: <4FE9E907.6050803@wwwdotorg.org> (raw)
In-Reply-To: <20120626085605.GA6047@shlinux2.ap.freescale.net>

(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 = <...>;
> 	};
> };

> 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 = <&regulator>;
>                 reset-gpios = <&gpio 0 0>;
>             };
>         };
>     };
> }

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.

  parent reply	other threads:[~2012-06-26 16:53 UTC|newest]

Thread overview: 83+ 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 10:40 ` Wei Ni
2012-06-13 10:40 ` Wei Ni
2012-06-13 17:33 ` Franky Lin
2012-06-13 17:33   ` Franky Lin
2012-06-13 17:33   ` Franky Lin
2012-06-14  4:17   ` Wei Ni
2012-06-14  4:17     ` Wei Ni
2012-06-14 16:45     ` Franky Lin
2012-06-14 16:45       ` Franky Lin
2012-06-13 21:17 ` Stephen Warren
2012-06-13 21:17   ` Stephen Warren
2012-06-14  6:31   ` Thierry Reding
2012-06-14  6:31     ` Thierry Reding
2012-06-14 12:12     ` Mark Brown
2012-06-14 12:12       ` Mark Brown
2012-06-14 12:12       ` Mark Brown
2012-06-14 15:54       ` Stephen Warren
2012-06-14 15:54         ` Stephen Warren
2012-06-14 15:54         ` Stephen Warren
2012-06-15  6:09         ` Wei Ni
2012-06-15  6:09           ` Wei Ni
2012-06-15 15:49           ` Stephen Warren
2012-06-15 15:49             ` Stephen Warren
2012-06-18  6:20             ` Wei Ni
2012-06-18  6:20               ` Wei Ni
2012-06-18  6:20               ` Wei Ni
2012-06-18  7:40               ` Rakesh Kumar
2012-06-18  7:40                 ` Rakesh Kumar
2012-06-18  8:03                 ` Laxman Dewangan
2012-06-18  8:03                   ` Laxman Dewangan
2012-06-18  8:03                   ` Laxman Dewangan
2012-06-18 15:01                   ` Stephen Warren
2012-06-18 15:01                     ` Stephen Warren
2012-06-18 15:01                     ` Stephen Warren
2012-06-19  9:13                     ` Wei Ni
2012-06-19  9:13                       ` Wei Ni
2012-06-19  1:23               ` Philip Rakity
2012-06-19  1:23                 ` Philip Rakity
2012-06-19  1:23                 ` Philip Rakity
2012-06-19  4:25                 ` Wei Ni
2012-06-19  4:25                   ` Wei Ni
2012-06-19  9:17                   ` Mark Brown
2012-06-19  9:17                     ` Mark Brown
2012-06-19  9:17                     ` Mark Brown
2012-06-19  9:44                     ` Wei Ni
2012-06-19  9:44                       ` Wei Ni
2012-06-19  9:44                       ` Wei Ni
2012-06-20  0:01                       ` Stephen Warren
2012-06-20  0:01                         ` Stephen Warren
2012-06-20  0:01                         ` Stephen Warren
2012-06-20 10:47                         ` Mark Brown
2012-06-20 10:47                           ` Mark Brown
2012-06-20 10:47                           ` Mark Brown
2012-06-20 11:28                         ` Wei Ni
2012-06-20 11:28                           ` Wei Ni
2012-06-20 11:28                           ` Wei Ni
2012-06-20 16:51                           ` Stephen Warren
2012-06-20 16:51                             ` Stephen Warren
2012-06-20 16:51                             ` Stephen Warren
2012-06-26  8:56                         ` Dong Aisheng
2012-06-26  8:56                           ` Dong Aisheng
2012-06-26  8:56                           ` Dong Aisheng
     [not found]                           ` <20120626085605.GA6047-Fb7DQEYuewWctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2012-06-26 16:53                             ` Stephen Warren [this message]
2012-06-26 16:53                               ` Stephen Warren
     [not found]                               ` <4FE9E907.6050803-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-26 21:26                                 ` Rob Herring
2012-06-26 21:26                                   ` Rob Herring
     [not found]                                   ` <4FEA28EC.2080906-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-06-26 22:38                                     ` Stephen Warren
2012-06-26 22:38                                       ` Stephen Warren
2012-06-27  2:19                                     ` Dong Aisheng
2012-06-27  2:19                                       ` Dong Aisheng
2012-06-27  2:16                                 ` Dong Aisheng
2012-06-27  2:16                                   ` Dong Aisheng
2012-06-15 16:24           ` Franky Lin
2012-06-15 16:24             ` Franky Lin
2012-06-15 16:24             ` Franky Lin
2012-06-18  6:00             ` Wei Ni
2012-06-18  6:00               ` Wei Ni
2012-06-14 11:27   ` Wei Ni
2012-06-14 11:27     ` Wei Ni
2012-06-14 11:44     ` Wei Ni
2012-06-14 11:44       ` 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=4FE9E907.6050803@wwwdotorg.org \
    --to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
    --cc=B20596-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=aisheng.dong-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=alexander.shishkin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    --cc=b29397-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=frankyl-dY08KVG/lbpWk0Htik3J/w@public.gmane.org \
    --cc=krakesh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=makon-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=prakity-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org \
    --cc=r49496-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=r64343-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=r65037-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
    --cc=stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org \
    --cc=wni-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.