Date: Wed, 14 Dec 2016 18:14:05 +0000
From: Mark Brown <broonie@kernel.org>
To: Harald Geyer <harald@ccbib.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>, linux-kernel@vger.kernel.org
Message-ID: <20161214181405.7hyn4b6yxdetzn5p@sirena.org.uk>
References: <E1cHAvO-0000Qg-Hv@stardust.g4.wien.funkfeuer.at>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="ib6reyxyle6aid7q"
Content-Disposition: inline
In-Reply-To: <E1cHAvO-0000Qg-Hv@stardust.g4.wien.funkfeuer.at>
User-Agent: NeoMutt/20161126 (1.7.1)
Subject: Re: Question about regulator API
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3559
Lines: 78


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

On Wed, Dec 14, 2016 at 03:52:54PM +0100, Harald Geyer wrote:

> Thus the following constraints should be met:
> * When user space asks the driver to read a device, it needs to "claim"
>   the supply and ensure that it has been up for at least 2 seconds
>   before proceeding to read the HW. The supply would be "locked" enabled.
>   (I think this is standard regulator API.)
> * When HW failure is detected, the driver needs to tell the supply to
>   turn off for at least 2 seconds, wait for all other devices to release
>   the supply so it can actually be turned off, then wait for the off peri=
od,
>   then start over again.
>   (This is easy only with getting the supply exclusively.)

You need to use a notification to figure out when the supply is actually
off.

> * It should be possible to read multiple devices quickly when everything
>   is okay and working. (Having 6 2-second delays accumulate would be quite
>   annoying.)
>   (This won't work with exclusive supply usage.)

Similarly using a notification to discover when the supply is on would
help here.

> * Optionally: If all devices are idle the supply would be enabled if short
>   response time is desired, but disabled if power saving is desired.
>=20
> Can this somehow be solved with the existing API?
> If not, do you think it would be reasonable/possible to extend the API
> to cover situations like the one described above?

This doesn't feel like a regulator API problem exactly, a lot of what
you're talking about here seems like you really need the devices to
coopereate with each other and know what they're doing in order to work
well together.  From a regulator API point of view my first thought is
to use notifications to hook into the actual power on/off transitions
and then expressing the bit where the devices all work together at a
higher level.  It may be that a lot of that higher level coordination
just falls out of normal usage patterns do doesn't need explicitly
implementing, assuming the devices are only powered up during reads
anyway.  Using regulator_disable_deferred() in the driver may help
grease the wheels in terms of avoiding needless power bounces and
delays - just wait a little while before powering down in case you need
to power up again very soon after.

You'd end up with the devices all ignoring each other but keeping track
of when the supply was last enabled and disabled and individually
keeping timers to make sure that the needed delays are taken care of.
Userspace would then turn up and read all the devices, they'd then do
the enables and disables as though they were working alone but
coordinate through the notifications.  If device A powered things up
then device B would know the power was already on via the notifications
and when it came on so could take account of that when doing its own
delays.

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

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

iQEzBAABCAAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlhRi+wACgkQJNaLcl1U
h9DuWwf9EUsAI/kd7WnYEz/B0aQ4O4qrJ1UjGqi61hO0Y480U7a8VA9B1ub7kJYs
hcLq7rywcO//nRR+WTHrukG1AyhryNjUXpG6HOZkFSjA+MSk4JrIBwV6rDc4lWG9
j0yezxRMgJMDWDBP7ts1hNCTcMtd8HFv2LpaF7+RYPpiQzpPGdBb3ydZOkjY1O5v
SyRqplXS17vKTU59dshrznnEd61eZvjN3ip54mcFv/1mMShGg3czrnnRWIav7RB0
0Q1HmsTy8ki3yzDtwoQji0M4u3gyfFM93BLAAKVUrLK/vnONgulPGXIqibiRDP+/
Sls2eVu1ew4x5mCto+3FBkwhuw4w7A==
=g3ud
-----END PGP SIGNATURE-----

--ib6reyxyle6aid7q--