From dcf5341f0150bc4c5bf37786e1198d2ff8fc2c38 Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Wed, 9 Mar 2016 20:38:59 +0100 Subject: [PATCH 01/10] ARM: dts: sun8i-q8-common: Do not set constraints on dc1sw regulator dc1sw is an on/off only regulator and as such it cannot have constraints. This is a limitation of the kernel regulator implementation which resolves supplies on the first regulator_get(), which is done after applying constraints, and applying the constrains will fail because it calls _regulator_get_voltage() and _regulator_do_set_voltage() both of which will fail on a switch regulator when there is no supply (yet). This causes registering of all axp22x regulators to fail with the following errors: [ 1.395249] vcc-lcd: failed to get the current voltage(-22) [ 1.405131] axp20x-regulator axp20x-regulator: Failed to register dc1sw [ 1.412436] axp20x-regulator: probe of axp20x-regulator failed with error -22 This commit removes the constrains on dc1sw / vcc-lcd fixing this problem note that dcdc1 itself is contrained to the exact same values, so this does not change anything. Signed-off-by: Hans de Goede Signed-off-by: Maxime Ripard --- arch/arm/boot/dts/sun8i-q8-common.dtsi | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi b/arch/arm/boot/dts/sun8i-q8-common.dtsi index 9d2b7e2f5975..346a49d805a7 100644 --- a/arch/arm/boot/dts/sun8i-q8-common.dtsi +++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi @@ -125,8 +125,6 @@ }; ®_dc1sw { - regulator-min-microvolt = <3000000>; - regulator-max-microvolt = <3000000>; regulator-name = "vcc-lcd"; }; From a0a966b83873f33778710a4fc59240244b0734a5 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Fri, 22 Apr 2016 09:26:52 +0200 Subject: [PATCH 02/10] ARM: EXYNOS: Properly skip unitialized parent clock in power domain on We want to skip reparenting a clock on turning on power domain, if we do not have the parent yet. The parent is obtained when turning the domain off. However due to a typo, the loop is continued on IS_ERR() of clock being reparented, not on the IS_ERR() of the parent. Theoretically this could lead to OOPS on first turn on of a power domain, if there was no turn off before. Practically that should never happen because all power domains are turned on by default (reset value, bootloader does not turn off them usually) so the first action will be always turn off. Fixes: 29e5eea06bc1 ("ARM: EXYNOS: Get current parent clock for power domain on/off") Reported-by: Vladimir Zapolskiy Signed-off-by: Krzysztof Kozlowski --- arch/arm/mach-exynos/pm_domains.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-exynos/pm_domains.c b/arch/arm/mach-exynos/pm_domains.c index 7c21760f590f..875a2bab64f6 100644 --- a/arch/arm/mach-exynos/pm_domains.c +++ b/arch/arm/mach-exynos/pm_domains.c @@ -92,7 +92,7 @@ static int exynos_pd_power(struct generic_pm_domain *domain, bool power_on) if (IS_ERR(pd->clk[i])) break; - if (IS_ERR(pd->clk[i])) + if (IS_ERR(pd->pclk[i])) continue; /* Skip on first power up */ if (clk_set_parent(pd->clk[i], pd->pclk[i])) pr_err("%s: error setting parent to clock%d\n", From f5515f9cdff136dc32517d4b81fe2b9091237b4a Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Mon, 25 Apr 2016 16:08:30 +0200 Subject: [PATCH 03/10] arm64: dts: r8a7795: Don't disable referenced optional scif clock MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit clk_get() on a disabled clock node will return -EPROBE_DEFER, which can cause drivers to be deferred forever if such clocks are referenced in their devices' clocks properties. Update the disabled external scif clock node so that it is not disabled to prevent this. Reported-by: Jürg Billeter Signed-off-by: Geert Uytterhoeven [simon: fix for v4.6 extracted from a larger patch targeted at v4.7] Signed-off-by: Simon Horman --- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index a7315ebe3883..706d2426024f 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi @@ -120,7 +120,6 @@ compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <0>; - status = "disabled"; }; soc { From 5086e5c79602a4620fbc3ec208f38e445982e301 Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Mon, 18 Apr 2016 13:06:06 +0300 Subject: [PATCH 04/10] ARM: dts: omap5-board-common: fix ldo1_reg and ldo4_reg ranges ldo4_reg is connected to DSS, and should always be 1.8V. However the The dts defines a range of 1.5V-1.8V, which requires somethings to set the actual voltage at runtime. Currently we set the voltage in omapdss driver. As the voltage must always be 1.8V, let's just define the range to 1.8V so that the driver doesn't need to deal with the voltage. In fact, the driver should not touch the voltage, except in the cases where the voltage needs to be changed at runtime. I presume the situation is the same for ldo1_reg, used for CSI, although I think it is not currently used in the mainline. Signed-off-by: Tomi Valkeinen Signed-off-by: Tony Lindgren --- arch/arm/boot/dts/omap5-board-common.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi index 902657d6713b..914bf4c47404 100644 --- a/arch/arm/boot/dts/omap5-board-common.dtsi +++ b/arch/arm/boot/dts/omap5-board-common.dtsi @@ -472,7 +472,7 @@ ldo1_reg: ldo1 { /* VDDAPHY_CAM: vdda_csiport */ regulator-name = "ldo1"; - regulator-min-microvolt = <1500000>; + regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; }; @@ -498,7 +498,7 @@ ldo4_reg: ldo4 { /* VDDAPHY_DISP: vdda_dsiport/hdmi */ regulator-name = "ldo4"; - regulator-min-microvolt = <1500000>; + regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; }; From 5607959a4d5b54dcc9a3572bdbf967dfda88ae66 Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Mon, 18 Apr 2016 13:06:07 +0300 Subject: [PATCH 05/10] ARM: dts: omap5-cm-t54: fix ldo1_reg and ldo4_reg ranges ldo4_reg is connected to DSS, and should always be 1.8V. However the The dts defines a range of 1.5V-1.8V, which requires somethings to set the actual voltage at runtime. Currently we set the voltage in omapdss driver. As the voltage must always be 1.8V, let's just define the range to 1.8V so that the driver doesn't need to deal with the voltage. In fact, the driver should not touch the voltage, except in the cases where the voltage needs to be changed at runtime. I presume the situation is the same for ldo1_reg, used for CSI, although I think it is not currently used in the mainline. Signed-off-by: Tomi Valkeinen Signed-off-by: Tony Lindgren --- arch/arm/boot/dts/omap5-cm-t54.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts b/arch/arm/boot/dts/omap5-cm-t54.dts index ecc591dc0778..4d87d9c6c86d 100644 --- a/arch/arm/boot/dts/omap5-cm-t54.dts +++ b/arch/arm/boot/dts/omap5-cm-t54.dts @@ -513,7 +513,7 @@ ldo1_reg: ldo1 { /* VDDAPHY_CAM: vdda_csiport */ regulator-name = "ldo1"; - regulator-min-microvolt = <1500000>; + regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; }; @@ -537,7 +537,7 @@ ldo4_reg: ldo4 { /* VDDAPHY_DISP: vdda_dsiport/hdmi */ regulator-name = "ldo4"; - regulator-min-microvolt = <1500000>; + regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; }; From e180feaf79b54d999329b194a3650f390acedf2c Mon Sep 17 00:00:00 2001 From: Ivaylo Dimitrov Date: Sat, 16 Apr 2016 09:20:28 +0300 Subject: [PATCH 06/10] ARM: dts: omap3: Fix ISP syscon register offset According to the TRM, SCM CONTROL_CSIRXFE register is on offset 0x6c Signed-off-by: Ivaylo Dimitrov Reviewed-By: Sebastian Reichel Signed-off-by: Tony Lindgren --- arch/arm/boot/dts/omap34xx.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi index 387dc31822fe..96f8ce7bd2af 100644 --- a/arch/arm/boot/dts/omap34xx.dtsi +++ b/arch/arm/boot/dts/omap34xx.dtsi @@ -46,7 +46,7 @@ 0x480bd800 0x017c>; interrupts = <24>; iommus = <&mmu_isp>; - syscon = <&scm_conf 0xdc>; + syscon = <&scm_conf 0x6c>; ti,phy-type = ; #clock-cells = <1>; ports { From 0698178c608e5f48ac78cde8c08260c2d7041a39 Mon Sep 17 00:00:00 2001 From: Ivaylo Dimitrov Date: Sun, 17 Apr 2016 17:29:23 +0300 Subject: [PATCH 07/10] ARM: dts: omap3-n900: Specify peripherals LDO regulators initial mode Without that, regulators are left in the mode last set by the bootloader or by the kernel the device was rebooted from. This leads to various problems, like non-working peripherals. Signed-off-by: Ivaylo Dimitrov Reviewed-By: Sebastian Reichel Reviewed-by: Javier Martinez Canillas Reviewed-by: Pavel Machek Signed-off-by: Tony Lindgren --- arch/arm/boot/dts/omap3-n900.dts | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts index b3c26a96a726..d9e2d9c6e999 100644 --- a/arch/arm/boot/dts/omap3-n900.dts +++ b/arch/arm/boot/dts/omap3-n900.dts @@ -329,6 +329,7 @@ regulator-name = "V28"; regulator-min-microvolt = <2800000>; regulator-max-microvolt = <2800000>; + regulator-initial-mode = <0x0e>; /* RES_STATE_ACTIVE */ regulator-always-on; /* due to battery cover sensor */ }; @@ -336,30 +337,35 @@ regulator-name = "VCSI"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; + regulator-initial-mode = <0x0e>; /* RES_STATE_ACTIVE */ }; &vaux3 { regulator-name = "VMMC2_30"; regulator-min-microvolt = <2800000>; regulator-max-microvolt = <3000000>; + regulator-initial-mode = <0x0e>; /* RES_STATE_ACTIVE */ }; &vaux4 { regulator-name = "VCAM_ANA_28"; regulator-min-microvolt = <2800000>; regulator-max-microvolt = <2800000>; + regulator-initial-mode = <0x0e>; /* RES_STATE_ACTIVE */ }; &vmmc1 { regulator-name = "VMMC1"; regulator-min-microvolt = <1850000>; regulator-max-microvolt = <3150000>; + regulator-initial-mode = <0x0e>; /* RES_STATE_ACTIVE */ }; &vmmc2 { regulator-name = "V28_A"; regulator-min-microvolt = <2800000>; regulator-max-microvolt = <3000000>; + regulator-initial-mode = <0x0e>; /* RES_STATE_ACTIVE */ regulator-always-on; /* due VIO leak to AIC34 VDDs */ }; @@ -367,6 +373,7 @@ regulator-name = "VPLL"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; + regulator-initial-mode = <0x0e>; /* RES_STATE_ACTIVE */ regulator-always-on; }; @@ -374,6 +381,7 @@ regulator-name = "VSDI_CSI"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; + regulator-initial-mode = <0x0e>; /* RES_STATE_ACTIVE */ regulator-always-on; }; @@ -381,6 +389,7 @@ regulator-name = "VMMC2_IO_18"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; + regulator-initial-mode = <0x0e>; /* RES_STATE_ACTIVE */ }; &vio { From 7472931f7f1e9d91f761dce30107ae345b61a5c3 Mon Sep 17 00:00:00 2001 From: "H. Nikolaus Schaller" Date: Mon, 18 Apr 2016 20:20:59 +0200 Subject: [PATCH 08/10] ARM: dts: omap5: fix range of permitted wakeup pinmux registers otherwise we can't define gpio1_wk14 Signed-off-by: H. Nikolaus Schaller Signed-off-by: Tony Lindgren --- arch/arm/boot/dts/omap5.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 38805ebbe2ba..120b6b80cd39 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -269,7 +269,7 @@ omap5_pmx_wkup: pinmux@c840 { compatible = "ti,omap5-padconf", "pinctrl-single"; - reg = <0xc840 0x0038>; + reg = <0xc840 0x003c>; #address-cells = <1>; #size-cells = <0>; #interrupt-cells = <1>; From 5616f36713ea77f57ae908bf2fef641364403c9f Mon Sep 17 00:00:00 2001 From: Sascha Hauer Date: Wed, 20 Apr 2016 13:34:31 +0000 Subject: [PATCH 09/10] ARM: SoCFPGA: Fix secondary CPU startup in thumb2 kernel The secondary CPU starts up in ARM mode. When the kernel is compiled in thumb2 mode we have to explicitly compile the secondary startup trampoline in ARM mode, otherwise the CPU will go to Nirvana. Signed-off-by: Sascha Hauer Reported-by: Steffen Trumtrar Suggested-by: Ard Biesheuvel Cc: stable@vger.kernel.org Signed-off-by: Dinh Nguyen Signed-off-by: Kevin Hilman --- arch/arm/mach-socfpga/headsmp.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-socfpga/headsmp.S b/arch/arm/mach-socfpga/headsmp.S index 5d94b7a2fb10..c160fa3007e9 100644 --- a/arch/arm/mach-socfpga/headsmp.S +++ b/arch/arm/mach-socfpga/headsmp.S @@ -13,6 +13,7 @@ #include .arch armv7-a + .arm ENTRY(secondary_trampoline) /* CPU1 will always fetch from 0x0 when it is brought out of reset. From 04b9665b54f7cdc184ea03b0687aaa6d9711646e Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Tue, 15 Mar 2016 22:34:45 +0100 Subject: [PATCH 10/10] ARM: davinci: only use NVMEM when available The davinci platform contains code that calls into the nvmem subsystem, but that might be a loadable module, causing a link error: arch/arm/mach-davinci/built-in.o: In function `davinci_get_mac_addr': :(.text+0x1088): undefined reference to `nvmem_device_read' arch/arm/mach-davinci/built-in.o: In function `read_factory_config': :(.text+0x214c): undefined reference to `nvmem_device_read' Also, when NVMEM is completely disabled, the functions fail with nonobvious error messages. This ensures we only call the API functions when the code is actually reachable from the board file, and otherwise prints a unique log message. Signed-off-by: Arnd Bergmann Fixes: bec3c11bad0e ("misc: at24: replace memory_accessor with nvmem_device_read") Signed-off-by: Sekhar Nori Signed-off-by: Kevin Hilman --- arch/arm/mach-davinci/board-mityomapl138.c | 5 +++++ arch/arm/mach-davinci/common.c | 5 +++++ 2 files changed, 10 insertions(+) diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c index d97c588550ad..bc4e63fa9808 100644 --- a/arch/arm/mach-davinci/board-mityomapl138.c +++ b/arch/arm/mach-davinci/board-mityomapl138.c @@ -121,6 +121,11 @@ static void read_factory_config(struct nvmem_device *nvmem, void *context) const char *partnum = NULL; struct davinci_soc_info *soc_info = &davinci_soc_info; + if (!IS_BUILTIN(CONFIG_NVMEM)) { + pr_warn("Factory Config not available without CONFIG_NVMEM\n"); + goto bad_config; + } + ret = nvmem_device_read(nvmem, 0, sizeof(factory_config), &factory_config); if (ret != sizeof(struct factory_config)) { diff --git a/arch/arm/mach-davinci/common.c b/arch/arm/mach-davinci/common.c index f55ef2ef2f92..742133b7266a 100644 --- a/arch/arm/mach-davinci/common.c +++ b/arch/arm/mach-davinci/common.c @@ -33,6 +33,11 @@ void davinci_get_mac_addr(struct nvmem_device *nvmem, void *context) char *mac_addr = davinci_soc_info.emac_pdata->mac_addr; off_t offset = (off_t)context; + if (!IS_BUILTIN(CONFIG_NVMEM)) { + pr_warn("Cannot read MAC addr from EEPROM without CONFIG_NVMEM\n"); + return; + } + /* Read MAC addr from EEPROM */ if (nvmem_device_read(nvmem, offset, ETH_ALEN, mac_addr) == ETH_ALEN) pr_info("Read MAC addr from EEPROM: %pM\n", mac_addr);