Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760551AbcLPWBG (ORCPT ); Fri, 16 Dec 2016 17:01:06 -0500 Received: from h1.radempa.de ([176.9.142.194]:51960 "EHLO mail.cosmopool.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756550AbcLPWAr (ORCPT ); Fri, 16 Dec 2016 17:00:47 -0500 From: Harald Geyer To: Mark Brown cc: Liam Girdwood , linux-kernel@vger.kernel.org Subject: Re: Question about regulator API In-reply-to: <20161216165348.mha6d3faucxdript@sirena.org.uk> References: <20161214181405.7hyn4b6yxdetzn5p@sirena.org.uk> <20161216165348.mha6d3faucxdript@sirena.org.uk> Comments: In-reply-to Mark Brown message dated "Fri, 16 Dec 2016 16:53:48 +0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1332.1481925635.1@stardust.g4.wien.funkfeuer.at> Date: Fri, 16 Dec 2016 23:00:35 +0100 Message-Id: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2665 Lines: 53 Mark Brown writes: > On Fri, Dec 16, 2016 at 02:41:42PM +0100, Harald Geyer wrote: > > Mark Brown writes: > > > On Wed, Dec 14, 2016 at 03:52:54PM +0100, Harald Geyer wrote: > > > > 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. > > > 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? > > It still seems a bit of a limitation to me, that the only way to really > > switch off a regulator is with regulator_force_disable(), which is quite > > a hard hammer. > > I really have no idea what sort of communication you're envisaging here > - powering supplies down when other devices are trying to use them is a > really serious thing with very substantial consequences for userspace, 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. As a convenience API there could be something like regulator_enable_wait() (mirrored by regulator_shutdown_wait()) to avoid having identical notification callbacks and timers in every consumer device. Of course this would require adding timing information to struct regulator. If nobody besides me has any use for that code, then maybe it's not a good idea. > if the devices aren't cooperating at a level higher than the regulator > API level it's unlikely to go well. The devices would need to cooperate in the sense, that they call regulator_disable() whenever they don't strictly need the supply, so that regulator_shutdown() won't block forever, of course. But this is a good idea, in terms of energy saving, anyway. The devices wouldn't need to know the (timing) constraints of other consumers of the same supply - so it's no hard cooperation.