RE: [PATCH 11/14] omap: Remap L3, L4 to get more kernel io address space
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Tuesday, October 20, 2009 5:51 AM To: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org; Shilimkar, Santosh Subject: Re: [PATCH 11/14] omap: Remap L3, L4 to get more kernel io address space * Tony Lindgren t...@atomide.com [091016 16:42]: From: Santosh Shilimkar santosh.shilim...@ti.com This patch remap L3 and L4 io space to get more kernel address space. With this patch, 512 MB of IO space is reclaimed. Some more combinations are possible but to make it uniform across OMAP24XX, OMAP34XX and OMAP4430, these io combinations are chosen Once this is reviewed and tested sufficiently, a documentation entry can be created to ease up reading and debugging. Like Documentation/arm/omap/io_map.txt Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/plat-omap/include/mach/io.h | 97 ++--- arch/arm/plat-omap/include/mach/vmalloc.h |2 - 2 files changed, 60 insertions(+), 39 deletions(-) snip diff --git a/arch/arm/plat-omap/include/mach/vmalloc.h b/arch/arm/plat-omap/include/mach/vmalloc.h index b97dfaf..9eebf62 100644 --- a/arch/arm/plat-omap/include/mach/vmalloc.h +++ b/arch/arm/plat-omap/include/mach/vmalloc.h @@ -17,5 +17,5 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -#define VMALLOC_END (PAGE_OFFSET + 0x1800) +#define VMALLOC_END (PAGE_OFFSET + 0x3800) This vmalloc.h change causes issues on omap1. I'll update the series to ifdef this define. Then I'll split the file in the later patches into separate vmalloc.h for mach-omap1 and mach-omap2, see below. OK Regrads Santosh -- 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 08/14] omap: Use ioremap for omap4 L4 code
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Monday, October 19, 2009 10:42 PM To: Shilimkar, Santosh Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 08/14] omap: Use ioremap for omap4 L4 code * Shilimkar, Santosh santosh.shilim...@ti.com [091019 00:27]: Tony, -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Monday, October 19, 2009 5:54 AM To: Shilimkar, Santosh Cc: linux-arm-ker...@lists.infradead.org; linux- o...@vger.kernel.org Subject: Re: [PATCH 08/14] omap: Use ioremap for omap4 L4 code * Tony Lindgren t...@atomide.com [091017 09:19]: * Shilimkar, Santosh santosh.shilim...@ti.com [091017 03:49]: Thanks Tony for this ioremap series!! -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Saturday, October 17, 2009 5:16 AM To: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org; Shilimkar, Santosh Subject: Re: [PATCH 08/14] omap: Use ioremap for omap4 L4 code * Tony Lindgren t...@atomide.com [091016 16:42]: Use ioremap for omap4 L4 code Santosh, can you please check and ack this patch? Especially some of the ioremap sizes may be wrong. Also, this one I cannot boot test, so it's just compile tested. I have checked the patch and it looks all right except few typo. Also the scu_base is needed bit earlier. snip Here is the patch on top of ioremap series which should fix above mentioned things. With below patch + two serial related patches the kernel boots on OMAP4430. Great, will update. Thanks for taking the time to fix it! Here's this one updated with Santosh's fix merged in. V2 has one typo which I think I also missed in my patch. + /* Static mapping, never released */ + gic_cpu_base_addr = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_512); + BUG_ON(!base); Should be BUG_ON(!gic_cpu_base_addr); OK, here's V3 of the patch. It's complete now :) Regards, Santosh -- 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 08/14] omap: Use ioremap for omap4 L4 code
Tony, -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Monday, October 19, 2009 5:54 AM To: Shilimkar, Santosh Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 08/14] omap: Use ioremap for omap4 L4 code * Tony Lindgren t...@atomide.com [091017 09:19]: * Shilimkar, Santosh santosh.shilim...@ti.com [091017 03:49]: Thanks Tony for this ioremap series!! -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Saturday, October 17, 2009 5:16 AM To: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org; Shilimkar, Santosh Subject: Re: [PATCH 08/14] omap: Use ioremap for omap4 L4 code * Tony Lindgren t...@atomide.com [091016 16:42]: Use ioremap for omap4 L4 code Santosh, can you please check and ack this patch? Especially some of the ioremap sizes may be wrong. Also, this one I cannot boot test, so it's just compile tested. I have checked the patch and it looks all right except few typo. Also the scu_base is needed bit earlier. snip Here is the patch on top of ioremap series which should fix above mentioned things. With below patch + two serial related patches the kernel boots on OMAP4430. Great, will update. Thanks for taking the time to fix it! Here's this one updated with Santosh's fix merged in. V2 has one typo which I think I also missed in my patch. + /* Static mapping, never released */ + gic_cpu_base_addr = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_512); + BUG_ON(!base); Should be BUG_ON(!gic_cpu_base_addr); Regards, Santosh -- 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 08/14] omap: Use ioremap for omap4 L4 code
Thanks Tony for this ioremap series!!
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Saturday, October 17, 2009 5:16 AM
To: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org; Shilimkar, Santosh
Subject: Re: [PATCH 08/14] omap: Use ioremap for omap4 L4 code
* Tony Lindgren t...@atomide.com [091016 16:42]:
Use ioremap for omap4 L4 code
Santosh, can you please check and ack this patch?
Especially some of the ioremap sizes may be wrong. Also, this one
I cannot boot test, so it's just compile tested.
I have checked the patch and it looks all right except few typo. Also the
scu_base is needed bit earlier.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c | 13 ++--
arch/arm/mach-omap2/omap-smp.c| 28
-
arch/arm/mach-omap2/timer-gp.c|3 ++-
arch/arm/plat-omap/include/mach/entry-macro.S |2 ++
arch/arm/plat-omap/include/mach/omap44xx.h|5
5 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
omap2/board-4430sdp.c
index eb37c40..2a7b901 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -52,8 +52,17 @@ static struct omap_board_config_kernel
sdp4430_config[] __initdata = {
static void __init gic_init_irq(void)
{
- gic_dist_init(0, OMAP2_IO_ADDRESS(OMAP44XX_GIC_DIST_BASE), 29);
- gic_cpu_init(0, OMAP2_IO_ADDRESS(OMAP44XX_GIC_CPU_BASE));
+ void __iomem *base;
+
+ /* Static mapping, never released */
+ base = ioremap(OMAP44XX_GIC_DIST_BASE, SZ_4K);
+ BUG_ON(!base);
+ gic_dist_init(0, base, 29);
+
+ /* Static mapping, never released */
+ base = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_256);
Should be SZ_512
+ BUG_ON(!base);
+ gic_cpu_init(0, OMAP44XX_GIC_CPU_BASE);
This should be gic_cpu_init(0, base);
}
static void __init omap_4430sdp_init_irq(void)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-
smp.c
index 48ee295..a1b618c 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -26,11 +26,11 @@
#include mach/hardware.h
/* Registers used for communicating startup information */
-#define OMAP4_AUXCOREBOOT_REG0 (OMAP44XX_VA_WKUPGEN_BASE +
0x800)
-#define OMAP4_AUXCOREBOOT_REG1 (OMAP44XX_VA_WKUPGEN_BASE +
0x804)
+static void __iomem *omap4_auxcoreboot_reg0;
+static void __iomem *omap4_auxcoreboot_reg1;
/* SCU base address */
-static void __iomem *scu_base = OMAP44XX_VA_SCU_BASE;
+static void __iomem *scu_base;
/*
* Use SCU config register to count number of cores
@@ -46,6 +46,8 @@ static DEFINE_SPINLOCK(boot_lock);
void __cpuinit platform_secondary_init(unsigned int cpu)
{
+ void __iomem *gic_cpu_base;
+
trace_hardirqs_off();
/*
@@ -54,7 +56,10 @@ void __cpuinit platform_secondary_init(unsigned int
cpu)
* for us: do so
*/
- gic_cpu_init(0, OMAP2_IO_ADDRESS(OMAP44XX_GIC_CPU_BASE));
+ /* Static mapping, never released */
+ gic_cpu_base = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_256);
Although underneath static mapping will take care of not doing dual mapping, we
can map this ones in gic_init_irq() and use the same variable here.
+ BUG_ON(!gic_cpu_base);
+ gic_cpu_init(0, gic_cpu_base);
/*
* Synchronise with the boot thread.
@@ -79,7 +84,7 @@ 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 is drained
*/
- __raw_writel(cpu, OMAP4_AUXCOREBOOT_REG1);
+ __raw_writel(cpu, omap4_auxcoreboot_reg1);
smp_wmb();
timeout = jiffies + (1 * HZ);
@@ -104,7 +109,7 @@ static void __init wakeup_secondary(void)
* A barrier is added to ensure that write buffer is drained
*/
__raw_writel(virt_to_phys(omap_secondary_startup), \
- OMAP4_AUXCOREBOOT_REG0);
+ omap4_auxcoreboot_reg0);
smp_wmb();
/*
@@ -130,6 +135,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
{
unsigned int ncores = get_core_count();
This call will not give correct count. Also there is one more call earlier and
hence scu_base ioremaps needs to be done earlier.
unsigned int cpu = smp_processor_id();
+ void __iomem *omap4_wkupgen_base;
int i;
/* sanity check */
@@ -161,6 +167,16 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
for (i = 0; i max_cpus; i++)
set_cpu_present(i, true);
+ /* Never released */
+ omap4_wkupgen_base = ioremap(OMAP44XX_WKUPGEN_BASE, SZ_4K
RE: [PATCH] OMAP3: Fix McBSP poll read and write for 32bit reg access
snip
-Original Message-
From: Varadarajan, Charu Latha
Sent: Thursday, October 15, 2009 10:59 AM
To: Shilimkar, Santosh; linux-omap@vger.kernel.org
Cc: Syed, Rafiuddin
Subject: RE: [PATCH] OMAP3: Fix McBSP poll read and write for 32bit reg
access
__
Subject: RE: [PATCH] OMAP3: Fix McBSP poll read and write for
32bit reg access
Charu,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Varadarajan, Charu Latha
Sent: Wednesday, October 14, 2009 3:00 PM
To: linux-omap@vger.kernel.org
Cc: Varadarajan, Charu Latha; Syed, Rafiuddin
Subject: [PATCH] OMAP3: Fix McBSP poll read and write for
32bit reg access
omap_mcbsp_pollwrite and omap_mcbsp_pollread functions access
McBSP registers as 16-bit registers.
The McBSP registers (DRR_REG and DXR_REG) are limited to
32-bit data accesses (L4 Interconnect). 16-bit and 8-bit is
not allowed and can corrupt register content.
This patch modifies omap_mcbsp_pollwrite and
omap_mcbsp_pollread functions to do 32 bit access for above
mentioned McBSP registers. Data accepted by these
functions is also modified to 32-bit.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
---
arch/arm/plat-omap/include/mach/mcbsp.h |4 +-
arch/arm/plat-omap/mcbsp.c | 46
++
-
2 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-
omap/include/mach/mcbsp.h
index 7e9cae3..05b0d8d 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -455,8 +455,8 @@ int
omap_mcbsp_spi_master_recv_word_poll(unsigned int
id, u32 * word);
void omap_mcbsp_set_spi_mode(unsigned int id, const struct
omap_mcbsp_spi_cfg * spi_cfg);
/* Polled read/write functions */
-int omap_mcbsp_pollread(unsigned int id, u16 * buf);
-int omap_mcbsp_pollwrite(unsigned int id, u16 buf);
+int omap_mcbsp_pollread(unsigned int id, u32 *buf);
+int omap_mcbsp_pollwrite(unsigned int id, u32 buf);
If the issue is with DRR_REG and DXR_REG, why are you
changing the signature of the generic API. You can handle
these registers as a exceptions in the code.
If 32 bit data could be read and written on McBSP, why should we
restrict
poll read and
poll write functions only for 16 bit data read and write?
If these API's are only accessing the DXR and DRR regs then this is OK.
int omap_mcbsp_set_io_type(unsigned int id, omap_mcbsp_io_type_t
io_type);
#endif
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-
omap/mcbsp.c
index 88ac976..1f278a2 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -613,7 +613,7 @@ void omap_mcbsp_stop(unsigned int id,
int tx, int rx)
EXPORT_SYMBOL(omap_mcbsp_stop);
/* polled mcbsp i/o operations */
-int omap_mcbsp_pollwrite(unsigned int id, u16 buf)
+int omap_mcbsp_pollwrite(unsigned int id, u32 buf)
{
struct omap_mcbsp *mcbsp;
void __iomem *base;
@@ -626,26 +626,24 @@ int omap_mcbsp_pollwrite(unsigned int
id, u16 buf)
mcbsp = id_to_mcbsp_ptr(id);
base = mcbsp-io_base;
- writew(buf, base + OMAP_MCBSP_REG_DXR1);
+ OMAP_MCBSP_WRITE(base, DXR, buf);
Why do you need this? Is writew()/readw() not doing 16 bit
operations ?
The intension is to use 32 bit access and not 16 bit access
Use readl() / writel() then.
Yes, OMAP_MCBSP_WRITE macro makes use of readl() / writel() for OMAP3
Good!! Then get rid of this macro and directly use kernel standard API- readl()
/ writel()
--
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] OMAP3: Fix McBSP poll read and write for 32bit reg access
Charu, -Original Message- From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com] Sent: Thursday, October 15, 2009 12:56 PM To: Shilimkar, Santosh Cc: Varadarajan, Charu Latha; linux-omap@vger.kernel.org; Syed, Rafiuddin Subject: Re: [PATCH] OMAP3: Fix McBSP poll read and write for 32bit reg access On Thursday 15 October 2009 09:10:54 ext Shilimkar, Santosh wrote: - writew(buf, base + OMAP_MCBSP_REG_DXR1); + OMAP_MCBSP_WRITE(base, DXR, buf); Why do you need this? Is writew()/readw() not doing 16 bit operations ? The intension is to use 32 bit access and not 16 bit access Use readl() / writel() then. Yes, OMAP_MCBSP_WRITE macro makes use of readl() / writel() for OMAP3 Good!! Then get rid of this macro and directly use kernel standard API- readl() / writel() -- Well, OMAP1 and OMAP2 still has 16 bit registers in McBSP. Please look at this comment from Peter. So please reconsider your patch and decision of changing the signature of the API since it breaks OMAP1 and OMAP2. Regards, Santosh -- 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: SMP: BUG with PREEMPT enabled
The patch submitted to patch-system I based it on 2.6.32-rc4
Have you tried that patch ?
The one attached was in email was based on 2.6.31
Regards,
Santosh
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Thursday, October 15, 2009 5:11 PM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: SMP: BUG with PREEMPT enabled
On Wed, Oct 14, 2009 at 04:56:18PM +0530, Shilimkar, Santosh wrote:
On the latest ARM kernel(v2.6.32-rc4),I have observed a BUG() dump
when
Umm...
@@ -350,7 +350,7 @@ static inline void local_flush_tlb_mm(struct
mm_struct *mm)
if (tlb_flag(TLB_WB))
dsb();
- if (cpu_isset(smp_processor_id(), mm-cpu_vm_mask)) {
+ if (cpu_isset(get_cpu(), mm-cpu_vm_mask)) {
This isn't 2.6.32-rc4 code - which actually is:
if (cpumask_test_cpu(smp_processor_id(), mm_cpumask(mm))) {
so what kernel version are you working with?
The result is this patch won't apply to 2.6.32-rc4.
--
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: SMP: BUG with PREEMPT enabled
-Original Message- From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm- kernel-boun...@lists.infradead.org] On Behalf Of Shilimkar, Santosh Sent: Thursday, October 15, 2009 6:55 PM To: Russell King - ARM Linux Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: SMP: BUG with PREEMPT enabled The patch submitted to patch-system I based it on 2.6.32-rc4 Have you tried that patch ? The one attached was in email was based on 2.6.31 I have submitted the correct version to patch system again. Regards Santosh -- 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] ARM: OMAP: SDMA: Fix omap_stop_dma() API for channel linking
snip This fix should be tested in linux-omap before we send this to mainline. Yes ofcourse. That what I meant by merge. Yeah, we should still have enough time to get it into mainline kernel as a fix during this -rc cycle. OK. Also please merge other two patches in linux-omap master since omap4 needs those two patches to boot. -- 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
patches rebased on 2.6.32-rc4
Tony, I am re-sending three patches rebased on the 2.6.32-rc4 mainline for the merge. You have already seen these on linux-omap mailing list. Second patch is spilt because it has two independent fixes. These patches are boot tested on - OMAP3430 SDP - OMAP3 beagle - OMAP4430 platform Santosh Shilimkar (3): ARM: OMAP: SDMA: Fix omap_stop_dma() API for channel linking ARM: OMAP4: Allow omap_serial_early_init() for OMAP4430 board ARM: OMAP4: Fix UART4 platform data arch/arm/mach-omap2/board-4430sdp.c |4 ++-- arch/arm/mach-omap2/io.c|2 ++ arch/arm/mach-omap2/serial.c| 10 -- arch/arm/plat-omap/dma.c|9 + 4 files changed, 9 insertions(+), 16 deletions(-) Please see if they are fine with you. If it helps you for merge, these patches can also be pulled from: git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git omap4_upstream Regards, Santosh -- 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] OMAP3: Fix McBSP poll read and write for 32bit reg access
Charu,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Varadarajan, Charu Latha
Sent: Wednesday, October 14, 2009 3:00 PM
To: linux-omap@vger.kernel.org
Cc: Varadarajan, Charu Latha; Syed, Rafiuddin
Subject: [PATCH] OMAP3: Fix McBSP poll read and write for 32bit reg access
omap_mcbsp_pollwrite and omap_mcbsp_pollread functions access
McBSP registers as 16-bit registers.
The McBSP registers (DRR_REG and DXR_REG) are limited to
32-bit data accesses (L4 Interconnect). 16-bit and 8-bit is
not allowed and can corrupt register content.
This patch modifies omap_mcbsp_pollwrite and
omap_mcbsp_pollread functions to do 32 bit access for above
mentioned McBSP registers. Data accepted by these
functions is also modified to 32-bit.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
---
arch/arm/plat-omap/include/mach/mcbsp.h |4 +-
arch/arm/plat-omap/mcbsp.c | 46 ++
-
2 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-
omap/include/mach/mcbsp.h
index 7e9cae3..05b0d8d 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -455,8 +455,8 @@ int omap_mcbsp_spi_master_recv_word_poll(unsigned int
id, u32 * word);
void omap_mcbsp_set_spi_mode(unsigned int id, const struct
omap_mcbsp_spi_cfg * spi_cfg);
/* Polled read/write functions */
-int omap_mcbsp_pollread(unsigned int id, u16 * buf);
-int omap_mcbsp_pollwrite(unsigned int id, u16 buf);
+int omap_mcbsp_pollread(unsigned int id, u32 *buf);
+int omap_mcbsp_pollwrite(unsigned int id, u32 buf);
If the issue is with DRR_REG and DXR_REG, why are you changing the signature of
the generic API. You can handle these registers as a exceptions in the code.
int omap_mcbsp_set_io_type(unsigned int id, omap_mcbsp_io_type_t
io_type);
#endif
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 88ac976..1f278a2 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -613,7 +613,7 @@ void omap_mcbsp_stop(unsigned int id, int tx, int rx)
EXPORT_SYMBOL(omap_mcbsp_stop);
/* polled mcbsp i/o operations */
-int omap_mcbsp_pollwrite(unsigned int id, u16 buf)
+int omap_mcbsp_pollwrite(unsigned int id, u32 buf)
{
struct omap_mcbsp *mcbsp;
void __iomem *base;
@@ -626,26 +626,24 @@ int omap_mcbsp_pollwrite(unsigned int id, u16 buf)
mcbsp = id_to_mcbsp_ptr(id);
base = mcbsp-io_base;
- writew(buf, base + OMAP_MCBSP_REG_DXR1);
+ OMAP_MCBSP_WRITE(base, DXR, buf);
Why do you need this? Is writew()/readw() not doing 16 bit operations ?
/* if frame sync error - clear the error */
- if (readw(base + OMAP_MCBSP_REG_SPCR2) XSYNC_ERR) {
+ if (OMAP_MCBSP_READ(base, SPCR2) XSYNC_ERR) {
/* clear error */
- writew(readw(base + OMAP_MCBSP_REG_SPCR2) (~XSYNC_ERR),
-base + OMAP_MCBSP_REG_SPCR2);
+ OMAP_MCBSP_WRITE(base, SPCR2, OMAP_MCBSP_READ(base , SPCR2)
+ (~XSYNC_ERR));
/* resend */
return -1;
} else {
/* wait for transmit confirmation */
int attemps = 0;
- while (!(readw(base + OMAP_MCBSP_REG_SPCR2) XRDY)) {
+ while (!(OMAP_MCBSP_READ(base, SPCR2) XRDY)) {
if (attemps++ 1000) {
- writew(readw(base + OMAP_MCBSP_REG_SPCR2)
-(~XRST),
-base + OMAP_MCBSP_REG_SPCR2);
+ OMAP_MCBSP_WRITE(base, SPCR2,
+ OMAP_MCBSP_READ(base, SPCR2) (~XRST));
udelay(10);
- writew(readw(base + OMAP_MCBSP_REG_SPCR2) |
-(XRST),
-base + OMAP_MCBSP_REG_SPCR2);
+ OMAP_MCBSP_WRITE(base, SPCR2,
+ OMAP_MCBSP_READ(base, SPCR2) | (XRST));
udelay(10);
dev_err(mcbsp-dev, Could not write to
McBSP%d Register\n, mcbsp-id);
@@ -658,7 +656,7 @@ int omap_mcbsp_pollwrite(unsigned int id, u16 buf)
}
EXPORT_SYMBOL(omap_mcbsp_pollwrite);
-int omap_mcbsp_pollread(unsigned int id, u16 *buf)
+int omap_mcbsp_pollread(unsigned int id, u32 *buf)
{
struct omap_mcbsp *mcbsp;
void __iomem *base;
@@ -671,24 +669,22 @@ int omap_mcbsp_pollread(unsigned int id, u16 *buf)
base = mcbsp-io_base;
/* if frame sync error - clear the error */
- if (readw(base + OMAP_MCBSP_REG_SPCR1) RSYNC_ERR) {
+ if
RE: SMP: BUG with PREEMPT enabled
-Original Message-
From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-
kernel-boun...@lists.infradead.org] On Behalf Of Shilimkar, Santosh
Sent: Tuesday, October 13, 2009 5:33 PM
To: Russell King - ARM Linux
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: ARM: SMP: BUG with PREEMPT enabled
Russell,
On the latest ARM kernel(v2.6.32-rc4),I have observed a BUG() dump when
PREEMPT is enabled.
Attached is the detailed log for your reference.
snip
**
BUG: using smp_processor_id() in preemptible [] code: init/1
caller is flush_tlb_mm+0x44/0x70
Backtrace:
[c00225c4] (dump_backtrace+0x0/0x110) from [c01713a0]
(dump_stack+0x18/0x1c)
r7: r6:c00234f0 r5:0001 r4:c7828000
[c0171388] (dump_stack+0x0/0x1c) from [c0135364]
(debug_smp_processor_id+0xc0/0xf0)
[c01352a4] (debug_smp_processor_id+0x0/0xf0) from [c00234f0]
(flush_tlb_mm+0x44/0x70)
r7: r6:c60b41a0 r5:c60b4154 r4:0001
[c00234ac] (flush_tlb_mm+0x0/0x70) from [c0039568]
(dup_mm+0x304/0x38c)
r5:c1f09058 r4:
[c0039264] (dup_mm+0x0/0x38c) from [c0039de4]
(copy_process+0x7b8/0xeb0)
[c003962c] (copy_process+0x0/0xeb0) from [c003a638]
(do_fork+0x15c/0x29c)
[c003a4dc] (do_fork+0x0/0x29c) from [c0021df0] (sys_clone+0x34/0x3c)
[c0021dbc] (sys_clone+0x0/0x3c) from [c001efa0]
(ret_fast_syscall+0x0/0x2c)
**
As evident from the log smp_processor_id is used in preemptible code.
This gets triggered from
flush_tlb_mm() --
local_flush_tlb_mm()
{
if (cpu_isset(smp_processor_id(), vma-vm_mm-cpu_vm_mask)) ^^
}
This can be guuarded using get_cpu/put_cpu pair which can make it
preemption safe but I am not sure whether that is the right fix.
Let me know your remarks !!
Here is the patch I used to fix this BUG.
From 1ea679d6ffded2a15bcdbdf29d0528b82df5914d Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Wed, 14 Oct 2009 16:47:12 +0530
Subject: [PATCH] ARM: SMP: Fix the BUG with CONFIG_PREEMPT enabled
This patch fixes the BUG: using smp_processor_id() in preemptible
Below is the stripped backtrace.
BUG: using smp_processor_id() in preemptible [] code: init/1
caller is flush_tlb_mm+0x44/0x70
Backtrace:
[c00225c4] (dump_backtrace+0x0/0x110) from [c01713a0] (dump_stack+0x18/0x1c)
r7: r6:c00234f0 r5:0001 r4:c7828000
[c0171388] (dump_stack+0x0/0x1c) from [c0135364]
(debug_smp_processor_id+0xc0/0xf0)
[c01352a4] (debug_smp_processor_id+0x0/0xf0) from [c00234f0]
(flush_tlb_mm+0x44/0x70)
r7: r6:c60b41a0 r5:c60b4154 r4:0001
[c00234ac] (flush_tlb_mm+0x0/0x70) from [c0039568] (dup_mm+0x304/0x38c)
r5:c1f09058 r4:
[c0039264] (dup_mm+0x0/0x38c) from [c0039de4] (copy_process+0x7b8/0xeb0)
[c003962c] (copy_process+0x0/0xeb0) from [c003a638] (do_fork+0x15c/0x29c)
[c003a4dc] (do_fork+0x0/0x29c) from [c0021df0] (sys_clone+0x34/0x3c)
[c0021dbc] (sys_clone+0x0/0x3c) from [c001efa0] (ret_fast_syscall+0x0/0x2c)
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/include/asm/tlbflush.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index c964f3f..a0abf5c 100644
--- a/arch/arm/include/asm/tlbflush.h
+++ b/arch/arm/include/asm/tlbflush.h
@@ -350,7 +350,7 @@ static inline void local_flush_tlb_mm(struct mm_struct *mm)
if (tlb_flag(TLB_WB))
dsb();
- if (cpu_isset(smp_processor_id(), mm-cpu_vm_mask)) {
+ if (cpu_isset(get_cpu(), mm-cpu_vm_mask)) {
if (tlb_flag(TLB_V3_FULL))
asm(mcr p15, 0, %0, c6, c0, 0 : : r (zero) : cc);
if (tlb_flag(TLB_V4_U_FULL))
@@ -360,6 +360,7 @@ static inline void local_flush_tlb_mm(struct mm_struct *mm)
if (tlb_flag(TLB_V4_I_FULL))
asm(mcr p15, 0, %0, c8, c5, 0 : : r (zero) : cc);
}
+ put_cpu();
if (tlb_flag(TLB_V6_U_ASID))
asm(mcr p15, 0, %0, c8, c7, 2 : : r (asid) : cc);
--
1.5.4.7
Regards,
Santosh
--
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] ARM: OMAP: SDMA: Fix omap_stop_dma() API for channel linking
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, October 14, 2009 10:36 PM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; S, Venkatraman; Hari n; Jarkko Nikula
Subject: Re: [PATCH] ARM: OMAP: SDMA: Fix omap_stop_dma() API for channel
linking
* Santosh Shilimkar santosh.shilim...@ti.com [091013 23:14]:
OMAP sDMA driver API omap_stop_dma() doesn't really stop the dma when
used
in linking scenario. This patch fixes the same.
To me it looks like this will break things for omap1 as the DMA channel
interrupt is not disabled first. I guess the fix is to move the
Disable all interrupts on the channel part above clearing the
link mappings.
Indeed it will break OMAP1. Initially I thought of putting this change at this
place so that it takes care of both normal and linking scenario.
I will rework this and send v2.
This fix should be tested in linux-omap before we send this to mainline.
Yes ofcourse. That what I meant by merge.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
CC: Hari n hari.z...@gmail.com
CC: Jarkko Nikula jhnik...@gmail.com
---
arch/arm/plat-omap/dma.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index fd3154a..633c123 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -975,6 +975,11 @@ void omap_stop_dma(int lch)
{
u32 l;
+ /* Disable the DMA channel */
+ l = dma_read(CCR(lch));
+ l = ~OMAP_DMA_CCR_EN;
+ dma_write(l, CCR(lch));
+
if (!omap_dma_in_1510_mode() dma_chan[lch].next_lch != -1) {
int next_lch, cur_lch = lch;
char dma_chan_link_map[OMAP_DMA4_LOGICAL_DMA_CH_COUNT];
@@ -1000,10 +1005,6 @@ void omap_stop_dma(int lch)
if (cpu_class_is_omap1())
dma_write(0, CICR(lch));
- l = dma_read(CCR(lch));
- l = ~OMAP_DMA_CCR_EN;
- dma_write(l, CCR(lch));
-
dma_chan[lch].flags = ~OMAP_DMA_ACTIVE;
}
EXPORT_SYMBOL(omap_stop_dma);
--
1.5.4.7
Regards,
Santosh
--
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: SMP: BUG with PREEMPT enabled
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Thursday, October 15, 2009 1:44 AM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: SMP: BUG with PREEMPT enabled On Wed, Oct 14, 2009 at 04:56:18PM +0530, Shilimkar, Santosh wrote: Here is the patch I used to fix this BUG. Patch is good. Could you send it to the patch system. Please note that the patch system now almost accepts standard patch submissions (in other words, it no longer requires the PATCH FOLLOWS tag.) However, it still requires the KernelVersion: tag to appear somewhere before the patch. Sure !! Regards, Santosh -- 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] [RFC] omap: 3630: default cpu_is_omap3630 to zero
Has anybody tried building latest linux-omap master ? The build is breaking for other OMAP processors. CC arch/arm/mach-omap2/id.o arch/arm/mach-omap2/id.c: In function 'omap3_cpuinfo': arch/arm/mach-omap2/id.c:269: error: implicit declaration of function 'cpu_is_omap3630' make[1]: *** [arch/arm/mach-omap2/id.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 This is because of 0a9b95f21995aa3cdda82ebc6e77b0b2ab401861 omap: Introduce OMAP3630 Below patch from Vikram fixes the build break. -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Pandita, Vikram Sent: Tuesday, October 13, 2009 2:38 AM To: Menon, Nishanth Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] [RFC] omap: 3630: default cpu_is_omap3630 to zero -Original Message- From: Menon, Nishanth Sent: Monday, October 12, 2009 4:05 PM To: Pandita, Vikram Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] [RFC] omap: 3630: default cpu_is_omap3630 to zero -Original Message- From: Pandita, Vikram Sent: Monday, October 12, 2009 3:51 PM make default cpu_is_omap3630() return zero Signed-off-by: Vikram Pandita vikram.pand...@ti.com --- arch/arm/plat-omap/include/mach/cpu.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- omap/include/mach/cpu.h index da9e8f8..940946e 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -322,6 +322,7 @@ IS_OMAP_TYPE(3430, 0x3430) #define cpu_is_omap2423() 0 #define cpu_is_omap2430() 0 #define cpu_is_omap3430() 0 +#define cpu_is_omap3630() 0 /* * Whether we have MULTI_OMAP1 or not, we still need to distinguish @@ -386,6 +387,7 @@ IS_OMAP_TYPE(3430, 0x3430) (omap3_has_sgx()) \ (!omap3_has_iva())) # define cpu_is_omap3530 (cpu_is_omap3430()) +# undef cpu_is_omap3630() # define cpu_is_omap3630()is_omap363x() #endif Dumb question: why is this needed? cpu_is_omap3530,15,25,03 don't seems to declare these.. If in some file, you want to distinguish between 3630 vs 3430, and the build is for 3430 only, then cpu_is_omap3630() should return 0. Eg: opp table allocation based on run time check Omap35xx may also need it for the opp in future I guess. -- 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
ARM: SMP: BUG with PREEMPT enabled
Russell,
On the latest ARM kernel(v2.6.32-rc4),I have observed a BUG() dump when PREEMPT
is enabled.
Attached is the detailed log for your reference.
snip
**
BUG: using smp_processor_id() in preemptible [] code: init/1
caller is flush_tlb_mm+0x44/0x70
Backtrace:
[c00225c4] (dump_backtrace+0x0/0x110) from [c01713a0] (dump_stack+0x18/0x1c)
r7: r6:c00234f0 r5:0001 r4:c7828000
[c0171388] (dump_stack+0x0/0x1c) from [c0135364]
(debug_smp_processor_id+0xc0/0xf0)
[c01352a4] (debug_smp_processor_id+0x0/0xf0) from [c00234f0]
(flush_tlb_mm+0x44/0x70)
r7: r6:c60b41a0 r5:c60b4154 r4:0001
[c00234ac] (flush_tlb_mm+0x0/0x70) from [c0039568] (dup_mm+0x304/0x38c)
r5:c1f09058 r4:
[c0039264] (dup_mm+0x0/0x38c) from [c0039de4] (copy_process+0x7b8/0xeb0)
[c003962c] (copy_process+0x0/0xeb0) from [c003a638] (do_fork+0x15c/0x29c)
[c003a4dc] (do_fork+0x0/0x29c) from [c0021df0] (sys_clone+0x34/0x3c)
[c0021dbc] (sys_clone+0x0/0x3c) from [c001efa0] (ret_fast_syscall+0x0/0x2c)
**
As evident from the log smp_processor_id is used in preemptible code. This
gets triggered from
flush_tlb_mm() --
local_flush_tlb_mm()
{
if (cpu_isset(smp_processor_id(), vma-vm_mm-cpu_vm_mask)) ^^
}
This can be guuarded using get_cpu/put_cpu pair which can make it preemption
safe but I am not sure whether that is the right fix.
Let me know your remarks !!
Regards,
Santosh
preempt.log
Description: preempt.log
RE: FEATURES prints
Sanjeev, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Wednesday, October 14, 2009 3:26 AM To: Kevin Hilman; Menon, Nishanth Cc: linux-omap@vger.kernel.org Subject: RE: FEATURES prints -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, October 14, 2009 3:17 AM To: Menon, Nishanth Cc: Premi, Sanjeev; linux-omap@vger.kernel.org Subject: Re: FEATURES prints Nishanth Menon n...@ti.com writes: Folks, With the addition of FEATURES in l-o, the following prints: - l2cache : Y - iva : Y - sgx : Y - neon : Y - isp : Y comes up on SDP3430 - now that we will introduce half a dozen features here and there, we will soon clutter this up. we should introduce a sysfs entry + remove the above noise.. Like Nishanth, I don't like the multi-line noise here. The patch below results in a single line output like this instead OMAP3430/3530 ES3.0 (l2cache iva sgx neon isp ) Not sure why we need to dump features that are not there, but if that s considered important, maybe prefixing each feature with a '+' or '-' would still allow this to be collapsed into a single line. Even with this, I think adding the display of these features into an OMAP-specific section of /proc/cpuinfo would be even better. [sp] Single line prints look good. We can also add details in cpuinfo. If you are ok with proc entry then we don't even need this noise at all in the boot. It's just that adding proc entries is discouraged to some extent. Regards, Santosh -- 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: Patches merged to split OMAP2_IO_ADDRESS
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Friday, October 09, 2009 10:51 AM To: Tony Lindgren Cc: linux-omap@vger.kernel.org; Paul Walmsley Subject: RE: Patches merged to split OMAP2_IO_ADDRESS -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Thursday, October 08, 2009 11:38 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org; Paul Walmsley Subject: Re: Patches merged to split OMAP2_IO_ADDRESS * Shilimkar, Santosh santosh.shilim...@ti.com [091008 03:59]: Tony, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Thursday, October 08, 2009 5:55 AM To: linux-omap@vger.kernel.org Cc: Paul Walmsley Subject: Patches merged to split OMAP2_IO_ADDRESS Hi all, I've pushed Santosh' patches to split OMAP2_IO_ADDRESS into *_L3_IO_ADDRESS and *_L4_IO_ADDRESS so we can claim more kernel address space and support over 512MB of memory instead of 256MB. Of course, our goal is to convert everything except the .S files to use ioremap() instead, but that can now be done parallel and in smaller chunks. Please everybody, please convert your code to use ioremap(), there are static mappings already in place so it should work out of the box. I also had add two quick patches to keep things compiling, Paul can you take a look at them? I could not really test them as all the code is not there yet. Will post them as a reply to this thread. Thanks for the merge!! I have boot tested below platforms with latest LO master. 1. OMAP3430 SDP board - BOOT OK 2. OMAP3 BEAGLE - BOOT OK 3. OMAP 4430 SDP - BOOT OK with variation of patch: http://patchwork.kernel.org/patch/50531/ Great. I guess we still have some issues on 24xx with the hwmod, but hopefully we'll get that working again soon. Can somebody with 512MB memory on a board try the current l-o master and make sure things work? Please check the dmesg for no overlaps in virtual address space, then run some memory test like memtester. Boot tested on OMAP4430 with 512MB and dmesg don't show any overlaps. Will run some memory test tomorrow. Run the memmark benchmark on OMAP4430 and not seen any issue. Regards, Santosh -- 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/2] arm/omap3: a driver for on-chip ETM and ETB
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of virtu...@slind.org
Sent: Thursday, October 08, 2009 3:06 AM
To: linux-omap@vger.kernel.org
Cc: Alexander Shishkin
Subject: [PATCH 1/2] arm/omap3: a driver for on-chip ETM and ETB
From: Alexander Shishkin virtu...@slind.org
This driver implements /dev/tracebuf and some control files for ETM
and ETB in sysfs.
Looks like a very useful driver for tracing/debug.
Do you have some README link on the usage of this driver ?
Signed-off-by: Alexander Shishkin virtu...@slind.org
---
arch/arm/Kconfig.debug|8 +
arch/arm/include/asm/hardware/coresight.h | 164
arch/arm/kernel/Makefile |2 +
arch/arm/kernel/etm.c | 584
+
arch/arm/mach-omap2/Kconfig |7 +
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/emu.c | 70
7 files changed, 838 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/hardware/coresight.h
create mode 100644 arch/arm/kernel/etm.c
create mode 100644 arch/arm/mach-omap2/emu.c
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 1a6f70e..ac83c03 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -83,6 +83,14 @@ config DEBUG_ICEDCC
It does include a timeout to ensure that the system does not
totally freeze when there is nothing connected to read.
+config OC_ETM
+ tristate On-chip ETM and ETB
+ depends on ARCH_OMAP3
+ help
+ Enables the on-chip embedded trace macrocell and embedded trace
+ buffer driver that will allow you to collect traces of the
+ kernel code.
+
config DEBUG_DC21285_PORT
bool Kernel low-level debugging messages via footbridge serial
port
depends on DEBUG_LL FOOTBRIDGE
diff --git a/arch/arm/include/asm/hardware/coresight.h
b/arch/arm/include/asm/hardware/coresight.h
new file mode 100644
index 000..ba22df9
--- /dev/null
+++ b/arch/arm/include/asm/hardware/coresight.h
@@ -0,0 +1,164 @@
+/*
+ * linux/arch/arm/include/asm/hardware/coresight.h
+ *
+ * CoreSight components' registers
+ *
+ * Copyright (C) 2009 Nokia Corporation.
+ * Alexander Shishkin
+ *
+ * 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.
+ */
+
+#ifndef __ASM_HARDWARE_CORESIGHT_H
+#define __ASM_HARDWARE_CORESIGHT_H
+
+#define TRACER_ACCESSED_BIT 0
+#define TRACER_RUNNING_BIT 1
+#define TRACER_CYCLE_ACC_BIT 2
+#define TRACER_ACCESSED BIT(TRACER_ACCESSED_BIT)
+#define TRACER_RUNNING BIT(TRACER_RUNNING_BIT)
+#define TRACER_CYCLE_ACC BIT(TRACER_CYCLE_ACC_BIT)
+
+struct tracectx {
+ unsigned int etb_bufsz;
+ void __iomem *etb_regs;
+ void __iomem *etm_regs;
+ unsigned long flags;
+ int ncmppairs;
+ int etm_portsz;
+ struct device *dev;
+ struct mutex mutex;
+};
+
+#define TRACER_TIMEOUT 1
+
+#define etm_writel(t, v, x) \
+ (__raw_writel((v), (t)-etm_regs + (x)))
+#define etm_readl(t, x) (__raw_readl((t)-etm_regs + (x)))
+
+/* CoreSight Management Registers */
+#define CSMR_LOCKACCESS 0xfb0
+#define CSMR_LOCKSTATUS 0xfb4
+#define CSMR_AUTHSTATUS 0xfb8
+#define CSMR_DEVID 0xfc8
+#define CSMR_DEVTYPE 0xfcc
+/* CoreSight Component Registers */
+#define CSCR_CLASS 0xff4
+
+#define CSCR_PRSR0x314
+
+#define UNLOCK_MAGIC 0xc5acce55
+
+/* ETM control register, ETM Architecture, 3.3.1 */
+#define ETMR_CTRL0
+#define ETMCTRL_POWERDOWN1
+#define ETMCTRL_PROGRAM (1 10)
+#define ETMCTRL_PORTSEL (1 11)
+#define ETMCTRL_DO_CONTEXTID (3 14)
+#define ETMCTRL_PORTMASK1(7 4)
+#define ETMCTRL_PORTMASK2(1 21)
+#define ETMCTRL_PORTMASK (ETMCTRL_PORTMASK1 | ETMCTRL_PORTMASK2)
+#define ETMCTRL_PORTSIZE(x) x) 7) 4) | (!!((x) 8)) 21)
+#define ETMCTRL_DO_CPRT (1 1)
+#define ETMCTRL_DATAMASK (3 2)
+#define ETMCTRL_DATA_DO_DATA (1 2)
+#define ETMCTRL_DATA_DO_ADDR (1 3)
+#define ETMCTRL_DATA_DO_BOTH (ETMCTRL_DATA_DO_DATA |
ETMCTRL_DATA_DO_ADDR)
+#define ETMCTRL_BRANCH_OUTPUT(1 8)
+#define ETMCTRL_CYCLEACCURATE(1 12)
+
+/* ETM configuration code register */
+#define ETMR_CONFCODE(0x04)
+
+/* ETM trace start/stop resource control register */
+#define ETMR_TRACESSCTRL (0x18)
+
+/* ETM trigger event register */
+#define ETMR_TRIGEVT (0x08)
+
+/* address access type register bits, ETM architecture,
+ * table 3-27 */
+/* - access type */
+#define ETMAAT_IFETCH0
+#define ETMAAT_IEXEC 1
+#define ETMAAT_IEXECPASS 2
+#define ETMAAT_IEXECFAIL 3
+#define
RE: [RFC][PATCH] OMAP3: introduce OMAP3630
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Nishanth Menon Sent: Friday, October 09, 2009 7:40 PM Cc: Premi, Sanjeev; Pandita, Vikram; linux-omap; Chikkature Rajashekar, Madhusudhan; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Aguirre Rodriguez, Sergio Alberto; Tony Lindgren Subject: Re: [RFC][PATCH] OMAP3: introduce OMAP3630 Shilimkar, Santosh had written, on 10/08/2009 11:29 PM, the following: -Original Message- From: Menon, Nishanth Sent: Thursday, October 08, 2009 8:11 PM To: Premi, Sanjeev Cc: Pandita, Vikram; Shilimkar, Santosh; linux-omap; Chikkature Rajashekar, Madhusudhan; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Aguirre Rodriguez, Sergio Alberto; Tony Lindgren Subject: Re: [RFC][PATCH] OMAP3: introduce OMAP3630 [...] +#define OMAP3630_REV_ES1_00x34305034 #define OMAP443X_CLASS0x44300034 Was expecting that this patch will add cpu_is_omap36xx() in cpu.h apart from above. Is this handled in another patch ? Idea is to re-use all 34xx code for 36xx, as per the mail thread on list, and given in reference. Hence at run time, the check could be: if (omap_rev() == OMAP3630_REV_ES1_0) x cpu_is_omap34xx() will be true for 36xx as well. [sp] This case seems quite similar to the OMAP35x. Can you look at this thread: http://marc.info/?l=linux-omapm=125372581804902w=2 It applies equally well here as well... I will be submitting updated patch tomorrow. yes, any specifics should be feature based IMHO. we will need to extend the feature list. If we are going to handle the delta 3630 changes w.r.t 3430 with feature based approach, its probably is the best thing. yes. i guess I can take this as an ACK ;) But in case delat code will be added like below then having a cpu_is_omap36xx() makes more sense. if (omap_rev() == OMAP3630_REV_ES1_0) x There is no harm having both cpu_is_omap36xx() and cpu_is_omap34xx() true for 3630 what is the need for this? if feature settings can handle the deltas. give me specific example where this will be needed. if needed, we can add this at a later point. No need if you follow the feature based approach. But in case delta code will be added like ... So there was a IF condition :) Regards, Santosh -- 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] OMAP3: introduce OMAP3630
-Original Message-
From: Menon, Nishanth
Sent: Thursday, October 08, 2009 10:17 AM
To: linux-omap
Cc: Menon, Nishanth; Chikkature Rajashekar, Madhusudhan; Pandita, Vikram;
Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Premi,
Sanjeev; Shilimkar, Santosh; Aguirre Rodriguez, Sergio Alberto; Tony
Lindgren
Subject: [RFC][PATCH] OMAP3: introduce OMAP3630
Device intro:
OMAP3630 is the latest in the family of OMAP3 devices
and among the changes it introduces are:
New OPP levels for new voltage and frequency levels. a bunch of
Bug fixes to various modules feature additions, notably with ISP,
sDMA etc.
Details about the chip is available here:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=61
23navigationId=12836contentId=52606
Strategy used:
Strategy to introduce this device into Linux was discussed here:
Ref: http://marc.info/?t=12534330343r=1w=2
Two approaches were available:
a) Consider 3630 generation of devices as a new family of silicon
b) Consider 3630 as an offshoot of 3430 family of devices
As a common consensus, (b) seems to be more valid for 3630 as:
* There are changes which are easily handled by looking at rev
* Most of existing 34xx infrastructure can be reused(almost 90%+)
- so no ugly if (cpu_is_omap34xx() || cpu_is_omap36xx())
all over the place
- lesser chance of bugs due to reuse of proven code flow
- 36xx specific handling can still be done where required
within the existing infrastructure
NOTE:
* If additional 34xx series are added, OMAP3430_REV_ES can be
added on top of the existing 3630 ones are renumbered
This patch was tested on SDP3430.
Signed-off-by: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Cc: Allen Pais allen.p...@ti.com
Cc: Anand Gadiyar gadi...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/id.c | 33
++---
arch/arm/plat-omap/include/mach/cpu.h |6 ++
2 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 03b80f2..79193c6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -186,6 +186,7 @@ void __init omap3_check_revision(void)
{
u32 cpuid, idcode;
u16 hawkeye;
+ u16 omap_type;
u8 rev;
char *rev_name = ES1.0;
@@ -210,7 +211,10 @@ void __init omap3_check_revision(void)
hawkeye = (idcode 12) 0x;
rev = (idcode 28) 0xff;
- if (hawkeye == 0xb7ae) {
+ omap_type = omap_rev() 16;
+ switch (hawkeye) {
+ case 0xb7ae:
+ /* Handle 34xx devices */
switch (rev) {
case 0:
omap_revision = OMAP3430_REV_ES2_0;
@@ -231,12 +235,35 @@ void __init omap3_check_revision(void)
default:
/* Use the latest known revision as default */
omap_revision = OMAP3430_REV_ES3_1;
- rev_name = Unknown revision\n;
+ rev_name = Unknown 34xx revision\n;
+ /* Fall through */
}
+ break;
+ case 0xb891:
+ /* Handle 36xx devices */
+ /* Over ride for display purposes */
+ omap_type = 0x3630;
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP3630_REV_ES1_0;
+ rev_name = ES1.0;
+ break;
+ default:
+ /* Use the latest known revision as default */
+ omap_revision = OMAP3630_REV_ES1_0;
+ rev_name = Unknown 36xx revision\n;
+ /* Fall through */
+ }
+ break;
+ default:
+ /* Unknown default to latest rev as default*/
+ omap_revision = OMAP3630_REV_ES1_0;
+ rev_name = Unknown revision\n;
+ /* Fall through */
}
out:
- pr_info(OMAP%04x %s\n, omap_rev() 16, rev_name);
+ pr_info(OMAP%04x %s\n, omap_type, rev_name);
}
#define OMAP3_SHOW_FEATURE(feat) \
diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-
omap/include/mach/cpu.h
index 431fec4..af1080f 100644
--- a/arch/arm/plat-omap/include/mach/cpu.h
+++ b/arch/arm/plat-omap/include/mach/cpu.h
@@ -383,6 +383,12 @@ IS_OMAP_TYPE(3430, 0x3430)
#define OMAP3430_REV_ES2_1 0x34302034
#define OMAP3430_REV_ES3_0 0x34303034
#define OMAP3430_REV_ES3_1 0x34304034
+/* NOTE: Add 36xx series below
RE: Patches merged to split OMAP2_IO_ADDRESS
Tony, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Thursday, October 08, 2009 5:55 AM To: linux-omap@vger.kernel.org Cc: Paul Walmsley Subject: Patches merged to split OMAP2_IO_ADDRESS Hi all, I've pushed Santosh' patches to split OMAP2_IO_ADDRESS into *_L3_IO_ADDRESS and *_L4_IO_ADDRESS so we can claim more kernel address space and support over 512MB of memory instead of 256MB. Of course, our goal is to convert everything except the .S files to use ioremap() instead, but that can now be done parallel and in smaller chunks. Please everybody, please convert your code to use ioremap(), there are static mappings already in place so it should work out of the box. I also had add two quick patches to keep things compiling, Paul can you take a look at them? I could not really test them as all the code is not there yet. Will post them as a reply to this thread. Thanks for the merge!! I have boot tested below platforms with latest LO master. 1. OMAP3430 SDP board - BOOT OK 2. OMAP3 BEAGLE - BOOT OK 3. OMAP 4430 SDP - BOOT OK with variation of patch: http://patchwork.kernel.org/patch/50531/ Regards, Santosh -- 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] OMAP3: introduce OMAP3630
-Original Message- From: Menon, Nishanth Sent: Thursday, October 08, 2009 8:11 PM To: Premi, Sanjeev Cc: Pandita, Vikram; Shilimkar, Santosh; linux-omap; Chikkature Rajashekar, Madhusudhan; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Aguirre Rodriguez, Sergio Alberto; Tony Lindgren Subject: Re: [RFC][PATCH] OMAP3: introduce OMAP3630 Premi, Sanjeev had written, on 10/08/2009 09:23 AM, the following: -Original Message- From: Pandita, Vikram Sent: Thursday, October 08, 2009 7:01 PM To: Shilimkar, Santosh; Menon, Nishanth; linux-omap Cc: Chikkature Rajashekar, Madhusudhan; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Premi, Sanjeev; Aguirre Rodriguez, Sergio Alberto; Tony Lindgren Subject: RE: [RFC][PATCH] OMAP3: introduce OMAP3630 -Original Message- From: Shilimkar, Santosh diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- omap/include/mach/cpu.h index 431fec4..af1080f 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -383,6 +383,12 @@ IS_OMAP_TYPE(3430, 0x3430) #define OMAP3430_REV_ES2_1 0x34302034 #define OMAP3430_REV_ES3_0 0x34303034 #define OMAP3430_REV_ES3_1 0x34304034 +/* NOTE: Add 36xx series below + * If additional 34xx series are added, OMAP3430_REV_ES can be + * added above the 3630 defines and series renumbered to ensure + * rev() checks to work + */ +#define OMAP3630_REV_ES1_0 0x34305034 #define OMAP443X_CLASS 0x44300034 Was expecting that this patch will add cpu_is_omap36xx() in cpu.h apart from above. Is this handled in another patch ? Idea is to re-use all 34xx code for 36xx, as per the mail thread on list, and given in reference. Hence at run time, the check could be: if (omap_rev() == OMAP3630_REV_ES1_0) x cpu_is_omap34xx() will be true for 36xx as well. [sp] This case seems quite similar to the OMAP35x. Can you look at this thread: http://marc.info/?l=linux-omapm=125372581804902w=2 It applies equally well here as well... I will be submitting updated patch tomorrow. yes, any specifics should be feature based IMHO. we will need to extend the feature list. If we are going to handle the delta 3630 changes w.r.t 3430 with feature based approach, its probably is the best thing. But in case delat code will be added like below then having a cpu_is_omap36xx() makes more sense. if (omap_rev() == OMAP3630_REV_ES1_0) x There is no harm having both cpu_is_omap36xx() and cpu_is_omap34xx() true for 3630 Regards, Santosh -- 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: Patches merged to split OMAP2_IO_ADDRESS
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Thursday, October 08, 2009 11:38 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org; Paul Walmsley Subject: Re: Patches merged to split OMAP2_IO_ADDRESS * Shilimkar, Santosh santosh.shilim...@ti.com [091008 03:59]: Tony, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Thursday, October 08, 2009 5:55 AM To: linux-omap@vger.kernel.org Cc: Paul Walmsley Subject: Patches merged to split OMAP2_IO_ADDRESS Hi all, I've pushed Santosh' patches to split OMAP2_IO_ADDRESS into *_L3_IO_ADDRESS and *_L4_IO_ADDRESS so we can claim more kernel address space and support over 512MB of memory instead of 256MB. Of course, our goal is to convert everything except the .S files to use ioremap() instead, but that can now be done parallel and in smaller chunks. Please everybody, please convert your code to use ioremap(), there are static mappings already in place so it should work out of the box. I also had add two quick patches to keep things compiling, Paul can you take a look at them? I could not really test them as all the code is not there yet. Will post them as a reply to this thread. Thanks for the merge!! I have boot tested below platforms with latest LO master. 1. OMAP3430 SDP board - BOOT OK 2. OMAP3 BEAGLE - BOOT OK 3. OMAP 4430 SDP - BOOT OK with variation of patch: http://patchwork.kernel.org/patch/50531/ Great. I guess we still have some issues on 24xx with the hwmod, but hopefully we'll get that working again soon. Can somebody with 512MB memory on a board try the current l-o master and make sure things work? Please check the dmesg for no overlaps in virtual address space, then run some memory test like memtester. Boot tested on OMAP4430 with 512MB and dmesg don't show any overlaps. Will run some memory test tomorrow. Regrads Santosh -- 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: [alsa-devel] [PATCHv3 1/7] OMAP4: PMIC: Add support for twl6030 codec
(Looping Samuel) -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Mark Brown Sent: Tuesday, October 06, 2009 10:06 PM To: Peter Ujfalusi Cc: alsa-de...@alsa-project.org; Lopez Cruz, Misael; linux- o...@vger.kernel.org; Krishnamoorthy, Balaji T Subject: Re: [alsa-devel] [PATCHv3 1/7] OMAP4: PMIC: Add support for twl6030 codec On Tue, Oct 06, 2009 at 11:46:05AM +0300, Peter Ujfalusi wrote: How does the twl4030 series would fit with this modification? I have also added the twl4030 codec as a child for the twl MFD, but I have not finished the cleanup of the codec fully. The TWL6030 specific bits all look good but this change ought to go via the MFD tree (probably as part of the big patch series adding twl6030 support that doesn't look to have been applied yet). Are people happy that the interface to the twl6030 won't change as a result of the twl4030 audio support? If so then I'll apply the ASoC side now, the Kconfig dependencies will stop it being built too soon. Since there is some sort of dependency on ASOC series with TWL_6030 core series by Balaji, its better that these gets merged in correct order to avoid reworks. Below order should make the merge without many conflicts. 1. [PATCH v3 0/4] TWL patch series http://www.mail-archive.com/linux-omap@vger.kernel.org/msg17059.html 2. [PATCH v3 0/4] TWL6030 patch series http://www.mail-archive.com/linux-omap@vger.kernel.org/msg17130.html 3. [PATCHv3 0/7] TWL6030 audio codec initial support + Rework the Kconfig dependency. http://www.spinics.net/lists/alsa-devel/msg28134.html Samuel can take a call on this. Regards, Santosh -- 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: [alsa-devel] [PATCHv3 1/7] OMAP4: PMIC: Add support for twl6030 codec
-Original Message- From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] Sent: Wednesday, October 07, 2009 3:07 PM To: Shilimkar, Santosh Cc: Peter Ujfalusi; sa...@linux.intel.com; alsa-de...@alsa-project.org; Lopez Cruz, Misael; linux-omap@vger.kernel.org; Krishnamoorthy, Balaji T Subject: Re: [alsa-devel] [PATCHv3 1/7] OMAP4: PMIC: Add support for twl6030 codec On Wed, Oct 07, 2009 at 11:56:38AM +0530, Shilimkar, Santosh wrote: [I've reflowed your mail to fit into 80 columns] Since there is some sort of dependency on ASOC series with TWL_6030 core series by Balaji, its better that these gets merged in correct order to avoid reworks. There's no ordering problem with ASoC providing the TWL6030 core patches add the TWL6030_CORE symbol as the last thing in the merge. None of the ASoC drivers will be built until that symbol is defined so the absence of the core shouldn't matter. OK. Regards, Santosh -- 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: Question on OPP table handling
-Original Message-
From: Premi, Sanjeev
Sent: Tuesday, October 06, 2009 2:14 PM
To: Shilimkar, Santosh; Menon, Nishanth; linux-omap@vger.kernel.org
Cc: Kevin H
Subject: RE: Question on OPP table handling
-Original Message-
From: Shilimkar, Santosh
Sent: Tuesday, October 06, 2009 1:36 PM
To: Menon, Nishanth; linux-omap@vger.kernel.org
Cc: Premi, Sanjeev; Kevin H
Subject: RE: Question on OPP table handling
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Nishanth Menon
Sent: Monday, October 05, 2009 10:49 PM
To: linux-omap@vger.kernel.org
Cc: Premi, Sanjeev; Kevin H
Subject: Re: Question on OPP table handling
Kevin Hilman had written, on 10/05/2009 11:56 AM, the following:
Premi, Sanjeev pr...@ti.com writes:
-Original Message-
From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
Sent: Saturday, October 03, 2009 8:35 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Question on OPP table handling
Sanjeev Premi said the following on 10/01/2009 01:03 PM:
+struct omap_opp omap3_mpu_rate_table[] = {
+{0, 0, 0},
+/*OPP1*/
+{S125M, VDD1_OPP1, 0x1E},
+/*OPP2*/
+{S250M, VDD1_OPP2, 0x26},
+/*OPP3*/
+{S500M, VDD1_OPP3, 0x30},
+/*OPP4*/
+{S550M, VDD1_OPP4, 0x36},
+/*OPP5*/
+{S600M, VDD1_OPP5, 0x3C},
+};
For those involved,
if we wanted to convert omap3_mpu_table[] into
*omap3_mpu_table so that
we dynamically initialize it based on cpu type - what
would be the
recommendations?
Nishanth,
Good idea!
As a table, previous patch enables it (not as intent, but due to
syntax):
+/* struct omap_opp_table - View OPP table as an object
+ * @min: Minimum OPP id
+ * @max: Maximim OPP id
+ * @opps: Pointer to array defining the OPPs.
+ *
+ * An OPP table has varied length. Knowing minimum
and maximum
+ * OPP ids allow easy traversal.
+ */
+struct omap_opp_table {
+ u8 min;
+ u8 max;
+ struct omap_opp* opps;
+};
But now, I think it would be good to have an API that can fill an
opp_table:
int add_opp_definition(u8 id, u32 freq, u16 vsel);
...and, if an array is preferred, length can be set as:
int set_opp_table_length (u8 max);
I'm all for dynamic OPP setting, but not as an array. A
list should
probably be used.
Won't a list implementation cause more than necessary
overhead? I agree
that something like set_opp_table_length probably might be
redundant in
that case.
If I were to extend the discussion from other thread on
toggling the
valid OPPs
based on enable_off_mode, these could be handy.
int set_opp_valid(bool flag);
bool is_opp_valid(void);
Yes, we need a concept of a valid OPP, not just for OFF
mode, but for
OSWR and possibly for a full constraint framework as well.
Ack.
Even though above approach is possibly better a simple fix
could be just adding a flag in the structure (OPP
valid/invalid) and populating this flag run time using CPU type.
[sp] This is exactly in the original patch.
OK
Regards,
Santosh
--
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: Question on OPP table handling
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dasgupta, Romit Sent: Tuesday, October 06, 2009 5:51 PM To: Menon, Nishanth Cc: Premi, Sanjeev; Cousson, Benoit; Kevin H; linux-omap@vger.kernel.org Subject: RE: Question on OPP table handling Typo I meant Put all the OPP tables for different CPUs (instead ofOPPs) in __initdata. Copy the run time detected CPU's OPP table in memory. Others get discarded! This is a good idea. Or if we want to save the _Copy_ effort, then make all these opp table structures as 'const' so that it get moved to *.RO section. In that case all data is still available. -- 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] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
Shweta, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of y...@india.ti.com Sent: Monday, October 05, 2009 4:53 PM To: linux-omap@vger.kernel.org Cc: Gulati, Shweta Subject: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430 From: Shweta Gulati shweta.gul...@ti.com Please add change-log / description about this patch here. Signed-off-by: Shweta Gulati shweta.gul...@ti.com --- arch/arm/mach-omap2/pm34xx.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index a9eda25..38f4781 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -140,6 +140,12 @@ static void omap3_core_save_context(void) omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_OFF); control_padconf_off |= START_PADCONF_SAVE; omap_ctrl_writel(control_padconf_off, OMAP343X_CONTROL_PADCONF_OFF); + /* Due to Silicon Bug on context restore it is found + * that the CONTROL_PAD_CONF_ETK14 register is not saved into + * scratch pad memory sometimes. To rectify it delay acess by Mpu + * for 300us for scm to finish saving task + */ + udelay(300); /* wait for the save to complete */ while (!omap_ctrl_readl(OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS) PADCONF_SAVE_DONE) -- 1.5.4.7 -- 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 Regards, Santosh -- 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 v3 0/4] TWL6030 patch series
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, October 02, 2009 12:08 AM To: Krishnamoorthy, Balaji T Cc: linux-omap@vger.kernel.org; Shilimkar, Santosh; Nayak, Rajendra; a.zu...@towertech.it; p_gortma...@yahoo.com; sa...@linux.intel.com; t...@atomide.com Subject: Re: [PATCH v3 0/4] TWL6030 patch series Krishnamoorthy, Balaji T balaj...@ti.com writes: This patch series v3 incorporates comments received earlier[1]. The upcoming TWL6030 is companion chip for OMAP4 like the current TWL4030 for OMAP3. This patch series adds support for TWL6030 irq framework, and driver support for RTC and regulator. These patches has dependancy on TWL patch series[2] [PATCH v3 01/04] OMAP4: PMIC: Add support for twl6030 irq framework [PATCH v3 02/04] OMAP4: PMIC: Add support for twl6030 RTC [PATCH v3 03/04] OMAP4: PMIC: Add support for twl6030 regulators [PATCH v3 04/04] OMAP4: PMIC: Update TWL mfd driver to create twl6030 Regulators [1] http://marc.info/?l=linux-omapm=125050037530307w=2 [RFC][PATCH 0/4] TWL6030 patch series [2] http://marc.info/?l=linux-omapm=125439874001377w=2 [PATCH v3 0/4] TWL patch series In the future, please report what platforms this was tested on and whether it was just compile tested, boot tested or actually functionally tested. Yes. That information is necessary for such a change. These patches were boot tested on 3430SDP, 4430SDP. Also some additional driver testing is done for I2C and RTC. Regards, Santosh -- 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
[OMAP3] ALSA driver 'suspend/resume' handlers
Tony,
Can you check below patch? If it is OK, please add this to omap-fixes
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh
Sent: Wednesday, September 30, 2009 11:38 AM
To: Jarkko Nikula
Cc: hari n; Pandita, Vikram; linux-omap@vger.kernel.org
Subject: RE: [OMAP3] ALSA driver 'suspend/resume' handlers
-Original Message-
From: Jarkko Nikula [mailto:jhnik...@gmail.com]
Sent: Wednesday, September 30, 2009 11:10 AM
To: Shilimkar, Santosh
Cc: hari n; Pandita, Vikram; linux-omap@vger.kernel.org
Subject: Re: [OMAP3] ALSA driver 'suspend/resume' handlers
On Tue, 29 Sep 2009 21:28:45 +0530
Shilimkar, Santosh santosh.shilim...@ti.com wrote:
Having said that, there is also bug in the DMA driver which doesn't
disable the channel in linking cases. Since we use always hardware
synchronized method, hardware will take care of draining the buffer so
no
loss of data.
So option B should be ok and USB case also would work as mentioned
above.
Which option finally we converged on this issue? Shall we fix in the DMA
driver or you want to do this in ALSA?
For me it looks that at least the omap_stop_dma should be fixed to stop
ongoing transfer always when it's called. As the name suggest :-)
Agree !!
Have a look at below patch and let me know if it's ok.
From 6042ce380c36907b0740e208f243f00ca370d09e Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Wed, 30 Sep 2009 11:26:24 +0530
Subject: [PATCH] ARM: OMAP: SDMA: Stop channel in omap_stop_dma() API for
linking as well.
OMAP sDMA driver API omap_stop_dma() doesn't really stop the dma when used
in linking scenario. This patch fixes the same.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
CC: Hari n hari.z...@gmail.com
CC: Jarkko Nikula jhnik...@gmail.com
---
arch/arm/plat-omap/dma.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index fd3154a..633c123 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -975,6 +975,11 @@ void omap_stop_dma(int lch)
{
u32 l;
+ /* Disable the DMA channel */
+ l = dma_read(CCR(lch));
+ l = ~OMAP_DMA_CCR_EN;
+ dma_write(l, CCR(lch));
+
if (!omap_dma_in_1510_mode() dma_chan[lch].next_lch != -1) {
int next_lch, cur_lch = lch;
char dma_chan_link_map[OMAP_DMA4_LOGICAL_DMA_CH_COUNT];
@@ -1000,10 +1005,6 @@ void omap_stop_dma(int lch)
if (cpu_class_is_omap1())
dma_write(0, CICR(lch));
- l = dma_read(CCR(lch));
- l = ~OMAP_DMA_CCR_EN;
- dma_write(l, CCR(lch));
-
dma_chan[lch].flags = ~OMAP_DMA_ACTIVE;
}
EXPORT_SYMBOL(omap_stop_dma);
--
1.5.4.7
--
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 v3 01/04] ARM: OMAP: Rename twl4030* driver files to enable re-use
Mark, -Original Message- From: Krishnamoorthy, Balaji T Sent: Thursday, October 01, 2009 6:27 PM To: Mark Brown Cc: linux-omap@vger.kernel.org; sa...@linux.intel.com; w...@iguana.be; timo.t.kokko...@nokia.com; ben-li...@fluff.org; l...@slimlogic.co.uk; p_gortma...@yahoo.com; a.zu...@towertech.it; Shilimkar, Santosh; Nayak, Rajendra; Lopez Cruz, Misael Subject: RE: [PATCH v3 01/04] ARM: OMAP: Rename twl4030* driver files to enable re-use On Thu, Oct 01, 2009 at 05:46:49PM +0530, balaj...@ti.com wrote: The upcoming TWL6030 is companion chip for OMAP4 like the current TWL4030 for OMAP3. The common modules like RTC, Regulator creates opportunity to re-use the most of the code from twl4030. This patch renames few common drivers twl4030* files to twl* to enable the code re-use. sound/soc/codecs/twl4030.c |2 +- Nack on this part of the change. The TWL6030 audio architecture is noticably different to the TWL4030 audio architecture, most of the digital functionality has been moved into the OMAP and the I2S/DSP DAIs replaced by PDM links. Merging the two drivers was previously suggested in response to the TWL6030 CODEC driver postings but Misael Lopez Cruz (who is doing the driver) wasn't happy with the idea. I agree that TWL6030 codec will very different from TWL4030 codec and two separate drivers will exist for twl4030 and twl6030.c The patch which is posted now will make both codec to use the same i2c read /write api like twl_i2c_write_u8, twl_i2c_read_u8 ... This patch doesn't rename sound/soc/codecs/twl4030.c. The change is just correcting the header file. As discussed and agreed the TWL6030 codec can be a separate file from TWL4030 codec. Regards, Santosh -- 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 v3 01/04] OMAP4: PMIC: Add support for twl6030 irq framework
Amit, snip -Original Message- From: Amit Kucheria [mailto:amit.kuche...@verdurent.com] On Behalf Of Amit Kucheria Sent: Thursday, October 01, 2009 6:46 PM To: Krishnamoorthy, Balaji T Cc: linux-omap@vger.kernel.org; sa...@linux.intel.com; w...@iguana.be; timo.t.kokko...@nokia.com; ben-li...@fluff.org; l...@slimlogic.co.uk; broo...@opensource.wolfsonmicro.com; p_gortma...@yahoo.com; a.zu...@towertech.it; Nayak, Rajendra; Shilimkar, Santosh Subject: Re: [PATCH v3 01/04] OMAP4: PMIC: Add support for twl6030 irq framework + + status = request_irq(irq_num, handle_twl6030_pih, IRQF_DISABLED, + TWL6030-PIH, irq_event); There is no need for the kthread hack anymore now that threaded irqs are available to everyone (2.6.32-rc1) So above would become, status = request_threaded_irq(irq_num, handle_twl6030_pih, twl6030_irq_thread, IRQF_DISABLED, TWL6030-PIH, irq_event); where, handle_twl6030_pih is the hard irq handler that mask the interrupt twl6030_irq_thread is a sleeping call called by the irq framework You might also be able to do away with handle_twl6030_pih entirely and pass NULL. That along with a IRQF_ONESHOT flag the the request_threaded_irq routine should automatically mask the irq until the sleeping call returns. I am working on doing this to the twl4030 driver currently, if anybody else isn't. This is interesting and can improve the TWL framework. Keep us posted about your testing on TWL4030. Thanks !! Regards Santosh
RE: [OMAP3] ALSA driver 'suspend/resume' handlers
-Original Message-
From: Jarkko Nikula [mailto:jhnik...@gmail.com]
Sent: Wednesday, September 30, 2009 11:10 AM
To: Shilimkar, Santosh
Cc: hari n; Pandita, Vikram; linux-omap@vger.kernel.org
Subject: Re: [OMAP3] ALSA driver 'suspend/resume' handlers
On Tue, 29 Sep 2009 21:28:45 +0530
Shilimkar, Santosh santosh.shilim...@ti.com wrote:
Having said that, there is also bug in the DMA driver which doesn't
disable the channel in linking cases. Since we use always hardware
synchronized method, hardware will take care of draining the buffer so
no
loss of data.
So option B should be ok and USB case also would work as mentioned
above.
Which option finally we converged on this issue? Shall we fix in the DMA
driver or you want to do this in ALSA?
For me it looks that at least the omap_stop_dma should be fixed to stop
ongoing transfer always when it's called. As the name suggest :-)
Agree !!
Have a look at below patch and let me know if it's ok.
From 6042ce380c36907b0740e208f243f00ca370d09e Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Wed, 30 Sep 2009 11:26:24 +0530
Subject: [PATCH] ARM: OMAP: SDMA: Stop channel in omap_stop_dma() API for
linking as well.
OMAP sDMA driver API omap_stop_dma() doesn't really stop the dma when used
in linking scenario. This patch fixes the same.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
CC: Hari n hari.z...@gmail.com
CC: Jarkko Nikula jhnik...@gmail.com
---
arch/arm/plat-omap/dma.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index fd3154a..633c123 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -975,6 +975,11 @@ void omap_stop_dma(int lch)
{
u32 l;
+ /* Disable the DMA channel */
+ l = dma_read(CCR(lch));
+ l = ~OMAP_DMA_CCR_EN;
+ dma_write(l, CCR(lch));
+
if (!omap_dma_in_1510_mode() dma_chan[lch].next_lch != -1) {
int next_lch, cur_lch = lch;
char dma_chan_link_map[OMAP_DMA4_LOGICAL_DMA_CH_COUNT];
@@ -1000,10 +1005,6 @@ void omap_stop_dma(int lch)
if (cpu_class_is_omap1())
dma_write(0, CICR(lch));
- l = dma_read(CCR(lch));
- l = ~OMAP_DMA_CCR_EN;
- dma_write(l, CCR(lch));
-
dma_chan[lch].flags = ~OMAP_DMA_ACTIVE;
}
EXPORT_SYMBOL(omap_stop_dma);
--
1.5.4.7
--
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: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, September 30, 2009 11:25 PM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org
Subject: Re: linux-omap git tree updated to v2.6.32-rc1, important changes,
please read
Hi,
* Shilimkar, Santosh santosh.shilim...@ti.com [090929 03:54]:
snip
Thanks for fixing the OMAP4 compilation issues. We need below patch to
make the kernel boot on OMAP4430 on the latest LO master.
No problem. In the future, let's make sure the omap4 patches are merged
into l-o master branch for testing. This time the first three patches
in the omap-fixes branch were build breakage caused by the omap4 patches
directly or indirectly..
Agree!!
Also, please everybody check that your patches don't break the build
for other the omaps, and also boot test on some other omaps if someting
looks risky.
Few comments below.
From d9a22d9f7b68b99aa9607bdab377d998dfe82acd Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Tue, 29 Sep 2009 16:10:46 +0530
Subject: [PATCH] ARM: OMAP4: Allow omap_serial_early_init() for OMAP4430
board
This patch enables omap_serial_early_init() function for OMAP4430
SDP. Without this the bootup would throw opps in omap_serial_init().
The opps probably should be oops above :)
YEP :)
Additionally the patch removed the merge issue for the UART4.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |4 ++--
arch/arm/mach-omap2/io.c|2 ++
arch/arm/mach-omap2/serial.c| 10 --
3 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
omap2/board-4430sdp.c
index eb37c40..609a5a4 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -58,6 +58,8 @@ static void __init gic_init_irq(void)
static void __init omap_4430sdp_init_irq(void)
{
+ omap_board_config = sdp4430_config;
+ omap_board_config_size = ARRAY_SIZE(sdp4430_config);
omap2_init_common_hw(NULL, NULL);
#ifdef CONFIG_OMAP_32K_TIMER
omap2_gp_clockevent_set_gptimer(1);
@@ -70,8 +72,6 @@ static void __init omap_4430sdp_init_irq(void)
static void __init omap_4430sdp_init(void)
{
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
- omap_board_config = sdp4430_config;
- omap_board_config_size = ARRAY_SIZE(sdp4430_config);
omap_serial_init();
}
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index e3a3bad..56be87d 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -302,7 +302,9 @@ void __init omap2_init_common_hw(struct
omap_sdrc_params *sdrc_cs0,
pwrdm_init(powerdomains_omap);
clkdm_init(clockdomains_omap, clkdm_pwrdm_autodeps);
omap2_clk_init();
+#endif
omap_serial_early_init();
+#ifndef CONFIG_ARCH_OMAP4
omap_hwmod_late_init();
omap_pm_if_init();
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index ae21868..54dfeb5 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -109,16 +109,6 @@ static struct plat_serial8250_port
serial_platform_data2[] = {
.regshift = 2,
.uartclk= OMAP24XX_BASE_BAUD * 16,
}, {
-#ifdef CONFIG_ARCH_OMAP4
- .membase= OMAP2_IO_ADDRESS(OMAP_UART4_BASE),
- .mapbase= OMAP_UART4_BASE,
- .irq= 70,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk= OMAP24XX_BASE_BAUD * 16,
- }, {
-#endif
.flags = 0
}
};
Can't we fix the extra uart instead of removing it? We just added it!
It's still there in omap4, right?
This is already fixed. Above piece is not necessary since there is a separate
instance for UART4 (serial_platform_data3[])
Regards,
Santosh
--
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: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
Tony,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Tuesday, September 29, 2009 12:34 AM
To: linux-omap@vger.kernel.org
Subject: linux-omap git tree updated to v2.6.32-rc1, important changes,
please read
Hi all,
I've updated our linux-omap tree to v2.6.32-rc1. I've also
added a branch omap-2.6.31 for the old code.
This time I also nuked the remaining omap legacy code we
still had lurking around :) The commits at the end of this
mail describe what I did first as commits, then I merged
everything to be the same as the mainline v2.6.32-rc1.
So currently the linux-omap master branch is:
v2.6.32-rc1 + omap-fixes + ehci + cbus
The new model is that I'll be resetting the linux-omap master
branch to mainline at each -rc, then merge in our various
upstream queues back in again.
Please note that Remove omap extra version in Makefile
commit means that you now need to set the ARCH and CROSS_COMPILE
for your compiler.
The good news is that now you can pull in the linux-omap master
branch into any Linux kernel tree without messing up the other
architectures.
Also note that Remove DEBUG_LL hack to printk means that
in order to get DEBUG_LL working, you need to patch printk.c
yourself. You can find the patch in the omap-debug branch.
As always, if something important got thrown out, please
send patches against the mainline tree to patch back in
the missing functionality!
Thanks for fixing the OMAP4 compilation issues. We need below patch to make the
kernel boot on OMAP4430 on the latest LO master.
From d9a22d9f7b68b99aa9607bdab377d998dfe82acd Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Tue, 29 Sep 2009 16:10:46 +0530
Subject: [PATCH] ARM: OMAP4: Allow omap_serial_early_init() for OMAP4430 board
This patch enables omap_serial_early_init() function for OMAP4430
SDP. Without this the bootup would throw opps in omap_serial_init().
Additionally the patch removed the merge issue for the UART4.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |4 ++--
arch/arm/mach-omap2/io.c|2 ++
arch/arm/mach-omap2/serial.c| 10 --
3 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index eb37c40..609a5a4 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -58,6 +58,8 @@ static void __init gic_init_irq(void)
static void __init omap_4430sdp_init_irq(void)
{
+ omap_board_config = sdp4430_config;
+ omap_board_config_size = ARRAY_SIZE(sdp4430_config);
omap2_init_common_hw(NULL, NULL);
#ifdef CONFIG_OMAP_32K_TIMER
omap2_gp_clockevent_set_gptimer(1);
@@ -70,8 +72,6 @@ static void __init omap_4430sdp_init_irq(void)
static void __init omap_4430sdp_init(void)
{
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
- omap_board_config = sdp4430_config;
- omap_board_config_size = ARRAY_SIZE(sdp4430_config);
omap_serial_init();
}
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index e3a3bad..56be87d 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -302,7 +302,9 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
pwrdm_init(powerdomains_omap);
clkdm_init(clockdomains_omap, clkdm_pwrdm_autodeps);
omap2_clk_init();
+#endif
omap_serial_early_init();
+#ifndef CONFIG_ARCH_OMAP4
omap_hwmod_late_init();
omap_pm_if_init();
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index ae21868..54dfeb5 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -109,16 +109,6 @@ static struct plat_serial8250_port serial_platform_data2[]
= {
.regshift = 2,
.uartclk= OMAP24XX_BASE_BAUD * 16,
}, {
-#ifdef CONFIG_ARCH_OMAP4
- .membase= OMAP2_IO_ADDRESS(OMAP_UART4_BASE),
- .mapbase= OMAP_UART4_BASE,
- .irq= 70,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk= OMAP24XX_BASE_BAUD * 16,
- }, {
-#endif
.flags = 0
}
};
--
1.5.4.7
Regards,
Santosh
--
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: [OMAP3] ALSA driver 'suspend/resume' handlers
Hari, -Original Message- From: Shilimkar, Santosh Sent: Thursday, September 24, 2009 12:54 PM To: 'Jarkko Nikula'; hari n Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: RE: [OMAP3] ALSA driver 'suspend/resume' handlers Hari/Jarkko, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Jarkko Nikula Sent: Thursday, September 24, 2009 12:16 PM To: hari n Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: Re: [OMAP3] ALSA driver 'suspend/resume' handlers I don't see any problem if suspend and resume callbacks are added into omap-pcm.c and omap-mcbsp.c calling e.g. omap_mcbsp_config if needed. omap_stop_dma() should be issued when we really want to stop the DMA transfer and issuing this with an outstanding transfer is a BUG in ALSA driver. Having said that, there is also bug in the DMA driver which doesn't disable the channel in linking cases. Since we use always hardware synchronized method, hardware will take care of draining the buffer so no loss of data. So option B should be ok and USB case also would work as mentioned above. Which option finally we converged on this issue? Shall we fix in the DMA driver or you want to do this in ALSA? Regards, Santosh -- 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
OMAP4430 build broken on latest mainline/linux-omap head
Tony,
OMAP4430 board build is breaking on the latest mainline head because of couple
of issues.
1. The serial.c merge conflict issue below wasn't fixed correctly :(
Related link:
http://article.gmane.org/gmane.linux.ports.arm.omap/23341
2. Pauls below series breaks build as well.
[PATCH 00/13] OMAP PM, clock, and SDRC updates for the 2.6.32 merge window
Paul,
Can you fix the same please? I don't have the correct cm-regbits-4xxx.h file
to generate the patch.
***
CC arch/arm/mach-omap2/control.o
CC arch/arm/mach-omap2/mux.o
CC arch/arm/mach-omap2/devices.o
CC arch/arm/mach-omap2/serial.o
CC arch/arm/mach-omap2/gpmc.o
CC arch/arm/mach-omap2/timer-gp.o
CC arch/arm/mach-omap2/omap-smp.o
AS arch/arm/mach-omap2/omap-headsmp.o
CC arch/arm/mach-omap2/timer-mpu.o
CC arch/arm/mach-omap2/cm4xxx.o
arch/arm/mach-omap2/cm4xxx.c:25:29: error: cm-regbits-4xxx.h: No such file or
directory
arch/arm/mach-omap2/cm4xxx.c: In function 'omap4_cm_wait_idlest_ready':
arch/arm/mach-omap2/cm4xxx.c:61: error: implicit declaration of function
'omap4_cm_read_mod_reg'
arch/arm/mach-omap2/cm4xxx.c:62: error: 'OMAP4_CM_CLKCTRL_DREG' undeclared
(first use in this function)
arch/arm/mach-omap2/cm4xxx.c:62: error: (Each undeclared identifier is reported
only once
arch/arm/mach-omap2/cm4xxx.c:62: error: for each function it appears in.)
make[1]: *** [arch/arm/mach-omap2/cm4xxx.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
*
Tony,
Patch regarding one 1. is below.
From 3abd16f9b81dc55a2d894175d4a75f5a40c0fdd5 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Sat, 26 Sep 2009 13:07:39 +0530
Subject: [PATCH] ARM: OMAP4: Fix build break because of merge conflict
On the latest mainline head 2.6.31 (commit:6d7f18f6), OMAP4430 board
build is broken. This was mainly because of merge conflict which wasn't
resolved correctly.
The related patch and issue was discussed here.
http://article.gmane.org/gmane.linux.ports.arm.omap/23341
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/serial.c | 14 ++
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 3a529c7..54dfeb5 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -109,16 +109,6 @@ static struct plat_serial8250_port serial_platform_data2[]
= {
.regshift = 2,
.uartclk= OMAP24XX_BASE_BAUD * 16,
}, {
-#ifdef CONFIG_ARCH_OMAP4
- .membase= IO_ADDRESS(OMAP_UART4_BASE),
- .mapbase= OMAP_UART4_BASE,
- .irq= 70,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk= OMAP24XX_BASE_BAUD * 16,
- }, {
-#endif
.flags = 0
}
};
@@ -126,7 +116,7 @@ static struct plat_serial8250_port serial_platform_data2[]
= {
#ifdef CONFIG_ARCH_OMAP4
static struct plat_serial8250_port serial_platform_data3[] = {
{
- .membase= IO_ADDRESS(OMAP_UART4_BASE),
+ .membase= OMAP2_IO_ADDRESS(OMAP_UART4_BASE),
.mapbase= OMAP_UART4_BASE,
.irq= 70,
.flags = UPF_BOOT_AUTOCONF,
@@ -579,7 +569,7 @@ static struct omap_uart_state omap_uart[OMAP_MAX_NR_PORTS]
= {
{
.pdev = {
.name = serial8250,
- .id = 3
+ .id = 3,
.dev= {
.platform_data = serial_platform_data3,
},
--
1.5.4.7
Thanks !!
Regards,
Santosh
--
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: [PATCHv2 0/7] TWL6030 audio codec initial support
Misa, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Lopez Cruz, Misael Sent: Saturday, September 26, 2009 7:32 AM To: alsa-de...@alsa-project.org; linux-omap@vger.kernel.org Cc: Mark Brown Subject: [PATCHv2 0/7] TWL6030 audio codec initial support Following patch series adds initial support for TWL6030 codec driver. TWL6030 codec depends on TWL6030_CORE, which is not accepted yet. The main intention then is to get comments, I'll repost the patches of this series when TWL6030_CORE support gets accepted and rework patches as needed. Looking at your series, you have based your patches on Balaji's 6030 PMIC series as you mentioned TWL6030 codec depends on TWL6030_CORE. While doing that series, we realized that there is a lot of code common between TWL5030 and TWL6030 apart from mainly interrupt handling and hence a common file approach is taken to avoid code duplication. The patch [PATCHv2 3/7] ASoC: TWL6030: Add twl6030 codec driver gives me an impression that there is opportunity to have a single file supporting both IC's. IC specific code can be handled using the runtime check depending on the revision. Can you explore this ? You can find more information on above discussion at below thread. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg15756.html From Changes from v1: - Renamed dai format for PDM as SND_SOC_DAIFMT_PDM - CODEC driver registered as a platform driver - AUDPWRON gpio line handled in the CODEC driver - Handle scenario when no AUDPWRON gpio line is provided - Corrected names of some widgets - Avoid multiple calls to power functions in set_bias_level Thanks, -Misa --- Misael Lopez Cruz (7): OMAP4: PMIC: Add support for twl6030 codec ASoC: Add PDM DAI format definition ASoC: TWL6030: Add twl6030 codec driver ASoC: TWL6030: Manual power-up/down sequences ASoC: TWL6030: Add support for low-power mode ASoC: TWL6030: Enable audio interrupt ASoC: TWL6030: Power-up seq completion through audio interrupt drivers/mfd/twl-core.c | 15 + include/linux/i2c/twl.h| 11 + include/sound/soc-dai.h|1 + sound/soc/codecs/Kconfig |4 + sound/soc/codecs/Makefile |2 + sound/soc/codecs/twl6030.c | 1179 sound/soc/codecs/twl6030.h | 137 + 7 files changed, 1349 insertions(+), 0 deletions(-) create mode 100644 sound/soc/codecs/twl6030.c create mode 100644 sound/soc/codecs/twl6030.h -- 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 Regards, Santosh -- 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: [OMAP3] ALSA driver 'suspend/resume' handlers
Hari/Jarkko, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Jarkko Nikula Sent: Thursday, September 24, 2009 12:16 PM To: hari n Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: Re: [OMAP3] ALSA driver 'suspend/resume' handlers On Wed, 23 Sep 2009 00:02:01 -0500 hari n hari.z...@gmail.com wrote: It appears OMAP ALSA driver does not seem to disable and idle the SDMA channel on a 'suspend' call. The problem seems to be with the 'omap_stop_dma()' call under 'SNDRV_PCM_TRIGGER_SUSPEND' in 'omap_pcm_trigger()'. ALSA audio driver uses self linking and the function 'omap_stop_dma()', only unlinks the channels, but DOES NOT disable an active channel for linked channels. Good finding, definitely I was expecting that it will stop the transfer. I worder what's the background for current omap_stop_dma implementation? I would expect that omap_stop_dma would just stop the logical channel without touching the channel linking etc. as there is own API for chained transfers and thus omap_stop_dma could be used for non-chained transfers or 'hacking' with chained transfers. This means after a return from the 'omap_stop_dma()', there can still be an active DMA transaction on the channel. Is this the intent Or a bug? I can think of situations, where in, we may want to complete the DMA transfer and then disable the channel. In such a case, we need to wait until the channel is inactive. I don't know, probably there is no driver expecting that transfer will complete after the omap_stop_dma is called or they explicitly do some PIO based FIFO flush for their devices? The problem with the current implementation is that after the audio platform trigger (suspend) is called, SOC core calls the CPU DAI trigger (suspend) and this stops the McBSP. Depending on the current DMA pointer, this may leave the DMA channel in active state, since DMA is configured for DEST HW Synchronization and and the this never gets asserted after the McBSP is stopped.. This is true. Then the question is will the operation recover after the stream is resumed and after the low-level dma and mcbsp contexts are restored and operation started again. I see two ways to resolve this issue: a) Wait after the 'omap_stop_dma()' in audio platform trigger(suspend) until the DMA channel is inactive (i.e buffer transfer complete). But, i believe 'trigger' is supposed to be an atomic operation, so we may need to wait in a worker thread. And we need to flag the McBSP stop based on DMA transfer completion. b) Explicitly disable the DMA channel in 'omap_stop_dma(). Option 'b' above may mean losing some data on resume, if we hit 'OFF' state during suspend. This may not be a big deal for audio (loss of few secs audio), but for other drivers (ex: USB data file transfer?), this may not be acceptable. 'Option 'a' means more rework in audio driver, but no changes in DAM driver and no loss of data. Yeah, trigger callback is atomic and can be called from the interrupt context as well. Option 'a' doesn't help losing of audio samples since the soc-core is first muting the codec. Current Audio driver also does not seem to support 'OFF' mode during suspend. It seems to assume that all DMA and McBSP configurations are retained in a suspend to resume transition. It's true, this has not got so much attention. I think I was expecting that low-level mcbsp and dma modules will take care of their context back-up and restore and that's enough for audio as long as audio will inform those modules with _start/_stop calls. I don't see any problem if suspend and resume callbacks are added into omap-pcm.c and omap-mcbsp.c calling e.g. omap_mcbsp_config if needed. omap_stop_dma() should be issued when we really want to stop the DMA transfer and issuing this with an outstanding transfer is a BUG in ALSA driver. Having said that, there is also bug in the DMA driver which doesn't disable the channel in linking cases. Since we use always hardware synchronized method, hardware will take care of draining the buffer so no loss of data. So option B should be ok and USB case also would work as mentioned above. Regrads Santosh -- 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][RFC] OMAP3630: Create architecture macros and config entries.
Allen, depends on ARCH_OMAP3 ARCH_OMAP34XX +config MACH_OMAP_3630SDP + bool OMAP 3630 SDP board + depends on ARCH_OMAP3 ARCH_OMAP34XX ARCH_OMAP36XX + config MACH_NOKIA_N8X0 bool Nokia N800/N810 depends on ARCH_OMAP2420 diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- omap/include/mach/cpu.h index 7a5f9e8..73c656c 100755 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -157,10 +157,12 @@ IS_OMAP_CLASS(15xx, 0x15) IS_OMAP_CLASS(16xx, 0x16) IS_OMAP_CLASS(24xx, 0x24) IS_OMAP_CLASS(34xx, 0x34) +IS_OMAP_CLASS(36xx, 0x36) ### OMAP3630 is just an OMAP3430 in disguise. I don't think it deserves a new class. It should probably be handled like it was done for 1610 and 1710. Theoretically, it should be considered as a 3430 ES4.0, because it is an OMAP3430 ES3 + couple of bug fixes + couple of improvements. I think, that the proposal from Sanjeev to support 35xx (http://marc.info/?l=linux-omapm=125050987112798w=2 ) might be leveraged to handle 36xx as well. ### I too second Benoit point here. A single runtime macro like cpu_is_omap36xx() should be good enough to add additional code for 3630. May be we can keep all 3430 switches by default enabled for 3630 and wherever necessary additional 3630 specific code can be added using the runtime switch like cpu_is_omap36xx(). Regards, Santosh -- 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/2] OMAP1/2/3/4: DEBUG_LL run time detection
Vikram,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Pandita, Vikram
Sent: Saturday, September 19, 2009 6:10 AM
To: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org
Cc: Pandita, Vikram; Russell King; Kevin Hilman
Subject: [PATCH 1/2] OMAP1/2/3/4: DEBUG_LL run time detection
+u32 get_uart_base(void)
+{
+ static u32 omap_uart_debug_ll_phy_addr;
+
+ if (omap_uart_debug_ll_phy_addr)
+ return omap_uart_debug_ll_phy_addr;
+
+ /* Add logic here for new platforms, using __machine_arch_type */
+
+ /* TODO: REVISIT -- Check Completeness
+ * DEFINE PHY ADDRESS for EACH BOARD HERE: omap1/2/3/4 */
+#if defined(CONFIG_ARCH_OMAP1)
+ switch (__machine_arch_type) {
+ case MACH_TYPE_OMAP_PALMTT:
+ case MACH_TYPE_SX1:
+ /* UART2 */
+ omap_uart_debug_ll_phy_addr = (u32 *)0xfffb0800;
+ break;
+ default:
+ /* UART1 */
+ omap_uart_debug_ll_phy_addr = (u32 *)0xfffb;
+ break;
+ }
+#endif
+
+#if defined(CONFIG_ARCH_OMAP2)
+ switch (__machine_arch_type) {
+ case MACH_TYPE_NOKIA_N800:
+ case MACH_TYPE_NOKIA_N810:
+ case MACH_TYPE_NOKIA_N810_WIMAX:
+ /* UART3 */
+ omap_uart_debug_ll_phy_addr = (u32 *)0x4806e000;
+ break;
+ default:
+ /* UART1 */
+ omap_uart_debug_ll_phy_addr = (u32 *)0x4806a000;
+ break;
+ }
+#endif
+
+#if defined(CONFIG_ARCH_OMAP3)
+ switch (__machine_arch_type) {
+ case MACH_TYPE_OMAP_LDP:
+ case MACH_TYPE_OVERO:
+ case MACH_TYPE_OMAP3_PANDORA:
+ case MACH_TYPE_NOKIA_RX51:
+ case MACH_TYPE_OMAP3_BEAGLE:
+ /* UART3 */
+ omap_uart_debug_ll_phy_addr = 0x4902;
+ break;
+ case MACH_TYPE_OMAP_ZOOM2:
+ /* EXTERNEL UART */
+ omap_uart_debug_ll_phy_addr = 0x1000;
+ break;
+ default:
+ /* UART1 */
+ omap_uart_debug_ll_phy_addr = 0x4806a000;
+ break;
+ }
+#endif
+
+#ifdef CONFIG_ARCH_OMAP4
+ switch (__machine_arch_type) {
+ /* OMAP3: UART1 */
+ case MACH_TYPE_OMAP_4430SDP:
+ default:
+ omap_uart_debug_ll_phy_addr = (u32 *)0x4806a000;
+ break;
+ }
+#endif
+
+ return omap_uart_debug_ll_phy_addr;
+}
This makes only UART1 as a DEBUG_LL option for OMAP4. Will we not have options
any more to select rest of the UARTs for DEBUG_LL as it was supported with
previous Russell's implementation?
Regards,
Santosh
--
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: 3430SDP: Crash on first UART keypress after boot
Anand, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Gadiyar, Anand Sent: Friday, September 11, 2009 2:55 PM To: Gadiyar, Anand; linux-omap@vger.kernel.org Subject: RE: 3430SDP: Crash on first UART keypress after boot Current linux-omap kernel boots up fine on 3430 SDP after adding Sergio's patch [1], but then I get the following crash on the first UART keypress. This is new, it used to work okay a little while ago. Regards, Anand The crash still exists with current linux-omap kernel. Disabling CONFIG_FB_OMAP makes the issue go away. (Only disabled this one option - see diff between .config.old and .config below) I don't see this issue on my SDP even with OMAP_FB enabled. May be we have different ES versions -- 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] ARM: OMAP2/3/4: Reclaim the kernel IO address space
Tony, What about this series? Shall I post this on ARM mailing list if you have already reviewed this. Thanks !! -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, August 28, 2009 5:32 PM To: Shilimkar, Santosh Cc: Tony Lindgren; linux-omap@vger.kernel.org Subject: Re: [PATCH 0/5] ARM: OMAP2/3/4: Reclaim the kernel IO address space Shilimkar, Santosh santosh.shilim...@ti.com writes: This patch series is intended to free up the kernel IO address space for OMAP2XXX, OMAP3XXX and OMAP4430. It is generated against Tony's omap-headers (2.6.31-rc6) branch and boot tested on OMAP3430 SDP and OMAP4430 platform. Some more combinations are possible but to make it uniform across OMAP2, OMAP3 and OMAP4, these io combinations are chosen. If needed documentation entry can be created to ease up reading and debugging information. Like Documentation/arm/omap/io_map.txt Yes, this would be very helpful. Otherwise, this series looks OK with me. Acked-by: Kevin Hilman khil...@deeprootsystems.com Summary of changes: The following changes since commit 95e32bc5b2d95370fb67a108a0e3678381fc42df: Tony Lindgren (1): OMAP: Remove ifdefs for io.h Santosh Shilimkar (5): ARM: OMAP2/3/4: Split OMAP2_IO_ADDRESS to L3 and L4 ARM: OMAP2/3/4: Remap L3, L4 to get more kernel io address space ARM: OMAP2/3/4: Move SRAM map to claim more io space ARM: OMAP2/3/4: Fix DEBUG_LL UART io address ARM: OMAP2/3/4: Add OMAP4 L3 and L4 peripherals. arch/arm/mach-omap2/board-2430sdp.c |2 +- arch/arm/mach-omap2/board-3430sdp.c |2 +- arch/arm/mach-omap2/board-4430sdp.c |6 +- arch/arm/mach-omap2/board-apollon.c |2 +- arch/arm/mach-omap2/board-generic.c |2 +- arch/arm/mach-omap2/board-h4.c|2 +- arch/arm/mach-omap2/board-ldp.c |2 +- arch/arm/mach-omap2/board-omap3beagle.c |2 +- arch/arm/mach-omap2/board-omap3evm.c |2 +- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-overo.c |2 +- arch/arm/mach-omap2/board-rx51.c |2 +- arch/arm/mach-omap2/board-zoom2.c |2 +- arch/arm/mach-omap2/cm.h |6 +- arch/arm/mach-omap2/io.c | 18 arch/arm/mach-omap2/irq.c |4 +- arch/arm/mach-omap2/omap-smp.c|2 +- arch/arm/mach-omap2/pm-debug.c|3 +- arch/arm/mach-omap2/prm.h |6 +- arch/arm/mach-omap2/sdrc.h|9 +- arch/arm/mach-omap2/serial.c |6 +- arch/arm/mach-omap2/sram242x.S|4 +- arch/arm/mach-omap2/sram243x.S|4 +- arch/arm/mach-omap2/timer-gp.c|2 +- arch/arm/plat-omap/common.c | 44 +- arch/arm/plat-omap/dma.c |6 +- arch/arm/plat-omap/dmtimer.c |2 +- arch/arm/plat-omap/gpio.c | 42 arch/arm/plat-omap/include/mach/control.h | 15 ++- arch/arm/plat-omap/include/mach/debug-macro.S |4 +- arch/arm/plat-omap/include/mach/entry-macro.S |4 +- arch/arm/plat-omap/include/mach/io.h | 124 +- --- arch/arm/plat-omap/include/mach/omap44xx.h| 14 ++- arch/arm/plat-omap/include/mach/sdrc.h|6 +- arch/arm/plat-omap/include/mach/vmalloc.h |2 +- arch/arm/plat-omap/io.c | 20 +++- arch/arm/plat-omap/sram.c | 24 +++--- drivers/video/omap/dispc.c|6 +- 38 files changed, 246 insertions(+), 161 deletions(-) Regards, Santosh -- 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 6/10] omap mailbox: remove unnecessary arg for omap_mbox_msg_send
Subbu, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of C.A, Subramaniam Sent: Monday, September 07, 2009 9:03 PM To: Russell King Cc: linux-omap@vger.kernel.org; t...@atomide.com; hiroshi.d...@nokia.com; Kanigeri, Hari; Gupta, Ramesh Subject: RE: [PATCH 6/10] omap mailbox: remove unnecessary arg for omap_mbox_msg_send Hi Russell, 'arg' is used later in Patch 10, as part of the tasklet implementation, for writing messages to the mailbox. Should I be removing it in patch 6 and introduce it only for the tasklet implementation? Avoid top posting !! -- 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][RFC] OMAP4: sDMA driver: descriptor autoloading feature
Venkat,
Few comments other wise patch looks fine to me.
-Original Message-
From: S, Venkatraman
Sent: Thursday, August 27, 2009 4:42 PM
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; Shilimkar, Santosh
Subject: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor autoloading
feature
(Updated version of previous patch: http://marc.info/?l=linux-
omapm=125012097403050w=2)
Add sDMA driver support for descriptor autoloading feature.
Descriptor autoloading is OMAP4 sDMA hardware capability that can be
exploited for scatter gather scenarios.
The feature works as described below
1) A sDMA channel is programmed to be in 'linked list' mode
2) The client (sDMA user) provides a list of descriptors in a linked list
format
3) Each of the 'descriptor' (element in the linked list) contains an
updated set of DMA configuration register values
4) Client starts DMA transfer
5) sDMA controller loads the first element to its register configuration
memory and executes the transfer
6) After completion, loads the next element (in linked list) to
configuration memory and executes the transfer, without MCU intervention.
7) Interrupt is generated after all transfers are completed; this can be
configured to be done differently.
Configurations and additional features
1) Fast mode non-fast mode
Fast mode/non-fast decides on how the first transfer begins. In
non-fast mode, the first element in the linked list is loaded only after
completing the transfer according to the configurations already in the
sDMA channel registers. In fast mode, the loading of the first element
precedes the transfer.
2) Pause / resume of transfers
A transfer can be paused after a descriptor set has been loaded,
provided the 'pause bit' is set in the linked list element.
An ongoing transfer cannot be paused. If the 'pause bit' is set, transfer
is not started after loading the register set from memory.
Such a transfer can be resumed later.
Would it be good if we move this description just above those APIs. Even though
this information is good to be here but later once merged, this would go in
commit history.
Somebody reading code also would benefit from this info. I leave that decision
to you.
3) Descriptor types
3 possible configurations of descriptors (initialized as linked
list elements) are possible. Type 1 provides the maximum flexibility,
which contains most register definitions of a DMA logical channel. Fewer
options are present in type 2. Type 3 can just modify source/destinations
address of transfers. In all transfers, unmodified registers settings are
maintained for the next transfer.
This information too should be in source code somewhere.
Patch provides options / API for
1) Setting up a descriptor loading for DMA channel for sg type transfers
2) configuration with linked list elements
3) Starting / pause and resume of the said transfers, query state
4) Closing/Releasing the DMA channel
The patches are generated against kernel 2.6.31-rc1, tested on OMAP4
simulator platform.
Summary:
OMAP sDMA driver changes for descriptor autoloading feature.
Signed-off-by: Venkatraman S svenk...@ti.com
---
arch/arm/plat-omap/dma.c | 303
+
arch/arm/plat-omap/include/mach/dma.h | 98 +++
2 files changed, 401 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 7677a4a..3a75272 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -29,6 +29,7 @@
#include linux/interrupt.h
#include linux/irq.h
#include linux/io.h
+#include linux/dma-mapping.h
#include asm/system.h
#include mach/hardware.h
@@ -46,13 +47,42 @@ enum { DMA_CH_ALLOC_DONE, DMA_CH_PARAMS_SET_DONE,
DMA_CH_STARTED,
enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
#endif
+/* CDP Register bitmaps */
+#define DMA_LIST_CDP_DST_VALID (BIT(0))
+#define DMA_LIST_CDP_SRC_VALID (BIT(2))
+#define DMA_LIST_CDP_TYPE1 (BIT(4))
+#define DMA_LIST_CDP_TYPE2 (BIT(5))
+#define DMA_LIST_CDP_TYPE3 (BIT(4) | BIT(5))
+#define DMA_LIST_CDP_PAUSEMODE (BIT(7))
+#define DMA_LIST_CDP_LISTMODE(BIT(8))
+#define DMA_LIST_CDP_FASTMODE(BIT(10))
+/* CAPS register bitmaps */
+#define DMA_CAPS_SGLIST_SUPPORT (BIT(20))
+
+#define DMA_LIST_DESC_PAUSE (BIT(0))
+#define DMA_LIST_DESC_SRC_VALID (BIT(24))
+#define DMA_LIST_DESC_DST_VALID (BIT(26))
+#define DMA_LIST_DESC_BLK_END(BIT(28))
+
#define OMAP_DMA_ACTIVE 0x01
#define OMAP_DMA_CCR_EN (1 7)
#define OMAP2_DMA_CSR_CLEAR_MASK 0xffe
#define OMAP_FUNC_MUX_ARM_BASE (0xfffe1000 + 0xec)
+#define OMAP_DMA_INVALID_FRAME_COUNT (0x)
+#define OMAP_DMA_INVALID_ELEM_COUNT (0xff)
+#define OMAP_DMA_INVALID_DESCRIPTOR_POINTER (0xfffc)
static int enable_1510_mode;
+static int
RE: [PATCH 0/5] ARM: OMAP2/3/4: Reclaim the kernel IO address space
Tony, Kevin, Did you happen to go through this series? -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Sunday, August 23, 2009 7:00 PM To: Tony Lindgren; Kevin Hilman Cc: linux-omap@vger.kernel.org Subject: [PATCH 0/5] ARM: OMAP2/3/4: Reclaim the kernel IO address space All, This patch series is intended to free up the kernel IO address space for OMAP2XXX, OMAP3XXX and OMAP4430. It is generated against Tony's omap-headers (2.6.31-rc6) branch and boot tested on OMAP3430 SDP and OMAP4430 platform. Some more combinations are possible but to make it uniform across OMAP2, OMAP3 and OMAP4, these io combinations are chosen. If needed documentation entry can be created to ease up reading and debugging information. Like Documentation/arm/omap/io_map.txt Summary of changes: The following changes since commit 95e32bc5b2d95370fb67a108a0e3678381fc42df: Tony Lindgren (1): OMAP: Remove ifdefs for io.h Santosh Shilimkar (5): ARM: OMAP2/3/4: Split OMAP2_IO_ADDRESS to L3 and L4 ARM: OMAP2/3/4: Remap L3, L4 to get more kernel io address space ARM: OMAP2/3/4: Move SRAM map to claim more io space ARM: OMAP2/3/4: Fix DEBUG_LL UART io address ARM: OMAP2/3/4: Add OMAP4 L3 and L4 peripherals. arch/arm/mach-omap2/board-2430sdp.c |2 +- arch/arm/mach-omap2/board-3430sdp.c |2 +- arch/arm/mach-omap2/board-4430sdp.c |6 +- arch/arm/mach-omap2/board-apollon.c |2 +- arch/arm/mach-omap2/board-generic.c |2 +- arch/arm/mach-omap2/board-h4.c|2 +- arch/arm/mach-omap2/board-ldp.c |2 +- arch/arm/mach-omap2/board-omap3beagle.c |2 +- arch/arm/mach-omap2/board-omap3evm.c |2 +- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-overo.c |2 +- arch/arm/mach-omap2/board-rx51.c |2 +- arch/arm/mach-omap2/board-zoom2.c |2 +- arch/arm/mach-omap2/cm.h |6 +- arch/arm/mach-omap2/io.c | 18 arch/arm/mach-omap2/irq.c |4 +- arch/arm/mach-omap2/omap-smp.c|2 +- arch/arm/mach-omap2/pm-debug.c|3 +- arch/arm/mach-omap2/prm.h |6 +- arch/arm/mach-omap2/sdrc.h|9 +- arch/arm/mach-omap2/serial.c |6 +- arch/arm/mach-omap2/sram242x.S|4 +- arch/arm/mach-omap2/sram243x.S|4 +- arch/arm/mach-omap2/timer-gp.c|2 +- arch/arm/plat-omap/common.c | 44 +- arch/arm/plat-omap/dma.c |6 +- arch/arm/plat-omap/dmtimer.c |2 +- arch/arm/plat-omap/gpio.c | 42 arch/arm/plat-omap/include/mach/control.h | 15 ++- arch/arm/plat-omap/include/mach/debug-macro.S |4 +- arch/arm/plat-omap/include/mach/entry-macro.S |4 +- arch/arm/plat-omap/include/mach/io.h | 124 +--- - arch/arm/plat-omap/include/mach/omap44xx.h| 14 ++- arch/arm/plat-omap/include/mach/sdrc.h|6 +- arch/arm/plat-omap/include/mach/vmalloc.h |2 +- arch/arm/plat-omap/io.c | 20 +++- arch/arm/plat-omap/sram.c | 24 +++--- drivers/video/omap/dispc.c|6 +- 38 files changed, 246 insertions(+), 161 deletions(-) Regards, Santosh -- 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 0/5] ARM: OMAP2/3/4: Reclaim the kernel IO address space
Thanks Kevin for review!! -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, August 28, 2009 5:32 PM To: Shilimkar, Santosh Cc: Tony Lindgren; linux-omap@vger.kernel.org Subject: Re: [PATCH 0/5] ARM: OMAP2/3/4: Reclaim the kernel IO address space Shilimkar, Santosh santosh.shilim...@ti.com writes: This patch series is intended to free up the kernel IO address space for OMAP2XXX, OMAP3XXX and OMAP4430. It is generated against Tony's omap-headers (2.6.31-rc6) branch and boot tested on OMAP3430 SDP and OMAP4430 platform. Some more combinations are possible but to make it uniform across OMAP2, OMAP3 and OMAP4, these io combinations are chosen. If needed documentation entry can be created to ease up reading and debugging information. Like Documentation/arm/omap/io_map.txt Yes, this would be very helpful. Otherwise, this series looks OK with me. Acked-by: Kevin Hilman khil...@deeprootsystems.com Will create the doc entry. Regards, Santosh -- 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/5] ARM: OMAP2/3/4: Split OMAP2_IO_ADDRESS to L3 and L4
-Original Message- From: V, Hemanth Sent: Monday, August 24, 2009 11:40 AM To: Shilimkar, Santosh; Pandita, Vikram; t...@atomide.com; khil...@deeprootsystems.com Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 1/5] ARM: OMAP2/3/4: Split OMAP2_IO_ADDRESS to L3 and L4 - Original Message - From: Shilimkar, Santosh santosh.shilim...@ti.com --- #define L3_IO_OFFSET 0x9000 #define __L3_IO_ADDRESS(pa) ((pa) + L3_IO_OFFSET)/* Works for L3 */ #define __OMAP2_L3_IO_ADDRESS(pa) ((pa) + L3_IO_OFFSET)/* Works for L3 */ #define l3_io_v2p(va) ((va) - L3_IO_OFFSET)/* Works for L3 */ #define IO_OFFSET 0xb200 #define __IO_ADDRESS(pa) ((pa) + IO_OFFSET)/* Works for L4 */ #define __OMAP2_IO_ADDRESS(pa) ((pa) + IO_OFFSET)/* Works for L4 */ #define io_v2p(va) ((va) - IO_OFFSET)/* Works for L4*/ --- This way you don't have to introduce new L4 macro at all = much lesser code impact. Initially I thought about this but later preferred to split it. The only change what you are suggesting is instead of calling OMAP2_L4_IO_ADDRESS, we keep that as OMAP2_IO_ADDRESS. But the idea was to differentiate between various IO accesses because at some point of time all these has to be removed in favor of ioremap() + read*()/write*() one by one and that time this would be beneficial. Does that mean all drivers, including the ones in other trees like camera, dss etc need to be modified if they are using IO_ADDRESS macros. The idea of having a macro as below was to reduce this impact. Going forward yes. Refer the mailing thread comments from Tony/Kevin/Richard on below thread. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg14015.html Regards, Santosh -- 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/2 v2] ARM: OMAP4: Fix NULL pointer dereference crash.
static inline unsigned int serial_read_reg(struct plat_serial8250_port
*up,
int offset)
{
@@ -550,6 +564,17 @@ static struct omap_uart_state
omap_uart[OMAP_MAX_NR_PORTS] = {
},
},
},
+#ifdef CONFIG_ARCH_OMAP4
+ {
+ .pdev = {
+ .name = serial8250,
+ .id = PLAT8250_DEV_FOURPORT,
This should not be FOURPORT, it should just be a number. In this case,
it should be 3 (the others start from zero.)
Santosh,
I've changed the .id field to '3' and will queue up this fix for the
next merge window along with my fixes queue[1]. Please let me know if you
want to do otherwise.
This is fine Kevin. Thanks !!
Bye the way I have also posted v3 version in which I changed the .id field to 3.
Regards,
Santosh
--
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/2] ARM: OMAP4: Fix NULL pointer dereference crash.
Kevin,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, August 24, 2009 7:41 PM
To: Shilimkar, Santosh
Cc: r...@arm.linux.org.uk; khil...@deeprootsystems.com; linux-arm-
ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org; Syed, Rafiuddin
Subject: Re: [PATCH 1/2] ARM: OMAP4: Fix NULL pointer dereference crash.
* Santosh Shilimkar santosh.shilim...@ti.com [090821 12:15]:
After the patch series [PATCH 00/14] OMAP PM fixes for .31-rc
merge in 2.6.31-rc5, the kernel crashed during boot on OMAP4430.
This patch fixes it by adding UART4 support and related code.
Without this patch omap_serial_init() would produce NULL pointer
dereference and kernel crashes in the bootup on OMAP4430 platform.
Some more info on the merge issue can be found here.
More info- http://lkml.org/lkml/2009/8/20/192
Note: While merging this patch,IO_ADDRESS needs to be changed
to OMAP2_IO_ADDRESS if the Tony's below series is already merged in.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg15072.html
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c |2 +-
arch/arm/mach-omap2/serial.c| 27 ++-
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
omap2/board-4430sdp.c
index b0c7402..1b22307 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -39,7 +39,7 @@ static struct platform_device *sdp4430_devices[]
__initdata = {
};
static struct omap_uart_config sdp4430_uart_config __initdata = {
- .enabled_uarts = (1 0) | (1 1) | (1 2),
+ .enabled_uarts = (1 0) | (1 1) | (1 2) | (1 3),
};
This part above won't be needed any longer with patches in omap for next.
Will you fix this in your branch or shall I post v4.
Regards
Santosh
--
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/2] ARM: OMAP4: Fix NULL pointer dereference crash.
Regards, Santosh This part above won't be needed any longer with patches in omap for next. Will you fix this in your branch or shall I post v4. Santosh, I'll fix this. Kevin Thanks Kevin!! Regards Santosh -- 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/5] ARM: OMAP2/3/4: Reclaim the kernel IO address space
All, This patch series is intended to free up the kernel IO address space for OMAP2XXX, OMAP3XXX and OMAP4430. It is generated against Tony's omap-headers (2.6.31-rc6) branch and boot tested on OMAP3430 SDP and OMAP4430 platform. Some more combinations are possible but to make it uniform across OMAP2, OMAP3 and OMAP4, these io combinations are chosen. If needed documentation entry can be created to ease up reading and debugging information. Like Documentation/arm/omap/io_map.txt Summary of changes: The following changes since commit 95e32bc5b2d95370fb67a108a0e3678381fc42df: Tony Lindgren (1): OMAP: Remove ifdefs for io.h Santosh Shilimkar (5): ARM: OMAP2/3/4: Split OMAP2_IO_ADDRESS to L3 and L4 ARM: OMAP2/3/4: Remap L3, L4 to get more kernel io address space ARM: OMAP2/3/4: Move SRAM map to claim more io space ARM: OMAP2/3/4: Fix DEBUG_LL UART io address ARM: OMAP2/3/4: Add OMAP4 L3 and L4 peripherals. arch/arm/mach-omap2/board-2430sdp.c |2 +- arch/arm/mach-omap2/board-3430sdp.c |2 +- arch/arm/mach-omap2/board-4430sdp.c |6 +- arch/arm/mach-omap2/board-apollon.c |2 +- arch/arm/mach-omap2/board-generic.c |2 +- arch/arm/mach-omap2/board-h4.c|2 +- arch/arm/mach-omap2/board-ldp.c |2 +- arch/arm/mach-omap2/board-omap3beagle.c |2 +- arch/arm/mach-omap2/board-omap3evm.c |2 +- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-overo.c |2 +- arch/arm/mach-omap2/board-rx51.c |2 +- arch/arm/mach-omap2/board-zoom2.c |2 +- arch/arm/mach-omap2/cm.h |6 +- arch/arm/mach-omap2/io.c | 18 arch/arm/mach-omap2/irq.c |4 +- arch/arm/mach-omap2/omap-smp.c|2 +- arch/arm/mach-omap2/pm-debug.c|3 +- arch/arm/mach-omap2/prm.h |6 +- arch/arm/mach-omap2/sdrc.h|9 +- arch/arm/mach-omap2/serial.c |6 +- arch/arm/mach-omap2/sram242x.S|4 +- arch/arm/mach-omap2/sram243x.S|4 +- arch/arm/mach-omap2/timer-gp.c|2 +- arch/arm/plat-omap/common.c | 44 +- arch/arm/plat-omap/dma.c |6 +- arch/arm/plat-omap/dmtimer.c |2 +- arch/arm/plat-omap/gpio.c | 42 arch/arm/plat-omap/include/mach/control.h | 15 ++- arch/arm/plat-omap/include/mach/debug-macro.S |4 +- arch/arm/plat-omap/include/mach/entry-macro.S |4 +- arch/arm/plat-omap/include/mach/io.h | 124 + arch/arm/plat-omap/include/mach/omap44xx.h| 14 ++- arch/arm/plat-omap/include/mach/sdrc.h|6 +- arch/arm/plat-omap/include/mach/vmalloc.h |2 +- arch/arm/plat-omap/io.c | 20 +++- arch/arm/plat-omap/sram.c | 24 +++--- drivers/video/omap/dispc.c|6 +- 38 files changed, 246 insertions(+), 161 deletions(-) Regards, Santosh -- 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/5] ARM: OMAP2/3/4: Split OMAP2_IO_ADDRESS to L3 and L4
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Sunday, August 23, 2009 8:35 AM To: t...@atomide.com; khil...@deeprootsystems.com Cc: linux-omap@vger.kernel.org; Shilimkar, Santosh Subject: [PATCH 1/5] ARM: OMAP2/3/4: Split OMAP2_IO_ADDRESS to L3 and L4 That sure is a big cleanup patch and would take patience to complete!! This patch splits OMAP2_IO_ADDRESS to OMAP2_L3_IO_ADDRESS and OMAP2_L4_IO_ADDRESS to reclaim more IO space. There is no reclaim of space with this patch. Its done with [2/5] Yes comment is valid. I wanted to put - This patch splits OMAP2_IO_ADDRESS to OMAP2_L3_IO_ADDRESS and OMAP2_L4_IO_ADDRESS to enable freeing up of more IO space. This patch only changes the macro definitions but the offsets are still the same as in old code. So the description needs to be more explicit as to why you introduced L3/L4 macro split. Another suggestion to minimize the so intrusive code change: As per the wiki approach: [1] Lot of code will remain un-touched if you re-used the existing IO_OFFSET macro as follows --- --- #define L3_IO_OFFSET 0x9000 #define __L3_IO_ADDRESS(pa) ((pa) + L3_IO_OFFSET)/* Works for L3 */ #define __OMAP2_L3_IO_ADDRESS(pa) ((pa) + L3_IO_OFFSET)/* Works for L3 */ #define l3_io_v2p(va) ((va) - L3_IO_OFFSET)/* Works for L3 */ #define IO_OFFSET 0xb200 #define __IO_ADDRESS(pa) ((pa) + IO_OFFSET)/* Works for L4 */ #define __OMAP2_IO_ADDRESS(pa)((pa) + IO_OFFSET)/* Works for L4 */ #define io_v2p(va)((va) - IO_OFFSET)/* Works for L4*/ --- This way you don't have to introduce new L4 macro at all = much lesser code impact. Initially I thought about this but later preferred to split it. The only change what you are suggesting is instead of calling OMAP2_L4_IO_ADDRESS, we keep that as OMAP2_IO_ADDRESS. But the idea was to differentiate between various IO accesses because at some point of time all these has to be removed in favor of ioremap() + read*()/write*() one by one and that time this would be beneficial. -- 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/5] OMAP1/2/3/4: DEBUG_LL: cleanup
Vikram, Thanks for this clean-up series !! Couple of comments. snip snip -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Pandita, Vikram Sent: Friday, August 21, 2009 11:25 PM To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.arm.linux.org.uk Cc: Pandita, Vikram Subject: [PATCH 1/5] OMAP1/2/3/4: DEBUG_LL: cleanup of arch/arm/plat-omap/include/mach/debug- macro.S Signed-off-by: Vikram Pandita vikram.pand...@ti.com --- arch/arm/plat-omap/Kconfig| 50 ++-- - arch/arm/plat-omap/include/mach/common.h |7 +++ arch/arm/plat-omap/include/mach/debug-macro.S | 40 arch/arm/plat-omap/include/mach/uncompress.h | 12 + 4 files changed, 54 insertions(+), 55 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index ab9f9ef..2fefb64 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -162,21 +162,43 @@ config OMAP_DM_TIMER help Select this option if you want to use OMAP Dual-Mode timers. + Specify the Physical address of Low level debug UART + Specify 0x0 in case you do not want DEBUG_LL functions to iterfere with your board uarts + + OMAP1: + --- + UART1 - 0xfffb (default) + UART2 - 0xfffb0800 + UART3 - 0xfffb9800 (sx1, palmtt) + + OMAP2: + --- + UART1 - 0x4806a000 (default) + UART2 - 0x4806c000 + UART3 - 0x4806e000 (N8X0) + + OMAP3/4: + --- + UART1 - 0x4806a000 (default: except following) + UART2 - 0x4806c000 + UART3 - 0x4902 (rx51, beagle, pendora, ldp, overo) OMAP4 UART3 base address is 0x4802 + UART4 - 0x4806e000 + UART_EXT - 0x1000 (zoom2: Debug uart is on external debug board) - -#elif defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4) - moveq \rx, #0x4800@ physical base address - movne \rx, #0xd800@ virtual base - orr \rx, \rx, #0x0006a000 -#ifdef CONFIG_OMAP_LL_DEBUG_UART2 - add \rx, \rx, #0x2000 @ UART 2 -#endif -#ifdef CONFIG_OMAP_LL_DEBUG_UART3 - add \rx, \rx, #0x00fb @ UART 3 This was already wrong for OMAP4 - add \rx, \rx, #0x6000 -#endif + /* omap1 */ + ldr \rx, =CONFIG_OMAP_DEBUG_LL_UART_PHY_ADDR @ physical base address + subne \rx, #CONFIG_OMAP_DEBUG_LL_UART_PHY_ADDR, #OMAP1_IO_OFFSET @ virtual base +#else + /* omap2/omap3/omap4 */ + ldr \rx, =CONFIG_OMAP_DEBUG_LL_UART_PHY_ADDR @ physical base address + orrne \rx, \rx, #OMAP2_IO_OFFSET @ virtual base #endif .endm diff --git a/arch/arm/plat-omap/include/mach/uncompress.h b/arch/arm/plat- omap/include/mach/uncompress.h index 0814c5f..0e21eb3 100644 --- a/arch/arm/plat-omap/include/mach/uncompress.h +++ b/arch/arm/plat-omap/include/mach/uncompress.h @@ -38,14 +38,8 @@ static void putc(int c) return; #endif -#ifdef CONFIG_ARCH_OMAP -#ifdef CONFIG_OMAP_LL_DEBUG_UART3 - uart = (volatile u8 *)(OMAP_UART3_BASE); -#elif defined(CONFIG_OMAP_LL_DEBUG_UART2) - uart = (volatile u8 *)(OMAP_UART2_BASE); -#else - uart = (volatile u8 *)(OMAP_UART1_BASE); -#endif +#if defined(CONFIG_DEBUG_LL) + uart = (volatile u8 *)(CONFIG_OMAP_DEBUG_LL_UART_PHY_ADDR); #ifdef CONFIG_ARCH_OMAP1 /* Determine which serial port to use */ @@ -62,7 +56,6 @@ static void putc(int c) return; } while (0); #endif /* CONFIG_ARCH_OMAP1 */ -#endif Regards, Santosh -- 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/2] ARM: OMAP4: Boot up crash 2.6.31-rc6
Thanks Kevin!! -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, August 21, 2009 9:30 PM To: Shilimkar, Santosh Cc: Russell King; Tony Lindgren; linux-omap@vger.kernel.org; linux-arm- ker...@lists.arm.linux.org.uk Subject: Re: [PATCH 0/2] ARM: OMAP4: Boot up crash 2.6.31-rc6 Shilimkar, Santosh santosh.shilim...@ti.com writes: Russell, On the mainline 2.6.31-rc6, OMAP4 boot is crashing. Also serial code in the linux-next branch isn't merge correctly and needs reworked patches. Can you please see if they are ok? After the fix I suggested on patch 2/2, I'm OK with these. Tony, should I pull these into my fixes queue, or do you want to merge them directly. We will need them in your for-next branch to resolve the problems in linux-next. I will submit new version with you comment. -- 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/2] ARM: OMAP4: Boot up crash 2.6.31-rc6
Russell, On the mainline 2.6.31-rc6, OMAP4 boot is crashing. Also serial code in the linux-next branch isn't merge correctly and needs reworked patches. Can you please see if they are ok? This patch series addresses the OMAP4430 boot up crash issues on the latest 2.6.31-rc6 kernel release. They are generated against 2.6.31-rc6 (commit= 6c30c53fd5ae6a99a23ad78e90c428d2c8ffb07f) OMAP4 was broken after [PATCH 00/14] OMAP PM fixes for .31-rc series series got merged in. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg14527.html Two issues - 1. NULL pointer dereference in omap_serial_init()- static struct omap_uart_state omap_uart[OMAP_MAX_NR_PORTS], has three instances populated and for OMAP4 macro OMAP_MAX_NR_PORTS=4. So at the fourth iteration, there is NULL pointer oops. This was also related to the merge issue in the linux-next branch. http://lkml.org/lkml/2009/8/20/192 [PATCH 1/2] ARM: OMAP4: Fix NULL pointer dereference crash. 2. Console is not working because the uart platform data is not getting registered to kernel. Registration fails because of clock check failure in omap_serial_init(). As you aware the clock framework is still under review on mailing list. Hence below patch is necessary to fix the same. [PATCH 2/2] ARM: OMAP4: Bypass the clock check. Thanks !! Regards, Santosh -- 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: linux-next: manual merge of the omap tree with the arm tree
Today's linux-next merge of the omap tree got a conflict in
arch/arm/mach-omap2/board-4430sdp.c between commit
085b54d99b8ee999e7905b8f16e201e0da8ba369 (ARM: OMAP4: Add UART4
support) from the arm tree and commit
4c29fa3e47342666e12e46f35f40dd90b12cd1a4 (OMAP: remove OMAP_TAG_UART)
from the omap tree.
Just context changes (I think). I fixed it up (see below) and can carry
the fix as necessary.
Thanks yeh the fix looks right. I'll take a look if I can squeeze
something
like that into my queue so the merge conflict disappears.
There is another issue with the same merge I noticed which not seems to be
correct.
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commit;h=a11128de5baf523cf73176170659902fe1335527
Code snippet
102 static struct plat_serial8250_port serial_platform_data2[] = {
103 {
104 .membase= OMAP2_IO_ADDRESS(OMAP_UART3_BASE),
105 .mapbase= OMAP_UART3_BASE,
106 .irq= 74,
107 .flags = UPF_BOOT_AUTOCONF,
108 .iotype = UPIO_MEM,
109 .regshift = 2,
110 .uartclk= OMAP24XX_BASE_BAUD * 16,
111 }, {
112 #ifdef CONFIG_ARCH_OMAP4
113 .membase= IO_ADDRESS(OMAP_UART4_BASE),
114 .mapbase= OMAP_UART4_BASE,
115 .irq= 70,
116 .flags = UPF_BOOT_AUTOCONF,
117 .iotype = UPIO_MEM,
118 .regshift = 2,
119 .uartclk= OMAP24XX_BASE_BAUD * 16,
120 }, {
121 #endif
122 .flags = 0
123 }
124 };
This patch (ARM: OMAP4: Add UART4) was generated when there was single
structure holding all three UARTs and fourth UART was added accordingly. And
now it's been merged with serial.c which has UART's structures separated
already.
Below patch fixes the same but don't know what is the way to get merged in such
cases.
Tony,
Could you please review it?
From c8be9f1b5d4fe1dce06b6f33be33fe57f376ea7f Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Thu, 20 Aug 2009 18:33:43 +0530
Subject: [PATCH] OMAP4: UART4 : Reworked patch to fix merge conflicts.
This patch adds UART4 support on OMAP4430 development platform.
The serial omap-patches has split the UART platform
data into separate structure hence needs rework.
Without this patch omap_serial_init() would produce kernel crash
on OMAP4430 platform while looping for the 4 th UART platform
data.
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |2 +-
arch/arm/mach-omap2/serial.c| 27 ++-
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index b0c7402..1b22307 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -39,7 +39,7 @@ static struct platform_device *sdp4430_devices[] __initdata =
{
};
static struct omap_uart_config sdp4430_uart_config __initdata = {
- .enabled_uarts = (1 0) | (1 1) | (1 2),
+ .enabled_uarts = (1 0) | (1 1) | (1 2) | (1 3),
};
static struct omap_lcd_config sdp4430_lcd_config __initdata = {
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index a7421a5..b96cac4 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -112,7 +112,21 @@ static struct plat_serial8250_port serial_platform_data2[]
= {
.flags = 0
}
};
-
+#ifdef CONFIG_ARCH_OMAP4
+static struct plat_serial8250_port serial_platform_data3[] = {
+ {
+ .membase= IO_ADDRESS(OMAP_UART4_BASE),
+ .mapbase= OMAP_UART3_BASE,
+ .irq= 70,
+ .flags = UPF_BOOT_AUTOCONF,
+ .iotype = UPIO_MEM,
+ .regshift = 2,
+ .uartclk= OMAP24XX_BASE_BAUD * 16,
+ }, {
+ .flags = 0
+ }
+};
+#endif
static inline unsigned int serial_read_reg(struct plat_serial8250_port *up,
int offset)
{
@@ -550,6 +564,17 @@ static struct omap_uart_state omap_uart[OMAP_MAX_NR_PORTS]
= {
},
},
},
+#ifdef CONFIG_ARCH_OMAP4
+ {
+ .pdev = {
+ .name = serial8250,
+ .id = PLAT8250_DEV_PLATFORM2,
+ .dev= {
+ .platform_data = serial_platform_data2,
+ },
+ },
+ },
+#endif
};
void __init omap_serial_init(void)
--
RE: linux-next: manual merge of the omap tree with the arm tree
(Resending with a correction)
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh
Sent: Thursday, August 20, 2009 6:33 PM
To: Tony Lindgren; Stephen Rothwell
Cc: linux-omap@vger.kernel.org; linux-n...@vger.kernel.org; linux-
ker...@vger.kernel.org; Syed, Rafiuddin; Russell King; Kalle Valo
Subject: RE: linux-next: manual merge of the omap tree with the arm tree
Today's linux-next merge of the omap tree got a conflict in
arch/arm/mach-omap2/board-4430sdp.c between commit
085b54d99b8ee999e7905b8f16e201e0da8ba369 (ARM: OMAP4: Add UART4
support) from the arm tree and commit
4c29fa3e47342666e12e46f35f40dd90b12cd1a4 (OMAP: remove
OMAP_TAG_UART)
from the omap tree.
Just context changes (I think). I fixed it up (see below) and can
carry
the fix as necessary.
Thanks yeh the fix looks right. I'll take a look if I can squeeze
something
like that into my queue so the merge conflict disappears.
There is another issue with the same merge I noticed which not seems to be
correct.
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-
next.git;a=commit;h=a11128de5baf523cf73176170659902fe1335527
Code snippet
102 static struct plat_serial8250_port serial_platform_data2[] = {
103 {
104 .membase= OMAP2_IO_ADDRESS(OMAP_UART3_BASE),
105 .mapbase= OMAP_UART3_BASE,
106 .irq= 74,
107 .flags = UPF_BOOT_AUTOCONF,
108 .iotype = UPIO_MEM,
109 .regshift = 2,
110 .uartclk= OMAP24XX_BASE_BAUD * 16,
111 }, {
112 #ifdef CONFIG_ARCH_OMAP4
113 .membase= IO_ADDRESS(OMAP_UART4_BASE),
114 .mapbase= OMAP_UART4_BASE,
115 .irq= 70,
116 .flags = UPF_BOOT_AUTOCONF,
117 .iotype = UPIO_MEM,
118 .regshift = 2,
119 .uartclk= OMAP24XX_BASE_BAUD * 16,
120 }, {
121 #endif
122 .flags = 0
123 }
124 };
This patch (ARM: OMAP4: Add UART4) was generated when there was single
structure holding all three UARTs and fourth UART was added accordingly.
And now it's been merged with serial.c which has UART's structures
separated already.
Below patch fixes the same but don't know what is the way to get merged in
such cases.
Tony,
Could you please review it?
From c8be9f1b5d4fe1dce06b6f33be33fe57f376ea7f Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Thu, 20 Aug 2009 18:33:43 +0530
Subject: [PATCH] OMAP4: UART4 : Reworked patch to fix merge conflicts.
This patch adds UART4 support on OMAP4430 development platform.
The serial omap patches has split the UART platform
data into separate structure hence needs rework.
Without this patch omap_serial_init() would produce kernel crash
on OMAP4430 platform while looping for the 4 th UART platform
data.
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |2 +-
arch/arm/mach-omap2/serial.c| 27 ++-
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index b0c7402..1b22307 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -39,7 +39,7 @@ static struct platform_device *sdp4430_devices[] __initdata =
{
};
static struct omap_uart_config sdp4430_uart_config __initdata = {
- .enabled_uarts = (1 0) | (1 1) | (1 2),
+ .enabled_uarts = (1 0) | (1 1) | (1 2) | (1 3),
};
static struct omap_lcd_config sdp4430_lcd_config __initdata = {
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index a7421a5..b96cac4 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -112,7 +112,21 @@ static struct plat_serial8250_port serial_platform_data2[]
= {
.flags = 0
}
};
-
+#ifdef CONFIG_ARCH_OMAP4
+static struct plat_serial8250_port serial_platform_data3[] = {
+ {
+ .membase= IO_ADDRESS(OMAP_UART4_BASE),
+ .mapbase= OMAP_UART4_BASE,
+ .irq= 70,
+ .flags = UPF_BOOT_AUTOCONF,
+ .iotype = UPIO_MEM,
+ .regshift = 2,
+ .uartclk= OMAP24XX_BASE_BAUD * 16,
+ }, {
+ .flags = 0
+ }
+};
+#endif
static inline unsigned int serial_read_reg(struct plat_serial8250_port *up,
int offset)
{
@@ -550,6 +564,17 @@ static struct omap_uart_state omap_uart
[PATCH 0/2] ARM: OMAP4: Boot up crash 2.6.31-rc6
Kevin/Tony, This patch series addresses the OMAP4430 boot up crash issues on the latest 2.6.31-rc6 kernel release. On the latest mainline as well as linux-omap master (2.6.31-rc6), OMAP4 boot is crashing. This has broken after [PATCH 00/14] OMAP PM fixes for .31-rc series series got merged in. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg14527.html Two issues - 1. NULL pointer dereference in omap_serial_init()- static struct omap_uart_state omap_uart[OMAP_MAX_NR_PORTS], has three instances populated and for OMAP4 macro OMAP_MAX_NR_PORTS=4. So at the fourth iteration, there is NULL pointer oops. This was also related to the merge issue in the linux-next branch. http://lkml.org/lkml/2009/8/20/192 [PATCH 1/2] ARM: OMAP4: Fix NULL pointer dereference crash. 2. Console is not working because the uart platform data is not getting registered to kernel. Registration fails because of clock check failure in omap_serial_init(). As you aware the clock framework is still under review on mailing list. Hence below patch is necessary to fix the same. [PATCH 2/2] ARM: OMAP4: Bypass the clock check. Please review the same. Thanks!! Regards, Santosh -- 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: SDP support seems broken in LO
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of vimal singh Sent: Tuesday, August 18, 2009 5:49 PM To: linux-omap@vger.kernel.org Subject: SDP support seems broken in LO LO seems broken on OMAP3430 SDP platform. I compile latest kernel with 'omap_3430sdp_defconfig' config options. Booting hangs after kernel uncompressed and last message which appears is 'booting the kernel' Thanks and regards, vimal See below log: ## Booting image at 8000 ... Image Name: Linux-2.6.31-rc5-omap1-05896-ge0 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2520992 Bytes = 2.4 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux. .. .. done, booting the kernel. Mainly because of frame-buffer and musb. You can try disabling these two and see if it boots. Regards, Santosh -- 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/6] ARM: OMAP4: PM: PRM/CM module offsets for OMAP4
Paul, I'd also like to see the full names of the PRCM submodules, e.g., OMAP4430_CM2_RESTORE_CM2_MOD rather than just OMAP4430_CM2_RESTORE_MOD Not sure what you mean by __full__ name here. You are adding a redundant CM2 in the name here. Regards, Santosh -- 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 v2 4/4] OMAP4: PMIC: Update TWL mfd driver to create twl6030 regulators
-Original Message- From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] Sent: Thursday, August 06, 2009 3:10 AM To: Shilimkar, Santosh Cc: Premi, Sanjeev; Tony Lindgren; Krishnamoorthy, Balaji T; linux-omap@vger.kernel.org; khil...@deeprootsystems.com; davi...@pacbell.net; linux-...@vger.kernel.org; sa...@openedhand.com; w...@iguana.be; timo.t.kokko...@nokia.com; ben-li...@fluff.org; l...@slimlogic.co.uk; Nayak, Rajendra Subject: Re: [RFC][PATCH v2 4/4] OMAP4: PMIC: Update TWL mfd driver to create twl6030 regulators On Tue, Aug 04, 2009 at 07:28:22PM +0530, Shilimkar, Santosh wrote: Do you have boards / use cases where more than one PM IC would be used _and_ it will use the same driver ? I don't personally but it's certainly something that I would consider realistic (if not mainstream). So what you suggest here. Regards, Santosh -- 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 v1 1/3] ARM:OMAP4 iommu:changes in iommu for OMAP4
Russell / Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, August 05, 2009 12:50 PM
To: Russell King - ARM Linux
Cc: Kanigeri, Hari; linux-omap@vger.kernel.org; Hiroshi DOYU;
Shilimkar, Santosh
Subject: Re: [PATCH v1 1/3] ARM:OMAP4 iommu:changes in iommu for OMAP4
* Russell King - ARM Linux li...@arm.linux.org.uk [090805 01:45]:
On Tue, Aug 04, 2009 at 05:30:23PM -0500, Kanigeri, Hari wrote:
- obj-clk = clk_get(pdev-dev, pdata-clk_name);
- if (IS_ERR(obj-clk))
- goto err_clk;
+ /*
+ * FIX-ME: Replace with correct clk node when clk
+ * framework is available
+ */
+ if (!cpu_is_omap44xx()) {
+ obj-clk = clk_get(pdev-dev, pdata-clk_name);
+ if (IS_ERR(obj-clk))
+ goto err_clk;
+ }
I've no visibility on when these are going to get resolved, and it's
starting to concern me that there appears to be no progress on it,
especially as we have more and more code being merged with these
workarounds. It's getting towards the point where enough is enough
and we need OMAP4 clk support in place, even if it is just a simple
stop-gap implementation rather than all these horrible hacks spread
through the code which one day will need to be found and removed.
Yeah I agree.
The initial set of clock patches are more or less ready now and we
will posting them in next few days.
Regards,
Santosh
--
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 v2 4/4] OMAP4: PMIC: Update TWL mfd driver to create twl6030 regulators
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Tuesday, August 04, 2009 1:16 PM
To: Mark Brown
Cc: Krishnamoorthy, Balaji T; linux-omap@vger.kernel.org;
khil...@deeprootsystems.com; davi...@pacbell.net; linux-
i...@vger.kernel.org; sa...@openedhand.com; w...@iguana.be;
timo.t.kokko...@nokia.com; ben-li...@fluff.org; l...@slimlogic.co.uk; Nayak,
Rajendra
Subject: Re: [RFC][PATCH v2 4/4] OMAP4: PMIC: Update TWL mfd driver to
create twl6030 regulators
* Mark Brown broo...@opensource.wolfsonmicro.com [090803 17:23]:
On Wed, Jul 29, 2009 at 10:06:13AM +0530, balaj...@ti.com wrote:
- if (twl_has_regulator()) {
+ if (twl_has_regulator() is_class_twl4030()) {
is_class_twl4030() feels like it should have better namespacing, though
having the part name in there means it's not actually an issue.
How about twl_is_4030()?
The idea was to have a class of twl4030 IC's type IC's. There are many of them
with just different name (TPS *)
... twl_class_is_4030() What you say ?
Regards,
Santosh
--
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 v2 4/4] OMAP4: PMIC: Update TWL mfd driver to create twl6030 regulators
-Original Message-
From: Premi, Sanjeev
Sent: Tuesday, August 04, 2009 6:54 PM
To: Shilimkar, Santosh; Tony Lindgren; Mark Brown
Cc: Krishnamoorthy, Balaji T; linux-omap@vger.kernel.org;
khil...@deeprootsystems.com; davi...@pacbell.net; linux-
i...@vger.kernel.org; sa...@openedhand.com; w...@iguana.be;
timo.t.kokko...@nokia.com; ben-li...@fluff.org; l...@slimlogic.co.uk; Nayak,
Rajendra
Subject: RE: [RFC][PATCH v2 4/4] OMAP4: PMIC: Update TWL mfd driver to
create twl6030 regulators
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh
Sent: Tuesday, August 04, 2009 1:27 PM
To: Tony Lindgren; Mark Brown
Cc: Krishnamoorthy, Balaji T; linux-omap@vger.kernel.org;
khil...@deeprootsystems.com; davi...@pacbell.net; linux-
i...@vger.kernel.org; sa...@openedhand.com; w...@iguana.be;
timo.t.kokko...@nokia.com; ben-li...@fluff.org; l...@slimlogic.co.uk; Nayak,
Rajendra
Subject: RE: [RFC][PATCH v2 4/4] OMAP4: PMIC: Update TWL mfd driver to
create twl6030 regulators
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Tuesday, August 04, 2009 1:16 PM
To: Mark Brown
Cc: Krishnamoorthy, Balaji T; linux-omap@vger.kernel.org;
khil...@deeprootsystems.com; davi...@pacbell.net; linux-
i...@vger.kernel.org; sa...@openedhand.com; w...@iguana.be;
timo.t.kokko...@nokia.com; ben-li...@fluff.org; l...@slimlogic.co.uk;
Nayak,
Rajendra
Subject: Re: [RFC][PATCH v2 4/4] OMAP4: PMIC: Update TWL mfd driver to
create twl6030 regulators
* Mark Brown broo...@opensource.wolfsonmicro.com [090803 17:23]:
On Wed, Jul 29, 2009 at 10:06:13AM +0530, balaj...@ti.com wrote:
- if (twl_has_regulator()) {
+ if (twl_has_regulator() is_class_twl4030()) {
is_class_twl4030() feels like it should have better namespacing,
though
having the part name in there means it's not actually an issue.
How about twl_is_4030()?
The idea was to have a class of twl4030 IC's type IC's. There are many of
them with just different name (TPS *)
... twl_class_is_4030() What you say ?
Can I suggest: pmic_class_is_xxx() ?
Even better
Regards,
Santosh
--
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 v2 4/4] OMAP4: PMIC: Update TWL mfd driver to create twl6030 regulators
-Original Message- From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] Sent: Tuesday, August 04, 2009 7:13 PM To: Shilimkar, Santosh Cc: Premi, Sanjeev; Tony Lindgren; Krishnamoorthy, Balaji T; linux- o...@vger.kernel.org; khil...@deeprootsystems.com; davi...@pacbell.net; linux-...@vger.kernel.org; sa...@openedhand.com; w...@iguana.be; timo.t.kokko...@nokia.com; ben-li...@fluff.org; l...@slimlogic.co.uk; Nayak, Rajendra Subject: Re: [RFC][PATCH v2 4/4] OMAP4: PMIC: Update TWL mfd driver to create twl6030 regulators On Tue, Aug 04, 2009 at 06:56:13PM +0530, Shilimkar, Santosh wrote: is_class_twl4030() feels like it should have better namespacing, though having the part name in there means it's not actually an issue. How about twl_is_4030()? The idea was to have a class of twl4030 IC's type IC's. There are many of them with just different name (TPS *) ... twl_class_is_4030() What you say ? Can I suggest: pmic_class_is_xxx() ? Even better That feels like it's got a more global namespace than it ought - this is really only for this class of chip. It's also got a bit of an assumption that there's only one PMIC in the system which isn't always the case. Do you have boards / use cases where more than one PM IC would be used _and_ it will use the same driver ? Regards, Santosh -- 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] ARM: OMAP: TWL4030 IRQ
Anyways would be nice to get this in as a fix. I applied it to my for-next branch for now, and I'll also try to have Linus pulling it. Thanks Regards, Santosh -- 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 0/4] TWL6030 patch series
Mark, Felipe, -Original Message- From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] Sent: Friday, July 24, 2009 2:51 PM To: Shilimkar, Santosh Cc: Felipe Balbi; Krishnamoorthy, Balaji T; linux-omap@vger.kernel.org; t...@atomide.com; khil...@deeprootsystems.com; davi...@pacbell.net; Nayak, Rajendra Subject: Re: [RFC][PATCH 0/4] TWL6030 patch series On Fri, Jul 24, 2009 at 09:46:27AM +0530, Shilimkar, Santosh wrote: Mark, Liam, Can you please your comments of regulator patches. I'd really like to see the ifdefs go as someone else requested earlier in the thread. Allowing both twl4030 and twl6030 support to be built simultaneously is much nicer from a maintinance perspective and will scale better as further devices are added to the family. Can you please provide your comments on the v2 version of the patches in which Balaji has fixed the ifdef's Thanks!! Regards, Santosh -- 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
Pull Request for OMAP4
Hi Russell, Could you please pull four patches below for the upcoming merging window. The patches are rebased on commit 4be3bd7849165e7efa6b0b35a23d6a3598d97465: Linus Torvalds (1):Linux 2.6.31-rc4 and available in the git repository at: git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git omap4_upstream Summary: Santosh Shilimkar (1): OMAP4: sDMA: Update the request lines and new registers. Syed Rafiuddin (3): ARM: OMAP4: Add McBSP support ARM: OMAP4: Add UART4 support ARM: OMAP4: Update the GPIO support arch/arm/mach-omap2/board-4430sdp.c |2 +- arch/arm/mach-omap2/mcbsp.c | 41 + arch/arm/mach-omap2/serial.c| 10 ++ arch/arm/plat-omap/gpio.c | 249 --- arch/arm/plat-omap/include/mach/dma.h | 88 +++ arch/arm/plat-omap/include/mach/mcbsp.h |8 +- arch/arm/plat-omap/mcbsp.c |2 +- 7 files changed, 346 insertions(+), 54 deletions(-) Regards, Santosh -- 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: Enabling TPS65950 / TWL4030 Real-time clock functions
-Original Message- From: Elvis Dowson [mailto:elvis.dow...@mac.com] Sent: Saturday, August 01, 2009 8:56 PM To: Shilimkar, Santosh Cc: Linux OMAP Users Subject: Re: Enabling TPS65950 / TWL4030 Real-time clock functions Hi Santosh, Thanks for the reply. On Aug 1, 2009, at 6:55 PM, Shilimkar, Santosh wrote: Yes there is support on 2.6.29 and 2.6.31.Refer drivers/rtc/rtc- twl4030.c for more details. Is there any way to hook up a battery backup for the RTC for the Gumstix Overo Earth (TI OMAP 3503). Not sure whether I got your question correctly. The software driver you already know. Are you asking where to plug the backup battery on hardware pins? I don't have Gumstix Overo hardware but if above is your question and schematics are available then it can be traced. Regards, Santosh -- 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] ARM: OMAP: TWL4030 IRQ
Samuel,
Any comments?
In case the patch is ok, can you please merge it.
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh
Sent: Monday, July 27, 2009 11:31 AM
To: sa...@linux.intel.com
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.arm.linux.org.uk;
Russell King
Subject: [PATCH] ARM: OMAP: TWL4030 IRQ
From: Russell King rmk+ker...@arm.linux.org.uk
(Rebased on 2.6.31-rc4)
The TWL4030 IRQ handler has a bug which leads to spinlock lock-up. It is
calling the 'unmask' function in a process context. :The mask/unmask/ack
functions are only designed to be called from the IRQ handler code,
or the proper API interfaces found in linux/interrupt.h.
Also there is no need to have IRQ chaining mechanism. The right way to
handle this is to claim the parent interrupt as a standard interrupt
and arrange for handle_twl4030_pih to take care of the rest of the devices.
Mail thread on this issue can be found at:
http://marc.info/?l=linux-arm-kernelm=124629940123396w=2
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/mfd/twl4030-irq.c | 55 +++-
1 files changed, 24 insertions(+), 31 deletions(-)
diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index bae61b2..7d43083 100644
--- a/drivers/mfd/twl4030-irq.c
+++ b/drivers/mfd/twl4030-irq.c
@@ -180,14 +180,9 @@ static struct completion irq_event;
static int twl4030_irq_thread(void *data)
{
long irq = (long)data;
- struct irq_desc *desc = irq_to_desc(irq);
static unsigned i2c_errors;
static const unsigned max_i2c_errors = 100;
- if (!desc) {
- pr_err(twl4030: Invalid IRQ: %ld\n, irq);
- return -EINVAL;
- }
current-flags |= PF_NOFREEZE;
@@ -240,7 +235,7 @@ static int twl4030_irq_thread(void *data)
}
local_irq_enable();
- desc-chip-unmask(irq);
+ enable_irq(irq);
}
return 0;
@@ -255,25 +250,13 @@ static int twl4030_irq_thread(void *data)
* thread. All we do here is acknowledge and mask the interrupt and
wakeup
* the kernel thread.
*/
-static void handle_twl4030_pih(unsigned int irq, struct irq_desc *desc)
+static irqreturn_t handle_twl4030_pih(int irq, void *devid)
{
/* Acknowledge, clear *AND* mask the interrupt... */
- desc-chip-ack(irq);
- complete(irq_event);
-}
-
-static struct task_struct *start_twl4030_irq_thread(long irq)
-{
- struct task_struct *thread;
-
- init_completion(irq_event);
- thread = kthread_run(twl4030_irq_thread, (void *)irq, twl4030-
irq);
- if (!thread)
- pr_err(twl4030: could not create irq %ld thread!\n, irq);
-
- return thread;
+ disable_irq_nosync(irq);
+ complete(devid);
+ return IRQ_HANDLED;
}
-
/*--
*/
/*
@@ -734,18 +717,28 @@ int twl_init_irq(int irq_num, unsigned irq_base,
unsigned irq_end)
}
/* install an irq handler to demultiplex the TWL4030 interrupt */
- task = start_twl4030_irq_thread(irq_num);
- if (!task) {
- pr_err(twl4030: irq thread FAIL\n);
- status = -ESRCH;
- goto fail;
- }
- set_irq_data(irq_num, task);
- set_irq_chained_handler(irq_num, handle_twl4030_pih);
- return status;
+ init_completion(irq_event);
+ status = request_irq(irq_num, handle_twl4030_pih, IRQF_DISABLED,
+ TWL4030-PIH, irq_event);
+ if (status 0) {
+ pr_err(twl4030: could not claim irq%d: %d\n, irq_num,
status);
+ goto fail_rqirq;
+ }
+
+ task = kthread_run(twl4030_irq_thread, (void *)irq_num, twl4030-
irq);
+ if (IS_ERR(task)) {
+ pr_err(twl4030: could not create irq %d thread!\n, irq_num);
+ status = PTR_ERR(task);
+ goto fail_kthread;
+ }
+ return status;
+fail_kthread:
+ free_irq(irq_num, irq_event);
+fail_rqirq:
+ /* clean up twl4030_sih_setup */
fail:
for (i = irq_base; i irq_end; i++)
set_irq_chip_and_handler(i, NULL, NULL);
--
1.5.4.7
--
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: Enabling TPS65950 / TWL4030 Real-time clock functions
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Elvis Dowson Sent: Saturday, August 01, 2009 7:27 PM To: Linux OMAP Users Subject: Enabling TPS65950 / TWL4030 Real-time clock functions Hi, I am using a Gumstix Overo Earth (TI OMAP 3503) and this has a TPS69590/TWL4030 module, which I understand has a real-time clock subsystem. Is there support in the linux 2.6.29 or 2.6.31 kernel for enabling the RTC functions? I would like to preserve the system data and time between reboots. I've seen a 32Khz RTC clock option in the linux kernel. Is there a separate pin for a small battery just to keep supplying power to the RTC module? Yes there is support on 2.6.29 and 2.6.31.Refer drivers/rtc/rtc-twl4030.c for more details. Regards, Santosh -- 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 0/4] TWL6030 patch series
-Original Message- From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] Sent: Monday, July 20, 2009 5:45 PM To: Felipe Balbi Cc: Krishnamoorthy, Balaji T; linux-omap@vger.kernel.org; t...@atomide.com; khil...@deeprootsystems.com; davi...@pacbell.net; Shilimkar, Santosh; Nayak, Rajendra Subject: Re: [RFC][PATCH 0/4] TWL6030 patch series On Mon, Jul 20, 2009 at 03:11:57PM +0300, Felipe Balbi wrote: send these to lkml and Cc linux-omap. Also add to Cc: Samuel Ortiz sa...@openedhand.com Wim Van Sebroeck w...@iguana.be Timo Kokkonen timo.t.kokko...@nokia.com Ben Dooks ben-li...@fluff.org linux-...@vger.kernel.org linux-ker...@vger.kernel.org Plus me and Liam Girdwood l...@slimlogic.co.uk for the regulator stuff. Mark, Liam, Can you please your comments of regulator patches. Regards, Santosh -- 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: OMAP: Rename twl4030* driver files to enable re-use
-Original Message-
From: Felipe Balbi [mailto:m...@felipebalbi.com]
Sent: Tuesday, July 21, 2009 12:23 AM
To: Krishnamoorthy, Balaji T
Cc: linux-ker...@vger.kernel.org; t...@atomide.com;
khil...@deeprootsystems.com; davi...@pacbell.net;
linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
sa...@openedhand.com; w...@iguana.be;
timo.t.kokko...@nokia.com; ben-li...@fluff.org;
l...@slimlogic.co.uk; broo...@opensource.wolfsonmicro.com;
Shilimkar, Santosh; Nayak, Rajendra
Subject: Re: [PATCH 1/4] ARM: OMAP: Rename twl4030* driver
files to enable re-use
Hi,
On Mon, Jul 20, 2009 at 07:01:11PM +0530, balaj...@ti.com wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
The upcoming TWL6030 is companion chip for OMAP4 like the
current TWL4030
for OMAP3. The common modules like RTC, Regulator creates
opportunity
to re-use the most of the code from twl4030.
This patch renames few common drivers twl4030* files to
twl* to enable
the code re-use.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/board-2430sdp.c|2 +-
arch/arm/mach-omap2/board-3430sdp.c|2 +-
arch/arm/mach-omap2/board-ldp.c|2 +-
arch/arm/mach-omap2/board-omap3beagle.c|2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2 +-
arch/arm/mach-omap2/board-overo.c |2 +-
drivers/gpio/twl4030-gpio.c|2 +-
drivers/mfd/Makefile |2 +-
drivers/mfd/{twl4030-core.c = twl-core.c} |8 +++-
drivers/mfd/twl4030-irq.c |2 +-
drivers/regulator/Makefile |2 +-
.../{twl4030-regulator.c = twl-regulator.c} |6 +++---
drivers/rtc/Makefile |2 +-
drivers/rtc/{rtc-twl4030.c = rtc-twl.c} |2 +-
drivers/usb/otg/twl4030-usb.c |2 +-
include/linux/i2c/{twl4030.h = twl.h} |5 -
sound/soc/codecs/twl4030.c |2 +-
this is kinda useless, we can consider twl6030 as being sw compatible
(almost) with twl4030. And twl4030 driver already support plenty of
other devices, just look at drivers/mfd/twl4030-core.c lines
807 - 814.
We have twl4003, twl5030, tps65950, tps65930 and tps65920.
So IMO, renaming the files is unnecessary.
Well tps* are just catalog names of the twl4* family. So you can keep adding
whatever names there as long it's a same IC.
Perhaps you look in hurry to comment about this. Please look at the intention
of these patches. TWL6030 has PM IC similar to TWL4030 with bit different
interrupt management. Audio IC is a separate one as compared to combined in
case of TWL4030.
If it allows code re-use by renaming files, it should be good. Isn't it ? --
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 1/4] OMAP4: PMIC: Add support for twl6030 irq framework
Felipe, Thanks for the review. -Original Message- From: Felipe Balbi [mailto:m...@felipebalbi.com] Sent: Tuesday, July 21, 2009 12:37 AM To: Krishnamoorthy, Balaji T Cc: linux-ker...@vger.kernel.org; t...@atomide.com; khil...@deeprootsystems.com; davi...@pacbell.net; linux-omap@vger.kernel.org; linux-...@vger.kernel.org; sa...@openedhand.com; w...@iguana.be; timo.t.kokko...@nokia.com; ben-li...@fluff.org; l...@slimlogic.co.uk; broo...@opensource.wolfsonmicro.com; Nayak, Rajendra; Shilimkar, Santosh Subject: Re: [RFC][PATCH 1/4] OMAP4: PMIC: Add support for twl6030 irq framework I can summarize all your review comments in two points. 1. Renaming is some thing __you__ think in not necessary. For this, I have already responded but just to clarify others on the list, I am just copy pasting your point and our view on this topic. this is kinda useless, we can consider twl6030 as being sw compatible (almost) with twl4030. And twl4030 driver already support plenty of other devices, just look at drivers/mfd/twl4030-core.c lines 807 - 814. We have twl4003, twl5030, tps65950, tps65930 and tps65920. So IMO, renaming the files is unnecessary. Well tps* are just another catalog names of the twl4* family. So you can keep adding whatever names there as long it's a same IC. Perhaps you look in hurry to comment about this. Please look at the intention of these patches. TWL6030 has PM IC similar to TWL4030 with bit different interrupt management. Audio IC is a separate one as compared to combined in case of TWL4030. If it allows code re-use by renaming files, it should be good. Isn't it ? Here is summary of Major difference between Triton(TWL4030) and Phoenix(TWL6030_ chips are: -GPIO, Keypad is not present in Phoenix -I2C Chips addresses of modules like RTC, BCI, ADC, USB, PMC Master/Slave have changed. Base address of these module register is also changed. -PIH and SIH, module interrupt status registers will be replaced by PIH (INT_STS_A, INT_STS_B and INT_STS_C) and module interrupt status registers -MADC to GPADC in Phoenix, 17 channels supported GPADC in Phoenix supports Realtime, Asynchronous SW request. -RTC register offsets have changed. Addition/removal of LDO/SMPS Voltage Regulators 2. Usage of compile time macros like CONFIG_TWL4030 and CONFIG_TWL6030 should be avoided and you think it would break multi-omap. If we just go by definition Multi-OMAP is for different OMAP IC's. TWL4030 and TWL6030 are external companion IC's to OMAP. Any ways, these compile time switches can be avoided if we make runtime provision for these TWL IC's like. is_twl4030(), is_twl6030 etc like cpu_is_24xx(),cpu_is_44xx() etc. Obviously this asks to make the driver register map (which is different in case of TWL6030 w.r.t TWL4030) to be held in some arrays and select the appropriate one run-time. But it's doable if it helps. The patch series was made under _assumption_ that either TWL4030 or TWL6030 would be used. I am not sure whether there will boards where both will co-exist. Regards Santosh-- 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: OMAP4: sDMA: Update the request lines
diff --git a/arch/arm/plat-omap/include/mach/dma.h b/arch/arm/plat-omap/include/mach/dma.h index 8c1eae8..01ea54a 100644 --- a/arch/arm/plat-omap/include/mach/dma.h +++ b/arch/arm/plat-omap/include/mach/dma.h @@ -122,6 +122,11 @@ #define OMAP_DMA4_CCFN(n)(0x60 * (n) + 0xc0) #define OMAP_DMA4_COLOR(n) (0x60 * (n) + 0xc4) +/* Additional registers available on OMAP4 */ +#define OMAP_DMA4_CDP(n) (0x60 * (n) + 0xd0) +#define OMAP_DMA4_CNDP(n)(0x60 * (n) + 0xd4) +#define OMAP_DMA4_CCDN(n)(0x60 * (n) + 0xd8) + /* Dummy defines to keep multi-omap compiles happy */ #define OMAP1_DMA_REVISION 0 #define OMAP1_DMA_IRQSTATUS_L0 0 @@ -311,6 +316,89 @@ #define OMAP34XX_DMA_USIM_TX 79 /* S_DMA_78 */ #define OMAP34XX_DMA_USIM_RX 80 /* S_DMA_79 */ +/* DMA request lines for 44xx */ +#define OMAP44XX_DMA_DSS_DISPC_REQ 6 /* S_DMA_5 */ +#define OMAP44XX_DMA_SYS_REQ27 /* S_DMA_6 */ +#define OMAP44XX_DMA_ISS_REQ19 /* S_DMA_8 */ +#define OMAP44XX_DMA_ISS_REQ210 /* S_DMA_9 */ +#define OMAP44XX_DMA_ISS_EQ3 12 /* S_DMA_11 */ ^^ ... this one. Suggest you resend a version that uses that data. I am sorry but what's mistake you noticed in the patch ? Ya It should have been REQ. We will cross verify and resubmit the patch-- 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: User/kernel memory split
Romit, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Dasgupta, Romit Sent: Monday, July 06, 2009 5:00 PM To: V, Hemanth; linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org Subject: RE: User/kernel memory split Hemanth, I might be missing something but please see below: Hemanth, Why do you want the split? Do you have physical mem 1G in your system? We want to fit 512MB RAM on 2.6.27 Kernel which doesnot have highmem option. We also donot want to disturb the current I/O memory map [Romit] As long as your physical memory is slightly less than 1GB, I do not think highmem is necessary. For I/O map: Kernel virtual addresses start from 0xC000. Adding 512M to it gives 0xE000. So the virtual memory for IO space needs to be after this. Currently the IO Map is #define L4_WK_34XX_PHYS L4_WK_34XX_BASE /* 0x4830 */ #define L4_WK_34XX_VIRT 0xd830 #define L4_WK_34XX_SIZE SZ_1M #define L4_PER_34XX_VIRT0xd900 #define L4_PER_34XX_SIZESZ_1M #define L4_EMU_34XX_VIRT0xe400 #define L4_EMU_34XX_SIZESZ_64M #define OMAP34XX_GPMC_PHYS OMAP34XX_GPMC_BASE /* 0x6E00 */ #define OMAP34XX_GPMC_VIRT 0xFE00 #define OMAP34XX_GPMC_SIZE SZ_1M #define OMAP343X_SMS_VIRT 0xFC00 #define OMAP343X_SMS_SIZE SZ_1M #define OMAP343X_SDRC_PHYS OMAP343X_SDRC_BASE /* 0x6D00 */ #define OMAP343X_SDRC_VIRT 0xFD00 #define OMAP343X_SDRC_SIZE SZ_1M This is a problem as the existing virtual memory maps for I/O space would overlap with 512M SDRAM. So, we need to redefine the virtual mapping after 0xe000. The IO_OFFSET is 0x9000 currently. For L4_WK_34XX_VIRT we need a minimum of 0xe000 - 0x4830 i.e. 0x97D0 as the new IO_OFFSET. But using this new IO_OFFSET for mapping OMAP343x_GPMC_VIRT would result in an overflow(0x6E00 + 0x97D0 = 0x105D0). Using ioremap for these regions might help. But this needs changes to most drivers. In that case these static mappings could go away and I think they should. Some ARM kernel expert may comment! These points were discussed in below thread. http://lists.arm.linux.org.uk/lurker/message/20090626.181403.55450a9c.en.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: [ARM][OMAP] TWL4030 IRQ
Russell,
drivers/mfd/twl4030-irq.c | 55
++--
1 files changed, 23 insertions(+), 32 deletions(-)
diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index bae61b2..4bb1ea7 100644
--- a/drivers/mfd/twl4030-irq.c
+++ b/drivers/mfd/twl4030-irq.c
@@ -180,15 +180,9 @@ static struct completion irq_event;
static int twl4030_irq_thread(void *data)
{
long irq = (long)data;
- struct irq_desc *desc = irq_to_desc(irq);
static unsigned i2c_errors;
static const unsigned max_i2c_errors = 100;
- if (!desc) {
- pr_err(twl4030: Invalid IRQ: %ld\n, irq);
- return -EINVAL;
- }
-
current-flags |= PF_NOFREEZE;
while (!kthread_should_stop()) {
@@ -240,38 +234,25 @@ static int twl4030_irq_thread(void *data)
}
local_irq_enable();
- desc-chip-unmask(irq);
+ enable_irq(irq);
}
return 0;
}
/*
- * handle_twl4030_pih() is the desc-handle method for the
twl4030 interrupt.
- * This is a chained interrupt, so there is no desc-action
method for it.
+ * handle_twl4030_pih() is the handler for the main twl4030
interrupt.
* Now we need to query the interrupt controller in the
twl4030 to determine
* which module is generating the interrupt request.
However, we can't do i2c
* transactions in interrupt context, so we must defer that
work to a kernel
* thread. All we do here is acknowledge and mask the
interrupt and wakeup
* the kernel thread.
*/
-static void handle_twl4030_pih(unsigned int irq, struct
irq_desc *desc)
-{
- /* Acknowledge, clear *AND* mask the interrupt... */
- desc-chip-ack(irq);
- complete(irq_event);
-}
-
-static struct task_struct *start_twl4030_irq_thread(long irq)
+static irqreturn_t handle_twl4030_pih(int irq, void *devid)
{
- struct task_struct *thread;
-
- init_completion(irq_event);
- thread = kthread_run(twl4030_irq_thread, (void *)irq,
twl4030-irq);
- if (!thread)
- pr_err(twl4030: could not create irq %ld
thread!\n, irq);
-
- return thread;
+ disable_irq_nosync(irq);
+ complete(devid);
+ return IRQ_HANDLED;
}
/*
--*/
@@ -734,18 +715,28 @@ int twl_init_irq(int irq_num, unsigned
irq_base, unsigned irq_end)
}
/* install an irq handler to demultiplex the TWL4030
interrupt */
- task = start_twl4030_irq_thread(irq_num);
- if (!task) {
- pr_err(twl4030: irq thread FAIL\n);
- status = -ESRCH;
- goto fail;
+ init_completion(irq_event);
+
+ status = request_irq(irq_num, handle_twl4030_pih, IRQF_DISABLED,
+ TWL4030-PIH, irq_event);
+ if (status 0) {
+ pr_err(twl4030: could not claim irq%d: %d\n,
irq_num, status);
+ goto fail_rqirq;
}
- set_irq_data(irq_num, task);
- set_irq_chained_handler(irq_num, handle_twl4030_pih);
+ task = kthread_run(twl4030_irq_thread, (void *)irq_num,
twl4030-irq);
+ if (IS_ERR(task)) {
+ pr_err(twl4030: could not create irq %d
thread!\n, irq_num);
+ status = PTR_ERR(task);
+ goto fail_kthread;
+ }
return status;
+fail_kthread:
+ free_irq(irq_num, irq_event);
+fail_rqirq:
+ /* clean up twl4030_sih_setup */
fail:
for (i = irq_base; i irq_end; i++)
set_irq_chip_and_handler(i, NULL, NULL);
I have tested this patch on OMAP3430SDP with Triton RTC module and works well.
Thanks!!
Kevin/Vikram,
Can this patch be included on omap_pm branch to check for any regression?
Regards,
Santosh
twl_mainline_irq.patch
Description: twl_mainline_irq.patch
RE: [ARM][OMAP] TWL4030 IRQ
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, July 01, 2009 4:36 AM
To: Shilimkar, Santosh
Cc: Russell King - ARM Linux;
linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org
Subject: Re: [ARM][OMAP] TWL4030 IRQ
Shilimkar, Santosh santosh.shilim...@ti.com writes:
Kevin/Vikram,
Can this patch be included on omap_pm branch to check for
any regression?
Sure, I have it applied to the PM branch locally, but before I push,
can you (or Russell) send me a descriptive changelog for this patch.
(Here is the patch with some description.)
From 67d399fd88629f37b8debea1aa51bf20ff8957f6 Mon Sep 17 00:00:00 2001
From: Russell King rmk+ker...@arm.linux.org.uk
Date: Wed, 1 Jul 2009 10:31:17 +0530
Subject: [PATCH] ARM: OMAP: TWL4030 IRQ
The TWL4030 IRQ handler has a bug which leads to spinlock lock-up. It is
calling the 'unmask' function in a process context. The mask/unmask/ack
functions are only designed to be called from the IRQ handler code,
or the proper API interfaces found in linux/interrupt.h.
Also there is no need to have IRQ chaining mechanism. The right way to
handle this is to claim the parent interrupt as a standard interrupt
and arrange for handle_twl4030_pih to take care of the rest of the devices.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/mfd/twl4030-irq.c | 54 -
1 files changed, 24 insertions(+), 30 deletions(-)
diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index aca2670..e30e7bc 100644
--- a/drivers/mfd/twl4030-irq.c
+++ b/drivers/mfd/twl4030-irq.c
@@ -180,14 +180,9 @@ static struct completion irq_event;
static int twl4030_irq_thread(void *data)
{
long irq = (long)data;
- struct irq_desc *desc = irq_to_desc(irq);
static unsigned i2c_errors;
static const unsigned max_i2c_errors = 100;
- if (!desc) {
- pr_err(twl4030: Invalid IRQ: %ld\n, irq);
- return -EINVAL;
- }
current-flags |= PF_NOFREEZE;
@@ -240,7 +235,7 @@ static int twl4030_irq_thread(void *data)
}
local_irq_enable();
- desc-chip-unmask(irq);
+ enable_irq(irq);
}
return 0;
@@ -255,23 +250,12 @@ static int twl4030_irq_thread(void *data)
* thread. All we do here is acknowledge and mask the interrupt and wakeup
* the kernel thread.
*/
-static void handle_twl4030_pih(unsigned int irq, irq_desc_t *desc)
+static irqreturn_t handle_twl4030_pih(int irq, void *devid)
{
/* Acknowledge, clear *AND* mask the interrupt... */
- desc-chip-ack(irq);
- complete(irq_event);
-}
-
-static struct task_struct *start_twl4030_irq_thread(long irq)
-{
- struct task_struct *thread;
-
- init_completion(irq_event);
- thread = kthread_run(twl4030_irq_thread, (void *)irq, twl4030-irq);
- if (!thread)
- pr_err(twl4030: could not create irq %ld thread!\n, irq);
-
- return thread;
+ disable_irq_nosync(irq);
+ complete(devid);
+ return IRQ_HANDLED;
}
/*--*/
@@ -734,18 +718,28 @@ int twl_init_irq(int irq_num, unsigned irq_base, unsigned
irq_end)
}
/* install an irq handler to demultiplex the TWL4030 interrupt */
- task = start_twl4030_irq_thread(irq_num);
- if (!task) {
- pr_err(twl4030: irq thread FAIL\n);
- status = -ESRCH;
- goto fail;
- }
- set_irq_data(irq_num, task);
- set_irq_chained_handler(irq_num, handle_twl4030_pih);
- return status;
+ init_completion(irq_event);
+ status = request_irq(irq_num, handle_twl4030_pih, IRQF_DISABLED,
+ TWL4030-PIH, irq_event);
+ if (status 0) {
+ pr_err(twl4030: could not claim irq%d: %d\n, irq_num, status);
+ goto fail_rqirq;
+ }
+
+ task = kthread_run(twl4030_irq_thread, (void *)irq_num, twl4030-irq);
+ if (IS_ERR(task)) {
+ pr_err(twl4030: could not create irq %d thread!\n, irq_num);
+ status = PTR_ERR(task);
+ goto fail_kthread;
+ }
+ return status;
+fail_kthread:
+ free_irq(irq_num, irq_event);
+fail_rqirq:
+ /* clean up twl4030_sih_setup */
fail:
for (i = irq_base; i irq_end; i++)
set_irq_chip_and_handler(i, NULL, NULL);
--
1.5.4.7
Regards,
Santosh
0001-ARM-OMAP-TWL4030-IRQ.patch
Description: 0001-ARM-OMAP-TWL4030-IRQ.patch
RE: [ARM][OMAP] TWL4030 IRQ
And here it is - I've only build-tested it so far.
drivers/mfd/twl4030-irq.c | 55
++--
1 files changed, 23 insertions(+), 32 deletions(-)
diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index bae61b2..4bb1ea7 100644
--- a/drivers/mfd/twl4030-irq.c
+++ b/drivers/mfd/twl4030-irq.c
@@ -180,15 +180,9 @@ static struct completion irq_event;
static int twl4030_irq_thread(void *data)
{
long irq = (long)data;
- struct irq_desc *desc = irq_to_desc(irq);
static unsigned i2c_errors;
static const unsigned max_i2c_errors = 100;
- if (!desc) {
- pr_err(twl4030: Invalid IRQ: %ld\n, irq);
- return -EINVAL;
- }
-
current-flags |= PF_NOFREEZE;
while (!kthread_should_stop()) {
@@ -240,38 +234,25 @@ static int twl4030_irq_thread(void *data)
}
local_irq_enable();
- desc-chip-unmask(irq);
+ enable_irq(irq);
}
return 0;
}
Russell,
Just a question here.
In the enable_irq(irq) and disable_irq(irq) call tree, internally there are
calls to
the interrupt controller chip.
In disable_irq() path:
desc-chip-disable(irq);
And in emable_irq() path:
desc-chip-enable(irq);
But the in gic gic_chip, enable/disable fn are not populated.
static struct irq_chip gic_chip = {
.name = GIC,
.ack= gic_ack_irq,
.mask = gic_mask_irq,
.unmask = gic_unmask_irq,
#ifdef CONFIG_SMP
.set_affinity = gic_set_cpu,
#endif
}
Do we need these(disable/enable) hooks in gic_chip as well ?
Regards,
Santosh
--
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] [RFC] OMAP4: sDMA: Update the request lines and new registers.
-Original Message- From: Shilimkar, Santosh Sent: Tuesday, May 12, 2009 6:11 PM To: linux-omap@vger.kernel.org Cc: Shilimkar, Santosh Subject: [PATCH] [RFC] OMAP4: sDMA: Update the request lines and new registers. This patch updates the platform dma.h with new dma request lines for OMAP4 peripherals. Also additional hardware register of OMAP4 sDMA module are included. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/plat-omap/include/mach/dma.h | 65 - 1 files changed, 64 insertions(+), 1 deletions(-) mode change 100644 = 100755 arch/arm/plat-omap/include/mach/dma.h diff --git a/arch/arm/plat-omap/include/mach/dma.h b/arch/arm/plat-omap/include/mach/dma.h old mode 100644 new mode 100755 index 8e05b6a..3dc1b14 --- a/arch/arm/plat-omap/include/mach/dma.h +++ b/arch/arm/plat-omap/include/mach/dma.h @@ -122,6 +122,10 @@ #define OMAP_DMA4_CCFN(n)(0x60 * (n) + 0xc0) #define OMAP_DMA4_COLOR(n) (0x60 * (n) + 0xc4) +#define OMAP_DMA4_CDP_REG(n) (0x60 * (n) + 0xd0) +#define OMAP_DMA4_CNDP_REG(n) (0x60 * (n) + 0xd4) +#define OMAP_DMA4_CCDN_REG(n) (0x60 * (n) + 0xd8) + /* Dummy defines to keep multi-omap compiles happy */ #define OMAP1_DMA_REVISION 0 #define OMAP1_DMA_IRQSTATUS_L0 0 @@ -209,7 +213,7 @@ #define OMAP_DMA_MMC2_RX 55 #define OMAP_DMA_CRYPTO_DES_OUT 56 -/* DMA channels for 24xx */ +/* DMA channels for 24xx 34xx and 44xx*/ #define OMAP24XX_DMA_NO_DEVICE 0 #define OMAP24XX_DMA_XTI_DMA 1 /* S_DMA_0 */ #define OMAP24XX_DMA_EXT_DMAREQ0 2 /* S_DMA_1 */ @@ -310,6 +314,65 @@ #define OMAP34XX_DMA_USIM_TX 79 /* S_DMA_78 */ #define OMAP34XX_DMA_USIM_RX 80 /* S_DMA_79 */ + +#define OMAP44XX_DMA_DSS_LINE_TRIG 6 /* S_DMA_5 */ +#define OMAP44XX_DMA_MCASP1_AXEVT 8 /* S_DMA_7 */ +#define OMAP44XX_DMA_ISS_DMA_REQ0 9 /* S_DMA_8 */ +#define OMAP44XX_DMA_ISS_DMA_REQ1 10 /* S_DMA_9 */ +#define OMAP44XX_DMA_MCASP1_AREVT 11 /* S_DMA_10 */ +#define OMAP44XX_DMA_ISS_DMA_REQ2 12 /* S_DMA_11 */ +#define OMAP44XX_DMA_ISS_DMA_REQ3 13 /* S_DMA_12 */ +#define OMAP44XX_DMA_DSS_RFBI_DMA_REQ 14 /* S_DMA_13 */ +#define OMAP44XX_DMA_MCBSP2_TX 17 /* S_DMA_16 */ +#define OMAP44XX_DMA_MCBSP2_RX 18 /* S_DMA_17 */ +#define OMAP44XX_DMA_MCBSP3_TX 19 /* S_DMA_18 */ +#define OMAP44XX_DMA_MCBSP3_RX 20 /* S_DMA_19 */ +#define OMAP44XX_DMA_MCBSP4_TX 31 /* S_DMA_30 */ +#define OMAP44XX_DMA_MCBSP4_RX 32 /* S_DMA_31 */ +#define OMAP44XX_DMA_MCBSP1_TX 33 /* S_DMA_32 */ +#define OMAP44XX_DMA_MCBSP1_RX 34 /* S_DMA_33 */ +#define OMAP44XX_DMA_UART4_DMA_TX 55 /* S_DMA_54 */ +#define OMAP44XX_DMA_UART4_DMA_RX 56 /* S_DMA_55 */ +#define OMAP44XX_DMA_MMC4_DMA_TX 57 /* S_DMA_56 */ +#define OMAP44XX_DMA_MMC5_DMA_TX 59 /* S_DMA_58 */ +#define OMAP44XX_DMA_MMC5_DMA_RX 60 /* S_DMA_59 */ +#define OMAP44XX_DMA_MCPDM_UP 65 /* S_DMA_64 */ +#define OMAP44XX_DMA_MCPDM_DL 66 /* S_DMA_65 */ +#define OMAP44XX_DMA_DMIC_DMA_REQ 67 /* S_DMA_66 */ +#define OMAP44XX_DSS_HDMI_DMA_REQ 76 /* S_DMA_75 */ + + +#define OMAP44XX_DMM_DSS_DSI2_DMA0 81 /* S_DMA_80 */ +#define OMAP44XX_DMM_DSS_DSI2_DMA1 82 /* S_DMA_81 */ +#define OMAP44XX_DMM_DSS_DSI2_DMA2 83 /* S_DMA_82 */ +#define OMAP44XX_DMM_DSS_DSI2_DMA3 84 /* S_DMA_83 */ +#define OMAP44XX_DMM_SLIMBUS1_DMA_TX0 85 /* S_DMA_84 */ +#define OMAP44XX_DMM_SLIMBUS1_DMA_TX1 86 /* S_DMA_85 */ +#define OMAP44XX_DMM_SLIMBUS1_DMA_TX2 87 /* S_DMA_86 */ +#define OMAP44XX_DMM_SLIMBUS1_DMA_TX3 88 /* S_DMA_87 */ +#define OMAP44XX_DMM_SLIMBUS1_DMA_RX0 89 /* S_DMA_88 */ +#define OMAP44XX_DMM_SLIMBUS1_DMA_RX1 90 /* S_DMA_89 */ +#define OMAP44XX_DMM_SLIMBUS1_DMA_RX2 91 /* S_DMA_90 */ +#define OMAP44XX_DMM_SLIMBUS1_DMA_RX3 92 /* S_DMA_91 */ +#define OMAP44XX_DMM_SLIMBUS2_DMA_TX0 93 /* S_DMA_92 */ +#define OMAP44XX_DMM_SLIMBUS2_DMA_TX1 94 /* S_DMA_93 */ +#define OMAP44XX_DMM_SLIMBUS2_DMA_TX2 95 /* S_DMA_94 */ +#define OMAP44XX_DMM_SLIMBUS2_DMA_TX3 96 /* S_DMA_95 */ +#define OMAP44XX_DMM_SLIMBUS2_DMA_RX0 97 /* S_DMA_96 */ +#define OMAP44XX_DMM_SLIMBUS2_DMA_RX1 98 /* S_DMA_97 */ +#define OMAP44XX_DMM_SLIMBUS2_DMA_RX2 99 /* S_DMA_98 */ +#define OMAP44XX_DMM_SLIMBUS2_DMA_RX3 100 /* S_DMA_99 */ +#define OMAP44XX_DMM_ABE_DMAREQ0 101 /* S_DMA_100*/ +#define OMAP44XX_DMM_ABE_DMAREQ1 102 /* S_DMA_101*/ +#define OMAP44XX_DMM_ABE_DMAREQ2 103 /* S_DMA_102*/ +#define
RE: [PATCH] [RFC] OMAP4: sDMA: Update the request lines and new registers.
/* */ /* Hardware registers for LCD DMA */ -- Tony, Can you also check this patch and UART4 patch: http://www.spinics.net/lists/linux-omap/msg14161.html If you ack these two then we can rebase these on kernel.org and submit it for merge on linux-arm Acked-by: Tony Lindgren t...@atomide.com This should be queued for the next merge window, too late for 2.6.30 IMHO. Hi Santosh, could you compare the autogenerated DMA data that Rajendra has with this data, and use the autogenerated names if there are differences? It would be ideal to use the autogenerated DMA macro names if possible, since that will simplify the process of autogenerating omap_hwmod structures for OMAP4. Ok will check this Regards, Santosh -- 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: Reclaim address space on omaps, Tony on vacation in July
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Friday, June 26, 2009 11:56 AM To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.arm.linux.org.uk Subject: RFC: Reclaim address space on omaps, Tony on vacation in July Hi all, Last week I posted some more omap io.h clean-up patches to the linux-omap list [1], and started looking at what it would take to reclaim lost address space on top of the io.h clean-up patches. Looks like we should be able to reclaim about 454MB of the 640MB of the lost IO address space by doing the following: 1. Start converting drivers using omap_read/write to use ioremap + __raw_read/write 2. Remove OMAP2_IO_ADDRESS macro, and replace it with with finer grained OMAP_L3_ADDRESS, OMAP_L4_ADDRESS, OMAP_SDRC_ADDRESS and so on macros 3. Remap the the IO addresses in smaller sections in io.h so the virtual address for the blocks stays the same, and is counted down from the ARM reserved DMA address. After these steps, omap io.h would look like this: #define ARM_RESERVED_FUTURE_DMA 0xff00 /* Documentation/arm/memory.txt */ #define OMAP23_L4_PHYS0x4800 #define OMAP24_L3_PHYS0x6800 #define OMAP4_L3_PHYS 0x4400 #define OMAP4_L4_PHYS 0x4a00 /* These virtual addresses are the same for all omaps */ #define OMAP_L3_SIZE SZ_1M #define OMAP_L3_VIRT (ARM_RESERVED_FUTURE_DMA - OMAP_L3_SIZE) #define OMAP_L4_SIZE (SZ_16M + SZ_1M) #define OMAP_L4_VIRT (OMAP_L3_VIRT - OMAP_L4_SIZE) #define OMAP_SDRC_SIZESZ_1M #define OMAP_SDRC_BASE(OMAP_L4_VIRT - OMAP_SDRC_SIZE) ... #define OMAP_L3_ADDRESS(pa) (((pa) ~0xff00) + OMAP_L3_VIRT) #define OMAP_L4_ADDRESS(pa) (((pa) ~0xff00) + OMAP_L4_VIRT) #define OMAP_SDRC_ADDRESS(pa) (((pa) ~0xff00) + OMAP_SDRC_VIRT) We surely need this going forward since there is also demand to fit higher RAMS(256MB,512MB,1GB)in the system. Just to confirm, any further patches on this topic should be on top of this: Tony Lindgren (3): OMAP: Remove ifdefs for io.h OMAP: Rename OMAP_MPUIO_BASE to OMAP1_MPUIO_BASE OMAP: Remove OMAP_IO_ADDRESS, use OMAP1_IO_ADDRESS and OMAP2_IO_ADDRESS instead Is that correct Tony ? Regards, Santosh -- 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: [RESUBMIT][PATCH][RFC] OMAP4: McSPI Support for OMAP_4430
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Thursday, June 25, 2009 10:15 PM To: Syed, Rafiuddin Cc: linux-omap@vger.kernel.org Subject: Re: [RESUBMIT][PATCH][RFC] OMAP4: McSPI Support for OMAP_4430 Syed Rafiuddin rafiuddin.s...@ti.com writes: This patch adds McSPI support for OMAP4430 SDP platform. All the base addresses are changed between OMAP1/2/3 and OMAP4.The fields of the resource structures are filled at runtime to have McSPI support on OMAP4. Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com This driver needs some help for multi-omap, but that problem existed before this patch, so Acked-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/devices.c | 25 + drivers/spi/omap2_mcspi.c | 10 ++ 2 files changed, 27 insertions(+), 8 deletions(-) Not sure but looks like the patch needs split since different upstream paths 1. arch/arm/mach-omap2/devices.c -- linux-arm 2. drivers/spi/omap2_mcspi.c --- Don't know the list but should be some driver list. Is that correct ? Regards, Santosh -- 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: [RESUBMIT][PATCH][RFC] OMAP4: McSPI Support for OMAP_4430
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, June 26, 2009 11:21 AM To: Shilimkar, Santosh Cc: Kevin Hilman; Syed, Rafiuddin; linux-omap@vger.kernel.org Subject: Re: [RESUBMIT][PATCH][RFC] OMAP4: McSPI Support for OMAP_4430 * Shilimkar, Santosh santosh.shilim...@ti.com [090626 08:00]: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Thursday, June 25, 2009 10:15 PM To: Syed, Rafiuddin Cc: linux-omap@vger.kernel.org Subject: Re: [RESUBMIT][PATCH][RFC] OMAP4: McSPI Support for OMAP_4430 Syed Rafiuddin rafiuddin.s...@ti.com writes: This patch adds McSPI support for OMAP4430 SDP platform. All the base addresses are changed between OMAP1/2/3 and OMAP4.The fields of the resource structures are filled at runtime to have McSPI support on OMAP4. Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com This driver needs some help for multi-omap, but that problem existed before this patch, so Acked-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/devices.c | 25 + drivers/spi/omap2_mcspi.c | 10 ++ 2 files changed, 27 insertions(+), 8 deletions(-) Not sure but looks like the patch needs split since different upstream paths 1. arch/arm/mach-omap2/devices.c -- linux-arm 2. drivers/spi/omap2_mcspi.c --- Don't know the list but should be some driver list. Is that correct ? I think this is OK to send as a single patch via the SPI list. Acked-by: Tony Lindgren t...@atomide.com Cool !! Thanks Kevin, Tony for ACK. -- 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
[ARM][OMAP] TWL4030 IRQ
(resending wrapped message)
Russell,
-Original Message-
From: Shilimkar, Santosh
Sent: Saturday, June 20, 2009 8:55 PM
To: 'Tony Lindgren'; 'linux-omap@vger.kernel.org'
Cc: 'Russell King - ARM Linux'
Subject: [ARM][OMAP] TWL4030 IRQ
Just to brief you all, I came across a dead lock scenario on
the arm-smp kernel. After discussing with Russell on mailing
list, the actual bug seems be located in twl4030 IRQ implementation.
Initially I was suspecting the arm-generic area and hence
didn't include linux-omap list in the mail thread
For more information on this issue, please read this email thread.
http://marc.info/?l=linux-arm-kernelm=124550947525299w=2
I will create a patch for twl4030 and also would be
correcting upcoming twl6030 accordingly.
If anyone on this mailing list has any other opinion, please
react to the email thread.
After digging a bit, the proposed twl_irq change would need some major
changes.
1. All the T2(TWL)drivers ( rtc, madc, bci, gpio, keypad, usb, mmc)needs
modification.Currently twl_irq fw implements kind of twl4030_irq_chip
which allows all the T2 drivers to get virtual interrupt numbers and can
make use of standard request_irq linux api.
2.Above also helps to have useful entries
like /proc/interrupts/rtc etc.
With proposed change this also won't be available.
3. Register/unregister irq handlers to T2 from all the drivers
On the reported lock-up issue, I tried alternative to call mask/unmask
functions with disabling local cpu interrupts.
This worked for me but not sure whether it is entirely correct.
Something like this:
static void handle_twl4030_pih(unsigned int irq, irq_desc_t *desc)
{
+ unsigned long flags;
+
/* Acknowledge, clear *AND* mask the interrupt... */
+ local_irq_save(flags);
desc-chip-ack(irq);
+ local_irq_restore(flags);
complete(irq_event);
}
Do you think above approach is fine to get around the spin-lock lockup
issue ?
Regards,
Santosh--
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: [ARM][OMAP] TWL4030 IRQ
Russell,
After digging a bit, the proposed twl_irq change would need some major changes.
1. All the T2(TWL)drivers ( rtc, madc, bci, gpio, keypad, usb, mmc)needs
modification. Currently twl_irq fw implements kind of twl4030_irq_chip which
allows all the T2 drivers to get virtual interrupt numbers and can make use of
standard request_irq linux api.
2.Above also helps to have useful entries like /proc/interrupts/rtc etc. With
proposed change this also won't be available.
3. Register/unregister irq handlers to T2 from all the drivers
On the reported lock-up issue, I tried alternative to call mask/unmask
functions with disabling local cpu interrupts. This worked for me but not sure
whether it is entirely correct.
Something like this:
static void handle_twl4030_pih(unsigned int irq, irq_desc_t *desc)
{
+ unsigned long flags;
+
/* Acknowledge, clear *AND* mask the interrupt... */
+ local_irq_save(flags);
desc-chip-ack(irq);
+ local_irq_restore(flags);
complete(irq_event);
}
Do you think above approach is fine to get around the spin-lock lockup issue ?
-Original Message-
From: Shilimkar, Santosh
Sent: Saturday, June 20, 2009 8:55 PM
To: 'Tony Lindgren'; 'linux-omap@vger.kernel.org'
Cc: 'Russell King - ARM Linux'
Subject: [ARM][OMAP] TWL4030 IRQ
Just to brief you all, I came across a dead lock scenario on
the arm-smp kernel. After discussing with Russell on mailing
list, the actual bug seems be located in twl4030 IRQ implementation.
Initially I was suspecting the arm-generic area and hence
didn't include linux-omap list in the mail thread
For more information on this issue, please read this email thread.
http://marc.info/?l=linux-arm-kernelm=124550947525299w=2
I will create a patch for twl4030 and also would be
correcting upcoming twl6030 accordingly.
If anyone on this mailing list has any other opinion, please
react to the email thread.
Regards,
Santosh --
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
[ARM][OMAP] TWL4030 IRQ
Just to brief you all, I came across a dead lock scenario on the arm-smp kernel. After discussing with Russell on mailing list, the actual bug seems be located in twl4030 IRQ implementation. Initially I was suspecting the arm-generic area and hence didn't include linux-omap list in the mail thread For more information on this issue, please read this email thread. http://marc.info/?l=linux-arm-kernelm=124550947525299w=2 I will create a patch for twl4030 and also would be correcting upcoming twl6030 accordingly. If anyone on this mailing list has any other opinion, please react to the email thread. Thanks !! Regards, Santosh -- 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/4]ARM: OMAP4: SMP: Patch series
Russell, -Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Monday, June 08, 2009 8:21 PM To: Shilimkar, Santosh Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org; Tony Lindgren Subject: Re: [PATCH 0/4]ARM: OMAP4: SMP: Patch series On Wed, May 27, 2009 at 09:52:38PM +0530, Shilimkar, Santosh wrote: I have rebased this series on top of your arm-smp patches and my earlier basic omap4 patches. Can you please rebase your patches on commit c7f7ff1 in my tree (it's in my devel branch) and I'll merge them in. (Please don't base patches on the top of the devel branch - you may notice it's a merge of 'devel-unstable' which is... unstable stuff.) I have rebased my patches on commit c7f7ff1 in your tree's devel branch. The 'arch/arm/mach-types' is still not updated in your tree so I added manually to test the functionality. Is it possible for you to pull these patches from following: git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git for_rmk -shortlog Santosh Shilimkar(4) ARM: OMAP4: SMP: Update defconfig for OMAP4430 ARM: OMAP4: SMP: Enable SMP support for OMAP4430 ARM: OMAP4: SMP: Add mpu timer support for OMAP4430 ARM: OMAP4: SMP: Add OMAP4430 SMP board files -diffstat arch/arm/Kconfig |8 +- arch/arm/configs/omap_4430sdp_defconfig | 128 +- arch/arm/mach-omap2/Makefile |4 + arch/arm/mach-omap2/omap-headsmp.S| 46 +++ arch/arm/mach-omap2/omap-smp.c| 178 + arch/arm/mach-omap2/timer-gp.c|4 + arch/arm/mach-omap2/timer-mpu.c | 34 + arch/arm/plat-omap/include/mach/entry-macro.S | 28 arch/arm/plat-omap/include/mach/irqs.h|2 + arch/arm/plat-omap/include/mach/smp.h | 51 +++ 10 files changed, 445 insertions(+), 38 deletions(-) create mode 100644 arch/arm/mach-omap2/omap-headsmp.S create mode 100644 arch/arm/mach-omap2/omap-smp.c create mode 100644 arch/arm/mach-omap2/timer-mpu.c create mode 100644 arch/arm/plat-omap/include/mach/smp.h Regards, Santosh -- 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: linux-next: manual merge of the omap tree with the arm tree
-Original Message- From: Stephen Rothwell [mailto:s...@canb.auug.org.au] Sent: Thursday, May 28, 2009 10:02 AM To: Tony Lindgren; linux-omap@vger.kernel.org Cc: linux-n...@vger.kernel.org; linux-ker...@vger.kernel.org; Russell King; Shilimkar, Santosh Subject: linux-next: manual merge of the omap tree with the arm tree Hi all, Today's linux-next merge of the omap tree got a conflict in arch/arm/Makefile between commit b4175b89921fefb2f352472fa6dccb0fc4fb37d9 ([ARM] sort machine- and plat- by CONFIG* name) from the arm tree and commit 68394eae0fc4e801fc2ae33055b24a9754669a7b (ARM: OMAP4: Add support for 4430 SDP) from the omap tree. I fixed it up (see below) and can carry the fix as necessary. -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc arch/arm/Makefile index e97c21b,676d10d..000 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@@ -99,72 -99,65 +99,73 @@@ CHECKFLAGS += -D__arm_ #Default value head-y := arch/arm/kernel/head$(MMUEXT).o arch/arm/kernel/init_task.o textofs-y := 0x8000 - machine-$(CONFIG_ARCH_W90X900):= w90x900 + +# Machine directory name. This list is sorted alphanumerically +# by CONFIG_* macro name. +machine-$(CONFIG_ARCH_AAEC2000) := aaec2000 +machine-$(CONFIG_ARCH_AT91) := at91 +machine-$(CONFIG_ARCH_CLPS711X) := clps711x +machine-$(CONFIG_ARCH_DAVINCI) := davinci +machine-$(CONFIG_ARCH_EBSA110) := ebsa110 +machine-$(CONFIG_ARCH_EP93XX) := ep93xx +machine-$(CONFIG_ARCH_GEMINI) := gemini +machine-$(CONFIG_ARCH_H720X):= h720x +machine-$(CONFIG_ARCH_INTEGRATOR) := integrator +machine-$(CONFIG_ARCH_IOP13XX) := iop13xx +machine-$(CONFIG_ARCH_IOP32X) := iop32x +machine-$(CONFIG_ARCH_IOP33X) := iop33x +machine-$(CONFIG_ARCH_IXP2000) := ixp2000 +machine-$(CONFIG_ARCH_IXP23XX) := ixp23xx +machine-$(CONFIG_ARCH_IXP4XX) := ixp4xx +machine-$(CONFIG_ARCH_KIRKWOOD) := kirkwood +machine-$(CONFIG_ARCH_KS8695) := ks8695 +machine-$(CONFIG_ARCH_L7200):= l7200 +machine-$(CONFIG_ARCH_LH7A40X) := lh7a40x +machine-$(CONFIG_ARCH_LOKI) := loki +machine-$(CONFIG_ARCH_MMP) := mmp +machine-$(CONFIG_ARCH_MSM) := msm +machine-$(CONFIG_ARCH_MV78XX0) := mv78xx0 +machine-$(CONFIG_ARCH_MX1) := mx1 +machine-$(CONFIG_ARCH_MX2) := mx2 +machine-$(CONFIG_ARCH_MX3) := mx3 +machine-$(CONFIG_ARCH_NETX) := netx +machine-$(CONFIG_ARCH_NS9XXX) := ns9xxx +machine-$(CONFIG_ARCH_OMAP1):= omap1 +machine-$(CONFIG_ARCH_OMAP2):= omap2 +machine-$(CONFIG_ARCH_OMAP3):= omap2 ++machine-$(CONFIG_ARCH_OMAP4):= omap2 ++ Is this really ok ? +machine-$(CONFIG_ARCH_ORION5X) := orion5x +machine-$(CONFIG_ARCH_PNX4008) := pnx4008 +machine-$(CONFIG_ARCH_PXA) := pxa -- 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: linux-next: manual merge of the omap tree with the arm tree
-Original Message- From: Stephen Rothwell [mailto:s...@canb.auug.org.au] Sent: Thursday, May 28, 2009 12:05 PM To: Shilimkar, Santosh Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-n...@vger.kernel.org; linux-ker...@vger.kernel.org; Russell King Subject: Re: linux-next: manual merge of the omap tree with the arm tree Hi, On Thu, 28 May 2009 11:55:09 +0530 Shilimkar, Santosh santosh.shilim...@ti.com wrote: +machine-$(CONFIG_ARCH_OMAP2):= omap2 +machine-$(CONFIG_ARCH_OMAP3):= omap2 ++machine-$(CONFIG_ARCH_OMAP4):= omap2 ++ Is this really ok ? Yeah, this is a diff of a git merge. The ++ just means it was added on neither side of the merge - I modified the change from the omap tree slightly to fit in better with the cleanups from the arm tree. Ok. Thanks !! Regards, Santosh -- 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: OMAP4: SMP: Patch series
Russell, I have rebased this series on top of your arm-smp patches and my earlier basic omap4 patches. Series is based of kernel.org 2.6.30-rc6 ( commit:1406de8e11eb043681297adf86d6892ff8efc27a). This series have dependency on [1],[2],[3],[4] and latest mach-types The series contains: [PATCH 1/4] ARM: OMAP4: SMP: Add OMAP4430 SMP board files [PATCH 2/4] ARM: OMAP4: SMP: Add mpu timer support for OMAP4430 [PATCH 3/4] ARM: OMAP4: SMP: Enable SMP support for OMAP4430 [PATCH 4/4] ARM: OMAP4: SMP: Update defconfig for OMAP4430 Regards, Santosh [1]:Russell's arm-smp patch series + one of my patch http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/arm:smp.diff [2]:Tony's : [PATCH 0/5] More header clean-up http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12231.html [3]:Mine [PATCH 0/4] OMAP: Cleanup series. http://lists.arm.linux.org.uk/lurker/message/20090519.131647.c2c471ef.en.html [4]:Mine [PATCH 0/4] ARM: OMPA4: Basic boot patch series based on linux-omap http://lists.arm.linux.org.uk/lurker/message/20090520.125900.9209eb81.en.html Regards, Santosh-- 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: OMAP4: Add minimal support for omap4
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Thursday, May 28, 2009 5:07 AM To: Shilimkar, Santosh Cc: li...@arm.linux.org.uk; linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org Subject: Re: [PATCH 1/4] ARM: OMAP4: Add minimal support for omap4 * Santosh Shilimkar santosh.shilim...@ti.com [090520 05:59]: This patch adds the support for OMAP4. The platform and machine specific headers and sources updated for OMAP4430 SDP platform. OMAP4430 is Texas Instrument's SOC based on ARM Cortex-A9 SMP architecture. It's a dual core SOC with GIC used for interrupt handling and SCU for cache coherency. I've added these to omap for-next branch. Thanks Tony !! Regards, Santosh -- 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/10] ARM: OMAP2/3: sDMA: Correct omap_request_dma_chain()
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Monday, May 25, 2009 3:04 PM To: Tony Lindgren Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org; Shilimkar, Santosh Subject: Re: [PATCH 07/10] ARM: OMAP2/3: sDMA: Correct omap_request_dma_chain() On Tue, May 19, 2009 at 04:40:07PM -0700, Tony Lindgren wrote: From: Santosh Shilimkar santosh.shilim...@ti.com Original OMAP DMA chaining design has chain_id as one of the callback parameters. Patch 538528de0cb256f65716ab2e9613d9e920f97fe2 broke the desing. Change the callback to return the logical channel number and not chain_id. This patch does not make a material change. It merely changes the name used in a couple function pointer prototype. This has no impact on the generated code - iow, it's cosmetic. Yes it does look cosmetic but if you see the API signature, it corrects the callback parameters which actually the DMA lib sends. The current API signature is misleading for chained DMA transfers where the actual driver passes 'channel number' as one of the callback parameter instead of chain_id which was the original design. Regards, Santosh -- 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: OMAP4: Clock stubs since CLKDEV not in yet.
Tony, Correcting the spelling error which RMK has pointed (sunctions -- functions ) Regards, Santosh 0002-ARM-OMAP4-Clock-stubs-since-clock-management-frame.patch Description: 0002-ARM-OMAP4-Clock-stubs-since-clock-management-frame.patch
RE: [PATCH 07/10] ARM: OMAP2/3: sDMA: Correct omap_request_dma_chain(), v2
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Monday, May 25, 2009 9:59 PM To: Shilimkar, Santosh Cc: Russell King - ARM Linux; linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org Subject: Re: [PATCH 07/10] ARM: OMAP2/3: sDMA: Correct omap_request_dma_chain(), v2 * Shilimkar, Santosh santosh.shilim...@ti.com [090525 02:40]: -Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Monday, May 25, 2009 3:04 PM To: Tony Lindgren Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org; Shilimkar, Santosh Subject: Re: [PATCH 07/10] ARM: OMAP2/3: sDMA: Correct omap_request_dma_chain() On Tue, May 19, 2009 at 04:40:07PM -0700, Tony Lindgren wrote: From: Santosh Shilimkar santosh.shilim...@ti.com Original OMAP DMA chaining design has chain_id as one of the callback parameters. Patch 538528de0cb256f65716ab2e9613d9e920f97fe2 broke the desing. Change the callback to return the logical channel number and not chain_id. This patch does not make a material change. It merely changes the name used in a couple function pointer prototype. This has no impact on the generated code - iow, it's cosmetic. Yes it does look cosmetic but if you see the API signature, it corrects the callback parameters which actually the DMA lib sends. The current API signature is misleading for chained DMA transfers where the actual driver passes 'channel number' as one of the callback parameter instead of chain_id which was the original design. Here's this one with more descriptive comments. Thanks Tony !! Regards, Santosh -- 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/2] McSPI Slave and DMA,FIFO support
Hemanth, Signed-off-by: Hemanth V heman...@ti.com arch/arm/mach-omap2/devices.c |5 arch/arm/plat-omap/include/mach/mcspi.h | 16 + drivers/spi/omap2_mcspi.c | 343 drivers/spi/omap2_mcspi.c This should be separate patch since this has touching drivers directory. How about arranging this series [1/2]: OMAP platform specific changes ( arch/arm/plat-omap, arch/arm/mach-omap) [2/2]: Drivers specific (drivers/spi) Regards, Santosh -- 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/2] McSPI Slave and DMA,FIFO support
+ + /* SPI2 Pin MUX */ + omap_cfg_reg(AA3_3430_McSPI2_CLK); + omap_cfg_reg(Y2_3430_McSPI2_SIMO); + omap_cfg_reg(Y3_3430_McSPI2_SOMI); + omap_cfg_reg(Y4_3430_McSPI2_CS0); + This will still change the padconf for this port unconditionally. How do we handle the case where the same platform (SDP in this case) could have different configurations McSPI2 vs USBHOST2, etc? Is there a clean way, or do we have no option but to use a CONFIG option? How about boot_arg or in case usb is a loadable module then module argument ?-- 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: OMPA4: Basic boot patch series based on linux-omap
Tony, I have rebased this series on top of the 'for-next' branch (2.6.30-rc6) in linux-omap tree. Additionally the series is reorganized as you suggested. As discussed earlier, there is a dependency on arch/arm/tools/mach-types(dated:18/04/2009). [PATCH 1/4] ARM: OMAP4: Add minimal support for omap4 [PATCH 2/4] ARM: OMAP4: Clock stubs since clock management framework not in [PATCH 3/4] ARM: OMAP4: Add support for 4430 SDP [PATCH 4/4] ARM: OMAP4: Add defconfig for 4430 SDP Regards, Santosh -- 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
