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;
Date:   Fri, 12 Oct 2018 18:44:24 +0200
From:   Mark Brown <broonie@kernel.org>
To:     jacopo mondi <jacopo@jmondi.org>
Cc:     Linus Walleij <linus.walleij@linaro.org>,
        Liam Girdwood <lgirdwood@gmail.com>,
        linux-kernel@vger.kernel.org,
        Marek Szyprowski <m.szyprowski@samsung.com>,
        Jon Hunter <jonathanh@nvidia.com>,
        Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
        Cheng-yi Chiang <cychiang@chromium.org>
Subject: Re: [PATCH v2] regulator/gpio: Allow nonexclusive GPIO access
Message-ID: <20181012164424.GE2340@sirena.org.uk>
References: <20181012125412.21324-1-linus.walleij@linaro.org>
 <20181012142612.GJ7677@w540>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="ytoMbUMiTKPMT3hY"
Content-Disposition: inline
In-Reply-To: <20181012142612.GJ7677@w540>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--ytoMbUMiTKPMT3hY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 12, 2018 at 04:26:12PM +0200, jacopo mondi wrote:

> Sorry, I'm going slightly OT with this, but please read below.

> On Fri, Oct 12, 2018 at 02:54:12PM +0200, Linus Walleij wrote:
> > This allows nonexclusive (simultaneous) access to a single
> > GPIO line for the fixed regulator enable line. This happens

> I might have a use case for shared GPIO lines used as 'simple' reset
> signal for camera devices and not for regulators.

This recently came up in ASoC too with audio CODECs sharing reset lines,
there was a discussion started with the reset API maintainer though no
response yet.  CCing in Cheng-yi who had that problem.  Not deleting
context for that.

> See drivers/media/i2c/ov772x.c FIXME note in power_on() function at:
> https://elixir.bootlin.com/linux/latest/source/drivers/media/i2c/ov772x.c=
#L832
>=20
> The reset line is in this case is passed to the driver by board file:
> https://elixir.bootlin.com/linux/latest/source/arch/sh/boards/mach-migor/=
setup.c#L350
>=20
> As you can see PTT3 is used for both sensors (I know, questionable
> HW design...)
>=20
> 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.

> Please note this is an ancient architecture that boots from board
> files, but the same might happen in modern designs with OF support. Is
> there any clean way to handle shared GPIOs I might not be aware of for
> those systems?

--ytoMbUMiTKPMT3hY
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlvAz2gACgkQJNaLcl1U
h9Dghgf/QYGQR+/EtUlEcvLClnxcuMJn1cmuMyRx2H9O3ZutEWX1Am9+7nfw9gEZ
cDbHLErdpR0UJ/+KqoB1pX+MSwioI/ItZ5JhaIZ6BVlQltkUs9JVAhKZ+7RrObpP
LfiZSl01xHzObb1ecJK7o9D1woPNlclRGQa4Njbjqp5kiztzDGzUH7xviR3A2I2H
LwxuJXnrtZ6Z2oGCAfyCak6j+JnlxsxfvEB0HM8xk/1A0iHGGyhOKrOby98ocxp5
FqvW3fE5t2oGltifP5aN7xEUSbbar3Wuyig3WqG7SH5eiPshkjlJGN0C82IdZXX8
C0M5Aj/0Vcz6dO77femaqzLzICtK7w==
=G3SA
-----END PGP SIGNATURE-----

--ytoMbUMiTKPMT3hY--