RE: [PATCH V2 1/7] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
Hi Thomas,
Sorry for top posting. My mailer is not allowing me any formatting.
I agree with both of your comments below.
I will post V3 for this.
Regards,
Sricharan
From: Thomas Gleixner [t...@linutronix.de]
Sent: Wednesday, October 30, 2013 8:45 PM
To: R, Sricharan
Cc: linux-ker...@vger.kernel.org; devicet...@vger.kernel.org;
linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
linux-omap@vger.kernel.org; linus.wall...@linaro.org; li...@arm.linux.org.uk;
t...@atomide.com; Nayak, Rajendra; marc.zyng...@arm.com;
grant.lik...@linaro.org; mark.rutl...@arm.com; robherri...@gmail.com;
Shilimkar, Santosh; Rob Herring
Subject: Re: [PATCH V2 1/7] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable
irqs
On Wed, 30 Oct 2013, Sricharan R wrote:
@@ -700,11 +709,22 @@ static int gic_irq_domain_xlate(struct irq_domain *d,
*out_hwirq = intspec[1] + 16;
/* For SPIs, we need to add 16 more to get the GIC irq ID number */
- if (!intspec[0])
+ if (!intspec[0]) {
*out_hwirq += 16;
Minor nit. This should be in the default implementation. The crossbar
implementation will fill out_hwirq in its own way and is not
interested in the +16 operation at all.
+ ret = gic_routable_irq_domain_ops-xlate(d, controller,
+ intspec,
+ intsize,
+ out_hwirq,
+ out_type);
+
+ gic-domain = irq_domain_add_legacy(node, gic_irqs, irq_base,
+ hwirq_base, gic_irq_domain_ops, gic);
+ } else {
+ if (WARN_ON(!gic_routable_irq_domain_ops))
+ return;
This warning is pointless, because you have default ops now.
+
+ gic-domain = irq_domain_add_linear(node, nr_routable_irqs,
+ gic_irq_domain_ops,
+ gic);
}
Thanks,
tglx--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2 2/7] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
Hi Thomas,
Again sorry for top post.
I agree and will fix both of the comments below.
Thanks for the reviews.
Regards,
Sricharan
From: Thomas Gleixner [t...@linutronix.de]
Sent: Wednesday, October 30, 2013 9:00 PM
To: R, Sricharan
Cc: linux-ker...@vger.kernel.org; devicet...@vger.kernel.org;
linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
linux-omap@vger.kernel.org; linus.wall...@linaro.org; li...@arm.linux.org.uk;
t...@atomide.com; Nayak, Rajendra; marc.zyng...@arm.com;
grant.lik...@linaro.org; mark.rutl...@arm.com; robherri...@gmail.com;
Shilimkar, Santosh; Rob Herring
Subject: Re: [PATCH V2 2/7] DRIVERS: IRQCHIP: CROSSBAR: Add support for
Crossbar IP
On Wed, 30 Oct 2013, Sricharan R wrote:
+static inline const u32 allocate_free_irq(int cb_no)
I understand the static inline part, but const u32 is more than
fishy. What's wrong with static inline int ?
+{
+ int i;
+
+ for (i = 0; i cb-int_max; i++) {
+ if (cb-irq_map[i] == IRQ_FREE) {
+ cb-irq_map[i] = cb_no;
+ return i;
+ }
+ }
+
+ return -ENODEV;
+}
+static int crossbar_domain_xlate(struct irq_domain *d,
+ struct device_node *controller,
+ const u32 *intspec, unsigned int intsize,
+ unsigned long *out_hwirq,
+ unsigned int *out_type)
+{
+ unsigned long ret = 0;
Why do you need to initialize ret when you assign a value to it in the
next line?
Thanks,
tglx--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] arm :omap :DMA: fix a bug on reserving the omap SDMA channels
Hi, On Sunday 30 December 2012 02:13 AM, ahema...@gmail.com wrote: From: ahemaily ahema...@gmail.com The variable dma_lch_count used for comparison (omap_dma_reserve_channels = dma_lch_count) before it initialized to the value from omap_dma_dev_attr : d-lch_count. I change the place of dma_lch_count initialization to be before the comparison. Signed-off-by: Abdelrahman Hemaily ahema...@gmail.com --- arch/arm/plat-omap/dma.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index c76ed8b..cb3e321 100644 --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -2014,12 +2014,12 @@ static int __devinit omap_system_dma_probe(struct platform_device *pdev) d = p-dma_attr; errata = p-errata; - + dma_lch_count = d-lch_count; + if ((d-dev_caps RESERVE_CHANNEL) omap_dma_reserve_channels (omap_dma_reserve_channels = dma_lch_count)) d-lch_count = omap_dma_reserve_channels; - dma_lch_count = d-lch_count; By removing this line, you are effectively not assigning d-lch_count after reserving. So the patch should only change dma_lch_count in the above if statement to d-lch_count Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32kHz clock removal causes problems omap_hsmmc
Hi, On Wednesday 19 December 2012 07:34 PM, Benoit Cousson wrote: On 12/19/2012 02:58 PM, Luciano Coelho wrote: On Wed, 2012-12-19 at 14:51 +0100, Benoit Cousson wrote: On 12/19/2012 02:01 PM, Felipe Balbi wrote: On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote: BTW: have you happened to ubdate u-boot recently? There is a nice easter egg added there: f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls. Which means that _essential_ clocks and pads are no longer configured. anything essential you can list ? Yeah, that u-boot version is just unusable at all with any mainline kernel, since we are still missing pads conf for every drivers. Regarding the 32k clock, I noticed as well that the OMAP4460 panda u-boot is the only one to enable it at boot time, and thus this is the only board that can probe the wilink chip properly as of today. Do you mean that with the latest mainline u-boot all boards will have trouble except panda? I don't know since the u-boot mainline has never ever supported properly the SDP4430, I stopped wasting my time with that code a long time ago. But the braves who tried using the latest u-boot mainline code that does not configure anything anymore had some troubles... Configuring every pad and clocks in the u-boot was removed to force kernel drivers to fix up things. Dependency on boot loader was always a problem. Bootloader should not configure anything apart from what is required for boot. Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4/Panda: u-boot upgrade v2012.04.01 - v2012.10 breaks RTC wakeups
Hi Kevin, In the latest, pad mux and clocks for all non-essential modules at U-BOOT were removed. This might also cause the problem. We can bring this back in u-boot by adding the following macros and check if it works fine again. include/configs/omap4_common.h -- #define CONFIG_SYS_ENABLE_PADS_ALL #define CONFIG_SYS_CLOCKS_ENABLE_ALL Regards, Sricharan On Wednesday 07 November 2012 06:23 AM, Santosh Shilimkar wrote: + Sricharan, On Tuesday 06 November 2012 06:46 PM, Kevin Hilman wrote: Hello, I just noticed that the kernel wakeup from suspend using RTC is broken after I upgraded u-boot from v2012.04.01 to v2012.10 on my OMAP4430/Panda and OMAP4460/Panda-ES. I haven't isolated the cause yet, but am hoping someone might have a pointer about where to start digging. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] ARM: OMAP: counter: add locking to read_persistent_clock
Hi Tony,
[snip..]
index dbf1e03..2bc51fb 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -55,22 +55,29 @@ static u32 notrace omap_32k_read_sched_clock(void)
* nsecs and adds to a monotonically increasing timespec.
*/
static struct timespec persistent_ts;
-static cycles_t cycles, last_cycles;
+static cycles_t cycles;
static unsigned int persistent_mult, persistent_shift;
+static DEFINE_SPINLOCK(read_persistent_clock_lock);
+
static void omap_read_persistent_clock(struct timespec *ts)
{
unsigned long long nsecs;
- cycles_t delta;
- struct timespec *tsp = persistent_ts;
+ cycles_t last_cycles;
+ unsigned long flags;
+
+ spin_lock_irqsave(read_persistent_clock_lock, flags);
last_cycles = cycles;
cycles = sync32k_cnt_reg ? __raw_readl(sync32k_cnt_reg) : 0;
- delta = cycles - last_cycles;
- nsecs = clocksource_cyc2ns(delta, persistent_mult, persistent_shift);
+ nsecs = clocksource_cyc2ns(cycles - last_cycles,
+ persistent_mult, persistent_shift);
..I think there's another bug here where cycles - last_cycles
returns wrong value when the timer wraps around as cycles_t is
64 bits and the counter is 32 bits. It seems it's been there
since when the read_persistent_clock was added with commit
d92cfcbe (OMAP: timekeeping: time should not stop during suspend)?
It seems that after this patch cycles should not be cycles_t
but u32, and the result of cycles - last_cycles should also
be u32.
cycles_t is defined as typedef unsigned long cycles_t;
Am i missing something here ?
Thanks,
Sricharan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3] ARM: LPAE: Fix mapping in alloc_init_pte for unaligned addresses.
With LPAE, When either the start address or end address
or physical address to be mapped is unaligned,
alloc_init_section creates page granularity mappings.
alloc_init_section calls alloc_init_pte which populates
one pmd entry and sets up the ptes. But if the size is
greater than what can be mapped by one pmd entry,
then the rest remains unmapped.
The issue becomes visible when LPAE is enabled, where we have
the 3 levels with seperate pgd and pmd's.
When a static mapping for 3MB is requested, only 2MB is mapped
and the remaining 1MB is unmapped. Fixing this here, by looping
in to map the entire unaligned address range.
Also the issue can be reproduced by enabling CMA + LPAE.
CMA tries to map 16MB with 2 level tables during boot.
Boot tested on OMAP5 evm with both LPAE enabled/disabled
and verified that static mappings with unaligned addresses
are properly mapped. Also the verified the boot with CMA and LPAE
enabled.
Signed-off-by: R Sricharan r.sricha...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Catalin Marinas catalin.mari...@arm.com
---
[V2] Moved the loop to alloc_init_pte as per Russell's
feedback and changed the subject accordingly.
Using PMD_XXX instead of SECTION_XXX to avoid
different loop increments with/without LPAE.
[v3] Removed the dummy variable phys and updated
the commit log for CMA case.
arch/arm/mm/mmu.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index c2fa21d..53c9787 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -579,11 +579,23 @@ static void __init alloc_init_pte(pmd_t *pmd, unsigned
long addr,
unsigned long end, unsigned long pfn,
const struct mem_type *type)
{
- pte_t *pte = early_pte_alloc(pmd, addr, type-prot_l1);
+ unsigned long next;
+ pte_t *pte;
+
do {
- set_pte_ext(pte, pfn_pte(pfn, __pgprot(type-prot_pte)), 0);
- pfn++;
- } while (pte++, addr += PAGE_SIZE, addr != end);
+ if ((end-addr) PMD_MASK)
+ next = (addr + PMD_SIZE) PMD_MASK;
+ else
+ next = end;
+
+ pte = early_pte_alloc(pmd, addr, type-prot_l1);
+ do {
+ set_pte_ext(pte, pfn_pte(pfn,
+ __pgprot(type-prot_pte)), 0);
+ pfn++;
+ } while (pte++, addr += PAGE_SIZE, addr != next);
+
+ } while (pmd++, addr = next, addr != end);
}
static void __init alloc_init_section(pud_t *pud, unsigned long addr,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] ARM: OMAP2+: Round of the carve out memory requested to section_size
memblock_steal tries to reserve physical memory during boot.
When the requested size is not aligned on the section size
then, the remaining memory available for lowmem becomes
unaligned on the section boundary. There is a issue with this,
which is discussed in the thread below.
https://lkml.org/lkml/2012/6/28/112
The final conclusion from the thread seems to
be align the memblock_steal calls on the SECTION boundary.
The issue comes out when LPAE is enabled, where the
section size is 2MB.
Boot tested this on OMAP5 evm with and without LPAE.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
[V2] Corrected the subject and added one more description line.
arch/arm/mach-omap2/omap-secure.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-secure.c
b/arch/arm/mach-omap2/omap-secure.c
index d9ae4a5..26edfec 100644
--- a/arch/arm/mach-omap2/omap-secure.c
+++ b/arch/arm/mach-omap2/omap-secure.c
@@ -61,8 +61,8 @@ int __init omap_secure_ram_reserve_memblock(void)
{
u32 size = OMAP_SECURE_RAM_STORAGE;
- size = ALIGN(size, SZ_1M);
- omap_secure_memblock_base = arm_memblock_steal(size, SZ_1M);
+ size = ALIGN(size, SECTION_SIZE);
+ omap_secure_memblock_base = arm_memblock_steal(size, SECTION_SIZE);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] ARM: OMAP: counter: add locking to read_persistent_clock
From: Colin Cross ccr...@android.com
read_persistent_clock uses a global variable, use a spinlock to
ensure non-atomic updates to the variable don't overlap and cause
time to move backwards.
Signed-off-by: Colin Cross ccr...@android.com
Signed-off-by: R Sricharan r.sricha...@ti.com
---
[V2] Added signed-off-by and looped in linux-arm-kernel list
arch/arm/plat-omap/counter_32k.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index dbf1e03..2bc51fb 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -55,22 +55,29 @@ static u32 notrace omap_32k_read_sched_clock(void)
* nsecs and adds to a monotonically increasing timespec.
*/
static struct timespec persistent_ts;
-static cycles_t cycles, last_cycles;
+static cycles_t cycles;
static unsigned int persistent_mult, persistent_shift;
+static DEFINE_SPINLOCK(read_persistent_clock_lock);
+
static void omap_read_persistent_clock(struct timespec *ts)
{
unsigned long long nsecs;
- cycles_t delta;
- struct timespec *tsp = persistent_ts;
+ cycles_t last_cycles;
+ unsigned long flags;
+
+ spin_lock_irqsave(read_persistent_clock_lock, flags);
last_cycles = cycles;
cycles = sync32k_cnt_reg ? __raw_readl(sync32k_cnt_reg) : 0;
- delta = cycles - last_cycles;
- nsecs = clocksource_cyc2ns(delta, persistent_mult, persistent_shift);
+ nsecs = clocksource_cyc2ns(cycles - last_cycles,
+ persistent_mult, persistent_shift);
+
+ timespec_add_ns(persistent_ts, nsecs);
+
+ *ts = persistent_ts;
- timespec_add_ns(tsp, nsecs);
- *ts = *tsp;
+ spin_unlock_irqrestore(read_persistent_clock_lock, flags);
}
/**
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ARM: mm: ADD descriptor string to CONFIG_DMA_ADDR_64BIT_T
Hi, On Wed, Sep 12, 2012 at 6:55 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Wed, Sep 12, 2012 at 6:49 PM, Catalin Marinas catalin.mari...@arm.com wrote: On Wed, Sep 12, 2012 at 01:57:26PM +0100, Shilimkar, Santosh wrote: On Wed, Sep 12, 2012 at 6:16 PM, Cyril Chemparathy cy...@ti.com wrote: On 9/12/2012 1:50 AM, R Sricharan wrote: Even if CONFIG_DMA_ADDR_64BIT_T is enabled by the defconfig, the feature is not getting selected. Adding a string description in the Kconfig resolves this. But not sure if this is the right way to fix this. Shouldn't you be selecting this in your 64-bit dma address capable arch instead? Yes. The selection to enable CONFIG_DMA_ADDR_64BIT_T happens in the arch which needs it. Since this option was made as simple bool, looks like because of some KCONFIG magic, it was not getting selected. Adding some help text does fix the issue and thats is the patch all about. Are you sure you select this explicitly in Kconfig? It should not depend on a description. You are right. What I understood from the initial email was that this option was only added to the defconfig but ignored by the kernel as it's not a user selectable option (unless you add some text). That's right. Explicit KCONFIG select should work. yes. It works when enabled in arch/KCONFIG. Thanks. This patch is not needed then. Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH] ARM: mm: ADD descriptor string to CONFIG_DMA_ADDR_64BIT_T
Even if CONFIG_DMA_ADDR_64BIT_T is enabled by the defconfig, the feature is not getting selected. Adding a string description in the Kconfig resolves this. But not sure if this is the right way to fix this. Signed-off-by: R Sricharan r.sricha...@ti.com Cc: Catalin Marinas catalin.mari...@arm.com --- arch/arm/mm/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig index 101b968..90c5ea4 100644 --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -601,7 +601,7 @@ config ARCH_PHYS_ADDR_T_64BIT def_bool ARM_LPAE config ARCH_DMA_ADDR_T_64BIT - bool + bool 64bit capable DMA device config ARM_THUMB bool Support Thumb user binaries -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: TEMP: Round of the carve out memory requested to section_size
memblock_steal tries to reserve physical memory during boot.
When the requested size is not aligned on the section size
then, the remaining memory available for lowmem becomes
unaligned on the section boundary. There is a issue with this,
which is discussed in the thread below.
https://lkml.org/lkml/2012/6/28/112
The final conclusion from the thread seems to
be align the memblock_steal calls on the SECTION boundary.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/omap-secure.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-secure.c
b/arch/arm/mach-omap2/omap-secure.c
index d9ae4a5..26edfec 100644
--- a/arch/arm/mach-omap2/omap-secure.c
+++ b/arch/arm/mach-omap2/omap-secure.c
@@ -61,8 +61,8 @@ int __init omap_secure_ram_reserve_memblock(void)
{
u32 size = OMAP_SECURE_RAM_STORAGE;
- size = ALIGN(size, SZ_1M);
- omap_secure_memblock_base = arm_memblock_steal(size, SZ_1M);
+ size = ALIGN(size, SECTION_SIZE);
+ omap_secure_memblock_base = arm_memblock_steal(size, SECTION_SIZE);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: counter: add locking to read_persistent_clock
From: Colin Cross ccr...@android.com
read_persistent_clock uses a global variable, use a spinlock to
ensure non-atomic updates to the variable don't overlap and cause
time to move backwards.
Signed-off-by: Colin Cross ccr...@android.com
---
arch/arm/plat-omap/counter_32k.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index dbf1e03..2bc51fb 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -55,22 +55,29 @@ static u32 notrace omap_32k_read_sched_clock(void)
* nsecs and adds to a monotonically increasing timespec.
*/
static struct timespec persistent_ts;
-static cycles_t cycles, last_cycles;
+static cycles_t cycles;
static unsigned int persistent_mult, persistent_shift;
+static DEFINE_SPINLOCK(read_persistent_clock_lock);
+
static void omap_read_persistent_clock(struct timespec *ts)
{
unsigned long long nsecs;
- cycles_t delta;
- struct timespec *tsp = persistent_ts;
+ cycles_t last_cycles;
+ unsigned long flags;
+
+ spin_lock_irqsave(read_persistent_clock_lock, flags);
last_cycles = cycles;
cycles = sync32k_cnt_reg ? __raw_readl(sync32k_cnt_reg) : 0;
- delta = cycles - last_cycles;
- nsecs = clocksource_cyc2ns(delta, persistent_mult, persistent_shift);
+ nsecs = clocksource_cyc2ns(cycles - last_cycles,
+ persistent_mult, persistent_shift);
+
+ timespec_add_ns(persistent_ts, nsecs);
+
+ *ts = persistent_ts;
- timespec_add_ns(tsp, nsecs);
- *ts = *tsp;
+ spin_unlock_irqrestore(read_persistent_clock_lock, flags);
}
/**
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: OMAP2+: Move the stubbed prm and cm functions to prcm.c file and make them __weak.
Hi Paul, On Wed, Jul 4, 2012 at 8:49 PM, Paul Walmsley p...@pwsan.com wrote: Hi On Thu, 28 Jun 2012, R, Sricharan wrote: Ping.. Since the prcm.c cleanup series isn't ready yet, I've queued this modified version of your patch. Once the prcm.c cleanup series is ready, hopefully in the 3.7 time frame, we'll be able to get rid of all of these nasty stubs. Thanks a lot. I think this should help to get rid of the OMAP5 dependency. Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: OMAP2+: Move the stubbed prm and cm functions to prcm.c file and make them __weak.
Ping.. Thanks, Sricharan On Thu, Jun 14, 2012 at 5:26 PM, R, Sricharan r.sricha...@ti.com wrote: Hi Paul, Some prm and cm registers read/write and status functions are built only for some custom OMAP2+ builds and are stubbed in header files for other builds under ifdef statements. But this results in adding new CONFIG_ARCH_OMAPXXX checks when SOCs are added in the future. So move them to a common place for OMAP2+ and make them 'weak' implementations. Thanks for the patch. These stubs aren't needed any longer, so we can just get rid of them; no need to mark them __weak. I've got a patch to just drop them here to be posted soon as part of a larger PRCM cleanup. Is the PRCM cleanup series available now ? Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Crash with VMALLOC api
Hi David, On Mon, Jun 25, 2012 at 2:17 AM, David Rientjes rient...@google.com wrote: On Sat, 23 Jun 2012, R, Sricharan wrote: Hi, I am observing a below crash with VMALLOC call on mainline kernel. The issue happens when there is insufficent vmalloc space. Isn't it expected that the API should return a NULL instead of crashing when there is not enough memory?. Yes. This can be reproduced with succesive vmalloc calls for a size of about say 10MB, without a vfree, thus exhausting the memory. Strangely when vmalloc is requested for a large chunk, then at that time API does not crash instead returns a NULL correctly. Please correct me if my understanding is not correct.. -- [ 345.059841] Unable to handle kernel paging request at virtual address 90011000 [ 345.067063] pgd = ebc34000 [ 345.069793] [90011000] *pgd= [ 345.073383] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 345.078685] Modules linked in: bcmdhd cfg80211 inv_mpu_ak8975 inv_mpu_kxtf9 mpu3050 [ 345.086380] CPU: 0 Tainted: G W (3.4.0-rc1-05660-g0d4b175 #1) [ 345.093351] PC is at vmap_page_range_noflush+0xf0/0x200 [ 345.098569] LR is at vmap_page_range+0x14/0x50 [ 345.103005] pc : [c01091c8] lr : [c01092ec] psr: 8013 [ 345.103009] sp : ebc41e38 ip : fe000fff fp : 2000 [ 345.114472] r10: c0a78480 r9 : 90011000 r8 : c096e2ac [ 345.119685] r7 : 90011000 r6 : r5 : fe00 r4 : [ 345.126198] r3 : 50011452 r2 : f385c400 r1 : fe000fff r0 : f385c400 [ 345.132713] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 345.139835] Control: 10c5387d Table: abc3404a DAC: 0015 Couple requests: - since you're already running an -rc kernel, would it be possible to try 3.5-rc4, which was released today, instead? - could you disassemble vmap_page_range_noflush and post the output or map the offset back to the line in the code? Thanks a lot for the response. Debugged this further and the real issue was because of static mapping for a 1MB io page and the vmalloc mapping for a 1MB dram page falling in to one PGD entry (PGDIR_SHIFT is 0x21). While trying to setup the pagetables for the dram page, the PGD entry of static io map is used, resulting in the paging fault. This was because of a recent change that brought the static io mappings under the vmalloc space. Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Crash with VMALLOC api
Hi, BTW i was facing the issue on OMAP4430 SDP platform with mainline. Thanks, Sricharan On Sat, Jun 23, 2012 at 11:28 AM, R, Sricharan r.sricha...@ti.com wrote: Hi, I am observing a below crash with VMALLOC call on mainline kernel. The issue happens when there is insufficent vmalloc space. Isn't it expected that the API should return a NULL instead of crashing when there is not enough memory?. This can be reproduced with succesive vmalloc calls for a size of about say 10MB, without a vfree, thus exhausting the memory. Strangely when vmalloc is requested for a large chunk, then at that time API does not crash instead returns a NULL correctly. Please correct me if my understanding is not correct.. -- [ 345.059841] Unable to handle kernel paging request at virtual address 90011000 [ 345.067063] pgd = ebc34000 [ 345.069793] [90011000] *pgd= [ 345.073383] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 345.078685] Modules linked in: bcmdhd cfg80211 inv_mpu_ak8975 inv_mpu_kxtf9 mpu3050 [ 345.086380] CPU: 0 Tainted: G W (3.4.0-rc1-05660-g0d4b175 #1) [ 345.093351] PC is at vmap_page_range_noflush+0xf0/0x200 [ 345.098569] LR is at vmap_page_range+0x14/0x50 [ 345.103005] pc : [c01091c8] lr : [c01092ec] psr: 8013 [ 345.103009] sp : ebc41e38 ip : fe000fff fp : 2000 [ 345.114472] r10: c0a78480 r9 : 90011000 r8 : c096e2ac [ 345.119685] r7 : 90011000 r6 : r5 : fe00 r4 : [ 345.126198] r3 : 50011452 r2 : f385c400 r1 : fe000fff r0 : f385c400 [ 345.132713] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 345.139835] Control: 10c5387d Table: abc3404a DAC: 0015 Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Crash with VMALLOC api
Hi, I am observing a below crash with VMALLOC call on mainline kernel. The issue happens when there is insufficent vmalloc space. Isn't it expected that the API should return a NULL instead of crashing when there is not enough memory?. This can be reproduced with succesive vmalloc calls for a size of about say 10MB, without a vfree, thus exhausting the memory. Strangely when vmalloc is requested for a large chunk, then at that time API does not crash instead returns a NULL correctly. Please correct me if my understanding is not correct.. -- [ 345.059841] Unable to handle kernel paging request at virtual address 90011000 [ 345.067063] pgd = ebc34000 [ 345.069793] [90011000] *pgd= [ 345.073383] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 345.078685] Modules linked in: bcmdhd cfg80211 inv_mpu_ak8975 inv_mpu_kxtf9 mpu3050 [ 345.086380] CPU: 0Tainted: GW (3.4.0-rc1-05660-g0d4b175 #1) [ 345.093351] PC is at vmap_page_range_noflush+0xf0/0x200 [ 345.098569] LR is at vmap_page_range+0x14/0x50 [ 345.103005] pc : [c01091c8]lr : [c01092ec]psr: 8013 [ 345.103009] sp : ebc41e38 ip : fe000fff fp : 2000 [ 345.114472] r10: c0a78480 r9 : 90011000 r8 : c096e2ac [ 345.119685] r7 : 90011000 r6 : r5 : fe00 r4 : [ 345.126198] r3 : 50011452 r2 : f385c400 r1 : fe000fff r0 : f385c400 [ 345.132713] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 345.139835] Control: 10c5387d Table: abc3404a DAC: 0015 Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: OMAP2+: Move the stubbed prm and cm functions to prcm.c file and make them __weak.
Hi Paul, Some prm and cm registers read/write and status functions are built only for some custom OMAP2+ builds and are stubbed in header files for other builds under ifdef statements. But this results in adding new CONFIG_ARCH_OMAPXXX checks when SOCs are added in the future. So move them to a common place for OMAP2+ and make them 'weak' implementations. Thanks for the patch. These stubs aren't needed any longer, so we can just get rid of them; no need to mark them __weak. I've got a patch to just drop them here to be posted soon as part of a larger PRCM cleanup. Is the PRCM cleanup series available now ? Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] ARM: OMAP5: Add minimal OMAP5 SOC support
Tony, Thanks for you suggestions OMAP5 V2 series is ready with all comments addressed, but I have below dependencies to be merged to apply my series against your cleanup-soc branch OK 1) git://git.pwsan.com/linux-2.6 hwmod_soc_conditional_cleanup_3.5 This one is not merged in yet and it seems that we're out of time for v3.5 unless it drags on and we have -rc8 after -rc7. OK 2) git://git.pwsan.com/linux-2.6 hwmod_data_cleanup_3.5 3) https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup These two are merged in arm-soc now. OK 4) http://www.spinics.net/lists/arm-kernel/msg174461.html I think this series still has some pending comments? Yes, right. In fact except for the last patch, others should not be needed when rebased against paul's PRCM cleanups which is yet to be posted and [1] which is already acked now. 1) http://www.spinics.net/lists/linux-omap/msg70192.html Can you please let me know how you want me to prepare the series with these dependencies. Until these dependencies get cleared out, it seems that the best branch to base your patches is omap-cleanup-timer-for-v3.5 tag and just carry the pending patches for a little bit longer. Ok, will rebase against it then and then prepare the series with a couple of temporary patches that can be dropped when the above mentioned dependencies are sorted out. Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: OMAP2+: Introduce CONFIG_SOC_HAS_OMAP_DPLL macro
Vaibhav,
[snip]
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index d0ef57c..095bee8 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -156,7 +156,7 @@ struct dpll_data {
u8 min_divider;
u16 max_divider;
u8 modes;
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#ifdef CONFIG_SOC_HAS_OMAP_DPLL
void __iomem *autoidle_reg;
void __iomem *idlest_reg;
u32 autoidle_mask;
@@ -167,7 +167,7 @@ struct dpll_data {
u8 auto_recal_bit;
u8 recal_en_bit;
u8 recal_st_bit;
-# endif
+#endif
I had submitted similar patch recently, and Kevin had suggested that
Instead of adding config option, we shoule simply get rid of this ifdef
completely.
Refer to
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg68293.html
Waiting for Paul to conform here.
Thanks for pointing that out. Will check on this and Paul's PRCM series
cleanup series then.
Thanks,
Sricharan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: OMAP2+: Introduce CONFIG_SOC_HAS_OMAP_DPLL macro
Hi Vaibhav, Sricharan, Yesterday, Paul confirmed that, removing ifdef is the way to go. So just few mins back I had submitted patch for the same. http://permalink.gmane.org/gmane.linux.ports.arm.omap/76972 oh ya, was just looking at that. Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
Tony, [snip] So after the cleanup patch introducing CONFIG_SOC_OMAP4PLUS it can be changed as #ifdef (CONFIG_SOC_OMAP4PLUS) !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)) So this will avoid patching this for the future socs. ? Well it seems that we've come to a conclusion that if we introduce new config options, they should be based on features instead. So CONFIG_SOC_HAS_OMAPXYZ_BLAH rather than CONFIG_SOC_OMAP4PLUS. Sure thanks for clarifying. Then i will introduce a relevant config in my cleanup patch first and then add OMAP5. Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] ARM: OMAP5: id: Add cpu id for ES versions
Hi Roger,
+void __init omap5xxx_check_revision(void)
+{
+ u32 idcode;
+ u16 hawkeye;
+ u8 rev;
+
+ idcode = read_tap_reg(OMAP_TAP_IDCODE);
+ hawkeye = (idcode 12) 0x;
+ rev = (idcode 28) 0xff;
+ switch (hawkeye) {
+ case 0xb942:
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP5430_REV_ES1_0;
+ break;
+ case 1:
+ omap_revision = OMAP5430_REV_ES2_0;
+ break;
+ default:
+ omap_revision = OMAP5430_REV_ES1_0;
Default should always be the latest version supported. i.e. in this case
it should be OMAP5430_REV_ES2_0
ok thanks, will correct it.
Thanks,
Sricharan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] ARM: OMAP5: id: Add cpu id for ES versions
Hi J,
why do you duplicate this
+ break;
+ case 1:
+ omap_revision = OMAP5430_REV_ES2_0;
+ break;
do this
case 0:
+ default:
+ omap_revision = OMAP5430_REV_ES1_0;
+ }
+ break;
+
+ case 0xb998:
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP5432_REV_ES1_0;
+ break;
+ default:
ditto here
Agree. Will correct the redundancy.
Thanks,
Sricharan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: OMAP2+: Move stubbed secure_sram_reserve function to a common.c and call it __weak
omap_secure_ram_reserve_memblock is stubbed for OMAP1,2 only builds using a
ifdef check. But this results in adding CONFIG_ARCH_OMAPxx checks for
future socs that use the real function. So move this to common.c file and
call it __weak.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/plat-omap/common.c |9 +
arch/arm/plat-omap/include/plat/omap-secure.h |5 -
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 0a9b9a9..89a3723 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -77,3 +77,12 @@ void __init omap_init_consistent_dma_size(void)
init_consistent_dma_size(CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE 20);
#endif
}
+
+/*
+ * Stub function for OMAP2 so that common files
+ * continue to build when custom builds are used
+ */
+int __weak omap_secure_ram_reserve_memblock(void)
+{
+ return 0;
+}
diff --git a/arch/arm/plat-omap/include/plat/omap-secure.h
b/arch/arm/plat-omap/include/plat/omap-secure.h
index 8c7994c..0e4acd2 100644
--- a/arch/arm/plat-omap/include/plat/omap-secure.h
+++ b/arch/arm/plat-omap/include/plat/omap-secure.h
@@ -3,12 +3,7 @@
#include linux/types.h
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
extern int omap_secure_ram_reserve_memblock(void);
-#else
-static inline void omap_secure_ram_reserve_memblock(void)
-{ }
-#endif
#ifdef CONFIG_OMAP4_ERRATA_I688
extern int omap_barrier_reserve_memblock(void);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] ARM: OMAP2+: Misc cleanup part2
This is a continuation of the previous cleanup series from santosh.shilim...@ti.com [1]. Patches are outcome of the OMAP5 review suggestions from Tony/Benoit/Santosh/Rajendra. [1] http://www.spinics.net/lists/linux-omap/msg69730.html R Sricharan (4): ARM: OMAP2+: Introduce CONFIG_SOC_HAS_OMAP_DPLL macro ARM: OMAP2+: Move the stubbed prm and cm functions to prcm.c file and make them __weak. ARM: OMAP2+: Move stubbed secure_sram_reserve function to a common.c and call it __weak ARM: OMAP: counter-32k: Select the CR register offset using the IP scheme. arch/arm/mach-omap2/Kconfig |5 ++ arch/arm/mach-omap2/clock.c |2 +- arch/arm/mach-omap2/cminst44xx.h | 25 arch/arm/mach-omap2/prcm.c| 77 + arch/arm/mach-omap2/prm2xxx_3xxx.h| 65 - arch/arm/plat-omap/common.c |9 +++ arch/arm/plat-omap/counter_32k.c | 16 - arch/arm/plat-omap/include/plat/clock.h |4 +- arch/arm/plat-omap/include/plat/omap-secure.h |5 -- 9 files changed, 107 insertions(+), 101 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: OMAP2+: Move the stubbed prm and cm functions to prcm.c file and make them __weak.
Some prm and cm registers read/write and status functions
are built only for some custom OMAP2+ builds and are stubbed
in header files for other builds under ifdef statements.
But this results in adding new CONFIG_ARCH_OMAPXXX
checks when SOCs are added in the future. So move them
to a common place for OMAP2+ and make them 'weak' implementations.
This way no new ifdefs would be required in the future and also
cleans up the existing code.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/cminst44xx.h | 25
arch/arm/mach-omap2/prcm.c | 77
arch/arm/mach-omap2/prm2xxx_3xxx.h | 65 --
3 files changed, 77 insertions(+), 90 deletions(-)
diff --git a/arch/arm/mach-omap2/cminst44xx.h b/arch/arm/mach-omap2/cminst44xx.h
index a018a73..d69fdef 100644
--- a/arch/arm/mach-omap2/cminst44xx.h
+++ b/arch/arm/mach-omap2/cminst44xx.h
@@ -16,38 +16,13 @@ extern void omap4_cminst_clkdm_enable_hwsup(u8 part, s16
inst, u16 cdoffs);
extern void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs);
extern void omap4_cminst_clkdm_force_sleep(u8 part, s16 inst, u16 cdoffs);
extern void omap4_cminst_clkdm_force_wakeup(u8 part, s16 inst, u16 cdoffs);
-
extern int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16 cdoffs, u16
clkctrl_offs);
-
-# ifdef CONFIG_ARCH_OMAP4
extern int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs);
-
extern void omap4_cminst_module_enable(u8 mode, u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs);
extern void omap4_cminst_module_disable(u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs);
-
-# else
-
-static inline int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs,
- u16 clkctrl_offs)
-{
- return 0;
-}
-
-static inline void omap4_cminst_module_enable(u8 mode, u8 part, u16 inst,
- s16 cdoffs, u16 clkctrl_offs)
-{
-}
-
-static inline void omap4_cminst_module_disable(u8 part, u16 inst, s16 cdoffs,
-u16 clkctrl_offs)
-{
-}
-
-# endif
-
/*
* In an ideal world, we would not export these low-level functions,
* but this will probably take some time to fix properly
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 480f40a..9bc3f5d 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -164,3 +164,80 @@ void __init omap2_set_globals_prcm(struct omap_globals
*omap2_globals)
omap_cm_base_init();
}
}
+
+/*
+ * Stubbed functions so that common files
+ * continue to build when custom builds are used
+ */
+u32 __weak omap2_prm_read_mod_reg(s16 module, u16 idx)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+
+void __weak omap2_prm_write_mod_reg(u32 val, s16 module, u16 idx)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+}
+u32 __weak omap2_prm_rmw_mod_reg_bits(u32 mask, u32 bits,
+ s16 module, s16 idx)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+u32 __weak omap2_prm_set_mod_reg_bits(u32 bits, s16 module, s16 idx)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+u32 __weak omap2_prm_clear_mod_reg_bits(u32 bits, s16 module, s16 idx)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+u32 __weak omap2_prm_read_mod_bits_shift(s16 domain, s16 idx, u32 mask)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+int __weak omap2_prm_is_hardreset_asserted(s16 prm_mod, u8 shift)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+int __weak omap2_prm_assert_hardreset(s16 prm_mod, u8 shift)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+int __weak omap2_prm_deassert_hardreset(s16 prm_mod, u8 rst_shift,
+ u8 st_shift)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+
+int __weak omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs,
+ u16 clkctrl_offs)
+{
+ return 0;
+}
+
+void __weak omap4_cminst_module_enable(u8 mode, u8 part, u16 inst,
+ s16
[PATCH 1/4] ARM: OMAP2+: Introduce CONFIG_SOC_HAS_OMAP_DPLL macro
The DPLL ip was introduced and used in the OMAP3PLUS socs, while
OMAP2 had the APLL IP. There are some features which are common
to both ips, and some which are only applicable to DPLL ip's.
Currently CONFIG_ARCH_OMAP_XXX checks is used to conditionally
compile the additional features for every applicable SOC. This
makes it nessecary to add new a check for every new SOC added
in the future.
So by introducing a new SOC_HAS_OMAP_DPLL config such new #ifdefs
can be avoided for the future socs and also to cleanup the existing
ifdefferies.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/Kconfig |5 +
arch/arm/mach-omap2/clock.c |2 +-
arch/arm/plat-omap/include/plat/clock.h |4 ++--
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 0685dc8..9a8d691 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -27,9 +27,13 @@ config ARCH_OMAP2
select CPU_V6
select MULTI_IRQ_HANDLER
+config SOC_HAS_OMAP_DPLL
+ bool
+
config ARCH_OMAP3
bool TI OMAP3
depends on ARCH_OMAP2PLUS
+ select SOC_HAS_OMAP_DPLL
default y
select CPU_V7
select USB_ARCH_HAS_EHCI if USB_SUPPORT
@@ -42,6 +46,7 @@ config ARCH_OMAP4
bool TI OMAP4
default y
depends on ARCH_OMAP2PLUS
+ select SOC_HAS_OMAP_DPLL
select CACHE_L2X0
select CPU_V7
select ARM_GIC
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index d9f4931..629cd2d 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -400,7 +400,7 @@ int omap2_clk_set_parent(struct clk *clk, struct clk
*new_parent)
/* OMAP3/4 non-CORE DPLL clkops */
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#ifdef CONFIG_SOC_HAS_OMAP_DPLL
const struct clkops clkops_omap3_noncore_dpll_ops = {
.enable = omap3_noncore_dpll_enable,
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index d0ef57c..095bee8 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -156,7 +156,7 @@ struct dpll_data {
u8 min_divider;
u16 max_divider;
u8 modes;
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#ifdef CONFIG_SOC_HAS_OMAP_DPLL
void __iomem*autoidle_reg;
void __iomem*idlest_reg;
u32 autoidle_mask;
@@ -167,7 +167,7 @@ struct dpll_data {
u8 auto_recal_bit;
u8 recal_en_bit;
u8 recal_st_bit;
-# endif
+#endif
u8 flags;
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: OMAP: counter-32k: Select the CR register offset using the IP scheme.
OMAP socs has a legacy and a highlander version of the 32k sync counter IP. The register offsets vary between the highlander and the legacy scheme. So use the 'SCHEME' bits(30-31) of the revision register to distinguish between the two versions and choose the CR register offset accordingly. Signed-off-by: R Sricharan r.sricha...@ti.com --- arch/arm/plat-omap/counter_32k.c | 16 +--- 1 files changed, 13 insertions(+), 3 deletions(-) diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c index b2f634b..cbd939d 100644 --- a/arch/arm/plat-omap/counter_32k.c +++ b/arch/arm/plat-omap/counter_32k.c @@ -28,7 +28,10 @@ #include plat/clock.h /* OMAP2_32KSYNCNT_CR_OFF: offset of 32ksync counter register */ -#define OMAP2_32KSYNCNT_CR_OFF 0x10 +#define OMAP2_32KSYNCNT_REV_OFF0x0 +#define OMAP2_32KSYNCNT_REV_SCHEME (0x3 30) +#define OMAP2_32KSYNCNT_CR_OFF_LOW 0x10 +#define OMAP2_32KSYNCNT_CR_OFF_HIGH0x30 /* * 32KHz clocksource ... always available, on pretty most chips except @@ -83,9 +86,16 @@ int __init omap_init_clocksource_32k(void __iomem *vbase) int ret; /* -* 32k sync Counter register offset is at 0x10 +* 32k sync Counter IP register offsets vary between the +* highlander version and the legacy ones. +* The 'SCHEME' bits(30-31) of the revision register is used +* to identify the version. */ - sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF; + if (__raw_readl(vbase + OMAP2_32KSYNCNT_REV_OFF) + OMAP2_32KSYNCNT_REV_SCHEME) + sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_HIGH; + else + sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_LOW; /* * 12 rough estimate from the calculations in -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
Tony,
[snip]
-#if defined(CONFIG_ARCH_OMAP4) !(defined(CONFIG_ARCH_OMAP2) || \
- defined(CONFIG_ARCH_OMAP3))
+#if (defined(CONFIG_ARCH_OMAP5) || defined(CONFIG_ARCH_OMAP4)) \
+ !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3))
+
static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
{
WARN(1, prm: omap2xxx/omap3xxx specific function and
Maybe these functions could be just set up as __weak to avoid the
ifdeffery?
sorry to understand,
you mean make this weak and have a strong override for OMAP2 ?
Yeah that should do the trick, right?
Ok, There are multiple functions under that #ifdef.
Also i see that __weak cannot be used for inline functions.
So should those functions should be moved to .c file and qualify them
__weak. There is already a strong override for OMAP2 and 3 which
should not be a problem.
[OR]
So after the cleanup patch introducing CONFIG_SOC_OMAP4PLUS
it can be changed as
#ifdef (CONFIG_SOC_OMAP4PLUS) !(defined(CONFIG_ARCH_OMAP2) ||
defined(CONFIG_ARCH_OMAP3))
So this will avoid patching this for the future socs. ?
Thanks,
Sricharan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/13] ARM: OMAP5: l3: Add l3 error handler support for omap5.
Tony,
On Mon, May 7, 2012 at 11:04 PM, Tony Lindgren t...@atomide.com wrote:
* R, Sricharan r.sricha...@ti.com [120506 00:42]:
Hi Tony,
- if (!(cpu_is_omap44xx()))
+ if ((!(cpu_is_omap44xx())) (!cpu_is_omap54xx()))
return -ENODEV;
for (i = 0; i L3_MODULES; i++) {
Isn't there some unnecessary parens here?
You mean in this above for loop?.
There are multiple statements .
No, both the old (!(cpu_is_omap44xx())) and the added one.
oh ok, will remove those extra ones. Thanks.
Thanks,
Sricharan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/13] ARM: OMAP5: board-generic: Add device tree support.
Hi Benoit, Thanks for the reviews. Adding the minimal support for OMAP5 soc with device tree. You should probably split that patch since you are doing several things that are not OMAP5 related. Do a patch that move the omap_init_irq into the INTC and GIC code first. Then, you can add a patch to add the OMAP5_DT machine entry. ok, will split this then accordingly. [snip] @@ -185,6 +185,8 @@ void omap3_intc_prepare_idle(void); void omap3_intc_resume_idle(void); void omap2_intc_handle_irq(struct pt_regs *regs); void omap3_intc_handle_irq(struct pt_regs *regs); +void omap_of_init_irq(void); In order to be consistent with the GIC function and even the previous ones, you should name the exported one: +void omap_intc_of_init(void); Ok, will take care of this rename. @@ -279,6 +280,16 @@ int __init omap_intc_of_init(struct device_node *node, And thus rename that one that become a private function without the omap_ prefix. ok.. Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
Hi Tony,
[snip]
OK this seems to be based on Santosh' Makefile cleanup.
yes..
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4) || \
+ defined(CONFIG_ARCH_OMAP5)
How about we add CONFIG_SOC_OMAP3PLUS in the clean-up series?
Then this becomes just:
#ifdef CONFIG_SOC_OMAP3PLUS
Ok, thanks for the example later. I will do a cleanup patch and
rebase this one.
-# ifdef CONFIG_ARCH_OMAP4
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_OMAP5)
extern int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs);
And this would be:
#ifdef CONFIG_SOC_OMAP4PLUS
ok..
Also, please change the whole series to use CONFIG_SOC_OMAP5 instead
of CONFIG_ARCH_OMAP5. CONFIG_ARCH_OMAP stuff will go away except
for CONFIG_ARCH_OMAP2PLUS. Sorry forgot to mention that earlier.
ok. sure. will change this.
-#if defined(CONFIG_ARCH_OMAP4) !(defined(CONFIG_ARCH_OMAP2) || \
- defined(CONFIG_ARCH_OMAP3))
+#if (defined(CONFIG_ARCH_OMAP5) || defined(CONFIG_ARCH_OMAP4)) \
+ !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3))
+
static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
{
WARN(1, prm: omap2xxx/omap3xxx specific function and
Maybe these functions could be just set up as __weak to avoid the
ifdeffery?
sorry to understand,
you mean make this weak and have a strong override for OMAP2 ?
#define CK_443X (1 11)
#define CK_TI816X (1 12)
#define CK_446X (1 13)
+#define CK_54XX (1 14)
#define CK_1710 (1 15) /* 1710 extra for rate
selection */
Are we going to have to patch tons of existing clocks just to add
CK_54XX? If so, we should init clocks using SoC specific lists instead.
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index d0ef57c..41858f4 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -61,6 +61,7 @@ struct clkops {
#define RATE_IN_4460 (1 7)
#define RATE_IN_AM33XX (1 8)
#define RATE_IN_TI814X (1 9)
+#define RATE_IN_54XX (1 10)
This too may have similar issues, but I guess that's really a different
patch series to sort out..
ok. agree
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4) \
+ || defined(CONFIG_ARCH_OMAP5)
void __iomem *autoidle_reg;
void __iomem *idlest_reg;
u32 autoidle_mask;
#ifdef CONFIG_SOC_OMAP3PLUS could be used here too
ok..
Thanks,
Sricharan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/13] ARM: OMAP5: l3: Add l3 error handler support for omap5.
Hi Tony,
- if (!(cpu_is_omap44xx()))
+ if ((!(cpu_is_omap44xx())) (!cpu_is_omap54xx()))
return -ENODEV;
for (i = 0; i L3_MODULES; i++) {
Isn't there some unnecessary parens here?
You mean in this above for loop?.
There are multiple statements .
Thanks,
Sricharan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/13] ARM: OMAP5: Add the build support
Hi Tony, - select NEON if ARCH_OMAP3 || ARCH_OMAP4 + select NEON if ARCH_OMAP3 || ARCH_OMAP4 || ARCH_OMAP5 select SERIAL_OMAP select SERIAL_OMAP_CONSOLE select I2C If we add CONFIG_SOC_OMAP3PLUS and CONFIG_SOC_OMAP4PLUS, then this becomes more future proof with select NEON if SOC_OMAP3PLUS. ok. will change this. +config ARCH_OMAP5 + bool TI OMAP5 + depends on ARCH_OMAP2PLUS + select CPU_V7 + select ARM_GIC + select HAVE_SMP No need to have depends on ARCH_OMAP2PLUS, it's all inside if ARCH_OMAP2PLUS anyways. I removed those already once, but that had to be reverted because the patch was doing other things too that did not work out too well.. ll ok, will remove this then. +config MACH_OMAP5_SEVM + bool OMAP5 sevm Board + depends on ARCH_OMAP5 + config OMAP3_EMU bool OMAP3 debugging peripherals depends on ARCH_OMAP3 No need for it here either. Actually, I think this whole chunk can be now left out since it's DT based? he ok, but the concern here was that without this macro the print from compress and subsequently early prints appear broken. machine_is_omap5_sevm becomes zero without this config and machine_is_ is used by the macro _DEBUG_LL_ENTRY uncompress.h. Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: dma: Define dma capabilities register bitfields and use them.
The system dma module has capabiities register indicating
the support for descriptor loading, constant fill, etc.
Use this instead of OMAP revision check to identify the features
supported runtime.
This avoids patching the code for feature SOCs which has
those capabilities.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/dma.c | 11 +++
arch/arm/plat-omap/include/plat/dma.h |5 +
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index b19d849..ff75abe 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -227,10 +227,6 @@ static int __init omap2_system_dma_init_dev(struct
omap_hwmod *oh, void *unused)
dma_stride = OMAP2_DMA_STRIDE;
dma_common_ch_start = CSDP;
- if (cpu_is_omap3630() || cpu_is_omap44xx())
- dma_common_ch_end = CCDN;
- else
- dma_common_ch_end = CCFN;
p = kzalloc(sizeof(struct omap_system_dma_plat_info), GFP_KERNEL);
if (!p) {
@@ -277,6 +273,13 @@ static int __init omap2_system_dma_init_dev(struct
omap_hwmod *oh, void *unused)
dev_err(pdev-dev, %s: kzalloc fail\n, __func__);
return -ENOMEM;
}
+
+ /* Check the capabilities register for descriptor loading feature */
+ if (dma_read(CAPS_0, 0) DMA_HAS_DESCRIPTOR_CAPS)
+ dma_common_ch_end = CCDN;
+ else
+ dma_common_ch_end = CCFN;
+
return 0;
}
diff --git a/arch/arm/plat-omap/include/plat/dma.h
b/arch/arm/plat-omap/include/plat/dma.h
index dc562a5..7742204 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -312,6 +312,11 @@
#define CLEAR_CSR_ON_READ BIT(0xC)
#define IS_WORD_16 BIT(0xD)
+/* Defines for DMA Capabilities */
+#define DMA_HAS_TRANSPARENT_CAPS (0x1 18)
+#define DMA_HAS_CONSTANT_FILL_CAPS (0x1 19)
+#define DMA_HAS_DESCRIPTOR_CAPS(0x3 20)
+
enum omap_reg_offsets {
GCR, GSCR, GRST1, HW_ID,
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/13] ARM: OMAP5: Add the build support
Adding the build support required for OMAP5 soc in to omap2+ config. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: R Sricharan r.sricha...@ti.com --- arch/arm/configs/omap2plus_defconfig |2 ++ arch/arm/mach-omap2/Kconfig | 13 - arch/arm/plat-omap/Kconfig |4 ++-- 3 files changed, 16 insertions(+), 3 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index d5f00d7..8beba1a 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -234,3 +234,5 @@ CONFIG_CRC_T10DIF=y CONFIG_CRC_ITU_T=y CONFIG_CRC7=y CONFIG_LIBCRC32C=y +CONFIG_ARCH_OMAP5=y +CONFIG_MACH_OMAP5_SEVM=y diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 8141b76..b50541a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -9,7 +9,7 @@ config ARCH_OMAP2PLUS_TYPICAL select REGULATOR select PM_RUNTIME select VFP - select NEON if ARCH_OMAP3 || ARCH_OMAP4 + select NEON if ARCH_OMAP3 || ARCH_OMAP4 || ARCH_OMAP5 select SERIAL_OMAP select SERIAL_OMAP_CONSOLE select I2C @@ -55,6 +55,13 @@ config ARCH_OMAP4 select USB_ARCH_HAS_EHCI if USB_SUPPORT select ARM_CPU_SUSPEND if PM +config ARCH_OMAP5 + bool TI OMAP5 + depends on ARCH_OMAP2PLUS + select CPU_V7 + select ARM_GIC + select HAVE_SMP + comment OMAP Core Type depends on ARCH_OMAP2 @@ -343,6 +350,10 @@ config MACH_OMAP4_PANDA select OMAP_PACKAGE_CBS select REGULATOR_FIXED_VOLTAGE if REGULATOR +config MACH_OMAP5_SEVM + bool OMAP5 sevm Board + depends on ARCH_OMAP5 + config OMAP3_EMU bool OMAP3 debugging peripherals depends on ARCH_OMAP3 diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index ad95c7a..dcfb506 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -29,7 +29,7 @@ config ARCH_OMAP2PLUS select USE_OF select PROC_DEVICETREE if PROC_FS help - Systems based on OMAP2, OMAP3 or OMAP4 + Systems based on OMAP2, OMAP3, OMAP4 or OMAP5 endchoice @@ -150,7 +150,7 @@ config OMAP_32K_TIMER This timer saves power compared to the OMAP_MPU_TIMER, and has support for no tick during idle. The 32KHz timer provides less intra-tick resolution than OMAP_MPU_TIMER. The 32KHz timer is - currently only available for OMAP16XX, 24XX, 34XX and OMAP4. + currently only available for OMAP16XX, 24XX, 34XX and OMAP4/5. config OMAP3_L2_AUX_SECURE_SAVE_RESTORE bool OMAP3 HS/EMU save and restore for L2 AUX control register -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/13] ARM: OMAP5: gpmc: Update gpmc_init()
GPMC module is the same as in OMAP4.
Just update the base address and irq number.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/gpmc.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 00d5108..2f8f915 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -713,7 +713,8 @@ static int __init gpmc_init(void)
ck = gpmc_fck;
l = OMAP34XX_GPMC_BASE;
gpmc_irq = INT_34XX_GPMC_IRQ;
- } else if (cpu_is_omap44xx()) {
+ } else if (cpu_is_omap44xx() || cpu_is_omap54xx()) {
+ /* Base address and irq number are same for OMAP4/5 */
ck = gpmc_ck;
l = OMAP44XX_GPMC_BASE;
gpmc_irq = OMAP44XX_IRQ_GPMC;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/13] TEMP: ARM: OMAP5: Update the base address of the 32k-counter.
Not for merge. Just update the base address of the counter for OMAP5 soc. This patch will no longer be needed after rebasing on top of below series from Vaibhav Hiremath hvaib...@ti.com. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67166.html Signed-off-by: R Sricharan r.sricha...@ti.com --- arch/arm/plat-omap/counter_32k.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c index 5068fe5..5a48ec9 100644 --- a/arch/arm/plat-omap/counter_32k.c +++ b/arch/arm/plat-omap/counter_32k.c @@ -90,6 +90,8 @@ int __init omap_init_clocksource_32k(void) pbase = OMAP3430_32KSYNCT_BASE + 0x10; else if (cpu_is_omap44xx()) pbase = OMAP4430_32KSYNCT_BASE + 0x10; + else if (cpu_is_omap54xx()) + pbase = OMAP54XX_32KSYNCT_BASE + 0x30; else return -ENODEV; -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/13] TEMP: ARM: OMAP5: Add cpu_is_omap54xx() checks.
Not for merge.
Adding the cpu_is_omap54xx checks at relevant places
for that part of code to execute on OMAP5 socs as well.
This patch will no longer be needed once rebased on
top of below series from Kevin Hilman khil...@ti.com
http://www.spinics.net/lists/linux-omap/msg69013.html
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7144ae6..4063a8c 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1221,7 +1221,7 @@ static int _wait_target_ready(struct omap_hwmod *oh)
ret = omap2_cm_wait_module_ready(oh-prcm.omap2.module_offs,
oh-prcm.omap2.idlest_reg_id,
oh-prcm.omap2.idlest_idle_bit);
- } else if (cpu_is_omap44xx()) {
+ } else if (cpu_is_omap44xx() || cpu_is_omap54xx()) {
if (!oh-clkdm)
return -EINVAL;
@@ -1291,13 +1291,16 @@ static int _assert_hardreset(struct omap_hwmod *oh,
const char *name)
if (cpu_is_omap24xx() || cpu_is_omap34xx())
return omap2_prm_assert_hardreset(oh-prcm.omap2.module_offs,
ohri.rst_shift);
- else if (cpu_is_omap44xx())
+ else if (cpu_is_omap44xx() || cpu_is_omap54xx()) {
return omap4_prminst_assert_hardreset(ohri.rst_shift,
oh-clkdm-pwrdm.ptr-prcm_partition,
oh-clkdm-pwrdm.ptr-prcm_offs,
oh-prcm.omap4.rstctrl_offs);
- else
+ } else {
return -EINVAL;
+ }
+
+ return ret;
}
/**
@@ -1326,9 +1329,9 @@ static int _deassert_hardreset(struct omap_hwmod *oh,
const char *name)
ret = omap2_prm_deassert_hardreset(oh-prcm.omap2.module_offs,
ohri.rst_shift,
ohri.st_shift);
- } else if (cpu_is_omap44xx()) {
+ } else if (cpu_is_omap44xx() || cpu_is_omap54xx()) {
if (ohri.st_shift)
- pr_err(omap_hwmod: %s: %s: hwmod data error: OMAP4
does not support st_shift\n,
+ pr_err(omap_hwmod: %s: %s: hwmod data error: OMAP4+
does not support st_shift\n,
oh-name, name);
ret = omap4_prminst_deassert_hardreset(ohri.rst_shift,
oh-clkdm-pwrdm.ptr-prcm_partition,
@@ -1367,7 +1370,7 @@ static int _read_hardreset(struct omap_hwmod *oh, const
char *name)
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
return
omap2_prm_is_hardreset_asserted(oh-prcm.omap2.module_offs,
ohri.st_shift);
- } else if (cpu_is_omap44xx()) {
+ } else if (cpu_is_omap44xx() || cpu_is_omap54xx()) {
return omap4_prminst_is_hardreset_asserted(ohri.rst_shift,
oh-clkdm-pwrdm.ptr-prcm_partition,
oh-clkdm-pwrdm.ptr-prcm_offs,
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/13] ARM: OMAP5: timer: Add clocksource, clockevent support
Adding the Initialisaton for clocksource and clockevent device on OMAP5 Socs. Signed-off-by: R Sricharan r.sricha...@ti.com --- arch/arm/mach-omap2/common.h |1 + arch/arm/mach-omap2/timer.c |5 + 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h index 797dda7..88fb577 100644 --- a/arch/arm/mach-omap2/common.h +++ b/arch/arm/mach-omap2/common.h @@ -92,6 +92,7 @@ extern struct sys_timer omap2_timer; extern struct sys_timer omap3_timer; extern struct sys_timer omap3_secure_timer; extern struct sys_timer omap4_timer; +extern struct sys_timer omap5_timer; void omap2420_init_early(void); void omap2430_init_early(void); diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index c512bac..3262ad6 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -348,6 +348,11 @@ static void __init omap4_timer_init(void) OMAP_SYS_TIMER(4) #endif +#ifdef CONFIG_ARCH_OMAP5 +OMAP_SYS_TIMER_INIT(5, 1, OMAP4_CLKEV_SOURCE, 2, OMAP4_MPU_SOURCE) +OMAP_SYS_TIMER(5) +#endif + /** * omap2_dm_timer_set_src - change the timer input clock source * @pdev: timer platform device pointer -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/13] arm/dts: OMAP5: Add omap5 dts files
Adding the minimum device tree files required for
OMAP5 to boot.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
.../devicetree/bindings/arm/omap/omap.txt |3 +
arch/arm/boot/dts/omap5-evm.dts| 20 ++
arch/arm/boot/dts/omap5.dtsi | 201
3 files changed, 224 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap5-evm.dts
create mode 100644 arch/arm/boot/dts/omap5.dtsi
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index e78e8bc..3d450f6 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -47,3 +47,6 @@ Boards:
- AM335X EVM : Software Developement Board for AM335x
compatible = ti,am335x-evm, ti,am33xx, ti,omap3
+
+- OMAP5 EVM : Evaluation Module
+ compatible = ti,omap5-evm, ti,omap5
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
new file mode 100644
index 000..200c39a
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -0,0 +1,20 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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.
+ */
+/dts-v1/;
+
+/include/ omap5.dtsi
+
+/ {
+ model = TI OMAP5 EVM board;
+ compatible = ti,omap5-evm, ti,omap5;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x4000; /* 1 GB */
+ };
+};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
new file mode 100644
index 000..b50c28d
--- /dev/null
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -0,0 +1,201 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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.
+ * Based on omap4.dtsi
+ */
+
+/*
+ * Carveout for multimedia usecases
+ * It should be the last 48MB of the first 512MB memory part
+ * In theory, it should not even exist. That zone should be reserved
+ * dynamically during the .reserve callback.
+ */
+/memreserve/ 0x9d00 0x0300;
+
+/include/ skeleton.dtsi
+
+/ {
+ compatible = ti,omap5;
+ interrupt-parent = gic;
+
+ aliases {
+ serial0 = uart1;
+ serial1 = uart2;
+ serial2 = uart3;
+ serial3 = uart4;
+ serial4 = uart5;
+ serial5 = uart6;
+ };
+
+ cpus {
+ cpu@0 {
+ compatible = arm,cortex-a15;
+ };
+ cpu@1 {
+ compatible = arm,cortex-a15;
+ };
+ };
+
+ /*
+* The soc node represents the soc top level view. It is uses for IPs
+* that are not memory mapped in the MPU view or for the MPU itself.
+*/
+ soc {
+ compatible = ti,omap-infra;
+ mpu {
+ compatible = ti,omap5-mpu;
+ ti,hwmods = mpu;
+ };
+ };
+
+ /*
+* XXX: Use a flat representation of the OMAP4 interconnect.
+* The real OMAP interconnect network is quite complex.
+*
+* MPU -+-- MPU_PRIVATE - GIC, L2
+* |
+* ++--+
+* || |
+* ++- EMIF - DDR |
+* || |
+* |+ ++
+* || |
+* |+- L4_ABE - AESS, MCBSP, TIMERs...
+* ||
+* +- L3_MAIN --+- L4_CORE - IPs...
+* |
+* +- L4_PER - IPs...
+* |
+*
+* Since that will not bring real advantage to represent that in DT for
+* the moment, just use a fake OCP bus entry to represent the whole bus
+* hierarchy.
+*/
+ ocp {
+ compatible = ti,omap4-l3-noc, simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ ti,hwmods = l3_main_1, l3_main_2, l3_main_3;
+
+ gic: interrupt-controller@48211000 {
+ compatible = arm,cortex-a15-gic;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x48211000 0x1000,
+ 0x48212000 0x1000;
+ };
+
+ gpio1: gpio@4ae1 {
+ compatible = ti,omap4-gpio;
+ ti,hwmods = gpio1
[PATCH 08/13] ARM: OMAP5: Add the WakeupGen IP updates.
From: Santosh Shilimkar santosh.shilim...@ti.com
OMAP4 and OMAP5 share same WakeupGen IP with below few udpates on OMAP5.
- Additional 32 interrupt support is added w.r.t OMAP4 design.
- The AUX CORE boot registers are now made accessible from non-secure SW.
- SAR offset are changed and PTMSYNC* registers are removed from SAR.
Patch updates the WakeupGen code accordingly.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/include/mach/omap-wakeupgen.h |6 +
arch/arm/mach-omap2/omap-hotplug.c| 24 -
arch/arm/mach-omap2/omap-smp.c| 19 +++-
arch/arm/mach-omap2/omap-wakeupgen.c | 110 +++-
arch/arm/mach-omap2/omap4-sar-layout.h| 12 ++-
5 files changed, 135 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
index 548de90..4d700bc 100644
--- a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
+++ b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
@@ -11,15 +11,20 @@
#ifndef OMAP_ARCH_WAKEUPGEN_H
#define OMAP_ARCH_WAKEUPGEN_H
+/* OMAP4 and OMAP5 has same base address */
+#define OMAP_WKUPGEN_BASE 0x48281000
+
#define OMAP_WKG_CONTROL_0 0x00
#define OMAP_WKG_ENB_A_0 0x10
#define OMAP_WKG_ENB_B_0 0x14
#define OMAP_WKG_ENB_C_0 0x18
#define OMAP_WKG_ENB_D_0 0x1c
+#define OMAP_WKG_ENB_E_0 0x20
#define OMAP_WKG_ENB_A_1 0x410
#define OMAP_WKG_ENB_B_1 0x414
#define OMAP_WKG_ENB_C_1 0x418
#define OMAP_WKG_ENB_D_1 0x41c
+#define OMAP_WKG_ENB_E_1 0x420
#define OMAP_AUX_CORE_BOOT_0 0x800
#define OMAP_AUX_CORE_BOOT_1 0x804
#define OMAP_PTMSYNCREQ_MASK 0xc00
@@ -28,4 +33,5 @@
#define OMAP_TIMESTAMPCYCLEHI 0xc0c
extern int __init omap_wakeupgen_init(void);
+extern void __iomem *omap_get_wakeupgen_base(void);
#endif
diff --git a/arch/arm/mach-omap2/omap-hotplug.c
b/arch/arm/mach-omap2/omap-hotplug.c
index 56c345b..052303c 100644
--- a/arch/arm/mach-omap2/omap-hotplug.c
+++ b/arch/arm/mach-omap2/omap-hotplug.c
@@ -17,8 +17,10 @@
#include linux/kernel.h
#include linux/errno.h
#include linux/smp.h
+#include linux/io.h
#include asm/cacheflush.h
+#include mach/omap-wakeupgen.h
#include common.h
@@ -35,7 +37,8 @@ int platform_cpu_kill(unsigned int cpu)
*/
void __ref platform_cpu_die(unsigned int cpu)
{
- unsigned int this_cpu;
+ unsigned int boot_cpu = 0;
+ void __iomem *base = omap_get_wakeupgen_base();
flush_cache_all();
dsb();
@@ -43,16 +46,27 @@ void __ref platform_cpu_die(unsigned int cpu)
/*
* we're ready for shutdown now, so do it
*/
- if (omap_modify_auxcoreboot0(0x0, 0x200) != 0x0)
- pr_err(Secure clear status failed\n);
+ if (cpu_is_omap44xx()) {
+ if (omap_modify_auxcoreboot0(0x0, 0x200) != 0x0)
+ pr_err(Secure clear status failed\n);
+ } else {
+ __raw_writel(0, base + OMAP_AUX_CORE_BOOT_0);
+ }
+
for (;;) {
/*
* Enter into low power state
*/
omap4_hotplug_cpu(cpu, PWRDM_POWER_OFF);
- this_cpu = smp_processor_id();
- if (omap_read_auxcoreboot0() == this_cpu) {
+
+ if (cpu_is_omap44xx())
+ boot_cpu = omap_read_auxcoreboot0();
+ else
+ boot_cpu =
+ __raw_readl(base + OMAP_AUX_CORE_BOOT_0) 5;
+
+ if (boot_cpu == smp_processor_id()) {
/*
* OK, proper wakeup, we're done
*/
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index deffbf1..151fd5b 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -26,6 +26,8 @@
#include mach/hardware.h
#include mach/omap-secure.h
+#include mach/omap-wakeupgen.h
+#include asm/cputype.h
#include iomap.h
#include common.h
@@ -73,6 +75,8 @@ int __cpuinit boot_secondary(unsigned int cpu, struct
task_struct *idle)
{
static struct clockdomain *cpu1_clkdm;
static bool booted;
+ void __iomem *base = omap_get_wakeupgen_base();
+
/*
* Set synchronisation state between this boot processor
* and the secondary one
@@ -85,7 +89,11 @@ int __cpuinit boot_secondary(unsigned int cpu, struct
task_struct *idle)
* the AuxCoreBoot1 register is updated with cpu state
* A barrier is added to ensure that write buffer
[PATCH 13/13] ARM: Kconfig update to support additional GPIOs in OMAP5
From: Tarun Kanti DebBarma tarun.ka...@ti.com OMAP5 has 8 GPIO banks so that there are 32x8 = 256 GPIOs. In order for the gpiolib to detect and initialize these additional GPIOs and other TWL GPIOs, ARCH_NR_GPIO is set to 512 instead of present 256. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Cousson, Benoit b-cous...@ti.com Reported-by: Govindraj.R govindraj.r...@ti.com Tested-by: Govindraj.R govindraj.r...@ti.com Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- arch/arm/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index cf006d4..d649c16 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1602,6 +1602,7 @@ config ARCH_NR_GPIO default 1024 if ARCH_SHMOBILE || ARCH_TEGRA default 355 if ARCH_U8500 default 264 if MACH_H4700 + default 512 if ARCH_OMAP5 default 0 help Maximum number of GPIOs in the system. -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP architecture. It's a dual core SOC with GIC used for interrupt handling and with an integrated L2 cache controller. OMAP5432 is another variant of OMAP5430, with a memory controller supporting DDR3 and SATA. Patch includes: - The machine specific headers and sources updates. - Platform header updates. - Minimum initialisation support for serial. - IO table init Signed-off-by: R Sricharan r.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/Makefile | 26 ++ arch/arm/mach-omap2/clock.c|3 +- arch/arm/mach-omap2/cminst44xx.h |2 +- arch/arm/mach-omap2/common.c | 24 + arch/arm/mach-omap2/common.h | 11 ++ arch/arm/mach-omap2/include/mach/debug-macro.S |8 ++-- arch/arm/mach-omap2/io.c | 44 arch/arm/mach-omap2/iomap.h| 27 ++ arch/arm/mach-omap2/prcm.c |2 +- arch/arm/mach-omap2/prm2xxx_3xxx.h |5 ++- arch/arm/plat-omap/Makefile|4 +-- arch/arm/plat-omap/include/plat/clkdev_omap.h |1 + arch/arm/plat-omap/include/plat/clock.h|4 ++- arch/arm/plat-omap/include/plat/hardware.h |1 + arch/arm/plat-omap/include/plat/multi.h|9 + arch/arm/plat-omap/include/plat/omap54xx.h | 32 + arch/arm/plat-omap/include/plat/serial.h | 10 + arch/arm/plat-omap/include/plat/uncompress.h |6 +++ arch/arm/plat-omap/sram.c | 11 +- 19 files changed, 208 insertions(+), 22 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/omap54xx.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 669e2b1..fbb6b3d 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -16,6 +16,7 @@ secure-common = omap-smc.o omap-secure.o obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common) obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common) obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common) +obj-$(CONFIG_ARCH_OMAP5) += prm44xx.o $(hwmod-common) $(secure-common) ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),) obj-y += mcbsp.o @@ -27,8 +28,10 @@ obj-$(CONFIG_TWL4030_CORE) += omap_twl.o obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o -obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o -obj-$(CONFIG_ARCH_OMAP4) += sleep44xx.o +omap-4-5-common= omap4-common.o omap-wakeupgen.o \ + sleep44xx.o +obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-common) +obj-$(CONFIG_ARCH_OMAP5)+= $(omap-4-5-common) plus_sec := $(call as-instr,.arch_extension sec,+sec) AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec) @@ -68,6 +71,7 @@ obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o obj-$(CONFIG_ARCH_OMAP3) += cpuidle34xx.o obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o +obj-$(CONFIG_ARCH_OMAP5) += omap-mpuss-lowpower.o obj-$(CONFIG_ARCH_OMAP4) += cpuidle44xx.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o @@ -87,9 +91,11 @@ obj-y+= prm_common.o obj-$(CONFIG_ARCH_OMAP2) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o obj-$(CONFIG_ARCH_OMAP3) += vc3xxx_data.o vp3xxx_data.o -obj-$(CONFIG_ARCH_OMAP4) += prcm.o cminst44xx.o cm44xx.o -obj-$(CONFIG_ARCH_OMAP4) += prcm_mpu44xx.o prminst44xx.o -obj-$(CONFIG_ARCH_OMAP4) += vc44xx_data.o vp44xx_data.o prm44xx.o +omap-prcm-4-5-common = prcm.o cminst44xx.o cm44xx.o \ + prcm_mpu44xx.o prminst44xx.o \ + vc44xx_data.o vp44xx_data.o +obj-$(CONFIG_ARCH_OMAP4) += $(omap-prcm-4-5-common) prm44xx.o +obj-$(CONFIG_ARCH_OMAP5)+= $(omap-prcm-4-5-common) # OMAP voltage domains voltagedomain-common := voltage.o vc.o vp.o @@ -99,6 +105,7 @@ obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common) obj-$(CONFIG_ARCH_OMAP3) += voltagedomains3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) obj-$(CONFIG_ARCH_OMAP4) += voltagedomains44xx_data.o +obj-$(CONFIG_ARCH_OMAP5
[PATCH 07/13] ARM: OMAP5: l3: Add l3 error handler support for omap5.
The l3 interconnect ip is same for OMAP4 and OMAP5.
So reuse the l3 error handler error code for OMAP5
as well. Also a few targets has been newly added for
OMAP5. So updating the driver for that here.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/omap_l3_noc.h | 22 ++
3 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fbb6b3d..9f554e3 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -183,6 +183,7 @@ obj-$(CONFIG_OMAP3_EMU) += emu.o
# L3 interconnect
obj-$(CONFIG_ARCH_OMAP3) += omap_l3_smx.o
obj-$(CONFIG_ARCH_OMAP4) += omap_l3_noc.o
+obj-$(CONFIG_ARCH_OMAP5)+= omap_l3_noc.o
obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o
mailbox_mach-objs := mailbox.o
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index e433603..a1b539a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -85,7 +85,7 @@ static int __init omap4_l3_init(void)
* To avoid code running on other OMAPs in
* multi-omap builds
*/
- if (!(cpu_is_omap44xx()))
+ if ((!(cpu_is_omap44xx())) (!cpu_is_omap54xx()))
return -ENODEV;
for (i = 0; i L3_MODULES; i++) {
diff --git a/arch/arm/mach-omap2/omap_l3_noc.h
b/arch/arm/mach-omap2/omap_l3_noc.h
index 90b5098..a6ce34d 100644
--- a/arch/arm/mach-omap2/omap_l3_noc.h
+++ b/arch/arm/mach-omap2/omap_l3_noc.h
@@ -51,7 +51,9 @@ static u32 l3_targ_inst_clk1[] = {
0x200, /* DMM2 */
0x300, /* ABE */
0x400, /* L4CFG */
- 0x600 /* CLK2 PWR DISC */
+ 0x600, /* CLK2 PWR DISC */
+ 0x0,/* Host CLK1 */
+ 0x900 /* L4 Wakeup */
};
static u32 l3_targ_inst_clk2[] = {
@@ -72,11 +74,16 @@ static u32 l3_targ_inst_clk2[] = {
0xE00, /* missing in TRM corresponds to AES2*/
0xC00, /* L4 PER3 */
0xA00, /* L4 PER1*/
- 0xB00 /* L4 PER2*/
+ 0xB00, /* L4 PER2*/
+ 0x0, /* HOST CLK2 */
+ 0x1800, /* CAL */
+ 0x1700 /* LLI */
};
static u32 l3_targ_inst_clk3[] = {
- 0x0100 /* EMUSS */
+ 0x0100 /* EMUSS */,
+ 0x0300, /* DEBUGSS_CT_TBR */
+ 0x0 /* HOST CLK3 */
};
static struct l3_masters_data {
@@ -110,13 +117,15 @@ static struct l3_masters_data {
{ 0xC8, USBHOSTFS}
};
-static char *l3_targ_inst_name[L3_MODULES][18] = {
+static char *l3_targ_inst_name[L3_MODULES][21] = {
{
DMM1,
DMM2,
ABE,
L4CFG,
CLK2 PWR DISC,
+ HOST CLK1,
+ L4 WAKEUP
},
{
CORTEX M3 ,
@@ -137,9 +146,14 @@ static char *l3_targ_inst_name[L3_MODULES][18] = {
L4 PER3,
L4 PER1,
L4 PER2,
+ HOST CLK2,
+ CAL,
+ LLI
},
{
EMUSS,
+ DEBUG SOURCE,
+ HOST CLK3
},
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/13] ARM: OMAP5: board-generic: Add device tree support.
Adding the minimal support for OMAP5 soc with device tree.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 39 +-
arch/arm/mach-omap2/common.h|2 +
arch/arm/mach-omap2/irq.c | 11 +
arch/arm/mach-omap2/omap4-common.c | 14
4 files changed, 51 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 098d183..0dd9e3f 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -20,6 +20,7 @@
#include mach/hardware.h
#include asm/hardware/gic.h
#include asm/mach/arch.h
+#include mach/omap-wakeupgen.h
#include plat/board.h
#include common.h
@@ -32,17 +33,6 @@
#define gic_of_initNULL
#endif
-static struct of_device_id irq_match[] __initdata = {
- { .compatible = ti,omap2-intc, .data = omap_intc_of_init, },
- { .compatible = arm,cortex-a9-gic, .data = gic_of_init, },
- { }
-};
-
-static void __init omap_init_irq(void)
-{
- of_irq_init(irq_match);
-}
-
static struct of_device_id omap_dt_match_table[] __initdata = {
{ .compatible = simple-bus, },
{ .compatible = ti,omap-infra, },
@@ -66,7 +56,7 @@ DT_MACHINE_START(OMAP242X_DT, Generic OMAP2420 (Flattened
Device Tree))
.reserve= omap_reserve,
.map_io = omap242x_map_io,
.init_early = omap2420_init_early,
- .init_irq = omap_init_irq,
+ .init_irq = omap_of_init_irq,
.handle_irq = omap2_intc_handle_irq,
.init_machine = omap_generic_init,
.timer = omap2_timer,
@@ -85,7 +75,7 @@ DT_MACHINE_START(OMAP243X_DT, Generic OMAP2430 (Flattened
Device Tree))
.reserve= omap_reserve,
.map_io = omap243x_map_io,
.init_early = omap2430_init_early,
- .init_irq = omap_init_irq,
+ .init_irq = omap_of_init_irq,
.handle_irq = omap2_intc_handle_irq,
.init_machine = omap_generic_init,
.timer = omap2_timer,
@@ -120,7 +110,7 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened Device
Tree))
.reserve= omap_reserve,
.map_io = omap3_map_io,
.init_early = omap3430_init_early,
- .init_irq = omap_init_irq,
+ .init_irq = omap_of_init_irq,
.handle_irq = omap3_intc_handle_irq,
.init_machine = omap3_init,
.timer = omap3_timer,
@@ -155,7 +145,7 @@ DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened Device
Tree))
.reserve= omap_reserve,
.map_io = omap4_map_io,
.init_early = omap4430_init_early,
- .init_irq = omap_init_irq,
+ .init_irq = omap_gic_of_init,
.handle_irq = gic_handle_irq,
.init_machine = omap4_init,
.timer = omap4_timer,
@@ -163,3 +153,22 @@ DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened
Device Tree))
.restart= omap_prcm_restart,
MACHINE_END
#endif
+
+#ifdef CONFIG_ARCH_OMAP5
+static const char *omap5_boards_compat[] __initdata = {
+ ti,omap5,
+ NULL,
+};
+
+DT_MACHINE_START(OMAP5_DT, Generic OMAP5 (Flattened Device Tree))
+ .reserve= omap_reserve,
+ .map_io = omap5_map_io,
+ .init_early = omap5_init_early,
+ .init_irq = omap_gic_of_init,
+ .handle_irq = gic_handle_irq,
+ .init_machine = omap_generic_init,
+ .timer = omap5_timer,
+ .dt_compat = omap5_boards_compat,
+ .restart= omap_prcm_restart,
+MACHINE_END
+#endif
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 0771d22..e66859d 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -185,6 +185,8 @@ void omap3_intc_prepare_idle(void);
void omap3_intc_resume_idle(void);
void omap2_intc_handle_irq(struct pt_regs *regs);
void omap3_intc_handle_irq(struct pt_regs *regs);
+void omap_of_init_irq(void);
+void omap_gic_of_init(void);
#ifdef CONFIG_CACHE_L2X0
extern void __iomem *omap4_get_l2cache_base(void);
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 65f0d25..d316c68 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -21,6 +21,7 @@
#include linux/irqdomain.h
#include linux/of.h
#include linux/of_address.h
+#include linux/of_irq.h
#include mach/hardware.h
@@ -279,6 +280,16 @@ int __init omap_intc_of_init(struct device_node *node,
return 0;
}
+static struct of_device_id irq_match[] __initdata = {
+ { .compatible = ti,omap2-intc, .data = omap_intc_of_init, },
+ { }
+};
+
+void __init omap_of_init_irq(void)
+{
+ of_irq_init(irq_match);
+}
+
#ifdef CONFIG_ARCH_OMAP3
static struct omap3_intc_regs intc_context[ARRAY_SIZE(irq_banks)];
diff --git a/arch
[PATCH 09/13] ARM: OMAP5: Add SMP support.
From: Santosh Shilimkar santosh.shilim...@ti.com
Add OMAP5 SMP boot support using OMAP4 SMP code. The relevant code paths
are runtime checked using cpu id
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/omap-headsmp.S | 21 ++
arch/arm/mach-omap2/omap-smp.c | 41 +--
3 files changed, 51 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 88fb577..0771d22 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -222,6 +222,7 @@ extern void omap_secondary_startup(void);
extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask);
extern void omap_auxcoreboot_addr(u32 cpu_addr);
extern u32 omap_read_auxcoreboot0(void);
+extern void omap5_secondary_startup(void);
#endif
#if defined(CONFIG_SMP) defined(CONFIG_PM)
diff --git a/arch/arm/mach-omap2/omap-headsmp.S
b/arch/arm/mach-omap2/omap-headsmp.S
index 503ac77..502e313 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -19,6 +19,27 @@
#include linux/init.h
__CPUINIT
+
+/* Physical address needed since MMU not enabled yet on secondary core */
+#define AUX_CORE_BOOT0_PA 0x48281800
+
+/*
+ * OMAP5 specific entry point for secondary CPU to jump from ROM
+ * code. This routine also provides a holding flag into which
+ * secondary core is held until we're ready for it to initialise.
+ * The primary core will update this flag using a hardware
++ * register AuxCoreBoot0.
+ */
+ENTRY(omap5_secondary_startup)
+wait: ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0
+ ldr r0, [r2]
+ mov r0, r0, lsr #5
+ mrc p15, 0, r4, c0, c0, 5
+ and r4, r4, #0x0f
+ cmp r0, r4
+ bne wait
+ b secondary_startup
+END(omap5_secondary_startup)
/*
* OMAP4 specific entry point for secondary CPU to jump from ROM
* code. This routine also provides a holding flag into which
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 151fd5b..9424bb6 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -33,6 +33,10 @@
#include common.h
#include clockdomain.h
+#define CPU_MASK 0xff00
+#define CPU_CORTEX_A9 0x410FC090
+#define CPU_CORTEX_A15 0x410FC0F0
+
/* SCU base address */
static void __iomem *scu_base;
@@ -43,6 +47,14 @@ void __iomem *omap4_get_scu_base(void)
return scu_base;
}
+static inline unsigned int get_a15_core_count(void)
+{
+ unsigned int ncores;
+
+ asm volatile(mrc p15, 1, %0, c9, c0, 2\n : =r (ncores));
+ return ((ncores 24) 3) + 1;
+}
+
void __cpuinit platform_secondary_init(unsigned int cpu)
{
/*
@@ -133,7 +145,6 @@ int __cpuinit boot_secondary(unsigned int cpu, struct
task_struct *idle)
static void __init wakeup_secondary(void)
{
void __iomem *base = omap_get_wakeupgen_base();
-
/*
* Write the address of secondary startup routine into the
* AuxCoreBoot1 where ROM code will jump and start executing
@@ -162,16 +173,21 @@ static void __init wakeup_secondary(void)
*/
void __init smp_init_cpus(void)
{
- unsigned int i, ncores;
-
- /*
-* Currently we can't call ioremap here because
-* SoC detection won't work until after init_early.
-*/
- scu_base = OMAP2_L4_IO_ADDRESS(OMAP44XX_SCU_BASE);
- BUG_ON(!scu_base);
-
- ncores = scu_get_core_count(scu_base);
+ unsigned int i = 0, ncores = 1, cpu_id;
+
+ /* Use ARM cpuid check here, as SoC detection will not work so early */
+ cpu_id = read_cpuid(CPUID_ID) CPU_MASK;
+ if (cpu_id == CPU_CORTEX_A9) {
+ /*
+* Currently we can't call ioremap here because
+* SoC detection won't work until after init_early.
+*/
+ scu_base = OMAP2_L4_IO_ADDRESS(OMAP44XX_SCU_BASE);
+ BUG_ON(!scu_base);
+ ncores = scu_get_core_count(scu_base);
+ } else if (cpu_id == CPU_CORTEX_A15) {
+ ncores = get_a15_core_count();
+ }
/* sanity check */
if (ncores nr_cpu_ids) {
@@ -193,6 +209,7 @@ void __init platform_smp_prepare_cpus(unsigned int max_cpus)
* Initialise the SCU and wake up the secondary core using
* wakeup_secondary().
*/
- scu_enable(scu_base);
+ if (scu_base)
+ scu_enable(scu_base);
wakeup_secondary();
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/13] ARM: OMAP5: Add minimal OMAP5 SOC support
The series adds minimal OMAP5 support. OMAP5430 has a dual core Cortex-A15 based MPU subsystem with 2MB L2 cache. The SOC has many compatible blocks with OMAP4 SOCS and hence large part of the peripherals are re-used. OMAP5432 is another variant of OMAP5430, with a memory controller supporting DDR3 and SATA. Series is generated against the 3.4-rc5. This has been rebased on top of the OMAP2+ cleanup series [1] To get the boot working with omap2plus_defconfig, OMAP5 hwmod/clock/prm/cm database needs to be added. The data and the integrated tree are available in the below git repository OMAP5_DATA: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git omap5_data OMAP5_INTEGRATED: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git omap5_dt_integrated The series is boot tested on OMAP5430 ES1.0. OMAP2/3/4 build and boot is tested as well to avoid any breakage because of the series. Patch TEMP: ARM: OMAP5: Add cpu_is_omap54xx() checks is temporary and can be dropped once rebased against [2] Patch TEMP: ARM: OMAP5: Update the base address of the 32k-counter is temporary and can be dropped once rebased against [3] [1] http://www.spinics.net/lists/linux-omap/msg69233.html [2] http://www.spinics.net/lists/linux-omap/msg69013.html [3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67166.html R Sricharan (10): ARM: OMAP5: id: Add cpu id for ES versions ARM: OMAP5: Add minimal support for OMAP5430 SOC TEMP: ARM: OMAP5: Add cpu_is_omap54xx() checks. ARM: OMAP5: timer: Add clocksource, clockevent support TEMP: ARM: OMAP5: Update the base address of the 32k-counter. ARM: OMAP5: gpmc: Update gpmc_init() ARM: OMAP5: l3: Add l3 error handler support for omap5. ARM: OMAP5: board-generic: Add device tree support. arm/dts: OMAP5: Add omap5 dts files ARM: OMAP5: Add the build support Santosh Shilimkar (2): ARM: OMAP5: Add the WakeupGen IP updates. ARM: OMAP5: Add SMP support. Tarun Kanti DebBarma (1): ARM: Kconfig update to support additional GPIOs in OMAP5 .../devicetree/bindings/arm/omap/omap.txt |3 + arch/arm/Kconfig |1 + arch/arm/boot/dts/omap5-evm.dts| 20 ++ arch/arm/boot/dts/omap5.dtsi | 201 arch/arm/configs/omap2plus_defconfig |2 + arch/arm/mach-omap2/Kconfig| 13 ++- arch/arm/mach-omap2/Makefile | 27 ++- arch/arm/mach-omap2/board-generic.c| 39 +++-- arch/arm/mach-omap2/clock.c|3 +- arch/arm/mach-omap2/cminst44xx.h |2 +- arch/arm/mach-omap2/common.c | 24 +++ arch/arm/mach-omap2/common.h | 15 ++ arch/arm/mach-omap2/control.h |4 + arch/arm/mach-omap2/devices.c |2 +- arch/arm/mach-omap2/gpmc.c |3 +- arch/arm/mach-omap2/id.c | 47 + arch/arm/mach-omap2/include/mach/debug-macro.S |8 +- arch/arm/mach-omap2/include/mach/omap-wakeupgen.h |6 + arch/arm/mach-omap2/io.c | 44 + arch/arm/mach-omap2/iomap.h| 27 +++ arch/arm/mach-omap2/irq.c | 11 + arch/arm/mach-omap2/omap-headsmp.S | 21 ++ arch/arm/mach-omap2/omap-hotplug.c | 24 ++- arch/arm/mach-omap2/omap-smp.c | 58 +-- arch/arm/mach-omap2/omap-wakeupgen.c | 110 --- arch/arm/mach-omap2/omap4-common.c | 14 ++ arch/arm/mach-omap2/omap4-sar-layout.h | 12 +- arch/arm/mach-omap2/omap_hwmod.c | 15 +- arch/arm/mach-omap2/omap_l3_noc.h | 22 ++- arch/arm/mach-omap2/prcm.c |2 +- arch/arm/mach-omap2/prm2xxx_3xxx.h |5 +- arch/arm/mach-omap2/timer.c|5 + arch/arm/plat-omap/Kconfig |4 +- arch/arm/plat-omap/Makefile|4 +- arch/arm/plat-omap/counter_32k.c |2 + arch/arm/plat-omap/include/plat/clkdev_omap.h |1 + arch/arm/plat-omap/include/plat/clock.h|4 +- arch/arm/plat-omap/include/plat/cpu.h | 23 ++- arch/arm/plat-omap/include/plat/hardware.h |1 + arch/arm/plat-omap/include/plat/multi.h|9 + arch/arm/plat-omap/include/plat/omap54xx.h | 32 +++ arch/arm/plat-omap/include/plat/serial.h | 10 + arch/arm/plat-omap/include/plat/uncompress.h |6 + arch/arm/plat-omap/sram.c | 11 +- 44 files changed, 796 insertions(+), 101 deletions(-) create mode 100644 arch/arm/boot/dts/omap5-evm.dts create mode 100644 arch/arm/boot/dts/omap5.dtsi create mode 100644 arch/arm/plat-omap
[PATCH 01/13] ARM: OMAP5: id: Add cpu id for ES versions
Adding the OMAP5 ES1.0, 2.0 and OMAP5432 cpu revision
detection support.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/control.h |4 +++
arch/arm/mach-omap2/id.c | 47 +
arch/arm/plat-omap/include/plat/cpu.h | 23 ++-
3 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index a406fd0..9daac6f 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -246,6 +246,10 @@
/* TI81XX CONTROL_DEVCONF register offsets */
#define TI81XX_CONTROL_DEVICE_ID (TI81XX_CONTROL_DEVCONF + 0x000)
+/* OMAP54XX CONTROL STATUS register */
+#define OMAP5XXX_CONTROL_STATUS0x134
+#define OMAP5_DEVICETYPE_MASK (0x7 6)
+
/*
* REVISIT: This list of registers is not comprehensive - there are more
* that should be added.
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 0e79b7b..d2ec323 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -50,6 +50,11 @@ int omap_type(void)
val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
} else if (cpu_is_omap44xx()) {
val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
+ } else if (cpu_is_omap54xx()) {
+ val = omap_ctrl_readl(OMAP5XXX_CONTROL_STATUS);
+ val = OMAP5_DEVICETYPE_MASK;
+ val = 6;
+ goto out;
} else {
pr_err(Cannot detect omap type!\n);
goto out;
@@ -500,6 +505,48 @@ void __init omap4xxx_check_revision(void)
((omap_rev() 12) 0xf), ((omap_rev() 8) 0xf));
}
+void __init omap5xxx_check_revision(void)
+{
+ u32 idcode;
+ u16 hawkeye;
+ u8 rev;
+
+ idcode = read_tap_reg(OMAP_TAP_IDCODE);
+ hawkeye = (idcode 12) 0x;
+ rev = (idcode 28) 0xff;
+ switch (hawkeye) {
+ case 0xb942:
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP5430_REV_ES1_0;
+ break;
+ case 1:
+ omap_revision = OMAP5430_REV_ES2_0;
+ break;
+ default:
+ omap_revision = OMAP5430_REV_ES1_0;
+ }
+ break;
+
+ case 0xb998:
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP5432_REV_ES1_0;
+ break;
+ default:
+ omap_revision = OMAP5432_REV_ES1_0;
+ }
+ break;
+
+ default:
+ /* Unknown default to latest silicon rev as default*/
+ omap_revision = OMAP5430_REV_ES2_0;
+ }
+
+ pr_info(OMAP%04x ES%d.0\n,
+ omap_rev() 16, ((omap_rev() 12) 0xf));
+}
+
/*
* Set up things for map_io and processor detection later on. Gets called
* pretty much first thing from board init. For multi-omap, this gets
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index dc6a86b..5e57732 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -9,7 +9,7 @@
*
* Written by Tony Lindgren tony.lindg...@nokia.com
*
- * Added OMAP4 specific defines - Santosh Shilimkarsantosh.shilim...@ti.com
+ * Added OMAP4/5 specific defines - Santosh Shilimkarsantosh.shilim...@ti.com
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -70,6 +70,7 @@ unsigned int omap_rev(void);
* cpu_is_omap443x(): True for OMAP4430
* cpu_is_omap446x(): True for OMAP4460
* cpu_is_omap447x(): True for OMAP4470
+ * cpu_is_omap543x(): True for OMAP5430, OMAP5432
*/
#define GET_OMAP_CLASS (omap_rev() 0xff)
@@ -121,6 +122,7 @@ IS_OMAP_CLASS(16xx, 0x16)
IS_OMAP_CLASS(24xx, 0x24)
IS_OMAP_CLASS(34xx, 0x34)
IS_OMAP_CLASS(44xx, 0x44)
+IS_OMAP_CLASS(54xx, 0x54)
IS_AM_CLASS(33xx, 0x33)
IS_TI_CLASS(81xx, 0x81)
@@ -132,6 +134,7 @@ IS_OMAP_SUBCLASS(363x, 0x363)
IS_OMAP_SUBCLASS(443x, 0x443)
IS_OMAP_SUBCLASS(446x, 0x446)
IS_OMAP_SUBCLASS(447x, 0x447)
+IS_OMAP_SUBCLASS(543x, 0x543)
IS_TI_SUBCLASS(816x, 0x816)
IS_TI_SUBCLASS(814x, 0x814)
@@ -154,6 +157,8 @@ IS_AM_SUBCLASS(335x, 0x335)
#define cpu_is_omap443x() 0
#define cpu_is_omap446x() 0
#define cpu_is_omap447x() 0
+#define cpu_is_omap54xx() 0
+#define cpu_is_omap543x() 0
#if defined(MULTI_OMAP1)
# if defined(CONFIG_ARCH_OMAP730)
@@ -299,6 +304,7 @@ IS_OMAP_TYPE(3517, 0x3517)
#define cpu_is_omap3517() 0
#define cpu_is_omap3430() 0
#define cpu_is_omap3630() 0
+#define cpu_is_omap5430
[PATCH] ARM: OMAP2+: Fix omap2+ build error.
With CONFIG_OMAP4_ERRATA_I688 enabled, omap2+ build
was broken as below.
arch/arm/kernel/io.c: In function '_memcpy_toio':
arch/arm/kernel/io.c:29: error: implicit declaration of function
'outer_sync'
make[1]: *** [arch/arm/kernel/io.o] Error 1
Fixing this here.
Signed-off-by: R Sricharan r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/include/asm/barrier.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 44f4a09..0511238 100644
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -2,6 +2,7 @@
#define __ASM_BARRIER_H
#ifndef __ASSEMBLY__
+#include asm/outercache.h
#define nop() __asm__ __volatile__(mov\tr0,r0\t@ nop\n\t);
@@ -39,7 +40,6 @@
#ifdef CONFIG_ARCH_HAS_BARRIERS
#include mach/barriers.h
#elif defined(CONFIG_ARM_DMA_MEM_BUFFERABLE) || defined(CONFIG_SMP)
-#include asm/outercache.h
#define mb() do { dsb(); outer_sync(); } while (0)
#define rmb() dsb()
#define wmb() mb()
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: OMAP2+: Fix omap2+ build error.
With CONFIG_OMAP4_ERRATA_I688 enabled, omap2+ build
was broken as below.
arch/arm/kernel/io.c: In function '_memcpy_toio':
arch/arm/kernel/io.c:29: error: implicit declaration of function
'outer_sync'
make[1]: *** [arch/arm/kernel/io.o] Error 1
after the commit,
commit 9f97da78bf018206fb623cd351d454af2f105fe0
Author: David Howells dhowe...@redhat.com
Date: Wed Mar 28 18:30:01 2012 +0100
Disintegrate asm/system.h for ARM
Disintegrate asm/system.h for ARM.
Fixing this here.
Signed-off-by: R Sricharan r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/include/asm/barrier.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 44f4a09..0511238 100644
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -2,6 +2,7 @@
#define __ASM_BARRIER_H
#ifndef __ASSEMBLY__
+#include asm/outercache.h
#define nop() __asm__ __volatile__(mov\tr0,r0\t@ nop\n\t);
@@ -39,7 +40,6 @@
#ifdef CONFIG_ARCH_HAS_BARRIERS
#include mach/barriers.h
#elif defined(CONFIG_ARM_DMA_MEM_BUFFERABLE) || defined(CONFIG_SMP)
-#include asm/outercache.h
#define mb() do { dsb(); outer_sync(); } while (0)
#define rmb() dsb()
#define wmb() mb()
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: Fix module build errors with CONFIG_OMAP4_ERRATA_I688
While building modules with randconfig the below errors are observed. ERROR: omap_bus_sync [drivers/watchdog/sp805_wdt.ko] undefined! ERROR: omap_bus_sync [drivers/watchdog/dw_wdt.ko] undefined! ERROR: omap_bus_sync [drivers/virtio/virtio_ring.ko] undefined! ERROR: omap_bus_sync [drivers/video/sm501fb.ko] undefined! ERROR: omap_bus_sync [drivers/usb/mon/usbmon.ko] undefined! ERROR: omap_bus_sync [drivers/usb/host/sl811-hcd.ko] undefined! ERROR: omap_bus_sync [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: omap_bus_sync [drivers/usb/host/isp1760.ko] undefined! ERROR: omap_bus_sync [drivers/usb/host/isp1362-hcd.ko] undefined! ERROR: omap_bus_sync [drivers/usb/host/isp116x-hcd.ko] undefined! ERROR: omap_bus_sync [drivers/usb/core/usbcore.ko] undefined! ERROR: omap_bus_sync [drivers/tty/serial/altera_uart.ko] undefined! ERROR: omap_bus_sync [drivers/tty/serial/altera_jtaguart.ko] undefined! ERROR: omap_bus_sync [drivers/tty/serial/8250/8250_dw.ko] undefined! ERROR: omap_bus_sync [drivers/ssb/ssb.ko] undefined! ERROR: omap_bus_sync [drivers/rtc/rtc-cmos.ko] undefined! ERROR: omap_bus_sync [drivers/rtc/rtc-bq4802.ko] undefined! ERROR: omap_bus_sync [drivers/mtd/nand/tmio_nand.ko] undefined! ERROR: omap_bus_sync [drivers/mtd/nand/omap2.ko] undefined! Signed-off-by: R Sricharan r.sricha...@ti.com --- arch/arm/mach-omap2/omap4-common.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c index ebc5950..70de277 100644 --- a/arch/arm/mach-omap2/omap4-common.c +++ b/arch/arm/mach-omap2/omap4-common.c @@ -31,6 +31,7 @@ #include common.h #include omap4-sar-layout.h +#include linux/export.h #ifdef CONFIG_CACHE_L2X0 static void __iomem *l2cache_base; @@ -55,6 +56,7 @@ void omap_bus_sync(void) isb(); } } +EXPORT_SYMBOL(omap_bus_sync); /* Steal one page physical memory for barrier implementation */ int __init omap_barrier_reserve_memblock(void) -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS testing help?
Hi Paul, Hello Sricharan, It looks like Archit is out of the office. Would it be possible for you to test the updated DSS reset patch, below? Ok. I will test this. I have tested the patch from, git://gitorious.org/linux-omap-dss2/linux.git MASTER branch. I tested for about 100 iterations on beagle board C3 version. It was working fine. Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS testing help?
Paul, On Tue, Oct 4, 2011 at 2:18 AM, Paul Walmsley p...@pwsan.com wrote: Hello Sricharan, It looks like Archit is out of the office. Would it be possible for you to test the updated DSS reset patch, below? Ok. I will test this. snip .. Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Regression seen when HIGHMEM enabled with NFS on 3.1rc4 kernel
Sorry resending again. My mailer settings thrashed my earlier email.
Hi,
A kernel crash is observed on 3.1rc4 kernel when HIGHMEM is enabled and
kernel is booted with a NFS on omap4430sdp. The issue happens in the below
scenario.
In file net/sunrpc/xprtsock.c,
static int xs_send_pagedata( xxx, struct xdr_buf *xdr, ..)
{
Struct page **ppage;
.
ppage = xdr-pages + (base PAGE_SHIFT);
err = sock-ops-sendpage(sock, *ppage, base, len, flags);
...
}
1) In the above piece of code, the *ppage value from ops-sendpage
function is finally passed on to Kmap by the lower level code to
get the virtual address of the page.
2) In some corner cases the value of *ppage pointer is NULL.
3) When highmem is enabled and a NULL pointer is passed to
Kmap, then kmap finally crashes. But in the case when highmem
is disabled, then kmap returns a junk value for NULL pointer.
Highmem Enabled , kmap( NULL )- kernel crashes.
Highmem disabled, kmap( NULL )- junk value is returned.
Subsequently this message is observed on
the console.
RPC call returned error 14
4) Now the question is why is the value of *ppage = NULL is passed
from the above piece of code to lower layers.
Should that not have handled *ppage = NULL? and kmap should not
have received a NULL pointer?
Thanks,
Sricharan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/5] OMAP4: mux: Initialise OMAP4 mux pins.
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, November 19, 2010 2:56 AM To: Cousson, Benoit Cc: R, Sricharan; linux-omap@vger.kernel.org Subject: Re: [PATCH 0/5] OMAP4: mux: Initialise OMAP4 mux pins. * Cousson, Benoit b-cous...@ti.com [101118 12:56]: On 11/18/2010 8:06 PM, Tony Lindgren wrote: * sricharanr.sricha...@ti.com [101114 23:26]: This series updates the core device drivers to use mux framework for OMAP4 SDP and PANDA board. It's generated against the linux-omap master branch. It has a dependency on the Benoit's omap4 mux data series. snip 2. Do PAD configuration independently for each module Pros: a. Avoids repetition of similar data for different boards. b. Gives a knowledge of how pins are configured for a module to the respective owners. c. Pads are not initialised unless they are really needed. Cons: a. Can become difficult to maintain if lot of data tend to be different across boards. For the common modules, we should have generic platform init code using hwmod. And that init code is the logical place to do the muxing. We also need to consider that the pin muxing is board specific. So in cases where the are alternative signal paths, we need to pass the signal names from board-*.c file to the platform driver init code. What about the omap_board_mux array in board file? Do you want to get rid of it, or is the plan is to use that for pads that does not belong to any driver or pads that are purely board specific? Well we might as well keep it around for now as that's the way some people prefer to do the muxing. But yeah, eventually that could be for only board specific unused pads. I'll post some sample patches related to the uart (re)muxing within next few days, then let's see how that will work for other devices. Here's the rough plan in case you have some ideas on it: 1. board-*.c code calls omap_serial_init_port with struct omap_device_mux array that contains the pin names 2. serial.c init code muxes the pins the right way and sets wake-up events for omap3 4. It also populates the runtime remux values needed for omap2 uart 3. serial.c init code saves the struct omap_device_mux pointer to the related hwmod entry 4. omap_device_idle/shutdown can then call omap_remux if the omap_device_mux entry exists ... This should solve how devices need to initialize the pads. It should also work for all devices that may require runtime remuxing, like some USB transceivers and eMMC. Ok . This means that the pin muxing introduced would be applicable for omap 2 ,3 and 4 also, with the board file passing the respective data if they are different ? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/5] OMAP4: mux: Initialise OMAP4 mux pins.
Adding people in CC. This series updates the core device drivers to use mux framework for OMAP4 SDP and PANDA board. It's generated against the linux-omap master branch. It has a dependency on the Benoit's omap4 mux data series. http://www.spinics.net/lists/linux-omap/msg40039.html sricharan (5): OMAP4: hsmmc: Initialise the mmc mux pins OMAP4: usb-musb: Initialise the usb mux pins. OMAP4: mcbsp: Initialise the mcbsp mux pins OMAP4: board-4430sdp: Initialise the mcspi mux pins OMAP4: serial: Initialise the uart mux pins arch/arm/mach-omap2/board-4430sdp.c | 20 arch/arm/mach-omap2/devices.c | 83 +++ arch/arm/mach-omap2/mcbsp.c | 33 +- arch/arm/mach-omap2/serial.c| 38 arch/arm/mach-omap2/usb-musb.c | 41 + 5 files changed, 214 insertions(+), 1 deletions(-) While doing some internal reviews, there were few debates about existing mux framework usage. I am summarising that discussion here and would like to hear more on this from the community. 1. PAD configuration for all pins should be done in a central place(board file) Pros: a. All pins configured in a central place. Easy to ensure coverage and maintenance. Single place to look for all mux related settings b. Drivers, unless they have run time pad configuration requirements need not worry about muxing. Cons: a. Adds a lot of duplicate data in different board files assuming most of the pins will be connected the same way across different boards. 2. Do PAD configuration independently for each module Pros: a. Avoids repetition of similar data for different boards. b. Gives a knowledge of how pins are configured for a module to the respective owners. c. Pads are not initialised unless they are really needed. Cons: a. Can become difficult to maintain if lot of data tend to be different across boards. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
