* dma_alloc_coherent fails in framebuffer
From: Tony Prisk @ 2012-10-16 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016075835.GF29125@suse.de>
On Tue, 2012-10-16 at 08:58 +0100, Mel Gorman wrote:
> On Tue, Oct 16, 2012 at 07:50:07PM +1300, Tony Prisk wrote:
> > > > > Why it caused a problem on that particular commit I don't know - but it
> > > > > was reproducible by adding/removing it.
> > > > >
> > >
> > > I finally found the link to this patch which caused the problem - and
> > > may still be the cause of my problems :)
> > >
>
> Blast, thanks. This was already identified as being a problem and "fixed"
> in https://lkml.org/lkml/2012/10/5/164 but I missed that the fix did not
> get picked up before RC1 after all the patches got collapsed together. I'm
> very sorry about that, I should have spotted that it didn't make it through.
>
> > Any suggestions on how to fix this?
> >
>
> Can you test this to be sure and if it's fine I'll push it to Andrew.
>
> ---8<---
> mm: compaction: Correct the strict_isolated check for CMA
>
> Thierry reported that the "iron out" patch for isolate_freepages_block()
> had problems due to the strict check being too strict with "mm: compaction:
> Iron out isolate_freepages_block() and isolate_freepages_range() -fix1".
> It's possible that more pages than necessary are isolated but the check
> still fails and I missed that this fix was not picked up before RC1. This
> has also been identified in RC1 by Tony Prisk and should be addressed by
> the following patch.
>
> Signed-off-by: Mel Gorman <mgorman@suse.de>
> ---
> compaction.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 2c4ce17..9eef558 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -346,7 +346,7 @@ static unsigned long isolate_freepages_block(struct compact_control *cc,
> * pages requested were isolated. If there were any failures, 0 is
> * returned and CMA will fail.
> */
> - if (strict && nr_strict_required != total_isolated)
> + if (strict && nr_strict_required > total_isolated)
> total_isolated = 0;
>
> if (locked)
I don't need to test that again.. thats exactly what I did to fix it
myself :)
Tested-by: Tony Prisk <linux@prisktech.co.nz>
.. if needed.
Nice to know I'm not completely bonkers.
Thanks for your help
Tony P
^ permalink raw reply
* [PATCH 2/2] ASoC: atmel-ssc: use module_platform_driver macro
From: Nicolas Ferre @ 2012-10-16 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350359819-2461-2-git-send-email-voice.shen@atmel.com>
On 10/16/2012 05:56 AM, Bo Shen :
> This patch removes some code duplication by using module_platform_driver
>
> Signed-off-by: Bo Shen <voice.shen@atmel.com>
Very good simplification but...
> ---
> drivers/misc/atmel-ssc.c | 18 ++++--------------
> 1 file changed, 4 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
> index 23dcb76..ac00f83 100644
> --- a/drivers/misc/atmel-ssc.c
> +++ b/drivers/misc/atmel-ssc.c
> @@ -68,7 +68,7 @@ void ssc_free(struct ssc_device *ssc)
> }
> EXPORT_SYMBOL(ssc_free);
>
> -static int __init ssc_probe(struct platform_device *pdev)
> +static int ssc_probe(struct platform_device *pdev)
Here you remove the __init altogether, maybe converting to __devinit is
the proper replacement for this? I do not know myself but if anybody knows?
Bye,
> {
> struct resource *regs;
> struct ssc_device *ssc;
> @@ -135,24 +135,14 @@ static int __devexit ssc_remove(struct platform_device *pdev)
> }
>
> static struct platform_driver ssc_driver = {
> - .remove = __devexit_p(ssc_remove),
> .driver = {
> .name = "ssc",
> .owner = THIS_MODULE,
> },
> + .probe = ssc_probe,
> + .remove = __devexit_p(ssc_remove),
> };
> -
> -static int __init ssc_init(void)
> -{
> - return platform_driver_probe(&ssc_driver, ssc_probe);
> -}
> -module_init(ssc_init);
> -
> -static void __exit ssc_exit(void)
> -{
> - platform_driver_unregister(&ssc_driver);
> -}
> -module_exit(ssc_exit);
> +module_platform_driver(ssc_driver);
>
> MODULE_AUTHOR("Hans-Christian Egtvedt <hcegtvedt@atmel.com>");
> MODULE_DESCRIPTION("SSC driver for Atmel AVR32 and AT91");
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 7/7] ARM: tegra30: cpuidle: add LP2 driver for CPU0
From: Peter De Schrijver @ 2012-10-16 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507C32E8.1040701@wwwdotorg.org>
> > Even though we have plan to use coupled cpuidle, I still prefer to go
> > with the LP2 driver first. Then adding one more patch to support coupled
> > cpuidle based on LP2 driver. This is good for history. And if there is
> > any issue, it's more easy to roll back to the stable one.
>
> I don't think that implementing it one way and then changing to a
> different way will benefit history at all. It'll make the history more
> complicated. What exactly is the problem with just using coupled cpuidle
> from the start? If we did merge this implementation now, then switch to
> coupled cpuidle later, when do you think the switch would happen?
>
Before we consider doing this, I think we should have some idea on how
frequently we run into the situation where CPU0 is idle but a secondary
core is not. Depending on that we can then decide how useful coupled cpuidle
would be for us.
Cheers,
Peter.
^ permalink raw reply
* [PATCH 1/2] ASoC: atmel-ssc: use devm_xxx() managed function
From: Nicolas Ferre @ 2012-10-16 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350359819-2461-1-git-send-email-voice.shen@atmel.com>
On 10/16/2012 05:56 AM, Bo Shen :
> Using the devm_xxx() managed function to stripdown the error
> and remove code.
>
> Signed-off-by: Bo Shen <voice.shen@atmel.com>
Maybe too late, but:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/misc/atmel-ssc.c | 47 +++++++++++++++-------------------------------
> 1 file changed, 15 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
> index 5bb1877..23dcb76 100644
> --- a/drivers/misc/atmel-ssc.c
> +++ b/drivers/misc/atmel-ssc.c
> @@ -70,37 +70,33 @@ EXPORT_SYMBOL(ssc_free);
>
> static int __init ssc_probe(struct platform_device *pdev)
> {
> - int retval = 0;
> struct resource *regs;
> struct ssc_device *ssc;
>
> - ssc = kzalloc(sizeof(struct ssc_device), GFP_KERNEL);
> + ssc = devm_kzalloc(&pdev->dev, sizeof(struct ssc_device), GFP_KERNEL);
> if (!ssc) {
> dev_dbg(&pdev->dev, "out of memory\n");
> - retval = -ENOMEM;
> - goto out;
> + return -ENOMEM;
> }
>
> + ssc->pdev = pdev;
> +
> regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!regs) {
> dev_dbg(&pdev->dev, "no mmio resource defined\n");
> - retval = -ENXIO;
> - goto out_free;
> + return -ENXIO;
> }
>
> - ssc->clk = clk_get(&pdev->dev, "pclk");
> - if (IS_ERR(ssc->clk)) {
> - dev_dbg(&pdev->dev, "no pclk clock defined\n");
> - retval = -ENXIO;
> - goto out_free;
> - }
> -
> - ssc->pdev = pdev;
> - ssc->regs = ioremap(regs->start, resource_size(regs));
> + ssc->regs = devm_request_and_ioremap(&pdev->dev, regs);
> if (!ssc->regs) {
> dev_dbg(&pdev->dev, "ioremap failed\n");
> - retval = -EINVAL;
> - goto out_clk;
> + return -EINVAL;
> + }
> +
> + ssc->clk = devm_clk_get(&pdev->dev, "pclk");
> + if (IS_ERR(ssc->clk)) {
> + dev_dbg(&pdev->dev, "no pclk clock defined\n");
> + return -ENXIO;
> }
>
> /* disable all interrupts */
> @@ -112,8 +108,7 @@ static int __init ssc_probe(struct platform_device *pdev)
> ssc->irq = platform_get_irq(pdev, 0);
> if (!ssc->irq) {
> dev_dbg(&pdev->dev, "could not get irq\n");
> - retval = -ENXIO;
> - goto out_unmap;
> + return -ENXIO;
> }
>
> spin_lock(&user_lock);
> @@ -125,16 +120,7 @@ static int __init ssc_probe(struct platform_device *pdev)
> dev_info(&pdev->dev, "Atmel SSC device at 0x%p (irq %d)\n",
> ssc->regs, ssc->irq);
>
> - goto out;
> -
> -out_unmap:
> - iounmap(ssc->regs);
> -out_clk:
> - clk_put(ssc->clk);
> -out_free:
> - kfree(ssc);
> -out:
> - return retval;
> + return 0;
> }
>
> static int __devexit ssc_remove(struct platform_device *pdev)
> @@ -142,10 +128,7 @@ static int __devexit ssc_remove(struct platform_device *pdev)
> struct ssc_device *ssc = platform_get_drvdata(pdev);
>
> spin_lock(&user_lock);
> - iounmap(ssc->regs);
> - clk_put(ssc->clk);
> list_del(&ssc->list);
> - kfree(ssc);
> spin_unlock(&user_lock);
>
> return 0;
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 1/1] Documentation: Describe Device Tree bindings for GPIO Regulator driver
From: Lee Jones @ 2012-10-16 8:02 UTC (permalink / raw)
To: linux-arm-kernel
Here we specify all non-standard bindings which can be used when
requesting the use of an GPIO controlled regulator from Device Tree.
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
.../bindings/regulator/gpio-regulator.txt | 36 ++++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/gpio-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
new file mode 100644
index 0000000..3703be2
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
@@ -0,0 +1,36 @@
+GPIO controlled regulators
+
+Required properties:
+- compatible : Must be "regulator-gpio".
+
+Optional properties:
+- gpio-enable : GPIO to use to enable/disable the regulator.
+- gpios : GPIO group used to control voltage.
+- states : Selection of available voltages and GPIO configs.
+- startup-delay-us : Startup time in microseconds.
+- enable-active-high : Polarity of GPIO is active high (default is low).
+
+Any property defined as part of the core regulator binding defined in
+regulator.txt can also be used.
+
+Example:
+
+ mmciv: gpio-regulator {
+ compatible = "regulator-gpio";
+
+ regulator-name = "mmci-gpio-supply";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2600000>;
+ regulator-boot-on;
+
+ gpio-enable = <&gpio0 23 0x4>;
+ gpios = <&gpio0 24 0x4
+ &gpio0 25 0x4>;
+ states = <1800000 0x3
+ 2200000 0x2
+ 2600000 0x1
+ 2900000 0x0>;
+
+ startup-delay-us = <100000>;
+ enable-active-high;
+ };
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] regulator: gpio-regulator: Allow use of GPIO controlled regulators though DT
From: Lee Jones @ 2012-10-16 8:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016074643.GA10323@opensource.wolfsonmicro.com>
On Tue, 16 Oct 2012, Mark Brown wrote:
> On Tue, Oct 16, 2012 at 08:29:56AM +0100, Lee Jones wrote:
> > On Tue, 16 Oct 2012, Mark Brown wrote:
>
> > > Not looked at the patch yet but patch 2 doesn't seem to have appeared?
>
> > Has it arrived yet?
>
> > Arnd responded to it, so it hit the list.
>
> > Since Arnd's comments I've also fired v2 up - do you see it/them?
>
> Not in my inbox, I'm not looking at the list right now.
Strange, both emails had you in CC.
I'm assuming it's just the documentation patch you're missing.
Let me resend it as a single patch.
^ permalink raw reply
* dma_alloc_coherent fails in framebuffer
From: Mel Gorman @ 2012-10-16 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350370207.26424.13.camel@gitbox>
On Tue, Oct 16, 2012 at 07:50:07PM +1300, Tony Prisk wrote:
> > > > Why it caused a problem on that particular commit I don't know - but it
> > > > was reproducible by adding/removing it.
> > > >
> >
> > I finally found the link to this patch which caused the problem - and
> > may still be the cause of my problems :)
> >
Blast, thanks. This was already identified as being a problem and "fixed"
in https://lkml.org/lkml/2012/10/5/164 but I missed that the fix did not
get picked up before RC1 after all the patches got collapsed together. I'm
very sorry about that, I should have spotted that it didn't make it through.
> Any suggestions on how to fix this?
>
Can you test this to be sure and if it's fine I'll push it to Andrew.
---8<---
mm: compaction: Correct the strict_isolated check for CMA
Thierry reported that the "iron out" patch for isolate_freepages_block()
had problems due to the strict check being too strict with "mm: compaction:
Iron out isolate_freepages_block() and isolate_freepages_range() -fix1".
It's possible that more pages than necessary are isolated but the check
still fails and I missed that this fix was not picked up before RC1. This
has also been identified in RC1 by Tony Prisk and should be addressed by
the following patch.
Signed-off-by: Mel Gorman <mgorman@suse.de>
---
compaction.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 2c4ce17..9eef558 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -346,7 +346,7 @@ static unsigned long isolate_freepages_block(struct compact_control *cc,
* pages requested were isolated. If there were any failures, 0 is
* returned and CMA will fail.
*/
- if (strict && nr_strict_required != total_isolated)
+ if (strict && nr_strict_required > total_isolated)
total_isolated = 0;
if (locked)
^ permalink raw reply related
* [PATCH 1/2] regulator: gpio-regulator: Allow use of GPIO controlled regulators though DT
From: Mark Brown @ 2012-10-16 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016072956.GF7662@gmail.com>
On Tue, Oct 16, 2012 at 08:29:56AM +0100, Lee Jones wrote:
> On Tue, 16 Oct 2012, Mark Brown wrote:
> > Not looked at the patch yet but patch 2 doesn't seem to have appeared?
> Has it arrived yet?
> Arnd responded to it, so it hit the list.
> Since Arnd's comments I've also fired v2 up - do you see it/them?
Not in my inbox, I'm not looking at the list right now.
^ permalink raw reply
* [PATCH] Boottime: A tool for automatic measurement of kernel/bootloader boot time
From: Lee Jones @ 2012-10-16 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507C3125.70702@ti.com>
> >>>>>>root at ME:/ cat /sys/kernel/debug/boottime/bootgraph
> >>>>>>[ 0.185254] calling splash+0x0/0x0
> >>>>>>[ 2.984335] initcall splash+0x0/0x0 returned 0 after 2799 msecs.
> >>>>>>[ 2.984335] calling autoboot_delay+0x0/0x0
> >>>>>>[ 4.089513] initcall autoboot_delay+0x0/0x0 returned 0 after 1105 msecs.
> >>>>>>[ 4.089513] calling load_kernel+0x0/0x0
> >>>>>>[ 4.239174] initcall load_kernel+0x0/0x0 returned 0 after 149 msecs.
> >>>>>>[ 4.239174] calling boot_kernel+0x0/0x0
> >>>>>>[ 4.276260] initcall boot_kernel+0x0/0x0 returned 0 after 37 msecs.
> >>>>>>[ 4.276260] calling uncompress_ll_init+0x0/0x0
> >>>>>>[ 4.276260] initcall uncompress_ll_init+0x0/0x0 returned 0 after 0 msecs.
> >>>>>>[ 4.276260] Freeing init memory: 0K
> >commit 4c49a18bcfd2d041cbad7f41c6e6b39d90008382 (HEAD, refs/heads/dt-snowball-pre-rc1)
> >Author: Jonas Aaberg<jonas.aberg@stericsson.com>
> >Date: Wed Sep 14 09:29:20 2011 +0200
> >
> > drivers: clocksource: dbx500-prcmu: Add boottime support
> >
> > Change-Id: I9b5e3d050131c08c08786ae84cb76619c0525049
> > Signed-off-by: Jonas Aaberg<jonas.aberg@stericsson.com>
> > Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/32055
> >
> >diff --git a/drivers/clocksource/clksrc-dbx500-prcmu.c b/drivers/clocksource/clksrc-dbx500-prcmu.c
> >index c26c369..0069cd9 100644
> >--- a/drivers/clocksource/clksrc-dbx500-prcmu.c
> >+++ b/drivers/clocksource/clksrc-dbx500-prcmu.c
> >@@ -14,6 +14,7 @@
> > */
> > #include<linux/clockchips.h>
> > #include<linux/clksrc-dbx500-prcmu.h>
> >+#include<linux/boottime.h>
> >
> > #include<asm/sched_clock.h>
> >
> >@@ -68,6 +69,23 @@ static u32 notrace dbx500_prcmu_sched_clock_read(void)
> >
> > #endif
> >
> >+#ifdef CONFIG_BOOTTIME
> >+static unsigned long __init boottime_get_time(void)
> >+{
> >+ return div_s64(clocksource_cyc2ns(clocksource_dbx500_prcmu.read(
> >+ &clocksource_dbx500_prcmu),
> >+ clocksource_dbx500_prcmu.mult,
> >+ clocksource_dbx500_prcmu.shift),
> >+ 1000);
> >+}
> >+
> >+static struct boottime_timer __initdata boottime_timer = {
> >+ .init = NULL,
> >+ .get_time = boottime_get_time,
> >+ .finalize = NULL,
> >+};
> >+#endif
> >+
> > void __init clksrc_dbx500_prcmu_init(void __iomem *base)
> > {
> > clksrc_dbx500_timer_base = base;
> >@@ -90,4 +108,6 @@ void __init clksrc_dbx500_prcmu_init(void __iomem *base)
> > 32, RATE_32K);
> > #endif
> > clocksource_register_hz(&clocksource_dbx500_prcmu, RATE_32K);
> >+
> >+ boottime_activate(&boottime_timer);
> > }
> >
>
> OK So has this been validated and tested on any other IC then a ST part?
> This boottime_activate patch seems to be only for the dbx500. If
> this is supposed to be a generic solution I would expect
> a generic patch for ARM to enable boot time activation.
No, this is essentially an STE patch. We don't have access to any other
hardware, so we'd be reliant on kindhearted soles to test on their h/w.
I guess something like Beagleboard and/or Panda would be ideal. Know
anyone? ;)
> Have you profiled how much time the boot time logging has added to
> the over all boot?
> Also the boottime commit message should explain a little more what
> it is measuring.
> i.e. This patch enables logging the boot time from point x to point
> y for the kernel only. This does not include init.
>
> What about adding the boot time from the init sequence to init complete?
I don't know the answers to these questions, but I'll endeavour to find
out and get back to you posthaste.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 1/2] regulator: gpio-regulator: Allow use of GPIO controlled regulators though DT
From: Lee Jones @ 2012-10-16 7:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016051401.GB8670@opensource.wolfsonmicro.com>
On Tue, 16 Oct 2012, Mark Brown wrote:
> On Mon, Oct 15, 2012 at 02:16:59PM +0100, Lee Jones wrote:
> > Here we provide the GPIO Regulator driver with Device Tree capability, so
> > that when a platform is booting with DT instead of platform data we can
> > still make full use of it.
>
> Not looked at the patch yet but patch 2 doesn't seem to have appeared?
Has it arrived yet?
Arnd responded to it, so it hit the list.
Since Arnd's comments I've also fired v2 up - do you see it/them?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCHv4 8/8] ARM: OMAP3: do not delete per_clkdm autodeps during idle
From: Paul Walmsley @ 2012-10-16 7:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87k3vpek28.fsf@deeprootsystems.com>
Hi Kevin,
Here's an updated version of this one, with the erratum coverage expanded
to include OMAP34xx/35xx.
I think this one can replace Tero's "[PATCHv6 06/11] ARM: OMAP:
clockdomain: add support for preventing autodep delete" and "[PATCHv6
07/11] ARM: OMAP3: do not delete per_clkdm autodeps during idle". Tero,
please let us know if you feel otherwise.
The patch seems to pass testing on 37xx. Was not able to really test it
on 35xx due to PM regressions in v3.7-rc1.
- Paul
From: Paul Walmsley <paul@pwsan.com>
Date: Tue, 16 Oct 2012 00:08:53 -0600
Subject: [PATCH] ARM: OMAP3: PM: apply part of the erratum i582 workaround
On OMAP34xx/35xx, and OMAP36xx chips with ES < 1.2, if the PER
powerdomain goes to OSWR or OFF while CORE stays at CSWR or ON, or if,
upon chip wakeup from OSWR or OFF, the CORE powerdomain goes ON before
PER, the UART3/4 FIFOs and McBSP2/3 SIDETONE memories will be
unusable. This is erratum i582 in the OMAP36xx Silicon Errata
document.
This patch implements one of several parts of the workaround: the
addition of the wakeup dependency between the PER and WKUP
clockdomains, such that PER will wake up at the same time CORE_L3
does.
This is not a complete workaround. For it to be complete:
1. the PER powerdomain's next power state must not be set to OSWR or
OFF if the CORE powerdomain's next power state is set to CSWR or
ON;
2. the UART3/4 FIFO and McBSP2/3 SIDETONE loopback tests should be run
if the LASTPOWERSTATEENTERED bits for PER and CORE indicate that
PER went OFF while CORE stayed on. If loopback tests fail, then
those devices will be unusable until PER and CORE can undergo a
transition from ON to OSWR/OFF and back ON.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/pm.h | 1 +
arch/arm/mach-omap2/pm34xx.c | 30 ++++++++++++++++++++++++++++--
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 686137d..67d6613 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -91,6 +91,7 @@ extern void omap3_save_scratchpad_contents(void);
#define PM_RTA_ERRATUM_i608 (1 << 0)
#define PM_SDRC_WAKEUP_ERRATUM_i583 (1 << 1)
+#define PM_PER_MEMORIES_ERRATUM_i582 (1 << 2)
#if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP3)
extern u16 pm34xx_errata;
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c0f8a78..2e0c9e8 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -651,14 +651,17 @@ static void __init pm_errata_configure(void)
/* Enable the l2 cache toggling in sleep logic */
enable_omap3630_toggle_l2_on_restore();
if (omap_rev() < OMAP3630_REV_ES1_2)
- pm34xx_errata |= PM_SDRC_WAKEUP_ERRATUM_i583;
+ pm34xx_errata |= (PM_SDRC_WAKEUP_ERRATUM_i583 |
+ PM_PER_MEMORIES_ERRATUM_i582);
+ } else if (cpu_is_omap34xx()) {
+ pm34xx_errata |= PM_PER_MEMORIES_ERRATUM_i582;
}
}
int __init omap3_pm_init(void)
{
struct power_state *pwrst, *tmp;
- struct clockdomain *neon_clkdm, *mpu_clkdm;
+ struct clockdomain *neon_clkdm, *mpu_clkdm, *per_clkdm, *wkup_clkdm;
int ret;
if (!omap3_has_io_chain_ctrl())
@@ -710,6 +713,8 @@ int __init omap3_pm_init(void)
neon_clkdm = clkdm_lookup("neon_clkdm");
mpu_clkdm = clkdm_lookup("mpu_clkdm");
+ per_clkdm = clkdm_lookup("per_clkdm");
+ wkup_clkdm = clkdm_lookup("wkup_clkdm");
#ifdef CONFIG_SUSPEND
omap_pm_suspend = omap3_pm_suspend;
@@ -726,6 +731,27 @@ int __init omap3_pm_init(void)
if (IS_PM34XX_ERRATUM(PM_RTA_ERRATUM_i608))
omap3630_ctrl_disable_rta();
+ /*
+ * The UART3/4 FIFO and the sidetone memory in McBSP2/3 are
+ * not correctly reset when the PER powerdomain comes back
+ * from OFF or OSWR when the CORE powerdomain is kept active.
+ * See OMAP36xx Erratum i582 "PER Domain reset issue after
+ * Domain-OFF/OSWR Wakeup". This wakeup dependency is not a
+ * complete workaround. The kernel must also prevent the PER
+ * powerdomain from going to OSWR/OFF while the CORE
+ * powerdomain is not going to OSWR/OFF. And if PER last
+ * power state was off while CORE last power state was ON, the
+ * UART3/4 and McBSP2/3 SIDETONE devices need to run a
+ * self-test using their loopback tests; if that fails, those
+ * devices are unusable until the PER/CORE can complete a transition
+ * from ON to OSWR/OFF and then back to ON.
+ *
+ * XXX Technically this workaround is only needed if off-mode
+ * or OSWR is enabled.
+ */
+ if (IS_PM34XX_ERRATUM(PM_PER_MEMORIES_ERRATUM_i582))
+ clkdm_add_wkdep(per_clkdm, wkup_clkdm);
+
clkdm_add_wkdep(neon_clkdm, mpu_clkdm);
if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
omap3_secure_ram_storage =
--
1.7.10.4
^ permalink raw reply related
* [PATCH] mmc: mmci: Fixup and cleanup code for DMA handling
From: Ulf Hansson @ 2012-10-16 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZqe3uB9wGM5g5LUJuZEtzeBW=Hs5RF=5_CKU0CBWJRyA@mail.gmail.com>
Hi Linus,
On 12 October 2012 23:32, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, Oct 12, 2012 at 5:33 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
>
>> From: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> The cookie is now used to indicate if dma_unmap_sg shall be
>> done in post_request. At DMA errors, the DMA job is immediately
>> not only terminated but also unmapped. To indicate that this
>> has been done the cookie is reset to zero. post_request will
>> thus only do dma_umap_sg for requests which has a cookie not set
>> to zero.
>>
>> Some corresponding duplicated code could then be removed and
>> moreover some corrections at DMA errors for terminating the same
>> DMA job twice has also been fixed.
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> Signed-off-by: Per Forlin <per.forlin@stericsson.com>
>
> It looks like it's both factoring out code and also adding some unmapping
> in hithereto unhandled cases, correct? It looks OK to me now atleast so
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
This code has not been tested on a "legacy" ARM PL180 but only for
ux500 boards. Even if it should affect DMA handling we should test
this properly. Would be great if you were able to help out, I guess
you still have available hardware for these tests?
Kind regards
Ulf Hansson
^ permalink raw reply
* [PATCH 07/11] fsmc/nand: Provide contiguous buffers to dma
From: Artem Bityutskiy @ 2012-10-16 7:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdao_9TkH7=ia7kXB-KsQhNZQ7EfSS5B1X0wFPgg5OsuHA@mail.gmail.com>
On Mon, 2012-10-15 at 21:51 +0200, Linus Walleij wrote:
> On Mon, Oct 15, 2012 at 6:27 PM, Brian Norris
> <computersforpeace@gmail.com> wrote:
>
> > I would prefer not building a solution that hopes kmalloc() can get a
> > large contiguous buffer (remember, eraseblock sizes come as large as
> > 2MB these days). A real solution like CMA or scatter-gather seems like
> > a better idea.
>
> +1 on that, and as I think I illustrated the MMC subsystem is using
> the block layer helpers to form scatter-gather lists for it's requests.
> I don't see why the MTD subsystem need to be very different?
This is good idea, the problem is that it is a bit more work than
hacking the driver, so most people prefer the latter. By removing all
kmalloc()'s I basically wish to force people to go this way.
What are the SC functions names you refer?
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121016/e67d78eb/attachment-0001.sig>
^ permalink raw reply
* [PATCH 1/2] ARM: mx27_3ds: Reserve memory for camera usage
From: Sascha Hauer @ 2012-10-16 7:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5DqJuernaHk-4KO_v=8vPCnrpqCZ-uZ2nrhtFcKo9xObA@mail.gmail.com>
On Tue, Oct 16, 2012 at 01:08:57AM -0300, Fabio Estevam wrote:
> On Wed, Oct 10, 2012 at 4:52 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Wed, Oct 10, 2012 at 12:29:29AM -0300, Fabio Estevam wrote:
> >> From: Fabio Estevam <fabio.estevam@freescale.com>
> >>
> >> Reserve dedicated memory block for camera usage.
> >
> > Why not use CMA?
>
> Sorry, not familiar with CMA. Could you please point to some board
> file/driver that makes use of it?
You just have to enable it. The driver then can use dma_alloc_* as it
used to.
Sascha
--
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
* [RESEND PATCH v3 2/2] i2c: change id to let i2c-at91 work
From: Greg KH @ 2012-10-16 7:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350364668-21280-2-git-send-email-voice.shen@atmel.com>
On Tue, Oct 16, 2012 at 01:17:48PM +0800, Bo Shen wrote:
> From: voice <voice.shen@atmel.com>
>
> The i2c core driver will turn the platform device ID to busnum
> When using platfrom device ID as -1, it means dynamically assigned
> the busnum. When writing code, we need to make sure the busnum,
> and call i2c_register_board_info(int busnum, ...) to register device
> if using -1, we do not know the value of busnum
>
> In order to solve this issue, set the platform device ID as a fix number
> Here using 0 to match the busnum used in i2c_regsiter_board_info()
>
> Signed-off-by: Bo Shen <voice.shen@atmel.com>
> ---
> Resend
> Cc linux kernel stable mailing list
> ---
> arch/arm/mach-at91/at91rm9200.c | 2 +-
> arch/arm/mach-at91/at91rm9200_devices.c | 2 +-
> arch/arm/mach-at91/at91sam9260.c | 4 ++--
> arch/arm/mach-at91/at91sam9260_devices.c | 2 +-
> arch/arm/mach-at91/at91sam9261.c | 4 ++--
> arch/arm/mach-at91/at91sam9261_devices.c | 2 +-
> arch/arm/mach-at91/at91sam9263.c | 2 +-
> arch/arm/mach-at91/at91sam9263_devices.c | 2 +-
> arch/arm/mach-at91/at91sam9rl_devices.c | 2 +-
> 9 files changed, 11 insertions(+), 11 deletions(-)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
^ permalink raw reply
* [RESEND PATCH v3 1/2] i2c: change id to let i2c-gpio work
From: Greg KH @ 2012-10-16 7:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350364668-21280-1-git-send-email-voice.shen@atmel.com>
On Tue, Oct 16, 2012 at 01:17:47PM +0800, Bo Shen wrote:
> From: voice <voice.shen@atmel.com>
>
> The i2c core driver will turn the platform device ID to busnum
> When using platfrom device ID as -1, it means dynamically assigned
> the busnum. When writing code, we need to make sure the busnum,
> and call i2c_register_board_info(int busnum, ...) to register device
> if using -1, we do not know the value of busnum
>
> In order to solve this issue, set the platform device ID as a fix number
> Here using 0 to match the busnum used in i2c_regsiter_board_info()
>
> Signed-off-by: Bo Shen <voice.shen@atmel.com>
> ---
> Resend
> Cc linux kernel stable mailing list
> Change since v2
> Fix this issue for more boards
> Change since v1
> Make the commit message more clear
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
^ permalink raw reply
* [PATCH 07/11] fsmc/nand: Provide contiguous buffers to dma
From: Artem Bityutskiy @ 2012-10-16 7:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAN8TOE-7d=YUSYsHFw9X5vnz8cpSJYv5uZfvBpDyhg+-F_LDiQ@mail.gmail.com>
On Mon, 2012-10-15 at 09:27 -0700, Brian Norris wrote:
> > I'd really prefer to just switch to kmalloc() everywhere instead of
> > adding hacks like this to the drivers. Then if this is a problem for
> > someone, he can fix it by either switching to smaller buffers (possible
> > in many places), or by improving memory fragmentation issues on his
> > system, or by just using CMA.
>
> I think I can suggest that this is already a problem on real systems.
> In bringing up a board on v3.3 kernel, I experienced a kernel memory
> allocation error when trying to memdup_user() in eraseblock-size
> regions. I believe I would experience more of these if all
> eraseblock-sized buffers were kmalloc()'d.
>
> See the commit description for the following commit in mtd-utils.git:
>
> commit 71c76e74661492b4f68f670514866cfc85f47089
> libmtd: fix mtd_write() issues for large data-only writes
Well, this is another work-around. The better way to fix this would be
to change kernel's 'mtdchar_write_ioctl()' to be iterative and avoid
calling 'memdup_user(len)' for arbitrary 'len' passed from user-space.
> I would prefer not building a solution that hopes kmalloc() can get a
> large contiguous buffer (remember, eraseblock sizes come as large as
> 2MB these days). A real solution like CMA or scatter-gather seems like
> a better idea.
Me too. But this does not happen. People bring this up for years. Of
course it is easier to hack drivers, and very understandable. So what
I would like to do is somehow force people to fix this issue.
So I thought about something like introducing an mtd_alloc() which
would:
a. Try doing CMA allocation: dma_alloc_from_contiguous()
b. If it fails, use kmalloc().
This function would probably need a cookie which it returns and which
the mtd_free() function would use to call either kfree() or
dma_release_from_contiguous()...
If both fail - bad luck. Go look at the code and switch to S-G lists
instead of allocating contiguous regions. As I said, in many places it
is easy to do, and there are few places when you would need to spend a
bit more time.
How does this sound to you?
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121016/04d3c8f5/attachment.sig>
^ permalink raw reply
* [PATCH 0/4] OMAP-GPMC generic timing migration
From: Afzal Mohammed @ 2012-10-16 6:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015160154.GB15569@atomide.com>
Hi Tony,
On Monday 15 October 2012 09:31 PM, Tony Lindgren wrote:
> * Mohammed, Afzal<afzal@ti.com> [121015 05:42]:
>> On Thu, Oct 11, 2012 at 20:17:56, Tony Lindgren wrote:
>>> Yes, then please do a second pull request for what's needed
>>> to apply the minimal DT bindings. For the DT binding, let's
>>> just leave out the timings for now as we can load those from
>>> auxdata. Then the binding for the timings can be added
>>> later on. So just the minimal binding using standard features
>>> for the iorange and interrupt.
>> Ok, I will keep timings aside for now and proceed with DT
>> (avoiding auxdata usage with generic routine looked to me a
>> saner approach though, with an initial DT'fy delay)
> Oh well if you think it's easier to do the timings too in
> the DT binding, please go ahead with that. It may take some
> longer discussion on the lists for the binding though. But
> up to you.
I certainly don't think it is easier, rather tougher, cleaner
as well. One thing that worried me was, if we pursue the
auxdata path (a last resort option) and later if it is
objected, we would be back to square one.
Let me discuss internally and get back.
Regards
Afzal
^ permalink raw reply
* dma_alloc_coherent fails in framebuffer
From: Tony Prisk @ 2012-10-16 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350366893.26424.5.camel@gitbox>
On Tue, 2012-10-16 at 18:54 +1300, Tony Prisk wrote:
> On Tue, 2012-10-16 at 10:17 +0800, Bob Liu wrote:
> > On Tue, Oct 16, 2012 at 2:28 AM, Tony Prisk <linux@prisktech.co.nz> wrote:
> > > On Mon, 2012-10-15 at 10:45 +0100, Mel Gorman wrote:
> > >> On Mon, Oct 15, 2012 at 09:34:55AM +1300, Tony Prisk wrote:
> > >> > On Sun, 2012-10-14 at 18:28 +1300, Tony Prisk wrote:
> > >> > > Up until 07 Oct, drivers/video/wm8505-fb.c was working fine, but on the
> > >> > > 11 Oct when I did another pull from linus all of a sudden
> > >> > > dma_alloc_coherent is failing to allocate the framebuffer any longer.
> > >> > >
> > >> > > I did a quick look back and found this:
> > >> > >
> > >> > > ARM: add coherent dma ops
> > >> > >
> > >> > > arch_is_coherent is problematic as it is a global symbol. This
> > >> > > doesn't work for multi-platform kernels or platforms which can support
> > >> > > per device coherent DMA.
> > >> > >
> > >> > > This adds arm_coherent_dma_ops to be used for devices which connected
> > >> > > coherently (i.e. to the ACP port on Cortex-A9 or A15). The arm_dma_ops
> > >> > > are modified at boot when arch_is_coherent is true.
> > >> > >
> > >> > > Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> > >> > > Cc: Russell King <linux@arm.linux.org.uk>
> > >> > > Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> > >> > > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > >> > >
> > >> > >
> > >> > > This is the only patch lately that I could find (not that I would claim
> > >> > > to be any good at finding things) that is related to the problem. Could
> > >> > > it have caused the allocations to fail?
> > >> > >
> > >> > > Regards
> > >> > > Tony P
> > >> >
> > >> > Have done a bit more digging and found the cause - not Rob's patch so
> > >> > apologies.
> > >> >
> > >> > The cause of the regression is this patch:
> > >> >
> > >> > From f40d1e42bb988d2a26e8e111ea4c4c7bac819b7e Mon Sep 17 00:00:00 2001
> > >> > From: Mel Gorman <mgorman@suse.de>
> > >> > Date: Mon, 8 Oct 2012 16:32:36 -0700
> > >> > Subject: [PATCH 2/3] mm: compaction: acquire the zone->lock as late as
> > >> > possible
> > >> >
> > >> > Up until then, the framebuffer allocation with dma_alloc_coherent(...)
> > >> > was fine. From this patch onwards, allocations fail.
> > >> >
> > >>
> > >> Was this found through bisection or some other means?
> > >>
> > >> There was a bug in that series that broke CMA but it was commit bb13ffeb
> > >> (mm: compaction: cache if a pageblock was scanned and no pages were
> > >> isolated) and it was fixed by 62726059 (mm: compaction: fix bit ranges
> > >> in {get,clear,set}_pageblock_skip()). So it should have been fixed by
> > >> 3.7-rc1 and probably was included by the time you pulled in October 11th
> > >> but bisection would be a pain. There were problems with that series during
> > >> development but tests were completing for other people.
> > >>
> > >> Just in case, is this still broken in 3.7-rc1?
> > >
> > > Still broken. Although the printk's might have cleared it up a bit.
> > >>
> > >> > I don't know how this patch would effect CMA allocations, but it seems
> > >> > to be causing the issue (or at least, it's caused an error in
> > >> > arch-vt8500 to become visible).
> > >> >
> > >> > Perhaps someone who understand -mm could explain the best way to
> > >> > troubleshoot the cause of this problem?
> > >> >
> > >>
> > >> If you are comfortable with ftrace, it can be used to narrow down where
> > >> the exact failure is occurring but if you're not comfortable with that
> > >> then the easiest is a bunch of printks starting in alloc_contig_range()
> > >> to see at what point and why it returns failure.
> > >>
> > >> It's not obvious at the moment why that patch would cause an allocation
> > >> problem. It's the type of patch that if it was wrong it would fail every
> > >> time for everyone, not just for a single driver.
> > >>
> > >
> > > I added some printk's to see what was happening.
> > >
> > > from arch/arm/mm/dma-mapping.c: arm_dma_alloc(..) it calls out to:
> > > dma_alloc_from_coherent().
> > >
> > > This returns 0, because:
> > > mem = dev->dma_mem
> > > if (!mem) return 0;
> > >
> > > and then arm_dma_alloc() falls back on __dma_alloc(..)
> > >
> > >
> > > I suspect the reason this fault is a bit 'weird' is because its
> > > effectively not using alloc_from_coherent at all, but falling back on
> > > __dma_alloc all the time, and sometimes it fails.
> > >
> >
> > I think you need to declare that memory using
> > dma_declare_coherent_memory() before
> > alloc_from_coherent.
> >
> > > Why it caused a problem on that particular commit I don't know - but it
> > > was reproducible by adding/removing it.
> > >
> > >
> > > Regards
> > > Tony P
> > >
> > > --
> > > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > > the body to majordomo at kvack.org. For more info on Linux MM,
> > > see: http://www.linux-mm.org/ .
> > > Don't email: <a href=mailto:"dont@kvack.org"> email at kvack.org </a>
> >
>
>
> I finally found the link to this patch which caused the problem - and
> may still be the cause of my problems :)
>
> > >>>
> > >>> From f40d1e42bb988d2a26e8e111ea4c4c7bac819b7e Mon Sep 17 00:00:00 2001
> > >>> From: Mel Gorman <mgorman@suse.de>
> > >>> Date: Mon, 8 Oct 2012 16:32:36 -0700
> > >>> Subject: [PATCH 2/3] mm: compaction: acquire the zone->lock as late as
> > >>> possible
>
> In mm/page_alloc.c:alloc_contig_range()
>
> ...
> outer_end = isolate_freepages_range(&cc, outer_start, end);
> if (!outer_end) {
> ret = -EBUSY;
> goto done;
> }
> ..
>
> It is always returning via the !outer_end test with -EBUSY.
>
> isolate_freepages_range() was one of the functions modified by
> the above mentioned patch.
>
> Around in a big circle and back to the start :)
>
> Regards
> Tony P
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Found the new code which has produced the problem, but perhaps someone
with more knowledge can explain why. Commit
f40d1e42bb988d2a26e8e111ea4c4c7bac819b7e introduced an additional check
which wasn't previously there.
+ /*
+ * If strict isolation is requested by CMA then check that all the
+ * pages requested were isolated. If there were any failures, 0 is
+ * returned and CMA will fail.
+ */
+ if (strict && nr_strict_required != total_isolated)
+ total_isolated = 0;
At the moment, my platform always fails to allocate the framebuffer
because nr_strict_required != total_isolated.
total_isolated will exceed nr_strict_required which causes an error.
For all the other drivers using dma_alloc_coherent, it seems to keep
increasing nr_strict_required until it gets a match with total_isolated:
For the EHCI driver:
[ 4.740000] total_isolated = 512, nr_strict_required=1
[ 4.740000] FINAL! total_isolated = 512, nr_strict_required=1
[ 4.740000] strict && nr_strict_required != total_isolated
[ 4.750000] total_isolated = 512, nr_strict_required=2
[ 4.750000] FINAL! total_isolated = 512, nr_strict_required=2
[ 4.750000] strict && nr_strict_required != total_isolated
...
[ 13.220000] total_isolated = 512, nr_strict_required=511
[ 13.220000] FINAL! total_isolated = 512, nr_strict_required=511
[ 13.220000] strict && nr_strict_required != total_isolated
[ 13.230000] total_isolated = 512, nr_strict_required=512
[ 13.230000] FINAL! total_isolated = 512, nr_strict_required=512
The framebuffer gives up trying when:
[ 0.730000] total_isolated = 1024, nr_strict_required=983
[ 0.730000] FINAL! total_isolated = 1024, nr_strict_required=983
[ 0.730000] strict && nr_strict_required != total_isolated
[ 0.730000] total_isolated = 1024, nr_strict_required=999
[ 0.730000] FINAL! total_isolated = 1024, nr_strict_required=999
[ 0.730000] strict && nr_strict_required != total_isolated
[ 0.740000] total_isolated = 1024, nr_strict_required=1015
[ 0.740000] FINAL! total_isolated = 1024, nr_strict_required=1015
[ 0.740000] strict && nr_strict_required != total_isolated
Given that nr_strict_required + 16 = 1031, I guess it gives up trying
and fails.
Any suggestions on how to fix this?
Regards
Tony P
^ permalink raw reply
* [PATCH] MTD: atmel_nand: fix compile error when use avr32-atstk1006_defconfig
From: Josh Wu @ 2012-10-16 6:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350308938.5769.7.camel@sauron.fi.intel.com>
On 10/15/2012 9:48 PM, Artem Bityutskiy wrote:
> On Mon, 2012-10-08 at 14:46 +0800, Josh Wu wrote:
>> fixed the following compile error when use avr32 config:
>> drivers/mtd/nand/atmel_nand.c: In function 'pmecc_err_location':
>> drivers/mtd/nand/atmel_nand.c:639: error: implicit declaration of function 'writel_relaxed'
>>
>> Since in ARCH avr32, there is no macro "writel_relaxed" defined. In this patch we use macro "writel" instead.
>>
>> Signed-off-by: Josh Wu <josh.wu@atmel.com>
> Why not to provide writel_relaxed() in AVR instead?
>
OK, I can send another patch to add writel_relaxed() in AVR. Since I
don't have any AVR board in my hand, I need someone test it. thank you.
Best Regards,
Josh Wu
^ permalink raw reply
* [PATCH 6/6] ARM: EXYNOS5: SATA PHY controller driver
From: Vasanth Ananthan @ 2012-10-16 6:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10179968.slaZyPIETn@flatron>
Hi Tomasz,
On Sat, Oct 13, 2012 at 4:20 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> Hi,
>
> On Tuesday 09 of October 2012 17:18:52 Vasanth Ananthan wrote:
>> This patch adds a platform driver and I2C client driver for SATA PHY
>> controller
>>
>> Signed-off-by: Vasanth Ananthan <vasanth.a@samsung.com>
>> ---
>> drivers/ata/Makefile | 2 +-
>> drivers/ata/sata_exynos_phy.c | 303
>> +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 304
>> insertions(+), 1 deletions(-)
>> create mode 100644 drivers/ata/sata_exynos_phy.c
>>
[ ... ]
>> +
>> + phy->init = sataphy_init;
>> + phy->shutdown = sataphy_shutdown;
>> + phy->priv_data = (void *)sataphy;
>> + phy->dev = &pdev->dev;
>> +
>> + ret = sata_add_phy(phy, SATA_PHY_GENERATION3);
>> + if (ret < 0)
>> + goto err4;
>
> Do you have any warranties that phy callbacks won't get called before i2c
> device probes and sets i2c_client?
>
>> +
>> + ret = i2c_add_driver(&sataphy_i2c_driver);
>> + if (ret < 0)
>> + goto err5;
>> +
>> + platform_set_drvdata(pdev, phy);
I shall register my i2c client driver before assigning the SATA PHY
call backs. Would that guarantee the calling of phy callbacks after
the i2c device probes?
--
Vasanth Ananthan
^ permalink raw reply
* [Linaro-mm-sig] [RFC 0/2] DMA-mapping & IOMMU - physically contiguous allocations
From: Hiroshi Doyu @ 2012-10-16 6:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAQKjZMYFNMEnb2ue2aR+6AEbOixnQFyggbXrThBCW5VOznePg@mail.gmail.com>
Hi Inki/Marek,
On Tue, 16 Oct 2012 02:50:16 +0200
Inki Dae <inki.dae@samsung.com> wrote:
> 2012/10/15 Marek Szyprowski <m.szyprowski@samsung.com>:
> > Hello,
> >
> > Some devices, which have IOMMU, for some use cases might require to
> > allocate a buffers for DMA which is contiguous in physical memory. Such
> > use cases appears for example in DRM subsystem when one wants to improve
> > performance or use secure buffer protection.
> >
> > I would like to ask if adding a new attribute, as proposed in this RFC
> > is a good idea? I feel that it might be an attribute just for a single
> > driver, but I would like to know your opinion. Should we look for other
> > solution?
> >
>
> In addition, currently we have worked dma-mapping-based iommu support
> for exynos drm driver with this patch set so this patch set has been
> tested with iommu enabled exynos drm driver and worked fine. actually,
> this feature is needed for secure mode such as TrustZone. in case of
> Exynos SoC, memory region for secure mode should be physically
> contiguous and also maybe OMAP but now dma-mapping framework doesn't
> guarantee physically continuous memory allocation so this patch set
> would make it possible.
Agree that the contigous memory allocation is necessary for us too.
In addition to those contiguous/discontiguous page allocation, is
there any way to _import_ anonymous pages allocated by a process to be
used in dma-mapping API later?
I'm considering the following scenario, an user process allocates a
buffer by malloc() in advance, and then it asks some driver to convert
that buffer into IOMMU'able/DMA'able ones later. In this case, pages
are discouguous and even they may not be yet allocated at
malloc()/mmap().
^ permalink raw reply
* [PATCH 3/3] ARM: dts: enable dma support for auart0 in mx28
From: Huang Shijie @ 2012-10-16 6:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350367386-7742-1-git-send-email-b32955@freescale.com>
enable the dma support for auart0 in mx28.
Signed-off-by: Huang Shijie <b32955@freescale.com>
---
arch/arm/boot/dts/imx28.dtsi | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 6ed9215..738e023 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -798,6 +798,8 @@
compatible = "fsl,imx28-auart";
reg = <0x8006a000 0x2000>;
interrupts = <112 70 71>;
+ fsl,auart-dma-channel = <8 9>;
+ fsl,auart-enable-dma;
clocks = <&clks 45>;
status = "disabled";
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] serial: mxs-auart: add the DMA support for mx28
From: Huang Shijie @ 2012-10-16 6:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350367386-7742-1-git-send-email-b32955@freescale.com>
Only we meet the following conditions, we can enable the DMA support for
auart:
(1) We enable the DMA support in the dts file, such as
arch/arm/boot/dts/imx28.dtsi.
(2) We enable the hardware flow control.
(3) We use the mx28, not the mx23. Due to hardware bug(see errata: 2836),
we can not add the DMA support to mx23.
Signed-off-by: Huang Shijie <b32955@freescale.com>
---
.../bindings/tty/serial/fsl-mxs-auart.txt | 7 +
drivers/tty/serial/mxs-auart.c | 307 +++++++++++++++++++-
2 files changed, 311 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
index a154bf1..67e54b4 100644
--- a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
+++ b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
@@ -6,11 +6,18 @@ Required properties:
- reg : Address and length of the register set for the device
- interrupts : Should contain the auart interrupt numbers
+Optional properties:
+- fsl,auart-dma-channel : The DMA channels, the first is for RX, the other
+ is for TX.
+- fsl,auart-enable-dma : Enable the DMA support for the auart.
+
Example:
auart0: serial at 8006a000 {
compatible = "fsl,imx28-auart";
reg = <0x8006a000 0x2000>;
interrupts = <112 70 71>;
+ fsl,auart-dma-channel = <8 9>;
+ fsl,auart-enable-dma;
};
Note: Each auart port should have an alias correctly numbered in "aliases"
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index cd9ec1d..2271330 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -34,6 +34,8 @@
#include <linux/io.h>
#include <linux/pinctrl/consumer.h>
#include <linux/of_device.h>
+#include <linux/dma-mapping.h>
+#include <linux/fsl/mxs-dma.h>
#include <asm/cacheflush.h>
@@ -76,7 +78,15 @@
#define AUART_CTRL0_SFTRST (1 << 31)
#define AUART_CTRL0_CLKGATE (1 << 30)
+#define AUART_CTRL0_RXTO_ENABLE (1 << 27)
+#define AUART_CTRL0_RXTIMEOUT(v) (((v) & 0x7ff) << 16)
+#define AUART_CTRL0_XFER_COUNT(v) ((v) & 0xffff)
+#define AUART_CTRL1_XFER_COUNT(v) ((v) & 0xffff)
+
+#define AUART_CTRL2_DMAONERR (1 << 26)
+#define AUART_CTRL2_TXDMAE (1 << 25)
+#define AUART_CTRL2_RXDMAE (1 << 24)
#define AUART_CTRL2_CTSEN (1 << 15)
#define AUART_CTRL2_RTSEN (1 << 14)
#define AUART_CTRL2_RTS (1 << 11)
@@ -116,12 +126,15 @@
#define AUART_STAT_BERR (1 << 18)
#define AUART_STAT_PERR (1 << 17)
#define AUART_STAT_FERR (1 << 16)
+#define AUART_STAT_RXCOUNT_MASK 0xffff
static struct uart_driver auart_driver;
struct mxs_auart_port {
struct uart_port port;
+#define MXS_AUART_DMA_CONFIG 0x1
+#define MXS_AUART_DMA_ENABLED 0x2
unsigned int flags;
unsigned int ctrl;
@@ -130,16 +143,116 @@ struct mxs_auart_port {
struct clk *clk;
struct device *dev;
struct platform_device *pdev;
+
+ /* for DMA */
+ struct mxs_dma_data dma_data;
+ int dma_channel_rx, dma_channel_tx;
+ int dma_irq_rx, dma_irq_tx;
+ int dma_channel;
+
+ struct scatterlist tx_sgl;
+ struct dma_chan *tx_dma_chan;
+ void *tx_dma_buf;
+
+ struct scatterlist rx_sgl;
+ struct dma_chan *rx_dma_chan;
+ void *rx_dma_buf;
};
+static inline bool auart_dma_enabled(struct mxs_auart_port *s)
+{
+ return s->flags & MXS_AUART_DMA_ENABLED;
+}
+
static void mxs_auart_stop_tx(struct uart_port *u);
#define to_auart_port(u) container_of(u, struct mxs_auart_port, port)
+static inline void mxs_auart_tx_chars(struct mxs_auart_port *s);
+
+static void dma_tx_callback(void *param)
+{
+ struct mxs_auart_port *s = param;
+ struct circ_buf *xmit = &s->port.state->xmit;
+
+ dma_unmap_sg(s->dev, &s->tx_sgl, 1, DMA_TO_DEVICE);
+
+ /* wake up the possible processes. */
+ if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+ uart_write_wakeup(&s->port);
+
+ mxs_auart_tx_chars(s);
+}
+
+static int mxs_auart_dma_tx(struct mxs_auart_port *s, int size)
+{
+ struct dma_async_tx_descriptor *desc;
+ struct scatterlist *sgl = &s->tx_sgl;
+ struct dma_chan *channel = s->tx_dma_chan;
+ u32 pio[1];
+
+ /* [1] : send PIO. Note, the first pio word is CTRL1. */
+ pio[0] = AUART_CTRL1_XFER_COUNT(size);
+ desc = dmaengine_prep_slave_sg(channel, (struct scatterlist *)pio,
+ 1, DMA_TRANS_NONE, 0);
+ if (!desc) {
+ dev_err(s->dev, "step 1 error\n");
+ return -EINVAL;
+ }
+
+ /* [2] : set DMA buffer. */
+ sg_init_one(sgl, s->tx_dma_buf, size);
+ dma_map_sg(s->dev, sgl, 1, DMA_TO_DEVICE);
+ desc = dmaengine_prep_slave_sg(channel, sgl,
+ 1, DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ if (!desc) {
+ dev_err(s->dev, "step 2 error\n");
+ return -EINVAL;
+ }
+
+ /* [3] : submit the DMA */
+ desc->callback = dma_tx_callback;
+ desc->callback_param = s;
+ dmaengine_submit(desc);
+ dma_async_issue_pending(channel);
+ return 0;
+}
+
static inline void mxs_auart_tx_chars(struct mxs_auart_port *s)
{
struct circ_buf *xmit = &s->port.state->xmit;
+ if (auart_dma_enabled(s)) {
+ int i = 0;
+ int size;
+ void *buffer = s->tx_dma_buf;
+ enum dma_status status;
+
+ /* Check whether there is pending DMA operations. */
+ status = dmaengine_tx_status(s->tx_dma_chan, 0, NULL);
+ if (status != DMA_SUCCESS)
+ return;
+
+ while (!uart_circ_empty(xmit) && !uart_tx_stopped(&s->port)) {
+ size = min_t(u32, UART_XMIT_SIZE - i,
+ CIRC_CNT_TO_END(xmit->head,
+ xmit->tail,
+ UART_XMIT_SIZE));
+ memcpy(buffer + i, xmit->buf + xmit->tail, size);
+ xmit->tail = (xmit->tail + size) & (UART_XMIT_SIZE - 1);
+
+ i += size;
+ if (i >= UART_XMIT_SIZE)
+ break;
+ }
+
+ if (uart_tx_stopped(&s->port))
+ mxs_auart_stop_tx(&s->port);
+ if (i)
+ mxs_auart_dma_tx(s, i);
+ return;
+ }
+
while (!(readl(s->port.membase + AUART_STAT) &
AUART_STAT_TXFF)) {
if (s->port.x_char) {
@@ -293,10 +406,155 @@ static u32 mxs_auart_get_mctrl(struct uart_port *u)
return mctrl;
}
+static bool mxs_auart_dma_filter(struct dma_chan *chan, void *param)
+{
+ struct mxs_auart_port *s = param;
+
+ if (!mxs_dma_is_apbx(chan))
+ return false;
+
+ if (s->dma_channel == chan->chan_id) {
+ chan->private = &s->dma_data;
+ return true;
+ }
+ return false;
+}
+
+static int mxs_auart_dma_prep_rx(struct mxs_auart_port *s);
+static void dma_rx_callback(void *arg)
+{
+ struct mxs_auart_port *s = (struct mxs_auart_port *) arg;
+ struct tty_struct *tty = s->port.state->port.tty;
+ int count;
+ u32 stat;
+
+ stat = readl(s->port.membase + AUART_STAT);
+ stat &= ~(AUART_STAT_OERR | AUART_STAT_BERR |
+ AUART_STAT_PERR | AUART_STAT_FERR);
+
+ count = stat & AUART_STAT_RXCOUNT_MASK;
+ tty_insert_flip_string(tty, s->rx_dma_buf, count);
+
+ writel(stat, s->port.membase + AUART_STAT);
+ tty_flip_buffer_push(tty);
+
+ /* start the next DMA for RX. */
+ mxs_auart_dma_prep_rx(s);
+}
+
+static int mxs_auart_dma_prep_rx(struct mxs_auart_port *s)
+{
+ struct dma_async_tx_descriptor *desc;
+ struct scatterlist *sgl = &s->rx_sgl;
+ struct dma_chan *channel = s->rx_dma_chan;
+ u32 pio[1];
+
+ /* [1] : send PIO */
+ pio[0] = AUART_CTRL0_RXTO_ENABLE
+ | AUART_CTRL0_RXTIMEOUT(0x80)
+ | AUART_CTRL0_XFER_COUNT(UART_XMIT_SIZE);
+ desc = dmaengine_prep_slave_sg(channel, (struct scatterlist *)pio,
+ 1, DMA_TRANS_NONE, 0);
+ if (!desc) {
+ dev_err(s->dev, "step 1 error\n");
+ return -EINVAL;
+ }
+
+ /* [2] : send DMA request */
+ sg_init_one(sgl, s->rx_dma_buf, UART_XMIT_SIZE);
+ dma_map_sg(s->dev, sgl, 1, DMA_FROM_DEVICE);
+ desc = dmaengine_prep_slave_sg(channel, sgl, 1, DMA_DEV_TO_MEM,
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ if (!desc) {
+ dev_err(s->dev, "step 2 error\n");
+ return -1;
+ }
+
+ /* [3] : submit the DMA, but do not issue it. */
+ desc->callback = dma_rx_callback;
+ desc->callback_param = s;
+ dmaengine_submit(desc);
+ dma_async_issue_pending(channel);
+ return 0;
+}
+
+static void mxs_auart_dma_exit_channel(struct mxs_auart_port *s)
+{
+ if (s->tx_dma_chan) {
+ dma_release_channel(s->tx_dma_chan);
+ s->tx_dma_chan = NULL;
+ }
+ if (s->rx_dma_chan) {
+ dma_release_channel(s->rx_dma_chan);
+ s->rx_dma_chan = NULL;
+ }
+
+ kfree(s->tx_dma_buf);
+ kfree(s->rx_dma_buf);
+ s->tx_dma_buf = NULL;
+ s->rx_dma_buf = NULL;
+}
+
+static void mxs_auart_dma_exit(struct mxs_auart_port *s)
+{
+
+ writel(AUART_CTRL2_TXDMAE | AUART_CTRL2_RXDMAE | AUART_CTRL2_DMAONERR,
+ s->port.membase + AUART_CTRL2_CLR);
+
+ mxs_auart_dma_exit_channel(s);
+ s->flags &= ~MXS_AUART_DMA_ENABLED;
+}
+
+static int mxs_auart_dma_init(struct mxs_auart_port *s)
+{
+ dma_cap_mask_t mask;
+
+ if (auart_dma_enabled(s))
+ return 0;
+
+ /* We do not get the right DMA channels. */
+ if (s->dma_channel_rx == -1 || s->dma_channel_rx == -1)
+ return -EINVAL;
+
+ /* init for RX */
+ dma_cap_zero(mask);
+ dma_cap_set(DMA_SLAVE, mask);
+ s->dma_channel = s->dma_channel_rx;
+ s->dma_data.chan_irq = s->dma_irq_rx;
+ s->rx_dma_chan = dma_request_channel(mask, mxs_auart_dma_filter, s);
+ if (!s->rx_dma_chan)
+ goto err_out;
+ s->rx_dma_buf = kzalloc(UART_XMIT_SIZE, GFP_KERNEL | GFP_DMA);
+ if (!s->rx_dma_buf)
+ goto err_out;
+
+ /* init for TX */
+ s->dma_channel = s->dma_channel_tx;
+ s->dma_data.chan_irq = s->dma_irq_tx;
+ s->tx_dma_chan = dma_request_channel(mask, mxs_auart_dma_filter, s);
+ if (!s->tx_dma_chan)
+ goto err_out;
+ s->tx_dma_buf = kzalloc(UART_XMIT_SIZE, GFP_KERNEL | GFP_DMA);
+ if (!s->tx_dma_buf)
+ goto err_out;
+
+ /* set the flags */
+ s->flags |= MXS_AUART_DMA_ENABLED;
+ dev_dbg(s->dev, "enabled the DMA support.");
+
+ return 0;
+
+err_out:
+ mxs_auart_dma_exit_channel(s);
+ return -EINVAL;
+
+}
+
static void mxs_auart_settermios(struct uart_port *u,
struct ktermios *termios,
struct ktermios *old)
{
+ struct mxs_auart_port *s = to_auart_port(u);
u32 bm, ctrl, ctrl2, div;
unsigned int cflag, baud;
@@ -368,10 +626,23 @@ static void mxs_auart_settermios(struct uart_port *u,
ctrl |= AUART_LINECTRL_STP2;
/* figure out the hardware flow control settings */
- if (cflag & CRTSCTS)
+ if (cflag & CRTSCTS) {
+ /*
+ * The DMA has a bug(see errata:2836) in mx23.
+ * So we can not implement the DMA for auart in mx23,
+ * we can only implement the DMA support for auart
+ * in mx28.
+ */
+ if (!AUART_IS_MX23(s) && (s->flags & MXS_AUART_DMA_CONFIG)) {
+ if (!mxs_auart_dma_init(s))
+ /* enable DMA tranfer */
+ ctrl2 |= AUART_CTRL2_TXDMAE | AUART_CTRL2_RXDMAE
+ | AUART_CTRL2_DMAONERR;
+ }
ctrl2 |= AUART_CTRL2_CTSEN | AUART_CTRL2_RTSEN;
- else
+ } else {
ctrl2 &= ~(AUART_CTRL2_CTSEN | AUART_CTRL2_RTSEN);
+ }
/* set baud rate */
baud = uart_get_baud_rate(u, termios, old, 0, u->uartclk);
@@ -383,6 +654,17 @@ static void mxs_auart_settermios(struct uart_port *u,
writel(ctrl2, u->membase + AUART_CTRL2);
uart_update_timeout(u, termios->c_cflag, baud);
+
+ /* prepare for the DMA RX. */
+ if (auart_dma_enabled(s)) {
+ if (!mxs_auart_dma_prep_rx(s)) {
+ /* Disable the normal RX interrupt. */
+ writel(AUART_INTR_RXIEN, u->membase + AUART_INTR_CLR);
+ } else {
+ mxs_auart_dma_exit(s);
+ dev_err(s->dev, "We can not start up the DMA.\n");
+ }
+ }
}
static irqreturn_t mxs_auart_irq_handle(int irq, void *context)
@@ -461,6 +743,9 @@ static void mxs_auart_shutdown(struct uart_port *u)
{
struct mxs_auart_port *s = to_auart_port(u);
+ if (auart_dma_enabled(s))
+ mxs_auart_dma_exit(s);
+
writel(AUART_CTRL2_UARTEN, u->membase + AUART_CTRL2_CLR);
writel(AUART_INTR_RXIEN | AUART_INTR_RTIEN | AUART_INTR_CTSMIEN,
@@ -707,6 +992,7 @@ static int serial_mxs_probe_dt(struct mxs_auart_port *s,
struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
+ u32 dma_channel[2];
int ret;
if (!np)
@@ -722,6 +1008,22 @@ static int serial_mxs_probe_dt(struct mxs_auart_port *s,
pdev->id_entry = of_match_device(mxs_auart_dt_ids, &pdev->dev)->data;
+ ret = of_property_read_u32_array(np, "fsl,auart-dma-channel",
+ dma_channel, 2);
+ if (ret == 0) {
+ s->dma_channel_rx = dma_channel[0];
+ s->dma_channel_tx = dma_channel[1];
+ } else {
+ s->dma_channel_rx = -1;
+ s->dma_channel_tx = -1;
+ }
+
+ s->dma_irq_rx = platform_get_irq(pdev, 1);
+ s->dma_irq_tx = platform_get_irq(pdev, 2);
+
+ if (of_property_read_bool(np, "fsl,auart-enable-dma"))
+ s->flags |= MXS_AUART_DMA_CONFIG;
+
return 0;
}
@@ -772,7 +1074,6 @@ static int __devinit mxs_auart_probe(struct platform_device *pdev)
s->port.type = PORT_IMX;
s->port.dev = s->dev = get_device(&pdev->dev);
- s->flags = 0;
s->ctrl = 0;
s->pdev = pdev;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/3] serial: mxs-auart: distinguish the different SOCs
From: Huang Shijie @ 2012-10-16 6:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350367386-7742-1-git-send-email-b32955@freescale.com>
From: Huang Shijie <shijie8@gmail.com>
The current mxs-auart driver is used for both mx23 and mx28.
But in mx23, the DMA has a bug(see errata:2836). We can not add the
DMA support in mx23, but we can add DMA support to auart in mx28.
So in order to add the DMA support for the auart in mx28, we should add
the platform_device_id to distinguish the distinguish SOCs.
Signed-off-by: Huang Shijie <b32955@freescale.com>
---
.../bindings/tty/serial/fsl-mxs-auart.txt | 2 +-
arch/arm/boot/dts/imx28.dtsi | 10 +++---
drivers/tty/serial/mxs-auart.c | 28 +++++++++++++++----
3 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
index 2ee903f..a154bf1 100644
--- a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
+++ b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
@@ -8,7 +8,7 @@ Required properties:
Example:
auart0: serial at 8006a000 {
- compatible = "fsl,imx28-auart", "fsl,imx23-auart";
+ compatible = "fsl,imx28-auart";
reg = <0x8006a000 0x2000>;
interrupts = <112 70 71>;
};
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index e16d631..6ed9215 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -795,7 +795,7 @@
};
auart0: serial at 8006a000 {
- compatible = "fsl,imx28-auart", "fsl,imx23-auart";
+ compatible = "fsl,imx28-auart";
reg = <0x8006a000 0x2000>;
interrupts = <112 70 71>;
clocks = <&clks 45>;
@@ -803,7 +803,7 @@
};
auart1: serial at 8006c000 {
- compatible = "fsl,imx28-auart", "fsl,imx23-auart";
+ compatible = "fsl,imx28-auart";
reg = <0x8006c000 0x2000>;
interrupts = <113 72 73>;
clocks = <&clks 45>;
@@ -811,7 +811,7 @@
};
auart2: serial at 8006e000 {
- compatible = "fsl,imx28-auart", "fsl,imx23-auart";
+ compatible = "fsl,imx28-auart";
reg = <0x8006e000 0x2000>;
interrupts = <114 74 75>;
clocks = <&clks 45>;
@@ -819,7 +819,7 @@
};
auart3: serial at 80070000 {
- compatible = "fsl,imx28-auart", "fsl,imx23-auart";
+ compatible = "fsl,imx28-auart";
reg = <0x80070000 0x2000>;
interrupts = <115 76 77>;
clocks = <&clks 45>;
@@ -827,7 +827,7 @@
};
auart4: serial at 80072000 {
- compatible = "fsl,imx28-auart", "fsl,imx23-auart";
+ compatible = "fsl,imx28-auart";
reg = <0x80072000 0x2000>;
interrupts = <116 78 79>;
clocks = <&clks 45>;
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 6db3baa..cd9ec1d 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -37,6 +37,11 @@
#include <asm/cacheflush.h>
+/* Use the platform_id to distinguish different Archs. */
+#define IS_MX23 0x0
+#define IS_MX28 0x1
+#define AUART_IS_MX23(x) ((x)->pdev->id_entry->driver_data == IS_MX23)
+
#define MXS_AUART_PORTS 5
#define AUART_CTRL0 0x00000000
@@ -124,6 +129,7 @@ struct mxs_auart_port {
struct clk *clk;
struct device *dev;
+ struct platform_device *pdev;
};
static void mxs_auart_stop_tx(struct uart_port *u);
@@ -680,6 +686,19 @@ static struct uart_driver auart_driver = {
#endif
};
+static const struct platform_device_id auart_ids[] = {
+ { .name = "imx23-auart", .driver_data = IS_MX23, },
+ { .name = "imx28-auart", .driver_data = IS_MX28, },
+ {},
+};
+
+static struct of_device_id mxs_auart_dt_ids[] = {
+ { .compatible = "fsl,imx23-auart", .data = (void *)&auart_ids[0] },
+ { .compatible = "fsl,imx28-auart", .data = (void *)&auart_ids[1] },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mxs_auart_dt_ids);
+
/*
* This function returns 1 if pdev isn't a device instatiated by dt, 0 if it
* could successfully get all information from dt or a negative errno.
@@ -701,6 +720,8 @@ static int serial_mxs_probe_dt(struct mxs_auart_port *s,
}
s->port.line = ret;
+ pdev->id_entry = of_match_device(mxs_auart_dt_ids, &pdev->dev)->data;
+
return 0;
}
@@ -753,6 +774,7 @@ static int __devinit mxs_auart_probe(struct platform_device *pdev)
s->flags = 0;
s->ctrl = 0;
+ s->pdev = pdev;
s->irq = platform_get_irq(pdev, 0);
s->port.irq = s->irq;
@@ -805,12 +827,6 @@ static int __devexit mxs_auart_remove(struct platform_device *pdev)
return 0;
}
-static struct of_device_id mxs_auart_dt_ids[] = {
- { .compatible = "fsl,imx23-auart", },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, mxs_auart_dt_ids);
-
static struct platform_driver mxs_auart_driver = {
.probe = mxs_auart_probe,
.remove = __devexit_p(mxs_auart_remove),
--
1.7.0.4
^ permalink raw reply related
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