[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160329182725.GD2350@sirena.org.uk>
Date: Tue, 29 Mar 2016 11:27:25 -0700
From: Mark Brown <broonie@...nel.org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Bjorn Andersson <bjorn@...o.se>,
Krzysztof Kozlowski <k.kozlowski@...sung.com>,
Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
Liam Girdwood <lgirdwood@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
linux-mmc <linux-mmc@...r.kernel.org>,
linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
Javier Martinez Canillas <javier@....samsung.com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
linux-renesas-soc@...r.kernel.org
Subject: Re: [PATCH 2/2] regulator: core: Ensure we are at least in bounds
for our constraints
On Tue, Mar 29, 2016 at 08:05:34PM +0200, Geert Uytterhoeven wrote:
> sh_mobile_sdhi ee100000.sd: Got WP GPIO
> ======> sh_mobile_sdhi ee100000.sd: could not set regulator OCR (-22)
> gpio_rcar e6055400.gpio: sense irq = 6, type = 3
> sh_mobile_sdhi ee100000.sd: mmc0 base at 0xee100000 clock rate 97 MHz
> The line marked with the arrow is introduced by the changed check, and looks
> to be the origin of the failure.
This isn't making any sense. Why would a change in how we apply voltage
constraints on initial probe of the regulator have an impact here? The
changed code shouldn't even be executing at the point where the SDHCI
driver is trying to use the regulator. There's something else going on
here.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists