From patchwork Fri Apr 29 13:24:51 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Raul Benet X-Patchwork-Id: 8982201 Return-Path: X-Original-To: patchwork-linux-mmc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 83D889F372 for ; Fri, 29 Apr 2016 13:25:04 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9C4B0201CE for ; Fri, 29 Apr 2016 13:25:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1A4BB200FF for ; Fri, 29 Apr 2016 13:25:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753077AbcD2NY7 (ORCPT ); Fri, 29 Apr 2016 09:24:59 -0400 Received: from mail-db3on0070.outbound.protection.outlook.com ([157.55.234.70]:3100 "EHLO emea01-db3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752964AbcD2NY6 (ORCPT ); Fri, 29 Apr 2016 09:24:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightblueoptics.onmicrosoft.com; s=selector1-lightblueoptics-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6GZ/GqBwbX8Ab68T6AwW1XcrjEVvHKu1kyA2DLMPCOM=; b=QiNvSPu0Cx8pUIXv4DQADzJwoZbzDGDMoQ33ootUm6ObaYeLlcOHkfhpoNxVvC59Zlg9b57PP/kUyHvybhaCcstE8Kj/bVAbErtEAmHyja4Gk3nBAKEe0Vj9c5RBghHgOr+VvB1Qk8K2GGudt6Ub2n5BLPL+yZqGCMbWXY1R7R0= Received: from VI1PR05MB1533.eurprd05.prod.outlook.com (10.164.85.151) by VI1PR05MB1536.eurprd05.prod.outlook.com (10.164.85.154) with Microsoft SMTP Server (TLS) id 15.1.477.8; Fri, 29 Apr 2016 13:24:51 +0000 Received: from VI1PR05MB1533.eurprd05.prod.outlook.com ([10.164.85.151]) by VI1PR05MB1533.eurprd05.prod.outlook.com ([10.164.85.151]) with mapi id 15.01.0477.014; Fri, 29 Apr 2016 13:24:51 +0000 From: Raul Benet To: Dong Aisheng CC: "linux-mmc@vger.kernel.org" Subject: RE: support for fixed 1.8V eMMC interface Thread-Topic: support for fixed 1.8V eMMC interface Thread-Index: AdGgehuO/h9XIl9rRa2xt7cz4pXarAAzYR6AADSxJ8A= Date: Fri, 29 Apr 2016 13:24:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=lightblueoptics.com; x-originating-ip: [46.17.166.146] x-ms-office365-filtering-correlation-id: 19b4779c-69e0-4944-eccd-08d37031a553 x-microsoft-exchange-diagnostics: 1; VI1PR05MB1536; 5:osBwrxmIDyuIK4L9bCNCtLREslfX7iw23tFX1wo3riRs6FKPESst7PddUyT5Gh5u34Hf5CCeIE7h/PLLcp+CFffZDHP4L+Rtm/rwdHBXUFw6n74HujoodhGEeN5vPTSksqVAx3i7+wDfaWZ9p44lBQ==; 24:E+/5zXiO/1sOY7H+NC0MK4Nviu+mGccVlbo5b1SuAOreblNBQ0eE0wki5i8TyevPcYFDYPrB/mw5WJCwC/eUZyExF7jBTCyZO6fd+Ekt+WU=; 7:v7kICCl0Nb9t/xt39aNL1ErOZHr0hD2usJhLPomh9HRcXcSS8x1T7tSz8hrRlICBOCM/DHICoeGyYaMvwB19x+HVTl8nUcsdVLj2fpuWH6+Hix3Hi/DHKZzQaMoCJYKCRIgadiRlPAbHC6ZN1xU81y/KH0bTw0/rMjNfbLqDLWF9cs6MR9GhRbUSA/6BMnnr x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR05MB1536; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521072)(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046); SRVR:VI1PR05MB1536; BCL:0; PCL:0; RULEID:; SRVR:VI1PR05MB1536; x-forefront-prvs: 0927AA37C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(24454002)(13464003)(66066001)(1411001)(5002640100001)(11100500001)(5004730100002)(76576001)(586003)(10400500002)(9686002)(5003600100002)(33656002)(110136002)(86362001)(575784001)(92566002)(189998001)(81166005)(4326007)(1096002)(1220700001)(3280700002)(54356999)(76176999)(3660700001)(50986999)(19580405001)(87936001)(19580395003)(74316001)(6116002)(3846002)(122556002)(102836003)(2906002)(2900100001)(2950100001)(15975445007)(5008740100001)(77096005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR05MB1536; H:VI1PR05MB1533.eurprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: lightblueoptics.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2016 13:24:51.6945 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: db60b8ee-e0f5-44d7-870b-20f8ac4962d8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB1536 Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham 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 Dong, Ulf, Thanks for your advice. I will pursue your suggestions. Regards, Raul Benet. -----Original Message----- From: Dong Aisheng [mailto:dongas86@gmail.com] Sent: 28 April 2016 13:15 To: Raul Benet Cc: linux-mmc@vger.kernel.org Subject: Re: support for fixed 1.8V eMMC interface On Wed, Apr 27, 2016 at 7:44 PM, Raul Benet wrote: > Hi, > > I am currently working on a design using i.MX6SL and Linux Kernel 3.14.52. Though I believe may question still applies to latest MMC code. > Our design uses an eMMC as boot device and main storage (ie: it contains u-boot, kernel, dtb and rootfs). > > The eMMC I/O rail is fixed in hardware to 1.8Volts. > The Processor SDIO I/O rail is controlled by the MMC driver. > > In 3.14.52, the MMC driver sets processor SDIO rail to 3v3 per default, and only when using HS DDR modes (which do not apply in our case) would it set it to 1.8V. > > I have seen that starting on 3.16, the function power_up() in drivers/mmc/core/core.c attempts at setting the regulator to 3v3, failing that it tries 1v8, failing that it tries 1v2. > > So I patched my kernel with that, and defined a fixed regulator with 1v8 in my dts, and set the vqmmc-supply to point to it. > But that doesn't work, because power_up() ultimately tries to call > set_voltage() on the vqmmc regulator, which doesn't seem to exist for > "regulator-fixed" type of regulators, and hence it fails in setting > all the rails, which ultimately means that it sets it to 3v3 ('cause > that is the default/initial value of the field in the ios struct) > It seems the 3.6 kernel you tried may still not support set voltage for fixed regulator. But i tried the latest kernel already supports it. > So my question is: how am I supposed to setup the MMC driver in my scenario (I/O at 1.8V always) ? > (I know I can go and force the rail to 1.8V by hacking > drivers/mmc/host/sdhci-esdhc-imx.c, but I would very much prefer to > avoid that) > Pls try the option 2 as Ulf pointed. You can refer to this patch: commit c00dc359e5e0b10de993651d8e73e60c41bf29cd Author: Bjorn Andersson Date: Wed Feb 5 12:30:26 2014 -0800 regulator: core: Allow regulator_set_voltage for fixed regulators Make it okay to call regulator_set_voltage on regulators with fixed voltage if the requested range overlaps the current/configured voltage. Signed-off-by: Bjorn Andersson Signed-off-by: Mark Brown Regards Dong Aisheng > Thanks , > Raul. > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" > in the body of a message to majordomo@vger.kernel.org More majordomo > info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index b38a6b669e8c..0cd1a3b8e589 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -2395,6 +2395,7 @@ int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV) struct regulator_dev *rdev = regulator->rdev; int ret = 0; int old_min_uV, old_max_uV; + int current_uV; mutex_lock(&rdev->mutex); @@ -2405,6 +2406,19 @@ int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV) if (regulator->min_uV == min_uV && regulator->max_uV == max_uV) goto out; + /* If we're trying to set a range that overlaps the current voltage, + * return succesfully even though the regulator does not support + * changing the voltage. + */ + if (!(rdev->constraints->valid_ops_mask & REGULATOR_CHANGE_VOLTAGE)) { + current_uV = _regulator_get_voltage(rdev); + if (min_uV <= current_uV && current_uV <= max_uV) { + regulator->min_uV = min_uV; + regulator->max_uV = max_uV; + goto out; + } + } + /* sanity check */ if (!rdev->desc->ops->set_voltage && !rdev->desc->ops->set_voltage_sel) {