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@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? 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@78000000 { compatible = "nvidia,tegra30-sdhci", "nvidia,tegra20-sdhci"; reg = <0x78000000 0x200>; interrupts = <0 14 0x04>; socket { reset-gpios = <...>; enable-gpios = <...>; sdio-device-option@0 { compatible = "broadcom,bcm4239"; }; sdio-device-option@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. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html