* [PATCH v2] cpufreq: instantiate cpufreq-cpu0 as a platform_driver
From: Rafael J. Wysocki @ 2013-01-30 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130134939.GE2757@S2101-09.ap.freescale.net>
On Wednesday, January 30, 2013 09:49:41 PM Shawn Guo wrote:
> On Wed, Jan 30, 2013 at 02:40:35PM +0100, Rafael J. Wysocki wrote:
> > > > Mark, AnilKumar,
> > > >
> > > > I only compile-tested it on highbank and omap2. Please give it a test
> > > > no hardware to make sure cpufreq-cpu0 still works for you. Thanks.
> > >
> > > Hi Shawn,
> > >
> > > I hope this is based on linux-omap/master, to test the driver I have
> > > to add some patches on top of this patch, because of recent changes.
> > > I will provide the test details once I am done.
> >
> > Shawn, does it mean I need to wait with applying the patch or will OMAP2
> > work as is?
> >
> I would expect that omap2/am33xx should work as it is, but I do not
> have hardware to confirm that.
>
> Also as the patch touches a few files in arch/arm/mach-omap2, we may
> need an ACK from Tony.
>
> Actually, I prefer to move omap2 bits into a separate patch and have
> it go via omap tree to avoid the possible conflict with cpufreq and
> arm-soc tree. What do you say? If you agree, I will re-iterate the
> patch to do so.
Yes, please do as you think is appropriate.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [PATCH,RFC] usb: add devicetree helpers for determining dr_mode and phy_type
From: Sascha Hauer @ 2013-01-30 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130020627.GA699@nchen-desktop>
On Wed, Jan 30, 2013 at 10:06:28AM +0800, Peter Chen wrote:
> On Tue, Jan 29, 2013 at 01:55:04PM +0200, Alexander Shishkin wrote:
> > Sascha Hauer <s.hauer@pengutronix.de> writes:
> >
> > > From: Michael Grzeschik <m.grzeschik@pengutronix.de>
> > >
> > > This adds two little devicetree helper functions for determining the
> > > dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
> > > the devicetree.
> > >
> > > Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
> > > Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
> > > ---
> > >
> > > The properties and their values have been taken from the fsl-mph-dr driver.
> > > This binding is also documented (though currently not used) for the tegra
> > > ehci driver (Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt).
> > > This is a first attempt to parse these bindings at a common place so that
> > > others can make use of it.
> > >
> > > Basically I want to know whether this binding is recommended for new drivers
> > > since normally the devicetree uses '-' instead of '_', and maybe there are
> > > other problems with it.
> > >
> > > I need this binding for the chipidea driver. I suspect that the fsl-mph-dr
> > > driver also really handles a chipidea core.
> >
> > As far as I know, it is a chipidea core. Adding Peter to Cc list, he can
> > probably confirm.
>
> The fsl-mph-dr can't be used for chipdiea as it handles three platform
> drivers for three roles (peripheral , host, otg). But chipidea only has
> two platform drivers, one is the chipidea core, the other is related
> controller wrapper.
What do you mean by 'three platform drivers'? That's only how the driver
is built, no? I was talking about the hardware the fsl-mph-dr driver
handles which definitely smells like chipidea.
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
* kernel 3.8 make problem
From: Jean-Francois Moine @ 2013-01-30 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bedmt81oibwyqccqjqgpshjv.1359552548411@email.android.com>
On Wed, 30 Jan 2013 13:29:11 +0000
"Menon, Nishanth" <nm@ti.com> wrote:
> I do a cross compile on x86 for omap(I am TI ;) ).
>
> Looks like an setup issue IMHO.
What are you thinking about?
For more information, I can say that everything else is working fine
in my system: X11, network (mail, web browsing, ssh), compilation,
edition, scripting (bash, busybox, javascript, tcl/tk, ghostscript..)...
There is just a 'shell' problem with 'make'!
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH v2] ARM: OMAP2: hwmod: Fix "register offset NULL check" bug
From: Hebbar, Gururaja @ 2013-01-30 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1212200734160.7362@utopia.booyaka.com>
On Thu, Dec 20, 2012 at 13:05:27, Paul Walmsley wrote:
> On Thu, 20 Dec 2012, Hebbar, Gururaja wrote:
>
> > On Wed, Dec 19, 2012 at 07:43:50, Paul Walmsley wrote:
> >
> > > We've got a few hwmods on OMAP44xx that don't have clkctrl_offs registers
> > > listed in the hwmod data, and which are not marked with HWMOD_NO_IDLEST.
> > > What's going to happen in those cases?
> >
> > Hmm. This is a special case to me. Let me go back and do some review.
> > Will be back with some more details.
>
> Probably what needs to happen is that those hwmods need to be marked with
> HWMOD_NO_IDLEST, in a separate patch before yours. As far as I can tell,
> that's how they should have been marked initially. Then your patch should
> be fine.
Looking at latest kernel v3.8-rc5, there is separate cm33xx.c file which
handles module ready checking for am33xx platform. So I will update this
patch to work on this file instead of touching omap4 related file
(cminst44xx.c)
>
> - Paul
>
Regards,
Gururaja
^ permalink raw reply
* kernel 3.8 make problem
From: Jean-Francois Moine @ 2013-01-30 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ttxj4oytvg02pxivwnruketi.1359554350723@email.android.com>
On Wed, 30 Jan 2013 13:59:12 +0000
"Menon, Nishanth" <nm@ti.com> wrote:
> Not completely sure.. I was thinking rebuilt binutils or the like.. An abi breakage would be a sad story though. Let's see what the list says..
Maybe. I am using Debian sid, and the libc is rather old (2.13). Are
there some changes in kernels > 3.5 which could ask for a newer libc?
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH 1/2] ARM: memory: use SZ_ constants for defining the virtual memory layout
From: Will Deacon @ 2013-01-30 14:08 UTC (permalink / raw)
To: linux-arm-kernel
Parts of the virtual memory layout (mainly the modules area) are
described using open-coded immediate values.
Use the SZ_ definitions from linux/sizes.h instead to make the code
clearer.
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/include/asm/memory.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 73cf03a..a0fd518 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -36,23 +36,23 @@
* TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area
*/
#define PAGE_OFFSET UL(CONFIG_PAGE_OFFSET)
-#define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(0x01000000))
+#define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(SZ_16M))
#define TASK_UNMAPPED_BASE (UL(CONFIG_PAGE_OFFSET) / 3)
/*
* The maximum size of a 26-bit user space task.
*/
-#define TASK_SIZE_26 UL(0x04000000)
+#define TASK_SIZE_26 UL(SZ_64M)
/*
* The module space lives between the addresses given by TASK_SIZE
* and PAGE_OFFSET - it must be within 32MB of the kernel text.
*/
#ifndef CONFIG_THUMB2_KERNEL
-#define MODULES_VADDR (PAGE_OFFSET - 16*1024*1024)
+#define MODULES_VADDR (PAGE_OFFSET - SZ_16M)
#else
/* smaller range for Thumb-2 symbols relocation (2^24)*/
-#define MODULES_VADDR (PAGE_OFFSET - 8*1024*1024)
+#define MODULES_VADDR (PAGE_OFFSET - SZ_8M)
#endif
#if TASK_SIZE > MODULES_VADDR
--
1.8.0
^ permalink raw reply related
* [PATCH 2/2] ARM: memory: define TASK_UNMAPPED_BASE in terms of TASK_SIZE
From: Will Deacon @ 2013-01-30 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359554912-26872-1-git-send-email-will.deacon@arm.com>
TASK_UNMAPPED_BASE is defined directly in terms of PAGE_OFFSET, which is
confusing given that the modules area sits between here and TASK_SIZE
and is not available for user allocations.
This patch defines TASK_UNMAPPED_BASE in terms of TASK_SIZE instead and
fixes a bug introduced by 394ef6403abc ("mm: use vm_unmapped_area() on
arm architecture") whereby TASK_UNMAPPED_BASE is no longer page-aligned
for bottom-up mmap, causing get_unmapped_area to choke on misaligned
addresses.
Reported-by: Christoffer Dall <cdall@cs.columbia.edu>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/include/asm/memory.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index a0fd518..255a01b 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -37,7 +37,7 @@
*/
#define PAGE_OFFSET UL(CONFIG_PAGE_OFFSET)
#define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(SZ_16M))
-#define TASK_UNMAPPED_BASE (UL(CONFIG_PAGE_OFFSET) / 3)
+#define TASK_UNMAPPED_BASE ((TASK_SIZE / 3) & ~UL(SZ_16M - 1))
/*
* The maximum size of a 26-bit user space task.
--
1.8.0
^ permalink raw reply related
* [PATCH] ARM: tlb: perform branch predictor maintenance for whole invalidation
From: Will Deacon @ 2013-01-30 14:12 UTC (permalink / raw)
To: linux-arm-kernel
The ARM architecture requires explicit branch predictor maintenance
when updating an instruction stream for a given virtual address. In
reality, this isn't so much of a burden because the branch predictor
is flushed during the cache maintenance required to make the new
instructions visible to the I-side of the processor.
One exception to this rule is when we flush the entire TLB for a CPU in
response to something other than writing new instructions (for example,
ASID rollover or switching to an identity mapping before disabling the
MMU).
This patch ensures that we flush the branch predictor as part of
invalidating the entire TLB.
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/include/asm/tlbflush.h | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index 6e924d3..713ff32 100644
--- a/arch/arm/include/asm/tlbflush.h
+++ b/arch/arm/include/asm/tlbflush.h
@@ -38,6 +38,7 @@
#define TLB_V7_UIS_PAGE (1 << 19)
#define TLB_V7_UIS_FULL (1 << 20)
#define TLB_V7_UIS_ASID (1 << 21)
+#define TLB_V7_UIS_BP (1 << 22)
#define TLB_BARRIER (1 << 28)
#define TLB_L2CLEAN_FR (1 << 29) /* Feroceon */
@@ -166,9 +167,11 @@
#endif
#define v7wbi_tlb_flags_smp (TLB_WB | TLB_DCLEAN | TLB_BARRIER | \
- TLB_V7_UIS_FULL | TLB_V7_UIS_PAGE | TLB_V7_UIS_ASID)
+ TLB_V7_UIS_FULL | TLB_V7_UIS_PAGE | \
+ TLB_V7_UIS_ASID | TLB_V7_UIS_BP)
#define v7wbi_tlb_flags_up (TLB_WB | TLB_DCLEAN | TLB_BARRIER | \
- TLB_V6_U_FULL | TLB_V6_U_PAGE | TLB_V6_U_ASID)
+ TLB_V6_U_FULL | TLB_V6_U_PAGE | \
+ TLB_V6_U_ASID)
#ifdef CONFIG_CPU_TLB_V7
@@ -330,6 +333,11 @@ static inline void local_flush_tlb_all(void)
tlb_op(TLB_V4_I_FULL | TLB_V6_I_FULL, "c8, c5, 0", zero);
tlb_op(TLB_V7_UIS_FULL, "c8, c3, 0", zero);
+ if (tlb_flag(TLB_V7_UIS_BP))
+ asm("mcr p15, 0, %0, c7, c1, 6" : : "r" (zero));
+ else
+ asm("mcr p15, 0, %0, c7, c5, 6" : : "r" (zero));
+
if (tlb_flag(TLB_BARRIER)) {
dsb();
isb();
--
1.8.0
^ permalink raw reply related
* [PATCH 0/6] Fix 740t support and remove more unused ARMv3 code
From: Will Deacon @ 2013-01-30 14:27 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
When looking at the remaining ARMv3 code that we still have kicking
around, I noticed that the only user of the cache-flushing routines is
the 740t, an ARMv4 chip. Having read the datasheet, we can actually use
our ARMv4 cache-flushing code and remove cache-v3.S.
After making that change, I thought I'd better do some testing, which is
where the fun began...
Even after getting hold of a 740t Integrator/AP core-tile, I ran into
many problems with the CPU support, which I don't believe has *ever*
worked. Anyway, having fixed those, the board runs like a charm.
Next stop is the 940t, which looks to be broken in similar ways.
Will
Will Deacon (6):
ARM: tlbflush: remove ARMv3 support
ARM: cache: remove ARMv3 support code
ARM: mm: fix numerous hideous errors in proc-arm740.S
ARM: mm: remove broken condition check for v4 flushing
ARM: modules: don't export cpu_set_pte_ext when !MMU
ARM: integrator: ensure ap_syscon_base is initialised when
!CONFIG_MMU
arch/arm/include/asm/glue-cache.h | 8 --
arch/arm/include/asm/tlbflush.h | 11 +--
arch/arm/mach-integrator/integrator_ap.c | 2 +-
arch/arm/mm/Kconfig | 5 +-
arch/arm/mm/Makefile | 1 -
arch/arm/mm/cache-v3.S | 137 -------------------------------
arch/arm/mm/cache-v4.S | 2 +-
arch/arm/mm/proc-arm740.S | 30 ++++---
arch/arm/mm/proc-syms.c | 2 +
9 files changed, 24 insertions(+), 174 deletions(-)
delete mode 100644 arch/arm/mm/cache-v3.S
--
1.8.0
^ permalink raw reply
* [PATCH 1/6] ARM: tlbflush: remove ARMv3 support
From: Will Deacon @ 2013-01-30 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359556069-28289-1-git-send-email-will.deacon@arm.com>
We no longer support any ARMv3 platforms, so remove the old tlbflushing
code.
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/include/asm/tlbflush.h | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index 6e924d3..23edd03 100644
--- a/arch/arm/include/asm/tlbflush.h
+++ b/arch/arm/include/asm/tlbflush.h
@@ -14,7 +14,6 @@
#include <asm/glue.h>
-#define TLB_V3_PAGE (1 << 0)
#define TLB_V4_U_PAGE (1 << 1)
#define TLB_V4_D_PAGE (1 << 2)
#define TLB_V4_I_PAGE (1 << 3)
@@ -22,7 +21,6 @@
#define TLB_V6_D_PAGE (1 << 5)
#define TLB_V6_I_PAGE (1 << 6)
-#define TLB_V3_FULL (1 << 8)
#define TLB_V4_U_FULL (1 << 9)
#define TLB_V4_D_FULL (1 << 10)
#define TLB_V4_I_FULL (1 << 11)
@@ -49,7 +47,6 @@
* =============
*
* We have the following to choose from:
- * v3 - ARMv3
* v4 - ARMv4 without write buffer
* v4wb - ARMv4 with write buffer without I TLB flush entry instruction
* v4wbi - ARMv4 with write buffer with I TLB flush entry instruction
@@ -324,7 +321,6 @@ static inline void local_flush_tlb_all(void)
if (tlb_flag(TLB_WB))
dsb();
- tlb_op(TLB_V3_FULL, "c6, c0, 0", zero);
tlb_op(TLB_V4_U_FULL | TLB_V6_U_FULL, "c8, c7, 0", zero);
tlb_op(TLB_V4_D_FULL | TLB_V6_D_FULL, "c8, c6, 0", zero);
tlb_op(TLB_V4_I_FULL | TLB_V6_I_FULL, "c8, c5, 0", zero);
@@ -345,9 +341,8 @@ static inline void local_flush_tlb_mm(struct mm_struct *mm)
if (tlb_flag(TLB_WB))
dsb();
- if (possible_tlb_flags & (TLB_V3_FULL|TLB_V4_U_FULL|TLB_V4_D_FULL|TLB_V4_I_FULL)) {
+ if (possible_tlb_flags & (TLB_V4_U_FULL|TLB_V4_D_FULL|TLB_V4_I_FULL)) {
if (cpumask_test_cpu(get_cpu(), mm_cpumask(mm))) {
- tlb_op(TLB_V3_FULL, "c6, c0, 0", zero);
tlb_op(TLB_V4_U_FULL, "c8, c7, 0", zero);
tlb_op(TLB_V4_D_FULL, "c8, c6, 0", zero);
tlb_op(TLB_V4_I_FULL, "c8, c5, 0", zero);
@@ -379,9 +374,8 @@ local_flush_tlb_page(struct vm_area_struct *vma, unsigned long uaddr)
if (tlb_flag(TLB_WB))
dsb();
- if (possible_tlb_flags & (TLB_V3_PAGE|TLB_V4_U_PAGE|TLB_V4_D_PAGE|TLB_V4_I_PAGE|TLB_V4_I_FULL) &&
+ if (possible_tlb_flags & (TLB_V4_U_PAGE|TLB_V4_D_PAGE|TLB_V4_I_PAGE|TLB_V4_I_FULL) &&
cpumask_test_cpu(smp_processor_id(), mm_cpumask(vma->vm_mm))) {
- tlb_op(TLB_V3_PAGE, "c6, c0, 0", uaddr);
tlb_op(TLB_V4_U_PAGE, "c8, c7, 1", uaddr);
tlb_op(TLB_V4_D_PAGE, "c8, c6, 1", uaddr);
tlb_op(TLB_V4_I_PAGE, "c8, c5, 1", uaddr);
@@ -412,7 +406,6 @@ static inline void local_flush_tlb_kernel_page(unsigned long kaddr)
if (tlb_flag(TLB_WB))
dsb();
- tlb_op(TLB_V3_PAGE, "c6, c0, 0", kaddr);
tlb_op(TLB_V4_U_PAGE, "c8, c7, 1", kaddr);
tlb_op(TLB_V4_D_PAGE, "c8, c6, 1", kaddr);
tlb_op(TLB_V4_I_PAGE, "c8, c5, 1", kaddr);
--
1.8.0
^ permalink raw reply related
* [PATCH 2/6] ARM: cache: remove ARMv3 support code
From: Will Deacon @ 2013-01-30 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359556069-28289-1-git-send-email-will.deacon@arm.com>
This is only used by 740t, which is a v4 core and (by my reading of the
datasheet for the CPU) ignores CRm for the cp15 cache flush operation,
making the v4 cache implementation in cache-v4.S sufficient for this
CPU.
Tested with 740T core-tile on Integrator/AP baseboard.
Cc: Hyok S. Choi <hyok.choi@samsung.com>
Cc: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/include/asm/glue-cache.h | 8 ---
arch/arm/mm/Kconfig | 5 +-
arch/arm/mm/Makefile | 1 -
arch/arm/mm/cache-v3.S | 137 --------------------------------------
arch/arm/mm/proc-arm740.S | 2 +-
5 files changed, 2 insertions(+), 151 deletions(-)
delete mode 100644 arch/arm/mm/cache-v3.S
diff --git a/arch/arm/include/asm/glue-cache.h b/arch/arm/include/asm/glue-cache.h
index cca9f15..ea289e1 100644
--- a/arch/arm/include/asm/glue-cache.h
+++ b/arch/arm/include/asm/glue-cache.h
@@ -19,14 +19,6 @@
#undef _CACHE
#undef MULTI_CACHE
-#if defined(CONFIG_CPU_CACHE_V3)
-# ifdef _CACHE
-# define MULTI_CACHE 1
-# else
-# define _CACHE v3
-# endif
-#endif
-
#if defined(CONFIG_CPU_CACHE_V4)
# ifdef _CACHE
# define MULTI_CACHE 1
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 3fd629d..c430f46 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -43,7 +43,7 @@ config CPU_ARM740T
depends on !MMU
select CPU_32v4T
select CPU_ABRT_LV4T
- select CPU_CACHE_V3 # although the core is v4t
+ select CPU_CACHE_V4
select CPU_CP15_MPU
select CPU_PABRT_LEGACY
help
@@ -469,9 +469,6 @@ config CPU_PABRT_V7
bool
# The cache model
-config CPU_CACHE_V3
- bool
-
config CPU_CACHE_V4
bool
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index 8a9c4cb..c0fd3c1 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -33,7 +33,6 @@ obj-$(CONFIG_CPU_PABRT_LEGACY) += pabort-legacy.o
obj-$(CONFIG_CPU_PABRT_V6) += pabort-v6.o
obj-$(CONFIG_CPU_PABRT_V7) += pabort-v7.o
-obj-$(CONFIG_CPU_CACHE_V3) += cache-v3.o
obj-$(CONFIG_CPU_CACHE_V4) += cache-v4.o
obj-$(CONFIG_CPU_CACHE_V4WT) += cache-v4wt.o
obj-$(CONFIG_CPU_CACHE_V4WB) += cache-v4wb.o
diff --git a/arch/arm/mm/cache-v3.S b/arch/arm/mm/cache-v3.S
deleted file mode 100644
index 8a3fade..0000000
--- a/arch/arm/mm/cache-v3.S
+++ /dev/null
@@ -1,137 +0,0 @@
-/*
- * linux/arch/arm/mm/cache-v3.S
- *
- * Copyright (C) 1997-2002 Russell king
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <linux/linkage.h>
-#include <linux/init.h>
-#include <asm/page.h>
-#include "proc-macros.S"
-
-/*
- * flush_icache_all()
- *
- * Unconditionally clean and invalidate the entire icache.
- */
-ENTRY(v3_flush_icache_all)
- mov pc, lr
-ENDPROC(v3_flush_icache_all)
-
-/*
- * flush_user_cache_all()
- *
- * Invalidate all cache entries in a particular address
- * space.
- *
- * - mm - mm_struct describing address space
- */
-ENTRY(v3_flush_user_cache_all)
- /* FALLTHROUGH */
-/*
- * flush_kern_cache_all()
- *
- * Clean and invalidate the entire cache.
- */
-ENTRY(v3_flush_kern_cache_all)
- /* FALLTHROUGH */
-
-/*
- * flush_user_cache_range(start, end, flags)
- *
- * Invalidate a range of cache entries in the specified
- * address space.
- *
- * - start - start address (may not be aligned)
- * - end - end address (exclusive, may not be aligned)
- * - flags - vma_area_struct flags describing address space
- */
-ENTRY(v3_flush_user_cache_range)
- mov ip, #0
- mcreq p15, 0, ip, c7, c0, 0 @ flush ID cache
- mov pc, lr
-
-/*
- * coherent_kern_range(start, end)
- *
- * Ensure coherency between the Icache and the Dcache in the
- * region described by start. If you have non-snooping
- * Harvard caches, you need to implement this function.
- *
- * - start - virtual start address
- * - end - virtual end address
- */
-ENTRY(v3_coherent_kern_range)
- /* FALLTHROUGH */
-
-/*
- * coherent_user_range(start, end)
- *
- * Ensure coherency between the Icache and the Dcache in the
- * region described by start. If you have non-snooping
- * Harvard caches, you need to implement this function.
- *
- * - start - virtual start address
- * - end - virtual end address
- */
-ENTRY(v3_coherent_user_range)
- mov r0, #0
- mov pc, lr
-
-/*
- * flush_kern_dcache_area(void *page, size_t size)
- *
- * Ensure no D cache aliasing occurs, either with itself or
- * the I cache
- *
- * - addr - kernel address
- * - size - region size
- */
-ENTRY(v3_flush_kern_dcache_area)
- /* FALLTHROUGH */
-
-/*
- * dma_flush_range(start, end)
- *
- * Clean and invalidate the specified virtual address range.
- *
- * - start - virtual start address
- * - end - virtual end address
- */
-ENTRY(v3_dma_flush_range)
- mov r0, #0
- mcr p15, 0, r0, c7, c0, 0 @ flush ID cache
- mov pc, lr
-
-/*
- * dma_unmap_area(start, size, dir)
- * - start - kernel virtual start address
- * - size - size of region
- * - dir - DMA direction
- */
-ENTRY(v3_dma_unmap_area)
- teq r2, #DMA_TO_DEVICE
- bne v3_dma_flush_range
- /* FALLTHROUGH */
-
-/*
- * dma_map_area(start, size, dir)
- * - start - kernel virtual start address
- * - size - size of region
- * - dir - DMA direction
- */
-ENTRY(v3_dma_map_area)
- mov pc, lr
-ENDPROC(v3_dma_unmap_area)
-ENDPROC(v3_dma_map_area)
-
- .globl v3_flush_kern_cache_louis
- .equ v3_flush_kern_cache_louis, v3_flush_kern_cache_all
-
- __INITDATA
-
- @ define struct cpu_cache_fns (see <asm/cacheflush.h> and proc-macros.S)
- define_cache_functions v3
diff --git a/arch/arm/mm/proc-arm740.S b/arch/arm/mm/proc-arm740.S
index dc5de5d..2088234 100644
--- a/arch/arm/mm/proc-arm740.S
+++ b/arch/arm/mm/proc-arm740.S
@@ -145,5 +145,5 @@ __arm740_proc_info:
.long arm740_processor_functions
.long 0
.long 0
- .long v3_cache_fns @ cache model
+ .long v4_cache_fns @ cache model
.size __arm740_proc_info, . - __arm740_proc_info
--
1.8.0
^ permalink raw reply related
* [PATCH 3/6] ARM: mm: fix numerous hideous errors in proc-arm740.S
From: Will Deacon @ 2013-01-30 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359556069-28289-1-git-send-email-will.deacon@arm.com>
The setup code in proc-arm740.S is completely broken and, as far as I
can tell, always has been. I was >this< close to ripping it out, when a
740t core-tile materialised in the office, so I've had a crack at fixing
things up:
- Fix the ram/flash area calculations so that we actually set
the condition flags before testing them...
- Fix the proc_info structure so that __cpu_io_mmu_flags are
defined as 0, placing the __cpu_flush pointer at the correct
offset
- Re-number the registers used during __arm740_setup so that
we don't clobber the machine ID et al
- Advertise Thumb support via the hwcaps, since 740T is the only
740 implementation.
Cc: Hyok S. Choi <hyok.choi@samsung.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/mm/proc-arm740.S | 28 ++++++++++++++++------------
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mm/proc-arm740.S b/arch/arm/mm/proc-arm740.S
index 2088234..fde2d2a 100644
--- a/arch/arm/mm/proc-arm740.S
+++ b/arch/arm/mm/proc-arm740.S
@@ -77,24 +77,27 @@ __arm740_setup:
mcr p15, 0, r0, c6, c0 @ set area 0, default
ldr r0, =(CONFIG_DRAM_BASE & 0xFFFFF000) @ base[31:12] of RAM
- ldr r1, =(CONFIG_DRAM_SIZE >> 12) @ size of RAM (must be >= 4KB)
- mov r2, #10 @ 11 is the minimum (4KB)
-1: add r2, r2, #1 @ area size *= 2
- mov r1, r1, lsr #1
+ ldr r3, =(CONFIG_DRAM_SIZE >> 12) @ size of RAM (must be >= 4KB)
+ mov r4, #10 @ 11 is the minimum (4KB)
+1: add r4, r4, #1 @ area size *= 2
+ movs r3, r3, lsr #1
bne 1b @ count not zero r-shift
- orr r0, r0, r2, lsl #1 @ the area register value
+ orr r0, r0, r4, lsl #1 @ the area register value
orr r0, r0, #1 @ set enable bit
mcr p15, 0, r0, c6, c1 @ set area 1, RAM
ldr r0, =(CONFIG_FLASH_MEM_BASE & 0xFFFFF000) @ base[31:12] of FLASH
- ldr r1, =(CONFIG_FLASH_SIZE >> 12) @ size of FLASH (must be >= 4KB)
- mov r2, #10 @ 11 is the minimum (4KB)
-1: add r2, r2, #1 @ area size *= 2
- mov r1, r1, lsr #1
+ ldr r3, =(CONFIG_FLASH_SIZE >> 12) @ size of FLASH (must be >= 4KB)
+ cmp r3, #0
+ moveq r0, #0
+ beq 2f
+ mov r4, #10 @ 11 is the minimum (4KB)
+1: add r4, r4, #1 @ area size *= 2
+ movs r3, r3, lsr #1
bne 1b @ count not zero r-shift
- orr r0, r0, r2, lsl #1 @ the area register value
+ orr r0, r0, r4, lsl #1 @ the area register value
orr r0, r0, #1 @ set enable bit
- mcr p15, 0, r0, c6, c2 @ set area 2, ROM/FLASH
+2: mcr p15, 0, r0, c6, c2 @ set area 2, ROM/FLASH
mov r0, #0x06
mcr p15, 0, r0, c2, c0 @ Region 1&2 cacheable
@@ -137,10 +140,11 @@ __arm740_proc_info:
.long 0x41807400
.long 0xfffffff0
.long 0
+ .long 0
b __arm740_setup
.long cpu_arch_name
.long cpu_elf_name
- .long HWCAP_SWP | HWCAP_HALF | HWCAP_26BIT
+ .long HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB | HWCAP_26BIT
.long cpu_arm740_name
.long arm740_processor_functions
.long 0
--
1.8.0
^ permalink raw reply related
* [PATCH 4/6] ARM: mm: remove broken condition check for v4 flushing
From: Will Deacon @ 2013-01-30 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359556069-28289-1-git-send-email-will.deacon@arm.com>
There's no point having a conditional cache flush if we don't know the
state of the condition beforehand.
This patch makes the cacheflush in v4_flush_user_cache_range
unconditional.
signed-off-by: will deacon <will.deacon@arm.com>
---
arch/arm/mm/cache-v4.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/cache-v4.S b/arch/arm/mm/cache-v4.S
index 43e5d77..a7ba68f 100644
--- a/arch/arm/mm/cache-v4.S
+++ b/arch/arm/mm/cache-v4.S
@@ -58,7 +58,7 @@ ENTRY(v4_flush_kern_cache_all)
ENTRY(v4_flush_user_cache_range)
#ifdef CONFIG_CPU_CP15
mov ip, #0
- mcreq p15, 0, ip, c7, c7, 0 @ flush ID cache
+ mcr p15, 0, ip, c7, c7, 0 @ flush ID cache
mov pc, lr
#else
/* FALLTHROUGH */
--
1.8.0
^ permalink raw reply related
* [PATCH 5/6] ARM: modules: don't export cpu_set_pte_ext when !MMU
From: Will Deacon @ 2013-01-30 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359556069-28289-1-git-send-email-will.deacon@arm.com>
cpu_set_pte_ext is only guaranteed to be defined when CONFIG_MMU, so
don't export it to modules otherwise.
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/mm/proc-syms.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mm/proc-syms.c b/arch/arm/mm/proc-syms.c
index 3e6210b..054b491 100644
--- a/arch/arm/mm/proc-syms.c
+++ b/arch/arm/mm/proc-syms.c
@@ -17,7 +17,9 @@
#ifndef MULTI_CPU
EXPORT_SYMBOL(cpu_dcache_clean_area);
+#ifdef CONFIG_MMU
EXPORT_SYMBOL(cpu_set_pte_ext);
+#endif
#else
EXPORT_SYMBOL(processor);
#endif
--
1.8.0
^ permalink raw reply related
* [PATCH 6/6] ARM: integrator: ensure ap_syscon_base is initialised when !CONFIG_MMU
From: Will Deacon @ 2013-01-30 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359556069-28289-1-git-send-email-will.deacon@arm.com>
When running on Integrator/AP using atags, ap_syscon_base is initialised
in ->map_io, which isn't called for !MMU platforms.
Instead, initialise the pointer in ->machine_init, as we do when booting
with device-tree.
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/mach-integrator/integrator_ap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-integrator/integrator_ap.c b/arch/arm/mach-integrator/integrator_ap.c
index 11e2a41..26762bf 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -613,7 +613,6 @@ static struct map_desc ap_io_desc_atag[] __initdata = {
static void __init ap_map_io_atag(void)
{
iotable_init(ap_io_desc_atag, ARRAY_SIZE(ap_io_desc_atag));
- ap_syscon_base = __io_address(INTEGRATOR_SC_BASE);
ap_map_io();
}
@@ -685,6 +684,7 @@ static void __init ap_init(void)
platform_device_register(&cfi_flash_device);
+ ap_syscon_base = __io_address(INTEGRATOR_SC_BASE);
sc_dec = readl(ap_syscon_base + INTEGRATOR_SC_DEC_OFFSET);
for (i = 0; i < 4; i++) {
struct lm_device *lmdev;
--
1.8.0
^ permalink raw reply related
* [PATCH v3] cpufreq: instantiate cpufreq-cpu0 as a platform_driver
From: Shawn Guo @ 2013-01-30 14:27 UTC (permalink / raw)
To: linux-arm-kernel
As multiplatform build is being adopted by more and more ARM platforms,
initcall function should be used very carefully. For example, when
GENERIC_CPUFREQ_CPU0 is built in the kernel, cpu0_cpufreq_driver_init()
will be called on all the platforms to initialize cpufreq-cpu0 driver.
To eliminate this undesired the effect, the patch changes cpufreq-cpu0
driver to have it instantiated as a platform_driver. Then it will only
run on platforms that create the platform_device "cpufreq-cpu0".
Along with the change, it also changes cpu_dev to be &pdev->dev,
so that managed functions can start working, and module build gets
supported too.
The highbank-cpufreq driver is also updated accordingly to adapt the
changes on cpufreq-cpu0.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Cc: Mark Langsdorf <mark.langsdorf@calxeda.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
---
Changes since v2:
* Leave out omap2/am33xx bits to avoid conflicts with omap tree
drivers/cpufreq/Kconfig | 2 +-
drivers/cpufreq/cpufreq-cpu0.c | 35 +++++++++++++++++++++++------------
drivers/cpufreq/highbank-cpufreq.c | 5 +++++
3 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index ea512f4..774dc1c 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -180,7 +180,7 @@ config CPU_FREQ_GOV_CONSERVATIVE
If in doubt, say N.
config GENERIC_CPUFREQ_CPU0
- bool "Generic CPU0 cpufreq driver"
+ tristate "Generic CPU0 cpufreq driver"
depends on HAVE_CLK && REGULATOR && PM_OPP && OF
select CPU_FREQ_TABLE
help
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 90e9d73..519c2f7 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -12,12 +12,12 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/clk.h>
-#include <linux/cpu.h>
#include <linux/cpufreq.h>
#include <linux/err.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/opp.h>
+#include <linux/platform_device.h>
#include <linux/regulator/consumer.h>
#include <linux/slab.h>
@@ -174,7 +174,7 @@ static struct cpufreq_driver cpu0_cpufreq_driver = {
.attr = cpu0_cpufreq_attr,
};
-static int cpu0_cpufreq_driver_init(void)
+static int cpu0_cpufreq_probe(struct platform_device *pdev)
{
struct device_node *np;
int ret;
@@ -189,23 +189,17 @@ static int cpu0_cpufreq_driver_init(void)
return -ENOENT;
}
- cpu_dev = get_cpu_device(0);
- if (!cpu_dev) {
- pr_err("failed to get cpu0 device\n");
- ret = -ENODEV;
- goto out_put_node;
- }
-
+ cpu_dev = &pdev->dev;
cpu_dev->of_node = np;
- cpu_clk = clk_get(cpu_dev, NULL);
+ cpu_clk = devm_clk_get(cpu_dev, NULL);
if (IS_ERR(cpu_clk)) {
ret = PTR_ERR(cpu_clk);
pr_err("failed to get cpu0 clock: %d\n", ret);
goto out_put_node;
}
- cpu_reg = regulator_get(cpu_dev, "cpu0");
+ cpu_reg = devm_regulator_get(cpu_dev, "cpu0");
if (IS_ERR(cpu_reg)) {
pr_warn("failed to get cpu0 regulator\n");
cpu_reg = NULL;
@@ -266,7 +260,24 @@ out_put_node:
of_node_put(np);
return ret;
}
-late_initcall(cpu0_cpufreq_driver_init);
+
+static int cpu0_cpufreq_remove(struct platform_device *pdev)
+{
+ cpufreq_unregister_driver(&cpu0_cpufreq_driver);
+ opp_free_cpufreq_table(cpu_dev, &freq_table);
+
+ return 0;
+}
+
+static struct platform_driver cpu0_cpufreq_platdrv = {
+ .driver = {
+ .name = "cpufreq-cpu0",
+ .owner = THIS_MODULE,
+ },
+ .probe = cpu0_cpufreq_probe,
+ .remove = cpu0_cpufreq_remove,
+};
+module_platform_driver(cpu0_cpufreq_platdrv);
MODULE_AUTHOR("Shawn Guo <shawn.guo@linaro.org>");
MODULE_DESCRIPTION("Generic CPU0 cpufreq driver");
diff --git a/drivers/cpufreq/highbank-cpufreq.c b/drivers/cpufreq/highbank-cpufreq.c
index 2ea6276..0491f1f 100644
--- a/drivers/cpufreq/highbank-cpufreq.c
+++ b/drivers/cpufreq/highbank-cpufreq.c
@@ -20,6 +20,7 @@
#include <linux/err.h>
#include <linux/of.h>
#include <linux/mailbox.h>
+#include <linux/platform_device.h>
#define HB_CPUFREQ_CHANGE_NOTE 0x80000001
#define HB_CPUFREQ_IPC_LEN 7
@@ -65,6 +66,7 @@ static struct notifier_block hb_cpufreq_clk_nb = {
static int hb_cpufreq_driver_init(void)
{
+ struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
struct device *cpu_dev;
struct clk *cpu_clk;
struct device_node *np;
@@ -104,6 +106,9 @@ static int hb_cpufreq_driver_init(void)
goto out_put_node;
}
+ /* Instantiate cpufreq-cpu0 */
+ platform_device_register_full(&devinfo);
+
out_put_node:
of_node_put(np);
return ret;
--
1.7.9.5
^ permalink raw reply related
* [PATCH] ARM: omap2: register cpufreq-cpu0 device for am33xx
From: Shawn Guo @ 2013-01-30 14:32 UTC (permalink / raw)
To: linux-arm-kernel
The cpufreq-cpu0 driver changes to instantiate use platform_driver
mechanism. The patch is an am33xx platform level adaptation for it.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
arch/arm/mach-omap2/board-generic.c | 1 +
arch/arm/mach-omap2/cclock33xx_data.c | 2 +-
arch/arm/mach-omap2/common.h | 1 +
arch/arm/mach-omap2/io.c | 8 ++++++++
4 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 53cb380b..b945480 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -139,6 +139,7 @@ DT_MACHINE_START(AM33XX_DT, "Generic AM33XX (Flattened Device Tree)")
.init_irq = omap_intc_of_init,
.handle_irq = omap3_intc_handle_irq,
.init_machine = omap_generic_init,
+ .init_late = am33xx_init_late,
.timer = &omap3_am33xx_timer,
.dt_compat = am33xx_boards_compat,
MACHINE_END
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c
index ea64ad6..acb1620 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -850,7 +850,7 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, "dpll_core_m5_ck", &dpll_core_m5_ck, CK_AM33XX),
CLK(NULL, "dpll_core_m6_ck", &dpll_core_m6_ck, CK_AM33XX),
CLK(NULL, "dpll_mpu_ck", &dpll_mpu_ck, CK_AM33XX),
- CLK("cpu0", NULL, &dpll_mpu_ck, CK_AM33XX),
+ CLK("cpufreq-cpu0.0", NULL, &dpll_mpu_ck, CK_AM33XX),
CLK(NULL, "dpll_mpu_m2_ck", &dpll_mpu_m2_ck, CK_AM33XX),
CLK(NULL, "dpll_ddr_ck", &dpll_ddr_ck, CK_AM33XX),
CLK(NULL, "dpll_ddr_m2_ck", &dpll_ddr_m2_ck, CK_AM33XX),
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 948bcaa..e3355df5 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -106,6 +106,7 @@ void omap2430_init_late(void);
void omap3430_init_late(void);
void omap35xx_init_late(void);
void omap3630_init_late(void);
+void am33xx_init_late(void);
void am35xx_init_late(void);
void ti81xx_init_late(void);
void omap4430_init_late(void);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 2c3fdd6..0e67711 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -535,6 +535,14 @@ void __init omap3630_init_late(void)
omap2_clk_enable_autoidle_all();
}
+void __init am33xx_init_late(void)
+{
+ struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
+
+ if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0))
+ platform_device_register_full(&devinfo);
+}
+
void __init am35xx_init_late(void)
{
omap_mux_late_init();
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3] cpufreq: instantiate cpufreq-cpu0 as a platform_driver
From: Mark Langsdorf @ 2013-01-30 14:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359556069-16962-1-git-send-email-shawn.guo@linaro.org>
On 01/30/2013 08:27 AM, Shawn Guo wrote:
> As multiplatform build is being adopted by more and more ARM platforms,
> initcall function should be used very carefully. For example, when
> GENERIC_CPUFREQ_CPU0 is built in the kernel, cpu0_cpufreq_driver_init()
> will be called on all the platforms to initialize cpufreq-cpu0 driver.
>
> To eliminate this undesired the effect, the patch changes cpufreq-cpu0
> driver to have it instantiated as a platform_driver. Then it will only
> run on platforms that create the platform_device "cpufreq-cpu0".
>
> Along with the change, it also changes cpu_dev to be &pdev->dev,
> so that managed functions can start working, and module build gets
> supported too.
>
> The highbank-cpufreq driver is also updated accordingly to adapt the
> changes on cpufreq-cpu0.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> Cc: Mark Langsdorf <mark.langsdorf@calxeda.com>
> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
Acked-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
--Mark Langsdorf
Calxeda, Inc.
> Changes since v2:
> * Leave out omap2/am33xx bits to avoid conflicts with omap tree
>
> drivers/cpufreq/Kconfig | 2 +-
> drivers/cpufreq/cpufreq-cpu0.c | 35 +++++++++++++++++++++++------------
> drivers/cpufreq/highbank-cpufreq.c | 5 +++++
> 3 files changed, 29 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> index ea512f4..774dc1c 100644
> --- a/drivers/cpufreq/Kconfig
> +++ b/drivers/cpufreq/Kconfig
> @@ -180,7 +180,7 @@ config CPU_FREQ_GOV_CONSERVATIVE
> If in doubt, say N.
>
> config GENERIC_CPUFREQ_CPU0
> - bool "Generic CPU0 cpufreq driver"
> + tristate "Generic CPU0 cpufreq driver"
> depends on HAVE_CLK && REGULATOR && PM_OPP && OF
> select CPU_FREQ_TABLE
> help
> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> index 90e9d73..519c2f7 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++ b/drivers/cpufreq/cpufreq-cpu0.c
> @@ -12,12 +12,12 @@
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> #include <linux/clk.h>
> -#include <linux/cpu.h>
> #include <linux/cpufreq.h>
> #include <linux/err.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/opp.h>
> +#include <linux/platform_device.h>
> #include <linux/regulator/consumer.h>
> #include <linux/slab.h>
>
> @@ -174,7 +174,7 @@ static struct cpufreq_driver cpu0_cpufreq_driver = {
> .attr = cpu0_cpufreq_attr,
> };
>
> -static int cpu0_cpufreq_driver_init(void)
> +static int cpu0_cpufreq_probe(struct platform_device *pdev)
> {
> struct device_node *np;
> int ret;
> @@ -189,23 +189,17 @@ static int cpu0_cpufreq_driver_init(void)
> return -ENOENT;
> }
>
> - cpu_dev = get_cpu_device(0);
> - if (!cpu_dev) {
> - pr_err("failed to get cpu0 device\n");
> - ret = -ENODEV;
> - goto out_put_node;
> - }
> -
> + cpu_dev = &pdev->dev;
> cpu_dev->of_node = np;
>
> - cpu_clk = clk_get(cpu_dev, NULL);
> + cpu_clk = devm_clk_get(cpu_dev, NULL);
> if (IS_ERR(cpu_clk)) {
> ret = PTR_ERR(cpu_clk);
> pr_err("failed to get cpu0 clock: %d\n", ret);
> goto out_put_node;
> }
>
> - cpu_reg = regulator_get(cpu_dev, "cpu0");
> + cpu_reg = devm_regulator_get(cpu_dev, "cpu0");
> if (IS_ERR(cpu_reg)) {
> pr_warn("failed to get cpu0 regulator\n");
> cpu_reg = NULL;
> @@ -266,7 +260,24 @@ out_put_node:
> of_node_put(np);
> return ret;
> }
> -late_initcall(cpu0_cpufreq_driver_init);
> +
> +static int cpu0_cpufreq_remove(struct platform_device *pdev)
> +{
> + cpufreq_unregister_driver(&cpu0_cpufreq_driver);
> + opp_free_cpufreq_table(cpu_dev, &freq_table);
> +
> + return 0;
> +}
> +
> +static struct platform_driver cpu0_cpufreq_platdrv = {
> + .driver = {
> + .name = "cpufreq-cpu0",
> + .owner = THIS_MODULE,
> + },
> + .probe = cpu0_cpufreq_probe,
> + .remove = cpu0_cpufreq_remove,
> +};
> +module_platform_driver(cpu0_cpufreq_platdrv);
>
> MODULE_AUTHOR("Shawn Guo <shawn.guo@linaro.org>");
> MODULE_DESCRIPTION("Generic CPU0 cpufreq driver");
> diff --git a/drivers/cpufreq/highbank-cpufreq.c b/drivers/cpufreq/highbank-cpufreq.c
> index 2ea6276..0491f1f 100644
> --- a/drivers/cpufreq/highbank-cpufreq.c
> +++ b/drivers/cpufreq/highbank-cpufreq.c
> @@ -20,6 +20,7 @@
> #include <linux/err.h>
> #include <linux/of.h>
> #include <linux/mailbox.h>
> +#include <linux/platform_device.h>
>
> #define HB_CPUFREQ_CHANGE_NOTE 0x80000001
> #define HB_CPUFREQ_IPC_LEN 7
> @@ -65,6 +66,7 @@ static struct notifier_block hb_cpufreq_clk_nb = {
>
> static int hb_cpufreq_driver_init(void)
> {
> + struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
> struct device *cpu_dev;
> struct clk *cpu_clk;
> struct device_node *np;
> @@ -104,6 +106,9 @@ static int hb_cpufreq_driver_init(void)
> goto out_put_node;
> }
>
> + /* Instantiate cpufreq-cpu0 */
> + platform_device_register_full(&devinfo);
> +
> out_put_node:
> of_node_put(np);
> return ret;
>
^ permalink raw reply
* [PATCH v3] ARM: OMAP2: am33xx-hwmod: Fix "register offset NULL check" bug
From: Hebbar Gururaja @ 2013-01-30 14:39 UTC (permalink / raw)
To: linux-arm-kernel
am33xx_cm_wait_module_ready() checks if register offset is NULL.
int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
{
int i = 0;
if (!clkctrl_offs)
return 0;
In case of AM33xx, CLKCTRL register offset for different clock domains
are not uniformly placed. An example of this would be the RTC clock
domain with CLKCTRL offset at 0x00.
In such cases the module ready check is skipped which leads to a data
abort during boot-up when RTC registers is accessed.
Remove this check here to avoid checking module readiness for modules
with clkctrl register offset at 0x00.
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
---
Changes in v3:
- Since now there is separate cm33xx.c file which handles module
ready checking for am33xx platform, use the same for the fix.
- Also update subject to indicate am33xx platform name
Changes in v2:
- update commit message to reflect the actual cause. Previous
message conveyed a wrong/opposite message.
:100644 100644 058ce3c... 325a515... M arch/arm/mach-omap2/cm33xx.c
arch/arm/mach-omap2/cm33xx.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cm33xx.c b/arch/arm/mach-omap2/cm33xx.c
index 058ce3c..325a515 100644
--- a/arch/arm/mach-omap2/cm33xx.c
+++ b/arch/arm/mach-omap2/cm33xx.c
@@ -241,9 +241,6 @@ int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
{
int i = 0;
- if (!clkctrl_offs)
- return 0;
-
omap_test_timeout(_is_module_ready(inst, cdoffs, clkctrl_offs),
MAX_MODULE_READY_TIME, i);
--
1.7.9.5
^ permalink raw reply related
* linux-next: manual merge of the samsung tree with the arm-soc tree
From: Stephen Rothwell @ 2013-01-30 14:48 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kukjin,
Today's linux-next merge of the samsung tree got a conflict in
drivers/gpio/gpio-samsung.c between commits f69254328793 ("ARM: dts: Fix
compatible value of pinctrl module on EXYNOS5440") and b533c8685b16
("ARM: dts: fix compatible value for exynos pinctrl") from the arm-soc
tree and commit bda7f6d4e198 ("gpio: samsung: skip gpiolib registration
if pinctrl support is enabled for exynos5250") from the samsung tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
diff --cc drivers/gpio/gpio-samsung.c
index b2016ed,0d46db6..0000000
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@@ -3023,9 -3023,9 +3022,10 @@@ static __init int samsung_gpiolib_init(
*/
struct device_node *pctrl_np;
static const struct of_device_id exynos_pinctrl_ids[] = {
- { .compatible = "samsung,pinctrl-exynos4210", },
- { .compatible = "samsung,pinctrl-exynos4x12", },
- { .compatible = "samsung,pinctrl-exynos5250", },
+ { .compatible = "samsung,exynos4210-pinctrl", },
+ { .compatible = "samsung,exynos4x12-pinctrl", },
++ { .compatible = "samsung,exynos5250-pinctrl", },
+ { .compatible = "samsung,exynos5440-pinctrl", },
};
for_each_matching_node(pctrl_np, exynos_pinctrl_ids)
if (pctrl_np && of_device_is_available(pctrl_np))
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130131/740be2b8/attachment.sig>
^ permalink raw reply
* linux-next: manual merge of the samsung tree with the arm-soc tree
From: Stephen Rothwell @ 2013-01-30 14:48 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kukjin,
Today's linux-next merge of the samsung tree got a conflict in
arch/arm/mach-exynos/common.c between commit b533c8685b16 ("ARM: dts: fix
compatible value for exynos pinctrl") from the arm-soc tree and commit
d28a60d89c83 ("ARM: EXYNOS: skip wakeup interrupt registration for
exynos5250 if pinctrl is enabled") from the samsung tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
diff --cc arch/arm/mach-exynos/common.c
index 68c0689,cdaa55f..0000000
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@@ -1035,8 -1112,9 +1116,9 @@@ static int __init exynos_init_irq_eint(
* interrupt support code here can be completely removed.
*/
static const struct of_device_id exynos_pinctrl_ids[] = {
- { .compatible = "samsung,pinctrl-exynos4210", },
- { .compatible = "samsung,pinctrl-exynos4x12", },
- { .compatible = "samsung,pinctrl-exynos5250", },
+ { .compatible = "samsung,exynos4210-pinctrl", },
+ { .compatible = "samsung,exynos4x12-pinctrl", },
++ { .compatible = "samsung,exynos5250-pinctrl", },
};
struct device_node *pctrl_np, *wkup_np;
const char *wkup_compat = "samsung,exynos4210-wakeup-eint";
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130131/2c7bfc4e/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: tlb: perform branch predictor maintenance for whole invalidation
From: Dave Martin @ 2013-01-30 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359555125-27495-1-git-send-email-will.deacon@arm.com>
On Wed, Jan 30, 2013 at 02:12:05PM +0000, Will Deacon wrote:
> The ARM architecture requires explicit branch predictor maintenance
> when updating an instruction stream for a given virtual address. In
> reality, this isn't so much of a burden because the branch predictor
> is flushed during the cache maintenance required to make the new
> instructions visible to the I-side of the processor.
>
> One exception to this rule is when we flush the entire TLB for a CPU in
> response to something other than writing new instructions (for example,
> ASID rollover or switching to an identity mapping before disabling the
> MMU).
>
> This patch ensures that we flush the branch predictor as part of
> invalidating the entire TLB.
What about v6 implementations? Is the branch predictor flush implicit?
Cheers
---Dave
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/include/asm/tlbflush.h | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
> index 6e924d3..713ff32 100644
> --- a/arch/arm/include/asm/tlbflush.h
> +++ b/arch/arm/include/asm/tlbflush.h
> @@ -38,6 +38,7 @@
> #define TLB_V7_UIS_PAGE (1 << 19)
> #define TLB_V7_UIS_FULL (1 << 20)
> #define TLB_V7_UIS_ASID (1 << 21)
> +#define TLB_V7_UIS_BP (1 << 22)
>
> #define TLB_BARRIER (1 << 28)
> #define TLB_L2CLEAN_FR (1 << 29) /* Feroceon */
> @@ -166,9 +167,11 @@
> #endif
>
> #define v7wbi_tlb_flags_smp (TLB_WB | TLB_DCLEAN | TLB_BARRIER | \
> - TLB_V7_UIS_FULL | TLB_V7_UIS_PAGE | TLB_V7_UIS_ASID)
> + TLB_V7_UIS_FULL | TLB_V7_UIS_PAGE | \
> + TLB_V7_UIS_ASID | TLB_V7_UIS_BP)
> #define v7wbi_tlb_flags_up (TLB_WB | TLB_DCLEAN | TLB_BARRIER | \
> - TLB_V6_U_FULL | TLB_V6_U_PAGE | TLB_V6_U_ASID)
> + TLB_V6_U_FULL | TLB_V6_U_PAGE | \
> + TLB_V6_U_ASID)
>
> #ifdef CONFIG_CPU_TLB_V7
>
> @@ -330,6 +333,11 @@ static inline void local_flush_tlb_all(void)
> tlb_op(TLB_V4_I_FULL | TLB_V6_I_FULL, "c8, c5, 0", zero);
> tlb_op(TLB_V7_UIS_FULL, "c8, c3, 0", zero);
>
> + if (tlb_flag(TLB_V7_UIS_BP))
> + asm("mcr p15, 0, %0, c7, c1, 6" : : "r" (zero));
> + else
> + asm("mcr p15, 0, %0, c7, c5, 6" : : "r" (zero));
> +
> if (tlb_flag(TLB_BARRIER)) {
> dsb();
> isb();
> --
> 1.8.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] ARM i.MX6: Add regulator delay support
From: Shawn Guo @ 2013-01-30 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359585224-11304-1-git-send-email-b20788@freescale.com>
On Wed, Jan 30, 2013 at 05:33:44PM -0500, Anson Huang wrote:
> For ANATOP LDOs, vddcpu, vddsoc and vddpu
> have step time settings in the misc2 register, need
> to add necessary step time info for these three LDOs,
> then regulator driver can add necessary delay based on
> these settings.
>
> offset 0x170:
> bit [24-25]: vddcpu
> bit [26-27]: vddpu
> bit [28-29]: vddsoc
>
> field definition:
> 0'b00: 64 cycles of 24M clock;
> 0'b01: 128 cycles of 24M clock;
> 0'b02: 256 cycles of 24M clock;
> 0'b03: 512 cycles of 24M clock;
>
> Signed-off-by: Anson Huang <b20788@freescale.com>
Looks good. Will apply after the driver part gets accepted.
Shawn
> ---
> arch/arm/boot/dts/imx6q.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index d6265ca..a2e977d 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -480,6 +480,9 @@
> anatop-reg-offset = <0x140>;
> anatop-vol-bit-shift = <0>;
> anatop-vol-bit-width = <5>;
> + anatop-delay-reg-offset = <0x170>;
> + anatop-delay-bit-shift = <24>;
> + anatop-delay-bit-width = <2>;
> anatop-min-bit-val = <1>;
> anatop-min-voltage = <725000>;
> anatop-max-voltage = <1450000>;
> @@ -494,6 +497,9 @@
> anatop-reg-offset = <0x140>;
> anatop-vol-bit-shift = <9>;
> anatop-vol-bit-width = <5>;
> + anatop-delay-reg-offset = <0x170>;
> + anatop-delay-bit-shift = <26>;
> + anatop-delay-bit-width = <2>;
> anatop-min-bit-val = <1>;
> anatop-min-voltage = <725000>;
> anatop-max-voltage = <1450000>;
> @@ -508,6 +514,9 @@
> anatop-reg-offset = <0x140>;
> anatop-vol-bit-shift = <18>;
> anatop-vol-bit-width = <5>;
> + anatop-delay-reg-offset = <0x170>;
> + anatop-delay-bit-shift = <28>;
> + anatop-delay-bit-width = <2>;
> anatop-min-bit-val = <1>;
> anatop-min-voltage = <725000>;
> anatop-max-voltage = <1450000>;
> --
> 1.7.9.5
>
>
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Simon Baatz @ 2013-01-30 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5108F300.7000705@gmail.com>
Hi Sebastian,
On Wed, Jan 30, 2013 at 11:16:32AM +0100, Sebastian Hesselbarth wrote:
> On 01/30/2013 09:30 AM, Simon Baatz wrote:
> >On Wed, Jan 30, 2013 at 01:51:18AM +0100, Sebastian Hesselbarth wrote:
> >>- [PATCH v2 2/2] clk: mvebu: Do not gate runit clock on Kirkwood
> >> (no lockup for minimal kernel configs)
> >>
> >>- [PATCH] NET: mv643xx: get smi clock from device tree
> >> (no lockup for modular DT ethernet)
> >>
> >>- Some patch that adds MV643XX_ETH_SHARED_NAME ".0" and ".1" clk aliases
> >> (no lockup for modular non-DT ethernet)
> >
> >I think your patch to get the smi clock is intended for device tree.
> >Thus, the driver won't use these aliases, right?
>
> Actually, both patches above will not fix modular ethernet for 3.8-rc as
> shared driver is probed before core driver and not requesting any clk at
> all. The "NET: mv643xx: get smi clock from device tree" patch is based
> on Jason's attempt to separate shared driver.
>
> If we need to fix modular ethernet now, we also need to add a clk_get
> to shared ethernet.
>
> But yes, DT doesn't need any clock aliases.
>
> >>- Some patch that adds clk_prepare_enable to ge0/ge1 clocks to
> >> kirkwood_legacy_clk_init()
> >> (retain MAC address for modular DT ethernet)
> >
> >I like mine better, since it only enables the clocks of the
> >interfaces that are initialized in the init code. I tested it with
> >non-DT as well. But either is fine with me.
>
> I know the difference, but here it is not only about fixing an issue
> but have it cleanly removed later on. But I don't have a strong opinion
> on that and maybe Andrew or Jason should coordinate what must be fixed
> now and how we do it.
Nitpicking here: For a DT aware driver on a DT board, the calls to
kirkwood_ge0[01]_init() need to be removed anyway (this is already
part of Jason's patches) and the clocks will not be enabled. Thus,
there is not need to cleanup anything for DT when keeping the
clk_prepare_enable in those functions (beyond what we need to do
anyhow).
But now I will shut up. I fully agree that letting Jason/Andrew
decide what to do is the best way forward.
- Simon
^ permalink raw reply
* [PATCH] ARM: at91/DT: remove atmel, use-dma-* from 9x5 and 9n12 USART nodes
From: Nicolas Ferre @ 2013-01-30 14:55 UTC (permalink / raw)
To: linux-arm-kernel
Fix the use of USART on both at91sam9x5 and at91sam9n12. In DTS, the
atmel,use-dma-[rx|tx] property is present but a DMA channel cannot be used.
Indeed the connexion between the DMA engine and the slave is not implemented
yet in Device Tree.
Note however that this property is also used for PDC (private DMA) on older
SoCs. This is why the driver alone cannot determine the validity of this
property.
Reported-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/at91sam9n12.dtsi | 8 --------
arch/arm/boot/dts/at91sam9x5.dtsi | 6 ------
2 files changed, 14 deletions(-)
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
index 80e29c6..4801717 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -324,8 +324,6 @@
compatible = "atmel,at91sam9260-usart";
reg = <0xf801c000 0x4000>;
interrupts = <5 4 5>;
- atmel,use-dma-rx;
- atmel,use-dma-tx;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usart0>;
status = "disabled";
@@ -335,8 +333,6 @@
compatible = "atmel,at91sam9260-usart";
reg = <0xf8020000 0x4000>;
interrupts = <6 4 5>;
- atmel,use-dma-rx;
- atmel,use-dma-tx;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usart1>;
status = "disabled";
@@ -346,8 +342,6 @@
compatible = "atmel,at91sam9260-usart";
reg = <0xf8024000 0x4000>;
interrupts = <7 4 5>;
- atmel,use-dma-rx;
- atmel,use-dma-tx;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usart2>;
status = "disabled";
@@ -357,8 +351,6 @@
compatible = "atmel,at91sam9260-usart";
reg = <0xf8028000 0x4000>;
interrupts = <8 4 5>;
- atmel,use-dma-rx;
- atmel,use-dma-tx;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usart3>;
status = "disabled";
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 0c60090..d112c3a 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -402,8 +402,6 @@
compatible = "atmel,at91sam9260-usart";
reg = <0xf801c000 0x200>;
interrupts = <5 4 5>;
- atmel,use-dma-rx;
- atmel,use-dma-tx;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usart0>;
status = "disabled";
@@ -413,8 +411,6 @@
compatible = "atmel,at91sam9260-usart";
reg = <0xf8020000 0x200>;
interrupts = <6 4 5>;
- atmel,use-dma-rx;
- atmel,use-dma-tx;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usart1>;
status = "disabled";
@@ -424,8 +420,6 @@
compatible = "atmel,at91sam9260-usart";
reg = <0xf8024000 0x200>;
interrupts = <7 4 5>;
- atmel,use-dma-rx;
- atmel,use-dma-tx;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usart2>;
status = "disabled";
--
1.8.0
^ 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