Received: by 10.192.165.148 with SMTP id m20csp4931415imm; Tue, 24 Apr 2018 10:43:52 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr0SWuVjhdaKLhNSnSAy53V4sgQp4D29HGWAzgKeDu/ymKFHx+WHuvvFvIxhlmOMaVnPkii X-Received: by 10.98.9.145 with SMTP id 17mr3803865pfj.34.1524591832301; Tue, 24 Apr 2018 10:43:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524591832; cv=none; d=google.com; s=arc-20160816; b=KHktBVTxE2sm2Gk168AN3u36/3HkzxIKmUmUueQuJH72sGq9UjmlfyaRnhCZkYsyUf gPJYOKd7kYGyx/7eKcg9azvQFSCwJROljABbLJ3PThuLP1cesJU6dFYp8TfoIVhU2g1z x0R6Ou4WjG/IF+4RG7XHEkFUWP0lBa1UsbDn1Cn+ejKq7/MEH4TWv3T7WKB45lYcFXny zQsUPWUj44d2H6/CVRrmXroLfjQgF87PjwT8pPfEqil2ys8V9U9lqPs+7hm7CrUU7PCf Jqo2hqYsb8ds/FiM5dyQw4HQYzylzrGhasiMJR53yqvbq2lhKy9Pmjrx1HhcBW/uCcOh xfpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=uOkcGpnhAxlwiO6mBo+qtwyvGEguU8q+G28u/UbBqbw=; b=JnOP+F2a01qXKoaBwjqPDwqacaa+98BD0wQ6DYN6NRHEW9N2B81gmTpDpCc2LBvJee 1IWxxEdWM9iVl6pUOSfXkK92L2adhJ97Mk65sAWOaC5ES4YGJbULcq89E3fs4OBfHuIg sUjY0YA/f7X1ds/SYaBfEc1JIdll/AZ6YQWFrJ13X5WuilsinOfbeeofPpiWbCwN/vNi BHBoIaUYjqQzHOOFHGRQ4xzHUiWohzZaa9O8pOI6Q9wWYcu9bZLDJ/9/M5jxtv+0QORC hUU+BcLv/vCb7iLwvsWIfzWfEONYW/+iirBzbnpO2lj0Rc++6hDcNfajMXRV5TQKQLMA qYnw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=O7O966RN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u7si11085578pgv.251.2018.04.24.10.43.36; Tue, 24 Apr 2018 10:43:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=O7O966RN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752473AbeDXRlS (ORCPT + 99 others); Tue, 24 Apr 2018 13:41:18 -0400 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:35230 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750757AbeDXRlQ (ORCPT ); Tue, 24 Apr 2018 13:41:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; s=20170815-heliosphere; h=In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uOkcGpnhAxlwiO6mBo+qtwyvGEguU8q+G28u/UbBqbw=; b=O7O966RNxPGXHAHwCAb+hPDwf 7h7cMCXUV79aR/3/4Gi7bMmYqP4nOVB3u1jwa/o3brzGf4MtNQFGiPNatBDSELNxHdfRpe0kyeEjg xO1W4XAeQVAAucQIsZfg7gf3oNIm3QNo+MhyyIaj/AI1YenWhLx4sS/b2ydZ0a/wDPIA4=; Received: from debutante.sirena.org.uk ([2001:470:1f1d:6b5::3] helo=debutante) by heliosphere.sirena.org.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1fB1wF-0000Rp-RR; Tue, 24 Apr 2018 17:41:11 +0000 Received: from broonie by debutante with local (Exim 4.90_1) (envelope-from ) id 1fB1wF-0003Nd-5K; Tue, 24 Apr 2018 18:41:11 +0100 Date: Tue, 24 Apr 2018 18:41:11 +0100 From: Mark Brown To: David Collins Cc: Stephen Boyd , lgirdwood@gmail.com, mark.rutland@arm.com, robh+dt@kernel.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, rnayak@codeaurora.org, ilina@codeaurora.org Subject: Re: [PATCH 1/2] regulator: add QCOM RPMh regulator driver Message-ID: <20180424174111.GH22073@sirena.org.uk> References: <71fab82672524b95632cdb588c16edfc9711866a.1521246069.git.collinsd@codeaurora.org> <152165924074.91116.13025068669916027026@swboyd.mtv.corp.google.com> <493c1f5d-df99-ca68-0f90-a7937a696f5d@codeaurora.org> <152411734938.46528.9676451637772936597@swboyd.mtv.corp.google.com> <20180419120813.GD27188@sirena.org.uk> <38f42537-f801-115a-4120-1344a67a0462@codeaurora.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="17/8oYur5Y32USnW" Content-Disposition: inline In-Reply-To: <38f42537-f801-115a-4120-1344a67a0462@codeaurora.org> X-Cookie: Take your Senator to lunch this week. User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --17/8oYur5Y32USnW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Apr 20, 2018 at 12:28:21PM -0700, David Collins wrote: > On 04/19/2018 05:08 AM, Mark Brown wrote: > > This doesn't sound like what the min_dropout_uV constraint is intended > > to handle - that's there for the regulator driver (not constraints) to > > indicate how much headroom the regulator needs in the supply voltage in > > order to provide regulation. It's not something the regulator uses, > > it's something that gets fed into voltage requests made on the supply of > > the regulator which I can't see that the hardware is going to be able to > > handle unaided. > RPMh hardware enforces the requested minimum headroom voltage for all > regulators with a parent. It has full knowledge of the parent-child > connections of regulators on the board (as programmed by the bootloader). > It automatically reconfigures the parent voltage when needed as a result > of requests changing the voltage of any of its child regulators. If the hardware has full knowledge of all these constraints and enforces them transparently then why does the kernel care that it's doing that? Doesn't it defeat the point of it doing all this stuff if we have to know about it? > > Ideally future versions of the RPM will have improved interfaces, > > there's a bunch of problems like this :( > Do you have a preference for qcom,regulator-initial-microvolt vs a generic > framework supported regulator-initial-microvolt property for configuring a > specific voltage at registration time? We'll need to have support for one > or the other in order for the qcom_rpmh-regulator driver to be functional. This is basically specific to Qualcomm, I can't off hand think of any other devices with similar issues. > > Yes, constraints that specify a single voltage are done by setting min > > and max to the same value. fixed_uV is *only* for regulators that have > > a physically fixed voltage. > XOB managed regulators physically cannot change voltage. Therefore, do > you agree that it is reasonable to use fixed_uV for them? Note that I > removed init_data->constraints.apply_uV manipulation in version 2 of this > patch. If these regulators can't change voltage then surely we know what voltage they have without needing it to be specified in DT? --17/8oYur5Y32USnW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlrfbDYACgkQJNaLcl1U h9Cufwf8DKt2VxymLwg5FehUKHJfKGDmmKX/slyzbnJvnx551yP4dfGyDDakVpmX PwO8eaxHMezYNhc0itCZt4HGUnU2mBtOjRdkN8qM08K7sgWNoL7sK0Tl5xWiaq7h PsaRiSb4i7iBG4QGa7z8Q7bqRqFS1xiFwwjGA9ljkrB3b7+v5kIj2Ylhx0MQQ8VB S2dWZlEUz8dSTPLGjBSakFVhtCNs375iqWOYwXowkue1FsxZyn0cCObDrbJAEaBh 4EcuhIuSTkPbXeMNIQZjY3IwdRGy9OeftiVppWzUY2uUn0CGKOCW63tSoQAoj4AT rLTfKf2CLxpa3KQ5Av6IA4YFNkmNjg== =hSGr -----END PGP SIGNATURE----- --17/8oYur5Y32USnW--