* [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
@ 2016-10-18 16:38 Eric Anholt
2016-10-19 12:16 ` Linus Walleij
0 siblings, 1 reply; 8+ messages in thread
From: Eric Anholt @ 2016-10-18 16:38 UTC (permalink / raw)
To: linux-arm-kernel
From: Linus Walleij <linus.walleij@linaro.org>
The idea is to give useful names to GPIO lines that an implementer
will be using from userspace, e.g. for maker type projects. These are
user-visible using tools/gpio/lsgpio.c
v2: Major rewrite by anholt: Flatten each GPIO line to a line in the
file for better diffing, prefix all expansion header pins with
"P<number>" or "P5HEADER_P<number>" and drop the mostly-unused
GPIO_GEN<smallnumber> names in favor of GPIO<socgpionumber>, fix
extra '[]' on a couple of lines, fix locations of SD_CARD_DETECT,
CAM_GPIO and STATUS_LED, fix HDMI_HPD polarities, rewrite A+ using
unreleased schematics.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
---
Note: I haven't actually booted these and checked that the names line
up, just tried to visually review them. Hopefully with more
GPIO<number> values, it's easier to spot errors.
The only other thing here I think I would do is drop the [] around
names for behavior when pinmuxed. I find it more confusing than
helpful.
Linus, are these names considered ABI? Will we be locked into
whatever set of names we merge and release? My assumption would be
"yes".
arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 66 +++++++++++++++++++++++++++++++
arch/arm/boot/dts/bcm2835-rpi-a.dts | 68 ++++++++++++++++++++++++++++++++
arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 67 +++++++++++++++++++++++++++++++
arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 67 +++++++++++++++++++++++++++++++
arch/arm/boot/dts/bcm2835-rpi-b.dts | 68 ++++++++++++++++++++++++++++++++
5 files changed, 336 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
index 21507c922783..cec4c6e49e7b 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
@@ -22,6 +22,72 @@
};
&gpio {
+ /*
+ * This is based on the unreleased schematic for the Model A+.
+ *
+ * Legend:
+ * "NC" = not connected (no rail from the SoC)
+ * "[FOO]" = pin is muxed for peripheral FOO (not GPIO)
+ * "FOO" = GPIO line named "FOO" on the schematic
+ * "FOO_N" = GPIO line named "FOO" on schematic, active low
+ */
+ gpio-line-names = "[SDA0]",
+ "[SCL0]",
+ "[P3_SDA1]",
+ "[P5_SCL1]",
+ "[P7_GPIO_GCLK]",
+ "P29_GPIO5",
+ "P31_GPIO6",
+ "[P26_SPI_CE1_N]",
+ "[P24_SPI_CE0_N]",
+ "[P21_SPI_MISO]",
+ "[P19_SPI_MOSI]",
+ "[P23_SPI_SCLK]",
+ "P32_GPIO12",
+ "P33_GPIO13",
+ /* Serial port */
+ "[P8_TXD0]",
+ "[P10_RXD0]",
+ "P36_GPIO16",
+ "P11_GPIO17",
+ "P12_GPIO18",
+ "P35_GPIO19",
+ "P38_GPIO20",
+ "P40_GPIO21",
+ "P15_GPIO22",
+ "P16_GPIO23",
+ "P18_GPIO24",
+ "P22_GPIO25",
+ "P37_GPIO26",
+ "P13_GPIO27",
+ "[SDA0]",
+ "[SCL0]",
+ "NC", /* GPIO30 */
+ "NC", /* GPIO31 */
+ "NC", /* GPIO32 */
+ "NC", /* GPIO33 */
+ "NC", /* GPIO34 */
+ "PWR_LOW_N", /* GPIO35 */
+ "NC", /* GPIO36 */
+ "NC", /* GPIO37 */
+ "NC", /* GPIO38 */
+ "NC", /* GPIO39 */
+ "[PWM0_OUT]", /* GPIO40 */
+ "CAM_GPIO0", /* GPIO41 */
+ "NC", /* GPIO42 */
+ "NC", /* GPIO43 */
+ "NC", /* GPIO44 */
+ "[PWM1_OUT]", /* GPIO45 */
+ "HDMI_HPD_N",
+ "STATUS_LED",
+ /* Used by SD Card */
+ "[SD_CLK_R]",
+ "[SD_CMD_R]",
+ "[SD_DATA0_R]",
+ "[SD_DATA1_R]",
+ "[SD_DATA2_R]",
+ "[SD_DATA3_R]";
+
pinctrl-0 = <&gpioout &alt0 &i2s_alt0>;
/* I2S interface */
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a.dts b/arch/arm/boot/dts/bcm2835-rpi-a.dts
index 5afba0900449..0ff96ed4d15b 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a.dts
@@ -15,6 +15,74 @@
};
&gpio {
+ /*
+ * Taken from Raspberry-Pi-Rev-1.0-Model-AB-Schematics.pdf
+ * RPI00021 sheet 02
+ *
+ * Legend:
+ * "NC" = not connected (no rail from the SoC)
+ * "[FOO]" = pin is muxed for peripheral FOO (not GPIO)
+ * "FOO" = GPIO line named "FOO" on the schematic
+ * "FOO_N" = GPIO line named "FOO" on schematic, active low
+ */
+ gpio-line-names = "[P3_SDA0]",
+ "[P5_SCL0]",
+ "[SDA1]",
+ "[SCL1]",
+ "[P7_GPIO_GCLK]",
+ "[CAM_CLK]",
+ "LAN_RUN",
+ "[P26_SPI_CE1_N]",
+ "[P24_SPI_CE0_N]",
+ "[P21_SPI_MISO]",
+ "[P19_SPI_MOSI]",
+ "[P23_SPI_SCLK]",
+ "NC", /* GPIO12 */
+ "NC", /* GPIO13 */
+ /* Serial port */
+ "[P8_TXD0]",
+ "[P10_RXD0]",
+ "STATUS_LED_N",
+ "P11_GPIO17",
+ "P12_GPIO18",
+ "NC", /* GPIO19 */
+ "NC", /* GPIO20 */
+ "P13_GPIO21",
+ "P15_GPIO22",
+ "P16_GPIO23",
+ "P18_GPIO24",
+ "P22_GPIO25",
+ "NC", /* GPIO26 */
+ "CAM_GPIO",
+ /* Binary number representing build/revision */
+ "CONFIG0",
+ "CONFIG1",
+ "CONFIG2",
+ "CONFIG3",
+ "NC", /* GPIO32 */
+ "NC", /* GPIO33 */
+ "NC", /* GPIO34 */
+ "NC", /* GPIO35 */
+ "NC", /* GPIO36 */
+ "NC", /* GPIO37 */
+ "NC", /* GPIO38 */
+ "NC", /* GPIO39 */
+ "[PWM0_OUT]",
+ "NC", /* GPIO41 */
+ "NC", /* GPIO42 */
+ "NC", /* GPIO43 */
+ "NC", /* GPIO44 */
+ "[PWM1_OUT]",
+ "HDMI_HPD_P",
+ "SD_CARD_DET",
+ /* Used by SD Card */
+ "[SD_CLK_R]",
+ "[SD_CMD_R]",
+ "[SD_DATA0_R]",
+ "[SD_DATA1_R]",
+ "[SD_DATA2_R]",
+ "[SD_DATA3_R]";
+
pinctrl-0 = <&gpioout &alt0 &i2s_alt2>;
/* I2S interface */
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
index 38f66aa244fe..0e04fc2eb65e 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
@@ -23,6 +23,73 @@
};
&gpio {
+ /*
+ * Taken from Raspberry-Pi-B-Plus-V1.2-Schematics.pdf
+ * RPI-BPLUS sheet 1
+ *
+ * Legend:
+ * "NC" = not connected (no rail from the SoC)
+ * "[FOO]" = pin is muxed for peripheral FOO (not GPIO)
+ * "FOO" = GPIO line named "FOO" on the schematic
+ * "FOO_N" = GPIO line named "FOO" on schematic, active low
+ */
+ gpio-line-names = "[ID_SD]",
+ "[ID_SC]",
+ "[P3_SDA1]",
+ "[P5_SCL1]",
+ "[P7_GPIO_GCLK]",
+ "P29_GPIO5",
+ "P31_GPIO6",
+ "[P26_SPI_CE1_N]",
+ "[P24_SPI_CE0_N]",
+ "[P21_SPI_MISO]",
+ "[P19_SPI_MOSI]",
+ "[P23_SPI_SCLK]",
+ "P23_GPIO12",
+ "P33_GPIO13",
+ /* Serial port */
+ "[P8_TXD0]",
+ "[P10_RXD0]",
+ "P36_GPIO16",
+ "P11_GPIO17",
+ "P12_GPIO18",
+ "P35_GPIO19",
+ "P38_GPIO20",
+ "P40_GPIO21",
+ "P15_GPIO22",
+ "P16_GPIO23",
+ "P18_GPIO24",
+ "P22_GPIO25",
+ "P37_GPIO26",
+ "P13_GPIO27",
+ "[SDA0]",
+ "[SCL0]",
+ "NC", /* GPIO30 */
+ "LAN_RUN", /* GPIO31 */
+ "CAM_GPIO1", /* GPIO32 */
+ "NC", /* GPIO33 */
+ "NC", /* GPIO34 */
+ "PWR_LOW_N", /* GPIO35 */
+ "NC", /* GPIO36 */
+ "NC", /* GPIO37 */
+ "NC", /* GPIO38 */
+ "NC", /* GPIO39 */
+ "[PWM0_OUT]", /* GPIO40 */
+ "CAM_GPIO0", /* GPIO41 */
+ "NC", /* GPIO42 */
+ "NC", /* GPIO43 */
+ "ETHCLK", /* GPIO44 */
+ "[PWM1_OUT]", /* GPIO45 */
+ "HDMI_HPD_N",
+ "STATUS_LED",
+ /* Used by SD Card */
+ "[SD_CLK_R]",
+ "[SD_CMD_R]",
+ "[SD_DATA0_R]",
+ "[SD_DATA1_R]",
+ "[SD_DATA2_R]",
+ "[SD_DATA3_R]";
+
pinctrl-0 = <&gpioout &alt0 &i2s_alt0>;
/* I2S interface */
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
index 75e045aba7ce..6c91c9f0536c 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
@@ -16,6 +16,73 @@
};
&gpio {
+ /*
+ * Taken from Raspberry-Pi-Rev-2.0-Model-AB-Schematics.pdf
+ * RPI00022 sheet 02
+ *
+ * Legend:
+ * "NC" = not connected (no rail from the SoC)
+ * "[FOO]" = pin is muxed for peripheral FOO (not GPIO)
+ * "FOO" = GPIO line named "FOO" on the schematic
+ * "FOO_N" = GPIO line named "FOO" on schematic, active low
+ */
+ gpio-line-names = "[SDA0]",
+ "[SCL0]",
+ "[P3_SDA1]",
+ "[P5_SCL1]",
+ "[P7_GPIO_GCLK]",
+ "[CAM_CLK]",
+ "LAN_RUN",
+ "[P26_SPI_CE1_N]",
+ "[P24_SPI_CE0_N]",
+ "[P21_SPI_MISO]",
+ "[P19_SPI_MOSI]",
+ "[P23_SPI_SCLK]",
+ "NC", /* GPIO12 */
+ "NC", /* GPIO13 */
+ /* Serial port */
+ "[P8_TXD0]",
+ "[P10_RXD0]",
+ "STATUS_LED_N",
+ "P11_GPIO17",
+ "P12_GPIO18",
+ "NC", /* GPIO19 */
+ "NC", /* GPIO20 */
+ "CAM_GPIO",
+ "P15_GPIO22",
+ "P16_GPIO23",
+ "P18_GPIO24",
+ "P22_GPIO25",
+ "NC", /* GPIO 26 */
+ "P13_GPIO27",
+ "P5HEADER_P3_GPIO28",
+ "P5HEADER_P4_GPIO29",
+ "P5HEADER_P5_GPIO30",
+ "P5HEADER_P6_GPIO31",
+ "NC", /* GPIO32 */
+ "NC", /* GPIO33 */
+ "NC", /* GPIO34 */
+ "NC", /* GPIO35 */
+ "NC", /* GPIO36 */
+ "NC", /* GPIO37 */
+ "NC", /* GPIO38 */
+ "NC", /* GPIO39 */
+ "[PWM0_OUT]",
+ "NC", /* GPIO41 */
+ "NC", /* GPIO42 */
+ "NC", /* GPIO43 */
+ "NC", /* GPIO44 */
+ "[PWM1_OUT]",
+ "HDMI_HPD_P",
+ "SD_CARD_DET",
+ /* Used by SD Card */
+ "[SD_CLK_R]",
+ "[SD_CMD_R]",
+ "[SD_DATA0_R]",
+ "[SD_DATA1_R]",
+ "[SD_DATA2_R]",
+ "[SD_DATA3_R]";
+
pinctrl-0 = <&gpioout &alt0 &i2s_alt2>;
/* I2S interface */
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index 76a254b3219a..023239946826 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -16,6 +16,74 @@
};
&gpio {
+ /*
+ * Taken from Raspberry-Pi-Rev-1.0-Model-AB-Schematics.pdf
+ * RPI00021 sheet 02
+ *
+ * Legend:
+ * "NC" = not connected (no rail from the SoC)
+ * "[FOO]" = pin is muxed for peripheral FOO (not GPIO)
+ * "FOO" = GPIO line named "FOO" on the schematic
+ * "FOO_N" = GPIO line named "FOO" on schematic, active low
+ */
+ gpio-line-names = "[P3_SDA0]",
+ "[P5_SCL0]",
+ "[SDA1]",
+ "[SCL1]",
+ "[P7_GPIO_GCLK]",
+ "[CAM_CLK]",
+ "LAN_RUN",
+ "[P26_SPI_CE1_N]",
+ "[P24_SPI_CE0_N]",
+ "[P21_SPI_MISO]",
+ "[P19_SPI_MOSI]",
+ "[P23_SPI_SCLK]",
+ "NC", /* GPIO12 */
+ "NC", /* GPIO13 */
+ /* Serial port */
+ "[P8_TXD0]",
+ "[P10_RXD0]",
+ "STATUS_LED_N",
+ "P11_GPIO17",
+ "P12_GPIO18",
+ "NC", /* GPIO19 */
+ "NC", /* GPIO20 */
+ "P13_GPIO21",
+ "P15_GPIO22",
+ "P16_GPIO23",
+ "P18_GPIO24",
+ "P22_GPIO25",
+ "NC", /* GPIO26 */
+ "CAM_GPIO",
+ /* Binary number representing build/revision */
+ "CONFIG0",
+ "CONFIG1",
+ "CONFIG2",
+ "CONFIG3",
+ "NC", /* GPIO32 */
+ "NC", /* GPIO33 */
+ "NC", /* GPIO34 */
+ "NC", /* GPIO35 */
+ "NC", /* GPIO36 */
+ "NC", /* GPIO37 */
+ "NC", /* GPIO38 */
+ "NC", /* GPIO39 */
+ "[PWM0_OUT]",
+ "NC", /* GPIO41 */
+ "NC", /* GPIO42 */
+ "NC", /* GPIO43 */
+ "NC", /* GPIO44 */
+ "[PWM1_OUT]",
+ "HDMI_HPD_P",
+ "SD_CARD_DET",
+ /* Used by SD Card */
+ "[SD_CLK_R]",
+ "[SD_CMD_R]",
+ "[SD_DATA0_R]",
+ "[SD_DATA1_R]",
+ "[SD_DATA2_R]",
+ "[SD_DATA3_R]";
+
pinctrl-0 = <&gpioout &alt0>;
};
--
2.9.3
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
@ 2016-10-18 20:48 Gottfried Haider
0 siblings, 0 replies; 8+ messages in thread
From: Gottfried Haider @ 2016-10-18 20:48 UTC (permalink / raw)
To: linux-arm-kernel
Hi Eric, Linus,
I'll hopefully find time to look at the more recent changes to the
gpio subsystem (lsgpio?!), but since this patch is up for discussion
now - what I was wondering: how does this change relate to
/sys/class/gpio/gpio%d? Is this completely orthogonal - or would this
change the sysfs interface as well?
Regarding the proposed format using the header pin numbers: From what
I've seen in terms of existing educational materials, it seems the
overwhelming majority ends up using GPIO numbers instead of physical
pin header numbering. (e.g. [1] [2])
Would it be too confusing to try to pick GPIO 5 from an alphabetically
sorted list like this "P11_GPIO17", "P12_GPIO18"? (I know,
alphabetical sorting is an issue here already for a different reason.
But applications might do it, I guess?)
Best
Gottfried
[1] https://www.raspberrypi.org/learning/physical-computing-with-python/worksheet/
[2] https://pinout.xyz/pinout/
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
[not found] <CAPoCmYJC1TebBrspD_=mTETULSjg9or5a0Yda8p945y6ZWL99Q@mail.gmail.com>
@ 2016-10-19 3:25 ` Eric Anholt
2016-10-20 16:28 ` Linus Walleij
1 sibling, 0 replies; 8+ messages in thread
From: Eric Anholt @ 2016-10-19 3:25 UTC (permalink / raw)
To: linux-arm-kernel
Gottfried Haider <gottfried.haider@gmail.com> writes:
> Hi Eric, Linus,
>
> I'll hopefully find time to look at the more recent changes to the gpio
> subsystem (lsgpio?!), but since this patch is up for discussion now - what
> I was wondering: how does this change relate to /sys/class/gpio/gpio%d? Is
> this completely orthogonal - or would this change the sysfs interface as
> well?
>
> Regarding the proposed format using the header pin numbers: From what I've
> seen in terms of existing educational materials, it seems the overwhelming
> majority ends up using GPIO numbers instead of physical pin header
> numbering. (e.g. [1] [2])
> Would it be too confusing to try to pick GPIO 5 from an alphabetically
> sorted list like this "P11_GPIO17", "P12_GPIO18"? (I know, alphabetical
> sorting is an issue here already for a different reason. But applications
> might do it, I guess?)
I added the pin numbers because it was a consistent response to the
first version. I do think the GPIO numbers without pin numbers would be
the most clear.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161018/cae67ff7/attachment.sig>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
2016-10-18 16:38 [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines Eric Anholt
@ 2016-10-19 12:16 ` Linus Walleij
0 siblings, 0 replies; 8+ messages in thread
From: Linus Walleij @ 2016-10-19 12:16 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Oct 18, 2016 at 6:38 PM, Eric Anholt <eric@anholt.net> wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> The idea is to give useful names to GPIO lines that an implementer
> will be using from userspace, e.g. for maker type projects. These are
> user-visible using tools/gpio/lsgpio.c
>
> v2: Major rewrite by anholt: Flatten each GPIO line to a line in the
> file for better diffing, prefix all expansion header pins with
> "P<number>" or "P5HEADER_P<number>" and drop the mostly-unused
> GPIO_GEN<smallnumber> names in favor of GPIO<socgpionumber>, fix
> extra '[]' on a couple of lines, fix locations of SD_CARD_DETECT,
> CAM_GPIO and STATUS_LED, fix HDMI_HPD polarities, rewrite A+ using
> unreleased schematics.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Eric Anholt <eric@anholt.net>
Generally looks good!
I fully trust your usage of he Pnn_* prefix, I assume this
makes a lot of sense to RPi users.
> Note: I haven't actually booted these and checked that the names line
> up, just tried to visually review them. Hopefully with more
> GPIO<number> values, it's easier to spot errors.
>
> The only other thing here I think I would do is drop the [] around
> names for behavior when pinmuxed. I find it more confusing than
> helpful.
I added this on the 96board HiKey instead of just leaving it blank.
The idea was to distinguish somehow between GPIO proper and
a GPIO line that is actually not used as GPIO. It is only really
reflecting the schematic, so whatever makes sense for someone
familiar with the schematics apply.
I think it is up to the .dts file maintainer to decide. May even be
different things that make sense on different boards.
> Linus, are these names considered ABI? Will we be locked into
> whatever set of names we merge and release? My assumption would be
> "yes".
It is ABI if there is a userspace making use of it. So once libs
like libmraa (is that the name?) and similar things that do userspace
GPIO start using it, it becomes ABI.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
[not found] <CAPoCmYJC1TebBrspD_=mTETULSjg9or5a0Yda8p945y6ZWL99Q@mail.gmail.com>
2016-10-19 3:25 ` Eric Anholt
@ 2016-10-20 16:28 ` Linus Walleij
2016-10-20 16:58 ` Gottfried Haider
2016-10-20 17:04 ` Eric Anholt
1 sibling, 2 replies; 8+ messages in thread
From: Linus Walleij @ 2016-10-20 16:28 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Oct 18, 2016 at 10:44 PM, Gottfried Haider
<gottfried.haider@gmail.com wrote:
> I'll hopefully find time to look at the more recent changes to the gpio
> subsystem (lsgpio?!), but since this patch is up for discussion now - what I
> was wondering: how does this change relate to /sys/class/gpio/gpio%d? Is
> this completely orthogonal - or would this change the sysfs interface as
> well?
The old sysfs interface is not changing. However it is deprecated so once
you have a v4.8+ kernel, consider migrating whatever userspace you have
to use the chardev ABI instead.
See:
commit fe95046e960b4b76e73dc1486955d93f47276134
"gpio: ABI: mark the sysfs ABI as obsolete"
commit 521a2ad6f862a28e2e43cb3e254a26bf0f9452e9
"gpio: add userspace ABI for GPIO line information"
commit d7c51b47ac11e66f547b55640405c1c474642d72
"gpio: userspace ABI for reading/writing GPIO lines"
commit 61f922db72216b00386581c851db9c9095961522
"gpio: userspace ABI for reading GPIO line events"
> Regarding the proposed format using the header pin numbers: From what I've
> seen in terms of existing educational materials, it seems the overwhelming
> majority ends up using GPIO numbers instead of physical pin header
> numbering. (e.g. [1] [2])
What does that number mean? If you are referring to the global
GPIO numberspace it is obsolete and just reflecting the fact that
people up until now was referring to Linux-internal GPIO numbers.
> Would it be too confusing to try to pick GPIO 5 from an alphabetically
> sorted list like this "P11_GPIO17", "P12_GPIO18"? (I know, alphabetical
> sorting is an issue here already for a different reason. But applications
> might do it, I guess?)
Any attempt to preserve the global GPIO numberspace is futile.
If it is the local offset number on the chip it is another thing, that
is kind of OK if the arch maintainer likes it.
Global GPIO numbers are inherently inconsistent since the introduction
of deferred probe, as GPIO drivers often pick a dynamic number base
and thus end up with the same number even though that can depend on
things like cosmic radiation or the temperature of their board when
they boot. So global GPIO numbers are considered harmful and have
therefore been obsoleted as userspace ABI.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
2016-10-20 16:28 ` Linus Walleij
@ 2016-10-20 16:58 ` Gottfried Haider
2016-10-24 0:13 ` Linus Walleij
2016-10-20 17:04 ` Eric Anholt
1 sibling, 1 reply; 8+ messages in thread
From: Gottfried Haider @ 2016-10-20 16:58 UTC (permalink / raw)
To: linux-arm-kernel
> The old sysfs interface is not changing. However it is deprecated so once
> you have a v4.8+ kernel, consider migrating whatever userspace you have
> to use the chardev ABI instead.
>
> See:
> commit fe95046e960b4b76e73dc1486955d93f47276134
> "gpio: ABI: mark the sysfs ABI as obsolete"
> commit 521a2ad6f862a28e2e43cb3e254a26bf0f9452e9
> "gpio: add userspace ABI for GPIO line information"
> commit d7c51b47ac11e66f547b55640405c1c474642d72
> "gpio: userspace ABI for reading/writing GPIO lines"
> commit 61f922db72216b00386581c851db9c9095961522
> "gpio: userspace ABI for reading GPIO line events"
Thanks for those pointers. Somewhat off topic: is it planned to add
support for setting GENERIC_PINCONF style pull-up/pull-down resistors
throigh the new ABI? (The bcm28xx drivers would still need to
converted to this as well.)
>> Regarding the proposed format using the header pin numbers: From what I've
>> seen in terms of existing educational materials, it seems the overwhelming
>> majority ends up using GPIO numbers instead of physical pin header
>> numbering. (e.g. [1] [2])
>
> What does that number mean? If you are referring to the global
> GPIO numberspace it is obsolete and just reflecting the fact that
> people up until now was referring to Linux-internal GPIO numbers.
I am referring to the name of the various GPIO lines as per datasheet
("GPIO0", "GPIO1", ...). So far, I believe those matched the global
GPIO numberspace.
>> Would it be too confusing to try to pick GPIO 5 from an alphabetically
>> sorted list like this "P11_GPIO17", "P12_GPIO18"? (I know, alphabetical
>> sorting is an issue here already for a different reason. But applications
>> might do it, I guess?)
>
> Any attempt to preserve the global GPIO numberspace is futile.
> If it is the local offset number on the chip it is another thing, that
> is kind of OK if the arch maintainer likes it.
I understand that Linux can't guarantee a certain global GPIO number -
but I fear that the board manufacturers also might not think of the
pin headers as something set in stone (that the can't rearrange in a
future revision/product).
Would there be a reason against _naming_ the pin "GPIO0"? (even if it
ends up with a different global, internal number)
Thanks & best
Gottfried
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
2016-10-20 16:28 ` Linus Walleij
2016-10-20 16:58 ` Gottfried Haider
@ 2016-10-20 17:04 ` Eric Anholt
1 sibling, 0 replies; 8+ messages in thread
From: Eric Anholt @ 2016-10-20 17:04 UTC (permalink / raw)
To: linux-arm-kernel
Linus Walleij <linus.walleij@linaro.org> writes:
> On Tue, Oct 18, 2016 at 10:44 PM, Gottfried Haider
> <gottfried.haider@gmail.com wrote:
>
>> Regarding the proposed format using the header pin numbers: From what I've
>> seen in terms of existing educational materials, it seems the overwhelming
>> majority ends up using GPIO numbers instead of physical pin header
>> numbering. (e.g. [1] [2])
>
> What does that number mean? If you are referring to the global
> GPIO numberspace it is obsolete and just reflecting the fact that
> people up until now was referring to Linux-internal GPIO numbers.
The number within the SOC's GPIOs. Until the 8-line expander that's
been hung off the SOC GPIOs in the Pi3, they were the only GPIOs in the
system.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/3bd2a4ea/attachment.sig>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
2016-10-20 16:58 ` Gottfried Haider
@ 2016-10-24 0:13 ` Linus Walleij
0 siblings, 0 replies; 8+ messages in thread
From: Linus Walleij @ 2016-10-24 0:13 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Oct 20, 2016 at 6:58 PM, Gottfried Haider
<gottfried.haider@gmail.com> wrote:
> Somewhat off topic: is it planned to add
> support for setting GENERIC_PINCONF style pull-up/pull-down resistors
> throigh the new ABI?
Not planned, as in "I will do the job" but anticipated.
I expect that someone will come up with that usecase (indeed even the
Arduino is doing it) so that we will have to support it.
It's better than inventing a separate userspace ABI for pin control
anyways.
> (The bcm28xx drivers would still need to
> converted to this as well.)
All drivers that want to support it need converting I suspect.
>>> Regarding the proposed format using the header pin numbers: From what I've
>>> seen in terms of existing educational materials, it seems the overwhelming
>>> majority ends up using GPIO numbers instead of physical pin header
>>> numbering. (e.g. [1] [2])
>>
>> What does that number mean? If you are referring to the global
>> GPIO numberspace it is obsolete and just reflecting the fact that
>> people up until now was referring to Linux-internal GPIO numbers.
>
> I am referring to the name of the various GPIO lines as per datasheet
> ("GPIO0", "GPIO1", ...). So far, I believe those matched the global
> GPIO numberspace.
Aha. Yeah that is matching somewhat by chance these days, because:
static struct gpio_chip bcm2835_gpio_chip = {
.label = MODULE_NAME,
(...)
.base = -1,
(...)
};
That means this number is dynamicallly assigned and depend on
things like probe order or another GPIO chip failing etc.
> I understand that Linux can't guarantee a certain global GPIO number -
> but I fear that the board manufacturers also might not think of the
> pin headers as something set in stone (that the can't rearrange in a
> future revision/product).
Depends on which manufacturer. For 96boards there exist a document
specifying how they should be arranged and named:
https://github.com/96boards/documentation
Rpi would be wise to come up with something similar, but I have no
high hopes. We do need standardization and interoperability, but
it is not creating itself. :/
> Would there be a reason against _naming_ the pin "GPIO0"? (even if it
> ends up with a different global, internal number)
No not if it makes electronic sense, like if the schematic or SoC
uses that name, then use that if the board maintainer likes the idea.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-10-24 0:13 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-18 16:38 [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines Eric Anholt
2016-10-19 12:16 ` Linus Walleij
-- strict thread matches above, loose matches on Subject: below --
2016-10-18 20:48 Gottfried Haider
[not found] <CAPoCmYJC1TebBrspD_=mTETULSjg9or5a0Yda8p945y6ZWL99Q@mail.gmail.com>
2016-10-19 3:25 ` Eric Anholt
2016-10-20 16:28 ` Linus Walleij
2016-10-20 16:58 ` Gottfried Haider
2016-10-24 0:13 ` Linus Walleij
2016-10-20 17:04 ` Eric Anholt
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).