Hi all,
As GPIO hogs are configured at GPIO controller initialization time,
adding/removing GPIO hogs in Device Tree overlays currently does not
work. Hence this patch series adds support for that, by registering an
of_reconfig notifier, as is already done for platform, i2c, and SPI
devices.
Perhaps this would be better served through a pinctrl-gpio driver?
Pinctrl is already working fine with DT overlays, as the pinctrl-*
properties are part of the slave device node, and thus looked up at
slave device node attachment time, not at pin controller initialization
time.
In my particular use case (talking to SPI devices connected to a PMOD
connector on the RSK+RZA1 development board), the GPIO performs board
level muxing of a.o. the SPI MOSI/MISO/SCK signals. Hence the hog
really needs to be active only while talking to the SPI device, so the
muxing could (in theory) be done upon demand.
But how to describe that in DT, and implement it (using Runtime PM?)?
Thanks for your comments!
Geert Uytterhoeven (2):
gpio: of: Extract of_gpiochip_add_hog()
gpio: of: Add DT overlay support for GPIO hogs
drivers/gpio/gpiolib-of.c | 133 +++++++++++++++++++++++++++++++++-----
drivers/gpio/gpiolib-of.h | 2 +
drivers/gpio/gpiolib.c | 14 +++-
drivers/gpio/gpiolib.h | 3 +
4 files changed, 133 insertions(+), 19 deletions(-)
--
2.17.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
pon., 30 gru 2019 o 14:38 Geert Uytterhoeven <[email protected]>
napisał(a):
>
> Hi all,
>
> As GPIO hogs are configured at GPIO controller initialization time,
> adding/removing GPIO hogs in Device Tree overlays currently does not
> work. Hence this patch series adds support for that, by registering an
> of_reconfig notifier, as is already done for platform, i2c, and SPI
> devices.
>
> Perhaps this would be better served through a pinctrl-gpio driver?
> Pinctrl is already working fine with DT overlays, as the pinctrl-*
> properties are part of the slave device node, and thus looked up at
> slave device node attachment time, not at pin controller initialization
> time.
>
> In my particular use case (talking to SPI devices connected to a PMOD
> connector on the RSK+RZA1 development board), the GPIO performs board
> level muxing of a.o. the SPI MOSI/MISO/SCK signals. Hence the hog
> really needs to be active only while talking to the SPI device, so the
> muxing could (in theory) be done upon demand.
> But how to describe that in DT, and implement it (using Runtime PM?)?
>
I may be missing the whole picture, but from your description this
sounds like a job for the mux framework. Maybe we could make runtime
PM aware of muxing for this type of use-cases?
Bart
On 12/30/19 7:38 AM, Geert Uytterhoeven wrote:
> Hi all,
>
> As GPIO hogs are configured at GPIO controller initialization time,
> adding/removing GPIO hogs in Device Tree overlays currently does not
> work. Hence this patch series adds support for that, by registering an
> of_reconfig notifier, as is already done for platform, i2c, and SPI
> devices.
>
> Perhaps this would be better served through a pinctrl-gpio driver?
> Pinctrl is already working fine with DT overlays, as the pinctrl-*
> properties are part of the slave device node, and thus looked up at
> slave device node attachment time, not at pin controller initialization
> time.
>
> In my particular use case (talking to SPI devices connected to a PMOD
> connector on the RSK+RZA1 development board), the GPIO performs board
> level muxing of a.o. the SPI MOSI/MISO/SCK signals. Hence the hog
> really needs to be active only while talking to the SPI device, so the
> muxing could (in theory) be done upon demand.
> But how to describe that in DT, and implement it (using Runtime PM?)?
I'm trying to understand the use case. I can easily imagine two cases:
(1) want to configure the GPIO to be able to use the SPI bus sometimes,
but configure the GPIO differently when not using the SPI bus
(2) want to describe a device on the SPI bus in an overlay, thus
also needing to describe the associate gpio hog node in the
same overlay
For use case (2), the proposed patch seems to be a good solution.
For use case (1), this is a case of trying to use devicetree as a
way to control configuration instead of describing the hardware.
In this case, Bartosz' reply may indicate the way forward.
I'll assume use case (2) for patch comments.
>
> Thanks for your comments!
>
> Geert Uytterhoeven (2):
> gpio: of: Extract of_gpiochip_add_hog()
> gpio: of: Add DT overlay support for GPIO hogs
>
> drivers/gpio/gpiolib-of.c | 133 +++++++++++++++++++++++++++++++++-----
> drivers/gpio/gpiolib-of.h | 2 +
> drivers/gpio/gpiolib.c | 14 +++-
> drivers/gpio/gpiolib.h | 3 +
> 4 files changed, 133 insertions(+), 19 deletions(-)
>
Hi Bartosz,
On Fri, Jan 3, 2020 at 10:51 AM Bartosz Golaszewski
<[email protected]> wrote:
> pon., 30 gru 2019 o 14:38 Geert Uytterhoeven <[email protected]>
> napisał(a):
> > As GPIO hogs are configured at GPIO controller initialization time,
> > adding/removing GPIO hogs in Device Tree overlays currently does not
> > work. Hence this patch series adds support for that, by registering an
> > of_reconfig notifier, as is already done for platform, i2c, and SPI
> > devices.
> >
> > Perhaps this would be better served through a pinctrl-gpio driver?
> > Pinctrl is already working fine with DT overlays, as the pinctrl-*
> > properties are part of the slave device node, and thus looked up at
> > slave device node attachment time, not at pin controller initialization
> > time.
> >
> > In my particular use case (talking to SPI devices connected to a PMOD
> > connector on the RSK+RZA1 development board), the GPIO performs board
> > level muxing of a.o. the SPI MOSI/MISO/SCK signals. Hence the hog
> > really needs to be active only while talking to the SPI device, so the
> > muxing could (in theory) be done upon demand.
> > But how to describe that in DT, and implement it (using Runtime PM?)?
>
> I may be missing the whole picture, but from your description this
> sounds like a job for the mux framework. Maybe we could make runtime
> PM aware of muxing for this type of use-cases?
I'm happy with a (static) GPIO hog.
BTW, what exactly do you mean with "mux framework"? Pinctrl/pinmux?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Frank,
On Tue, Jan 7, 2020 at 12:34 AM Frank Rowand <[email protected]> wrote:
> On 12/30/19 7:38 AM, Geert Uytterhoeven wrote:
> > As GPIO hogs are configured at GPIO controller initialization time,
> > adding/removing GPIO hogs in Device Tree overlays currently does not
> > work. Hence this patch series adds support for that, by registering an
> > of_reconfig notifier, as is already done for platform, i2c, and SPI
> > devices.
> >
> > Perhaps this would be better served through a pinctrl-gpio driver?
> > Pinctrl is already working fine with DT overlays, as the pinctrl-*
> > properties are part of the slave device node, and thus looked up at
> > slave device node attachment time, not at pin controller initialization
> > time.
> >
> > In my particular use case (talking to SPI devices connected to a PMOD
> > connector on the RSK+RZA1 development board), the GPIO performs board
> > level muxing of a.o. the SPI MOSI/MISO/SCK signals. Hence the hog
> > really needs to be active only while talking to the SPI device, so the
> > muxing could (in theory) be done upon demand.
> > But how to describe that in DT, and implement it (using Runtime PM?)?
>
> I'm trying to understand the use case. I can easily imagine two cases:
>
> (1) want to configure the GPIO to be able to use the SPI bus sometimes,
> but configure the GPIO differently when not using the SPI bus
>
> (2) want to describe a device on the SPI bus in an overlay, thus
> also needing to describe the associate gpio hog node in the
> same overlay
>
> For use case (2), the proposed patch seems to be a good solution.
>
> For use case (1), this is a case of trying to use devicetree as a
> way to control configuration instead of describing the hardware.
> In this case, Bartosz' reply may indicate the way forward.
>
> I'll assume use case (2) for patch comments.
Yes, my main interest is use case (2).
I have no plans to pursue use case (1).
However, I have some more comments and questions for use case (1).
Before you can control configuration, you have to describe the hardware.
Hence isn't that a job for DT?
Furthermore, I'd like you to step back and answer the following question:
what is the difference between a GPIO serving as a chip select for an
SPI slave, and a GPIO controlling board level muxing? In both cases the
GPIO controls to which hardware other signals are routed, and both may
be changed at runtime.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
wt., 7 sty 2020 o 08:46 Geert Uytterhoeven <[email protected]> napisał(a):
>
> I'm happy with a (static) GPIO hog.
>
> BTW, what exactly do you mean with "mux framework"? Pinctrl/pinmux?
>
No, I meant the multiplexer subsystem under drivers/mux. I thought we
could call mux_control_select() from pm_runtime_get_*() or something
similar. This is just an idea though, and I see Frank already did an
in-depth analysis so never mind my comment.
Bart
Hi Bartosz,
On Tue, Jan 7, 2020 at 10:03 AM Bartosz Golaszewski <[email protected]> wrote:
> wt., 7 sty 2020 o 08:46 Geert Uytterhoeven <[email protected]> napisał(a):
> > I'm happy with a (static) GPIO hog.
> >
> > BTW, what exactly do you mean with "mux framework"? Pinctrl/pinmux?
>
> No, I meant the multiplexer subsystem under drivers/mux. I thought we
> could call mux_control_select() from pm_runtime_get_*() or something
> similar. This is just an idea though, and I see Frank already did an
> in-depth analysis so never mind my comment.
Thanks, I wasn't aware of drivers/mux/...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds