From: Alexandre Courbot <acourbot@nvidia.com>
To: Stephen Warren <swarren@wwwdotorg.org>,
Thierry Reding <thierry.reding@gmail.com>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Russell King <linux@arm.linux.org.uk>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ARM: tegra: add device tree for SHIELD
Date: Wed, 26 Feb 2014 14:12:16 +0900 [thread overview]
Message-ID: <530D77B0.8080807@nvidia.com> (raw)
In-Reply-To: <530D754A.60700@wwwdotorg.org>
On 02/26/2014 02:02 PM, Stephen Warren wrote:
> On 02/25/2014 09:58 PM, Alexandre Courbot wrote:
>> On 02/26/2014 07:38 AM, Stephen Warren wrote:
>>> On 02/24/2014 07:13 PM, Alexandre Courbot wrote:
>>>> On 02/25/2014 03:53 AM, Stephen Warren wrote:
>>>>> On 02/24/2014 03:26 AM, Alexandre Courbot wrote:
>>>>>> Add a device tree for NVIDIA SHIELD. The set of enabled features is
>>>>>> still minimal with no display option (although HDMI should be easy
>>>>>> to get to work) and USB requiring external power.
> ...
>>>> 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.
>>>
>>> How does that GPIO get manipulated right now? I assume you must be
>>> manually configuring it via sysfs after boot or something? If so,
>>> perhaps it's best to just leave out the WiFi node until it works
>>> automatically.
>>
>> The GPIO needs to be set from user-space, yes. But if we leave the Wifi
>> node out, I'm concerned that wireless will not be usable at all,
>> wouldn't it?
>
> True, but if we have no representation of the device in DT that works
> without manually enabling clocks and/or GPIOs, it's not a
> complete/accurate representation of the HW, so it doesn't make sense to
> add it to DT. Yes, I admit that sucks.
Well, I can always enable it in my out-of-tree branch until we can push
the complete binding in mainline, so I'm ok with taking it out of this
patch for now.
WARNING: multiple messages have this Message-ID (diff)
From: acourbot@nvidia.com (Alexandre Courbot)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: tegra: add device tree for SHIELD
Date: Wed, 26 Feb 2014 14:12:16 +0900 [thread overview]
Message-ID: <530D77B0.8080807@nvidia.com> (raw)
In-Reply-To: <530D754A.60700@wwwdotorg.org>
On 02/26/2014 02:02 PM, Stephen Warren wrote:
> On 02/25/2014 09:58 PM, Alexandre Courbot wrote:
>> On 02/26/2014 07:38 AM, Stephen Warren wrote:
>>> On 02/24/2014 07:13 PM, Alexandre Courbot wrote:
>>>> On 02/25/2014 03:53 AM, Stephen Warren wrote:
>>>>> On 02/24/2014 03:26 AM, Alexandre Courbot wrote:
>>>>>> Add a device tree for NVIDIA SHIELD. The set of enabled features is
>>>>>> still minimal with no display option (although HDMI should be easy
>>>>>> to get to work) and USB requiring external power.
> ...
>>>> 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.
>>>
>>> How does that GPIO get manipulated right now? I assume you must be
>>> manually configuring it via sysfs after boot or something? If so,
>>> perhaps it's best to just leave out the WiFi node until it works
>>> automatically.
>>
>> The GPIO needs to be set from user-space, yes. But if we leave the Wifi
>> node out, I'm concerned that wireless will not be usable at all,
>> wouldn't it?
>
> True, but if we have no representation of the device in DT that works
> without manually enabling clocks and/or GPIOs, it's not a
> complete/accurate representation of the HW, so it doesn't make sense to
> add it to DT. Yes, I admit that sucks.
Well, I can always enable it in my out-of-tree branch until we can push
the complete binding in mainline, so I'm ok with taking it out of this
patch for now.
next prev parent reply other threads:[~2014-02-26 5:12 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-24 10:26 [PATCH] ARM: tegra: add device tree for SHIELD Alexandre Courbot
2014-02-24 10:26 ` Alexandre Courbot
2014-02-24 10:26 ` Alexandre Courbot
[not found] ` <1393237593-28121-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-02-24 18:53 ` Stephen Warren
2014-02-24 18:53 ` Stephen Warren
2014-02-24 18:53 ` Stephen Warren
2014-02-25 2:13 ` Alexandre Courbot
2014-02-25 2:13 ` Alexandre Courbot
2014-02-25 2:13 ` Alexandre Courbot
[not found] ` <530BFC58.6020003-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-02-25 9:52 ` Arend van Spriel
2014-02-25 9:52 ` Arend van Spriel
2014-02-25 9:52 ` Arend van Spriel
[not found] ` <530C67F4.7010208-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
2014-02-26 4:52 ` Alexandre Courbot
2014-02-26 4:52 ` Alexandre Courbot
2014-02-26 4:52 ` Alexandre Courbot
2014-02-26 21:10 ` Arend van Spriel
2014-02-26 21:10 ` Arend van Spriel
2014-02-25 22:38 ` Stephen Warren
2014-02-25 22:38 ` Stephen Warren
2014-02-25 22:38 ` Stephen Warren
[not found] ` <530D1B7A.9070209-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-02-26 4:58 ` Alexandre Courbot
2014-02-26 4:58 ` Alexandre Courbot
2014-02-26 4:58 ` Alexandre Courbot
[not found] ` <530D748D.6010802-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-02-26 5:02 ` Stephen Warren
2014-02-26 5:02 ` Stephen Warren
2014-02-26 5:02 ` Stephen Warren
2014-02-26 5:12 ` Alexandre Courbot [this message]
2014-02-26 5:12 ` Alexandre Courbot
-- strict thread matches above, loose matches on Subject: below --
2014-03-03 3:49 Alexandre Courbot
2014-03-03 3:49 ` Alexandre Courbot
2014-03-03 3:49 ` Alexandre Courbot
[not found] ` <1393818596-26775-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-03-03 3:53 ` Alexandre Courbot
2014-03-03 3:53 ` Alexandre Courbot
2014-03-03 3:53 ` Alexandre Courbot
2014-03-03 17:00 ` Stephen Warren
2014-03-03 17:00 ` Stephen Warren
2014-03-03 17:00 ` Stephen Warren
2014-03-04 1:24 ` Alexandre Courbot
2014-03-04 1:24 ` Alexandre Courbot
2014-03-04 1:24 ` Alexandre Courbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=530D77B0.8080807@nvidia.com \
--to=acourbot@nvidia.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=swarren@wwwdotorg.org \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.