From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753542AbcLNTAH (ORCPT ); Wed, 14 Dec 2016 14:00:07 -0500 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:55078 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751713AbcLNTAF (ORCPT ); Wed, 14 Dec 2016 14:00:05 -0500 Date: Wed, 14 Dec 2016 18:14:05 +0000 From: Mark Brown To: Harald Geyer Cc: Liam Girdwood , linux-kernel@vger.kernel.org Message-ID: <20161214181405.7hyn4b6yxdetzn5p@sirena.org.uk> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ib6reyxyle6aid7q" Content-Disposition: inline In-Reply-To: X-Cookie: I represent a sardine!! User-Agent: NeoMutt/20161126 (1.7.1) X-SA-Exim-Connect-IP: 2001:470:1f1d:6b5::3 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: Question about regulator API X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: No (on mezzanine.sirena.org.uk); Unknown failure Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --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--