Message ID | 1456510756-15337-3-git-send-email-eric@anholt.net |
---|---|
State | New |
Headers | show |
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? 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.) -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
On 03/03/2016 03:28 PM, Eric Anholt wrote: > 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. I don't think it's worth making patches that change things around when they're immediately going to be thrown away. It is needless churn. If you take the approach of removing settings that shouldn't be applied, you'll vastly reduce (and possibly even completely eliminate) the work to more optimally represent what's left. -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts index 228614f..0a8b92e 100644 --- a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts +++ b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts @@ -21,11 +21,14 @@ }; &gpio { - pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>; - - /* I2S interface */ - i2s_alt0: i2s_alt0 { - brcm,pins = <18 19 20 21>; - brcm,function = <BCM2835_FSEL_ALT0>; - }; + pinctrl-0 = <&i2c0_gpio0 + &i2c1_gpio2 + &gpclk0_gpio4 + &gpclk1_gpio5 + &spi0_gpio7 + &pcm_gpio18 + &pwm0_gpio40 + &pwm1_gpio45 + &gpioout + &alt3>; }; diff --git a/arch/arm/boot/dts/bcm2835-rpi-a.dts b/arch/arm/boot/dts/bcm2835-rpi-a.dts index ddbbbbd..d093407 100644 --- a/arch/arm/boot/dts/bcm2835-rpi-a.dts +++ b/arch/arm/boot/dts/bcm2835-rpi-a.dts @@ -14,11 +14,14 @@ }; &gpio { - pinctrl-0 = <&gpioout &alt0 &i2s_alt2 &alt3>; - - /* I2S interface */ - i2s_alt2: i2s_alt2 { - brcm,pins = <28 29 30 31>; - brcm,function = <BCM2835_FSEL_ALT2>; - }; + pinctrl-0 = <&i2c0_gpio0 + &i2c1_gpio2 + &gpclk0_gpio4 + &gpclk1_gpio5 + &spi0_gpio7 + &pcm_gpio28 + &pwm0_gpio40 + &pwm1_gpio45 + &gpioout + &alt3>; }; diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts index ef54050..c26b81d 100644 --- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts +++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts @@ -21,11 +21,14 @@ }; &gpio { - pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>; - - /* I2S interface */ - i2s_alt0: i2s_alt0 { - brcm,pins = <18 19 20 21>; - brcm,function = <BCM2835_FSEL_ALT0>; - }; + pinctrl-0 = <&i2c0_gpio0 + &i2c1_gpio2 + &gpclk0_gpio4 + &gpclk1_gpio5 + &spi0_gpio7 + &pcm_gpio18 + &pwm0_gpio40 + &pwm1_gpio45 + &gpioout + &alt3>; }; diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts index 86f1f2f..a5b606e 100644 --- a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts +++ b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts @@ -14,11 +14,14 @@ }; &gpio { - pinctrl-0 = <&gpioout &alt0 &i2s_alt2 &alt3>; - - /* I2S interface */ - i2s_alt2: i2s_alt2 { - brcm,pins = <28 29 30 31>; - brcm,function = <BCM2835_FSEL_ALT2>; - }; + pinctrl-0 = <&i2c0_gpio0 + &i2c1_gpio2 + &gpclk0_gpio4 + &gpclk1_gpio5 + &spi0_gpio7 + &pcm_gpio28 + &pwm0_gpio40 + &pwm1_gpio45 + &gpioout + &alt3>; }; diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts b/arch/arm/boot/dts/bcm2835-rpi-b.dts index 4859e9d..97e3c2f 100644 --- a/arch/arm/boot/dts/bcm2835-rpi-b.dts +++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts @@ -14,5 +14,13 @@ }; &gpio { - pinctrl-0 = <&gpioout &alt0 &alt3>; + pinctrl-0 = <&i2c0_gpio0 + &i2c1_gpio2 + &gpclk0_gpio4 + &gpclk1_gpio5 + &spi0_gpio7 + &pwm0_gpio40 + &pwm1_gpio45 + &gpioout + &alt3>; }; diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/dts/bcm2835-rpi.dtsi index 76bdbca..141b18c 100644 --- a/arch/arm/boot/dts/bcm2835-rpi.dtsi +++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi @@ -37,11 +37,6 @@ brcm,function = <BCM2835_FSEL_GPIO_OUT>; }; - alt0: alt0 { - brcm,pins = <0 1 2 3 4 5 7 8 9 10 11 14 15 40 45>; - brcm,function = <BCM2835_FSEL_ALT0>; - }; - alt3: alt3 { brcm,pins = <48 49 50 51 52 53>; brcm,function = <BCM2835_FSEL_ALT3>; diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts index ff94666..52798ca 100644 --- a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts +++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts @@ -25,11 +25,14 @@ }; &gpio { - pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>; - - /* I2S interface */ - i2s_alt0: i2s_alt0 { - brcm,pins = <18 19 20 21>; - brcm,function = <BCM2835_FSEL_ALT0>; - }; + pinctrl-0 = <&i2c0_gpio0 + &i2c1_gpio2 + &gpclk0_gpio4 + &gpclk1_gpio5 + &spi0_gpio7 + &pcm_gpio18 + &pwm0_gpio40 + &pwm1_gpio45 + &gpioout + &alt3>; };
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> --- arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 17 ++++++++++------- arch/arm/boot/dts/bcm2835-rpi-a.dts | 17 ++++++++++------- arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 17 ++++++++++------- arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 17 ++++++++++------- arch/arm/boot/dts/bcm2835-rpi-b.dts | 10 +++++++++- arch/arm/boot/dts/bcm2835-rpi.dtsi | 5 ----- arch/arm/boot/dts/bcm2836-rpi-2-b.dts | 17 ++++++++++------- 7 files changed, 59 insertions(+), 41 deletions(-)