* [PATCH] ARM: i.MX6: add more chip revision support
From: Shawn Guo @ 2014-07-21 5:38 UTC (permalink / raw)
To: linux-arm-kernel
From: Jason Liu <r64343@freescale.com>
Add more revision support for the new i.MX6DQ tap-out (TO1.5). This
TO1.5 is the Rev 1.3 as documented in i.MX6DQ data sheet, because TO1.3
and TO1.4 are never revealed.
Signed-off-by: Jason Liu <r64343@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
---
arch/arm/mach-imx/anatop.c | 9 +++++++++
arch/arm/mach-imx/mxc.h | 2 ++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/mach-imx/anatop.c b/arch/arm/mach-imx/anatop.c
index 4a40bbb46183..459ba290744b 100644
--- a/arch/arm/mach-imx/anatop.c
+++ b/arch/arm/mach-imx/anatop.c
@@ -104,6 +104,15 @@ void __init imx_init_revision_from_anatop(void)
case 2:
revision = IMX_CHIP_REVISION_1_2;
break;
+ case 3:
+ revision = IMX_CHIP_REVISION_1_3;
+ break;
+ case 4:
+ revision = IMX_CHIP_REVISION_1_4;
+ break;
+ case 5:
+ revision = IMX_CHIP_REVISION_1_5;
+ break;
default:
revision = IMX_CHIP_REVISION_UNKNOWN;
}
diff --git a/arch/arm/mach-imx/mxc.h b/arch/arm/mach-imx/mxc.h
index a39b69ef4301..17a41ca65acf 100644
--- a/arch/arm/mach-imx/mxc.h
+++ b/arch/arm/mach-imx/mxc.h
@@ -43,6 +43,8 @@
#define IMX_CHIP_REVISION_1_1 0x11
#define IMX_CHIP_REVISION_1_2 0x12
#define IMX_CHIP_REVISION_1_3 0x13
+#define IMX_CHIP_REVISION_1_4 0x14
+#define IMX_CHIP_REVISION_1_5 0x15
#define IMX_CHIP_REVISION_2_0 0x20
#define IMX_CHIP_REVISION_2_1 0x21
#define IMX_CHIP_REVISION_2_2 0x22
--
1.9.1
^ permalink raw reply related
* Issue found in Armada 370: "No buffer space available" error during continuous ping
From: Willy Tarreau @ 2014-07-21 5:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAB8gEUvwPJUhDN-=tugTyKe93SdNwqNaGtKMF1DRCb8ZNncmmg@mail.gmail.com>
Hi Maggie,
On Sun, Jul 20, 2014 at 07:45:13PM -0700, Maggie Mae Roxas wrote:
> Hi Willy,
> Good day.
>
> BTW, here are some answers to your questions.
>
> > In fact I don't know if you're running your own board or a "standard"
> one (a mirabox or any NAS board).
> We are using a "customized" one, not a "standard" one.
> We based the design on Armada 370 RD Evaluation Board, but we used
> Marvell 88E1512 as Ethernet PHY and Marvell 88F6707 as processor
> instead of the ones in the Armada 370 RD (I think it uses Marvell
> 88E1310 as Ethernet PHY and Marvell 88F6W11 as processor).
OK. For information, the mirabox uses a 88F6707 and a 88E1510 for
the phy. So it's very close to what you have.
> > Maggie, do you know if it is possible that for any reason your board
> would not deliver an IRQ on Tx completion ? That could explain things.
> > You can easily test reverting commit 4f3a4f701b just in case.
> > If that's the case, then the next step will be to figure out how it is possible
> that IRQs are disabled!
> After reverting 4f3a4f701b, as I reported, issue does not happen anymore.
As you said that you both applied cd71e2 and reverted 4f3a4f, could you
please confirm that with cd71 applied only it was not enough ? I'm
finding it really strange, because as you use the same CPU as the
mirabox, I'm seeing no reason why the IRQ wouldn't work, and since
you're using a slightly different phy from us, the first patch which
changes the the RGMII configuration (cd71e2) would be a more likely
candidate.
> Please let me know how to "figure out how it is possible that IRQs are
> disabled".
Checking /proc/interrupts when you're sending some traffic should show
that the IRQ is increasing from time to time.
> Also, what is the impact if I use this combination?
First you're not using a mainline kernel which means that you'll always
be bothered. Second, removing support for the Tx IRQ means that your
Tx traffic can become very slow (typically 134 Mbps instead of 987 for
unidirectional traffic), which can be a problem if your board is used
as a router for example. If you're building a NAS, you'll have less
impact. Third, considering that other boards work without applying
these changes, it might be possible that there's an issue on your
board, and maybe detecting it early would allow you to fix it for all
future batches, and maybe only apply these patches for the few very
first ones.
Regards,
Willy
^ permalink raw reply
* [PATCH] spi: omap2-mcspi: fix blatant abuse of the resource subsystem
From: Lothar Waßmann @ 2014-07-21 5:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718171035.GQ17528@sirena.org.uk>
Hi,
Mark Brown wrote:
> On Fri, Jul 18, 2014 at 01:30:53PM +0200, Lothar Wa?mann wrote:
> > Aua. This really hurts. I wonder how this could ever be admitted to
> > the Linux kernel...
> > Further comments suppressed because the would most likely violate the
> > CDA.
> >
> > If someone should not grasp what this patch does, they should consider
> > what happens upon unloading/reloading the kernel module.
> >
> > Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
>
> I'm not going to apply this with a commit message such as the above.
> Quite aside from the tone the fact that it doesn't describe the issue
> is not helpful for review, one of the things done in review is to try to
> check that the change has the intended effect.
>
Maybe the original author or the maintainer who accepted this can come
up with a decent fix for this.
Lothar Wa?mann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
^ permalink raw reply
* [RESEND PATCH] thermal: samsung: Add TMU support for Exynos3250 SoC
From: Zhang Rui @ 2014-07-21 6:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405641605-3370-1-git-send-email-cw00.choi@samsung.com>
On Fri, 2014-07-18 at 09:00 +0900, Chanwoo Choi wrote:
> This patch adds the registers, bit fields and compatible strings
> required to support for the 1 TMU channels on Exynos3250.
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> [Add MUX address setting bits by Jonghwa Lee]
> Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> Reviewed-by: Amit Daniel Kachhap<amit.daniel@samsung.com>
Eduardo and Amit,
do you have any comments on this?
thanks,
rui
> ---
> .../devicetree/bindings/thermal/exynos-thermal.txt | 1 +
> drivers/thermal/samsung/exynos_tmu.c | 7 +-
> drivers/thermal/samsung/exynos_tmu.h | 3 +-
> drivers/thermal/samsung/exynos_tmu_data.c | 89 ++++++++++++++++++++++
> drivers/thermal/samsung/exynos_tmu_data.h | 7 ++
> 5 files changed, 105 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> index c949092..ae738f5 100644
> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> @@ -3,6 +3,7 @@
> ** Required properties:
>
> - compatible : One of the following:
> + "samsung,exynos3250-tmu"
> "samsung,exynos4412-tmu"
> "samsung,exynos4210-tmu"
> "samsung,exynos5250-tmu"
> diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
> index d7ca9f4..a2a08ea 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -505,6 +505,10 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
>
> static const struct of_device_id exynos_tmu_match[] = {
> {
> + .compatible = "samsung,exynos3250-tmu",
> + .data = (void *)EXYNOS3250_TMU_DRV_DATA,
> + },
> + {
> .compatible = "samsung,exynos4210-tmu",
> .data = (void *)EXYNOS4210_TMU_DRV_DATA,
> },
> @@ -677,7 +681,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
> goto err_clk_sec;
> }
>
> - if (pdata->type == SOC_ARCH_EXYNOS4210 ||
> + if (pdata->type == SOC_ARCH_EXYNOS3250 ||
> + pdata->type == SOC_ARCH_EXYNOS4210 ||
> pdata->type == SOC_ARCH_EXYNOS4412 ||
> pdata->type == SOC_ARCH_EXYNOS5250 ||
> pdata->type == SOC_ARCH_EXYNOS5260 ||
> diff --git a/drivers/thermal/samsung/exynos_tmu.h b/drivers/thermal/samsung/exynos_tmu.h
> index edd08cf..1b4a644 100644
> --- a/drivers/thermal/samsung/exynos_tmu.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -40,7 +40,8 @@ enum calibration_mode {
> };
>
> enum soc_type {
> - SOC_ARCH_EXYNOS4210 = 1,
> + SOC_ARCH_EXYNOS3250 = 1,
> + SOC_ARCH_EXYNOS4210,
> SOC_ARCH_EXYNOS4412,
> SOC_ARCH_EXYNOS5250,
> SOC_ARCH_EXYNOS5260,
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c b/drivers/thermal/samsung/exynos_tmu_data.c
> index c1d81dc..aa8e0de 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.c
> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
> @@ -90,6 +90,95 @@ struct exynos_tmu_init_data const exynos4210_default_tmu_data = {
> };
> #endif
>
> +#if defined(CONFIG_SOC_EXYNOS3250)
> +static const struct exynos_tmu_registers exynos3250_tmu_registers = {
> + .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
> + .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
> + .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
> + .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
> + .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
> + .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
> + .buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
> + .therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT,
> + .therm_trip_mode_mask = EXYNOS_TMU_TRIP_MODE_MASK,
> + .therm_trip_en_shift = EXYNOS_TMU_THERM_TRIP_EN_SHIFT,
> + .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
> + .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
> + .core_en_shift = EXYNOS_TMU_CORE_EN_SHIFT,
> + .tmu_status = EXYNOS_TMU_REG_STATUS,
> + .tmu_cur_temp = EXYNOS_TMU_REG_CURRENT_TEMP,
> + .threshold_th0 = EXYNOS_THD_TEMP_RISE,
> + .threshold_th1 = EXYNOS_THD_TEMP_FALL,
> + .tmu_inten = EXYNOS_TMU_REG_INTEN,
> + .inten_rise0_shift = EXYNOS_TMU_INTEN_RISE0_SHIFT,
> + .inten_rise1_shift = EXYNOS_TMU_INTEN_RISE1_SHIFT,
> + .inten_rise2_shift = EXYNOS_TMU_INTEN_RISE2_SHIFT,
> + .inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
> + .tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
> + .tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
> + .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
> + .intclr_rise_shift = EXYNOS_TMU_RISE_INT_SHIFT,
> + .intclr_rise_mask = EXYNOS_TMU_RISE_INT_MASK,
> + .intclr_fall_mask = EXYNOS_TMU_FALL_INT_MASK,
> + .emul_con = EXYNOS_EMUL_CON,
> + .emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
> + .emul_time_shift = EXYNOS_EMUL_TIME_SHIFT,
> + .emul_time_mask = EXYNOS_EMUL_TIME_MASK,
> +};
> +
> +#define EXYNOS3250_TMU_DATA \
> + .threshold_falling = 10, \
> + .trigger_levels[0] = 70, \
> + .trigger_levels[1] = 95, \
> + .trigger_levels[2] = 110, \
> + .trigger_levels[3] = 120, \
> + .trigger_enable[0] = true, \
> + .trigger_enable[1] = true, \
> + .trigger_enable[2] = true, \
> + .trigger_enable[3] = false, \
> + .trigger_type[0] = THROTTLE_ACTIVE, \
> + .trigger_type[1] = THROTTLE_ACTIVE, \
> + .trigger_type[2] = SW_TRIP, \
> + .trigger_type[3] = HW_TRIP, \
> + .max_trigger_level = 4, \
> + .gain = 8, \
> + .reference_voltage = 16, \
> + .noise_cancel_mode = 4, \
> + .cal_type = TYPE_TWO_POINT_TRIMMING, \
> + .efuse_value = 55, \
> + .min_efuse_value = 40, \
> + .max_efuse_value = 100, \
> + .first_point_trim = 25, \
> + .second_point_trim = 85, \
> + .default_temp_offset = 50, \
> + .freq_tab[0] = { \
> + .freq_clip_max = 800 * 1000, \
> + .temp_level = 70, \
> + }, \
> + .freq_tab[1] = { \
> + .freq_clip_max = 400 * 1000, \
> + .temp_level = 95, \
> + }, \
> + .freq_tab_count = 2, \
> + .registers = &exynos3250_tmu_registers, \
> + .features = (TMU_SUPPORT_EMULATION | \
> + TMU_SUPPORT_FALLING_TRIP | TMU_SUPPORT_READY_STATUS | \
> + TMU_SUPPORT_EMUL_TIME)
> +#endif
> +
> +#if defined(CONFIG_SOC_EXYNOS3250)
> +struct exynos_tmu_init_data const exynos3250_default_tmu_data = {
> + .tmu_data = {
> + {
> + EXYNOS3250_TMU_DATA,
> + .type = SOC_ARCH_EXYNOS3250,
> + .test_mux = EXYNOS4412_MUX_ADDR_VALUE,
> + },
> + },
> + .tmu_count = 1,
> +};
> +#endif
> +
> #if defined(CONFIG_SOC_EXYNOS4412) || defined(CONFIG_SOC_EXYNOS5250)
> static const struct exynos_tmu_registers exynos4412_tmu_registers = {
> .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.h b/drivers/thermal/samsung/exynos_tmu_data.h
> index d268981..f0979e5 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.h
> +++ b/drivers/thermal/samsung/exynos_tmu_data.h
> @@ -148,6 +148,13 @@
> #define EXYNOS5440_TMU_TH_RISE4_SHIFT 24
> #define EXYNOS5440_EFUSE_SWAP_OFFSET 8
>
> +#if defined(CONFIG_SOC_EXYNOS3250)
> +extern struct exynos_tmu_init_data const exynos3250_default_tmu_data;
> +#define EXYNOS3250_TMU_DRV_DATA (&exynos3250_default_tmu_data)
> +#else
> +#define EXYNOS3250_TMU_DRV_DATA (NULL)
> +#endif
> +
> #if defined(CONFIG_CPU_EXYNOS4210)
> extern struct exynos_tmu_init_data const exynos4210_default_tmu_data;
> #define EXYNOS4210_TMU_DRV_DATA (&exynos4210_default_tmu_data)
^ permalink raw reply
* [PATCH v2] watchdog: imx2_wdt: add support for WDOG_B signal generation
From: Uwe Kleine-König @ 2014-07-21 6:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405683510-1303-1-git-send-email-list-09_linux_arm@tqsc.de>
On Fri, Jul 18, 2014 at 01:38:30PM +0200, Markus Niebel wrote:
> From: Markus Niebel <Markus.Niebel@tq-group.com>
>
> Watchdog unit of i.MX supports output of a signal at
> watchdog shutdown. This feature can be useful to signal an
> external supevisor that a watchdog reset occured.
supervisor
> Support this feature as an option via devicetree.
>
> Signed-off-by: Markus Niebel <Markus.Niebel@tq-group.com>
> ---
> History
>
> v2:
> Fix incorrect sent patch
> - add include of.h
> - fix missing if in probe
>
> .../devicetree/bindings/watchdog/fsl-imx-wdt.txt | 3 +++
> drivers/watchdog/imx2_wdt.c | 11 +++++++++--
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
> index 2144af1..cb759cd 100644
> --- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
> +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
> @@ -5,6 +5,9 @@ Required properties:
> - reg : Should contain WDT registers location and length
> - interrupts : Should contain WDT interrupt
>
> +Optional properties:
> +- fsl,use-wre: set if watchdog reset out (WDOG_B) signal shall be asserted
> +
> Examples:
>
> wdt at 73f98000 {
> diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
> index 9d4874f..bde96db 100644
> --- a/drivers/watchdog/imx2_wdt.c
> +++ b/drivers/watchdog/imx2_wdt.c
> @@ -58,6 +58,7 @@ struct imx2_wdt_device {
> struct regmap *regmap;
> struct timer_list timer; /* Pings the watchdog when closed */
> struct watchdog_device wdog;
> + unsigned int use_wre:1; /* enable WRE feature */
> };
>
> static bool nowayout = WATCHDOG_NOWAYOUT;
> @@ -88,7 +89,10 @@ static inline void imx2_wdt_setup(struct watchdog_device *wdog)
> /* Strip the old watchdog Time-Out value */
> val &= ~IMX2_WDT_WCR_WT;
> /* Generate reset if WDOG times out */
> - val &= ~IMX2_WDT_WCR_WRE;
> + if (wdev->use_wre)
> + val |= IMX2_WDT_WCR_WRE;
> + else
> + val &= ~IMX2_WDT_WCR_WRE;
> /* Keep Watchdog Disabled */
> val &= ~IMX2_WDT_WCR_WDE;
> /* Set the watchdog's Time-Out value */
> @@ -219,6 +223,9 @@ static int __init imx2_wdt_probe(struct platform_device *pdev)
> return PTR_ERR(wdev->clk);
> }
>
> + if (of_property_read_bool(pdev->dev.of_node, "fsl,use-wre"))
> + wdev->use_wre = 1;
> +
> wdog = &wdev->wdog;
> wdog->info = &imx2_wdt_info;
> wdog->ops = &imx2_wdt_ops;
> @@ -226,7 +233,7 @@ static int __init imx2_wdt_probe(struct platform_device *pdev)
> wdog->max_timeout = IMX2_WDT_MAX_TIME;
>
> clk_prepare_enable(wdev->clk);
> -
> +
Don't add a space here.
Did you check that this feature works on all cpus that use this driver?
On which of them did you test your change?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Issue found in Armada 370: "No buffer space available" error during continuous ping
From: Maggie Mae Roxas @ 2014-07-21 6:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721054405.GK21834@1wt.eu>
Hi Willy,
Good day.
> OK. For information, the mirabox uses a 88F6707 and a 88E1510 for
the phy.
> So it's very close to what you have.
Noted.
> As you said that you both applied cd71e2 and reverted 4f3a4f, could you
please confirm that with cd71 applied only it was not enough?
Yes.
If mvneta.c used is the v3.13.9 + cd71e2, issue still occurs.
If mvneta.c used is the v3.13.9 + cd71e2 - 4f3a4f, issue does not occur anymore.
> I'm finding it really strange, because as you use the same CPU as the
mirabox,
> I'm seeing no reason why the IRQ wouldn't work, and since
you're using a slightly different phy from us, the first patch which
changes the the RGMII configuration (cd71e2) would be a more likely
candidate.
Okay. First, I'll check if the interrupts are working by checking
this, as you suggested:
<snip>
Checking /proc/interrupts when you're sending some traffic should show
that the IRQ is increasing from time to time.
<snip>
I'll inform you the results within the next 2-3 days.
> First you're not using a mainline kernel which means that you'll always
be bothered.
> Second, removing support for the Tx IRQ means that your Tx traffic can become very slow (typically 134 Mbps instead of 987 for unidirectional traffic), which can be a problem if your board is used as a router for example.
> If you're building a NAS, you'll have less impact.
We'll be using it as a router, thus, it would really be a problem for us.
Will check possibilities of shifting to v3.14+ with our customer -
especially if we found problems in ethernet performance as you
mentioned.
Any recommendations on which version to use, specifically?
> Third, considering that other boards work without applying these changes, it might be possible that there's an issue on your board, and maybe detecting it early would allow you to fix it for all future batches, and maybe only apply these patches for the few very first ones.
Acknowledged.
Once we verified that indeed, the performance was slower (or
interrupts were not increasing) - we will inform our hardware team and
have them investigate this issue further for possible hardware bugs.
Thanks a lot for the help again, I'll let you know as soon as I have more info.
Regards,
Maggie Roxas
On Sun, Jul 20, 2014 at 10:44 PM, Willy Tarreau <w@1wt.eu> wrote:
> Hi Maggie,
>
> On Sun, Jul 20, 2014 at 07:45:13PM -0700, Maggie Mae Roxas wrote:
>> Hi Willy,
>> Good day.
>>
>> BTW, here are some answers to your questions.
>>
>> > In fact I don't know if you're running your own board or a "standard"
>> one (a mirabox or any NAS board).
>> We are using a "customized" one, not a "standard" one.
>> We based the design on Armada 370 RD Evaluation Board, but we used
>> Marvell 88E1512 as Ethernet PHY and Marvell 88F6707 as processor
>> instead of the ones in the Armada 370 RD (I think it uses Marvell
>> 88E1310 as Ethernet PHY and Marvell 88F6W11 as processor).
>
> OK. For information, the mirabox uses a 88F6707 and a 88E1510 for
> the phy. So it's very close to what you have.
>
>> > Maggie, do you know if it is possible that for any reason your board
>> would not deliver an IRQ on Tx completion ? That could explain things.
>> > You can easily test reverting commit 4f3a4f701b just in case.
>> > If that's the case, then the next step will be to figure out how it is possible
>> that IRQs are disabled!
>> After reverting 4f3a4f701b, as I reported, issue does not happen anymore.
>
> As you said that you both applied cd71e2 and reverted 4f3a4f, could you
> please confirm that with cd71 applied only it was not enough ? I'm
> finding it really strange, because as you use the same CPU as the
> mirabox, I'm seeing no reason why the IRQ wouldn't work, and since
> you're using a slightly different phy from us, the first patch which
> changes the the RGMII configuration (cd71e2) would be a more likely
> candidate.
>
>> Please let me know how to "figure out how it is possible that IRQs are
>> disabled".
>
> Checking /proc/interrupts when you're sending some traffic should show
> that the IRQ is increasing from time to time.
>
>> Also, what is the impact if I use this combination?
>
> First you're not using a mainline kernel which means that you'll always
> be bothered. Second, removing support for the Tx IRQ means that your
> Tx traffic can become very slow (typically 134 Mbps instead of 987 for
> unidirectional traffic), which can be a problem if your board is used
> as a router for example. If you're building a NAS, you'll have less
> impact. Third, considering that other boards work without applying
> these changes, it might be possible that there's an issue on your
> board, and maybe detecting it early would allow you to fix it for all
> future batches, and maybe only apply these patches for the few very
> first ones.
>
> Regards,
> Willy
>
^ permalink raw reply
* [PATCH] ARM: i.MX6: add more chip revision support
From: Sascha Hauer @ 2014-07-21 6:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405921091-28748-1-git-send-email-shawn.guo@freescale.com>
On Mon, Jul 21, 2014 at 01:38:11PM +0800, Shawn Guo wrote:
> From: Jason Liu <r64343@freescale.com>
>
> Add more revision support for the new i.MX6DQ tap-out (TO1.5). This
> TO1.5 is the Rev 1.3 as documented in i.MX6DQ data sheet, because TO1.3
> and TO1.4 are never revealed.
So the chip identifies itself as 1.5 but the data sheet refers to it as
1.3. Is there a way to make that clear somewhere? Otherwise it's really
confusing.
Sascha
>
> Signed-off-by: Jason Liu <r64343@freescale.com>
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> ---
> arch/arm/mach-imx/anatop.c | 9 +++++++++
> arch/arm/mach-imx/mxc.h | 2 ++
> 2 files changed, 11 insertions(+)
>
> diff --git a/arch/arm/mach-imx/anatop.c b/arch/arm/mach-imx/anatop.c
> index 4a40bbb46183..459ba290744b 100644
> --- a/arch/arm/mach-imx/anatop.c
> +++ b/arch/arm/mach-imx/anatop.c
> @@ -104,6 +104,15 @@ void __init imx_init_revision_from_anatop(void)
> case 2:
> revision = IMX_CHIP_REVISION_1_2;
> break;
> + case 3:
> + revision = IMX_CHIP_REVISION_1_3;
> + break;
> + case 4:
> + revision = IMX_CHIP_REVISION_1_4;
> + break;
> + case 5:
> + revision = IMX_CHIP_REVISION_1_5;
> + break;
> default:
> revision = IMX_CHIP_REVISION_UNKNOWN;
> }
> diff --git a/arch/arm/mach-imx/mxc.h b/arch/arm/mach-imx/mxc.h
> index a39b69ef4301..17a41ca65acf 100644
> --- a/arch/arm/mach-imx/mxc.h
> +++ b/arch/arm/mach-imx/mxc.h
> @@ -43,6 +43,8 @@
> #define IMX_CHIP_REVISION_1_1 0x11
> #define IMX_CHIP_REVISION_1_2 0x12
> #define IMX_CHIP_REVISION_1_3 0x13
> +#define IMX_CHIP_REVISION_1_4 0x14
> +#define IMX_CHIP_REVISION_1_5 0x15
> #define IMX_CHIP_REVISION_2_0 0x20
> #define IMX_CHIP_REVISION_2_1 0x21
> #define IMX_CHIP_REVISION_2_2 0x22
> --
> 1.9.1
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] ARM: i.MX6: add more chip revision support
From: Uwe Kleine-König @ 2014-07-21 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721063520.GR23235@pengutronix.de>
On Mon, Jul 21, 2014 at 08:35:20AM +0200, Sascha Hauer wrote:
> On Mon, Jul 21, 2014 at 01:38:11PM +0800, Shawn Guo wrote:
> > From: Jason Liu <r64343@freescale.com>
> >
> > Add more revision support for the new i.MX6DQ tap-out (TO1.5). This
Is it "tap-out" or "tape-out"? A quick google request suggests the
latter.
> > TO1.5 is the Rev 1.3 as documented in i.MX6DQ data sheet, because TO1.3
> > and TO1.4 are never revealed.
>
> So the chip identifies itself as 1.5 but the data sheet refers to it as
> 1.3. Is there a way to make that clear somewhere? Otherwise it's really
> confusing.
Yeah, from the commit log I would have expected the following patch:
+ case 5:
+ revision = IMX_CHIP_REVISION_1_3;
+ break;
maybe with a code comment. Also, the commit log only mentions i.MX6DQ; I
wonder about the other imx6 variants. I hope they use the same logic?
Best regards
Uwe
> > diff --git a/arch/arm/mach-imx/anatop.c b/arch/arm/mach-imx/anatop.c
> > index 4a40bbb46183..459ba290744b 100644
> > --- a/arch/arm/mach-imx/anatop.c
> > +++ b/arch/arm/mach-imx/anatop.c
> > @@ -104,6 +104,15 @@ void __init imx_init_revision_from_anatop(void)
> > case 2:
> > revision = IMX_CHIP_REVISION_1_2;
> > break;
> > + case 3:
> > + revision = IMX_CHIP_REVISION_1_3;
> > + break;
> > + case 4:
> > + revision = IMX_CHIP_REVISION_1_4;
> > + break;
> > + case 5:
> > + revision = IMX_CHIP_REVISION_1_5;
> > + break;
> > default:
> > revision = IMX_CHIP_REVISION_UNKNOWN;
> > }
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [GIT PULL] omap dts changes for v3.17 merge window, part1
From: Tony Lindgren @ 2014-07-21 6:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140719051552.GD20064@quad.lixom.net>
* Olof Johansson <olof@lixom.net> [140718 22:17]:
> On Wed, Jul 16, 2014 at 05:55:58AM -0700, Tony Lindgren wrote:
> > The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
> >
> > Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.17/dt-part1
> >
> > for you to fetch changes up to 3c9464ed75d6c15ee864da6d8f6a4cd3b0f2c934:
> >
> > ARM: DTS: omap5-uevm: Enable basic audio (McPDM <-> twl6040) (2014-07-15 00:21:25 -0700)
> >
> > ----------------------------------------------------------------
> > First set of .dts changes for omaps for v3.17 merge
> > window:
> >
> > - Enable irqchip crossbar interrupt mapping. These changes
> > are based on an immutable irqchip branch set up by Jason
> > Cooper to make it easier to merge the related .dts changes.
> >
> > - Removal of omap2 related static clock data that now comes
> > from device tree.
> >
> > - Enabling of PHY regulators for various omaps
> >
> > - Enabling of PCIe for dra7
> >
> > - Add support for am437x starterkit
> >
> > - Enable audio for for omap5
> >
> > - Enable display and am335x-evmsk
>
> Merged, but:
>
> 1) There was a conflict in the qspi node of dra7.dtsi due to a fix to
> remove the interrupts property. It'd be nice to get these branches
> based on the fixes so that we don't see these conflicts (or at least
> get told about them). Besides, if we happen to have an older base in
> our branch than what had the fix, it'll bubble all the way up to Linus.
>
> 2) There was an add/add conflict in the dra7.dtsi file, due to new
> entries just being appended. Please keep these sorted on address to
> avoid that.
OK thanks. This was still based on -rc1, I'll use a later base
in the future if needed to avoid pointless merge conflicts.
Regards,
Tony
^ permalink raw reply
* [v3 PATCH 2/6] dt: TI: Describe the ti reset DT entries
From: Tony Lindgren @ 2014-07-21 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405615531-15649-2-git-send-email-dmurphy@ti.com>
* Dan Murphy <dmurphy@ti.com> [140717 09:47]:
> +
> +example:
> + prm: prm at 4ae06000 {
> + compatible = "ti,omap5-prm";
> + reg = <0x4ae06000 0x3000>;
> +
> + prm_resets: resets {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #reset-cells = <1>;
> + };
> + };
Probably the way to go with mapping various PRCM registers to separate
drivers is to provide one or more syscon entries like we already have
for the SCM. You may want to coordinate this with Tero.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: i.MX6: add more chip revision support
From: Shawn Guo @ 2014-07-21 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721064145.GA7350@pengutronix.de>
On Mon, Jul 21, 2014 at 08:41:45AM +0200, Uwe Kleine-K?nig wrote:
> On Mon, Jul 21, 2014 at 08:35:20AM +0200, Sascha Hauer wrote:
> > On Mon, Jul 21, 2014 at 01:38:11PM +0800, Shawn Guo wrote:
> > > From: Jason Liu <r64343@freescale.com>
> > >
> > > Add more revision support for the new i.MX6DQ tap-out (TO1.5). This
> Is it "tap-out" or "tape-out"? A quick google request suggests the
> latter.
Yes, you're right.
>
> > > TO1.5 is the Rev 1.3 as documented in i.MX6DQ data sheet, because TO1.3
> > > and TO1.4 are never revealed.
> >
> > So the chip identifies itself as 1.5 but the data sheet refers to it as
> > 1.3. Is there a way to make that clear somewhere? Otherwise it's really
> > confusing.
> Yeah, from the commit log I would have expected the following patch:
>
> + case 5:
> + revision = IMX_CHIP_REVISION_1_3;
> + break;
>
> maybe with a code comment.
I did consider such fix-up when I was trying to submit Jason's patch
from FSL internal tree. But this TO1.5 numbering has been already used
in a couple of FSL BSP releases. We do not really want to maintain two
different numbering scheme between FSL BSP and upstream kernel.
> Also, the commit log only mentions i.MX6DQ; I
> wonder about the other imx6 variants. I hope they use the same logic?
This is another reason for that above fix-up may not be good. This
revision mismatch between register and document is only with i.MX6DQ.
So far, only i.MX6DQ revision goes beyond 1.2, but I'm sure such
mismatch/mistake will not be with other imx6 variants.
Shawn
^ permalink raw reply
* [PATCH v2] cpufreq: tests: Providing cpufreq regression test
From: Lukasz Majewski @ 2014-07-21 7:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405678985-21677-1-git-send-email-l.majewski@samsung.com>
This commit adds first regression test "cpufreq_freq_test.sh" for the
cpufreq subsystem.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
---
Changes for v2:
- Replace *_PATCH with *_PATH for variables names
- Corrected mistakes in the README file
- Providing detailed explanation of the patch in the README file
---
drivers/cpufreq/tests/README | 33 +++++++
drivers/cpufreq/tests/cpufreq_freq_test.sh | 149 +++++++++++++++++++++++++++++
2 files changed, 182 insertions(+)
create mode 100644 drivers/cpufreq/tests/README
create mode 100755 drivers/cpufreq/tests/cpufreq_freq_test.sh
diff --git a/drivers/cpufreq/tests/README b/drivers/cpufreq/tests/README
new file mode 100644
index 0000000..3e9cd80
--- /dev/null
+++ b/drivers/cpufreq/tests/README
@@ -0,0 +1,33 @@
+This file contains list of cpufreq's available regression tests with a short
+usage description.
+
+1. cpufreq_freq_test.sh
+
+Description:
+------------
+This script is supposed to test if cpufreq attributes exported by sysfs are
+exposing correct values.
+
+To achieve this goal it saves the current governor and changes it to
+"performance". Afterwards, it reads the "scaling_available_frequencies"
+property. With the list of supported frequencies it is able to enforce each of
+them by writing to "scaling_max_freq" attribute. To make the test more reliable
+a superfluous load with gzip is created to be sure that we are running with
+highest possible frequency. This high load is regulated with the 'sleep'
+duration. After this time the "cpufreq_cur_freq" is read and compared with the
+original value. As the last step the original governor is restored.
+
+This script can work with or without BOOST enabled and helps in spotting errors
+related to cpufreq and common clock framework.
+
+Used attributes:
+----------------
+- "scaling_available_frequencies"
+- "cpuinfo_cur_freq"
+- "scaling_governor"
+- "scaling_max_freq"
+
+Target devices:
+---------------
+
+All devices which exports mentioned above sysfs attributes.
\ No newline at end of file
diff --git a/drivers/cpufreq/tests/cpufreq_freq_test.sh b/drivers/cpufreq/tests/cpufreq_freq_test.sh
new file mode 100755
index 0000000..c25f05c
--- /dev/null
+++ b/drivers/cpufreq/tests/cpufreq_freq_test.sh
@@ -0,0 +1,149 @@
+#!/bin/bash
+#
+# This file provides a simple mean to test if all declared freqs at
+# "scaling_available_frequencies" can be set and if "cpuinfo_cur_freq"
+# returns this value.
+#
+# Usage: ./cpufreq_freq_test.sh
+# Requisite: Compiled in "performance" governor
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, you can access it online at
+# http://www.gnu.org/licenses/gpl-2.0.html.
+#
+# Copyright (C) Samsung Electronics, 2014
+#
+# Author: Lukasz Majewski <l.majewski@samsung.com>
+
+set +x
+
+COLOUR_RED="\33[31m"
+COLOUR_BLUE="\33[34m"
+COLOUR_GREEN="\33[32m"
+COLOUR_DEFAULT="\33[0m"
+
+T_PATH=/sys/devices/system/cpu/cpu0/cpufreq
+BOOST_PATH=/sys/devices/system/cpu/cpufreq
+
+if [ ! -d "$T_PATH" ]; then
+ printf " $COLOUR_RED No path to CPUFREQ $COLOUR_DEFAULT\n"
+ exit 1
+fi
+
+ERRORS=0
+
+OLD_GOV=`cat $T_PATH/scaling_governor`
+echo "CURRENT GOVERNOR: $OLD_GOV"
+echo "SET GOVERNOR: performance"
+echo "performance" > $T_PATH/scaling_governor
+
+function test_freqs1 {
+ FREQS=`cat $1`
+ for I in $FREQS; do
+ cpufreq_set_freq $I
+ if [ "$2" ]; then
+ printf "$COLOUR_BLUE BOOST $COLOUR_DEFAULT" $I
+ fi
+ cpufreq_test_freq $I
+ done
+}
+
+function test_freqs2 {
+ FREQ=`cat $1`
+ FREQS_ARRAY=($FREQ)
+
+ for freq in ${FREQS_ARRAY[@]}
+ do
+ echo "REFERENCE FREQ: $freq"
+ for f in ${FREQS_ARRAY[@]}
+ do
+ cpufreq_set_freq $freq
+ echo -n "----> "
+ cpufreq_set_freq $f
+ cpufreq_test_freq $f
+ done
+ done
+}
+
+function restore {
+ if [ -f $BOOST_PATH/boost ]; then
+ cpufreq_boost_state $BOOST_STATE
+ fi
+
+ echo "SET GOVERNOR: $OLD_GOV"
+ echo $OLD_GOV > $T_PATH/scaling_governor
+}
+
+function die {
+ printf " $COLOUR_RED FAILED $COLOUR_DEFAULT\n"
+ restore_gov
+ exit 1
+}
+
+function cpufreq_test_freq {
+ gzip < /dev/urandom > /dev/null &
+ pid=$!
+ sleep 0.1
+ CURR_FREQ=`cat $T_PATH/cpuinfo_cur_freq`
+ if [ $1 -eq $CURR_FREQ ]; then
+ printf "\t$COLOUR_GREEN OK $COLOUR_DEFAULT\n"
+ else
+ printf "$COLOUR_RED CURRENT $CURR_FREQ $COLOUR_DEFAULT\n"
+ ERRORS=`expr $ERRORS + 1`
+ #die
+ fi
+ kill -9 $pid
+ wait $! 2>/dev/null
+}
+
+function cpufreq_set_freq {
+ echo $1 > $T_PATH/scaling_max_freq || die $?
+ printf "FREQ:$COLOUR_GREEN %s $COLOUR_DEFAULT" $1
+}
+
+function cpufreq_boost_state {
+ echo $1 > $BOOST_PATH/boost
+}
+
+function cpufreq_boost_status {
+ cat $BOOST_PATH/boost
+}
+
+if [ -f $BOOST_PATH/boost ]; then
+ echo "######################################"
+ echo "TEST BOOST OPERATION"
+ echo "######################################"
+
+ BOOST_STATE=$(cpufreq_boost_status)
+ if [ $BOOST_STATE -eq 0 ]; then
+ cpufreq_boost_state 1
+ fi
+ test_freqs1 $T_PATH/scaling_boost_frequencies 1
+fi
+
+echo "######################################"
+echo "TEST AVAILABLE FREQS"
+echo "######################################"
+test_freqs1 $T_PATH/scaling_available_frequencies
+
+echo "######################################"
+echo "TEST FREQS SWITCHING"
+echo "######################################"
+test_freqs2 $T_PATH/scaling_available_frequencies
+
+echo "######################################"
+echo "ERRORS: $ERRORS"
+echo "######################################"
+
+restore
+exit 0
--
2.0.0.rc2
^ permalink raw reply related
* Issue found in Armada 370: "No buffer space available" error during continuous ping
From: Willy Tarreau @ 2014-07-21 7:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAB8gEUsK9c3YMpAABifNAWU7zec2ePztSqS4KAYtiT7Sbhadvg@mail.gmail.com>
Hi Maggie,
On Sun, Jul 20, 2014 at 11:33:22PM -0700, Maggie Mae Roxas wrote:
> > As you said that you both applied cd71e2 and reverted 4f3a4f, could you
> please confirm that with cd71 applied only it was not enough?
> Yes.
> If mvneta.c used is the v3.13.9 + cd71e2, issue still occurs.
> If mvneta.c used is the v3.13.9 + cd71e2 - 4f3a4f, issue does not occur anymore.
Rather strange then.
> Okay. First, I'll check if the interrupts are working by checking
> this, as you suggested:
> <snip>
> Checking /proc/interrupts when you're sending some traffic should show
> that the IRQ is increasing from time to time.
> <snip>
> I'll inform you the results within the next 2-3 days.
OK.
> We'll be using it as a router, thus, it would really be a problem for us.
OK so clearly the issue must be found.
Just thinking about something, do you have a custom boot loader ? It
would be possible that in our case, the Tx IRQ works only because some
obscure or undocumented bits are set by the boot loader and that in your
case it's not pre-initialized.
> Will check possibilities of shifting to v3.14+ with our customer -
> especially if we found problems in ethernet performance as you
> mentioned.
> Any recommendations on which version to use, specifically?
LTS would probably even interest your customer as it's an LTS version.
In this case, always pick the most recent one (3.14.12 today). You may
even be interested in 3.15.6 which contains another phy fix supposed to
fix cd71e2, but if you're saying that it doesn't change anything for you
I guess it will have no effet (might be worth testing for the purpose of
helping troubleshooting though).
> > Third, considering that other boards work without applying these changes, it might be possible that there's an issue on your board, and maybe detecting it early would allow you to fix it for all future batches, and maybe only apply these patches for the few very first ones.
> Acknowledged.
> Once we verified that indeed, the performance was slower (or
> interrupts were not increasing) - we will inform our hardware team and
> have them investigate this issue further for possible hardware bugs.
OK. I still have a hard time imagining how hardware itself could prevent
an IRQ from being delivered from a NIC which is located inside the SoC,
but there must be an explanation somewhere :-/
> Thanks a lot for the help again, I'll let you know as soon as I have more info.
Thanks,
Willy
^ permalink raw reply
* [PATCH] ARM: i.MX6: add more chip revision support
From: Shawn Guo @ 2014-07-21 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721063520.GR23235@pengutronix.de>
On Mon, Jul 21, 2014 at 08:35:20AM +0200, Sascha Hauer wrote:
> On Mon, Jul 21, 2014 at 01:38:11PM +0800, Shawn Guo wrote:
> > From: Jason Liu <r64343@freescale.com>
> >
> > Add more revision support for the new i.MX6DQ tap-out (TO1.5). This
> > TO1.5 is the Rev 1.3 as documented in i.MX6DQ data sheet, because TO1.3
> > and TO1.4 are never revealed.
>
> So the chip identifies itself as 1.5 but the data sheet refers to it as
> 1.3. Is there a way to make that clear somewhere? Otherwise it's really
> confusing.
I can add a note about that in the code, but I'm not really sure if
there is a better way to pass such info to end users. Suggestions are
welcomed.
Shawn
^ permalink raw reply
* [PATCH 12/12] ARM: tegra: Convert PMC to a driver
From: Vince Hsu @ 2014-07-21 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717110110.GI17877@ulmo>
On 07/17/2014 07:01 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Thu, Jul 17, 2014 at 12:01:56PM +0300, Peter De Schrijver wrote:
>> On Thu, Jul 17, 2014 at 10:53:08AM +0200, Peter De Schrijver wrote:
>>> On Wed, Jul 16, 2014 at 08:57:16PM +0200, Thierry Reding wrote:
>>>>> Old Signed by an unknown key
>>>> On Wed, Jul 16, 2014 at 05:22:03PM +0200, Arnd Bergmann wrote:
>>>>> On Wednesday 16 July 2014 17:14:29 Thierry Reding wrote:
>>>>>>> Ok, I'll have a look. I think when this becomes a separate driver, it
>>>>>>> should also have its own header file, so maybe you can in the meantime
>>>>>>> make it a local header file in mach-tegra until we have found a good
>>>>>>> place for it.
>>>>>> Why do you think it should be a separate header? We already have a
>>>>>> couple in include/linux and I'm not sure it's useful to add even more.
>>>>>> If anything I would've thought it made sense to move the content of the
>>>>>> other headers into tegra-soc.h.
>>>>> I very much dislike the idea of having a per-vendor header file that
>>>>> everything gets crammed into. We should try to have proper subsystems
>>>>> and generic interfaces for these wherever possible.
>>>> I completely agree. However spreading the SoC-specific functions across
>>>> multiple header files isn't going to help. If we keep all the per-vendor
>>>> APIs in one file it makes it easier to see what could still be moved off
>>>> into a separate subsystem.
>>>>
>>>> Now for PMC specifically, we've investigated converting the powergate
>>>> API to power domains. I don't think it will be possible to make that
>>>> work. The issue is that there's a defined sequence that needs to be
>>>> respected to make sure the device is powered up properly. That sequence
>>>> involves the primary clock and reset of the device. It's been proposed
>>>> to make these clocks available to the PMC driver so that it can control
>>>> them, but then we can't make sure that clocks are really off if they
>>>> need to be, since we have two drivers accessing them. The only way I see
>>> resets do not have reference counts, so they can be controlled by a
>>> powerdomain driver without any problems. For clocks, there would only be
>>> a problem for the module clocks if the drivers don't use runtime PM. If
>>> we move all drivers to runtime PM, the clock control can move into the
>>> powerdomain code and runtime PM will ensure domains are not turned off
>>> with active modules.
>>>
>>>> to make that work reliably is by moving complete control of the
>>>> powergate into drivers so that they can make sure clocks and resets are
>>>> in the correct states.
>>>>
>>> Which won't work if you have domains which contain several modules.
>> We also need to control the memory clients in the domains using
>> MC_CLIENT_HOTRESET_CTRL.
> Oh, great. More interdependencies...
Some domains depend on others. Can we take this into account?
Thanks,
Vince
^ permalink raw reply
* [PATCH v2] watchdog: imx2_wdt: add support for WDOG_B signal generation
From: Markus Niebel @ 2014-07-21 7:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721063034.GA29997@pengutronix.de>
Am 21.07.2014 08:30, wrote Uwe Kleine-K?nig:
> On Fri, Jul 18, 2014 at 01:38:30PM +0200, Markus Niebel wrote:
>> From: Markus Niebel <Markus.Niebel@tq-group.com>
>>
>> Watchdog unit of i.MX supports output of a signal at
>> watchdog shutdown. This feature can be useful to signal an
>> external supevisor that a watchdog reset occured.
> supervisor
>
>> Support this feature as an option via devicetree.
>>
>> Signed-off-by: Markus Niebel <Markus.Niebel@tq-group.com>
>> ---
>> History
>>
>> v2:
>> Fix incorrect sent patch
>> - add include of.h
>> - fix missing if in probe
>>
>> .../devicetree/bindings/watchdog/fsl-imx-wdt.txt | 3 +++
>> drivers/watchdog/imx2_wdt.c | 11 +++++++++--
>> 2 files changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
>> index 2144af1..cb759cd 100644
>> --- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
>> +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
>> @@ -5,6 +5,9 @@ Required properties:
>> - reg : Should contain WDT registers location and length
>> - interrupts : Should contain WDT interrupt
>>
>> +Optional properties:
>> +- fsl,use-wre: set if watchdog reset out (WDOG_B) signal shall be asserted
>> +
>> Examples:
>>
>> wdt at 73f98000 {
>> diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
>> index 9d4874f..bde96db 100644
>> --- a/drivers/watchdog/imx2_wdt.c
>> +++ b/drivers/watchdog/imx2_wdt.c
#include linux/of.h is missing here ...
>> @@ -58,6 +58,7 @@ struct imx2_wdt_device {
>> struct regmap *regmap;
>> struct timer_list timer; /* Pings the watchdog when closed */
>> struct watchdog_device wdog;
>> + unsigned int use_wre:1; /* enable WRE feature */
>> };
>>
>> static bool nowayout = WATCHDOG_NOWAYOUT;
>> @@ -88,7 +89,10 @@ static inline void imx2_wdt_setup(struct watchdog_device *wdog)
>> /* Strip the old watchdog Time-Out value */
>> val &= ~IMX2_WDT_WCR_WT;
>> /* Generate reset if WDOG times out */
>> - val &= ~IMX2_WDT_WCR_WRE;
>> + if (wdev->use_wre)
>> + val |= IMX2_WDT_WCR_WRE;
>> + else
>> + val &= ~IMX2_WDT_WCR_WRE;
>> /* Keep Watchdog Disabled */
>> val &= ~IMX2_WDT_WCR_WDE;
>> /* Set the watchdog's Time-Out value */
>> @@ -219,6 +223,9 @@ static int __init imx2_wdt_probe(struct platform_device *pdev)
>> return PTR_ERR(wdev->clk);
>> }
>>
>> + if (of_property_read_bool(pdev->dev.of_node, "fsl,use-wre"))
>> + wdev->use_wre = 1;
>> +
>> wdog = &wdev->wdog;
>> wdog->info = &imx2_wdt_info;
>> wdog->ops = &imx2_wdt_ops;
>> @@ -226,7 +233,7 @@ static int __init imx2_wdt_probe(struct platform_device *pdev)
>> wdog->max_timeout = IMX2_WDT_MAX_TIME;
>>
>> clk_prepare_enable(wdev->clk);
>> -
>> +
> Don't add a space here.
Oops
>
> Did you check that this feature works on all cpus that use this driver?
> On which of them did you test your change?
>
We tested with i.MX6Q and i.MX6DL. Reading the RM at least i.MX25, i.MX35 and i.MX53
should implement the same behaviour. But you are right - the i.MX21 is slighly different.
Will prepare v3 after my holiday with
- work out SOC differences
- add missing include
- extended binding docu
- fix whitespace error
> Best regards
> Uwe
>
Best Regards
Markus
^ permalink raw reply
* [PATCH 0/9] usb: musb: several bugfixes for the musb driver
From: Lothar Waßmann @ 2014-07-21 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718165044.GA30821@saruman.home>
Hi,
Felipe Balbi wrote:
> Hi,
>
> On Fri, Jul 18, 2014 at 01:16:36PM -0300, Ezequiel Garcia wrote:
> > Hi Lothar,
> >
> > On 18 Jul 11:31 AM, Lothar Wa?mann wrote:
> > > The first three patches do some source code cleanup in the files that
> > > are modified in the subsequent patches.
> > >
> >
> > I've applied patches 4 and 9 on a recent -next, after fixing a conflict
> > due to patch 3 ("usb: musb_am335x: source cleanup"):
> >
> > > Patch 4 carries the proper fix reported in commit:
> > > 7adb5c876e9c ("usb: musb: Fix panic upon musb_am335x module removal")
> > >
> > > Patch 9 reinstates module unloading support for the musb_am335x driver
> > > which was disabled due to a false failure analysis
> > >
> >
> > For these two patches, Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
> >
> > Tested on a beaglebone with a mass storage USB device, module load/unload
> > works without issues. The module_get/put in the phy is now preventing the
> > musb_am335x driver unload, which seems to be the real cause of the issue
> > I reported. Thanks for providing a proper fix!
>
> I don't that's a good fix. The problem is that even after am335x
> removing all its child, someone else tried to release the PHY. That
> ordering is the one that needs to be fixed. Doing a module_get on the
> parent device looks like a hack to me.
>
No. It guarantees that the module cannot be unloaded when its resources
are still in use!
Lothar Wa?mann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
^ permalink raw reply
* [PATCHv7 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean
From: Arnd Bergmann @ 2014-07-21 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405909068-22539-1-git-send-email-cw00.choi@samsung.com>
On Monday 21 July 2014 11:17:44 Chanwoo Choi wrote:
>
> This patchset support Exynos3250 ADC (Analog Digital Converter) because
> Exynos3250 has additional special clock for ADC IP.
>
> Changes from v6:
> - Use "exynos3250-adc" compatible string instead of "exynos3250-adc-v2"
> - Use "sclk" clock name instead of "sclk_adc"
> - Remove un-necessary macro for exyno-adc-data-v2 structure.
> - Remove '(void *)' cast and mark the exynos-adc-data structure as 'const'
> - Change the number of ADC channels (Exynos3250 has only two channels for ADC)
>
Looks good to me. Two small requests:
a) if you don't mind, can you add my patch (1/2) to add support for s3c64xx to
your series, adding your Signed-off-by line in addition to mine? I think
that one was noncontroversial, while the second patch (2/2) need some more
work to address the comments and do testing.
b) For the "compatible" string, I think it makes sense to set a fallback to
"samsung,exynos-adc-v2" in the case for exynos3250, making the DT
representation
compatible = "samsung,exynos3250-adc", "samsung,exynos-adc-v2";
It's not entirely compatible because of the addition of the clock, but
since the register layout is the same, I think it still make sense.
Thanks.
For the entire series,
Acked-by: Arnd Bergmann <arnd@arndb.de>
Arnd
^ permalink raw reply
* [PATCH 0/6] of-thermal hardware trip points + Tegra124 SOCTHERM driver
From: Zhang Rui @ 2014-07-21 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1403856699-2140-1-git-send-email-mperttunen@nvidia.com>
Hi, Eduardo,
what do you think of this patch set?
thanks,
rui
On Fri, 2014-06-27 at 11:11 +0300, Mikko Perttunen wrote:
> Hi everyone,
>
> this series adds support for hardware-tracked thermal trip points
> for the device tree thermal framework and introduces a new Tegra124 thermal
> driver that uses them.
>
> Hardware-tracked trip points are trip points that do not need to be polled;
> the hardware gives an interrupt when the trip point is reached. The device
> tree thermal framework has not previously given the sensor driver any
> information about set trip points, so using these has been impossible.
> This series adds a new callback from of-thermal to the driver to allow telling
> the driver about trip points. The driver only needs to track two trip points,
> the framework ensures that the current temperature lies between those two.
> Behavior for drivers that do not include this callback is unchanged.
>
> The Tegra124 SOCTHERM thermal driver that is included exposes four thermal zones
> (the thermctl thermal zones) with hardware-tracked trip point support. While the
> hardware supports four tracked trip points, only one is used.
>
> Mikko Perttunen (6):
> thermal: of: Add support for hardware-tracked trip points
> of: Add bindings for nvidia,tegra124-soctherm
> ARM: tegra: Add thermal trip points for Jetson TK1
> ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree
> clk: tegra: Add soctherm and tsensor clocks to Tegra124 init table
> thermal: Add Tegra SOCTHERM thermal management driver
>
> .../devicetree/bindings/thermal/tegra-soctherm.txt | 32 ++
> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 32 ++
> arch/arm/boot/dts/tegra124.dtsi | 48 ++
> drivers/clk/tegra/clk-tegra124.c | 2 +
> drivers/thermal/Kconfig | 7 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/of-thermal.c | 97 +++-
> drivers/thermal/tegra_soctherm.c | 553 +++++++++++++++++++++
> include/dt-bindings/thermal/tegra124-soctherm.h | 15 +
> include/linux/thermal.h | 3 +-
> 10 files changed, 785 insertions(+), 5 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/thermal/tegra-soctherm.txt
> create mode 100644 drivers/thermal/tegra_soctherm.c
> create mode 100644 include/dt-bindings/thermal/tegra124-soctherm.h
>
^ permalink raw reply
* [PATCH 0/3] Enable SCU standby support at core level
From: Shawn Guo @ 2014-07-21 7:45 UTC (permalink / raw)
To: linux-arm-kernel
With SCU standby support, SCU CLK will be turned off when all processors
are in WFI mode. And the clock will be turned on when any processor
leaves WFI mode. This behavior should be preferable in terms of power
efficiency of system idle.
The patch series enables SCU standby support in SCU core function
scu_enable(), and then clean up the SCU standby enabling code at i.MX
platform level.
Shawn Guo (3):
ARM: smp_scu: use macro for SCU enable bit
ARM: smp_scu: enable SCU standby support
ARM: imx: remove SCU standby enable code
arch/arm/kernel/smp_scu.c | 6 ++++--
arch/arm/mach-imx/common.h | 2 --
arch/arm/mach-imx/cpuidle-imx6q.c | 4 ----
arch/arm/mach-imx/platsmp.c | 10 ----------
4 files changed, 4 insertions(+), 18 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/3] ARM: smp_scu: use macro for SCU enable bit
From: Shawn Guo @ 2014-07-21 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405928755-19413-1-git-send-email-shawn.guo@freescale.com>
Use macro instead of magic number for SCU enable bit.
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
---
arch/arm/kernel/smp_scu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
index 1aafa0d785eb..c947508f84e6 100644
--- a/arch/arm/kernel/smp_scu.c
+++ b/arch/arm/kernel/smp_scu.c
@@ -17,6 +17,7 @@
#include <asm/cputype.h>
#define SCU_CTRL 0x00
+#define SCU_ENABLE (1 << 0)
#define SCU_CONFIG 0x04
#define SCU_CPU_STATUS 0x08
#define SCU_INVALIDATE 0x0c
@@ -50,10 +51,10 @@ void scu_enable(void __iomem *scu_base)
scu_ctrl = readl_relaxed(scu_base + SCU_CTRL);
/* already enabled? */
- if (scu_ctrl & 1)
+ if (scu_ctrl & SCU_ENABLE)
return;
- scu_ctrl |= 1;
+ scu_ctrl |= SCU_ENABLE;
writel_relaxed(scu_ctrl, scu_base + SCU_CTRL);
/*
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] ARM: smp_scu: enable SCU standby support
From: Shawn Guo @ 2014-07-21 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405928755-19413-1-git-send-email-shawn.guo@freescale.com>
With SCU standby enabled, SCU CLK will be turned off when all processors
are in WFI mode. And the clock will be turned on when any processor
leaves WFI mode.
This behavior should be preferable in terms of power efficiency of
system idle. So let's set the SCU standby bit to enable the support in
function scu_enable().
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
---
arch/arm/kernel/smp_scu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
index c947508f84e6..9f29d167d02c 100644
--- a/arch/arm/kernel/smp_scu.c
+++ b/arch/arm/kernel/smp_scu.c
@@ -18,6 +18,7 @@
#define SCU_CTRL 0x00
#define SCU_ENABLE (1 << 0)
+#define SCU_STANDBY_ENABLE (1 << 5)
#define SCU_CONFIG 0x04
#define SCU_CPU_STATUS 0x08
#define SCU_INVALIDATE 0x0c
@@ -54,7 +55,7 @@ void scu_enable(void __iomem *scu_base)
if (scu_ctrl & SCU_ENABLE)
return;
- scu_ctrl |= SCU_ENABLE;
+ scu_ctrl |= SCU_ENABLE | SCU_STANDBY_ENABLE;
writel_relaxed(scu_ctrl, scu_base + SCU_CTRL);
/*
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] ARM: imx: remove SCU standby enable code
From: Shawn Guo @ 2014-07-21 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405928755-19413-1-git-send-email-shawn.guo@freescale.com>
Since we have scu_enable() enables SCU standby support at SCU core
level, the code enabling SCU standby at i.MX platform level can be
removed now.
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
---
arch/arm/mach-imx/common.h | 2 --
arch/arm/mach-imx/cpuidle-imx6q.c | 4 ----
arch/arm/mach-imx/platsmp.c | 10 ----------
3 files changed, 16 deletions(-)
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index 22ba8973bcb9..1dabf435c592 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -98,11 +98,9 @@ void imx_set_cpu_arg(int cpu, u32 arg);
void v7_secondary_startup(void);
void imx_scu_map_io(void);
void imx_smp_prepare(void);
-void imx_scu_standby_enable(void);
#else
static inline void imx_scu_map_io(void) {}
static inline void imx_smp_prepare(void) {}
-static inline void imx_scu_standby_enable(void) {}
#endif
void imx_src_init(void);
void imx_gpc_init(void);
diff --git a/arch/arm/mach-imx/cpuidle-imx6q.c b/arch/arm/mach-imx/cpuidle-imx6q.c
index 10844d3bb926..aa935787b743 100644
--- a/arch/arm/mach-imx/cpuidle-imx6q.c
+++ b/arch/arm/mach-imx/cpuidle-imx6q.c
@@ -66,10 +66,6 @@ static struct cpuidle_driver imx6q_cpuidle_driver = {
int __init imx6q_cpuidle_init(void)
{
- /* Need to enable SCU standby for entering WAIT modes */
- if (!cpu_is_imx6sx())
- imx_scu_standby_enable();
-
/* Set INT_MEM_CLK_LPM bit to get a reliable WAIT mode support */
imx6q_set_int_mem_clk_lpm(true);
diff --git a/arch/arm/mach-imx/platsmp.c b/arch/arm/mach-imx/platsmp.c
index 5b57c17c06bd..771bd25c1025 100644
--- a/arch/arm/mach-imx/platsmp.c
+++ b/arch/arm/mach-imx/platsmp.c
@@ -20,8 +20,6 @@
#include "common.h"
#include "hardware.h"
-#define SCU_STANDBY_ENABLE (1 << 5)
-
u32 g_diag_reg;
static void __iomem *scu_base;
@@ -45,14 +43,6 @@ void __init imx_scu_map_io(void)
scu_base = IMX_IO_ADDRESS(base);
}
-void imx_scu_standby_enable(void)
-{
- u32 val = readl_relaxed(scu_base);
-
- val |= SCU_STANDBY_ENABLE;
- writel_relaxed(val, scu_base);
-}
-
static int imx_boot_secondary(unsigned int cpu, struct task_struct *idle)
{
imx_set_cpu_jump(cpu, v7_secondary_startup);
--
1.9.1
^ permalink raw reply related
* [PATCH v2 4/4] mfd: pm8921: rename pm8921-core driver
From: Lee Jones @ 2014-07-21 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABu_nUQDWbejZcQqFSJMhCokeMJXBcsCpsiJxz4gBsmtKiyivA@mail.gmail.com>
On Fri, 18 Jul 2014, Prakash Burla wrote:
> On Thu, Jul 17, 2014 at 9:47 PM, Stanimir Varbanov <svarbanov@mm-sol.com> wrote:
> > The pm8921-core driver presently supports pm8921 and pm8058
> > Qualcomm PMICs. To avoid confusion with new generation PMICs
> > (like pm8941) rename the pm8921-core driver to more
> > appropriate name pm8xxx-ssbi, which reflects better that
> > those chips use SSBI interface.
> >
> > Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com>
> > ---
> > drivers/mfd/Kconfig | 14 +++++-----
> > drivers/mfd/Makefile | 2 +-
> > drivers/mfd/{pm8921-core.c => pm8xxx-ssbi.c} | 38 +++++++++++++-------------
> > 3 files changed, 27 insertions(+), 27 deletions(-)
> > rename drivers/mfd/{pm8921-core.c => pm8xxx-ssbi.c} (92%)
> .
> [Nope]
What does this mean?
> > MODULE_LICENSE("GPL v2");
> > -MODULE_DESCRIPTION("PMIC 8921 core driver");
> > +MODULE_DESCRIPTION("PMIC PM8XXX SSBI driver");
> > MODULE_VERSION("1.0");
> > -MODULE_ALIAS("platform:pm8921-core");
> > +MODULE_ALIAS("platform:pm8xxx-ssbi");
> >How about adding the module author as svarbanov at mm-sol.com/qcom?
> MODULE_AUTHOR("SVARBANOV<svarbanov@mm-sol.com>");
Module author has the same standards as Git author.
MODULE_AUTHOR("Stanimir Varbanov <svarbanov@mm-sol.com>");
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [GIT PULL] ARM: OMAP2+: clock cleanup for 3.17
From: Tony Lindgren @ 2014-07-21 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1407171817440.22427@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [140717 11:20]:
> Hi Tony,
>
> The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee:
>
> Linux 3.16-rc2 (2014-06-21 19:02:54 -1000)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.17/omap-clock-a
>
> for you to fetch changes up to acd052bb8119dd9117e0af48ff0ac6e56e61b6b4:
>
> ARM: OMAP2+: clock/interface: remove some headers from clkt_iclk.c file (2014-07-15 14:09:24 -0600)
>
> ----------------------------------------------------------------
> An OMAP clock cleanup series for 3.17 from Tero Kristo.
> This is in preparation for moving this code into drivers/clk/ti.
>
> Basic build, boot, and PM test logs are here:
>
> http://www.pwsan.com/omap/testlogs/clock-a-v3.17/20140717034329/
Thanks pulling into omap-for-v3.17/soc.
Regards,
Tony
^ 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