From patchwork Tue Feb 4 05:54:28 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bjorn Andersson X-Patchwork-Id: 3573961 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 851C4C02DC for ; Tue, 4 Feb 2014 05:55:18 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id BA6AE2017D for ; Tue, 4 Feb 2014 05:55:17 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CE4FA2017B for ; Tue, 4 Feb 2014 05:55:16 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WAYyK-0004ZD-3j; Tue, 04 Feb 2014 05:55:00 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WAYyH-0004fG-PN; Tue, 04 Feb 2014 05:54:57 +0000 Received: from mail-la0-f53.google.com ([209.85.215.53]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WAYyB-0004eS-Hd for linux-arm-kernel@lists.infradead.org; Tue, 04 Feb 2014 05:54:55 +0000 Received: by mail-la0-f53.google.com with SMTP id e16so6012435lan.26 for ; Mon, 03 Feb 2014 21:54:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id; bh=RCvYxDOAcVgIhANqRIPEazEFWGrbwgLkIXVfAtXBCT0=; b=Nt03IrI2BAYH+JQwvCQaiT8LOBd4EoYZvSyZrU7xrlQ8Q5pK5JsNHxLw+FU4niqeFl j9iBRnRzn8zFzZjYDjgwoiuuUc1OVyvqkEdwWUc0qJ0L6PhqmXJzNnvKfj7UndkUz4Zk KbrkF2gSe+ap+mLM0X2AYOEdCX8M+b9JVfh+o6tnlgrlTDLicaCLNweg2cJvHSVM0F7b 1HiVE3qLWetjgWS8ntUJhs5/qNq7qczwXlFFx8zFMA0eOp16B2coxxjH9jfiVwgCkXUw UBxKqnm8GazPzCHAw3ArbkyRb0oumswukMYLrhNSORAJPH3uJ0ah9IcjHGIpgKot9ePg y7zQ== X-Gm-Message-State: ALoCoQnHyw7DRROvdsmgFOq2u+Ck6Dqt60A8+KkZgBlhlbhEkxTFUCo/31II1Nb22BpU90DIpqJn X-Received: by 10.112.134.38 with SMTP id ph6mr15838615lbb.16.1391493265770; Mon, 03 Feb 2014 21:54:25 -0800 (PST) Received: from buildbot.san.rr.com (cpe-76-167-68-231.san.res.rr.com. [76.167.68.231]) by mx.google.com with ESMTPSA id cu8sm23972071lbb.12.2014.02.03.21.54.22 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Feb 2014 21:54:24 -0800 (PST) From: Bjorn Andersson To: Liam Girdwood , Mark Brown , linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [PATCH] regulator: core: Make regulator object reflect configured voltage Date: Mon, 3 Feb 2014 21:54:28 -0800 Message-Id: <1391493268-3242-1-git-send-email-bjorn.andersson@sonymobile.com> X-Mailer: git-send-email 1.7.9.5 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140204_005451_727881_FC6CF646 X-CRM114-Status: UNSURE ( 9.07 ) X-CRM114-Notice: Please train this message. X-Spam-Score: -2.6 (--) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP In the case when a regulator is initialized from DT with equal min and max voltages the voltage is applied on initialization and future calls to regulator_set_voltage fails. This behavious is different than if the regulator is configured to be a span and therefor requires logic to handle this difference in the consumer driver. Eliminate this difference by populating the min_uV and max_uV of the newly created regulator from the constraints so that calles to regulator_set_voltage is considered no-ops and not a failure. Signed-off-by: Bjorn Andersson --- drivers/regulator/core.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index d85f313..9c82d37 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -1209,6 +1209,16 @@ static struct regulator *create_regulator(struct regulator_dev *rdev, _regulator_is_enabled(rdev)) regulator->always_on = true; + /* + * Make the regulator reflect the configured voltage selected in + * machine_constraints_voltage() + */ + if (rdev->constraints->apply_uV && + rdev->constraints->min_uV == rdev->constraints->max_uV) { + regulator->min_uV = rdev->constraints->min_uV; + regulator->max_uV = rdev->constraints->min_uV; + } + mutex_unlock(&rdev->mutex); return regulator; overflow_err: