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

[Wei Ni]

On Wed, Jun 20, 2012 at 08:01:54, Stephen Warren wrote:
>On 06/19/2012 03:44 AM, Wei Ni wrote:
>> On Tue, Jun 19, 2012 at 17:17:19, Mark Brown wrote:
>>> * PGP Signed by an unknown key
>>>
>>> On Tue, Jun 19, 2012 at 12:25:58PM +0800, Wei Ni wrote:
>>>
>>> As Stephen previously said please fix your mail formatting - word 
>>> wrapping within paragraphs is important!
>>>
>>>> On Tue, Jun 19, 2012 at 09:23:35, Philip Rakity wrote:
>>>>> Why can't you use the regulator notify to get called back on power 
>>>>> or voltage change options to plumb in the manipulation of the gpio.
>>>>> I can imagine you might need to add a notify call in core.c if you 
>>>>> need to assert the gpio before power is applied
>>>>
>>>> Yes, we can use the regulator notify, but the Tegra30 support is 
>>>> via device tree, I think there have no special board file to run 
>>>> the call back.
>>>
>>> You can mix board files with device tree for cases where device tree 
>>> is not yet up to the job, though the goal should be to come up with 
>>> a way of expressing things in
>device tree.
>>
>> I think we wish to use the device tree to handle these gpios, pass 
>> them to the related driver to
>assert them.
>> If we mix the board files, we even can set these gpio directly, not 
>> use the notify. But I think this
>is not a goog way.
>
>Yes, I would definitely not want to add this to a board file; there is 
>no board file for Cardhu, and we're getting close to deleting all the board files that are left for other boards.
>
>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?
>
>But in this case, at least some of the data those two drivers want from 
>that node is the same; the 2 GPIOs that control the reset and enable 
>signals. Do we just make the bindings for those two devices happen to 
>share the same properties so that we can get away with just one node 
>irrespective of what device type has been found? What we're really modeling is the card slot, and the services it provides, so perhaps we should really end up with:
>
>sdhci at 78000000 {
>	compatible = "nvidia,tegra30-sdhci", "nvidia,tegra20-sdhci";
>	reg = <0x78000000 0x200>;
>	interrupts = <0 14 0x04>;
>
>	socket {
>		reset-gpios = <...>;
>		enable-gpios = <...>;
>
>		sdio-device-option at 0 {
>			compatible = "broadcom,bcm4239";
>		};
>
>		sdio-device-option at 1 {
>			compatible = "broadcom,bcm4330";
>		};
>	};
>};
>
>Where somehow the WiFi drivers can obtain the reset/enable service from 
>the socket that hosts them, but still have nodes for the attached 
>device itself in case any additional driver-specific configuration is needed.
>
>That sounds somewhat similar to the virtual platform device that was 
>mentioned earlier in this thread by Broadcom, although I'm not sure 
>whether explicitly modeling it as a platform device makes sense, rather than the socket providing services to the WiFi module, not necessarily through a device.
>
>Unfortunately, it should be noted that the WiFi device socket on Cardhu 
>apparently isn't some standardized thing (like PCIe) but something 
>rather more custom, although there are apparently devices available to 
>plug into it from multiple module vendors which contain WiFi chips from multiple chip vendors.
>
>Anyway, these are just some quick thoughts on the topic - obviously more flesh is needed.

Stephen, as Rakesh said that in case of bcm4329, the two GPIO (WF_EN and WF_RST) are shorted. So I think we can simply to use the power-gpios properity in the SD driver, just use one gpio.
I test it in this way, it runs ok, the bcm4329 can be powered up. We can use this option.

---
nvpublic