| Message ID | 20191230133852.5890-1-geert+renesas@glider.be (mailing list archive) |
|---|---|
| Headers | show |
| Series | gpio: of: Add DT overlay support for GPIO hogs | expand |
pon., 30 gru 2019 o 14:38 Geert Uytterhoeven <geert+renesas@glider.be> 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 <bgolaszewski@baylibre.com> wrote: > pon., 30 gru 2019 o 14:38 Geert Uytterhoeven <geert+renesas@glider.be> > 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
Hi Frank, On Tue, Jan 7, 2020 at 12:34 AM Frank Rowand <frowand.list@gmail.com> 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
wt., 7 sty 2020 o 08:46 Geert Uytterhoeven <geert@linux-m68k.org> 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 <brgl@bgdev.pl> wrote: > wt., 7 sty 2020 o 08:46 Geert Uytterhoeven <geert@linux-m68k.org> 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