From: Alexandre Courbot <gnurou@gmail.com>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Benoit Parrot <bparrot@ti.com>,
Pantelis Antoniou <panto@antoniou-consulting.com>,
Jiri Prchal <jiri.prchal@aksignal.cz>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
Date: Fri, 5 Dec 2014 00:00:26 +0900 [thread overview]
Message-ID: <CAAVeFuJkZrmrQSb=63yDWjgZieT_hnutZkuO2WTENfb+72rayQ@mail.gmail.com> (raw)
In-Reply-To: <20141204145206.GR30256@lukather>
On Thu, Dec 4, 2014 at 11:52 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi again,
>
> It looks like I missed some part of it.
>
> On Thu, Dec 04, 2014 at 11:15:38PM +0900, Alexandre Courbot wrote:
>> > GPIO hogging needs to be the ideal solution for that, since we can
>> > just enforce the GPIO14 value as the driver is probed, which provides
>> > the guarantee that any driver using the bank B will actually drive the
>> > GPIO it might use.
>>
>> At this point I start wondering if such initial setup should not be
>> the job of the bootloader? GPIO hogging ought to be simple and
>> definitive, adding the possibility to have it just as an initial value
>> would considerably complexify it. E.g. when is the gpio chip driver
>> supposed to release the hogged descriptor in such a case?
>
> Relying on the bootloader for such trivial (and critical) things may
> not work at all. You don't always have the option to replace it,
> either because you physically can't, or just because you don't have
> any alternative.
>
> I agree that in general this is something that should go in the
> bootloader, but we should have a way to deal with the case where it's
> not done.
>
>> Note that if the multiple GPIO consumer feature we are planning goes
>> through, you should be able to use both hogging *and* a regulator on
>> the same GPIO and achieve what you want. The expectation of multiple
>> consumers is that the board designers know what they are doing, and
>> this case would certainly fit (chip hogs the line and doesn't touch
>> the value after that, letting the regulator control it without any
>> conflict afterwards), although it would of course be better to solve
>> the issue through regular probing...
>
> If such an effort is on-going, then I'm totally fine waiting for it
> and leaving that outside the hogging mechanism. As long as it works,
> I'm happy.
Ok. I just want to wait until the next -rc1 to make sure that the
large GPIO array removal patch (on which the multiple consumers
feature depend) did not break anything important, then I will submit
it.
next prev parent reply other threads:[~2014-12-04 15:00 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-20 23:54 [Patch v2 0/2] gpio: add GPIO hogging mechanism Benoit Parrot
2014-11-20 23:54 ` [Patch v2 1/2] " Benoit Parrot
2014-11-28 7:30 ` Alexandre Courbot
2014-12-01 16:36 ` Maxime Ripard
2014-12-02 0:27 ` Benoit Parrot
2014-12-02 14:13 ` Alexandre Courbot
2014-12-02 14:29 ` Linus Walleij
2014-12-02 16:12 ` Maxime Ripard
2014-12-04 14:15 ` Alexandre Courbot
[not found] ` <CAAVeFu+Gms6ptyK6j1Zy_wWg+9URs+9zBu=pOiwiEERO=8NjNw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-12-04 14:27 ` Pantelis Antoniou
2014-12-04 14:41 ` Alexandre Courbot
2014-12-04 14:47 ` Pantelis Antoniou
[not found] ` <C9DBE2F0-A725-4D05-BEC6-F083F3F83B9F-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>
2014-12-04 14:58 ` Alexandre Courbot
2014-12-04 15:02 ` Pantelis Antoniou
2014-12-04 15:10 ` Alexandre Courbot
2014-12-04 15:22 ` Pantelis Antoniou
[not found] ` <8717617A-56AE-495C-B873-0B2E3EA83060-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>
2014-12-06 12:04 ` Alexandre Courbot
2014-12-04 14:27 ` Maxime Ripard
2014-12-04 14:49 ` Alexandre Courbot
2014-12-05 10:24 ` Maxime Ripard
2014-12-06 12:08 ` Alexandre Courbot
2014-12-08 19:18 ` Maxime Ripard
2014-12-04 14:52 ` Maxime Ripard
2014-12-04 15:00 ` Alexandre Courbot [this message]
2015-01-12 9:40 ` Linus Walleij
2015-01-12 12:45 ` Mark Brown
2014-12-02 0:22 ` Benoit Parrot
[not found] ` <20141202002244.GB24551-l0cyMroinI0@public.gmane.org>
2014-12-02 14:10 ` Alexandre Courbot
[not found] ` <CAAVeFuJWPvdmO_KPXP2LrkAy4SQDZ+f7pvE6U8r7gPH+jE3Lrw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-12-02 14:28 ` Linus Walleij
2014-12-02 14:25 ` Linus Walleij
2014-11-20 23:54 ` [Patch v2 2/2] gpio: Document " Benoit Parrot
[not found] ` <1416527684-19017-3-git-send-email-bparrot-l0cyMroinI0@public.gmane.org>
2014-11-28 7:31 ` Alexandre Courbot
2014-12-01 22:57 ` Benoit Parrot
2014-12-02 14:04 ` Alexandre Courbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAVeFuJkZrmrQSb=63yDWjgZieT_hnutZkuO2WTENfb+72rayQ@mail.gmail.com' \
--to=gnurou@gmail.com \
--cc=bparrot@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=jiri.prchal@aksignal.cz \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.ripard@free-electrons.com \
--cc=panto@antoniou-consulting.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).