Re: [RFC Patch] gpio: add GPIO hogging mechanism

[Pantelis Antoniou]

Hi Benoit,

> On Oct 29, 2014, at 18:34 , Benoit Parrot <bparrot@xxxxxx> wrote:
> 
> Pantelis,
> 
> Thanks for the feedback.
> 
> Pantelis Antoniou <pantelis.antoniou@xxxxxxxxx> wrote on Wed [2014-Oct-29 10:53:44 +0200]:
>> Hi Benoit,
>> 
>>> On Oct 21, 2014, at 23:09 , Benoit Parrot <bparrot@xxxxxx> wrote:
>>> 
>>> Based on Boris Brezillion work this is a reworked patch
>>> of his initial GPIO hogging mechanism.
>>> This patch provides a way to initally configure specific GPIO
>>> when the gpio controller is probe.
>>> 
>>> The actual DT scanning to collect the GPIO specific data is performed
>>> as part of the gpiochip_add().
>>> 
>>> The purpose of this is to allows specific GPIOs to be configured
>>> without any driver specific code.
>>> This particularly usueful because board design are getting
>>> increassingly complex and given SoC pins can now have upward
>>> of 10 mux values a lot of connections are now dependent on
>>> external IO muxes to switch various modes and combination.
>>> 
>>> Specific drivers should not necessarily need to be aware of
>>> what accounts to a specific board implementation. This board level
>>> "description" should be best kept as part of the dts file.
>>> 
>> 
>> This look like itâs going to the right direction. I have a few general
>> comments at first.
>> 
>> 1) It relies on dubious DT binding of having sub-nodes of the
>> gpio device implicitly defining hogs.
> 
> I think in this instance the nodes are explicitly defining hogs.
> Please clarify. What would you like to see here?
>> 

Any subnodes are implicitly taken as hog definitions. This is not right because
gpio controllers might have subnodes that they use for another purpose.

>> 2) There is no way for having hogs inserted dynamically as far as I can tell, and
>> no way to remove a hog either.
> 
> The original patch was allowing that but, Linus's review comment suggested this feature be 
> part of the gpio-controller's gpiochip_add() hook only.
> 

If itâs not possible to remove a hog, then itâs no good for my use case in which
the gpios get exported and then removed.

>> 
>> 3) Iâm not very fond of having this being part of the gpio controller. This
>> configuration conceptually has little to do with the gpio controller per se,
>> it is more of a board specific thing. Why not come up with a gpio-hog driver that
>> references GPIOs? That way with a single gpio-hog driver instance you could setup
>> all the GPIO-hogging configuration for all GPIOs on the board, even one that
>> lie on different GPIO controllers.
> 
> Again this follows Linus's review comment.
> I agree that it prevent a centralize spot where all hog would be defined but it has the advantages of not relying on PROBE_DEFER.
> I mean since all "gpio-hogs" would be defined in a single board dts file it would not be that hard to figure out the big picture anyways.
> 

There wonât be a single board dts file if youâre using things like overlays.

>> 
>> 
>>> Signed-off-by: Benoit Parrot <bparrot@xxxxxx>
>>> ---
>>> Documentation/devicetree/bindings/gpio/gpio.txt | 33 +++++++++
>>> drivers/gpio/gpiolib-of.c                       | 99 +++++++++++++++++++++++++
>>> drivers/gpio/gpiolib.c                          | 81 ++++++++++++++++++++
>>> include/linux/of_gpio.h                         | 11 +++
>>> 4 files changed, 224 insertions(+)
>>> 
>> 
>> Regards
>> 
>> â Pantelis
>> 
> 
> Regards,
> Benoit

Regards

â Pantelis

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/