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

Dong Aisheng
2012-06-27T02:19:38Z

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