Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3500647imm; Thu, 17 May 2018 09:42:28 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpjZQIXOyExM1Jz3gE4p1pHT2RALetv7Jy4knsUT8e+ICWiQ/MHa38V+6vyp1T8AVvnk8o+ X-Received: by 2002:a17:902:7488:: with SMTP id h8-v6mr5948807pll.124.1526575348648; Thu, 17 May 2018 09:42:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526575348; cv=none; d=google.com; s=arc-20160816; b=dP9bP0r9US/eiW9R4+MHmJch0I/zA5Gh/fh0Ds33pCSkFKeCLGmSHataashNrw2FpT QZ4XJKb/qXNsFIYIZs4QbO25phCvfZzbqbuwJjVv/gybHqWZGZkINaOo3VwDZlG0N7qL ZOoH7dAOlNqhZeQBf36z+CNQoO3/junTcMQwbwBlH/fz7RodTA9tSuqMlAF4YVarSOjI 0yFT/ndG9ikfDVSgKGFe1F/S/CIGuuR4d1Ql4RZmVM6kmniRABpj324oFzmTT7Slo9Q4 ieIj2ivI+WPDymp0kQMA4c7pMiTAK7AK681aY1Ll9nFcQK1XvNXmJOWa3qGsvNNbMzUu wXLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:message-id:in-reply-to:subject:cc:to :from:dkim-signature:arc-authentication-results; bh=jcCzc1/d7Pew92LKM8sAyXisScESQEi3eB3onS3CS6s=; b=gDsT5zzzQqA7NkEBNQxpoCaKBHOHTpX/dvomfzIufJmjoxEpzFGOQaLRp7/gpy9RYr I1I0qsrK2ZyZG1wBG/fAOjk5QJ86jJ3CAidKVe9JqhXnYIFdDnGAhkrIgFmaBbb8Ym5a 7rYa496W4mJYboiljvqcOs7cgZ8vJAhr4EewNNNQypg/giWymllE7lASfaiXX8Fbujec Rts0QJPFBTAg6RHKedyv7UtOQE64/+hbPY9RJJyp2Qt341EYhBnVp4AxgEVAlGWxOe4d oFM4eoT82wuvOLZpZR7IfVwlYHGYfmqav7/V7vgihbmZZXHvZqfmR5kwLhhiQ7Ulu1BZ K3UQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=PkuN31I7; 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 p3-v6si5715420pfb.171.2018.05.17.09.42.13; Thu, 17 May 2018 09:42:28 -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=PkuN31I7; 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 S1752749AbeEQQl6 (ORCPT + 99 others); Thu, 17 May 2018 12:41:58 -0400 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:53794 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752348AbeEQQlz (ORCPT ); Thu, 17 May 2018 12:41:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; s=20170815-heliosphere; h=Date:Message-Id:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner: List-Archive; bh=jcCzc1/d7Pew92LKM8sAyXisScESQEi3eB3onS3CS6s=; b=PkuN31I7p/Th xkS1gpfjgq/VccQOds2nufEAGrfMB5gWtl6ZIB47UpUqs3Zjmr5PRdLpuWzs2n5gZokTva6WgmKu2 60n+8JSI+8a/xTKz98qDDZW4MWEXGMn9W+mOCIZQIaDd0vyJGYtoQcvgEoh9hNcx0TEPIlSuqNqLx DtvrM=; 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 1fJLyS-00014z-Gm; Thu, 17 May 2018 16:41:52 +0000 Received: by finisterre.ee.mobilebroadband (Postfix, from userid 1000) id A49E444007E; Thu, 17 May 2018 17:41:49 +0100 (BST) From: Mark Brown To: Douglas Anderson Cc: Mark Brown , broonie@kernel.org, mka@chromium.org, collinsd@codeaurora.org, Liam Girdwood , linux-kernel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Applied "regulator: core: Allow for regulators that can't be read at bootup" to the regulator tree In-Reply-To: <20180515220717.254950-1-dianders@chromium.org> Message-Id: <20180517164149.A49E444007E@finisterre.ee.mobilebroadband> Date: Thu, 17 May 2018 17:41:49 +0100 (BST) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The patch regulator: core: Allow for regulators that can't be read at bootup has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark From 84b3a7c9c6befe5ab4d49070fe7bcab2da22637e Mon Sep 17 00:00:00 2001 From: Douglas Anderson Date: Tue, 15 May 2018 15:07:17 -0700 Subject: [PATCH] regulator: core: Allow for regulators that can't be read at bootup Regulators attached via RPMh on Qualcomm sdm845 apparently are write-only. Specifically you can send a request for a certain voltage but you can't read back to see what voltage you've requested. What this means is that at bootup we have absolutely no idea what voltage we could be at. As discussed in the patches to try to support the RPMh regulators [1], the fact that regulators are write-only means that its driver's get_voltage_sel() should return an error code if it's called before any calls to set_voltage_sel(). This causes problems in machine_constraints_voltage() when trying to apply the constraints. A proposed fix was to come up with an error code that could be returned by get_voltage_sel() which would cause the regulator framework to simply try setting the voltage with the current constraints. In this patch I propose the error code -ENOTRECOVERABLE. In errno.h this error is described as "State not recoverable". Though the error code was originally intended "for robust mutexes", the description of the error code seems to apply here because we can't read the state of the regulator. Also note that the only existing user of this error code in the regulator framework is tps65090-regulator.c which returns this error code from the enable() call (not get_voltage() or get_voltage_sel()), so there should be no existing regulators that might accidentally get the new behavior. (Side note is that tps65090 seems to interpret this error code to mean an error that you can't recover from rather than some data that can't be recovered). [1] https://patchwork.kernel.org/patch/10340897/ Signed-off-by: Douglas Anderson Signed-off-by: Mark Brown --- drivers/regulator/core.c | 12 ++++++++++++ include/linux/regulator/driver.h | 7 +++++-- 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index d4803460a557..fe314ff56772 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -886,6 +886,18 @@ static int machine_constraints_voltage(struct regulator_dev *rdev, rdev->constraints->min_uV && rdev->constraints->max_uV) { int target_min, target_max; int current_uV = _regulator_get_voltage(rdev); + + if (current_uV == -ENOTRECOVERABLE) { + /* This regulator can't be read and must be initted */ + rdev_info(rdev, "Setting %d-%duV\n", + rdev->constraints->min_uV, + rdev->constraints->max_uV); + _regulator_do_set_voltage(rdev, + rdev->constraints->min_uV, + rdev->constraints->max_uV); + current_uV = _regulator_get_voltage(rdev); + } + if (current_uV < 0) { rdev_err(rdev, "failed to get the current voltage(%d)\n", diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h index 4fc96cb8e5d7..14e512ad6d4f 100644 --- a/include/linux/regulator/driver.h +++ b/include/linux/regulator/driver.h @@ -81,9 +81,12 @@ struct regulator_linear_range { * @set_voltage_sel: Set the voltage for the regulator using the specified * selector. * @map_voltage: Convert a voltage into a selector - * @get_voltage: Return the currently configured voltage for the regulator. + * @get_voltage: Return the currently configured voltage for the regulator; + * return -ENOTRECOVERABLE if regulator can't be read at + * bootup and hasn't been set yet. * @get_voltage_sel: Return the currently configured voltage selector for the - * regulator. + * regulator; return -ENOTRECOVERABLE if regulator can't + * be read at bootup and hasn't been set yet. * @list_voltage: Return one of the supported voltages, in microvolts; zero * if the selector indicates a voltage that is unusable on this system; * or negative errno. Selectors range from zero to one less than -- 2.17.0