Re: [RFC] GPIO User I/O

[Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>]

Hi Rodolfo,

CC devicetree

On Tue, Jul 7, 2020 at 9:17 AM Rodolfo Giometti <giometti@xxxxxxxxxxxx> wrote:
> On 06/07/2020 23:00, Geert Uytterhoeven wrote:
> > On Mon, Jul 6, 2020 at 10:38 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
> >> On Mon, Jul 6, 2020 at 5:33 PM Rodolfo Giometti <giometti@xxxxxxxxxxxx> wrote:
> >>>> With Geert's GPIO aggregator userspace and device tree can conjure
> >>>> special per-usecase gpio chips as pointed out by Drew: this is
> >>>> very useful when you want some kernel-managed yet
> >>>> usecase-specific GPIO lines in a special "container" chip.
> >>>> To me this is the best of two worlds. (Kernelspace and userspace.)
> >>>
> >>> Maybe this is the "best of two worlds" as you say but the problem is that board
> >>> manufactures need a way to well-define how a GPIO line must be used for within
> >>> the device-tree and without the need of patches! In this point of view neither
> >>> the "driver_override" way nor adding a compatible value to
> >>> gpio_aggregator_dt_ids[] can help (this last solution requires a patch for each
> >>> board!). That's why at the moment they prefer not specify these GPIO lines at
> >>> all or (improperly) use the gpio-leds and gpio-uinput interfaces to keep it
> >>> simple...
> >>
> >> I think the idea is to add a very generic DT compatible to the
> >> gpio_aggregator_dt_ids[]. That way, any DT can use the aggregator
> >> to create a new chip with named lines etc.
> >>
> >> But Geert can speak of that.
> >
> > The idea is to describe the real device in DT, and add it's compatible value
> > to gpio_aggregator_dt_ids[], or enable support for it dynamically using
> > driver_override.
> > The former indeed requires modifying the driver.
>
> I see.
>
> > Note that if you ever want to write a pure kernelspace driver, you do need
> > a proper compatible value anyway.
>
> OK, but for our purposes we need just one compatible value.
>
> > I do agree that it's annoying to have "gpio-leds", but not "gpio-motors"
> > or "gpio-relays".  However, you can always propose bindings for the
> > latter, and, when they have been accepted, add those compatible
> > values to upstream gpio_aggregator_dt_ids[].
>
> Having gpio-uio with proper names within it as motor0, motor1, relay0, etc. as
> in my solution would be suffice. However, after these discussions, are there any
> chances my patch (with needed modifications and documentation) may be accepted? :)
>
> Thanks for your time and answers.

Let's ask the DT people...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

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