lkml.org 
[lkml]   [2016]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.
Date
Stephen Warren <swarren@wwwdotorg.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.
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2016-03-04 00:01    [W:0.231 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site