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

[Dong Aisheng]

On Wed, Jun 27, 2012 at 05:26:04AM +0800, 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.
> 
Those properties are sdio-device specific, the host may be hard to
know to handle it in a common way.

> One question is do the gpios have strict timing or ordering
> requirements. If so then that would be difficult to describe generically.
> 
Yes, may need special timing.

Regards
Dong Aisheng