From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: Shared regulator usage Date: Mon, 26 Nov 2012 13:47:19 +0000 Message-ID: <20121126134719.GI9411@opensource.wolfsonmicro.com> References: <1b9aae54f83056035d83c049a7ac1876.squirrel@www.codeaurora.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hABqaeELJqnDDeDE" Return-path: Received: from opensource.wolfsonmicro.com ([80.75.67.52]:41880 "EHLO opensource.wolfsonmicro.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753123Ab2KZNrV (ORCPT ); Mon, 26 Nov 2012 08:47:21 -0500 Content-Disposition: inline In-Reply-To: <1b9aae54f83056035d83c049a7ac1876.squirrel@www.codeaurora.org> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: aghayal@codeaurora.org Cc: linux-arm-msm@vger.kernel.org, collinsd@codeaurora.org, tsoni@codeaurora.org --hABqaeELJqnDDeDE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Nov 26, 2012 at 05:13:37AM -0800, aghayal@codeaurora.org wrote: > For example: > Consumer (A) cpu-freq sets the voltage range to {1.275v, 1.375v}. The > regulator framework eventually sets the regulator to 1.275v. Consumer (B) > recommends a lower the voltage say (1.25v) and executes set_volatge on > {1.25v, 1.25v}. This is where regulator_check_consumers() fails as it does > not meet the (A)'s constraint. Well, of course. What else would you expect to happen in this case? > We are looking for the right way to handle such a situation using > regulator framework, considering this to be a valid usecase. One way we > could think of is having one of the driver (say cpu-freq) register a > virtual regulator device and have the other driver be its consumer. This > way all the regulator calls to the physical hardware will be routed though > one primary driver which can take care of the adjustments. The problem > with such approach would be scalability for a new consumer, i.e. adding > another consumer for the primary driver would present a similar problem as > the original one. Why not just fix your consumers to request the voltage ranges they actually want? Clearly in your above example one of the consumers can support a wider voltage range than it is actually requesting so it should just request that voltage range. --hABqaeELJqnDDeDE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQs3LfAAoJELSic+t+oim9n74QAJXV/uNWmZHUTTiVXk4w2tmX u/aFaXVR7wlkcdU60Uj0qmBuW9VZXoIPIImLleJIpgkgWkXUo0EHkrSHm+3SN713 hM3OAH/eObVaP3ioeBGDtC0T9ie5UEpQw2KctqgskgBylFpn8IsnMA5r1at3Zc8Z VbcDI+H/J4xaDeRBKAu1M7DfYGnSpfuq+o4Olui/lB9r2EZRjJFq5GdUgZQTrjWj 3BO7pUTeI2JxfGzcCVInv4OV8K28NN0SHXnul/WLmFOwlo/oXIxKURxFhj8qtXFz SmGwQWKT9NqH6XYCI/eB6HaU/6q7v/I7bvyOuD2icuLZVtKZyaL4QDcVSkWG+siJ AlQD9cMjlzmlgG5r9CkO3GPlPK1mDVVQwxZ0LadfEMae9jsqmTnmvX6rkp5kBDw3 8c3gQ8Jblb9T22GEMMe2ERHAroPYlKB1+OBGziEOXhNOzbVMjtsK7VeCfsnP0sBi 0tg5a42Ec3OKlW3tjqZjwg9US/bv98BSE4fPlzavYEccNIXIxMW3G/H7dS1dun+C ciVnjo4Jt+hVRba/ktg3Ksdc2P/HyPRJzWUiAYo2FyTStYjU+5i15VllcOEZHN/T f4VIVH1Wo4X2kX8htZNJgQ0LMM8EZ6Z4Xk9KMW+IWRhUC/oqO7JadXhpIC1vPWYl e3HC84yLh2ojrUqiEmSu =ON/V -----END PGP SIGNATURE----- --hABqaeELJqnDDeDE--