From: Linus Walleij <linus.walleij@linaro.org>
To: Mark Brown <broonie@kernel.org>
Cc: jacopo <jacopo@jmondi.org>, Liam Girdwood <lgirdwood@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Jon Hunter <jonathanh@nvidia.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
cychiang@chromium.org
Subject: Re: [PATCH v2] regulator/gpio: Allow nonexclusive GPIO access
Date: Sat, 13 Oct 2018 16:59:12 +0200 [thread overview]
Message-ID: <CACRpkdZ3O+=BiXqasVA-f_0qJCcY2UzWjR3=ri=SxY1et=PzVQ@mail.gmail.com> (raw)
In-Reply-To: <20181012164424.GE2340@sirena.org.uk>
On Fri, Oct 12, 2018 at 6:44 PM Mark Brown <broonie@kernel.org> wrote:
> On Fri, Oct 12, 2018 at 04:26:12PM +0200, jacopo mondi wrote:
> > Do you think extending gpiod_lookup_flags with this newly introduced
> > NONEXCLUSIVE one is an acceptable solution to avoid handling this in
> > the sensor driver like we're doing today?
>
> One problem you've got there is that you need the two devices to know
> about each other so they coordinate their use of the reset line. This
> was relatively easy in the sysetm Cheng-yi has as it's just one driver
> but what if there's mutiple drivers? That's relatively likely with
> audio where you might have something like a CODEC with a separate power
> amplifier. The regulator enable stuff is handling this in the core but
> it's less clear where to put that for reset lines.
Yes spot on.
What we need to do for that to work is to move the reference
counting for shared lines over to gpiolib as well, else every subsystem
that needs to share a GPIO line essentially has to reimplement it.
If the consumers are in different subsystems they would even
have to share a reference count and this would lead to a big mess.
So I was thinking to pull that over to gpiolib for the next kernel :)
Hopefully I could do that without breaking anything, but I don't
have a good track record on that so I think the fine people who saw this
breakage will have to help me out.
Yours,
Linus Walleij
next prev parent reply other threads:[~2018-10-13 14:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-12 12:54 [PATCH v2] regulator/gpio: Allow nonexclusive GPIO access Linus Walleij
2018-10-12 14:26 ` jacopo mondi
2018-10-12 16:44 ` Mark Brown
2018-10-12 17:14 ` jacopo mondi
2018-10-13 14:59 ` Linus Walleij [this message]
2018-10-15 23:08 ` Laurent Pinchart
2018-10-16 7:10 ` Linus Walleij
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='CACRpkdZ3O+=BiXqasVA-f_0qJCcY2UzWjR3=ri=SxY1et=PzVQ@mail.gmail.com' \
--to=linus.walleij@linaro.org \
--cc=broonie@kernel.org \
--cc=cychiang@chromium.org \
--cc=jacopo@jmondi.org \
--cc=jonathanh@nvidia.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.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).