Hi Javier,

Am Freitag, 25. März 2016, 02:45:20 schrieb Javier Martinez Canillas:

Hello Krzysztof,

On 03/24/2016 05:12 AM, Krzysztof Kozlowski wrote:

quoted

The buck9 regulator of S2MPS11 PMIC had incorrect maximum voltage -
lower by 5 mV than specified by datasheet. This buck9 provides power to
other regulators, including LDO13 and LDO19 which supply the MMC2 (SD
card).

When constraints were applied, the depending regulators were not
providing enough power, leading to SD card detection errors:
	mmc1: card never left busy state
	mmc1: error -110 whilst initialising SD card

Fixes: 86a2d2ac5e5d ("ARM: dts: Add dts file for Odroid XU3 board")
Signed-off-by: Krzysztof Kozlowski <redacted>

---

The issue can be reproduced on next-20160324 with
bae4fdc88d7f7dda1 (regulator: core: Ensure we are at least in bounds for our constraints).
---
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 1bd507bfa750..82b2ba632cf6 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi

@@ -299,7 +299,7 @@
 			buck9_reg: BUCK9 {
 				regulator-name = "vdd_2.8v_ldo";
 				regulator-min-microvolt = <3000000>;
-				regulator-max-microvolt = <3750000>;
+				regulator-max-microvolt = <3755000>;
 				regulator-always-on;
 				regulator-boot-on;
 			};

I tested next-20160324 + $SUBJECT on an Odroid XU4 (with exynos_defconfig)
and while it's true that the patch makes the SD card error to go away, I see
that the s2mps11 regulator driver fails to probe due an -EINVAL being return
by machine_constraints_voltage() -> _regulator_do_set_voltage():

[    1.710300] vdd_2.8v_ldo: failed to apply 3755000-3755000uV constraint(-22)
[    1.716387] s2mps11-pmic s2mps11-regulator: regulator init failed for 46
[    1.734878] s2mps11-pmic: probe of s2mps11-regulator failed with error -22

I wonder how neither Markus nor you saw this issue when testing so maybe I'm
doing something wrong? Since AFAICT it's only working because the driver fails
to probe so the same effect can be achieved disabling CONFIG_REGULATOR_S2MPS11.

Best regards,

My first test yesterday was with next-20160324 + $SUBJECT, too, and I encountered the same
error of the regulator system as you.
As with next-20160324 I could not get the ethernet chip running (with or without $SUBJECT) I switched back to
next-20160323 + $SUBJECT and posted the result above.

Regards,
--
Markus 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel