Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20181012125412.21324-1-linus.walleij@linaro.org>
 <20181012142612.GJ7677@w540> <20181012164424.GE2340@sirena.org.uk>
In-Reply-To: <20181012164424.GE2340@sirena.org.uk>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Sat, 13 Oct 2018 16:59:12 +0200
Message-ID: <CACRpkdZ3O+=BiXqasVA-f_0qJCcY2UzWjR3=ri=SxY1et=PzVQ@mail.gmail.com>
Subject: Re: [PATCH v2] regulator/gpio: Allow nonexclusive GPIO access
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
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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