* [PATCH 3/3] clk: mmp: try to use closer one when do round rate
From: Chao Xie @ 2014-01-23 2:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390445262-27486-1-git-send-email-chao.xie@marvell.com>
From: Chao Xie <chao.xie@marvell.com>
The orignal code will use the bigger rate between
"previous rate" and "current rate" when caculate the
rate.
In fact, hardware cares about the closest one.
So choose the closer rate between "previous rate" and
"current rate".
Signed-off-by: Chao Xie <chao.xie@marvell.com>
---
drivers/clk/mmp/clk-frac.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/mmp/clk-frac.c b/drivers/clk/mmp/clk-frac.c
index 5863a37..23a56f5 100644
--- a/drivers/clk/mmp/clk-frac.c
+++ b/drivers/clk/mmp/clk-frac.c
@@ -45,10 +45,14 @@ static long clk_factor_round_rate(struct clk_hw *hw, unsigned long drate,
if (rate > drate)
break;
}
- if ((i == 0) || (i == factor->ftbl_cnt))
+ if ((i == 0) || (i == factor->ftbl_cnt)) {
return rate;
- else
- return prev_rate;
+ } else {
+ if ((drate - prev_rate) > (rate - drate))
+ return rate;
+ else
+ return prev_rate;
+ }
}
static unsigned long clk_factor_recalc_rate(struct clk_hw *hw,
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/3] clk: mmp: fix the wrong calculation formula
From: Chao Xie @ 2014-01-23 2:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390445262-27486-1-git-send-email-chao.xie@marvell.com>
From: Chao Xie <chao.xie@marvell.com>
The formula is numerator/denominator = Fin / (Fout * factor)
So
Fout = Fin * denominator / (numerator * factor).
Current clk_factor_round_rate and clk_factor_recalc_rate use
wrong formula. This patch will fix them.
Signed-off-by: Chao Xie <chao.xie@marvell.com>
---
drivers/clk/mmp/clk-frac.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/mmp/clk-frac.c b/drivers/clk/mmp/clk-frac.c
index f6e7691..5863a37 100644
--- a/drivers/clk/mmp/clk-frac.c
+++ b/drivers/clk/mmp/clk-frac.c
@@ -40,12 +40,12 @@ static long clk_factor_round_rate(struct clk_hw *hw, unsigned long drate,
for (i = 0; i < factor->ftbl_cnt; i++) {
prev_rate = rate;
- rate = (((*prate / 10000) * factor->ftbl[i].num) /
- (factor->ftbl[i].den * factor->masks->factor)) * 10000;
+ rate = (((*prate / 10000) * factor->ftbl[i].den) /
+ (factor->ftbl[i].num * factor->masks->factor)) * 10000;
if (rate > drate)
break;
}
- if (i == 0)
+ if ((i == 0) || (i == factor->ftbl_cnt))
return rate;
else
return prev_rate;
@@ -85,8 +85,8 @@ static int clk_factor_set_rate(struct clk_hw *hw, unsigned long drate,
for (i = 0; i < factor->ftbl_cnt; i++) {
prev_rate = rate;
- rate = (((prate / 10000) * factor->ftbl[i].num) /
- (factor->ftbl[i].den * factor->masks->factor)) * 10000;
+ rate = (((prate / 10000) * factor->ftbl[i].den) /
+ (factor->ftbl[i].num * factor->masks->factor)) * 10000;
if (rate > drate)
break;
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/3] clk: mmp: fix wrong mask when calculate denominator
From: Chao Xie @ 2014-01-23 2:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390445262-27486-1-git-send-email-chao.xie@marvell.com>
From: Chao Xie <chao.xie@marvell.com>
The code has typo when calculate denominator. It should use
den_mask instead of num_mask.
Signed-off-by: Chao Xie <chao.xie@marvell.com>
---
drivers/clk/mmp/clk-frac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/mmp/clk-frac.c b/drivers/clk/mmp/clk-frac.c
index 80c1dd1..f6e7691 100644
--- a/drivers/clk/mmp/clk-frac.c
+++ b/drivers/clk/mmp/clk-frac.c
@@ -64,7 +64,7 @@ static unsigned long clk_factor_recalc_rate(struct clk_hw *hw,
num = (val >> masks->num_shift) & masks->num_mask;
/* calculate denominator */
- den = (val >> masks->den_shift) & masks->num_mask;
+ den = (val >> masks->den_shift) & masks->den_mask;
if (!den)
return 0;
--
1.8.3.2
^ permalink raw reply related
* [PATCH 0/3] clk: mmp: bug fix for clk-frac
From: Chao Xie @ 2014-01-23 2:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Chao Xie <chao.xie@marvell.com>
When use the clk-frac type of mmp, some bugs are found.
The following 3 patches are bug fix for clk-frac
Chao Xie (3):
clk: mmp: fix wrong mask when calculate denominator
clk: mmp: fix the wrong calculation formula
clk: mmp: try to use closer one when do round rate
drivers/clk/mmp/clk-frac.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
--
1.8.3.2
^ permalink raw reply
* Internal error: Oops: 17 [#1] ARM
From: Fabio Estevam @ 2014-01-23 2:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACUGKYPakuAGOWb+RetqNhEBvRP-+Pmtu2_4a2zuV0bFR0QJRA@mail.gmail.com>
On Wed, Jan 22, 2014 at 9:49 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
> Hello all,
>
> Just to confirm that the error I posted previously exist in 3.13
> released. Just be noted that some patches related to eMMC/sdhci has
> been applied in order to boot the 3.13 on my board.
> Addition to that, I was getting additional errors (please see below):
> - It happened during the reboot.
>
> Cc'ng Dong Aisheng.
What are the steps to reproduce this? Which SoC are you using?
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH 2/3] ARM: kexec: copying code to ioremapped area
From: Wang Nan @ 2014-01-23 2:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122132734.GB15937@n2100.arm.linux.org.uk>
On 2014/1/22 21:27, Russell King - ARM Linux wrote:
> On Wed, Jan 22, 2014 at 07:25:15PM +0800, Wang Nan wrote:
>> ARM's kdump is actually corrupted (at least for omap4460), mainly because of
>> cache problem: flush_icache_range can't reliably ensure the copied data
>> correctly goes into RAM.
>
> Quite right too. You're mistake here is thinking that flush_icache_range()
> should push it to RAM. That's incorrect.
>
> flush_icache_range() is there to deal with such things as loadable modules
> and self modifying code, where the MMU is not being turned off. Hence, it
> only flushes to the point of coherency between the I and D caches, and
> any further levels of cache between that point and memory are not touched.
> Why should it touch any more levels - it's not the function's purpose.
>
>> After mmu turned off and jump to the trampoline, kexec always failed due
>> to random undef instructions.
>
> We already have code in the kernel which deals with shutting the MMU off.
> An instance of how this can be done is illustrated in the soft_restart()
> code path, and kexec already uses this.
>
> One of the first things soft_restart() does is turn off the outer cache -
> which OMAP4 does have, but this can only be done if there is a single CPU
> running. If there's multiple CPUs running, then the outer cache can't be
> disabled, and that's the most likely cause of the problem you're seeing.
>
You are right, commit b25f3e1c (OMAP4/highbank: Flush L2 cache before disabling)
solves my problem, it flushes outer cache before disabling. I have tested it in
UP and SMP situations and it works (actually, omap4 has not ready to support kexec
in SMP case, I insert an empty cpu_kill() to make it work), so the first 2
patches are unneeded.
What about the 3rd one (ARM: allow kernel to be loaded in middle of phymem)?
^ permalink raw reply
* [PATCH 2/2] ARM: dts: imx6sl-evk: Add audio support
From: Fabio Estevam @ 2014-01-23 2:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390443213-14061-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@freescale.com>
imx6sl-evk has a wm8962 codec. Add support for it.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/boot/dts/imx6sl-evk.dts | 72 +++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx6sl-pingrp.h | 11 ++++++
arch/arm/boot/dts/imx6sl.dtsi | 3 ++
3 files changed, 86 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sl-evk.dts b/arch/arm/boot/dts/imx6sl-evk.dts
index 5ba15ab..9e1ab77 100644
--- a/arch/arm/boot/dts/imx6sl-evk.dts
+++ b/arch/arm/boot/dts/imx6sl-evk.dts
@@ -24,6 +24,22 @@
#address-cells = <1>;
#size-cells = <0>;
+ reg_aud3v: wm8962_supply_3v15 {
+ compatible = "regulator-fixed";
+ regulator-name = "wm8962-supply-3v15";
+ regulator-min-microvolt = <3150000>;
+ regulator-max-microvolt = <3150000>;
+ regulator-boot-on;
+ };
+
+ reg_aud4v: wm8962_supply_4v2 {
+ compatible = "regulator-fixed";
+ regulator-name = "wm8962-supply-4v2";
+ regulator-min-microvolt = <4325000>;
+ regulator-max-microvolt = <4325000>;
+ regulator-boot-on;
+ };
+
reg_usb_otg1_vbus: regulator at 0 {
compatible = "regulator-fixed";
reg = <0>;
@@ -44,6 +60,28 @@
enable-active-high;
};
};
+
+ sound {
+ compatible = "fsl,imx6sl-evk-wm8962", "fsl,imx-audio-wm8962";
+ model = "wm8962-audio";
+ ssi-controller = <&ssi2>;
+ audio-codec = <&codec>;
+ audio-routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "Ext Spk", "SPKOUTL",
+ "Ext Spk", "SPKOUTR",
+ "AMIC", "MICBIAS",
+ "IN3R", "AMIC";
+ mux-int-port = <2>;
+ mux-ext-port = <3>;
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux3>;
+ status = "okay";
};
&i2c1 {
@@ -152,6 +190,27 @@
};
};
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ codec: wm8962 at 1a {
+ compatible = "wlf,wm8962";
+ reg = <0x1a>;
+ clocks = <&clks IMX6SL_CLK_EXTERN_AUDIO>;
+ DCVDD-supply = <&vgen3_reg>;
+ DBVDD-supply = <®_aud3v>;
+ AVDD-supply = <&vgen3_reg>;
+ CPVDD-supply = <&vgen3_reg>;
+ MICVDD-supply = <®_aud3v>;
+ PLLVDD-supply = <&vgen3_reg>;
+ SPKVDD1-supply = <®_aud4v>;
+ SPKVDD2-supply = <®_aud4v>;
+ };
+};
+
&ecspi1 {
fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio4 11 0>;
@@ -192,10 +251,18 @@
>;
};
+ pinctrl_audmux3: audmux3grp {
+ fsl,pins = <MX6SL_AUDMUX3_PINGRP1>;
+ };
+
pinctrl_i2c1: i2c1grp {
fsl,pins = <MX6SL_I2C1_PINGRP1>;
};
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <MX6SL_I2C2_PINGRP1>;
+ };
+
pinctrl_ecspi1: ecspi1grp {
fsl,pins = <MX6SL_ECSPI1_PINGRP1>;
};
@@ -277,6 +344,11 @@
status = "okay";
};
+&ssi2 {
+ fsl,mode = "i2s-slave";
+ status = "okay";
+};
+
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1>;
diff --git a/arch/arm/boot/dts/imx6sl-pingrp.h b/arch/arm/boot/dts/imx6sl-pingrp.h
index cada37a..ee50ace 100644
--- a/arch/arm/boot/dts/imx6sl-pingrp.h
+++ b/arch/arm/boot/dts/imx6sl-pingrp.h
@@ -10,6 +10,13 @@
#ifndef __DTS_IMX6SL_PINGRP_H
#define __DTS_IMX6SL_PINGRP_H
+#define MX6SL_AUDMUX3_PINGRP1 \
+ MX6SL_PAD_AUD_RXD__AUD3_RXD 0x4130B0 \
+ MX6SL_PAD_AUD_TXC__AUD3_TXC 0x4130B0 \
+ MX6SL_PAD_AUD_TXD__AUD3_TXD 0x4110B0 \
+ MX6SL_PAD_AUD_TXFS__AUD3_TXFS 0x4130B0 \
+ MX6SL_PAD_AUD_MCLK__AUDIO_CLK_OUT 0x4130B0
+
#define MX6SL_ECSPI1_PINGRP1 \
MX6SL_PAD_ECSPI1_MISO__ECSPI1_MISO 0x100b1 \
MX6SL_PAD_ECSPI1_MOSI__ECSPI1_MOSI 0x100b1 \
@@ -19,6 +26,10 @@
MX6SL_PAD_I2C1_SCL__I2C1_SCL 0x4001b8b1 \
MX6SL_PAD_I2C1_SDA__I2C1_SDA 0x4001b8b1
+#define MX6SL_I2C2_PINGRP1 \
+ MX6SL_PAD_I2C2_SCL__I2C2_SCL 0x4001b8b1 \
+ MX6SL_PAD_I2C2_SDA__I2C2_SDA 0x4001b8b1
+
#define MX6SL_FEC_PINGRP1 \
MX6SL_PAD_FEC_MDC__FEC_MDC 0x1b0b0 \
MX6SL_PAD_FEC_MDIO__FEC_MDIO 0x1b0b0 \
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 95bb37b..04cf457 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -236,6 +236,7 @@
<&sdma 38 1 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
+ fsl,ssi-dma-events = <38 37>;
status = "disabled";
};
@@ -250,6 +251,7 @@
<&sdma 42 1 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
+ fsl,ssi-dma-events = <42 41>;
status = "disabled";
};
@@ -264,6 +266,7 @@
<&sdma 46 1 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
+ fsl,ssi-dma-events = <46 45>;
status = "disabled";
};
--
1.8.1.2
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx6sl-evk: Add PFUZE100 support
From: Fabio Estevam @ 2014-01-23 2:13 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@freescale.com>
imx6sl-evk board has Freescale PFUZE100 regulator, so add support for it.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/boot/dts/imx6sl-evk.dts | 110 ++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx6sl-pingrp.h | 4 ++
2 files changed, 114 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sl-evk.dts b/arch/arm/boot/dts/imx6sl-evk.dts
index f23b5d1..5ba15ab 100644
--- a/arch/arm/boot/dts/imx6sl-evk.dts
+++ b/arch/arm/boot/dts/imx6sl-evk.dts
@@ -46,6 +46,112 @@
};
};
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+
+ pmic: pfuze100 at 08 {
+ compatible = "fsl,pfuze100";
+ reg = <0x08>;
+
+ regulators {
+ sw1a_reg: sw1ab {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw1c_reg: sw1c {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw2_reg: sw2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3a_reg: sw3a {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1975000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3b_reg: sw3b {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1975000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw4_reg: sw4 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ swbst_reg: swbst {
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5150000>;
+ };
+
+ snvs_reg: vsnvs {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vref_reg: vrefddr {
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vgen1_reg: vgen1 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ };
+
+ vgen2_reg: vgen2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ };
+
+ vgen3_reg: vgen3 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vgen4_reg: vgen4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen5_reg: vgen5 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen6_reg: vgen6 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
&ecspi1 {
fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio4 11 0>;
@@ -86,6 +192,10 @@
>;
};
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <MX6SL_I2C1_PINGRP1>;
+ };
+
pinctrl_ecspi1: ecspi1grp {
fsl,pins = <MX6SL_ECSPI1_PINGRP1>;
};
diff --git a/arch/arm/boot/dts/imx6sl-pingrp.h b/arch/arm/boot/dts/imx6sl-pingrp.h
index ead26d4..cada37a 100644
--- a/arch/arm/boot/dts/imx6sl-pingrp.h
+++ b/arch/arm/boot/dts/imx6sl-pingrp.h
@@ -15,6 +15,10 @@
MX6SL_PAD_ECSPI1_MOSI__ECSPI1_MOSI 0x100b1 \
MX6SL_PAD_ECSPI1_SCLK__ECSPI1_SCLK 0x100b1
+#define MX6SL_I2C1_PINGRP1 \
+ MX6SL_PAD_I2C1_SCL__I2C1_SCL 0x4001b8b1 \
+ MX6SL_PAD_I2C1_SDA__I2C1_SDA 0x4001b8b1
+
#define MX6SL_FEC_PINGRP1 \
MX6SL_PAD_FEC_MDC__FEC_MDC 0x1b0b0 \
MX6SL_PAD_FEC_MDIO__FEC_MDIO 0x1b0b0 \
--
1.8.1.2
^ permalink raw reply related
* [PATCH] clk: export __clk_get_hw for re-use in others
From: SeongJae Park @ 2014-01-23 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPtuhThZdDkKq_fruaduPknpXxCTHgCA7mCnDDh+vS_OiUy+1w@mail.gmail.com>
On Thu, Jan 23, 2014 at 3:11 AM, Mike Turquette <mturquette@linaro.org> wrote:
> On Wed, Jan 22, 2014 at 9:59 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> On 01/21/14 21:23, SeongJae Park wrote:
>>> On Wed, Jan 22, 2014 at 1:59 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>>>> On Wed, Jan 22, 2014 at 12:05:57PM +0900, SeongJae Park wrote:
>>>>> Dear Greg, Mike,
>>>>>
>>>>> May I ask your answer or other opinion, please?
>>>> It's the middle of the merge window, it's not time for new development,
>>>> or much time for free-time for me, sorry. Feel free to fix it the best
>>>> way you know how.
>>> Oops, I've forgot about the merge window. Thank you very much for your
>>> kind answer.
>>> Sorry if I bothered you while you're in busy time.
>>> Because the build problem is not a big deal because it exists only in
>>> -next tree,
>>> I will wait until merge window be closed and then fix it again if it
>>> still exist.
>>>
>>
>> I've already sent a patch that exports this and other clock provider
>> functions. Please use this one:
>>
>> https://patchwork.kernel.org/patch/3507921/
>
> I'm going to take Stephen's patch into a fixes branch and send it as
> part of a pull request. Maybe -rc1 or -rc2 at the latest.
Got it. Thank you for let me know :)
>
> Thanks all.
>
> Regards,
> Mike
>
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> hosted by The Linux Foundation
>>
^ permalink raw reply
* Freescale FEC packet loss
From: fugang.duan at freescale.com @ 2014-01-23 1:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401222255.29467.marex@denx.de>
Hi, Marek,
From: Marek Vasut <marex@denx.de>
Data: Thursday, January 23, 2014 5:55 AM
>To: netdev at vger.kernel.org
>Cc: Li Frank-B20596; Duan Fugang-B38611; Estevam Fabio-R49496; Hector Palacios;
>linux-arm-kernel at lists.infradead.org; Detlev Zundel; Eric Nelson
>Subject: Freescale FEC packet loss
>
>Hi guys,
>
>I am running stock Linux 3.13 on i.MX6Q SabreLite board. The CPU is i.MX6Q TO
>1.0 .
>
>I am hitting a WARNING when I use the FEC ethernet to transfer data, thus I
>started investigating this problem. TL;DR I am not able to figure this problem
>out, so I am not attaching a patch :-(
>
>Steps to reproduce:
>-------------------
>1) Boot stock Linux 3.13 on i.MX6Q SabreLite board
>2) Plug in an SD card into one of the SD slots (I use the full-size one)
>3) Plug in an USB stick into one of the USB ports (I use the upper one)
>4) Plug in an ethernet cable into the board
> -> Connect the other side into a gigabit-capable PC
> -> Let us assume the PC has IP address 192.168.1.1/24 and
> the board 192.168.1.2/24
>5) Install iperf on both boards
>6) Bring up the ethernet link on both ends:
> $ ifconfig ...
>7) On the PC, run:
> $ iperf -s -i 1
>8) Start producing load on the in-CPU busses. Run this on the board:
> $ sha1sum /dev/mmcblk0 &
> $ sha1sum /dev/sda &
>9) Now let the board generate ethernet traffic:
> $ iperf -c 192.168.1.1 -t 1000 -i 1
>
>Now wait about 10 minutes and the system will produce a warning and you will
>observe dips in the transmission speed. You can see the output at the end of
>the email.
>
>I observe that this happens more often when there is a severe load on the
>busses, which in this case I simulate by running the sha1sum on /dev/mmcblk0
>and sha1sum /dev/sda in the background in step 8) . I can also well simulate
>this by running 'sha1sum /dev/mmcblk0 & sha1sum /dev/mmcblk1 &' when I have
>both SD cards populated on the MX6Q sabrelite with the same result (WARNING and
>dips in speed).
>
>There was apparently a thread about this problem already [1] where the person
>used SATA to produce high bus load and had exactly the same result.
>
>One more observation is that I managed to replicate this problem all the way
>back to Linux 3.3.8 , which is one of the first kernel versions where sabrelite
>was supported. I also see this one the Freescale's 3.0.35-4.1.0 .
>
>I have trouble figuring out what this problem is all about. Can you please help
>me? Thank you!
>
>[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-
>October/202519.html
>
>root@(none):~# iperf -c 192.168.1.1 -t 1000 -i 1
>------------------------------------------------------------
>Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 43.8 KByte
>(default)
>------------------------------------------------------------
>[ 3] local 192.168.1.128 port 36760 connected with 192.168.1.1 port 5001
>[ ID] Interval Transfer Bandwidth
>[ 3] 0.0- 1.0 sec 25.5 MBytes 214 Mbits/sec
>[ 3] 1.0- 2.0 sec 28.9 MBytes 242 Mbits/sec
>[ 3] 2.0- 3.0 sec 24.1 MBytes 202 Mbits/sec
>[ 3] 3.0- 4.0 sec 21.1 MBytes 177 Mbits/sec
>[ 3] 4.0- 5.0 sec 20.2 MBytes 170 Mbits/sec
>[ 3] 5.0- 6.0 sec 20.0 MBytes 168 Mbits/sec
>[ 3] 6.0- 7.0 sec 20.0 MBytes 168 Mbits/sec
>[ 3] 7.0- 8.0 sec 20.1 MBytes 169 Mbits/sec
>[ 3] 8.0- 9.0 sec 20.5 MBytes 172 Mbits/sec
>[ 3] 9.0-10.0 sec 21.5 MBytes 180 Mbits/sec
>[ 3] 10.0-11.0 sec 20.0 MBytes 168 Mbits/sec
>[ 3] 11.0-12.0 sec 19.4 MBytes 163 Mbits/sec
>[ 3] 12.0-13.0 sec 19.6 MBytes 165 Mbits/sec
>[ 3] 13.0-14.0 sec 19.8 MBytes 166 Mbits/sec
>[ 3] 14.0-15.0 sec 19.4 MBytes 163 Mbits/sec
>[ 275.945247] ------------[ cut here ]------------ [ 275.949920] WARNING: CPU:
>3 PID: 1155 at net/sched/sch_generic.c:264
>dev_watchdog+0x280/0x2a4()
>[ 275.958679] NETDEV WATCHDOG: eth3 (fec): transmit queue 0 timed out
>[ 275.964985] Modules linked in:
>[ 275.968096] CPU: 3 PID: 1155 Comm: sha1sum Not tainted 3.13.0 #18
>[ 275.974217] Backtrace:
>[ 275.976787] [<80012410>] (dump_backtrace+0x0/0x10c) from [<800125ac>]
>(show_stack+0x18/0x1c)
>[ 275.985271] r6:00000108 r5:00000009 r4:00000000 r3:00000000
>[ 275.991050] [<80012594>] (show_stack+0x0/0x1c) from [<8060f9c8>]
>(dump_stack+0x80/0x9c)
>[ 275.999103] [<8060f948>] (dump_stack+0x0/0x9c) from [<8002703c>]
>(warn_slowpath_common+0x6c/0x90)
>[ 276.008017] r4:bef43e10 r3:bef96c00
>[ 276.011663] [<80026fd0>] (warn_slowpath_common+0x0/0x90) from [<80027104>]
>(warn_slowpath_fmt+0x3)
>[ 276.021170] r8:bf098240 r7:bef42000 r6:bf098200 r5:bf068000 r4:00000000
>[ 276.028083] [<800270cc>] (warn_slowpath_fmt+0x0/0x40) from [<804e2754>]
>(dev_watchdog+0x280/0x2a4)
>[ 276.037095] r3:bf068000 r2:807d2fb4
>[ 276.040734] [<804e24d4>] (dev_watchdog+0x0/0x2a4) from [<80030e1c>]
>(call_timer_fn+0x70/0xec)
>[ 276.049313] [<80030dac>] (call_timer_fn+0x0/0xec) from [<80031a90>]
>(run_timer_softirq+0x198/0x23)
>[ 276.058407] r8:00200200 r7:00000000 r6:bef43ec8 r5:bf836000 r4:bf068284
>[ 276.065257] [<800318f8>] (run_timer_softirq+0x0/0x230) from [<8002b480>]
>(__do_softirq+0x100/0x25)
>[ 276.074338] [<8002b380>] (__do_softirq+0x0/0x254) from [<8002b9a8>]
>(irq_exit+0xb0/0x108)
>[ 276.082570] [<8002b8f8>] (irq_exit+0x0/0x108) from [<8000f3dc>]
>(handle_IRQ+0x58/0xb8)
>[ 276.090528] r4:8086ccc8 r3:00000184
>[ 276.094162] [<8000f384>] (handle_IRQ+0x0/0xb8) from [<80008640>]
>(gic_handle_irq+0x30/0x64)
>[ 276.102552] r8:5590d9fa r7:f4000100 r6:bef43fb0 r5:8086ce14 r4:f400010c
>r3:000000a0
>[ 276.110575] [<80008610>] (gic_handle_irq+0x0/0x64) from [<800133a0>]
>(__irq_usr+0x40/0x60)
>[ 276.118871] Exception stack(0xbef43fb0 to 0xbef43ff8)
>[ 276.123942] 3fa0: fbe9d585 13e98d33
>6ed9eba1 21e67a57
>[ 276.132173] 3fc0: 170dd9fc bc58d89e 5d1b7878 c19f2bf4 5590d9fa 2577bcc4
>7b2ac1ea 6cee44dd [ 276.140398] 3fe0: cf486f09 7ea92a58 0000ba1f 0000ab72
>a0000030 ffffffff [ 276.147041] r7:c19f2bf4 r6:ffffffff r5:a0000030
>r4:0000ab72 [ 276.152846] ---[ end trace 054500acb8edb763 ]---
>[ 3] 15.0-16.0 sec 18.8 MBytes 157 Mbits/sec
>[ 3] 16.0-17.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 17.0-18.0 sec 0.00 Bytes
>0.00 bits/sec [ 3] 18.0-19.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 19.0-20.0
>sec 4.25 MBytes 35.7 Mbits/sec
>[ 3] 20.0-21.0 sec 19.8 MBytes 166 Mbits/sec
>[ 3] 21.0-22.0 sec 19.8 MBytes 166 Mbits/sec
>[ 3] 22.0-23.0 sec 19.5 MBytes 164 Mbits/sec
>[ 3] 23.0-24.0 sec 8.38 MBytes 70.3 Mbits/sec [ 3] 24.0-25.0 sec 0.00
>Bytes 0.00 bits/sec [ 3] 25.0-26.0 sec 7.88 MBytes 66.1 Mbits/sec
>[ 3] 26.0-27.0 sec 20.1 MBytes 169 Mbits/sec
>[...]
>[ 3] 71.0-72.0 sec 23.4 MBytes 196 Mbits/sec
>[ 3] 72.0-73.0 sec 12.2 MBytes 103 Mbits/sec
>[ 3] 73.0-74.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 74.0-75.0 sec 0.00 Bytes
>0.00 bits/sec [ 3] 75.0-76.0 sec 10.9 MBytes 91.2 Mbits/sec
>[ 3] 76.0-77.0 sec 22.4 MBytes 188 Mbits/sec
>[ 3] 77.0-78.0 sec 23.0 MBytes 193 Mbits/sec
>
I will debug the issue when I am free, and then report the result to you.
Thanks for your reporting the issue.
Thanks,
Andy
^ permalink raw reply
* [RFC PATCH 1/9] mtd: nand: retrieve ECC requirements from Hynix READ ID byte 4
From: Brian Norris @ 2014-01-23 1:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389190924-26226-2-git-send-email-b.brezillon@overkiz.com>
+ Huang
Hi Boris,
On Wed, Jan 08, 2014 at 03:21:56PM +0100, Boris BREZILLON wrote:
> The Hynix nand flashes store their ECC requirements in byte 4 of its id
> (returned on READ ID command).
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
I haven't verified yet (perhaps Huang can confirm?), but this may be
similar to a patch Huang submitted recently. In his case, we found that
this table is actually quite unreliable and is likely hard to maintain.
Why do you need this ECC information, for my reference?
Brian
^ permalink raw reply
* [PATCH v5 7/8] ARM: brcmstb: gic: add compatible string for Broadcom Brahma15
From: Marc C @ 2014-01-23 1:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGVrzcbPyaSe0aEHt157kz=quvsrBCPOUriCVG27fJfasa45jg@mail.gmail.com>
Hi Florian,
> Do not we also need to update drivers/irqchip/irq-gic.c to look for
> this compatible property? Alternatively should the example DTS contain
> the following:
>
> compatible = "brcm,brahma-b15-gic", "arm,cortex-a15-gic"?
Patch #8 [1] of this series has the "compatible" string set exactly that way. I was
following the pattern seen in the other reference DTS files, where "arm,cortex-a15-gic" is
used as the fall-back.
Thanks,
Marc C
[1] https://lkml.org/lkml/2014/1/21/649
On 01/22/2014 02:40 PM, Florian Fainelli wrote:
> Hi Marc,
>
> 2014/1/21 Marc Carino <marc.ceeeee@gmail.com>:
>> Document the Broadcom Brahma B15 GIC implementation as compatible
>> with the ARM GIC standard.
>>
>> Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
>> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Do not we also need to update drivers/irqchip/irq-gic.c to look for
> this compatible property? Alternatively should the example DTS contain
> the following:
>
> compatible = "brcm,brahma-b15-gic", "arm,cortex-a15-gic"?
>
>> ---
>> Documentation/devicetree/bindings/arm/gic.txt | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
>> index 3dfb0c0..d7409fd 100644
>> --- a/Documentation/devicetree/bindings/arm/gic.txt
>> +++ b/Documentation/devicetree/bindings/arm/gic.txt
>> @@ -15,6 +15,7 @@ Main node required properties:
>> "arm,cortex-a9-gic"
>> "arm,cortex-a7-gic"
>> "arm,arm11mp-gic"
>> + "brcm,brahma-b15-gic"
>> - interrupt-controller : Identifies the node as an interrupt controller
>> - #interrupt-cells : Specifies the number of cells needed to encode an
>> interrupt source. The type shall be a <u32> and the value shall be 3.
>> --
>> 1.7.1
>>
>
>
>
^ permalink raw reply
* [PATCH v4 00/36] mtd: st_spi_fsm: Add new driver
From: Brian Norris @ 2014-01-23 1:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122125049.GA8586@lee--X1>
Hi Lee,
On Wed, Jan 22, 2014 at 12:50:49PM +0000, Lee Jones wrote:
> > Version 4:
> > Tended to Brian's previous review comments
> > - Checkpatch acceptance
> > - MODULE_DEVICE_TABLE() name slip correction
> > - Timeout issue(s) resolved
> > - Potential infinite loop mitigated
> > - Code clarity suggests heeded
> > - Duplication with MTD core code removed
> > - Upgraded to using ROUND_UP() helper
> > - Moved non-shared header code into main driver
> > - Relocated dynamic msg sequence stores into main struct
> > - Averted adaption of static (table) data
> > - Basic whitespace/spelling/data type/dev_err suggestions accepted
> >
> > Version 3:
> > Okay, this thing should be fully functional now. Identify a chip
> > based on it's JEDEC ID, Read, Write, Erase (all or by sector).
> > Support for various chip quirks added too.
> >
> > Version 2:
> > The first bunch of these patches have been on the MLs before, but
> > didn't receive a great deal of attention for the most part. We are
> > a little more featureful this time however. We can now successfully
> > setup and configure the N25Q256. We still can't read/write/erase
> > it though. I'll start work on that next week and will provide it in
> > the next instalment.
> >
> > Version 1:
> > First stab at getting this thing Mainlined. It doesn't do a great deal
> > yet, but we are able to initialise the device and dynamically set it up
> > correctly based on an extracted JEDEC ID.
> >
> > Documentation/devicetree/bindings/mtd/st-fsm.txt | 26 ++
> > arch/arm/boot/dts/stih416-b2105.dts | 14 +
> > arch/arm/boot/dts/stih416-pinctrl.dtsi | 12 +
> > drivers/mtd/devices/Kconfig | 8 +
> > drivers/mtd/devices/Makefile | 1 +
> > drivers/mtd/devices/serial_flash_cmds.h | 81 ++++
> > drivers/mtd/devices/st_spi_fsm.c | 2124 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 7 files changed, 2266 insertions(+)
>
> Can you confirm receipt of this set, or would you like me to resend?
Well, I personally have the patch set but haven't had a chance to review
it. Can you resend with MTD in the CC, since we haven't had any comments
anyway? I believe MTD people are much less likely to look at it if you
forget the CC :)
You can just title it [PATCH RESEND v4 X/Y], possibly with a LKML
link back to the original v4, if you want to help avoid confusion.
Brian
^ permalink raw reply
* [PATCH] ARM: exynos_defconfig: Update EHCI config entry
From: kgene at kernel.org @ 2014-01-23 1:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000101cf1297$fef674c0$fce35e40$%han@samsung.com>
Jingoo Han wrote:
>
> On Thursday, January 16, 2014 5:34 PM, Tushar Behera wrote:
> >
> > Commit 29824c167bea ("USB: host: Rename ehci-s5p to ehci-exynos")
> > renamed the config entry of EHCI host driver. Similar change needs
> > to be done in exynos_defconfig as well.
> >
> > Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
>
> (+cc Vivek Gautam, Yulgon Kim, Julius Werner)
>
> Reviewed-by: Jingoo Han <jg1.han@samsung.com>
>
> Yes, right.
> I overlooked 'exynos_defconfig', when I changed the name of
> Exynos EHCI driver. Thank you for sending the patch. :-)
>
> Best regards,
> Jingoo Han
>
> > ---
> > arch/arm/configs/exynos_defconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/configs/exynos_defconfig
> b/arch/arm/configs/exynos_defconfig
> > index dbe1f1c..4ce7b70 100644
> > --- a/arch/arm/configs/exynos_defconfig
> > +++ b/arch/arm/configs/exynos_defconfig
> > @@ -94,7 +94,7 @@ CONFIG_FONT_7x14=y
> > CONFIG_LOGO=y
> > CONFIG_USB=y
> > CONFIG_USB_EHCI_HCD=y
> > -CONFIG_USB_EHCI_S5P=y
> > +CONFIG_USB_EHCI_EXYNOS=y
> > CONFIG_USB_STORAGE=y
> > CONFIG_USB_DWC3=y
> > CONFIG_USB_PHY=y
> > --
> > 1.7.9.5
OK, applied into -fixes.
Thanks,
Kukjin
^ permalink raw reply
* [PATCH 1/1] gic: change access of gicc_ctrl register to read modify write.
From: Feng Kan @ 2014-01-23 1:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1386534157-17366-1-git-send-email-fkan@apm.com>
Just checking to see anyone had time to take a look at this and comment.
Thanks
On Sun, Dec 8, 2013 at 12:22 PM, Feng Kan <fkan@apm.com> wrote:
> This change is made to preserve the GIC v2 releated bits in the
> GIC_CPU_CTRL register (also known as the GICC_CTLR register in spec).
> The original code only set the enable/disable group bit in this register.
> This code will preserve all other bits configured by the bootload except
> the enable/disable bit. The main reason for this change is to allow the
> bypass bits specified in the v2 spec to remain untouched by the current
> GIC code. In the X-Gene platform, the bypass functionality is not used
> and bypass must be disabled at all time.
>
> Signed-off-by: Vinayak Kale <vkale@apm.com>
> Acked-by: Anup Patel <apatel@apm.com>
> Signed-off-by: Feng Kan <fkan@apm.com>
> ---
> drivers/irqchip/irq-gic.c | 19 ++++++++++++++++---
> 1 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index d0e9480..6550ac9 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -419,6 +419,7 @@ static void gic_cpu_init(struct gic_chip_data *gic)
> void __iomem *dist_base = gic_data_dist_base(gic);
> void __iomem *base = gic_data_cpu_base(gic);
> unsigned int cpu_mask, cpu = smp_processor_id();
> + unsigned int ctrl_mask;
> int i;
>
> /*
> @@ -450,13 +451,21 @@ static void gic_cpu_init(struct gic_chip_data *gic)
> writel_relaxed(0xa0a0a0a0, dist_base + GIC_DIST_PRI + i * 4 / 4);
>
> writel_relaxed(0xf0, base + GIC_CPU_PRIMASK);
> - writel_relaxed(1, base + GIC_CPU_CTRL);
> +
> + ctrl_mask = readl(base + GIC_CPU_CTRL);
> + ctrl_mask |= 0x1;
> + writel_relaxed(ctrl_mask, base + GIC_CPU_CTRL);
> }
>
> void gic_cpu_if_down(void)
> {
> + unsigned int ctrl_mask;
> +
> void __iomem *cpu_base = gic_data_cpu_base(&gic_data[0]);
> - writel_relaxed(0, cpu_base + GIC_CPU_CTRL);
> +
> + ctrl_mask = readl(base + GIC_CPU_CTRL);
> + ctrl_mask &= 0xfffffffe;
> + writel_relaxed(ctrl_mask, cpu_base + GIC_CPU_CTRL);
> }
>
> #ifdef CONFIG_CPU_PM
> @@ -567,6 +576,7 @@ static void gic_cpu_restore(unsigned int gic_nr)
> {
> int i;
> u32 *ptr;
> + unsigned int ctrl_mask;
> void __iomem *dist_base;
> void __iomem *cpu_base;
>
> @@ -591,7 +601,10 @@ static void gic_cpu_restore(unsigned int gic_nr)
> writel_relaxed(0xa0a0a0a0, dist_base + GIC_DIST_PRI + i * 4);
>
> writel_relaxed(0xf0, cpu_base + GIC_CPU_PRIMASK);
> - writel_relaxed(1, cpu_base + GIC_CPU_CTRL);
> +
> + ctrl_mask = readl(base + GIC_CPU_CTRL);
> + ctrl_mask |= 0x1;
> + writel_relaxed(ctrl_mask, cpu_base + GIC_CPU_CTRL);
> }
>
> static int gic_notifier(struct notifier_block *self, unsigned long cmd, void *v)
> --
> 1.7.6.1
>
^ permalink raw reply
* [PATCH 1/1] gic: change access of gicc_ctrl register to read modify write.
From: Feng Kan @ 2014-01-23 0:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1386534157-17366-1-git-send-email-fkan@apm.com>
Just checking to see anyone had time to take a look at this and comment.
On Sun, Dec 8, 2013 at 12:22 PM, Feng Kan <fkan@apm.com> wrote:
> This change is made to preserve the GIC v2 releated bits in the
> GIC_CPU_CTRL register (also known as the GICC_CTLR register in spec).
> The original code only set the enable/disable group bit in this register.
> This code will preserve all other bits configured by the bootload except
> the enable/disable bit. The main reason for this change is to allow the
> bypass bits specified in the v2 spec to remain untouched by the current
> GIC code. In the X-Gene platform, the bypass functionality is not used
> and bypass must be disabled at all time.
>
> Signed-off-by: Vinayak Kale <vkale@apm.com>
> Acked-by: Anup Patel <apatel@apm.com>
> Signed-off-by: Feng Kan <fkan@apm.com>
> ---
> drivers/irqchip/irq-gic.c | 19 ++++++++++++++++---
> 1 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index d0e9480..6550ac9 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -419,6 +419,7 @@ static void gic_cpu_init(struct gic_chip_data *gic)
> void __iomem *dist_base = gic_data_dist_base(gic);
> void __iomem *base = gic_data_cpu_base(gic);
> unsigned int cpu_mask, cpu = smp_processor_id();
> + unsigned int ctrl_mask;
> int i;
>
> /*
> @@ -450,13 +451,21 @@ static void gic_cpu_init(struct gic_chip_data *gic)
> writel_relaxed(0xa0a0a0a0, dist_base + GIC_DIST_PRI + i * 4 / 4);
>
> writel_relaxed(0xf0, base + GIC_CPU_PRIMASK);
> - writel_relaxed(1, base + GIC_CPU_CTRL);
> +
> + ctrl_mask = readl(base + GIC_CPU_CTRL);
> + ctrl_mask |= 0x1;
> + writel_relaxed(ctrl_mask, base + GIC_CPU_CTRL);
> }
>
> void gic_cpu_if_down(void)
> {
> + unsigned int ctrl_mask;
> +
> void __iomem *cpu_base = gic_data_cpu_base(&gic_data[0]);
> - writel_relaxed(0, cpu_base + GIC_CPU_CTRL);
> +
> + ctrl_mask = readl(base + GIC_CPU_CTRL);
> + ctrl_mask &= 0xfffffffe;
> + writel_relaxed(ctrl_mask, cpu_base + GIC_CPU_CTRL);
> }
>
> #ifdef CONFIG_CPU_PM
> @@ -567,6 +576,7 @@ static void gic_cpu_restore(unsigned int gic_nr)
> {
> int i;
> u32 *ptr;
> + unsigned int ctrl_mask;
> void __iomem *dist_base;
> void __iomem *cpu_base;
>
> @@ -591,7 +601,10 @@ static void gic_cpu_restore(unsigned int gic_nr)
> writel_relaxed(0xa0a0a0a0, dist_base + GIC_DIST_PRI + i * 4);
>
> writel_relaxed(0xf0, cpu_base + GIC_CPU_PRIMASK);
> - writel_relaxed(1, cpu_base + GIC_CPU_CTRL);
> +
> + ctrl_mask = readl(base + GIC_CPU_CTRL);
> + ctrl_mask |= 0x1;
> + writel_relaxed(ctrl_mask, cpu_base + GIC_CPU_CTRL);
> }
>
> static int gic_notifier(struct notifier_block *self, unsigned long cmd, void *v)
> --
> 1.7.6.1
>
^ permalink raw reply
* [PATCH RFC 00/73] tree-wide: clean up some no longer required #include <linux/init.h>
From: Paul Gortmaker @ 2014-01-23 0:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122180023.dd90d34cba38d9f9ac516349@canb.auug.org.au>
[Re: [PATCH RFC 00/73] tree-wide: clean up some no longer required #include <linux/init.h>] On 22/01/2014 (Wed 18:00) Stephen Rothwell wrote:
> Hi Paul,
>
> On Tue, 21 Jan 2014 16:22:03 -0500 Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> >
> > Where: This work exists as a queue of patches that I apply to
> > linux-next; since the changes are fixing some things that currently
> > can only be found there. The patch series can be found at:
> >
> > http://git.kernel.org/cgit/linux/kernel/git/paulg/init.git
> > git://git.kernel.org/pub/scm/linux/kernel/git/paulg/init.git
> >
> > I've avoided annoying Stephen with another queue of patches for
> > linux-next while the development content was in flux, but now that
> > the merge window has opened, and new additions are fewer, perhaps he
> > wouldn't mind tacking it on the end... Stephen?
>
> OK, I have added this to the end of linux-next today - we will see how we
> go. It is called "init".
Thanks, it was a great help as it uncovered a few issues in fringe arch
that I didn't have toolchains for, and I've fixed all of those up.
I've noticed that powerpc has been un-buildable for a while now; I have
used this hack patch locally so I could run the ppc defconfigs to check
that I didn't break anything. Maybe useful for linux-next in the
interim? It is a hack patch -- Not-Signed-off-by: Paul Gortmaker. :)
Paul.
--
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
index d27960c89a71..d0f070a2b395 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -560,9 +560,9 @@ extern void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
pmd_t *pmdp);
#define pmd_move_must_withdraw pmd_move_must_withdraw
-typedef struct spinlock spinlock_t;
-static inline int pmd_move_must_withdraw(spinlock_t *new_pmd_ptl,
- spinlock_t *old_pmd_ptl)
+struct spinlock;
+static inline int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
+ struct spinlock *old_pmd_ptl)
{
/*
* Archs like ppc64 use pgtable to store per pmd
^ permalink raw reply related
* [PATCH v2 06/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
From: Sebastian Hesselbarth @ 2014-01-23 0:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123001934.GY18269@obsidianresearch.com>
On 01/23/2014 01:19 AM, Jason Gunthorpe wrote:
> On Thu, Jan 23, 2014 at 01:03:26AM +0100, Sebastian Hesselbarth wrote:
>>> Sebastian:
>>> I looked at the irq-orion driver a bit more and noticed this:
>>>
>>> ret = irq_alloc_domain_generic_chips(domain, nrirqs, 1, np->name,
>>> handle_level_irq, clr, 0, IRQ_GC_INIT_MASK_CACHE);
>>> ^^^^^^^^^^^^^^^^^^^^^
>>> Shouldn't it be handle_edge_irq? Otherwise who is calling irq_ack? How
>>> does this work at all? :)
>>
>> I can tell you that it comes from arch/arm/plat-orion/irq.c and I
>> blindly copied it. I never really checked the differences in handling
>> level/edge irqs. Besides, if it wasn't working, we wouldn't get far
>> in booting the kernel without timer irqs.
>
> Ezequiel found the ack call I missed, so it makes sense it works.
>
> I think the difference in routines only starts to matter when you can
> get another incoming edge IRQ while already handling one (due to SMP?
> threaded interrupts? RealTime? not sure)
>
>> It also remains asserted if you clear the actual cause of the interrupt
>> and is only asserted again on the next low-to-high transition.
>
> Which is why Ezequiel's patch is the right approach: we need to clear
> the interrupt latched in the cause register after the watchdog driver
> disable but before enabling/unmasking the interrupt.
>
> Remember, the BRIDGE_MASK register has no effect on the BRIDGE_CAUSE,
> it only effects which bits propogate to the main cause register.
Yeah, I know. But you don't get new ones if mask them. At least for
edge triggered irqs, you can also clear them without clearing the
cause of the interrupt. Nevertheless, I think we agree here.
>> *BUT*, I will double-check how Linux deals with level/edge irqs and if
>> Orion SoCs have edge or level triggered cause registers. That should
>> reveal, if it is more sane to use handle_edge_irq here and possibly in
>> the main interrupt controller, too.
>
> There is a mixture.
>
> Any cause bit documented to be clearable is edge triggered, all others
> are level.
>
> On Kirkwood this means all of the main interrupt controller bits are
> level and all the bridge bits are edge. Which means edge is
> definitely correct for the bridge handler, and level correct for the
> main handler.
Just checked that for Dove, it is the same there. Main IRQ_CAUSE is
RO, BRIDGE_CAUSE is RW0C, and PMU_CAUSE is RW *sigh*.
I need to remember that when Dove moves over to mach-mvebu, as we need
a different chained irq handler for PMU that deals with that broken RW
register.
Sebastian
^ permalink raw reply
* [PATCH RFC 04/10] base: power: Add generic OF-based power domain look-up
From: Stephen Boyd @ 2014-01-23 0:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DD4DB1.2050200@samsung.com>
On 01/20, Tomasz Figa wrote:
> Hi Kevin,
>
> On 14.01.2014 16:42, Kevin Hilman wrote:
> >Tomasz Figa <tomasz.figa@gmail.com> writes:
> >
> >>This patch introduces generic code to perform power domain look-up using
> >>device tree and automatically bind devices to their power domains.
> >>Generic device tree binding is introduced to specify power domains of
> >>devices in their device tree nodes.
> >>
> >>Backwards compatibility with legacy Samsung-specific power domain
> >>bindings is provided, but for now the new code is not compiled when
> >>CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
> >>will change as soon as Exynos power domain code gets converted to use
> >>the generic framework in further patch.
> >>
> >>Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
> >
> >I haven't read through this in detail yet, but wanted to make sure that
> >the DT representation can handle nested power domains. At least
> >SH-mobile has a hierarchy of power domains and the genpd code can handle
> >that, so wanted to make sure that the DT representation can handle it as
> >well.
>
> The representation of power domains themselves as implied by this
> patch is fully platform-specific. The only generic part is the
> #power-domain-cells property, which defines the number of cells
> needed to identify the power domain of given provider. You are free
> to have any platform-specific properties (or even generic ones,
> added on top of this patch) to let you specify the hierarchy in DT.
>
(Semi-related to this thread, but not really the patchset)
I'd like to have a way to say that this power domain is a
subdomain of another domain provided by a different power domain
provider driver. From what I can tell, the only way to reparent
domains as of today is by name or reference and you have to make
a function call to do it (pm_genpd_add_subdomain_names() or
pm_genpd_add_subdomain()). This is annoying in the case where all
the power domains are not regsitered within the same driver
because we don't know which driver comes first.
It would be great if there was a way to specify this relationship
explicitly when initializing a power domain so that the
reparenting is done automatically without requiring any explicit
function call. Perhaps DT could specify this? Or we could add
another field to the generic_power_domain struct like parent_name?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH RFC 04/10] base: power: Add generic OF-based power domain look-up
From: Tomasz Figa @ 2014-01-23 0:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123001802.GF13785@codeaurora.org>
Hi Stephen,
On 23.01.2014 01:18, Stephen Boyd wrote:
> On 01/11, Tomasz Figa wrote:
>> +
>> +/**
>> + * of_genpd_lock() - Lock access to of_genpd_providers list
>> + */
>> +static void of_genpd_lock(void)
>> +{
>> + mutex_lock(&of_genpd_mutex);
>> +}
>> +
>> +/**
>> + * of_genpd_unlock() - Unlock access to of_genpd_providers list
>> + */
>> +static void of_genpd_unlock(void)
>> +{
>> + mutex_unlock(&of_genpd_mutex);
>> +}
>
> Why do we need these functions? Can't we just call
> mutex_lock/unlock directly?
That would be fine as well, I guess. Just duplicated the pattern used in
CCF, but can remove them in next version if it's found to be better.
>
>> +
>> +/**
>> + * of_genpd_add_provider() - Register a domain provider for a node
>> + * @np: Device node pointer associated with domain provider
>> + * @genpd_src_get: callback for decoding domain
>> + * @data: context pointer for @genpd_src_get callback.
>
> These look a little outdated.
Oops, missed this.
>
>> + */
>> +int of_genpd_add_provider(struct device_node *np, genpd_xlate_t xlate,
>> + void *data)
>> +{
>> + struct of_genpd_provider *cp;
>> +
>> + cp = kzalloc(sizeof(struct of_genpd_provider), GFP_KERNEL);
>
> Please use sizeof(*cp) instead.
Right.
>
>> + if (!cp)
>> + return -ENOMEM;
>> +
>> + cp->node = of_node_get(np);
>> + cp->data = data;
>> + cp->xlate = xlate;
>> +
>> + of_genpd_lock();
>> + list_add(&cp->link, &of_genpd_providers);
>> + of_genpd_unlock();
>> + pr_debug("Added domain provider from %s\n", np->full_name);
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(of_genpd_add_provider);
>> +
> [...]
>> +
>> +/* See of_genpd_get_from_provider(). */
>> +static struct generic_pm_domain *__of_genpd_get_from_provider(
>> + struct of_phandle_args *genpdspec)
>> +{
>> + struct of_genpd_provider *provider;
>> + struct generic_pm_domain *genpd = ERR_PTR(-ENOENT);
>
> Can this be -EPROBE_DEFER so that we can defer probe until a
> later time if the power domain provider hasn't registered yet?
Yes, this could be useful. Makes me wonder why clock code (on which I
based this code) doesn't have it done this way.
>
>> +
>> + /* Check if we have such a provider in our array */
>> + list_for_each_entry(provider, &of_genpd_providers, link) {
>> + if (provider->node == genpdspec->np)
>> + genpd = provider->xlate(genpdspec, provider->data);
>> + if (!IS_ERR(genpd))
>> + break;
>> + }
>> +
>> + return genpd;
>> +}
>> +
> [...]
>> +static int of_genpd_notifier_call(struct notifier_block *nb,
>> + unsigned long event, void *data)
>> +{
>> + struct device *dev = data;
>> + int ret;
>> +
>> + if (!dev->of_node)
>> + return NOTIFY_DONE;
>> +
>> + switch (event) {
>> + case BUS_NOTIFY_BIND_DRIVER:
>> + ret = of_genpd_add_to_domain(dev);
>> + break;
>> +
>> + case BUS_NOTIFY_UNBOUND_DRIVER:
>> + ret = of_genpd_del_from_domain(dev);
>> + break;
>> +
>> + default:
>> + return NOTIFY_DONE;
>> + }
>> +
>> + return notifier_from_errno(ret);
>> +}
>> +
>> +static struct notifier_block of_genpd_notifier_block = {
>> + .notifier_call = of_genpd_notifier_call,
>> +};
>> +
>> +static int of_genpd_init(void)
>> +{
>> + return bus_register_notifier(&platform_bus_type,
>> + &of_genpd_notifier_block);
>> +}
>> +core_initcall(of_genpd_init);
>
> Would it be possible to call the of_genpd_add_to_domain() and
> of_genpd_del_from_domain() functions directly in the driver core,
> similar to how the pinctrl framework has a hook in there? That
> way we're not relying on any initcall ordering for this.
Hmm, the initcall here just registers a notifier, which needs to be done
just before any driver registers. So, IMHO, current variant is safe,
given an early enough initcall level is used.
However, doing it the pinctrl way might still have an advantage of not
relying on specific bus type, so this is worth consideration indeed. I'd
like to hear Rafael's and Kevin's opinions on this (and other comments
above too).
Best regards,
Tomasz
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with Linus' tree
From: Stephen Rothwell @ 2014-01-23 0:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/boot/dts/bcm11351.dtsi between commit 67a57be85e68 ("ARM:
bcm11351: Enable pinctrl for Broadcom Capri SoCs") from Linus' tree and
commit 0bd898b872ac ("ARM: dts: Declare clocks as fixed on bcm11351") and
several following commits from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
diff --cc arch/arm/boot/dts/bcm11351.dtsi
index dd8e878741c0,375a2f8eb878..000000000000
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@@ -142,8 -146,159 +146,164 @@@
status = "disabled";
};
+ pinctrl at 35004800 {
+ compatible = "brcm,capri-pinctrl";
+ reg = <0x35004800 0x430>;
+ };
++
+ i2c at 3e016000 {
+ compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
+ reg = <0x3e016000 0x80>;
+ interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&bsc1_clk>;
+ status = "disabled";
+ };
+
+ i2c at 3e017000 {
+ compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
+ reg = <0x3e017000 0x80>;
+ interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&bsc2_clk>;
+ status = "disabled";
+ };
+
+ i2c at 3e018000 {
+ compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
+ reg = <0x3e018000 0x80>;
+ interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&bsc3_clk>;
+ status = "disabled";
+ };
+
+ i2c at 3500d000 {
+ compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
+ reg = <0x3500d000 0x80>;
+ interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&pmu_bsc_clk>;
+ status = "disabled";
+ };
+
+ clocks {
+ bsc1_clk: bsc1 {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ bsc2_clk: bsc2 {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ bsc3_clk: bsc3 {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ pmu_bsc_clk: pmu_bsc {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ hub_timer_clk: hub_timer {
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ #clock-cells = <0>;
+ };
+
+ pwm_clk: pwm {
+ compatible = "fixed-clock";
+ clock-frequency = <26000000>;
+ #clock-cells = <0>;
+ };
+
+ sdio1_clk: sdio1 {
+ compatible = "fixed-clock";
+ clock-frequency = <48000000>;
+ #clock-cells = <0>;
+ };
+
+ sdio2_clk: sdio2 {
+ compatible = "fixed-clock";
+ clock-frequency = <48000000>;
+ #clock-cells = <0>;
+ };
+
+ sdio3_clk: sdio3 {
+ compatible = "fixed-clock";
+ clock-frequency = <48000000>;
+ #clock-cells = <0>;
+ };
+
+ sdio4_clk: sdio4 {
+ compatible = "fixed-clock";
+ clock-frequency = <48000000>;
+ #clock-cells = <0>;
+ };
+
+ tmon_1m_clk: tmon_1m {
+ compatible = "fixed-clock";
+ clock-frequency = <1000000>;
+ #clock-cells = <0>;
+ };
+
+ uartb_clk: uartb {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ uartb2_clk: uartb2 {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ uartb3_clk: uartb3 {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ uartb4_clk: uartb4 {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ usb_otg_ahb_clk: usb_otg_ahb {
+ compatible = "fixed-clock";
+ clock-frequency = <52000000>;
+ #clock-cells = <0>;
+ };
+ };
+
+ usbotg: usb at 3f120000 {
+ compatible = "snps,dwc2";
+ reg = <0x3f120000 0x10000>;
+ interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&usb_otg_ahb_clk>;
+ clock-names = "otg";
+ phys = <&usbphy>;
+ phy-names = "usb2-phy";
+ status = "disabled";
+ };
+
+ usbphy: usb-phy at 3f130000 {
+ compatible = "brcm,kona-usb2-phy";
+ reg = <0x3f130000 0x28>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
};
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140123/56f7fd1b/attachment.sig>
^ permalink raw reply
* [PATCH v2 06/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
From: Jason Gunthorpe @ 2014-01-23 0:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E05C4E.9060709@gmail.com>
On Thu, Jan 23, 2014 at 01:03:26AM +0100, Sebastian Hesselbarth wrote:
> >Sebastian:
> >I looked at the irq-orion driver a bit more and noticed this:
> >
> > ret = irq_alloc_domain_generic_chips(domain, nrirqs, 1, np->name,
> > handle_level_irq, clr, 0, IRQ_GC_INIT_MASK_CACHE);
> > ^^^^^^^^^^^^^^^^^^^^^
> >Shouldn't it be handle_edge_irq? Otherwise who is calling irq_ack? How
> >does this work at all? :)
>
> I can tell you that it comes from arch/arm/plat-orion/irq.c and I
> blindly copied it. I never really checked the differences in handling
> level/edge irqs. Besides, if it wasn't working, we wouldn't get far
> in booting the kernel without timer irqs.
Ezequiel found the ack call I missed, so it makes sense it works.
I think the difference in routines only starts to matter when you can
get another incoming edge IRQ while already handling one (due to SMP?
threaded interrupts? RealTime? not sure)
> It also remains asserted if you clear the actual cause of the interrupt
> and is only asserted again on the next low-to-high transition.
Which is why Ezequiel's patch is the right approach: we need to clear
the interrupt latched in the cause register after the watchdog driver
disable but before enabling/unmasking the interrupt.
Remember, the BRIDGE_MASK register has no effect on the BRIDGE_CAUSE,
it only effects which bits propogate to the main cause register.
> *BUT*, I will double-check how Linux deals with level/edge irqs and if
> Orion SoCs have edge or level triggered cause registers. That should
> reveal, if it is more sane to use handle_edge_irq here and possibly in
> the main interrupt controller, too.
There is a mixture.
Any cause bit documented to be clearable is edge triggered, all others
are level.
On Kirkwood this means all of the main interrupt controller bits are
level and all the bridge bits are edge. Which means edge is
definitely correct for the bridge handler, and level correct for the
main handler.
Jason
^ permalink raw reply
* [PATCH RFC 04/10] base: power: Add generic OF-based power domain look-up
From: Stephen Boyd @ 2014-01-23 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389469372-17199-5-git-send-email-tomasz.figa@gmail.com>
On 01/11, Tomasz Figa wrote:
> +
> +/**
> + * of_genpd_lock() - Lock access to of_genpd_providers list
> + */
> +static void of_genpd_lock(void)
> +{
> + mutex_lock(&of_genpd_mutex);
> +}
> +
> +/**
> + * of_genpd_unlock() - Unlock access to of_genpd_providers list
> + */
> +static void of_genpd_unlock(void)
> +{
> + mutex_unlock(&of_genpd_mutex);
> +}
Why do we need these functions? Can't we just call
mutex_lock/unlock directly?
> +
> +/**
> + * of_genpd_add_provider() - Register a domain provider for a node
> + * @np: Device node pointer associated with domain provider
> + * @genpd_src_get: callback for decoding domain
> + * @data: context pointer for @genpd_src_get callback.
These look a little outdated.
> + */
> +int of_genpd_add_provider(struct device_node *np, genpd_xlate_t xlate,
> + void *data)
> +{
> + struct of_genpd_provider *cp;
> +
> + cp = kzalloc(sizeof(struct of_genpd_provider), GFP_KERNEL);
Please use sizeof(*cp) instead.
> + if (!cp)
> + return -ENOMEM;
> +
> + cp->node = of_node_get(np);
> + cp->data = data;
> + cp->xlate = xlate;
> +
> + of_genpd_lock();
> + list_add(&cp->link, &of_genpd_providers);
> + of_genpd_unlock();
> + pr_debug("Added domain provider from %s\n", np->full_name);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_genpd_add_provider);
> +
[...]
> +
> +/* See of_genpd_get_from_provider(). */
> +static struct generic_pm_domain *__of_genpd_get_from_provider(
> + struct of_phandle_args *genpdspec)
> +{
> + struct of_genpd_provider *provider;
> + struct generic_pm_domain *genpd = ERR_PTR(-ENOENT);
Can this be -EPROBE_DEFER so that we can defer probe until a
later time if the power domain provider hasn't registered yet?
> +
> + /* Check if we have such a provider in our array */
> + list_for_each_entry(provider, &of_genpd_providers, link) {
> + if (provider->node == genpdspec->np)
> + genpd = provider->xlate(genpdspec, provider->data);
> + if (!IS_ERR(genpd))
> + break;
> + }
> +
> + return genpd;
> +}
> +
[...]
> +static int of_genpd_notifier_call(struct notifier_block *nb,
> + unsigned long event, void *data)
> +{
> + struct device *dev = data;
> + int ret;
> +
> + if (!dev->of_node)
> + return NOTIFY_DONE;
> +
> + switch (event) {
> + case BUS_NOTIFY_BIND_DRIVER:
> + ret = of_genpd_add_to_domain(dev);
> + break;
> +
> + case BUS_NOTIFY_UNBOUND_DRIVER:
> + ret = of_genpd_del_from_domain(dev);
> + break;
> +
> + default:
> + return NOTIFY_DONE;
> + }
> +
> + return notifier_from_errno(ret);
> +}
> +
> +static struct notifier_block of_genpd_notifier_block = {
> + .notifier_call = of_genpd_notifier_call,
> +};
> +
> +static int of_genpd_init(void)
> +{
> + return bus_register_notifier(&platform_bus_type,
> + &of_genpd_notifier_block);
> +}
> +core_initcall(of_genpd_init);
Would it be possible to call the of_genpd_add_to_domain() and
of_genpd_del_from_domain() functions directly in the driver core,
similar to how the pinctrl framework has a hook in there? That
way we're not relying on any initcall ordering for this.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v2 06/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
From: Sebastian Hesselbarth @ 2014-01-23 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122223117.GX18269@obsidianresearch.com>
On 01/22/2014 11:31 PM, Jason Gunthorpe wrote:
> On Wed, Jan 22, 2014 at 07:12:38PM -0300, Ezequiel Garcia wrote:
>> On Wed, Jan 22, 2014 at 01:52:13PM -0700, Jason Gunthorpe wrote:
>>>> Clearing BRIDGE_CAUSE will only clear all currently pending upstream
>>>> IRQs, of course. If WDT IRQ will be re-raised right after that in
>>>> BRIDGE_CAUSE depends on the actual HW implementation, i.e. we do no
>>>> clear the causing IRQ itself but just what it raised in BRIDGE_CAUSE.
>>>
>>> Which is why it makes no sense to clear it one time at kernel start.
>>>
>>
>> So, it seems we need to handle irq_startup(), as you suggested.
>> I've just tested the attached patch, and it's working fine: the driver's
>> probe() fully stops the watchdog, and then request_irq() acks and
>> pending interrupts, through the added irq_startup().
>>
>> How does it look?
>
> Looks sane to me.
>
> I looked some more and there are other drivers (eg irq-metag-ext) that
> take this same approach.
>
> Sebastian:
> I looked at the irq-orion driver a bit more and noticed this:
>
> ret = irq_alloc_domain_generic_chips(domain, nrirqs, 1, np->name,
> handle_level_irq, clr, 0, IRQ_GC_INIT_MASK_CACHE);
> ^^^^^^^^^^^^^^^^^^^^^
> Shouldn't it be handle_edge_irq? Otherwise who is calling irq_ack? How
> does this work at all? :)
I can tell you that it comes from arch/arm/plat-orion/irq.c and I
blindly copied it. I never really checked the differences in handling
level/edge irqs. Besides, if it wasn't working, we wouldn't get far
in booting the kernel without timer irqs.
From a HW point-of-view, I'd say the difference is that an
edge-triggered irq samples level transitions from e.g. low to high.
It also remains asserted if you clear the actual cause of the interrupt
and is only asserted again on the next low-to-high transition.
A level-triggered irq will be asserted as long as the cause of the irq
is asserted. If you clear the cause, you'll also clear that bit in the
upstream controller.
*BUT*, I will double-check how Linux deals with level/edge irqs and if
Orion SoCs have edge or level triggered cause registers. That should
reveal, if it is more sane to use handle_edge_irq here and possibly in
the main interrupt controller, too.
Sebastian
^ permalink raw reply
* [BUG] FL1009: xHCI host not responding to stop endpoint command.
From: Sarah Sharp @ 2014-01-22 23:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87mwin4ozf.fsf@natisbad.org>
On Wed, Jan 22, 2014 at 11:43:16PM +0100, Arnaud Ebalard wrote:
> Hi Jason,
>
> Jason Cooper <jason@lakedaemon.net> writes:
>
> > On Wed, Jan 22, 2014 at 11:23:23PM +0100, Arnaud Ebalard wrote:
> >> With the patch applied on top of 3.13.0 kernel recompiled w/
> >> CONFIG_PCI_MSI enabled, I cannot reproduce the bug. I guess
> >> you can add my:
> >>
> >> Reported-and-tested-By: Arnaud Ebalard <arno@natisbad.org>
> >>
> >> Since you'll have to push the patch to -stable team at least for 3.13,
> >> I wonder if it would not make sense to extend that at least to 3.12.
> >> and possibly 3.10 (3.2 is still widely used but I wonder if it makes
> >> sense to go that far).
> >
> > Can you pinpoint the commit that introduced the regression?
>
> f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some Fresco Logic hosts."
>
> Technically, this is not per se the commit which introduced the
> regression but the one that *partially* fixed it by introducing the XHCI
> quirk to skip MSI enabling for Fresco Logic chips. The thing is it
> should have included the FL1009 in the targets. Sarah, can you confirm
> this?
I don't know if it should have included FL1009, it was just a guess,
based on the fact that the 0x1000 and 0x1400 devices did need MSI
disabled. I can attempt to ask the Fresco Logic folks I know, but I'm
not sure if/when I'll get a response back.
That still doesn't necessarily rule out MSI issues in the Marvell PCI
host controller code. Can you attach another PCI device with MSI
support under the host and see if it works?
Sarah Sharp
> Jason, the logic is summarized here, AFAICT:
>
> commit 455f58925247e8a1a1941e159f3636ad6ee4c90b
> Author: Oliver Neukum <oneukum@suse.de>
> Date: Mon Sep 30 15:50:54 2013 +0200
>
> xhci: quirk for extra long delay for S4
>
> It has been reported that this chipset really cannot
> sleep without this extraordinary delay.
>
> This patch should be backported, in order to ensure this host functions
> under stable kernels. The last quirk for Fresco Logic hosts (commit
> bba18e33f25072ebf70fd8f7f0cdbf8cdb59a746 "xhci: Extend Fresco Logic MSI
> quirk.") was backported to stable kernels as old as 2.6.36.
>
> Signed-off-by: Oliver Neukum <oneukum@suse.de>
> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Cc: stable at vger.kernel.org
>
>
> commit bba18e33f25072ebf70fd8f7f0cdbf8cdb59a746
> Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Date: Wed Oct 17 13:44:06 2012 -0700
>
> xhci: Extend Fresco Logic MSI quirk.
>
> Ali reports that plugging a device into the Fresco Logic xHCI host with
> PCI device ID 1400 produces an IRQ error:
>
> do_IRQ: 3.176 No irq handler for vector (irq -1)
>
> Other early Fresco Logic host revisions don't support MSI, even though
> their PCI config space claims they do. Extend the quirk to disabling
> MSI to this chipset revision. Also enable the short transfer quirk,
> since it's likely this revision also has that quirk, and it should be
> harmless to enable.
>
> <SNIP>
>
> This patch should be backported to stable kernels as old as 2.6.36, that
> contain the commit f5182b4155b9d686c5540a6822486400e34ddd98 "xhci:
> Disable MSI for some Fresco Logic hosts."
>
> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Reported-by: A Sh <smr.ash1991@gmail.com>
> Tested-by: A Sh <smr.ash1991@gmail.com>
> Cc: stable at vger.kernel.org
>
>
> commit f5182b4155b9d686c5540a6822486400e34ddd98
> Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Date: Thu Jun 2 11:33:02 2011 -0700
>
> xhci: Disable MSI for some Fresco Logic hosts.
>
> Some Fresco Logic hosts, including those found in the AUAU N533V laptop,
> advertise MSI, but fail to actually generate MSI interrupts. Add a new
> xHCI quirk to skip MSI enabling for the Fresco Logic host controllers.
> Fresco Logic confirms that all chips with PCI vendor ID 0x1b73 and device
> ID 0x1000, regardless of PCI revision ID, do not support MSI.
>
> This should be backported to stable kernels as far back as 2.6.36, which
> was the first kernel to support MSI on xHCI hosts.
>
> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Reported-by: Sergey Galanov <sergey.e.galanov@gmail.com>
> Cc: stable at kernel.org
^ 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