From patchwork Thu Apr 28 12:15:17 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dong Aisheng X-Patchwork-Id: 8969271 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 185869F65D for ; Thu, 28 Apr 2016 12:15:33 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 00707202BE for ; Thu, 28 Apr 2016 12:15:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 75C8C20125 for ; Thu, 28 Apr 2016 12:15:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751513AbcD1MPV (ORCPT ); Thu, 28 Apr 2016 08:15:21 -0400 Received: from mail-qg0-f65.google.com ([209.85.192.65]:33617 "EHLO mail-qg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753282AbcD1MPS convert rfc822-to-8bit (ORCPT ); Thu, 28 Apr 2016 08:15:18 -0400 Received: by mail-qg0-f65.google.com with SMTP id 7so2200606qgj.0 for ; Thu, 28 Apr 2016 05:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=fX1CBAC2csrvUMIPUnB1+sWNW6rUxx9xW3k5KngwP30=; b=okBWMzDsiIT1LGUiSDoonm9eBaXJtV0Vfsu5oZ88mFDexvhyG87k5Ck/kc2fWvksfY bKG1M9NmUGifvQVMigM83KZjwrVNaQQK/DWIKLOMLrW+j7ppM0LTzsMMJf7wQeYIVzBC QR4wl0JMz1b4DnWpSTVIZ5gNpwdiEZ7TXpUc6GXYaEEdtWj0ezn1KTcBUANVlhMDtWSt 4VBbWdIrSn2KRpjXxrQJAOrS8tk9MBvPsm711COcEzmF9loj/5VAP0qUbYgZJh6lMgAF QN3S9av4mR06wtbgq+ejrjCYpF1qyHjCFuPG4eXYLm4uo+ovyuqRxztNTkiR+3V11bXW DRew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=fX1CBAC2csrvUMIPUnB1+sWNW6rUxx9xW3k5KngwP30=; b=ZB4zAhfI+TkCtPzMJa+tjzo2sLDPcKAAEG4ToSRARu6HcevtQGaPGeeUcya5xZ6dbs DiKIt7cTTj7DnfAvMegtieblBZ69yOPyLaWlwVhhmWUGo8yyAUpwCzYkZF4ghpEAAYW6 hXwwjnj4+HsKCm2qJPKTH/Fb/G35XCUKFIG386E5RNO4OREGEVdyON6QTND868Bd68FQ gyonDOuOHiHkRCk0fzHqZbns+l1HCRTVDQZotZbFGhTcNa2lDy5SEr8BLBGwf0YoEbJb T0vTO+Pw1tlnMMFy9oZ5tZWVV9xv/ghCbT7PbhfxIn7SbJD2m/ZHS9V5G9bOlKBtSFX1 bx/g== X-Gm-Message-State: AOPr4FWJtoO8eEBVQcHvoBce4vuJUqqluNQhTyktZMrLo9z1El8S00bm9o+tzZTzB/jOYT0bmMLqLEde0W8x7g== MIME-Version: 1.0 X-Received: by 10.140.91.103 with SMTP id y94mr13182337qgd.81.1461845717414; Thu, 28 Apr 2016 05:15:17 -0700 (PDT) Received: by 10.140.105.245 with HTTP; Thu, 28 Apr 2016 05:15:17 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Apr 2016 20:15:17 +0800 Message-ID: Subject: Re: support for fixed 1.8V eMMC interface From: Dong Aisheng To: Raul Benet Cc: "linux-mmc@vger.kernel.org" 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_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, 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 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 @@ -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) { 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 --- 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);