[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <2BA5D07E-B5EF-49E1-BFD2-310A6C5F3FE4@gmail.com>
Date: Wed, 29 Oct 2014 18:42:48 +0200
From: Pantelis Antoniou <pantelis.antoniou@...il.com>
To: Benoit Parrot <bparrot@...com>
Cc: Linus Walleij <linus.walleij@...aro.org>,
linux-gpio@...r.kernel.org,
linux-kernel <linux-kernel@...r.kernel.org>,
devicetree@...r.kernel.org
Subject: Re: [RFC Patch] gpio: add GPIO hogging mechanism
Hi Benoit,
> On Oct 29, 2014, at 18:34 , Benoit Parrot <bparrot@...com> wrote:
>
> Pantelis,
>
> Thanks for the feedback.
>
> Pantelis Antoniou <pantelis.antoniou@...il.com> wrote on Wed [2014-Oct-29 10:53:44 +0200]:
>> Hi Benoit,
>>
>>> On Oct 21, 2014, at 23:09 , Benoit Parrot <bparrot@...com> 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@...com>
>>> ---
>>> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists