From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932964AbcLSLJs (ORCPT ); Mon, 19 Dec 2016 06:09:48 -0500 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:46410 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754721AbcLSLJp (ORCPT ); Mon, 19 Dec 2016 06:09:45 -0500 Date: Mon, 19 Dec 2016 11:09:36 +0000 From: Mark Brown To: Harald Geyer Cc: Liam Girdwood , linux-kernel@vger.kernel.org Message-ID: <20161219110936.c3acatecdqdvzq7b@sirena.org.uk> References: <20161214181405.7hyn4b6yxdetzn5p@sirena.org.uk> <20161216165348.mha6d3faucxdript@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5alzecyegezcjl2k" 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 --5alzecyegezcjl2k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Dec 16, 2016 at 11:00:35PM +0100, Harald Geyer wrote: > Mark Brown writes: > > > I was hoping, that I somehow could get the necessary coordination from > > > the regulator framework. If the best I can get ATM is notifications, then > > > I'll try it and see what kind of code falls out of this. > Ok, tried that and it turns out there is no notification at > regulator_enable() ATM. I guess you'd merge a patch that added this > notification? Probably. > Sure, this is why regulator_force_disable() is the wrong tool for the job. > I was more looking for something (call it regulator_shutdown()) that > * blocked until the regulator is actually off > * made all calls to regulator_enable() from other consumers block (or fail) > * maybe sent notifications to consumers, so that they have a chance to > cooperate and call regulator_disable() at their earliest convenience. > * was undone by a call to either regulator_disable() or regulator_enable() > from the consumer that initially called regulator_shutdown() > I haven't explored this in detail - maybe there are good reasons not to > have it. That sounds like a complete mess from a user point of view - unless the other devices are actually cooperating it's going to have the same effect as doing nothing at all except it'll block the initiating consumer and possibly others doing enables, and as far as I can see it doesn't solve your problems with needing the regulator to be powered off for a specific amount of time. If it made enable calls block it'd be very disruptive for other users as they would suddenly find operations taking vastly longer than they were expecting which could end up being visible all the way back up to userspace. --5alzecyegezcjl2k Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlhXv/AACgkQJNaLcl1U h9Dspgf8D49XkNcea0bMRVO01ZsczshuU3Vz77EU5l398BultGkSPUZW3zfMX0Ct 2dGtpGHgCXbSqGs9A0hMYka6JiVPNHI2XQ01uWMwrw6/cfWOWdO+DJ9GfwWkPWoO 5kkkn9UEMWH3xGvwkJ7w9NVOAriGWb2XOb2zrGE+rb7UL7G5k/svEODK1oEyXfsO DQAILg5gIHKMZh57hlJrzRfmqPTE/lZCm7v2OSFqbG+ANaRWhZxIB91nenuFdrCi w5NqQYr0qvby2hnUiJiu1Kz6+scGROn0t69xYMtDlTvKgN0u5uTzjtJ1oRrtSumn zOSFG4+7lNVIGxaU2ZGZWvfe0ewKDg== =Z/KP -----END PGP SIGNATURE----- --5alzecyegezcjl2k--