Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4345737imm; Wed, 30 May 2018 04:02:38 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJpuFj5/STiOngfIbRaPova+qknpvmwyz7Qt0nr0MNCEQDrqiwncy+1XzZFtP/2EIlgQakq X-Received: by 2002:a65:654a:: with SMTP id a10-v6mr1843948pgw.107.1527678158455; Wed, 30 May 2018 04:02:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527678158; cv=none; d=google.com; s=arc-20160816; b=T2l4h39m8zf6o4dzcd60C6/Tx2CEirPgTON3nLmFmbuQNVgvPoSB9pVtM93JctW/ye UO+kKB8DEUHr8gOAXVvCgF4CVaOLb4abv9IVGwHgZlaCqEWvIXw3aLx/BjOAXizw2uOm yJkPC1SmvrM7N9aLrj/BTKmvMA94akVfn7VCinHqVDBuxk29FJbX4RLOgDlsKa4jUGIx 5D4VWYfj2rYNCv5YFMuNz3pbKXHz+n3YD5hiEfi0iMzKnhcWZjOKWY0HCZqvaGPDV6nA afR32oUpkNo/5q485a6H8Rq9raFNihaF0Em5l1iH6teuFJ2hDqxcswepWBQrA2fQBvBN BoeA== 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=/lbVNt2twKQOffQ4gnsxf0DTp8DtbwJ5mPajinYso7o=; b=sSt5POGE7Z2hKQsvaijLa8p7i32q1CmRiFwSqV8atXxyX/pUzLcpyh3pm9EMQSgdwI u1Zx0lW1u2Wnwy47M7NbrRpOwxYyauPFqA+/kfoLht7rGbpA4urgYzkJEBZNK6+EAzeu 5ql0Kf0YR+iLJS68egU72x9tvZRzzPygtKVXpX4DQ3WmHk4UiDVp8MGEFWw5uhe61UXA bQe+c/5yMUkTKVTzfT1F2WweCiCygpOITZ3d05CibgkNJ7p6WpuHK1VLya/aR2IPiCs/ ZJ00UZydnup6IY0r1an3XNmL8WVCsaixqjC7jGT7pTeoluGhPHBMmOiNQUX9fUgIUCOE jgkA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=aDYMRKdB; 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 u23-v6si36840567plk.487.2018.05.30.04.02.24; Wed, 30 May 2018 04:02:38 -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=aDYMRKdB; 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 S1752186AbeE3LAN (ORCPT + 99 others); Wed, 30 May 2018 07:00:13 -0400 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:51602 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751479AbeE3LAH (ORCPT ); Wed, 30 May 2018 07:00:07 -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=/lbVNt2twKQOffQ4gnsxf0DTp8DtbwJ5mPajinYso7o=; b=aDYMRKdBnPWaMVg7eW+f0rWtL qZBgGDIRJ4qKKBn6i+ZbtRB94YRDNI9EKRCUSqaKsVlf4BbL9PtXbhhwyCJwHtr8O/7YABBMG6Nq4 npksKQ+Zd3IkFBvFkzvnSnkPN7e8CcOd9Pw0M9U8FiBY1UfZrm3J1yUDmPsxH4/SH5rBQ=; 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 1fNypl-0007J0-H5; Wed, 30 May 2018 11:00:01 +0000 Received: from broonie by debutante with local (Exim 4.91) (envelope-from ) id 1fNypk-0006Xq-KW; Wed, 30 May 2018 12:00:00 +0100 Date: Wed, 30 May 2018 12:00:00 +0100 From: Mark Brown To: Matti Vaittinen Cc: Matti Vaittinen , mturquette@baylibre.com, sboyd@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com, lee.jones@linaro.org, lgirdwood@gmail.com, linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, mikko.mutanen@fi.rohmeurope.com, heikki.haikola@fi.rohmeurope.com Subject: Re: [PATCH v4 0/6] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver Message-ID: <20180530110000.GI6920@sirena.org.uk> References: <20180530090512.GC13528@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QDIl5R72YNOeCxaP" Content-Disposition: inline In-Reply-To: <20180530090512.GC13528@localhost.localdomain> X-Cookie: Don't get mad, get interest. 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 --QDIl5R72YNOeCxaP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, May 30, 2018 at 12:05:12PM +0300, Matti Vaittinen wrote: > Other 4 can be used on PWM or PFM switching mode. When PWM is used > voltages can be changed without disabling regulator. On PFM this should > not be done. These latter 4 regulators can be forced to PWM mode via > control bit in register. This driver does not support controlling this > mode though. So this driver version just checks if regulator is enabled > before changing the voltage and if it is the voltage change fails with > -EBUSY It probably should support setting modes (especially if the device isn't smart enough to automatically shift which sounds like the case) but that's a separate thing. > My question is whether it would be good idea to also read the 'force > PWM' bit when voltage is changed and allow the change if PWM mode is > forced to be used? Problem is that the check and voltage change can't be > atomic so there is a chance someone changes the mode (bypassing the > driver and regulator core) after this check but before we get to modify > the voltage. Furthermore, I doubt the 'force PWM' is widely used (but I > can't say for sure as I can't imagine all use cases) as it is not so > power efficient. Why would anything else be changing the mode configuration of the regulator while the system is running? That sounds like a bad idea. In any case if the hardware really needs to be manually put into force PWM to change voltage then the simplest thing would be to just move it into force PWM mode, do the change, then change back if it wasn't already in force PWM mode. The tradeoff with forced PWM mode is that the quality of regulation will be a lot better, especially if the load changes suddenly (as things like CPUs often do). Most hardware that's at all current is able respond to changes in load and switch modes automatically when it's appropriate, except possibly in some very low power modes. --QDIl5R72YNOeCxaP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlsOhC8ACgkQJNaLcl1U h9Ag/wf+K4uLA5x5eT0bG96OcP1drAx9nx/aAbTTtQsFPeSTocdCq4nplECWlONt Jfi9RRuX2TRezrrQa8QIcfssUhT4M1MJD30Mws0SJ3e1m+vhcSS3FUS4vOepmNPg HcFnwg8qXNXSn1ahvYxZ2ISbu20C2uQj2XeJYsB4sQhsBzW/FPp7Z40nH1TMpqR3 m9hl4NSci25M9BchBzR3vLdltsdYVmGrX4kX2nZSTOXgymX58R+rBLZeyZ4+kMO1 /E0AUYBNiQ6+UN1NmN0abv0cD/GsvNc8nTEt2lB/IXkVGnz/nyj01pg5/5vrL7fx g1F5lBtaLADOmLd6FbvX4wK4BJO3/g== =yqHD -----END PGP SIGNATURE----- --QDIl5R72YNOeCxaP--