* [PATCH 5/7] ARM: EXYNOS4: Add support external GIC
From: Will Deacon @ 2011-10-07 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E8ECA1B.5010005@arm.com>
Hi Marc,
On Fri, Oct 07, 2011 at 10:44:59AM +0100, Marc Zyngier wrote:
> So to make my suggestion completely clear, here's a patch I'm now
> carrying in my tree. It's only been test compiled on EXYNOS4, but works
> nicely on my 11MP. It turns both dist_base and cpu_base into per-cpu
> variables, removes these callbacks, removes your private copy of
> gic_cpu_init, and makes struct gic_chip_data private again.
>
> What do you think?
This looks like the right sort of idea, although I'm deeply suspicious about
per-cpu base addresses for the GIC distributor. It would be nice if the
Samsung guys can elaborate on what's going on here. Few comments inline.
> Subject: [PATCH] ARM: gic: allow GIC to support non-banked setups
>
> The GIC support code is heavily using the fact that hardware
> implementations are exposing banked registers. Unfortunately, it
> looks like at least one GIC implementation (EXYNOS4) offers both
> the distributor and the CPU interfaces at different addresses,
> depending on the CPU.
>
> This problem is solved by turning the distributor and CPU interface
> addresses into per-cpu variables. The EXYNOS4 code is updated not
> to mess with the GIC internals while handling interrupts, and
> struct gic_chip_data is back to being private.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm/common/gic.c | 76 +++++++++++++++++++++++++++--------
> arch/arm/include/asm/hardware/gic.h | 17 +------
> arch/arm/mach-exynos4/cpu.c | 14 ------
> arch/arm/mach-exynos4/platsmp.c | 28 ++-----------
> 4 files changed, 66 insertions(+), 69 deletions(-)
>
> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> index b574931..c7521dd 100644
> --- a/arch/arm/common/gic.c
> +++ b/arch/arm/common/gic.c
> @@ -37,6 +37,20 @@
> #include <asm/mach/irq.h>
> #include <asm/hardware/gic.h>
>
> +struct gic_chip_data {
> + unsigned int irq_offset;
> + void __percpu __iomem **dist_base;
> + void __percpu __iomem **cpu_base;
> +#ifdef CONFIG_CPU_PM
> + u32 saved_spi_enable[DIV_ROUND_UP(1020, 32)];
> + u32 saved_spi_conf[DIV_ROUND_UP(1020, 16)];
> + u32 saved_spi_target[DIV_ROUND_UP(1020, 4)];
> + u32 __percpu *saved_ppi_enable;
> + u32 __percpu *saved_ppi_conf;
> +#endif
> + unsigned int gic_irqs;
> +};
I think you can use DECLARE_PER_CPU(void __iomem *dist_base) etc. instead.
> +static inline void __iomem *gic_data_dist_base(struct gic_chip_data *data)
> +{
> + return *__this_cpu_ptr(data->dist_base);
> +}
Then you can use __get_cpu_var here (same applies throughout).
> +static void __cpuinit exynos4_secondary_init(unsigned int cpu)
> {
> void __iomem *dist_base = S5P_VA_GIC_DIST +
> - (gic_bank_offset * smp_processor_id());
> + (gic_bank_offset * cpu_logical_map(cpu));
Again, I'm deeply suspicious of this code :) Is there not a common memory
alias for the distributor across all of the CPUs?
Will
^ permalink raw reply
* [PATCH v2] ARM: tegra: fix compilation error due to mach/hardware.h removal
From: Olof Johansson @ 2011-10-07 15:31 UTC (permalink / raw)
To: linux-arm-kernel
From: Marc Dietrich <marvin24@gmx.de>
This fixes a compilation error in cpu-tegra.c which was introduced in
dc8d966bc (ARM: convert PCI defines to variables) which removed the now
obsolete mach/hardware.h from the mach-tegra subtree.
Signed-off-by: Marc Dietrich <marvin24@gmx.de>
Signed-off-by: Olof Johansson <olof@lixom.net>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
---
v2: Added patch subject of introducing commit
Linus, last minute build fix. Not sure of Arnd is planning another merge
before release so sending directly.
arch/arm/mach-tegra/cpu-tegra.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-tegra/cpu-tegra.c b/arch/arm/mach-tegra/cpu-tegra.c
index 0e1016a..0e0fd4d 100644
--- a/arch/arm/mach-tegra/cpu-tegra.c
+++ b/arch/arm/mach-tegra/cpu-tegra.c
@@ -32,7 +32,6 @@
#include <asm/system.h>
-#include <mach/hardware.h>
#include <mach/clk.h>
/* Frequency table index must be sequential starting at 0 */
--
1.7.4.1
^ permalink raw reply related
* [RFC/PATCH 2/7] ARM: ARM11 MPCore: pte_alloc_one{, _kernel} are not preempt safe
From: George G. Davis @ 2011-10-07 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111007074707.GD21464@n2100.arm.linux.org.uk>
On Oct 7, 2011, at 3:47 AM, Russell King - ARM Linux wrote:
> On Thu, Oct 06, 2011 at 10:38:36PM -0400, gdavis at mvista.com wrote:
>> -#define PGALLOC_GFP (GFP_KERNEL | __GFP_NOTRACK | __GFP_REPEAT | __GFP_ZERO)
>> +#define PGALLOC_GFP (GFP_KERNEL | __GFP_NOTRACK | __GFP_REPEAT)
>> @@ -81,8 +88,14 @@ pte_alloc_one(struct mm_struct *mm, unsigned long addr)
>> pte = alloc_pages(PGALLOC_GFP, 0);
>> #endif
>> if (pte) {
>> + void *p = page_address(pte);
>> + if (cache_ops_need_broadcast())
>> + preempt_disable();
>> + memset(p, 0, PAGE_SIZE);
>> if (!PageHighMem(pte))
>> - clean_pte_table(page_address(pte));
>> + clean_pte_table(p);
>> + if (cache_ops_need_broadcast())
>> + preempt_enable();
>
> This won't work - page_address(pte) will be NULL for highmem pages, and
> so will cause an oops, and removing the __GFP_ZERO will mean that highmem
> pages will not be zeroed, meaning that such page tables will not have been
> initialized.
Yep, I had a feeling that it was not going to work correctly for the HIGHMEM case.
Alas, I'm not using HIGHMEM so I did not see the issue in my testing. I'll respin it to fix
HIGHMEM breakage.
Thanks!
--
Regards,
George
^ permalink raw reply
* [GIT PULL] ux500-timers
From: Arnd Bergmann @ 2011-10-07 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbY7CL8h-qbZoKdgSiPrfHJ25BM61rwnuA3iJSdy5VC5g@mail.gmail.com>
On Friday 07 October 2011, Linus Walleij wrote:
> On Mon, Oct 3, 2011 at 9:41 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> > Hi Arnd,
> >
> > could you please pull the updated ux500 timer branch into the arm-soc
> > tree?
> >
> > The following changes since commit d93dc5c4478c1fd5de85a3e8aece9aad7bbae044:
> >
> > Linux 3.1-rc7 (2011-09-21 16:58:15 -0700)
> >
> > are available in the git repository at:
> > git://git.linaro.org/people/triad/linux-stericsson.git ux500-nomadik-timers
>
> Ping on this, note fixup patch at the end of the series, as requested.
Pulled now, sorry for the delay.
Arnd
^ permalink raw reply
* [PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file
From: Barry Song @ 2011-10-07 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111006175818.GB9886@atrey.karlin.mff.cuni.cz>
2011/10/7 Pavel Machek <pavel@ucw.cz>:
>> 2011/9/29 Luca Tettamanti <kronos.it@gmail.com>:
>> > On Thu, Sep 29, 2011 at 11:29 AM, Barry Song <Barry.Song@csr.com> wrote:
>> >> From: Barry Song <baohua.song@csr.com>
>> >>
>> >> Some devices like mmc are async detected very slow. For example,
>> >> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
>> >> mmc partitions then add disk.
>> >>
>> >> we do have wait_for_device_probe and scsi_complete_async_scans
>> >> before calling swsusp_check, but it is not enough to wait mmc.
>> >>
>> >> This patch adds resumewait kernel param just like rootwait so
>> >> that we have enough time to wait mmc ready. The differene is
>> >> here we wait for resume partition but rootwait waits for rootfs
>> >> partition.
>> >
>> > I assume that such a device would need "rootwait" to boot in the first
>> > place; why don't you "overload" the param to also enable waiting in
>> > the resume path?
>>
>> not real. for an embedded product, the type of the rootfs, the place
>> of the rootfs ?and the way to mount rootfs are pretty flexible.
>> even though both rootfs and resume file use mmc, they will be in
>> different partitions at least. so i don't think rootwait can overload
>> resumewait.
>
> It would be good to at least model it the same way. rootdelay allows
> you to specify time, which is important for USB devices...
actually i considered resumedelay before i sent this resumewait patch.
now resumedelay is not an indispensable feature to my application and
most other systems since they are able to wait for the swap devices
ready by resumewait.
but of course we can have the resumedelay param as well just like
rootdelay. since Rafael has applied this resumedelay patch, i can
treat resumedelay as one new seperate patch.
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
-barry
^ permalink raw reply
* [PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file
From: Barry Song @ 2011-10-07 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4wfpsTMEhs_-N1itXcJB03nvdfyjj+ksWG5g9YRB6Trgw@mail.gmail.com>
2011/10/7 Barry Song <21cnbao@gmail.com>:
> 2011/10/7 Pavel Machek <pavel@ucw.cz>:
>>> 2011/9/29 Luca Tettamanti <kronos.it@gmail.com>:
>>> > On Thu, Sep 29, 2011 at 11:29 AM, Barry Song <Barry.Song@csr.com> wrote:
>>> >> From: Barry Song <baohua.song@csr.com>
>>> >>
>>> >> Some devices like mmc are async detected very slow. For example,
>>> >> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
>>> >> mmc partitions then add disk.
>>> >>
>>> >> we do have wait_for_device_probe and scsi_complete_async_scans
>>> >> before calling swsusp_check, but it is not enough to wait mmc.
>>> >>
>>> >> This patch adds resumewait kernel param just like rootwait so
>>> >> that we have enough time to wait mmc ready. The differene is
>>> >> here we wait for resume partition but rootwait waits for rootfs
>>> >> partition.
>>> >
>>> > I assume that such a device would need "rootwait" to boot in the first
>>> > place; why don't you "overload" the param to also enable waiting in
>>> > the resume path?
>>>
>>> not real. for an embedded product, the type of the rootfs, the place
>>> of the rootfs ?and the way to mount rootfs are pretty flexible.
>>> even though both rootfs and resume file use mmc, they will be in
>>> different partitions at least. so i don't think rootwait can overload
>>> resumewait.
>>
>> It would be good to at least model it the same way. rootdelay allows
>> you to specify time, which is important for USB devices...
>
> actually i considered resumedelay before i sent this resumewait patch.
> now resumedelay is not an indispensable feature to my application and
> most other systems since they are able to wait for the swap devices
> ready by resumewait.
> but of course we can have the resumedelay param as well just like
> rootdelay. since Rafael has applied this resumedelay patch, ?i can
sorry for typo. -> since Rafael has applied this *resumewait* patch
> treat resumedelay as one new seperate patch.
>
>>
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>>
> -barry
>
^ permalink raw reply
* [PATCH 0/1] A trio of IXP425 boards
From: Arnd Bergmann @ 2011-10-07 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111007061918.GA2229@netboy.at.omicron.at>
On Friday 07 October 2011, Richard Cochran wrote:
> On Wed, Oct 05, 2011 at 03:00:01PM +0200, Krzysztof Halasa wrote:
> > Richard Cochran <richardcochran@gmail.com> writes:
> >
> > > This patch adds support for three boards using the ixp425. Since they
> > > are are almost identical to each other, they can share one setup file.
> > >
> > > The three machine types are slated for removal due to the fact that
> > > the board support has not been merged. My polite request is to merge
> > > this patch and restore the machine types.
> >
> > This is a good idea, IMHO.
> > Acked-by: Krzysztof Ha?asa <khc@pm.waw.pl>
> >
> > Unfortunately ATM I don't have access to kernel.org and being a bit
> > busy with unrelated things, I'd rather avoid "processing" this patch
> > personally if possible. Can you send it upstream yourself, please?
> > Let me know of any problem.
>
> Okay, then, Arnd? Russell?
>
> Will one of you please take this patch?
Sorry I forgot to notify you. I had already taken the patch on monday,
but it did not show up in linux-next because an unrelated change broke
the build. It should be fixed now.
Arnd
^ permalink raw reply
* ARM SoC tree: OMAP PM dependency on tip irq/core
From: Arnd Bergmann @ 2011-10-07 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111006195945.GQ6324@atomide.com>
On Thursday 06 October 2011, Tony Lindgren wrote:
> * Rob Herring <robherring2@gmail.com> [111001 13:21]:
> > On 09/30/2011 05:29 PM, Kevin Hilman wrote:
> > > Hi Arnd,
> > >
> > > Kevin Hilman <khilman@ti.com> writes:
> > >
> > >> The upcoming OMAP4 PM series from Santosh[1] that we're planning to
> > >> queue for v3.2 has a dependency[2] on a patch currently queued for v3.2
> > >> in the irq/core branch of Thomas' tip tree[3].
> > >>
> > >> In the past, I noticed you merged external trees like this to solve
> > >> dependencies.
> > >>
> > >> Could you pull the irq/core branch into your tree to meet this
> > >> dependency?
> > >
> > > On second thought, since Santosh's branch is the only one with this
> > > dependency (and we also have a dependency on Russell's devel-stable)
> > > I'll just build up a branch for Santosh's series that includes
> > > rmk/devel-stable and tglx/irq-core.
> > >
> >
> > Any new platforms will have a dependency on rmk/devel-stable with the
> > mach header clean-up. I'll probably have a dependency on tglx's tree as
> > well.
>
> Sounds like Arnd should pull this into some branch then.
I've pulled in rmk/devel-stable as a dependency now, thanks for
reminding me of that.
Thomas, where should I get the irq-core branch (or whichever
I should wait for) to pull in as another dependency. Is that
branch one that never gets rebased?
Arnd
^ permalink raw reply
* [RFC/PATCH v3 0/7] ARM11 MPCore: preemption/task migration cache coherency fixups
From: gdavis at mvista.com @ 2011-10-07 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317955121-28047-1-git-send-email-gdavis@mvista.com>
Greetings,
On ARM11 MPCore, the "SCU does not handle coherency consequences of CP15
cache operations" [1]. ?So cache maintenance functions have to insure
that memory is globally consistent. ?Although the current Linux kernel
works reasonably well on ARM11 MPCore machines, PREEMPT stress testing,
e.g. parallel module loading and hackbench, results in crashes which
exhibit non-sense oops traces where machine state does not make sense
relative to the code executing at the time of the oops.
Review and analysis of the various ARM11 MPCore cache maintenance
functions reveal that there are a number critical sections in which
ARM11 MPCore caches and/or memory may become inconsistent, i.e. a
cache line on CPU A contains a modified entry but preemption and task
migration occurs after which the same cache line is cleaned/flushed
on CPU B. ?This can obviously lead to inconsistent memory and/or
cache state as cache ops on ARM11 MPCore are non-coherent.
The following is a partial series of ARM11 MPCore preemption/task
migration fixes to resolve cache coherency problems on these machines:
George G. Davis (6):
ARM: ARM11 MPCore: pte_alloc_one{,_kernel} are not preempt safe
ARM: ARM11 MPCore: {clean,flush}_pmd_entry are not preempt safe
ARM: ARM11 MPCore: clean_dcache_area is not preempt safe
ARM: Move get_thread_info macro definition to <asm/assembler.h>
ARM: ARM11 MPCore: DMA_CACHE_RWFO operations are not preempt safe
ARM: ARM11 MPCore: cpu_v6_set_pte_ext is not preempt safe
Konstantin Baidarov (1):
ARM: ARM11 MPCore: pgd_alloc is not preempt safe
arch/arm/include/asm/assembler.h | 13 +++++++++++++
arch/arm/include/asm/pgalloc.h | 28 +++++++++++++++++++++++-----
arch/arm/include/asm/pgtable.h | 9 +++++++++
arch/arm/include/asm/smp_plat.h | 2 ++
arch/arm/kernel/entry-header.S | 11 -----------
arch/arm/mm/cache-v6.S | 27 +++++++++++++++++++++++++++
arch/arm/mm/idmap.c | 5 +++++
arch/arm/mm/ioremap.c | 9 +++++++++
arch/arm/mm/mmu.c | 12 ++++++++++++
arch/arm/mm/pgd.c | 7 +++++++
arch/arm/mm/proc-v6.S | 11 +++++++++++
arch/arm/plat-omap/iommu.c | 10 ++++++++++
arch/arm/vfp/entry.S | 5 ++++-
arch/arm/vfp/vfphw.S | 5 ++++-
14 files changed, 136 insertions(+), 18 deletions(-)
ChangeLog:
V2:
- Substitute {get,put}_cpu() with preempt_{disable,enable}().
- Fixed preempt {dis,en}able assembler code sequences to not
use r11 since it is reserved for frame pointer use. Also
optimised these sequences to use r2, r3; ip scratch registers
in most cases to eliminate stack push/pop. In one case,
cpu_v6_set_pte_ext, there are only two scratch registers
available, r3 and ip. However, both of these are used within
the armv6_set_pte_ext macro. So for this case, r3 is used
as a temporary scratch when disabling preemption and r4 and
r5 are pushed/popped as needed for other uses to avoid
conflict with scratch register usage in armv6_set_pte_ext.
- Remove incorrect use of ALT_SMP macros in cpu_v6_set_pte_ext,
making the preempt {dis,en}able assembler code sequences
compile time dependent upon CONFIG_SMP instead. This code
is safe on UP machines anyway.
V3:
- Fix HIGHMEM breakage.
The above changes are among the "low hanging fruit" where the
workarounds are relatively low impact from a performance and/or
implementation effort perspective. ?I'm still working on fixes
for the harder problems. ?Also, I believe that Catalin's "ARM: Allow
lazy cache flushing on ARM11MPCore" [2][3] is required for ARM11
MPCore machines and would like to see that or similar/alternative
solution applied.
Comments/feedback greatly appreciated.
TIA!
--
Regards,
George
[1] http://infocenter.arm.com/help/topic/com.arm.doc.dai0228a/index.html#arm_toc9
[2] http://www.spinics.net/lists/arm-kernel/msg129403.html
[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2010-May/014990.html
^ permalink raw reply
* [RFC/PATCH v3 1/7] ARM: ARM11 MPCore: pgd_alloc is not preempt safe
From: gdavis at mvista.com @ 2011-10-07 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318004800-6525-1-git-send-email-gdavis@mvista.com>
From: Konstantin Baidarov <kbaidarov@mvista.com>
If preemption and subsequent task migration occurs during a call to
pgd_alloc on ARM11 MPCore machines, global memory state can become
inconsistent. To prevent inconsistent memory state on these
machines, disable preemption around initialization and flushing
of new PGDs.
Signed-off-by: Konstantin Baidarov <kbaidarov@mvista.com>
Signed-off-by: George G. Davis <gdavis@mvista.com>
---
arch/arm/mm/pgd.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mm/pgd.c b/arch/arm/mm/pgd.c
index b2027c1..e608981 100644
--- a/arch/arm/mm/pgd.c
+++ b/arch/arm/mm/pgd.c
@@ -14,6 +14,7 @@
#include <asm/pgalloc.h>
#include <asm/page.h>
#include <asm/tlbflush.h>
+#include <asm/smp_plat.h>
#include "mm.h"
@@ -31,6 +32,9 @@ pgd_t *pgd_alloc(struct mm_struct *mm)
if (!new_pgd)
goto no_pgd;
+ if (cache_ops_need_broadcast())
+ preempt_disable();
+
memset(new_pgd, 0, USER_PTRS_PER_PGD * sizeof(pgd_t));
/*
@@ -42,6 +46,9 @@ pgd_t *pgd_alloc(struct mm_struct *mm)
clean_dcache_area(new_pgd, PTRS_PER_PGD * sizeof(pgd_t));
+ if (cache_ops_need_broadcast())
+ preempt_enable();
+
if (!vectors_high()) {
/*
* On ARM, first page must always be allocated since it
--
1.7.4.4
^ permalink raw reply related
* [RFC/PATCH v3 2/7] ARM: ARM11 MPCore: pte_alloc_one{, _kernel} are not preempt safe
From: gdavis at mvista.com @ 2011-10-07 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318004800-6525-1-git-send-email-gdavis@mvista.com>
From: George G. Davis <gdavis@mvista.com>
If preemption and subsequent task migration occurs during a call to
pte_alloc_one{,_kernel} on ARM11 MPCore machines, global memory state
can become inconsistent. To prevent inconsistent memory state on
these machines, disable preemption around initialization and flushing
of new PTEs.
Signed-off-by: George G. Davis <gdavis@mvista.com>
---
arch/arm/include/asm/pgalloc.h | 24 +++++++++++++++++++-----
1 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/pgalloc.h b/arch/arm/include/asm/pgalloc.h
index 22de005..92d3f27 100644
--- a/arch/arm/include/asm/pgalloc.h
+++ b/arch/arm/include/asm/pgalloc.h
@@ -17,6 +17,7 @@
#include <asm/processor.h>
#include <asm/cacheflush.h>
#include <asm/tlbflush.h>
+#include <asm/smp_plat.h>
#define check_pgt_cache() do { } while (0)
@@ -35,7 +36,7 @@
extern pgd_t *pgd_alloc(struct mm_struct *mm);
extern void pgd_free(struct mm_struct *mm, pgd_t *pgd);
-#define PGALLOC_GFP (GFP_KERNEL | __GFP_NOTRACK | __GFP_REPEAT | __GFP_ZERO)
+#define PGALLOC_GFP (GFP_KERNEL | __GFP_NOTRACK | __GFP_REPEAT)
static inline void clean_pte_table(pte_t *pte)
{
@@ -64,8 +65,14 @@ pte_alloc_one_kernel(struct mm_struct *mm, unsigned long addr)
pte_t *pte;
pte = (pte_t *)__get_free_page(PGALLOC_GFP);
- if (pte)
+ if (pte) {
+ if (cache_ops_need_broadcast())
+ preempt_disable();
+ memset(pte, 0, PAGE_SIZE);
clean_pte_table(pte);
+ if (cache_ops_need_broadcast())
+ preempt_enable();
+ }
return pte;
}
@@ -76,13 +83,20 @@ pte_alloc_one(struct mm_struct *mm, unsigned long addr)
struct page *pte;
#ifdef CONFIG_HIGHPTE
- pte = alloc_pages(PGALLOC_GFP | __GFP_HIGHMEM, 0);
+ pte = alloc_pages(PGALLOC_GFP | __GFP_ZERO | __GFP_HIGHMEM, 0);
#else
pte = alloc_pages(PGALLOC_GFP, 0);
#endif
if (pte) {
- if (!PageHighMem(pte))
- clean_pte_table(page_address(pte));
+ if (!PageHighMem(pte)) {
+ void *page = page_address(pte);
+ if (cache_ops_need_broadcast())
+ preempt_disable();
+ memset(page, 0, PAGE_SIZE);
+ clean_pte_table(page);
+ if (cache_ops_need_broadcast())
+ preempt_enable();
+ }
pgtable_page_ctor(pte);
}
--
1.7.4.4
^ permalink raw reply related
* [RFC/PATCH v3 3/7] ARM: ARM11 MPCore: {clean, flush}_pmd_entry are not preempt safe
From: gdavis at mvista.com @ 2011-10-07 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318004800-6525-1-git-send-email-gdavis@mvista.com>
From: George G. Davis <gdavis@mvista.com>
If preemption and subsequent task migration occurs during calls to
{clean,flush}_pmd_entry on ARM11 MPCore machines, global memory state
can become inconsistent. To prevent inconsistent memory state on
these machines, disable preemption in callers of these functions around
PMD modifications and subsequent {clean,flush}_pmd_entry calls.
Signed-off-by: George G. Davis <gdavis@mvista.com>
---
arch/arm/include/asm/pgalloc.h | 4 ++++
arch/arm/include/asm/pgtable.h | 9 +++++++++
arch/arm/include/asm/smp_plat.h | 2 ++
arch/arm/mm/idmap.c | 5 +++++
arch/arm/mm/ioremap.c | 9 +++++++++
arch/arm/mm/mmu.c | 12 ++++++++++++
6 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/pgalloc.h b/arch/arm/include/asm/pgalloc.h
index 92d3f27..ba8cf6a 100644
--- a/arch/arm/include/asm/pgalloc.h
+++ b/arch/arm/include/asm/pgalloc.h
@@ -122,9 +122,13 @@ static inline void __pmd_populate(pmd_t *pmdp, phys_addr_t pte,
unsigned long prot)
{
unsigned long pmdval = (pte + PTE_HWTABLE_OFF) | prot;
+ if (cache_ops_need_broadcast())
+ preempt_disable();
pmdp[0] = __pmd(pmdval);
pmdp[1] = __pmd(pmdval + 256 * sizeof(pte_t));
flush_pmd_entry(pmdp);
+ if (cache_ops_need_broadcast())
+ preempt_enable();
}
/*
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 5750704..00068dc 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -13,6 +13,7 @@
#include <linux/const.h>
#include <asm-generic/4level-fixup.h>
#include <asm/proc-fns.h>
+#include <asm/smp_plat.h>
#ifndef CONFIG_MMU
@@ -313,16 +314,24 @@ extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
#define copy_pmd(pmdpd,pmdps) \
do { \
+ if (cache_ops_need_broadcast()) \
+ preempt_disable(); \
pmdpd[0] = pmdps[0]; \
pmdpd[1] = pmdps[1]; \
flush_pmd_entry(pmdpd); \
+ if (cache_ops_need_broadcast()) \
+ preempt_enable(); \
} while (0)
#define pmd_clear(pmdp) \
do { \
+ if (cache_ops_need_broadcast()) \
+ preempt_disable(); \
pmdp[0] = __pmd(0); \
pmdp[1] = __pmd(0); \
clean_pmd_entry(pmdp); \
+ if (cache_ops_need_broadcast()) \
+ preempt_enable(); \
} while (0)
static inline pte_t *pmd_page_vaddr(pmd_t pmd)
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index f24c1b9..5a8d3df 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -5,6 +5,7 @@
#ifndef __ASMARM_SMP_PLAT_H
#define __ASMARM_SMP_PLAT_H
+#ifndef __ASSEMBLY__
#include <asm/cputype.h>
/*
@@ -42,5 +43,6 @@ static inline int cache_ops_need_broadcast(void)
return ((read_cpuid_ext(CPUID_EXT_MMFR3) >> 12) & 0xf) < 1;
}
#endif
+#endif
#endif
diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index 2be9139..c04face 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -3,17 +3,22 @@
#include <asm/cputype.h>
#include <asm/pgalloc.h>
#include <asm/pgtable.h>
+#include <asm/smp_plat.h>
static void idmap_add_pmd(pud_t *pud, unsigned long addr, unsigned long end,
unsigned long prot)
{
pmd_t *pmd = pmd_offset(pud, addr);
+ if (cache_ops_need_broadcast())
+ preempt_disable();
addr = (addr & PMD_MASK) | prot;
pmd[0] = __pmd(addr);
addr += SECTION_SIZE;
pmd[1] = __pmd(addr);
flush_pmd_entry(pmd);
+ if (cache_ops_need_broadcast())
+ preempt_enable();
}
static void idmap_add_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index ab50627..b56d78a 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -32,6 +32,7 @@
#include <asm/pgalloc.h>
#include <asm/tlbflush.h>
#include <asm/sizes.h>
+#include <asm/smp_plat.h>
#include <asm/mach/map.h>
#include "mm.h"
@@ -135,11 +136,15 @@ remap_area_sections(unsigned long virt, unsigned long pfn,
do {
pmd_t *pmd = pmd_offset(pgd, addr);
+ if (cache_ops_need_broadcast())
+ preempt_disable();
pmd[0] = __pmd(__pfn_to_phys(pfn) | type->prot_sect);
pfn += SZ_1M >> PAGE_SHIFT;
pmd[1] = __pmd(__pfn_to_phys(pfn) | type->prot_sect);
pfn += SZ_1M >> PAGE_SHIFT;
flush_pmd_entry(pmd);
+ if (cache_ops_need_broadcast())
+ preempt_enable();
addr += PGDIR_SIZE;
pgd++;
@@ -172,9 +177,13 @@ remap_area_supersections(unsigned long virt, unsigned long pfn,
for (i = 0; i < 8; i++) {
pmd_t *pmd = pmd_offset(pgd, addr);
+ if (cache_ops_need_broadcast())
+ preempt_disable();
pmd[0] = __pmd(super_pmd_val);
pmd[1] = __pmd(super_pmd_val);
flush_pmd_entry(pmd);
+ if (cache_ops_need_broadcast())
+ preempt_enable();
addr += PGDIR_SIZE;
pgd++;
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 594d677..3c8253f 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -567,12 +567,24 @@ static void __init alloc_init_section(pud_t *pud, unsigned long addr,
if (addr & SECTION_SIZE)
pmd++;
+ if (cache_ops_need_broadcast())
+ preempt_disable();
do {
*pmd = __pmd(phys | type->prot_sect);
phys += SECTION_SIZE;
} while (pmd++, addr += SECTION_SIZE, addr != end);
+ /* FIXME: Multiple PMD entries may be written above
+ * but only one cache line, up to 8 PMDs depending
+ * on the alignment of this mapping, is flushed below.
+ * IFF this mapping spans >8MiB, then only the first
+ * 8MiB worth of entries will be flushed. Entries
+ * above the 8MiB limit will not be flushed if I
+ * read this correctly.
+ */
flush_pmd_entry(p);
+ if (cache_ops_need_broadcast())
+ preempt_enable();
} else {
/*
* No need to loop; pte's aren't interested in the
--
1.7.4.4
^ permalink raw reply related
* [RFC/PATCH v3 4/7] ARM: ARM11 MPCore: clean_dcache_area is not preempt safe
From: gdavis at mvista.com @ 2011-10-07 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318004800-6525-1-git-send-email-gdavis@mvista.com>
From: George G. Davis <gdavis@mvista.com>
If preemption and subsequent task migration occurs during calls to
clean_dcache_area on ARM11 MPCore machines, global memory state
can become inconsistent. To prevent inconsistent memory state on
these machines, disable preemption in callers of these functions
around memory modifications and subsequent clean_dcache_area calls.
Signed-off-by: George G. Davis <gdavis@mvista.com>
---
arch/arm/plat-omap/iommu.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 34fc31e..59836d1 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -1014,8 +1014,12 @@ static int __devinit omap_iommu_probe(struct platform_device *pdev)
err = -ENOMEM;
goto err_pgd;
}
+ if (cache_ops_need_broadcast())
+ preempt_disable();
memset(p, 0, IOPGD_TABLE_SIZE);
clean_dcache_area(p, IOPGD_TABLE_SIZE);
+ if (cache_ops_need_broadcast())
+ preempt_enable();
obj->iopgd = p;
BUG_ON(!IS_ALIGNED((unsigned long)obj->iopgd, IOPGD_TABLE_SIZE));
@@ -1069,7 +1073,13 @@ static struct platform_driver omap_iommu_driver = {
static void iopte_cachep_ctor(void *iopte)
{
+ if (cache_ops_need_broadcast())
+ preempt_disable();
+ /* FIXME: This will not work on ARM11 MPCore.
+ */
clean_dcache_area(iopte, IOPTE_TABLE_SIZE);
+ if (cache_ops_need_broadcast())
+ preempt_enable();
}
static int __init omap_iommu_init(void)
--
1.7.4.4
^ permalink raw reply related
* [RFC/PATCH v3 5/7] ARM: Move get_thread_info macro definition to <asm/assembler.h>
From: gdavis at mvista.com @ 2011-10-07 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318004800-6525-1-git-send-email-gdavis@mvista.com>
From: George G. Davis <gdavis@mvista.com>
The get_thread_info assembler macro is currently defined in
arch/arm/kernel/entry-header.S and used in the following
files:
arch/arm/kernel/entry-armv.S
arch/arm/kernel/entry-common.S
arch/arm/vfp/vfphw.S
arch/arm/vfp/entry.S
The first two cases above use #include "entry-header.S" while
the later two cases use #include "../kernel/entry-header.S"
to obtain the get_thread_info assembler macro definition.
Move the get_thread_info assembler macro definition into
arch/arm/include/asm/assember.h and clean up inclusion
of this macro definition to use #include <asm/assember.h>.
This change facilitates use of the get_thread_info assembler
macro in other assembler functions without more of the same
path relative include directives.
Signed-off-by: George G. Davis <gdavis@mvista.com>
---
arch/arm/include/asm/assembler.h | 13 +++++++++++++
| 11 -----------
arch/arm/vfp/entry.S | 5 ++++-
arch/arm/vfp/vfphw.S | 5 ++++-
4 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 29035e8..78397d0 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -23,6 +23,19 @@
#include <asm/ptrace.h>
#include <asm/domain.h>
+#ifndef CONFIG_THUMB2_KERNEL
+ .macro get_thread_info, rd
+ mov \rd, sp, lsr #13
+ mov \rd, \rd, lsl #13
+ .endm
+#else /* CONFIG_THUMB2_KERNEL */
+ .macro get_thread_info, rd
+ mov \rd, sp
+ lsr \rd, \rd, #13
+ mov \rd, \rd, lsl #13
+ .endm
+#endif /* !CONFIG_THUMB2_KERNEL */
+
/*
* Endian independent macros for shifting bytes within registers.
*/
--git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S
index 9a8531e..d03b6a9 100644
--- a/arch/arm/kernel/entry-header.S
+++ b/arch/arm/kernel/entry-header.S
@@ -108,11 +108,6 @@
movs pc, lr @ return & move spsr_svc into cpsr
.endm
- .macro get_thread_info, rd
- mov \rd, sp, lsr #13
- mov \rd, \rd, lsl #13
- .endm
-
@
@ 32-bit wide "mov pc, reg"
@
@@ -148,12 +143,6 @@
movs pc, lr @ return & move spsr_svc into cpsr
.endm
- .macro get_thread_info, rd
- mov \rd, sp
- lsr \rd, \rd, #13
- mov \rd, \rd, lsl #13
- .endm
-
@
@ 32-bit wide "mov pc, reg"
@
diff --git a/arch/arm/vfp/entry.S b/arch/arm/vfp/entry.S
index 4fa9903..e475a5a 100644
--- a/arch/arm/vfp/entry.S
+++ b/arch/arm/vfp/entry.S
@@ -15,9 +15,12 @@
* r10 = thread_info structure
* lr = failure return
*/
+#include <linux/init.h>
+#include <linux/linkage.h>
#include <asm/thread_info.h>
#include <asm/vfpmacros.h>
-#include "../kernel/entry-header.S"
+#include <asm/assembler.h>
+#include <asm/asm-offsets.h>
ENTRY(do_vfp)
#ifdef CONFIG_PREEMPT
diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
index 2d30c7f..68ca5af 100644
--- a/arch/arm/vfp/vfphw.S
+++ b/arch/arm/vfp/vfphw.S
@@ -14,9 +14,12 @@
* r10 points at the start of the private FP workspace in the thread structure
* sp points to a struct pt_regs (as defined in include/asm/proc/ptrace.h)
*/
+#include <linux/init.h>
+#include <linux/linkage.h>
#include <asm/thread_info.h>
#include <asm/vfpmacros.h>
-#include "../kernel/entry-header.S"
+#include <asm/assembler.h>
+#include <asm/asm-offsets.h>
.macro DBGSTR, str
#ifdef DEBUG
--
1.7.4.4
^ permalink raw reply related
* [RFC/PATCH v3 6/7] ARM: ARM11 MPCore: DMA_CACHE_RWFO operations are not preempt safe
From: gdavis at mvista.com @ 2011-10-07 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318004800-6525-1-git-send-email-gdavis@mvista.com>
From: George G. Davis <gdavis@mvista.com>
The DMA_CACHE_RWFO operations are not preempt safe. If preemption
occurs immediately following a RWFO operation on a cache line of
CPU A, it is possible for task migration to occur on resume at
which point the subsequent cache maintenance operation on the
same cache line of CPU B will have no affect on the CPU A cache
line leading to inconsistent memory and/or cache state. To prevent
this, disable preemption during RWFO operations.
This change depends on "ARM: Move get_thread_info macro definition
to <asm/assembler.h>".
Signed-off-by: George G. Davis <gdavis@mvista.com>
---
arch/arm/mm/cache-v6.S | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mm/cache-v6.S b/arch/arm/mm/cache-v6.S
index 74c2e5a..9c44752 100644
--- a/arch/arm/mm/cache-v6.S
+++ b/arch/arm/mm/cache-v6.S
@@ -205,6 +205,12 @@ ENTRY(v6_flush_kern_dcache_area)
*/
v6_dma_inv_range:
#ifdef CONFIG_DMA_CACHE_RWFO
+#ifdef CONFIG_PREEMPT
+ get_thread_info ip
+ ldr r3, [ip, #TI_PREEMPT] @ get preempt count
+ add r2, r3, #1 @ increment it
+ str r2, [ip, #TI_PREEMPT] @ disable preempt
+#endif
ldrb r2, [r0] @ read for ownership
strb r2, [r0] @ write for ownership
#endif
@@ -241,6 +247,9 @@ v6_dma_inv_range:
blo 1b
mov r0, #0
mcr p15, 0, r0, c7, c10, 4 @ drain write buffer
+#if defined(CONFIG_DMA_CACHE_RWFO) && defined(CONFIG_PREEMPT)
+ str r3, [ip, #TI_PREEMPT] @ restore preempt count
+#endif
mov pc, lr
/*
@@ -249,6 +258,12 @@ v6_dma_inv_range:
* - end - virtual end address of region
*/
v6_dma_clean_range:
+#if defined(CONFIG_DMA_CACHE_RWFO) && defined(CONFIG_PREEMPT)
+ get_thread_info ip
+ ldr r3, [ip, #TI_PREEMPT] @ get preempt count
+ add r2, r3, #1 @ increment it
+ str r2, [ip, #TI_PREEMPT] @ disable preempt
+#endif
bic r0, r0, #D_CACHE_LINE_SIZE - 1
1:
#ifdef CONFIG_DMA_CACHE_RWFO
@@ -264,6 +279,9 @@ v6_dma_clean_range:
blo 1b
mov r0, #0
mcr p15, 0, r0, c7, c10, 4 @ drain write buffer
+#if defined(CONFIG_DMA_CACHE_RWFO) && defined(CONFIG_PREEMPT)
+ str r3, [ip, #TI_PREEMPT] @ restore preempt count
+#endif
mov pc, lr
/*
@@ -273,6 +291,12 @@ v6_dma_clean_range:
*/
ENTRY(v6_dma_flush_range)
#ifdef CONFIG_DMA_CACHE_RWFO
+#ifdef CONFIG_PREEMPT
+ get_thread_info ip
+ ldr r3, [ip, #TI_PREEMPT] @ get preempt count
+ add r2, r3, #1 @ increment it
+ str r2, [ip, #TI_PREEMPT] @ disable preempt
+#endif
ldrb r2, [r0] @ read for ownership
strb r2, [r0] @ write for ownership
#endif
@@ -292,6 +316,9 @@ ENTRY(v6_dma_flush_range)
blo 1b
mov r0, #0
mcr p15, 0, r0, c7, c10, 4 @ drain write buffer
+#if defined(CONFIG_DMA_CACHE_RWFO) && defined(CONFIG_PREEMPT)
+ str r3, [ip, #TI_PREEMPT] @ restore preempt count
+#endif
mov pc, lr
/*
--
1.7.4.4
^ permalink raw reply related
* [RFC/PATCH v3 7/7] ARM: ARM11 MPCore: cpu_v6_set_pte_ext is not preempt safe
From: gdavis at mvista.com @ 2011-10-07 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318004800-6525-1-git-send-email-gdavis@mvista.com>
From: George G. Davis <gdavis@mvista.com>
If preemption and subsequent task migration occurs during calls to
cpu_v6_set_pte_ext on ARM11 MPCore machines, global memory state
can become inconsistent. To prevent inconsistent memory state on
these machines, disable preemption in cpu_v6_set_pte_ext.
This change depends on "ARM: Move get_thread_info macro definition
to <asm/assembler.h>".
Signed-off-by: George G. Davis <gdavis@mvista.com>
---
arch/arm/mm/proc-v6.S | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mm/proc-v6.S b/arch/arm/mm/proc-v6.S
index a923aa0..57b359d 100644
--- a/arch/arm/mm/proc-v6.S
+++ b/arch/arm/mm/proc-v6.S
@@ -122,7 +122,18 @@ ENTRY(cpu_v6_switch_mm)
ENTRY(cpu_v6_set_pte_ext)
#ifdef CONFIG_MMU
+#if defined(CONFIG_SMP) && defined(CONFIG_PREEMPT)
+ stmdb sp!, {r4, r5}
+ get_thread_info r5
+ ldr r4, [r5, #TI_PREEMPT] @ get preempt count
+ add r3, r4, #1 @ increment it
+ str r3, [r5, #TI_PREEMPT] @ disable preempt
+#endif
armv6_set_pte_ext cpu_v6
+#if defined(CONFIG_SMP) && defined(CONFIG_PREEMPT)
+ str r4, [r5, #TI_PREEMPT] @ restore preempt count
+ ldmia sp!, {r4, r5}
+#endif
#endif
mov pc, lr
--
1.7.4.4
^ permalink raw reply related
* [PATCHv16 0/9] Contiguous Memory Allocator
From: Arnd Bergmann @ 2011-10-07 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317909290-29832-1-git-send-email-m.szyprowski@samsung.com>
On Thursday 06 October 2011, Marek Szyprowski wrote:
> Once again I decided to post an updated version of the Contiguous Memory
> Allocator patches.
>
> This version provides mainly a bugfix for a very rare issue that might
> have changed migration type of the CMA page blocks resulting in dropping
> CMA features from the affected page block and causing memory allocation
> to fail. Also the issue reported by Dave Hansen has been fixed.
>
> This version also introduces basic support for x86 architecture, what
> allows wide testing on KVM/QEMU emulators and all common x86 boxes. I
> hope this will result in wider testing, comments and easier merging to
> mainline.
Hi Marek,
I think we need to finally get this into linux-next now, to get some
broader testing. Having the x86 patch definitely helps here becauses
it potentially exposes the code to many more testers.
IMHO it would be good to merge the entire series into 3.2, since
the ARM portion fixes an important bug (double mapping of memory
ranges with conflicting attributes) that we've lived with for far
too long, but it really depends on how everyone sees the risk
for regressions here. If something breaks in unfixable ways before
the 3.2 release, we can always revert the patches and have another
try later.
It's also not clear how we should merge it. Ideally the first bunch
would go through linux-mm, and the architecture specific patches
through the respective architecture trees, but there is an obvious
inderdependency between these sets.
Russell, Andrew, are you both comfortable with putting the entire
set into linux-mm to solve this? Do you see this as 3.2 or rather
as 3.3 material?
Arnd
^ permalink raw reply
* [PATCH 1/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
From: Santosh Shilimkar @ 2011-10-07 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111007151116.GI6324@atomide.com>
On Friday 07 October 2011 08:41 PM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [111007 07:29]:
>> On Friday 07 October 2011 08:13 PM, Tony Lindgren wrote:
>>>
>>> ..so I think we should just have a separate static mapping for
>>> the omap4 errata fix SO page, and just limit the memory available
>>> for SRAM code to ioremap.
>>>
>>> How does that sounds to you?
>>>
>> That's more or less what the patch is already doing.
>> Instead of static mapping, I was dynamically stealing one
>> page ( SZ_4K) and mapping it as MT_MEMORY_SO and rest
>> of the memory as MT_MEMORY for OMAP4.
>
> Yeah cool.
>
>> It should be doable with your updates as well,
>> I guess with or without static mapping since the only
>> requisite is to keep one page of SRAM free on OMAP4 and
>> them map them using iotable_init() with MT_MEMORY_SO.
>
> How about something like the following, this won't compile
> without at least moving the defines around a bit, but shows
> what I had in mind:
>
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -238,6 +238,14 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
> .length = L4_EMU_44XX_SIZE,
> .type = MT_DEVICE,
> },
> +#ifdef CONFIG_OMAP4_ERRATA_I688
> + {
> + .virtual = OMAP4_SRAM_VA,
> + .pfn = __phys_to_pfn(OMAP4_SRAM_PA),
> + .length = PAGE_SIZE,
> + .type = MT_MEMORY_SO,
> + },
> +#endif
> };
I initially tried some thing similar but the issue was GP and
HS devices. SRAM_PA isn't same on GP and EMU device and hence
did that dynamically. One way is I can make GP and HS
device SRAM_PA same for OMAP4 (Will loose 16 KB of
SRAM on OMAP4 GP). It's ok to loose that 16 KB SRAM
for OMAP4 with errata enabled.
Below change works on both GP and HS device
If you are OK with it, I can update errata patch accordingly.
diff --git a/arch/arm/plat-omap/include/plat/sram.h
b/arch/arm/plat-omap/include/plat/sram.h
index f500fc3..111b1a8 100644
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -95,6 +95,11 @@ static inline void omap_push_sram_idle(void) {}
*/
#define OMAP2_SRAM_PA 0x40200000
#define OMAP3_SRAM_PA 0x40200000
+#ifdef CONFIG_OMAP4_ERRATA_I688
+#define OMAP4_SRAM_PA 0x40304000
+#else
#define OMAP4_SRAM_PA 0x40300000
+#endif
+#define OMAP4_SRAM_VA 0xfe404000
#endif
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 363c91e..cdd303f 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -48,9 +48,13 @@
#define OMAP3_SRAM_VA 0xfe400000
#define OMAP3_SRAM_PUB_PA (OMAP3_SRAM_PA + 0x8000)
#define OMAP3_SRAM_PUB_VA (OMAP3_SRAM_VA + 0x8000)
-#define OMAP4_SRAM_VA 0xfe400000
+#ifdef CONFIG_OMAP4_ERRATA_I688
+#define OMAP4_SRAM_PUB_PA OMAP4_SRAM_PA
+#define OMAP4_SRAM_PUB_VA OMAP4_SRAM_VA
+#else
#define OMAP4_SRAM_PUB_PA (OMAP4_SRAM_PA + 0x4000)
#define OMAP4_SRAM_PUB_VA (OMAP4_SRAM_VA + 0x4000)
+#endif
#if defined(CONFIG_ARCH_OMAP2PLUS)
#define SRAM_BOOTLOADER_SZ 0x00
@@ -203,6 +207,11 @@ static void __init omap_map_sram(void)
if (omap_sram_size == 0)
return;
+#ifdef CONFIG_OMAP4_ERRATA_I688
+ omap_sram_base += PAGE_SIZE;
+ omap_sram_start += PAGE_SIZE;
+ omap_sram_size -= SZ_16K;
+#endif
if (cpu_is_omap34xx()) {
/*
* SRAM must be marked as non-cached on OMAP3 since the
Regards
Santosh
^ permalink raw reply related
* [PATCH v3] omap: dmtimer: convert printk to pr_err
From: Joe Perches @ 2011-10-07 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111007092243.GC27281@n2100.arm.linux.org.uk>
On Fri, 2011-10-07 at 10:22 +0100, Russell King - ARM Linux wrote:
> On Fri, Oct 07, 2011 at 10:50:16AM +0200, V?ctor Manuel J?quez Leal wrote:
> > Convert a printk(KERN_ERR) message in the driver to pr_err().
> ...
> > @@ -111,7 +111,7 @@ static void omap_dm_timer_wait_for_reset(struct omap_dm_timer *timer)
> > while (!(__raw_readl(timer->sys_stat) & 1)) {
> > c++;
> > if (c > 100000) {
> > - printk(KERN_ERR "Timer failed to reset\n");
> > + pr_err("Timer failed to reset\n");
>
> What is the reason behind this change? It looks like it's to use the
> latest and greatest function.
Hi Russell
I'm not promoting this patch, just commenting.
At some point in the next couple of years, I want
to convert all of, or as many as possible of, the
remaining printk uses to pr_<level>.
This would allow finer grained control over the
prefixing of KBUILD_MODNAME and __func__, and
could possibly make the kernel image smaller.
Today, arch/arm has ~3:1 ratio of printk to pr_<level>.
grep shows 1427 printks, 468 pr_<level>, 405 pr_debug's.
> If so, please don't make these changes - we have on many occasions been
> blamed for size of diffstat, churn, needless change, and this patch is
> exactly that.
True.
These trivial changes could wait until arch/arm settles
down a bit more.
> By all means fix printk's without KERN_ constants,
There's still more than 250 of those in arch/arm.
Even more with the uses of secondary things like:
#define PRINTK(x...) (foo && printk(x))
> possibly converting
> them to pr_*, but don't go around replacing printk(KERN_* with pr_*(
> without ensuring that there's a real benefit to the change.
Style consistency patches do need to be governed by
acceptable churn rate.
^ permalink raw reply
* [PATCHv2 0/7]ARM: OMAP3PLUS PM: Add IO DaisyChain support via hwmod mux
From: Vishwanath BS @ 2011-10-07 17:47 UTC (permalink / raw)
To: linux-arm-kernel
The folowing patch series provides IO Daisychain feature via omap hwmod mux
framework.
The patch series has been generated against 3.1 rc9 and tested on OMAP3 Platform
(ZOOM3 and OMAP3430 SDP) for Retentiona and OFF mode in suspend/cpuidle path.
Tested on OMAP4 using [1] as OMAP4 Core PM is not yet supported mainline.
[1]: git://gitorious.org/omap-pm/linux.git omap4_core_pm
Also tested against latest UART Runtime with Chain Handler patches [1].
[2]: git://gitorious.org/runtime_3-0/runtime_3-0.git v6_uart_runtime
Mohan V (1):
ARM: OMAP3 PM: correct enable/disable of daisy io chain
Rajendra Nayak (1):
ARM: OMAP4 PM: Add IO Daisychain support
Vishwanath BS (5):
ARM: OMAP3 PM: Move IO Daisychain function to omap3 prm file
ARM: OMAP3 PM: Enable IO Wake up
ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux
ARM: OMAP3 PM: Remove IO Daisychain control from cpuidle
ARM: OMAP3 PM: Enable IO Daisychain for supported chips
arch/arm/mach-omap2/omap_hwmod.c | 9 +++++-
arch/arm/mach-omap2/pm.c | 11 ++++++++
arch/arm/mach-omap2/pm.h | 1 +
arch/arm/mach-omap2/pm34xx.c | 49 ++---------------------------------
arch/arm/mach-omap2/prm2xxx_3xxx.c | 27 +++++++++++++++++++
arch/arm/mach-omap2/prm2xxx_3xxx.h | 14 ++++++++++
arch/arm/mach-omap2/prm44xx.c | 33 ++++++++++++++++++++++++
arch/arm/mach-omap2/prm44xx.h | 1 +
8 files changed, 97 insertions(+), 48 deletions(-)
^ permalink raw reply
* [PATCHv2 1/7] ARM: OMAP3 PM: correct enable/disable of daisy io chain
From: Vishwanath BS @ 2011-10-07 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318009671-12813-1-git-send-email-vishwanath.bs@ti.com>
From: Mohan V <mohanv@ti.com>
Currently the enabling and disabling of IO Daisy chain is not
according to the TRM. The below steps are followed to enable/
disable the IO chain according to the "Sec 3.5.7.2.2
I/O Wake-Up Mechanism" in OMAP3630 Public TRM[1].
Steps to enable IO chain:
[a] Set PM_WKEN_WKUP.EN_IO bit
[b] Set the PM_WKEN_WKUP.EN_IO_CHAIN bit
[c] Poll for PM_WKST_WKUP.ST_IO_CHAIN.
[d] When ST_IO_CHAIN bit set to 1, clear PM_WKEN_WKUP.EN_IO_CHAIN
[e] Clear ST_IO_CHAIN bit.
Steps to disable IO chain:
[a] Clear PM_WKEN_WKUP.EN_IO_CHAIN bit
[b] Clear PM_WKEN_WKUP.EN_IO bit
[c] Clear PM_WKST_WKUP.ST_IO bit by writing 1 to it.
Step [e] & [c] in each case can be skipped, as these are handled
by the PRCM interrupt handler later.
[1] http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vV.zip
Signed-off-by: Mohan V <mohanv@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
---
arch/arm/mach-omap2/pm34xx.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7255d9b..041f6e6 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -105,7 +105,7 @@ static void omap3_enable_io_chain(void)
/* Do a readback to assure write has been done */
omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
- while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN) &
+ while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST) &
OMAP3430_ST_IO_CHAIN_MASK)) {
timeout++;
if (timeout > 1000) {
@@ -113,9 +113,9 @@ static void omap3_enable_io_chain(void)
"activation failed.\n");
return;
}
- omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
- WKUP_MOD, PM_WKEN);
}
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
}
}
--
1.7.0.4
^ permalink raw reply related
* [PATCHv2 2/7] ARM: OMAP3 PM: Move IO Daisychain function to omap3 prm file
From: Vishwanath BS @ 2011-10-07 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318009671-12813-1-git-send-email-vishwanath.bs@ti.com>
Since IO Daisychain modifies only PRM registers, it makes sense to move it to
PRM File.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
---
arch/arm/mach-omap2/pm34xx.c | 33 +--------------------------------
arch/arm/mach-omap2/prm2xxx_3xxx.c | 35 +++++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/prm2xxx_3xxx.h | 14 ++++++++++++++
3 files changed, 50 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 041f6e6..352ad3c 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -95,37 +95,6 @@ static inline void omap3_per_restore_context(void)
omap_gpio_restore_context();
}
-static void omap3_enable_io_chain(void)
-{
- int timeout = 0;
-
- if (omap_rev() >= OMAP3430_REV_ES3_1) {
- omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
- /* Do a readback to assure write has been done */
- omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
-
- while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST) &
- OMAP3430_ST_IO_CHAIN_MASK)) {
- timeout++;
- if (timeout > 1000) {
- printk(KERN_ERR "Wake up daisy chain "
- "activation failed.\n");
- return;
- }
- }
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
- }
-}
-
-static void omap3_disable_io_chain(void)
-{
- if (omap_rev() >= OMAP3430_REV_ES3_1)
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
-}
-
static void omap3_core_save_context(void)
{
omap3_ctrl_save_padconf();
@@ -376,7 +345,7 @@ void omap_sram_idle(void)
(per_next_state < PWRDM_POWER_ON ||
core_next_state < PWRDM_POWER_ON)) {
omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD, PM_WKEN);
- omap3_enable_io_chain();
+ omap3_trigger_wuclk_ctrl();
}
/* Block console output in case it is on one of the OMAP UARTs */
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 051213f..915d726 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -156,3 +156,38 @@ int omap2_prm_deassert_hardreset(s16 prm_mod, u8 rst_shift, u8 st_shift)
return (c == MAX_MODULE_HARDRESET_WAIT) ? -EBUSY : 0;
}
+
+/**
+ * Maximum time(us) it takes to output the signal WUCLKOUT of the last pad of
+ * the I/O ring after asserting WUCLKIN high
+ */
+#define MAX_IOPAD_LATCH_TIME 1000
+
+/* OMAP3 Daisychain trigger sequence */
+void omap3_trigger_wuclk_ctrl(void)
+{
+ int i = 0;
+
+ if (omap_rev() >= OMAP3430_REV_ES3_1) {
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
+ /* Do a readback to assure write has been done */
+ omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
+
+ omap_test_timeout(
+ (((omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST) &
+ OMAP3430_ST_IO_CHAIN_MASK) == 1)),
+ MAX_IOPAD_LATCH_TIME, i);
+
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
+ }
+}
+
+/* OMAP3 Daisychain disable sequence */
+void omap3_disable_io_chain(void)
+{
+ if (omap_rev() >= OMAP3430_REV_ES3_1)
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
+}
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index a1fc62a..8bc574d 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -289,6 +289,18 @@ static inline int omap2_prm_deassert_hardreset(s16 prm_mod, u8 rst_shift,
"not suppose to be used on omap4\n");
return 0;
}
+extern void omap3_trigger_wuclk_ctrl(void)
+{
+ WARN(1, "prm: omap2xxx/omap3xxx specific function and "
+ "not suppose to be used on omap4\n");
+ return 0;
+}
+extern void omap3_disable_io_chain(void)
+{
+ WARN(1, "prm: omap2xxx/omap3xxx specific function and "
+ "not suppose to be used on omap4\n");
+ return 0;
+}
#else
/* Power/reset management domain register get/set */
extern u32 omap2_prm_read_mod_reg(s16 module, u16 idx);
@@ -302,6 +314,8 @@ extern u32 omap2_prm_read_mod_bits_shift(s16 domain, s16 idx, u32 mask);
extern int omap2_prm_is_hardreset_asserted(s16 prm_mod, u8 shift);
extern int omap2_prm_assert_hardreset(s16 prm_mod, u8 shift);
extern int omap2_prm_deassert_hardreset(s16 prm_mod, u8 rst_shift, u8 st_shift);
+extern void omap3_trigger_wuclk_ctrl(void);
+extern void omap3_disable_io_chain(void);
#endif /* CONFIG_ARCH_OMAP4 */
#endif
--
1.7.0.4
^ permalink raw reply related
* [PATCHv2 3/7] ARM: OMAP4 PM: Add IO Daisychain support
From: Vishwanath BS @ 2011-10-07 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318009671-12813-1-git-send-email-vishwanath.bs@ti.com>
From: Rajendra Nayak <rnayak@ti.com>
patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in OMAP4430
Public TRM.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
---
arch/arm/mach-omap2/prm44xx.c | 33 +++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/prm44xx.h | 1 +
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 0016555..7e19678 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -23,6 +23,8 @@
#include "prm44xx.h"
#include "prm-regbits-44xx.h"
+#include "prcm44xx.h"
+#include "prminst44xx.h"
/* PRM low-level functions */
@@ -50,3 +52,34 @@ u32 omap4_prm_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 reg)
return v;
}
+
+/**
+ * Maximum time(us) it takes to output the signal WUCLKOUT of the last pad of
+ * the I/O ring after asserting WUCLKIN high
+ */
+#define MAX_IOPAD_LATCH_TIME 1000
+
+/* OMAP4 IO Daisychain trigger sequence */
+void omap4_trigger_wuclk_ctrl(void)
+{
+ int i = 0;
+
+ /* Enable GLOBAL_WUEN */
+ if (!(omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET)
+ & OMAP4430_GLOBAL_WUEN_MASK))
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
+ OMAP4430_GLOBAL_WUEN_MASK, OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET);
+
+ /* Trigger WUCLKIN enable */
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, OMAP4430_WUCLK_CTRL_MASK,
+ OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
+ omap_test_timeout(
+ ((omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET)
+ >> OMAP4430_WUCLK_STATUS_SHIFT) == 1), MAX_IOPAD_LATCH_TIME, i);
+ /* Trigger WUCLKIN disable */
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
+ OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
+ return;
+}
+
diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h
index 7dfa379..275b25a 100644
--- a/arch/arm/mach-omap2/prm44xx.h
+++ b/arch/arm/mach-omap2/prm44xx.h
@@ -750,6 +750,7 @@
extern u32 omap4_prm_read_inst_reg(s16 inst, u16 idx);
extern void omap4_prm_write_inst_reg(u32 val, s16 inst, u16 idx);
extern u32 omap4_prm_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx);
+extern void omap4_trigger_wuclk_ctrl(void);
# endif
--
1.7.0.4
^ permalink raw reply related
* [PATCHv2 4/7] ARM: OMAP3 PM: Enable IO Wake up
From: Vishwanath BS @ 2011-10-07 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318009671-12813-1-git-send-email-vishwanath.bs@ti.com>
Enable IO Wake up for OMAP3 as part of PM Init.
Currently this has been managed in cpuidle path which is not the right place.
Subsequent patch will remove IO Daisy chain handling in cpuidle path once daisy
chain is handled as part of hwmod mux.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
---
arch/arm/mach-omap2/pm34xx.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 352ad3c..c282552 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -854,6 +854,9 @@ static int __init omap3_pm_init(void)
goto err1;
}
+ if (omap3_has_io_wakeup())
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD, PM_WKEN);
+
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
printk(KERN_ERR "Failed to setup powerdomains\n");
--
1.7.0.4
^ permalink raw reply related
* [PATCHv2 5/7] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux
From: Vishwanath BS @ 2011-10-07 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318009671-12813-1-git-send-email-vishwanath.bs@ti.com>
IO Daisychain feature has to be triggered whenever there is a change in
device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP).
Now devices can idle independent of the powerdomain, there can be a window where device
is idled and corresponding powerdomain can be ON/INACTIVE state. In such situations,
since both module wake up is enabled at padlevel as well as io daisychain sequence is
triggered, there will be 2 PRCM interrupts (Module async wake up via swakeup and IO Pad
interrupt). But as PRCM Interrupt handler clears the Module Padlevel WKST bit in the
first interrupt, module specific interrupt handler will not triggered for the second time
Also look at detailed explanation given by Rajendra at
http://www.spinics.net/lists/linux-serial/msg04480.html
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
---
This has been tested on OMAP3 using Chain Handler + UART Runtime patches [1]. Special
thanks to GOvind for testing and confirming this behaviour on UART3.
[1]: git://gitorious.org/runtime_3-0/runtime_3-0.git v6_uart_runtime
arch/arm/mach-omap2/omap_hwmod.c | 9 +++++++--
arch/arm/mach-omap2/pm.c | 11 +++++++++++
arch/arm/mach-omap2/pm.h | 1 +
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 84cc0bd..070f3f5 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -151,6 +151,7 @@
#include "prm44xx.h"
#include "prminst44xx.h"
#include "mux.h"
+#include "pm.h"
/* Maximum microseconds to wait for OMAP module to softreset */
#define MAX_MODULE_SOFTRESET_WAIT 10000
@@ -1462,8 +1463,10 @@ static int _enable(struct omap_hwmod *oh)
/* Mux pins for device runtime if populated */
if (oh->mux && (!oh->mux->enabled ||
((oh->_state == _HWMOD_STATE_IDLE) &&
- oh->mux->pads_dynamic)))
+ oh->mux->pads_dynamic))) {
omap_hwmod_mux(oh->mux, _HWMOD_STATE_ENABLED);
+ omap_trigger_wuclk_ctrl();
+ }
_add_initiator_dep(oh, mpu_oh);
@@ -1553,8 +1556,10 @@ static int _idle(struct omap_hwmod *oh)
clkdm_hwmod_disable(oh->clkdm, oh);
/* Mux pins for device idle if populated */
- if (oh->mux && oh->mux->pads_dynamic)
+ if (oh->mux && oh->mux->pads_dynamic) {
omap_hwmod_mux(oh->mux, _HWMOD_STATE_IDLE);
+ omap_trigger_wuclk_ctrl();
+ }
oh->_state = _HWMOD_STATE_IDLE;
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 472bf22..79be7af 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -23,6 +23,8 @@
#include "powerdomain.h"
#include "clockdomain.h"
#include "pm.h"
+#include "prm2xxx_3xxx.h"
+#include "prm44xx.h"
static struct omap_device_pm_latency *pm_lats;
@@ -95,6 +97,15 @@ static void omap2_init_processor_devices(void)
}
}
+void omap_trigger_wuclk_ctrl(void)
+{
+ if (cpu_is_omap34xx())
+ omap3_trigger_wuclk_ctrl();
+
+ if (cpu_is_omap44xx())
+ omap4_trigger_wuclk_ctrl();
+}
+
/* Types of sleep_switch used in omap_set_pwrdm_state */
#define FORCEWAKEUP_SWITCH 0
#define LOWPOWERSTATE_SWITCH 1
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 4e166ad..05c2da2 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -21,6 +21,7 @@ extern void omap_sram_idle(void);
extern int omap3_can_sleep(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
+void omap_trigger_wuclk_ctrl(void);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
--
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