Date:	Wed, 26 Feb 2014 13:52:43 +0900
From:	Alexandre Courbot <acourbot@...dia.com>
To:	Arend van Spriel <arend@...adcom.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Russell King <linux@....linux.org.uk>
CC:	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ARM: tegra: add device tree for SHIELD

On 02/25/2014 06:52 PM, Arend van Spriel wrote:
> On 02/25/2014 03:13 AM, Alexandre Courbot wrote:
>>>
>>>> +    /* Wifi */
>>>> +    sdhci@...00000 {
>>>> +        status = "okay";
>>>> +        bus-width = <4>;
>>>> +        broken-cd;
>>>> +        keep-power-in-suspend;
>>>> +        cap-sdio-irq;
>>>
>>> Is non-removable better than broken-cd, or are they entirely unrelated?
>>
>> They are unrelated actually. With non-removable the driver expects the
>> device to always be there since boot, and does not check for the card to
>> be removed/added after boot. broken-cd indicates there is no CD line and
>> the device should be polled regularly.
>>
>> For the Wifi chip, non-removable would be the correct setting
>> hardware-wise, but there is a trap: the chip has its reset line asserted
>> at boot-time, and you need to set GPIO 229 to de-assert it. Only after
>> that will the device be detected on the SDIO bus. Since it lacks a CD
>> line, it must be polled, hence the broken-cd property.
>>
>> This also raises another, redundant problem with DT bindings: AFAIK we
>> currently have no way to let the system know the device will only appear
>> after a given GPIO is set. It would also be nice to be able to give some
>> parameters to the Wifi driver through the DT (like the OOB interrupt).
>> Right now the Wifi chip is brought up by exporting the GPIO and writing
>> to it from user-space, and the OOB interrupt is not used.
>
> Hi Alexandre,
>
> I recently posted a proposal for brcmfmac DT binding [1]. I did receive
> some comments, but it would be great if you (and/or others involved) had
> a look at it as well and give me some feedback. DT work still needs to
> grow on me.

Hi Arend, (and thanks again for all the help with getting the chip to work!)

Great, I'm not subscribed to the devicetree list and so have missed this 
thread, but I'm glad to see it.

I don't think I have much to add to the comments you already received 
there. I'd need it to reference the 32K clock (which I currently 
force-enable manually), the OOB interrupt, and the reset pin as a GPIO 
(as for SHIELD the device needs to be put out of reset using an 
active-low GPIO before anything can happen). That last property could be 
optional as I suspect most designs won't use it.

Getting the device out of reset should be done before the bus probes the 
non-removable device, so I wonder how this would fit wrt. the DT 
power-on sequencing series by Olof. Something tells me this could rather 
be a property of the bus, but physically speaking the pin is connected 
to the wifi chip, so... Maybe we could get the platform driver to ask 
the bus to probe again after enabling power/getting the device out of reset?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists