From patchwork Wed Mar 30 15:25:00 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Brown X-Patchwork-Id: 8698441 Return-Path: X-Original-To: patchwork-linux-samsung-soc@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 2562F9F39A for ; Wed, 30 Mar 2016 15:25:31 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 5D8A420386 for ; Wed, 30 Mar 2016 15:25:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8DCCE2037F for ; Wed, 30 Mar 2016 15:25:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754585AbcC3PZ0 (ORCPT ); Wed, 30 Mar 2016 11:25:26 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:56786 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754116AbcC3PZY (ORCPT ); Wed, 30 Mar 2016 11:25:24 -0400 Received: from [12.139.153.2] (helo=finisterre) by mezzanine.sirena.org.uk with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1alHzZ-0000rr-5v; Wed, 30 Mar 2016 15:25:10 +0000 Received: from broonie by finisterre with local (Exim 4.87) (envelope-from ) id 1alHzQ-0006JY-UK; Wed, 30 Mar 2016 08:25:00 -0700 Date: Wed, 30 Mar 2016 08:25:00 -0700 From: Mark Brown To: Haibo Chen Cc: Geert Uytterhoeven , Bjorn Andersson , Krzysztof Kozlowski , Ivaylo Dimitrov , Liam Girdwood , "linux-kernel@vger.kernel.org" , Ulf Hansson , linux-mmc , linux-samsung-soc , Javier Martinez Canillas , Marek Szyprowski , "linux-renesas-soc@vger.kernel.org" Message-ID: <20160330152500.GU2350@sirena.org.uk> References: <56F0624C.8010004@gmail.com> <20160327090859.GH5028@sirena.org.uk> <20160329145823.GK2350@sirena.org.uk> <20160329182725.GD2350@sirena.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Cookie: If anything can go wrong, it will. User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: 12.139.153.2 X-SA-Exim-Mail-From: broonie@sirena.org.uk X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Subject: Re: [PATCH 2/2] regulator: core: Ensure we are at least in bounds for our constraints X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-samsung-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Mar 30, 2016 at 09:07:21AM +0000, Haibo Chen wrote: Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. > In our sdhci.c, we call the function > regulator_set_voltage ---> regulator_set_voltage_unlocked(struct regulator *regulator, int min_uV, int max_uV) > here, the parameter min_uV is 3300000, and the max_uV is 3400000 > > currently with your patch (the upper operator is &&), when insert a SD3.0 card, > it will do the sanity check, and return -EINVAL > but when I change the upper operator from && to !=, > before the sanity check, it will first get the current_uV, and then go to out. > > I'm not familiar with regulator common code. Hope the upper describe can help you debug this issue. No, that's not helping clarify anything. To repeat what I said to Geert this patch changes code that is only called when the regulator is probed. This means that the changed code is not running when the SDHCI code is running. You need to investigate what exactly is causing the error. Just randomly thrashing around with a separate bit of code with no coharent explanation for what you think is happening is not helping here, we need some analysis of what is going on. The change you are both proposing is guaranteed to break other boards since it means that the case we supported originally where we set a specific voltage that is specified by setting equal minimum and maximum constraints is no longer going have the voltage applied. Having taken another look I *suspect* that the SDHCI code is broken in the way it enumerates the set of voltages that can be set and that this will probably trigger in other situations where the set of voltages that can be set is limited but I can't put my finger on it, someone with the ability to run the code will need to investigate. The following patch *might* help the SDHCI but I'm just guessing and like I say it looks like this is flagging up a problem in the SDHCI code. > > -----Original Message----- > > From: linux-mmc-owner@vger.kernel.org [mailto:linux-mmc- > > owner@vger.kernel.org] On Behalf Of Mark Brown Please don't top post, reply in line with needed context. This allows readers to readily follow the flow of conversation and understand what you are talking about and also helps ensure that everything in the discussion is being addressed. diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c index f45106a44635..cd828dbf9d52 100644 --- a/drivers/regulator/of_regulator.c +++ b/drivers/regulator/of_regulator.c @@ -43,10 +43,12 @@ static void of_get_regulation_constraints(struct device_node *np, constraints->max_uV = pval; /* Voltage change possible? */ - if (constraints->min_uV && constraints->max_uV) { + if (constraints->min_uV != constraints->max_uV) constraints->valid_ops_mask |= REGULATOR_CHANGE_VOLTAGE; + + /* Do we have a voltage range, if so try to apply it? */ + if (constraints->min_uV && constraints->max_uV) constraints->apply_uV = true; - } if (!of_property_read_u32(np, "regulator-microvolt-offset", &pval)) constraints->uV_offset = pval;