From: Stephen Warren <swarren@wwwdotorg.org>
To: Linus Walleij <linus.walleij@linaro.org>, Eric Anholt <eric@anholt.net>
Cc: linux-rpi-kernel <linux-rpi-kernel@lists.infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Lee Jones <lee@kernel.org>,
Florian Fainelli <f.fainelli@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>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
Stefan Wahren <stefan.wahren@i2se.com>
Subject: Re: [PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.
Date: Tue, 8 Mar 2016 09:42:24 -0700 [thread overview]
Message-ID: <56DF00F0.3080801@wwwdotorg.org> (raw)
In-Reply-To: <CACRpkdYzSt=R7j9GLSY39CsyMKLjqRYnP_31ti5jWiGngJacqA@mail.gmail.com>
On 03/08/2016 01:24 AM, Linus Walleij wrote:
> On Sat, Feb 27, 2016 at 1:19 AM, Eric Anholt <eric@anholt.net> wrote:
>
>> Since all of these pins were documented, we can use their names to
>> explain what's going on.
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>
>> + pinctrl-0 = <&i2c0_gpio0
>> + &i2c1_gpio2
>> + &gpclk0_gpio4
>> + &gpclk1_gpio5
>> + &spi0_gpio7
>> + &pcm_gpio18
>> + &pwm0_gpio40
>> + &pwm1_gpio45
>> + &gpioout
>> + &alt3>;
>
> Why are all of these done as hogs instead of being in pinctrl-0
> "default" for the device that is using them? i2c1, gpclk0,
> etc?
>
> The only reason I see would be if they are unused or something.
I think it makes sense to have the pinctrl driver (or even FW before the
kernel boots) set up everything at once where possible. That's the
easiest way to ensure there are never any conflicts in the pinmux table
(i.e. that two different pins don't end up being both muxed to SPI1's
MISO signal at the same time for a while before all the drivers probe).
Putting pinctrl entries into individual devices only makes sense to me
when one of:
a) That device needs to dynamically change the pinmux at run-time, e.g.
to switch between different states, so needs definitions of those
different states.
or:
b) The initial pinmux is guaranteed set up to a safe non-conflicting
state that enables very little, and we need to defer enabling various
peripherals until a later time when we know the peripheral is in use,
e.g. when loading a DT overlay from user-space.
On the RPi there are certain peripherals that fall into each category,
e.g. SD card is always used, I2S only optionally used.
next prev parent reply other threads:[~2016-03-08 16:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-26 18:19 [PATCH 0/5] BCM2835 pinctrl DT rework (resend) Eric Anholt
2016-02-26 18:19 ` [PATCH 1/5] ARM: bcm2835: Define standard pinctrl groups in the gpio node Eric Anholt
2016-03-03 21:20 ` Stephen Warren
[not found] ` <56D8AAA2.60907-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2016-03-03 22:23 ` Eric Anholt
2016-03-03 22:32 ` Stephen Warren
2016-03-04 9:27 ` Martin Sperl
2016-02-26 18:19 ` [PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups Eric Anholt
2016-03-03 21:26 ` Stephen Warren
2016-03-03 22:28 ` Eric Anholt
2016-03-03 22:34 ` Stephen Warren
2016-03-08 8:24 ` Linus Walleij
2016-03-08 16:42 ` Stephen Warren [this message]
2016-02-26 18:19 ` [PATCH 3/5] ARM: bcm2835: Move the emmc pin group to bcm283x.dtsi Eric Anholt
2016-02-26 18:19 ` [PATCH 4/5] ARM: bcm2835: Add a group for mapping pins 48-53 to sdhost Eric Anholt
2016-02-26 18:19 ` [PATCH 5/5] ARM: bcm2835: Move most RPi default pin groups to their devices Eric Anholt
2016-03-08 8:25 ` Linus Walleij
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=56DF00F0.3080801@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=devicetree@vger.kernel.org \
--cc=eric@anholt.net \
--cc=f.fainelli@gmail.com \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=lee@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=stefan.wahren@i2se.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).