Messages in this thread |  | | From | Geert Uytterhoeven <> | Date | Tue, 7 Jan 2020 08:46:12 +0100 | Subject | Re: [PATCH/RFC 0/2] gpio: of: Add DT overlay support for GPIO hogs |
| |
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
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
|  |