Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751310AbcDJXTK (ORCPT ); Sun, 10 Apr 2016 19:19:10 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:58486 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750910AbcDJXTI (ORCPT ); Sun, 10 Apr 2016 19:19:08 -0400 Date: Mon, 11 Apr 2016 00:18:56 +0100 From: Mark Brown To: Martin Fuzzey Cc: Javier Martinez Canillas , linux-kernel@vger.kernel.org Message-ID: <20160410231856.GE18319@sirena.org.uk> References: <57065FB5.6040707@parkeon.com> <20160407170249.GV1924@sirena.org.uk> <5706A435.4050304@parkeon.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EgVrEAR5UttbsTXg" Content-Disposition: inline In-Reply-To: <5706A435.4050304@parkeon.com> X-Cookie: Great minds run in great circles. User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: 2a01:348:6:8808:fab::3 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: Regulator: drivers that need to know their supply X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2197 Lines: 56 --EgVrEAR5UttbsTXg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Apr 07, 2016 at 08:17:25PM +0200, Martin Fuzzey wrote: > On 07/04/16 19:02, Mark Brown wrote: > >No, this is not sensible. You should be telling the framework about the > >slew rate and letting the framework work out how long it's going to take > >to transition. Your driver shouldn't be peering around inside other > >regulators, it should be telling the framework what it does itself and > >any handling of interrelationships should be in the framework. > Ok, but I fail to see any way to do that (at least with the framework as > is). Then send patches for the framework. One of the great things about working on Linux is that the whole OS is free software so you don't have to work around things in your driver! I've not looked at the code for this specific case. > Or are you saying I should extend the framework to add a .get_ramp_delay > driver callback and make the framework do the calculation itself? Yes. > While moving it to the framework will avoid the driver knowing about other > regulators it won't fix the underlying issues I mentionned. > For a regulator configured as always-on the framework doesn't lookup and > enable the parent regulators until regulator_register_resolve_supply() > is caused right at the end of regulator_register(). > This means that, when the always-on register is enabled it has no supply > assigned, even at the framework level. You might find this changing very shortly but in any case the answer is still the same, change the framework if it needs changing. --EgVrEAR5UttbsTXg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXCt9fAAoJECTWi3JdVIfQP5YH/0hkTZyR6vRBhoXgr/+bZIBN hJ3GtkrJJPnNR06fUvo1Z1vmGPFD9MOJEuCUZwvcv1S4qy4enTGDhh3AZUaiBTbu 5yZNILPzO1kr3v3quKDXsqi3vViZdhJ2N3uH6/CRnm6bbdhnyJhS4GspdsN1nTgX HJLpa3+bHZFDUSEdZ/6w931JsX4DX1H6b7+8C3jwXGywBxCrbV2kfNKn1Hy+svfm QgtoNPCypVpWgfYpPwCqWRMuXJULcu0/leCMMUdHUndm2tj2Hsibx9rCz9dktpTy ElnKzwD1pN6vCsZ6ShSeHoO4msI7cvd5QKdd6yRelyTMZSX6OkgtvpyHBQiwWzU= =wbPL -----END PGP SIGNATURE----- --EgVrEAR5UttbsTXg--