From patchwork Mon Aug 25 09:07:08 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Javier Martinez Canillas X-Patchwork-Id: 4773331 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id DFB789F2E8 for ; Mon, 25 Aug 2014 09:12:50 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 07B3B200F0 for ; Mon, 25 Aug 2014 09:12:50 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (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 33D5D200E3 for ; Mon, 25 Aug 2014 09:12:49 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1XLqFV-0000H4-6P; Mon, 25 Aug 2014 09:07:37 +0000 Received: from bhuna.collabora.co.uk ([93.93.135.160]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1XLqFR-0000CY-Sn for linux-arm-kernel@lists.infradead.org; Mon, 25 Aug 2014 09:07:35 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: javier) with ESMTPSA id 9FADF6004D4 Message-ID: <53FAFCBC.2050407@collabora.co.uk> Date: Mon, 25 Aug 2014 11:07:08 +0200 From: Javier Martinez Canillas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: Yuvaraj Cd , Doug Anderson Subject: Re: [PATCH v9 1/2] regulator: Add driver for max77802 PMIC PMIC regulators References: <1408350762-15520-1-git-send-email-javier.martinez@collabora.co.uk> <1408350762-15520-2-git-send-email-javier.martinez@collabora.co.uk> <53F73472.8010609@collabora.co.uk> <20140822144531.GV24407@sirena.org.uk> <53F7838F.8060906@collabora.co.uk> <20140822183054.GY24407@sirena.org.uk> <53F7BDD8.7060500@collabora.co.uk> In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140825_020734_231246_A45CEE00 X-CRM114-Status: GOOD ( 18.30 ) X-Spam-Score: -0.0 (/) Cc: "devicetree@vger.kernel.org" , linux-samsung-soc , "linux-kernel@vger.kernel.org" , sunil joshi , Abhilash Kesavan , Mark Brown , Alim Akhtar , Olof Johansson , Prashanth G , "linux-arm-kernel@lists.infradead.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, 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 Hello Yuvaraj, On 08/25/2014 10:22 AM, Yuvaraj Cd wrote: >>> Good question. I'm not that familiar with the dw_mmc host controller nor >>> its driver implementation so I'll let Yuvaraj or Doug to answer that. > Well,here it goes! > 1. Power ON the board LDO4CTRL1[7:6] 11b > 2. dw_mmc driver enable the vqmmc. > 3. checks for UHS support, complete the voltage switching t0 1.8V > 4. Does warm reset by reboot command. > 5. mmc core calls mmc_set_ios() with MMC_POWER_OFF. > 6. dw_mmc driver cut-off the regulator with LDO4CTRL1[7:6] is 00b > 7.dw_mmc driver enable the vqmmc. > But after step 7 also, LD4CTRL[7:6] is 00b. Ok, so the dw_mmc driver is enabling vqmmc, that's good. >> >> I haven't seen the issue that Yuvaraj is reporting (but I also haven't >> picked up all of the relevant patches and tried to reproduce), so I'm >> going to have to leave it to Yuvaraj to answer. > static int max77802_enable(struct regulator_dev *rdev) > { > struct max77802_regulator_prv *max77802 = rdev_get_drvdata(rdev); > int id = rdev_get_id(rdev); > int shift = max77802_get_opmode_shift(id); > return regmap_update_bits(rdev->regmap, > rdev->desc->enable_reg,rdev->desc->enable_mask,max77802->opmode[id] << > shift); > } > I think in the above code snippet, the "val" is what we got it during > the probe.We always write that value for enabling this regulator(which > is LDO4CTRL1[7:6] 00b after warm reset) which is not correct according > the MAX77802 manual. >> I see, so probably until we have a way to define the operating mode for each regulator using DT we should set the opmode to normal when enabling a regulator independently of the value the hardware register reported on probe. Can you please test the following change [0] so I can post as a proper patch? Doug, Mark do you think that forcing the regulator to opmode normal when enabling is the right solution here? Best regards, Javier [0] linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c index ad1caa9..917b5ab 100644 --- a/drivers/regulator/max77802.c +++ b/drivers/regulator/max77802.c @@ -180,7 +180,7 @@ static int max77802_enable(struct regulator_dev *rdev) return regmap_update_bits(rdev->regmap, rdev->desc->enable_reg, rdev->desc->enable_mask, - max77802->opmode[id] << shift); + MAX77802_OPMODE_NORMAL << shift); } _______________________________________________