From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752095AbcBLXDn (ORCPT ); Fri, 12 Feb 2016 18:03:43 -0500 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:48606 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751912AbcBLXDV (ORCPT ); Fri, 12 Feb 2016 18:03:21 -0500 Date: Fri, 12 Feb 2016 23:03:00 +0000 From: Mark Brown To: Stephen Boyd Cc: Georgi Djakov , Lina Iyer , lgirdwood@gmail.com, andy.gross@linaro.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org Message-ID: <20160212230300.GE18988@sirena.org.uk> References: <1455023549-30836-1-git-send-email-georgi.djakov@linaro.org> <20160209222154.GB1646@linaro.org> <56BB32A9.7090002@linaro.org> <20160210183651.GH30978@codeaurora.org> <20160210184327.GB13270@sirena.org.uk> <20160210190436.GI30978@codeaurora.org> <20160210192101.GE13270@sirena.org.uk> <20160210224628.GK30978@codeaurora.org> <56BC5FA7.5020108@linaro.org> <20160212001755.GL30978@codeaurora.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cYtjc4pxslFTELvY" Content-Disposition: inline In-Reply-To: <20160212001755.GL30978@codeaurora.org> X-Cookie: Isn't this my STOP?! 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: [PATCH v4] regulator: qcom-saw: Add support for SAW regulators 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 --cYtjc4pxslFTELvY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 11, 2016 at 04:17:55PM -0800, Stephen Boyd wrote: > On 02/11, Georgi Djakov wrote: > > 8064 uses SSBI instead of SPMI and we currently do not have any > > existing regulator support upstream yet. So this driver is not > > duplicating any existing regulator. We should decide whether to > > keep this driver or to replace it with a new ssbi-regulator driver > > and bindings instead, where we can avoid the split-bus fun at > > least to some extent. Maybe the latter is the better option? > Yes I think having an ssbi/spmi regulator driver may be a better > approach. The SAW code can monitor the regulator for voltage > changes with a notifier and then stick the restore voltage into > the SAW registers. There's only one sticking point below. So this is sounding like we want to drop this driver? > modifies the SAW registers to set the voltage on the CPU that is > using the regulator, thereby preventing the CPU from going idle > or hitting suspend when the voltage is changed. If we were to use > the SSBI/SPMI regulator driver we would need to do something > similar so that the SPM is guaranteed to not be running during > the voltage switch. So I guess schedule a work on the CPU that's > affected by the voltage switch and hope that the CPU doesn't go > offline during that time? "Hope" doesn't sound like this is going to be a safe long term solution, either something more integrated with the offline code that explicitly blocks offlining (which I don't off the top of my head know if we can do easily) or something where we start something on the CPU and then explicitly handshake with it (but then what if the CPU has real work to do?) seems better. --cYtjc4pxslFTELvY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWvmSjAAoJECTWi3JdVIfQ6yQH/AmYyWm9Wh9aHJBXHfct3jFY DaSH3Maqwtne81M5GDtyYbextb7qgy2P0QF5QiBX6iJoLrB+/lUFpVxhjVy1XK8b kIsGHQzyMNoGNfa5VSxxCQ2p9up9ES5Ba+BZ3Nc+G0peOXJ01Y+hgTwrptYs1Ypp Q7XyNU9/fL2DkFbhW6sZIxF20LXPB1n15yf2ZD0OxbFbhzqV0KYovQ+MqIkm7wCs V74mmEwB5Rv7D1PECHVKk0T4Vt3QilUNu/lHw8WWgIyHifXGE9HjtoGcQIHqNaWn 9thxjnn38s58245QZNadzb2yJbM6nqRhUmkdLB4uKzIcXJsDHEykqt+i3qhAMSc= =DFP2 -----END PGP SIGNATURE----- --cYtjc4pxslFTELvY--