Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3505856imm; Thu, 17 May 2018 09:47:50 -0700 (PDT) X-Google-Smtp-Source: AB8JxZq1a49cRcUy2vyZO2fMuPxQ00jJPRD35mVl/dQeGqvs7MYYZY/UcaI0aAAv8tZKCHJlkA1p X-Received: by 2002:a17:902:bd84:: with SMTP id q4-v6mr6021775pls.254.1526575670424; Thu, 17 May 2018 09:47:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526575670; cv=none; d=google.com; s=arc-20160816; b=m1RAte2piHscgbTtCqCcVu1cG0TrANR/+UmRovGuvTN5W2rHcV9eRtVkYhYGFuYl2i vQWRPP/vmI3i6OPlq98MgysvUorr0JRSxCrOpY7dkVfcYdQBAbXE12sjzL+Doymwl9ju d6QeN1RysxClu6pDUCruYP0DQEHepjGTRKFujb2Kh+BOzQL/5OOhofa0zXSRfargPWar /16wKny4WSEeMG2ne7602yLEzxLlifNFUiU9oWZ4802ryCjwPS3NHJYWyUcAJY7ebOX+ IftEoyL/ziU737926JduYcCfjLML9RkNS5Aue0kovGpbnohg80En6kdJC2LGaudEOtD4 TsvQ== 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=bf+fHOMch2D5sUwv/IwxUqfU4nXKQoWK2UQRujKkuoE=; b=mTB1idq+AaiS6Gu41+/PlgXZR+XVySR26QQ6Qzp/WWwyYzezsEKZS7JGXl1w+XW1bb 34EDpdkOft89tLDyMUj/f36epAn+o00e2Luj6C/UclZAHpTV8/lselJbjOLeqT0wqlgU Ik0iXkebwyXY9bkk3x7aaDkPvq0JZINlg0gMpytU0jtjmfao5Ki5VHxATo+I4RRvRSvD bjP3Qvg6NSbbKUGBb1Ak2GwEm879UoA785/6kTQ5pUmuTTxKlyL581tY8/VpFtszyPNB 4/6tss1ri0mEL7SrVZ8JQ0AXmk0eoGH1TVxYZpjgQaMIWkQyrYv2mXa5N58770KPkWKi 862g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=TYyHFcCA; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b16-v6si5593479pfd.240.2018.05.17.09.47.36; Thu, 17 May 2018 09:47:50 -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=TYyHFcCA; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752383AbeEQQq6 (ORCPT + 99 others); Thu, 17 May 2018 12:46:58 -0400 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:59070 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752791AbeEQQo7 (ORCPT ); Thu, 17 May 2018 12:44:59 -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=bf+fHOMch2D5sUwv/IwxUqfU4nXKQoWK2UQRujKkuoE=; b=TYyHFcCAaf1ni5cAWp0DJWmGl 0NNqEx9NhSMPLLl+U0+HYwGuVVaqLwAJG60cBlPdLJ9APJR7AuUWooGG9U5IrWl/EJcX2rpc9rCkx Ora/mfyx+h9VdTWnHTnGvwhGVsYPQYW8dvGaEmyl4ihuvJDuAf04Qf05O16ELWI25F+xk=; Received: from [37.205.61.206] (helo=finisterre.ee.mobilebroadband) by heliosphere.sirena.org.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1fJM1O-00015x-5i; Thu, 17 May 2018 16:44:54 +0000 Received: by finisterre.ee.mobilebroadband (Postfix, from userid 1000) id 18797440093; Thu, 17 May 2018 07:09:48 +0100 (BST) Date: Thu, 17 May 2018 15:09:48 +0900 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: <20180517060948.GI20254@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> <20180424174111.GH22073@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OfrWf2Fun5Ae4m0Y" Content-Disposition: inline In-Reply-To: X-Cookie: Are you a turtle? User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --OfrWf2Fun5Ae4m0Y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 24, 2018 at 01:46:21PM -0700, David Collins wrote: > On 04/24/2018 10:41 AM, Mark Brown wrote: > > 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? > The RPMh hardware is aware of the parent-child connections between > regulators as well as minimum headroom to ensure stable LDO voltage output > for subregulated LDOs. The intention of having the headroom be a > configurable property for processors is to support usecases in which > subregulated LDO loads are particularly sensitive to noise and require > additional headroom. Such usecases are board dependent and beyond the > baseline configurations set in RPMh hardware. So the hardware implementation is some hard coding stuff that doesn't really adequately reflect reality? This seems unfortunate. However do we really need to tell the hardware about the fact that we're adding extra headroom - are there actual interactions with non-Linux things here? > >> 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? > In the case of XOB managed LDO regulators, the LDOs physically can be > configured to different voltages by the bootloader. However, the RPMh > interface provides no mechanism for the application processor to read or > change that voltage. Therefore, we need a way to specify such voltages in > a board specific (as opposed to driver specific) manner (i.e. device tree). Is the kernel somehow prevented from varying these voltages? --OfrWf2Fun5Ae4m0Y Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlr9HKgACgkQJNaLcl1U h9BNLAf+MXHtZxYJQq5vjkWDr1x4ZTeTs9eBmLvqlxpkL2U2URCm2ZJWVirJt5fF G9f+bcDiJTCeW0dNCR8Cs01LWKgYzoXa/pXlse8LEj3eUO9+RdqjsiyDoD5UfVPU TAuMpkvwwnnA46U6OfIV4KIUf8/hNx5rI3R0fyURsrANuBdp47GvHKVhqIBwWYMc n8rjy1bzOFT3TYTAwVtXVczMJrwDe0t1qshGfvOaMK7j7fmra2YVtRXFmCW8VVY1 bwpJwrfKpR1FOGitcqvyP7TLKQy9VtZiuNKpxI4akhIXuSwK5GaFxqwtmO1x8eKk XoJRm8dQhKEpblnzBR2Urx7Fg131SA== =vmht -----END PGP SIGNATURE----- --OfrWf2Fun5Ae4m0Y--