| Message ID | 20171027202148.4188-1-ard.biesheuvel@linaro.org |
|---|---|
| Headers | show |
| Series | GPIO support for Socionext Synquacer | expand |
On Fri, Oct 27, 2017 at 10:21 PM, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > The Socionext Synquacer SC2A11, which is used in the arm64 Developer Box, > shares its GPIO IP with a Fujitsu SoC for which we already have support > in the tree. So let's tweak it so that we can reuse it. > > Cc: Linus Walleij <linus.walleij@linaro.org> > > Ard Biesheuvel (2): > gpio: mb86s7x: share with other SoCs as module > gpio: mb86s70: Revert "Return error if requesting an already assigned > gpio" Nice. We might need to look into the following wrt this driver: - Using generic MMIO GPIO, i.e. select GPIO_GENERIC in Kconfig and a patch such as commit 6d125412fc16802012a17665638f49b0b0c81f18 "gpio: iop: Use generic GPIO MMIO functions for driver" apart from reduced code size this brings the .get_multiple() and .set_multiple() callbacks for FREE. The fact that the driver is so simple that it should have been using MMIO/GENERIC GPIO is a plain oversight during review. - When submitting the DTS for that developer box, make sure that the 96boards header has proper GPIO line names from day 1, see e.g. commit bbaf867e2d3796bca465d07ffcd800a3bd570861 "arm64: dts: hikey: name the GPIO lines" Ard: if you have this machine on your desk help with the above would be much appreciated (plus it's fun!) thanks a bunch :) 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 31 October 2017 at 12:20, Linus Walleij <linus.walleij@linaro.org> wrote: > On Fri, Oct 27, 2017 at 10:21 PM, Ard Biesheuvel > <ard.biesheuvel@linaro.org> wrote: > >> The Socionext Synquacer SC2A11, which is used in the arm64 Developer Box, >> shares its GPIO IP with a Fujitsu SoC for which we already have support >> in the tree. So let's tweak it so that we can reuse it. >> >> Cc: Linus Walleij <linus.walleij@linaro.org> >> >> Ard Biesheuvel (2): >> gpio: mb86s7x: share with other SoCs as module >> gpio: mb86s70: Revert "Return error if requesting an already assigned >> gpio" > > Nice. We might need to look into the following wrt this driver: > > - Using generic MMIO GPIO, i.e. select GPIO_GENERIC in Kconfig > and a patch such as commit 6d125412fc16802012a17665638f49b0b0c81f18 > "gpio: iop: Use generic GPIO MMIO functions for driver" > apart from reduced code size this brings the .get_multiple() and > .set_multiple() callbacks for FREE. > The fact that the driver is so simple that it should have been using > MMIO/GENERIC GPIO is a plain oversight during review. > Does this work with the layout if this chip? It has 32 GPIO lines, whose controls are mapped onto the lowest 8 bits of 4 adjacent 32-bit registers. > - When submitting the DTS for that developer box, make sure that > the 96boards header has proper GPIO line names from day 1, > see e.g. > commit bbaf867e2d3796bca465d07ffcd800a3bd570861 > "arm64: dts: hikey: name the GPIO lines" > I currently have this in my DTS: &gpio { dsw3_1 { gpios = <0 GPIO_ACTIVE_HIGH>; gpio-hog; input; }; dsw3_2 { gpios = <1 GPIO_ACTIVE_HIGH>; gpio-hog; input; }; dsw3_3 { gpios = <2 GPIO_ACTIVE_HIGH>; gpio-hog; input; }; dsw3_4 { gpios = <3 GPIO_ACTIVE_HIGH>; gpio-hog; input; }; dsw3_5 { gpios = <4 GPIO_ACTIVE_HIGH>; gpio-hog; input; }; dsw3_6 { gpios = <5 GPIO_ACTIVE_HIGH>; gpio-hog; input; }; dsw3_7 { gpios = <6 GPIO_ACTIVE_HIGH>; gpio-hog; input; }; dsw3_8 { gpios = <7 GPIO_ACTIVE_HIGH>; gpio-hog; input; }; for the 8 DIP switches that are connected to GPIO lines. There are more assigned, to various function, and 8 of them are routed to the 96boards low speed connector as well. > Ard: if you have this machine on your desk help with the above would > be much appreciated (plus it's fun!) thanks a bunch :) > Of course, if you help me understand it :-) So I can add the names for all the lines that have a purpose, but is that orthogonal to hogging? -- 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 31 October 2017 at 12:27, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > On 31 October 2017 at 12:20, Linus Walleij <linus.walleij@linaro.org> wrote: >> On Fri, Oct 27, 2017 at 10:21 PM, Ard Biesheuvel >> <ard.biesheuvel@linaro.org> wrote: >> >>> The Socionext Synquacer SC2A11, which is used in the arm64 Developer Box, >>> shares its GPIO IP with a Fujitsu SoC for which we already have support >>> in the tree. So let's tweak it so that we can reuse it. >>> >>> Cc: Linus Walleij <linus.walleij@linaro.org> >>> >>> Ard Biesheuvel (2): >>> gpio: mb86s7x: share with other SoCs as module >>> gpio: mb86s70: Revert "Return error if requesting an already assigned >>> gpio" >> >> Nice. We might need to look into the following wrt this driver: >> >> - Using generic MMIO GPIO, i.e. select GPIO_GENERIC in Kconfig >> and a patch such as commit 6d125412fc16802012a17665638f49b0b0c81f18 >> "gpio: iop: Use generic GPIO MMIO functions for driver" >> apart from reduced code size this brings the .get_multiple() and >> .set_multiple() callbacks for FREE. >> The fact that the driver is so simple that it should have been using >> MMIO/GENERIC GPIO is a plain oversight during review. >> > > Does this work with the layout if this chip? It has 32 GPIO lines, > whose controls are mapped onto the lowest 8 bits of 4 adjacent 32-bit > registers. > >> - When submitting the DTS for that developer box, make sure that >> the 96boards header has proper GPIO line names from day 1, >> see e.g. >> commit bbaf867e2d3796bca465d07ffcd800a3bd570861 >> "arm64: dts: hikey: name the GPIO lines" >> > > I currently have this in my DTS: > > &gpio { > dsw3_1 { > gpios = <0 GPIO_ACTIVE_HIGH>; > gpio-hog; > input; > }; > > dsw3_2 { > gpios = <1 GPIO_ACTIVE_HIGH>; > gpio-hog; > input; > }; > > dsw3_3 { > gpios = <2 GPIO_ACTIVE_HIGH>; > gpio-hog; > input; > }; > > dsw3_4 { > gpios = <3 GPIO_ACTIVE_HIGH>; > gpio-hog; > input; > }; > > dsw3_5 { > gpios = <4 GPIO_ACTIVE_HIGH>; > gpio-hog; > input; > }; > > dsw3_6 { > gpios = <5 GPIO_ACTIVE_HIGH>; > gpio-hog; > input; > }; > > dsw3_7 { > gpios = <6 GPIO_ACTIVE_HIGH>; > gpio-hog; > input; > }; > > dsw3_8 { > gpios = <7 GPIO_ACTIVE_HIGH>; > gpio-hog; > input; > }; > > for the 8 DIP switches that are connected to GPIO lines. There are > more assigned, to various function, and 8 of them are routed to the > 96boards low speed connector as well. > >> Ard: if you have this machine on your desk help with the above would >> be much appreciated (plus it's fun!) thanks a bunch :) >> > > Of course, if you help me understand it :-) > > So I can add the names for all the lines that have a purpose, but is > that orthogonal to hogging? OK, so i now have # cat /sys/kernel/debug/gpio gpiochip0: GPIOs 480-511, parent: platform/51000000.gpio, 51000000.gpio: gpio-480 (DSW3-PIN1 |dsw3_1 ) in lo gpio-481 (DSW3-PIN2 |dsw3_2 ) in lo gpio-482 (DSW3-PIN3 |dsw3_3 ) in lo gpio-483 (DSW3-PIN4 |dsw3_4 ) in hi gpio-484 (DSW3-PIN5 |dsw3_5 ) in hi gpio-485 (DSW3-PIN6 |dsw3_6 ) in lo gpio-486 (DSW3-PIN7 |dsw3_7 ) in lo gpio-487 (DSW3-PIN8 |dsw3_8 ) in lo gpio-488 (NC ) gpio-489 (PWROFF# ) gpio-490 (GPIO-A ) gpio-491 (GPIO-B ) gpio-492 (GPIO-C ) gpio-493 (GPIO-D ) gpio-494 (PCIE1EXTINT ) gpio-495 (PCIE0EXTINT ) gpio-496 (PHY2-INT# ) gpio-497 (PHY1-INT# ) gpio-498 (GPIO-E ) gpio-499 (GPIO-F ) gpio-500 (GPIO-G ) gpio-501 (GPIO-H ) gpio-502 (GPIO-I ) gpio-503 (GPIO-J ) gpio-504 (GPIO-K ) gpio-505 (GPIO-L ) gpio-506 (PEC-PD26 ) gpio-507 (PEC-PD27 ) gpio-508 (PEC-PD28 ) gpio-509 (PEC-PD29 ) gpio-510 (PEC-PD30 ) gpio-511 (PEC-PD31 ) after adding this gpio-line-names = "DSW3-PIN1", "DSW3-PIN2", "DSW3-PIN3", "DSW3-PIN4", "DSW3-PIN5", "DSW3-PIN6", "DSW3-PIN7", "DSW3-PIN8", "NC", "PWROFF#", "GPIO-A", "GPIO-B", "GPIO-C", "GPIO-D", "PCIE1EXTINT", "PCIE0EXTINT", "PHY2-INT#", "PHY1-INT#", "GPIO-E", "GPIO-F", "GPIO-G", "GPIO-H", "GPIO-I", "GPIO-J", "GPIO-K", "GPIO-L", "PEC-PD26", "PEC-PD27", "PEC-PD28", "PEC-PD29", "PEC-PD30", "PEC-PD31"; to the DT node of the GPIO controller. -- 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 Tue, Oct 31, 2017 at 1:59 PM, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > OK, so i now have > > # cat /sys/kernel/debug/gpio "lsgpio" from tools/gpio/lsgpio.c is even nicer, but OK :) > gpiochip0: GPIOs 480-511, parent: platform/51000000.gpio, 51000000.gpio: > gpio-480 (DSW3-PIN1 |dsw3_1 ) in lo > gpio-481 (DSW3-PIN2 |dsw3_2 ) in lo > gpio-482 (DSW3-PIN3 |dsw3_3 ) in lo > gpio-483 (DSW3-PIN4 |dsw3_4 ) in hi > gpio-484 (DSW3-PIN5 |dsw3_5 ) in hi > gpio-485 (DSW3-PIN6 |dsw3_6 ) in lo > gpio-486 (DSW3-PIN7 |dsw3_7 ) in lo > gpio-487 (DSW3-PIN8 |dsw3_8 ) in lo > gpio-488 (NC ) > gpio-489 (PWROFF# ) > gpio-490 (GPIO-A ) > gpio-491 (GPIO-B ) > gpio-492 (GPIO-C ) > gpio-493 (GPIO-D ) > gpio-494 (PCIE1EXTINT ) > gpio-495 (PCIE0EXTINT ) > gpio-496 (PHY2-INT# ) > gpio-497 (PHY1-INT# ) > gpio-498 (GPIO-E ) > gpio-499 (GPIO-F ) > gpio-500 (GPIO-G ) > gpio-501 (GPIO-H ) > gpio-502 (GPIO-I ) > gpio-503 (GPIO-J ) > gpio-504 (GPIO-K ) > gpio-505 (GPIO-L ) > gpio-506 (PEC-PD26 ) > gpio-507 (PEC-PD27 ) > gpio-508 (PEC-PD28 ) > gpio-509 (PEC-PD29 ) > gpio-510 (PEC-PD30 ) > gpio-511 (PEC-PD31 ) > > after adding this > > gpio-line-names = "DSW3-PIN1", "DSW3-PIN2", "DSW3-PIN3", "DSW3-PIN4", > "DSW3-PIN5", "DSW3-PIN6", "DSW3-PIN7", "DSW3-PIN8", > "NC", "PWROFF#", > "GPIO-A", "GPIO-B", "GPIO-C", "GPIO-D", > "PCIE1EXTINT", "PCIE0EXTINT", > "PHY2-INT#", "PHY1-INT#", > "GPIO-E", "GPIO-F", "GPIO-G", "GPIO-H", > "GPIO-I", "GPIO-J", "GPIO-K", "GPIO-L", > "PEC-PD26", "PEC-PD27", "PEC-PD28", > "PEC-PD29", "PEC-PD30", "PEC-PD31"; > > to the DT node of the GPIO controller. Perfect. Proper naming of GPIO-A thru L gives userspace an easy time to get a grip on the right GPIO line on the Low Speed Connector. Acked-by: Linus Walleij <linus.walleij@linaro.org> 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 Tue, Oct 31, 2017 at 1:27 PM, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > I currently have this in my DTS: > > &gpio { > dsw3_1 { > gpios = <0 GPIO_ACTIVE_HIGH>; > gpio-hog; > input; > }; > > dsw3_2 { > gpios = <1 GPIO_ACTIVE_HIGH>; > gpio-hog; > input; > }; > > dsw3_3 { > gpios = <2 GPIO_ACTIVE_HIGH>; > gpio-hog; > input; > }; > > dsw3_4 { > gpios = <3 GPIO_ACTIVE_HIGH>; > gpio-hog; > input; > }; > > dsw3_5 { > gpios = <4 GPIO_ACTIVE_HIGH>; > gpio-hog; > input; > }; > > dsw3_6 { > gpios = <5 GPIO_ACTIVE_HIGH>; > gpio-hog; > input; > }; > > dsw3_7 { > gpios = <6 GPIO_ACTIVE_HIGH>; > gpio-hog; > input; > }; > > dsw3_8 { > gpios = <7 GPIO_ACTIVE_HIGH>; > gpio-hog; > input; > }; > > for the 8 DIP switches that are connected to GPIO lines. I have no idea how to make proper use of DIP switches really. We *could* route them as inputs using GPIO keys, but it would maybe give people the idea that it is a good idea to start prying them at runtime. If they don't have a usecase I would just leave them as this. I guess/hope they will not be used by userspace either. > So I can add the names for all the lines that have a purpose, but is > that orthogonal to hogging? Naming is orthogonal to hogging and should be a functional name for the line, preferably header name, else rail name or something else reasonable. 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 31 October 2017 at 13:13, Linus Walleij <linus.walleij@linaro.org> wrote: > On Tue, Oct 31, 2017 at 1:27 PM, Ard Biesheuvel > <ard.biesheuvel@linaro.org> wrote: > >> I currently have this in my DTS: >> >> &gpio { >> dsw3_1 { >> gpios = <0 GPIO_ACTIVE_HIGH>; >> gpio-hog; >> input; >> }; >> >> dsw3_2 { >> gpios = <1 GPIO_ACTIVE_HIGH>; >> gpio-hog; >> input; >> }; >> >> dsw3_3 { >> gpios = <2 GPIO_ACTIVE_HIGH>; >> gpio-hog; >> input; >> }; >> >> dsw3_4 { >> gpios = <3 GPIO_ACTIVE_HIGH>; >> gpio-hog; >> input; >> }; >> >> dsw3_5 { >> gpios = <4 GPIO_ACTIVE_HIGH>; >> gpio-hog; >> input; >> }; >> >> dsw3_6 { >> gpios = <5 GPIO_ACTIVE_HIGH>; >> gpio-hog; >> input; >> }; >> >> dsw3_7 { >> gpios = <6 GPIO_ACTIVE_HIGH>; >> gpio-hog; >> input; >> }; >> >> dsw3_8 { >> gpios = <7 GPIO_ACTIVE_HIGH>; >> gpio-hog; >> input; >> }; >> >> for the 8 DIP switches that are connected to GPIO lines. > > I have no idea how to make proper use of DIP switches really. > We *could* route them as inputs using GPIO keys, but it would > maybe give people the idea that it is a good idea to start > prying them at runtime. > > If they don't have a usecase I would just leave them as this. > > I guess/hope they will not be used by userspace either. > Not a clue. I guess I can remove the hogs, and simply describe them using the names. They are probably more useful at boot time, i.e., to clear the NVRAM and to en/disable secure boot etc. >> So I can add the names for all the lines that have a purpose, but is >> that orthogonal to hogging? > > Naming is orthogonal to hogging and should be a functional name > for the line, preferably header name, else rail name or something > else reasonable. -- 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 Tue, Oct 31, 2017 at 1:27 PM, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > On 31 October 2017 at 12:20, Linus Walleij <linus.walleij@linaro.org> wrote: >> On Fri, Oct 27, 2017 at 10:21 PM, Ard Biesheuvel >> <ard.biesheuvel@linaro.org> wrote: >> >>> The Socionext Synquacer SC2A11, which is used in the arm64 Developer Box, >>> shares its GPIO IP with a Fujitsu SoC for which we already have support >>> in the tree. So let's tweak it so that we can reuse it. >>> >>> Cc: Linus Walleij <linus.walleij@linaro.org> >>> >>> Ard Biesheuvel (2): >>> gpio: mb86s7x: share with other SoCs as module >>> gpio: mb86s70: Revert "Return error if requesting an already assigned >>> gpio" >> >> Nice. We might need to look into the following wrt this driver: >> >> - Using generic MMIO GPIO, i.e. select GPIO_GENERIC in Kconfig >> and a patch such as commit 6d125412fc16802012a17665638f49b0b0c81f18 >> "gpio: iop: Use generic GPIO MMIO functions for driver" >> apart from reduced code size this brings the .get_multiple() and >> .set_multiple() callbacks for FREE. >> The fact that the driver is so simple that it should have been using >> MMIO/GENERIC GPIO is a plain oversight during review. > > Does this work with the layout if this chip? It has 32 GPIO lines, > whose controls are mapped onto the lowest 8 bits of 4 adjacent 32-bit > registers. I didn't look close enough. No GPIO MMIO is just for simple 1:1 mapping of say 32 bits, so it won't work. There is opportunity to exploit [get|set]_multiple() callbacks for any bits that end up in the same group of 8 though, but it requires some elaborate code for just this driver. It does make for a nice 8-line oscilloscope to sample all 8 lines simultaneously with .get_multiple() for example. But that is just optimization. If you have the datasheet, also check if the block is really this simple and whether it maybe actually supports some pin config like open drain or debounce etc, we have support for that as well these days using .set_config() in the drivers. 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
The Socionext Synquacer SC2A11, which is used in the arm64 Developer Box, shares its GPIO IP with a Fujitsu SoC for which we already have support in the tree. So let's tweak it so that we can reuse it. Cc: Linus Walleij <linus.walleij@linaro.org> Ard Biesheuvel (2): gpio: mb86s7x: share with other SoCs as module gpio: mb86s70: Revert "Return error if requesting an already assigned gpio" drivers/gpio/Kconfig | 3 +-- drivers/gpio/gpio-mb86s7x.c | 17 +++++++++++------ 2 files changed, 12 insertions(+), 8 deletions(-) -- 2.11.0 -- 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