[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 03 Mar 2016 14:28:58 -0800
From: Eric Anholt <eric@...olt.net>
To: Stephen Warren <swarren@...dotorg.org>
Cc: linux-rpi-kernel@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Lee Jones <lee@...nel.org>,
Florian Fainelli <f.fainelli@...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>, devicetree@...r.kernel.org,
Linus Walleij <linus.walleij@...aro.org>,
linux-gpio@...r.kernel.org, Stefan Wahren <stefan.wahren@...e.com>
Subject: Re: [PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.
Stephen Warren <swarren@...dotorg.org> writes:
> On 02/26/2016 11:19 AM, Eric Anholt wrote:
>> Since all of these pins were documented, we can use their names to
>> explain what's going on.
>
>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
>
>> &gpio {
>> + pinctrl-0 = <&i2c0_gpio0
>> + &i2c1_gpio2
>> + &gpclk0_gpio4
>> + &gpclk1_gpio5
>> + &spi0_gpio7
>> + &pcm_gpio18
>> + &pwm0_gpio40
>> + &pwm1_gpio45
>> + &gpioout
>> + &alt3>;
>> };
>
> Why not convert alt3 to the new scheme too?
(covered in the next patch)
> I think this configures too many pins, which in turn makes assumptions
> about what those pins are used for that may not be valid.
>
> Recent RPi firmware configures almost all expansion connector GPIOs as
> GPIO-in. This ensures that no matter what is connected to the expansion
> connector, there can be no signal conflicts due to both the bcm283x and
> some external device both attempting to drive the same pin. I believe
> the default Linux pinmux should adopt the same approach, by simply not
> configuring any expansion connector pins except those known to have a
> 100% hard-coded usage. For example, the HAT I2C pins must only be used
> for that purpose on the RPi, so even if the HW supported using them as
> arbitrary GPIO or PWM or ..., we know they're actually I2C.
>
> So, I think this list should only include configuration for pins
> connected to on-board devices, or expansion pins that have a 100% known
> purpose.
>
> (I can't quite remember how many pins are being configured in the
> upstream kernel's DT files at present; it's possible the complying with
> this rule may involve removing some pinctrl settings that are currently
> present to avoid conflicts. User-specific additions should come from DT
> overlays or manual DT edits.)
If we want to improve on our default pin configurations, I'm into that,
but I think the first step is to get groups split up so it's clear what
we're doing with pins in the first place. This patch is just a no-op
change to get the board files to use smaller groups for
enabling/disabling, and we should stack functional changes after that.
Download attachment "signature.asc" of type "application/pgp-signature" (819 bytes)
Powered by blists - more mailing lists