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@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.
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
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
