Re: [RFC] GPIO User I/O

[Rodolfo Giometti <giometti@xxxxxxxxxxxx>]

On 07/07/2020 09:41, Geert Uytterhoeven wrote:
> 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...

I think I need an OK from GPIO SUBSYSTEM's maintainers first...

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@xxxxxxxxxxxx
Linux Device Driver                          giometti@xxxxxxxx
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti