* [PATCH] ARM: dts: fix incorrect vdd_arm voltage range for Exynos4412 based boards
From: Thomas Abraham @ 2014-01-18 11:11 UTC (permalink / raw)
To: linux-arm-kernel
From: Thomas Abraham <thomas.ab@samsung.com>
To allow Exynos4412 based Odroidx and Origen-quad boards to operate between
200MHz to 1.4Ghz, update the vdd_arm voltage range to operate between these
cpu clock speeds.
Cc: Dongjin Kim <tobetter@gmail.com>
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
---
arch/arm/boot/dts/exynos4412-odroidx.dts | 2 +-
arch/arm/boot/dts/exynos4412-origen.dts | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 9804fcb..12459b0 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -251,7 +251,7 @@
buck2_reg: BUCK2 {
regulator-name = "vdd_arm";
regulator-min-microvolt = <900000>;
- regulator-max-microvolt = <1300000>;
+ regulator-max-microvolt = <1350000>;
regulator-always-on;
regulator-boot-on;
};
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts b/arch/arm/boot/dts/exynos4412-origen.dts
index 6bc0539..388f035 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -459,8 +459,8 @@
buck2_reg: BUCK2 {
regulator-name = "vdd_arm";
- regulator-min-microvolt = <925000>;
- regulator-max-microvolt = <1300000>;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1350000>;
regulator-always-on;
regulator-boot-on;
op_mode = <1>; /* Normal Mode */
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH] ARM: dts: add max77686 pmic node for smdk5250 board
From: Thomas Abraham @ 2014-01-18 11:09 UTC (permalink / raw)
To: linux-arm-kernel
From: Thomas Abraham <thomas.ab@samsung.com>
Add Maxim 77686 PMIC node for Exynos5250 based SMDK5250 board.
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 142 +++++++++++++++++++++++++++++
1 files changed, 142 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 3e69837..5c1b7d9 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -36,6 +36,148 @@
compatible = "samsung,s524ad0xd1";
reg = <0x50>;
};
+
+ max77686 at 09 {
+ compatible = "maxim,max77686";
+ reg = <0x09>;
+
+ voltage-regulators {
+ ldo1_reg: LDO1 {
+ regulator-name = "P1.0V_LDO_OUT1";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ };
+
+ ldo2_reg: LDO2 {
+ regulator-name = "P1.2V_LDO_OUT2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ };
+
+ ldo3_reg: LDO3 {
+ regulator-name = "P1.8V_LDO_OUT3";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ ldo4_reg: LDO4 {
+ regulator-name = "P2.8V_LDO_OUT4";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ ldo5_reg: LDO5 {
+ regulator-name = "P1.8V_LDO_OUT5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ ldo6_reg: LDO6 {
+ regulator-name = "P1.1V_LDO_OUT6";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-always-on;
+ };
+
+ ldo7_reg: LDO7 {
+ regulator-name = "P1.1V_LDO_OUT7";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-always-on;
+ };
+
+ ldo8_reg: LDO8 {
+ regulator-name = "P1.0V_LDO_OUT8";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ };
+
+ ldo10_reg: LDO10 {
+ regulator-name = "P1.8V_LDO_OUT10";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ ldo11_reg: LDO11 {
+ regulator-name = "P1.8V_LDO_OUT11";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ ldo12_reg: LDO12 {
+ regulator-name = "P3.0V_LDO_OUT12";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ };
+
+ ldo13_reg: LDO13 {
+ regulator-name = "P1.8V_LDO_OUT13";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ ldo14_reg: LDO14 {
+ regulator-name = "P1.8V_LDO_OUT14";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ ldo15_reg: LDO15 {
+ regulator-name = "P1.0V_LDO_OUT15";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ };
+
+ ldo16_reg: LDO16 {
+ regulator-name = "P1.8V_LDO_OUT16";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ buck1_reg: BUCK1 {
+ regulator-name = "vdd_mif";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck2_reg: BUCK2 {
+ regulator-name = "vdd_arm";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck3_reg: BUCK3 {
+ regulator-name = "vdd_int";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck4_reg: BUCK4 {
+ regulator-name = "vdd_g3d";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck5_reg: BUCK5 {
+ regulator-name = "P1.8V_BUCK_OUT5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+ };
};
vdd: fixed-regulator at 0 {
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH] ARM: imx6: dmo edmqmx6 updates
From: Shawn Guo @ 2014-01-18 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389876750-29880-1-git-send-email-s.hauer@pengutronix.de>
On Thu, Jan 16, 2014 at 01:52:26PM +0100, Sascha Hauer wrote:
> Philipp Zabel (1):
> ARM: dts: imx6: edmqmx6: add PF0100 PMIC to device tree
>
> Sascha Hauer (3):
> ARM: dts: imx6: edmqmx6: Add usdhc4 (emmc) support
> ARM: dts: imx6: edmqmx6: Add sata support
> ARM: dts: imx6: edmqmx6: Add LED support
Applied all 4, thanks.
^ permalink raw reply
* [PATCH v2] ARM: dts: imx6: Add DFI FS700-M60 board support
From: Shawn Guo @ 2014-01-18 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389949752-9617-1-git-send-email-s.hauer@pengutronix.de>
On Fri, Jan 17, 2014 at 10:09:12AM +0100, Sascha Hauer wrote:
> The DFI FS700-M60 is a q7 board with i.MX6 quad, dual, duallite or solo
> SoC. This adds support for it.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Applied, thanks.
^ permalink raw reply
* [PATCH v5] ARM: DTS: imx5* imx6*, use imx51-ssi
From: Shawn Guo @ 2014-01-18 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389949662-11172-1-git-send-email-mpa@pengutronix.de>
On Fri, Jan 17, 2014 at 10:07:42AM +0100, Markus Pargmann wrote:
> imx51-ssi and imx21-ssi are different IPs. imx51-ssi supports online
> reconfiguration and needs this for correct interaction with SDMA. This
> patch adds imx51-ssi before each imx21-ssi for all imx5/imx6 SoCs.
>
> Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
> ---
> Hi Shawn,
>
> This is the patch including the two added compatibles in imx50.dtsi for
> fsl,imx51-ssi. That is the only change in v5.
>
> Regards,
>
> Markus
>
>
> arch/arm/boot/dts/imx50.dtsi | 6 +++++-
> arch/arm/boot/dts/imx53.dtsi | 10 +++++++---
> arch/arm/boot/dts/imx6qdl.dtsi | 12 +++++++++---
> arch/arm/boot/dts/imx6sl.dtsi | 12 +++++++++---
> 4 files changed, 30 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
> index 01c0499..47df15f 100644
> --- a/arch/arm/boot/dts/imx50.dtsi
> +++ b/arch/arm/boot/dts/imx50.dtsi
> @@ -140,7 +140,9 @@
> };
>
> ssi2: ssi at 50014000 {
> - compatible = "fsl,imx50-ssi", "fsl,imx21-ssi";
> + compatible = "fsl,imx50-ssi",
> + "fsl,imx51-ssi",
> + "fsl,imx21-ssi";
> reg = <0x50014000 0x4000>;
> interrupts = <30>;
> clocks = <&clks IMX5_CLK_SSI2_IPG_GATE>;
> @@ -446,6 +448,8 @@
>
> ssi1: ssi at 63fcc000 {
> compatible = "fsl,imx50-ssi", "fsl,imx21-ssi";
This line should removed then. I fixed it up and applied the patch.
Shawn
> + compatible = "fsl,imx50-ssi", "fsl,imx51-ssi",
> + "fsl,imx21-ssi";
> reg = <0x63fcc000 0x4000>;
> interrupts = <29>;
> clocks = <&clks IMX5_CLK_SSI1_IPG_GATE>;
> diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
> index 4dbde25..73e103b 100644
> --- a/arch/arm/boot/dts/imx53.dtsi
> +++ b/arch/arm/boot/dts/imx53.dtsi
> @@ -171,7 +171,9 @@
> };
>
> ssi2: ssi at 50014000 {
> - compatible = "fsl,imx53-ssi", "fsl,imx21-ssi";
> + compatible = "fsl,imx53-ssi",
> + "fsl,imx51-ssi",
> + "fsl,imx21-ssi";
> reg = <0x50014000 0x4000>;
> interrupts = <30>;
> clocks = <&clks IMX5_CLK_SSI2_IPG_GATE>;
> @@ -590,7 +592,8 @@
> };
>
> ssi1: ssi at 63fcc000 {
> - compatible = "fsl,imx53-ssi", "fsl,imx21-ssi";
> + compatible = "fsl,imx53-ssi", "fsl,imx51-ssi",
> + "fsl,imx21-ssi";
> reg = <0x63fcc000 0x4000>;
> interrupts = <29>;
> clocks = <&clks IMX5_CLK_SSI1_IPG_GATE>;
> @@ -617,7 +620,8 @@
> };
>
> ssi3: ssi at 63fe8000 {
> - compatible = "fsl,imx53-ssi", "fsl,imx21-ssi";
> + compatible = "fsl,imx53-ssi", "fsl,imx51-ssi",
> + "fsl,imx21-ssi";
> reg = <0x63fe8000 0x4000>;
> interrupts = <96>;
> clocks = <&clks IMX5_CLK_SSI3_IPG_GATE>;
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index 8a86502..cf7956e 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -247,7 +247,9 @@
> };
>
> ssi1: ssi at 02028000 {
> - compatible = "fsl,imx6q-ssi","fsl,imx21-ssi";
> + compatible = "fsl,imx6q-ssi",
> + "fsl,imx51-ssi",
> + "fsl,imx21-ssi";
> reg = <0x02028000 0x4000>;
> interrupts = <0 46 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clks 178>;
> @@ -260,7 +262,9 @@
> };
>
> ssi2: ssi at 0202c000 {
> - compatible = "fsl,imx6q-ssi","fsl,imx21-ssi";
> + compatible = "fsl,imx6q-ssi",
> + "fsl,imx51-ssi",
> + "fsl,imx21-ssi";
> reg = <0x0202c000 0x4000>;
> interrupts = <0 47 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clks 179>;
> @@ -273,7 +277,9 @@
> };
>
> ssi3: ssi at 02030000 {
> - compatible = "fsl,imx6q-ssi","fsl,imx21-ssi";
> + compatible = "fsl,imx6q-ssi",
> + "fsl,imx51-ssi",
> + "fsl,imx21-ssi";
> reg = <0x02030000 0x4000>;
> interrupts = <0 48 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clks 180>;
> diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
> index a449c4f..95bb37b 100644
> --- a/arch/arm/boot/dts/imx6sl.dtsi
> +++ b/arch/arm/boot/dts/imx6sl.dtsi
> @@ -226,7 +226,9 @@
> };
>
> ssi1: ssi at 02028000 {
> - compatible = "fsl,imx6sl-ssi","fsl,imx21-ssi";
> + compatible = "fsl,imx6sl-ssi",
> + "fsl,imx51-ssi",
> + "fsl,imx21-ssi";
> reg = <0x02028000 0x4000>;
> interrupts = <0 46 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clks IMX6SL_CLK_SSI1>;
> @@ -238,7 +240,9 @@
> };
>
> ssi2: ssi at 0202c000 {
> - compatible = "fsl,imx6sl-ssi","fsl,imx21-ssi";
> + compatible = "fsl,imx6sl-ssi",
> + "fsl,imx51-ssi",
> + "fsl,imx21-ssi";
> reg = <0x0202c000 0x4000>;
> interrupts = <0 47 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clks IMX6SL_CLK_SSI2>;
> @@ -250,7 +254,9 @@
> };
>
> ssi3: ssi at 02030000 {
> - compatible = "fsl,imx6sl-ssi","fsl,imx21-ssi";
> + compatible = "fsl,imx6sl-ssi",
> + "fsl,imx51-ssi",
> + "fsl,imx21-ssi";
> reg = <0x02030000 0x4000>;
> interrupts = <0 48 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clks IMX6SL_CLK_SSI3>;
> --
> 1.8.5.2
>
^ permalink raw reply
* [PATCH] dts: i.MX: Add aliases
From: Shawn Guo @ 2014-01-18 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389876261-29087-1-git-send-email-s.hauer@pengutronix.de>
On Thu, Jan 16, 2014 at 01:44:17PM +0100, Sascha Hauer wrote:
> Sascha Hauer (4):
> ARM: dts: imx53: Add mmc aliases
> ARM: dts: imx6q: Add spi4 alias
> ARM: dts: imx6qdl: Add mmc aliases
> ARM: dts: imx51: Add mmc aliases
Applied all, thanks.
^ permalink raw reply
* [PATCH] ARM: dts: imx6qdl-sabreauto: Add LVDS support
From: Shawn Guo @ 2014-01-18 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389739887-21272-1-git-send-email-festevam@gmail.com>
On Tue, Jan 14, 2014 at 08:51:27PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Add LVDS support for mx6 sabreauto boards.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Applied, thanks.
Regarding the additional change that is required by componentised device
adoption for imx-drm, let's deal with it when it comes.
Shawn
> ---
> arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 43 ++++++++++++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> index 088b0d2..47c5a3f 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> @@ -22,6 +22,14 @@
> spdif-controller = <&spdif>;
> spdif-in;
> };
> +
> + backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm3 0 5000000>;
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + default-brightness-level = <7>;
> + status = "okay";
> + };
> };
>
> &ecspi1 {
> @@ -86,6 +94,10 @@
> fsl,pins = <MX6QDL_GPMI_NAND_PINGRP1>;
> };
>
> + pinctrl_pwm3: pwm1grp {
> + fsl,pins = <MX6QDL_PWM3_PINGRP1>;
> + };
> +
> pinctrl_spdif: spdifgrp {
> fsl,pins = <
> MX6QDL_PAD_KEY_COL3__SPDIF_IN 0x1b0b0
> @@ -118,6 +130,37 @@
> };
> };
>
> +&ldb {
> + status = "okay";
> +
> + lvds-channel at 0 {
> + fsl,data-mapping = "spwg";
> + fsl,data-width = <18>;
> + status = "okay";
> +
> + display-timings {
> + native-mode = <&timing0>;
> + timing0: hsd100pxn1 {
> + clock-frequency = <65000000>;
> + hactive = <1024>;
> + vactive = <768>;
> + hback-porch = <220>;
> + hfront-porch = <40>;
> + vback-porch = <21>;
> + vfront-porch = <7>;
> + hsync-len = <60>;
> + vsync-len = <10>;
> + };
> + };
> + };
> +};
> +
> +&pwm3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm3>;
> + status = "okay";
> +};
> +
> &spdif {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_spdif>;
> --
> 1.8.1.2
>
^ permalink raw reply
* [PATCHv2 0/2] ARM: dts: imx53: add support for Ka-Ro TX53 modules
From: Shawn Guo @ 2014-01-18 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389860123-14874-1-git-send-email-LW@KARO-electronics.de>
On Thu, Jan 16, 2014 at 09:15:21AM +0100, Lothar Wa?mann wrote:
> This patch adds support for the Ka-Ro electronics GmbH TX53 modules.
> There are two distinct module types. One with an LVDS display
> interface and SATA support, the other with a parallel LCD
> interface and no SATA interface.
>
> Changes wrt. v1:
> - set the '#pwm-cells' property locally due to the changed
> pwm-polarity patch that made this property optional.
> see <1389859585-14006-3-git-send-email-LW@KARO-electronics.de>
Applied both, thanks.
But please be aware that componentised device adoption required by
moving imx-drm out of staging tree will need some additional change.
Let's fixed it up when it comes.
Shawn
^ permalink raw reply
* [PATCH v6 0/3] AArch64: KGDB support
From: Vijay Kilari @ 2014-01-18 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140116134550.GA7496@arm.com>
Hi Catalin,
On Thu, Jan 16, 2014 at 7:15 PM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Thu, Dec 19, 2013 at 11:50:48AM +0000, vijay.kilari at gmail.com wrote:
>> Vijaya Kumar K (3):
>> AArch64: KGDB: Add Basic KGDB support
>> AArch64: KGDB: Add step debugging support
>> KGDB: make kgdb_breakpoint() as noinline
>
> I gave them a try and now I have some doubts about your testing
> methodology:
>
> 1. There is no HAVE_ARCH_KGDB anywhere in these patches, so
> the code here isn't compiled.
>
OK, I will send a patch
> 2. There are several compiler warnings that need to be addressed.
>
> 3. I enabled CONFIG_KGDB_TESTS and CONFIG_KGDB_TESTS_ON_BOOT and that's
> what really scared me.
>
Are you refering to these warning?. I don't see any warning in the
patched files. I will fix these.
drivers/misc/kgdbts.c: In function 'check_single_step':
drivers/misc/kgdbts.c:353:2: warning: format '%lx' expects argument of
type 'long unsigned int', but argument 2 has type 'u64' [-Wformat]
drivers/misc/kgdbts.c:379:3: warning: format '%lx' expects argument of
type 'long unsigned int', but argument 2 has type 'u64' [-Wformat]
drivers/misc/kgdbts.c: In function 'emul_sstep_put':
drivers/misc/kgdbts.c:494:3: warning: format '%lx' expects argument of
type 'long unsigned int', but argument 2 has type 'u64' [-Wformat]
kernel/debug/debug_core.c: In function 'kgdb_cpu_enter':
kernel/debug/debug_core.c:498:4: warning: value computed is not used
[-Wunused-value]
kernel/debug/debug_core.c:513:5: warning: value computed is not used
[-Wunused-value]
> Please address these before we can consider the patches for merging.
>
> --
> Catalin
^ permalink raw reply
* [PATCH 1/2] USB: at91: fix the number of endpoint parameter
From: Jean-Christophe PLAGNIOL-VILLARD @ 2014-01-18 5:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389927565-22477-1-git-send-email-voice.shen@atmel.com>
On 10:59 Fri 17 Jan , Bo Shen wrote:
> In sama5d3 SoC, there are 16 endpoints. As the USBA_NR_ENDPOINTS
> is only 7. So, fix it for sama5d3 SoC using the udc->num_ep.
>
> Signed-off-by: Bo Shen <voice.shen@atmel.com>
> ---
>
> drivers/usb/gadget/atmel_usba_udc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/atmel_usba_udc.c b/drivers/usb/gadget/atmel_usba_udc.c
> index 2cb52e0..7e67a81 100644
> --- a/drivers/usb/gadget/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/atmel_usba_udc.c
> @@ -1670,7 +1670,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
> if (ep_status) {
> int i;
>
> - for (i = 0; i < USBA_NR_ENDPOINTS; i++)
> + for (i = 0; i < udc->num_ep; i++)
no the limit need to specified in the driver as a checkpoint by the compatible
or platform driver id
Best Regards,
J.
> if (ep_status & (1 << i)) {
> if (ep_is_control(&udc->usba_ep[i]))
> usba_control_irq(udc, &udc->usba_ep[i]);
> --
> 1.8.5.2
>
^ permalink raw reply
* [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
From: Chen-Yu Tsai @ 2014-01-18 4:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZOD4zeA8T5kbJ4c5NsnuzHCg1mw8rRMYNT9c4R-Qnc6A@mail.gmail.com>
On Sat, Jan 18, 2014 at 7:11 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, Jan 17, 2014 at 6:43 PM, Chen-Yu Tsai <wens@csie.org> wrote:
>> On Sat, Jan 18, 2014 at 12:47 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
>>>> +- NAME_shutdown-gpios : GPIO phandle to shutdown control
>>>> + (phandle must be the second)
>>>> +- NAME_reset-gpios : GPIO phandle to reset control
>>>> +
>>>> +NAME must match the rfkill-name property. NAME_shutdown-gpios or
>>>> +NAME_reset-gpios, or both, must be defined.
>>>> +
>>>
>>> I don't understand this part. Why do you include the name in the
>>> gpios property, rather than just hardcoding the property strings
>>> to "shutdown-gpios" and "reset-gpios"?
>>
>> This quirk is a result of how gpiod_get_index implements device tree
>> lookup.
>
> Why can't it just have a single property "gpios", where the first
> element is the reset GPIO and the second is the shutdown GPIO?
>
> rfkill-gpio does this:
>
> gpio = devm_gpiod_get_index(&pdev->dev, rfkill->reset_name, 0);
> gpio = devm_gpiod_get_index(&pdev->dev, rfkill->shutdown_name, 1);
>
> The passed con ID name parameter is only there for the device
> tree case it seems. (ACPI ignores it.) So what about you just
> don't pass it at all and patch it to do like this instead:
>
> gpio = devm_gpiod_get_index(&pdev->dev, NULL, 0);
> gpio = devm_gpiod_get_index(&pdev->dev, NULL, 1);
I'd like that. It's much cleaner.
> Heikki, are you OK with this change?
>
> I think this is actually necessary if the ACPI and DT unification
> pipe dream shall limp forward, we cannot have arguments passed
> that have a semantic effect on DT but not on ACPI... Drivers
> that are supposed to use both ACPI and DT will always
> have to pass NULL as con ID.
>
>> If con_id is given, it is prepended to "gpios" as the property string.
>> con_id is also used as the label passed to gpiod_request, which is
>> then shown in /sys/kernel/debug/gpio.
>
> If your problem is really what turns up in debugfs, then we need
> to figure out a way to label gpios outside of the *gpiod_get* calls.
Let's add a gpiod_set_label call. Currently there's a desc_set_label
in gpiolib, which is static inlined. We can either rename and promote
it to non-static, or add a new wrapping function.
> The string passed in *gpiod_get* is a "connection ID" not a proper
> name for the GPIO.
I see. Perhaps we should not pass this to gpiod_request as the label,
or add a comment stating consumers can use the new gpiod_set_label call
to change it.
Cheers,
ChenYu
^ permalink raw reply
* [PATCH 04/20] ARM64 / ACPI: Introduce arm_core.c and its related head file
From: Hanjun Guo @ 2014-01-18 4:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117141241.GH16003@mudshark.cambridge.arm.com>
On 2014-1-17 22:12, Will Deacon wrote:
> On Fri, Jan 17, 2014 at 12:24:58PM +0000, Hanjun Guo wrote:
>> Introduce arm_core.c and its related head file, after this patch,
>> we can get ACPI tables from firmware on ARM64 now.
>>
>> Signed-off-by: Al Stone <al.stone@linaro.org>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>
> [...]
>
>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>> index bd9bbd0..2210353 100644
>> --- a/arch/arm64/kernel/setup.c
>> +++ b/arch/arm64/kernel/setup.c
>> @@ -41,6 +41,7 @@
>> #include <linux/memblock.h>
>> #include <linux/of_fdt.h>
>> #include <linux/of_platform.h>
>> +#include <linux/acpi.h>
>>
>> #include <asm/cputype.h>
>> #include <asm/elf.h>
>> @@ -225,6 +226,11 @@ void __init setup_arch(char **cmdline_p)
>>
>> arm64_memblock_init();
>>
>> + /* Parse the ACPI tables for possible boot-time configuration */
>> + acpi_boot_table_init();
>> + early_acpi_boot_init();
>> + acpi_boot_init();
>
> Do we really need *three* back-to-back calls for ACPI to initialise?
Sorry, my colleague Graeme had integrate them as one function but I
forgot to merge them in this patch, my bad, will update it in next
version.
Thanks
Hanjun
^ permalink raw reply
* [PATCH 1/3] ACPI / idle: Move idle_boot_override out of the arch directory
From: Hanjun Guo @ 2014-01-18 3:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D9F8E8.8030602@linaro.org>
On 2014-1-18 11:45, Hanjun Guo wrote:
> On 2014-1-17 20:06, Sudeep Holla wrote:
>> On 17/01/14 02:03, Hanjun Guo wrote:
>>> Move idle_boot_override out of the arch directory to be a single enum
>>> including both platforms values, this will make it rather easier to
>>> avoid ifdefs around which definitions are for which processor in
>>> generally used ACPI code.
>>>
>>> IDLE_FORCE_MWAIT for IA64 is not used anywhere, so romove it.
>>>
>>> No functional change in this patch.
>>>
>>> Suggested-by: Alan <gnomes@lxorguk.ukuu.org.uk>
>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>>> ---
[...]
>>> diff --git a/include/linux/cpu.h b/include/linux/cpu.h
>>> index 03e235ad..e324561 100644
>>> --- a/include/linux/cpu.h
>>> +++ b/include/linux/cpu.h
>>> @@ -220,6 +220,14 @@ void cpu_idle(void);
>>>
>>> void cpu_idle_poll_ctrl(bool enable);
>>>
>>> +enum idle_boot_override {
>>> + IDLE_NO_OVERRIDE = 0,
>>> + IDLE_HALT,
>>> + IDLE_NOMWAIT,
>>> + IDLE_POLL,
>>> + IDLE_POWERSAVE_OFF
>>> +};
>>> +
>>
>> I do understand the idea behind this change, but IMO HALT and MWAIT are x86
>> specific and may not make sense for other architectures.
>
> yes, this is the strange part, the value is arch-dependent.
>
>>
>> It will also require every architecture using ACPI to export
>> boot_option_idle_override which may not be really required.
>
> so, how about forget this patch and move boot_option_idle_override
> related code into arch directory such as arch/x86/acpi/boot.c for
> x86?
The general idea is that we can move all the arch-dependent codes
in ACPI driver to arch directory, then make codes in drivers/acpi/
arch independent.
Thanks
Hanjun
^ permalink raw reply
* [PATCH] clk: Export more clk-provider functions
From: Stephen Boyd @ 2014-01-18 3:47 UTC (permalink / raw)
To: linux-arm-kernel
Allow drivers to be compiled as modules by exporting more clock
provider functions.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
drivers/clk/clk.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 0b27b543dacf..2e83cf643db0 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -547,16 +547,19 @@ struct clk_hw *__clk_get_hw(struct clk *clk)
{
return !clk ? NULL : clk->hw;
}
+EXPORT_SYMBOL_GPL(__clk_get_hw);
u8 __clk_get_num_parents(struct clk *clk)
{
return !clk ? 0 : clk->num_parents;
}
+EXPORT_SYMBOL_GPL(__clk_get_num_parents);
struct clk *__clk_get_parent(struct clk *clk)
{
return !clk ? NULL : clk->parent;
}
+EXPORT_SYMBOL_GPL(__clk_get_parent);
struct clk *clk_get_parent_by_index(struct clk *clk, u8 index)
{
@@ -570,6 +573,7 @@ struct clk *clk_get_parent_by_index(struct clk *clk, u8 index)
else
return clk->parents[index];
}
+EXPORT_SYMBOL_GPL(clk_get_parent_by_index);
unsigned int __clk_get_enable_count(struct clk *clk)
{
@@ -601,6 +605,7 @@ unsigned long __clk_get_rate(struct clk *clk)
out:
return ret;
}
+EXPORT_SYMBOL_GPL(__clk_get_rate);
unsigned long __clk_get_flags(struct clk *clk)
{
@@ -649,6 +654,7 @@ bool __clk_is_enabled(struct clk *clk)
out:
return !!ret;
}
+EXPORT_SYMBOL_GPL(__clk_is_enabled);
static struct clk *__clk_lookup_subtree(const char *name, struct clk *clk)
{
@@ -740,6 +746,7 @@ out:
return best;
}
+EXPORT_SYMBOL_GPL(__clk_mux_determine_rate);
/*** clk api ***/
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH 1/3] ACPI / idle: Move idle_boot_override out of the arch directory
From: Hanjun Guo @ 2014-01-18 3:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D91CE2.3050704@arm.com>
On 2014-1-17 20:06, Sudeep Holla wrote:
> On 17/01/14 02:03, Hanjun Guo wrote:
>> Move idle_boot_override out of the arch directory to be a single enum
>> including both platforms values, this will make it rather easier to
>> avoid ifdefs around which definitions are for which processor in
>> generally used ACPI code.
>>
>> IDLE_FORCE_MWAIT for IA64 is not used anywhere, so romove it.
>>
>> No functional change in this patch.
>>
>> Suggested-by: Alan <gnomes@lxorguk.ukuu.org.uk>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>> arch/ia64/include/asm/processor.h | 3 ---
>> arch/powerpc/include/asm/processor.h | 1 -
>> arch/x86/include/asm/processor.h | 3 ---
>> arch/x86/kernel/process.c | 1 +
>> include/linux/cpu.h | 8 ++++++++
>> 5 files changed, 9 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/ia64/include/asm/processor.h b/arch/ia64/include/asm/processor.h
>> index 5a84b3a..ccd63a0 100644
>> --- a/arch/ia64/include/asm/processor.h
>> +++ b/arch/ia64/include/asm/processor.h
>> @@ -698,9 +698,6 @@ prefetchw (const void *x)
>>
>> extern unsigned long boot_option_idle_override;
>>
>> -enum idle_boot_override {IDLE_NO_OVERRIDE=0, IDLE_HALT, IDLE_FORCE_MWAIT,
>> - IDLE_NOMWAIT, IDLE_POLL};
>> -
>> void default_idle(void);
>>
>> #define ia64_platform_is(x) (strcmp(x, ia64_platform_name) == 0)
>> diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
>> index fc14a38..06689c0 100644
>> --- a/arch/powerpc/include/asm/processor.h
>> +++ b/arch/powerpc/include/asm/processor.h
>> @@ -440,7 +440,6 @@ static inline unsigned long get_clean_sp(unsigned long sp, int is_32)
>> #endif
>>
>> extern unsigned long cpuidle_disable;
>> -enum idle_boot_override {IDLE_NO_OVERRIDE = 0, IDLE_POWERSAVE_OFF};
>>
>
> I don't think it is used in the context of ACPI. Though it's same variable name,
> it looks like it just used as boot to override the cpuidle option.
> Does it still make any sense to combine this ?
Yes, it is not related to ACPI on powerpc, I will investigate it will cause
compile warning or not if I don't combine this.
>
>> extern int powersave_nap; /* set if nap mode can be used in idle loop */
>> extern void power7_nap(void);
>> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
>> index 7b034a4..4bee51a 100644
>> --- a/arch/x86/include/asm/processor.h
>> +++ b/arch/x86/include/asm/processor.h
>> @@ -729,9 +729,6 @@ extern void init_amd_e400_c1e_mask(void);
>> extern unsigned long boot_option_idle_override;
>> extern bool amd_e400_c1e_detected;
>>
>> -enum idle_boot_override {IDLE_NO_OVERRIDE=0, IDLE_HALT, IDLE_NOMWAIT,
>> - IDLE_POLL};
>> -
>> extern void enable_sep_cpu(void);
>> extern int sysenter_setup(void);
>>
>> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
>> index 3fb8d95..62764ff 100644
>> --- a/arch/x86/kernel/process.c
>> +++ b/arch/x86/kernel/process.c
>> @@ -17,6 +17,7 @@
>> #include <linux/stackprotector.h>
>> #include <linux/tick.h>
>> #include <linux/cpuidle.h>
>> +#include <linux/cpu.h>
>> #include <trace/events/power.h>
>> #include <linux/hw_breakpoint.h>
>> #include <asm/cpu.h>
>> diff --git a/include/linux/cpu.h b/include/linux/cpu.h
>> index 03e235ad..e324561 100644
>> --- a/include/linux/cpu.h
>> +++ b/include/linux/cpu.h
>> @@ -220,6 +220,14 @@ void cpu_idle(void);
>>
>> void cpu_idle_poll_ctrl(bool enable);
>>
>> +enum idle_boot_override {
>> + IDLE_NO_OVERRIDE = 0,
>> + IDLE_HALT,
>> + IDLE_NOMWAIT,
>> + IDLE_POLL,
>> + IDLE_POWERSAVE_OFF
>> +};
>> +
>
> I do understand the idea behind this change, but IMO HALT and MWAIT are x86
> specific and may not make sense for other architectures.
yes, this is the strange part, the value is arch-dependent.
>
> It will also require every architecture using ACPI to export
> boot_option_idle_override which may not be really required.
so, how about forget this patch and move boot_option_idle_override
related code into arch directory such as arch/x86/acpi/boot.c for
x86?
>
> Further the only users of boot_option_idle_override(outside x86) are:
>
> 1. drivers/acpi/processor_core.c
> Your second patch is moving this to x86 specific code anyway
>
> 2. drivers/acpi/processor_idle.c
> Currently idle driver is bit x86 specific and needs modifications to get it
> working on ARM
Yes, That's why I did not enable acpi idle driver on ARM64 for now.
Thanks
Hanjun
^ permalink raw reply
* [PATCH v4 3/4] ARM: pinctrl: Add Broadcom Capri pinctrl driver
From: Matt Porter @ 2014-01-18 2:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D98B99.5050604@broadcom.com>
On Fri, Jan 17, 2014 at 11:59:21AM -0800, Sherman Yin wrote:
> On 14-01-16 05:19 AM, Linus Walleij wrote:
> >On Sat, Dec 21, 2013 at 3:13 AM, Sherman Yin <syin@broadcom.com> wrote:
> >
> >'> Adds pinctrl driver for Broadcom Capri (BCM281xx) SoCs.
> >>
> >>Signed-off-by: Sherman Yin <syin@broadcom.com>
> >>Reviewed-by: Christian Daudt <bcm@fixthebug.org>
> >>Reviewed-by: Matt Porter <matt.porter@linaro.org>
> >>---
> >>v4: - PINCTRL selected in Kconfig, PINCTRL_CAPRI selected in bcm_defconfig
> >> - make use of regmap
> >> - change CAPRI_PIN_UPDATE from macro to inline function.
> >> - Handle pull-up strength arg in Ohm instead of enum
> >
> >Patch applied. It is really good now! It's late before the merge
> >window, but you've done a tremendous work on this driver and
> >I don't want to delay its deployment further.
>
> Great, thanks for the support and reviews!
Very nice! Now after having completely missing something fundamental on
my reviews, I feel compelled to bring it up at the 11^H^H12th hour.
That is, this is the *only* BCM281xx driver to be named Capri, both in
the filename and driver code, but also in the binding compatible. We
didn't do that on anything else that's gone upstream to date. This
really introduces an unfortunate inconsistency as it obscures which
SoC family this binding and driver belong with.
I wonder if Linus would accept a rename at this point (too late for 3.14
presumably, but for 3.15) of s/capri/bcm281xx throughout, bcm11351 for
the compatible string, as we have for the machine compatible, and also
BCM281XX for the Kconfig option. If not, I'll survive, but it pains me
to see one thing completely different out of this entire family. If
nothing else, it would be great to address the compatible string before
this hits the 3.14 release.
Linus?
-Matt
^ permalink raw reply
* [PATCH 1/2] ARM: EXYNOS: Support Suspend-to-RAM on EXYNOS5420
From: Abhilash Kesavan @ 2014-01-18 2:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPQV+nO=Xe=z669QxCJSerrm-xP0b=WtyPveyh2uTcM2B3i5KQ@mail.gmail.com>
Hi,
I have observed on an average 2 failures in 100 S2R cycles even with
the mainline kernel on SMDK5420. The system resumes fine after an
aborted suspend. I have isolated the problem to the MCT_L0 interrupt.
On disabling the forwarding of just this interrupt from the
distributor there are no failures for over 1000 cycles.
Code exists to mask the system timer wake-up and post-resume in a
failed case the WAKEUP_STAT register does not show the timer having
woken up the system (I am checking this quite early post-resume).
On suspending the system, the non-boot cores would free their timer
irqs (in the MCT driver) but not the boot core. So, there is a
possibility that L0 irq might wake the system if it races with
suspend. Is this a possibility ? Please correct me if my understanding
is wrong.
Abhilash
On Sat, Jan 11, 2014 at 1:06 AM, Jonathan Kliegman <kliegs@chromium.org> wrote:
>
>
>
> On Fri, Dec 20, 2013 at 8:15 PM, Doug Anderson <dianders@chromium.org>
> wrote:
>>
>> Tomasz,
>>
>> On Fri, Dec 20, 2013 at 1:19 PM, Tomasz Figa <tomasz.figa@gmail.com>
>> wrote:
>> > Hi,
>> >
>> > On Friday 20 of December 2013 15:56:38 sunil joshi wrote:
>> >> Hi Abhilash,
>> >> I saw another patch in chrome tree ..by Andrew Bresticker
>> >> which may be relevant here ..
>> >>
>> >> Just wondering if you missed adding this ? or this is not needed ?
>> >> You did not face any issue in getting core to suspend ?
>> >>
>> >>
>> >> ------------------------------------------------------------------------------------------
>> >> commit 95402d816b9f1a05ce633f7ff64b4c939c142482
>> >> Author: Andrew Bresticker <abrestic@chromium.org>
>> >> Date: Mon Jul 15 13:14:36 2013 -0700
>> >>
>> >> arm: exynos: disable all interrupts on Exynos5420 before suspend
>> >>
>> >> Disable all interrupts from the GIC before entering suspend on
>> >> Exynos5420 as is done on Exynos5250. If interrupts are enabled, we
>> >> may receive an interrupt after entering WFI but before the PMU has
>> >> suspended the system, causing suspend to fail.
>> >>
>> >> BUG=chrome-os-partner:20523
>> >> TEST=Run suspend_stress_test on Pit and observe that entering
>> >> suspend
>> >> no longer occasionally fails with the "Failed to suspend the
>> >> system"
>> >> error in exynos_cpu_suspend().
>> >
>> > A question about this for Chromium and LSI guys:
>> >
>> > If you find out that there is already a pending interrupt before you
>> > enter
>> > the sleep mode, isn't it more reasonable to cancel the process ASAP and
>> > handle the event instead of entering the sleep just to leave it?
>> >
>> > I believe this should be both more efficient with respect to power usage
>> > and latency, because sleep-wakeup transition takes time and power.
>> >
>> > Do you have any reason to think the opposite?
>>
>> I'm not actually sure I know every last detail, but...
>>
>> From what I remember on 5250 there was some type of mystery interrupt
>> that was hitting in the system but that wasn't identifiable as any
>> particular interrupt source. I think that this was an attempt to deal
>> with that with a heavy hammer. I don't think it was a very elegant
>> solution and it would be nice to do better.
>>
>> Ah, here's the original CL:
>> <https://chromium-review.googlesource.com/#/c/34541/>. ...as you can
>> see I wasn't super happy about it at the time but was OK with it going
>> in since it was very late in the Chromebook release cycle and we
>> needed suspend/resume to be reliable.
>>
>> Another fairly questionable CL:
>> <https://chromium-review.googlesource.com/#/c/37991/>
>>
>> It would be super great if we could get suspend/resume reliable
>> upstream without those hacks.
>
> My recollection is the first CL (34541 that I put in) didn't actually do
> anything itself, but had enough of a change in the timings that it made
> behavior better. The second CL (37991) is definitely a hack that covered up
> the issue and I don't think anyone was happy with but given the timing it
> was the best alternative.
>
> I did a lot of debugging and don't believe I ever found an actual interrupt
> firing that caused this. I'm pretty sure this was related to power settings
> and it just failing to enter the suspend state.
>>
>>
>> -Doug
>
>
^ permalink raw reply
* [PATCH v7 net-next 2/4] sh_eth: Add support for r7s72100
From: David Miller @ 2014-01-18 2:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389918150-19058-3-git-send-email-horms+renesas@verge.net.au>
From: Simon Horman <horms+renesas@verge.net.au>
Date: Fri, 17 Jan 2014 09:22:28 +0900
> The r7s72100 SoC includes a fast ethernet controller.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied.
^ permalink raw reply
* [PATCH v7 net-next 1/4] sh_eth: Use bool as return type of sh_eth_is_gether()
From: David Miller @ 2014-01-18 2:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389918150-19058-2-git-send-email-horms+renesas@verge.net.au>
From: Simon Horman <horms+renesas@verge.net.au>
Date: Fri, 17 Jan 2014 09:22:27 +0900
> Return a boolean from sh_eth_is_gether() and refactor it as a one-liner.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Applied.
^ permalink raw reply
* Deadlock in do_page_fault() on ARM (old kernel)
From: Russell King - ARM Linux @ 2014-01-18 1:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D9D16C.9080501@signal11.us>
On Fri, Jan 17, 2014 at 07:57:16PM -0500, Alan Ott wrote:
> On 01/17/2014 08:46 AM, Russell King - ARM Linux wrote:
>> My suspicion therefore is that some other thread must have died while
>> holding the mmap_sem, so there's probably a kernel oops earlier...
>> that's my best guess at the moment without seeing the full backtrace.
>
> There's no oops that I'm able to see.
>
> Each of the tasks which lockdep reports as "holding" mmap_sem are
> blocking for it. If some other task had taken it and then crashed, I
> assume lockdep would list the crashed task as also holding the resource
> in the printout.
My point is this:
- the five (or six) threads which are trying to take the mmap_sem in
read-mode in the fault handler are all blocked on it - they haven't
taken the lock, which will only happen because there's a pending writer.
- of these in your original post, there are two which faulted from
__copy_to_user_std(). __copy_to_user_std() doesn't take the mmap_sem -
this is the non-uaccess-with-memcpy path.
- the pending writers are the two threads in sys_mmap_pgoff(), both of
which are blocked waiting to gain the write lock.
- there are no *other* threads holding the mmap_sem lock.
So... there's a question here how we got into this state - and frankly
I don't know. What I do see from your latest dump is that there's two
unknown modules there - something called rcu2m and another called
buttoms, and there are two threads inside ioctls there. Both have
faulted from the function at 0xc0d2a394 (which won't appear in the
backtrace, but is most likely __copy_to_user_std.)
So, in the absence of you saying anything about there being any preceding
oopses, my conclusion now is that one of those modules is taking the
mmap_sem itself, and is the culpret inducing this deadlock.
Note that your dump ([2]) in your reply was just the hung task detector
printing out the stacktrace for a few tasks, not the full all-threads
stack dump which I was expecting.
So I'm pulling out these conclusions from the very little information
you're supplying.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCHv13 00/40] ARM: TI SoC clock DT conversion
From: Nishanth Menon @ 2014-01-18 1:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMjB-Np1hkHfAPWeCxGK20OzWBt5zumFzDp5WLKTrntUAQ@mail.gmail.com>
On 01/17/2014 06:23 PM, Olof Johansson wrote:
> On Fri, Jan 17, 2014 at 4:19 PM, Nishanth Menon <nm@ti.com> wrote:
>> On 01/17/2014 06:12 PM, Olof Johansson wrote:
>>> On Fri, Jan 17, 2014 at 4:02 PM, Nishanth Menon <nm@ti.com> wrote:
>>>
>>>> clk-next-6a0cad9 + next-20140117 multi_v7_defconfig + CONFIG_LPAE=y:
>>>> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s21GRhEOj4
>>>> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s20zcNsD8h
>>>> 3: am3517-evm: Boot PASS: http://slexy.org/raw/s27U9IfRKR
>>>> 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2zYyeonec
>>>> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21iCRjTHK
>>>> 6: beagleboard-xm: Boot PASS: http://slexy.org/raw/s20bPGL3Sz
>>>> 7: beaglebone-black: Boot PASS: http://slexy.org/raw/s21AhFmkCk
>>>> 8: crane: No Image built - Missing platform support?:
>>>> 9: dra7: Boot FAIL: http://slexy.org/raw/s21Qh3sQRu
>>>> * DRA7 not enabled?
>>>> 10: ldp: Boot PASS: http://slexy.org/raw/s21fvBfBgs
>>>> 11: panda-es: Boot FAIL: http://slexy.org/raw/s20RsgVUZJ
>>>> * known issue (https://patchwork.kernel.org/patch/3084521/)
>>>> 12: sdp2430: Boot FAIL: v6 platform - wont boot with multi_v7
>>>> 13: sdp3430: Boot PASS: http://slexy.org/raw/s20rhjjBwe
>>>> 14: sdp4430: Boot PASS: http://slexy.org/raw/s2My0UfNPm
>>>> 15: uevm: Boot PASS: http://slexy.org/raw/s21aqF6eMN
>>>> TOTAL = 15 boards, Booted Boards = 11, No Boot boards = 4
>>>
>>>
>>> I have a hard time believing the above; A8/A9 boards are not bootable
>>> with CONFIG_LPAE=y...
>>
>> You are right! Drat!! I had CONFIG_LPAE=y in my script, not
>> CONFIG_ARM_LPAE=y! Grrr...
>>
>> Retest in a around 30 mins..
>
> It's not a huge concern though; it's unlikely that LPAE makes a
> functional difference on this patch series. It's still useful to catch
> warnings, etc (most likely printk formats and the like).
>
I suppose, as expected:
clk-next-6a0cad9 + next-20140117 multi_v7_defconfig + CONFIG_ARM_LPAE=y
* .config = http://slexy.org/view/s208uSeQS8
* Build warnings: http://slexy.org/raw/s20n7YwbwN
1: am335x-evm: Boot FAIL: http://slexy.org/raw/s20tF2eUZG
2: am335x-sk: Boot FAIL: http://slexy.org/raw/s2uP65lOMQ
3: am3517-evm: Boot FAIL: http://slexy.org/raw/s2Lx13gsFZ
4: am37x-evm: Boot FAIL: http://slexy.org/raw/s2eOLXxvsT
5: am43xx-epos: Boot FAIL: http://slexy.org/raw/s24coJzGvR
6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s240WznuPd
7: BeagleBone-Black: Boot FAIL: http://slexy.org/raw/s20NG2UVTU
8: crane: No Image built - Missing platform support?:
9: dra7: Boot FAIL: http://slexy.org/raw/s21T3RpHx2
^^ might probably boot if we enable CONFIG_SOC_DRA7XX in multi_v7
(this is another A15 target)
10: ldp: Boot FAIL: http://slexy.org/raw/s2F4VO9hDM
11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s20HpzT1jW
12: sdp2430: Boot FAIL: http://slexy.org/raw/s21snV1EvL
13: sdp3430: Boot FAIL: http://slexy.org/raw/s2FwkVfG5R
14: sdp4430: Boot FAIL: http://slexy.org/raw/s2xiWxlpTj
15: uevm: Boot PASS: http://slexy.org/raw/s2LWUOmfiG
TOTAL = 15 boards, Booted Boards = 1, No Boot boards = 14
I am running a defconfig set check on next-20140117 and will do one
with next-20140118 once that is ready for comparison results
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH] dt-bindings: qcom: Fix warning with duplicate dt define
From: Stephen Boyd @ 2014-01-18 1:05 UTC (permalink / raw)
To: linux-arm-kernel
arch/arm/boot/dts/include/dt-bindings/clock/qcom,mmcc-msm8974.h:60:0:
warning: "RBCPR_CLK_SRC" redefined
Rename this to MMSS_RBCPR_CLK_SRC to avoid conflicts with the
RBCPR clock in the gcc header.
Reported-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
include/dt-bindings/clock/qcom,mmcc-msm8974.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/dt-bindings/clock/qcom,mmcc-msm8974.h b/include/dt-bindings/clock/qcom,mmcc-msm8974.h
index 04d318d1187a..032ed87ef0f3 100644
--- a/include/dt-bindings/clock/qcom,mmcc-msm8974.h
+++ b/include/dt-bindings/clock/qcom,mmcc-msm8974.h
@@ -57,7 +57,7 @@
#define EXTPCLK_CLK_SRC 40
#define HDMI_CLK_SRC 41
#define VSYNC_CLK_SRC 42
-#define RBCPR_CLK_SRC 43
+#define MMSS_RBCPR_CLK_SRC 43
#define CAMSS_CCI_CCI_AHB_CLK 44
#define CAMSS_CCI_CCI_CLK 45
#define CAMSS_CSI0_AHB_CLK 46
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* Deadlock in do_page_fault() on ARM (old kernel)
From: Alan Ott @ 2014-01-18 0:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117134646.GL27282@n2100.arm.linux.org.uk>
On 01/17/2014 08:46 AM, Russell King - ARM Linux wrote:
> On Wed, Jan 15, 2014 at 08:13:04PM -0500, Alan Ott wrote:
>> So my questions are:
>> 1. Why don't I see a full backtrace beyond the exception stack? It's the
>> same when dump_stack() is called manually.
> No idea - it looks like you're not using frame pointers, but are using
> the unwinder. Full backtraces can always be created with frame pointers,
> it's just that unwinding seems unreliable.
Hi Russell,
I managed to get frame pointers turned on, which in this kernel version,
seems like it requires the unwinder to be turned off[1].
When I built with frame pointers, the backtraces show differently. It
only shows the frames which were _not_ shown with the unwinder.
Backtrace at [2]. As you can see, it shows the non-exception stack dumps
ending at places which can't page fault (and if it did page fault in
those locations, it wouldn't try to take the mmap_sem lock). Its as
though it shows what's in the modules but not what's in the image, where
with the unwinder, it showed what's in the image and not what's in the
modules[3].
> I think we do need to see the full backtrace here - from looking at the
> full state dump, I don't see any sign of the mmap_sem being held except
> by an attempt to process a fault, and two threads trying to do a
> sys_mmap_pgoff().
The lockdep printout at the end of [4] (which is the original log I sent
the other day) shows do_page_fault() holding mmap_sem in six tasks and
sys_mmap_pgoff() holding it in two. (I don't like the term "held" in the
lockdep printout and believe it to mean "held or waiting for," based on
my analysis of the rw_semaphore code.)
Each of those tasks seems to be blocking for it.
> My suspicion therefore is that some other thread must have died while
> holding the mmap_sem, so there's probably a kernel oops earlier...
> that's my best guess at the moment without seeing the full backtrace.
There's no oops that I'm able to see.
Each of the tasks which lockdep reports as "holding" mmap_sem are
blocking for it. If some other task had taken it and then crashed, I
assume lockdep would list the crashed task as also holding the resource
in the printout.
Thanks for having a look at this,
Alan.
[1] It seems a little strange to me even in the newest kernel:
1: lib/Kconfig.debug specifies FRAME_POINTER . The text of this instance
shows up when one searches for FRAME_POINTER in menuconfig. It can
become selected even though the dependencies listed here are not met.
2: arch/arm/Kconfig.debug also specifies FRAME_POINTER, with a
dependency only on !THUMB2_KERNEL, defaulting to yes on !ARM_UNWIND
3: ARM doens't set ARCH_WANT_FRAME_POINTERS
[2] http://www.signal11.us/~alan/stack_dump_with_frame_pointers.txt
Note: This is a sysrq dump of the locks held at lockup time and then the
automatic hung task detection.
[3] The modules are being built in the standard way for out-of-tree:
$(MAKE) -C $(PRJDIR)/linux M=$(CWD) modules
[4] http://www.signal11.us/~alan/show-all-tasks-deadlock.txt
^ permalink raw reply
* [PATCH v3 0/8] ARM: sunxi: rename DT clock node names to clk@N
From: Mike Turquette @ 2014-01-18 0:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D89E27.6060204@elopez.com.ar>
Quoting Emilio L?pez (2014-01-16 19:06:15)
> Hi,
>
> El 09/01/14 05:52, Chen-Yu Tsai escribi?:
> > This is v3 of the clock node renaming patch series, which renames
> > the clock nodes in sunxi dts to conform to device tree naming
> > conventions, i.e. clk at N. Dummy clocks that will be renamed/removed
> > later, or clocks sharing registers are not renamed.
> >
> > Renamed clock nodes have clock-output-names properties added to
> > desginate their names. Support for this is added in the first
> > patch.
> >
> > Changes since v2:
> >
> > * Dropped Cubietruck dts i2c controller patch. Maxime has taken it.
> > * Changed ARM in commit messages to uppercase.
> > * Add pll5, pll6 clock names to factors_data tied to compatible strings.
> > * Dropped pll5 output name in dts due to the previous change.
> > * Added dts binding documentation for "clock-output-names", as well as
> > examples.
> >
> > Changes since v1:
> >
> > * Fixed pll5, pll6 divs clock name handling
> >
> > Cheers
> > ChenYu
> >
> > Chen-Yu Tsai (8):
> > clk: sunxi: add clock-output-names dt property support
> > clk: sunxi: update clock-output-names dt binding documentation
> > clk: sunxi: add names for pll5, pll6 parent clocks to factors_data
> > clk: sunxi: get divs parent clock name from parent factor clock
> > ARM: dts: sun4i: rename clock node names to clk at N
> > ARM: dts: sun5i: rename clock node names to clk at N
> > ARM: dts: sun6i: rename clock node names to clk at N
> > ARM: dts: sun7i: rename clock node names to clk at N
> >
> > Documentation/devicetree/bindings/clock/sunxi.txt | 36 +++++++++++++++++++----
> > arch/arm/boot/dts/sun4i-a10.dtsi | 24 ++++++++-------
> > arch/arm/boot/dts/sun5i-a10s.dtsi | 24 ++++++++-------
> > arch/arm/boot/dts/sun5i-a13.dtsi | 24 ++++++++-------
> > arch/arm/boot/dts/sun6i-a31.dtsi | 12 ++++----
> > arch/arm/boot/dts/sun7i-a20.dtsi | 19 +++++++-----
> > drivers/clk/sunxi/clk-sunxi.c | 36 ++++++++++++++++-------
> > 7 files changed, 117 insertions(+), 58 deletions(-)
>
> The series looks good to me, other than the comment I made. Once that's
> settled, and if Mike, Maxime or anyone else have no further comments,
> I'll queue 1-4 for 3.15.
Ack for patches 1-4.
Regards,
Mike
>
> Cheers, and thanks for working on this!
>
> Emilio
^ permalink raw reply
* [PATCHv13 00/40] ARM: TI SoC clock DT conversion
From: Olof Johansson @ 2014-01-18 0:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D9C88C.3020508@ti.com>
On Fri, Jan 17, 2014 at 4:19 PM, Nishanth Menon <nm@ti.com> wrote:
> On 01/17/2014 06:12 PM, Olof Johansson wrote:
>> On Fri, Jan 17, 2014 at 4:02 PM, Nishanth Menon <nm@ti.com> wrote:
>>
>>> clk-next-6a0cad9 + next-20140117 multi_v7_defconfig + CONFIG_LPAE=y:
>>> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s21GRhEOj4
>>> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s20zcNsD8h
>>> 3: am3517-evm: Boot PASS: http://slexy.org/raw/s27U9IfRKR
>>> 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2zYyeonec
>>> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21iCRjTHK
>>> 6: beagleboard-xm: Boot PASS: http://slexy.org/raw/s20bPGL3Sz
>>> 7: beaglebone-black: Boot PASS: http://slexy.org/raw/s21AhFmkCk
>>> 8: crane: No Image built - Missing platform support?:
>>> 9: dra7: Boot FAIL: http://slexy.org/raw/s21Qh3sQRu
>>> * DRA7 not enabled?
>>> 10: ldp: Boot PASS: http://slexy.org/raw/s21fvBfBgs
>>> 11: panda-es: Boot FAIL: http://slexy.org/raw/s20RsgVUZJ
>>> * known issue (https://patchwork.kernel.org/patch/3084521/)
>>> 12: sdp2430: Boot FAIL: v6 platform - wont boot with multi_v7
>>> 13: sdp3430: Boot PASS: http://slexy.org/raw/s20rhjjBwe
>>> 14: sdp4430: Boot PASS: http://slexy.org/raw/s2My0UfNPm
>>> 15: uevm: Boot PASS: http://slexy.org/raw/s21aqF6eMN
>>> TOTAL = 15 boards, Booted Boards = 11, No Boot boards = 4
>>
>>
>> I have a hard time believing the above; A8/A9 boards are not bootable
>> with CONFIG_LPAE=y...
>
> You are right! Drat!! I had CONFIG_LPAE=y in my script, not
> CONFIG_ARM_LPAE=y! Grrr...
>
> Retest in a around 30 mins..
It's not a huge concern though; it's unlikely that LPAE makes a
functional difference on this patch series. It's still useful to catch
warnings, etc (most likely printk formats and the like).
-Olof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox