From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751376AbbCTL3S (ORCPT ); Fri, 20 Mar 2015 07:29:18 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:37545 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750929AbbCTL3Q (ORCPT ); Fri, 20 Mar 2015 07:29:16 -0400 Date: Fri, 20 Mar 2015 11:28:28 +0000 From: Mark Brown To: Ulf Hansson Cc: Doug Anderson , Heiko Stuebner , Jaehoon Chung , Seungwon Jeon , Alexandru Stan , Alim Akhtar , Sonny Rao , Andrew Bresticker , Addy Ke , Javier Martinez Canillas , "open list:ARM/Rockchip SoC..." , "linux-arm-kernel@lists.infradead.org" , Chris Ball , Johan Rudholm , Adrian Hunter , Tim Kryger , Andrew Gabbasov , Sascha Hauer , linux-mmc , "linux-kernel@vger.kernel.org" Message-ID: <20150320112828.GF2869@sirena.org.uk> References: <1426112117-18220-1-git-send-email-dianders@chromium.org> <1426112117-18220-2-git-send-email-dianders@chromium.org> <20150319113646.GQ2869@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4fo3mGi7Q6pk/+I3" Content-Disposition: inline In-Reply-To: X-Cookie: Wanna buy a duck? User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 94.175.94.161 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH v4 2/4] mmc: core: Add mmc_regulator_set_vqmmc() 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 --4fo3mGi7Q6pk/+I3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 20, 2015 at 11:55:50AM +0100, Ulf Hansson wrote: > On 19 March 2015 at 12:36, Mark Brown wrote: > > The implementation *should* do that anyway, it's just not trivial to > > implement in an efficient fashion with the current information we have > > from drivers. > The APIs regulator_count_voltages() and regulator_list_voltage(), are > currently used from the mmc core to find out which voltages that is > supported (with 0.1V granularity). Then that information can be used > when trying to set a new voltage. > But I guess such a wrapper API is out of the question? > Anyway, I get the feeling that we will need to do the same for this case. As previously discussed the problem is that there can be a *lot* of voltages on a modern regulator with fine grained voltage steps and tolerances are also used for things like cpufreq where we care about performance. We need something that doesn't require a linear scan of possible values. > >> would be good to allow both upper and lower limits to be zero. > > The lower limit can be zero already though it isn't clear to me that > > this is useful. Setting an upper limit of zero seems nonsensical, an > > upper limit that is lower than the lower limit isn't terribly obvious > > and removing the upper limit isn't safe - it means that we'll happily > > oversupply things which is a road to physical damage. > I am not sure I follow here. In the regulator_set_voltage_tol() you > can only specifiy one limit (tolerance?). What Dough proposed was to > add a new API which can have both a low tolerance value and a high > tolerance value. Tolerances are not limits - when you say "limit" that sounds like a hard value. I can't see any reason why the code would prevent anyone setting a tolerance of zero, though it should be rare that this is actually the best thing to do. --4fo3mGi7Q6pk/+I3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVDARbAAoJECTWi3JdVIfQiPQH+wVECwfALfzRrxDM2hMMzyoO EdpJfak+mGZrowaxAyb4AcfS1qxEETng0G2bK67QM2cX38ZvWnPZTRd3fG/huIZ4 VIlW63RyR5KGOUYa4QNplp4XdYt41d3fuc1Zee3iqEkCDfngoacWgdoYYh61h7F0 acEcg7nN1IjCLMp5c+aRAKsKKwpfJyYaQn3tSyS31sBKtk35tqZyGNO5Fl4k+vAg ZJnAzzIpeEPJ+xiqt6WTb+Qr9R6+QIp/sxsfzbuYzbT5noAYBvj1Vknc4x+q/51E 93eHG+dcRrfqfx+FrfKtId9ObsYRfBQhHz+gogkQPSix75SPGUcKioc5eDj9hKY= =pyen -----END PGP SIGNATURE----- --4fo3mGi7Q6pk/+I3--