[PATCH 0/2] omap_globals cleanup
Tony, Kevin, As discussed on off the list email, below two patches converts all the omap_globals to physical address and ioremap the space dynamically. Patches generated against the latest 2.6.33-rc5+ mainline kernel. Boot tested on OMAP4430SDP and OMAP3430SDP. I don't have OMAP2 board here :( The following changes since commit f6760aa024199cfbce564311dc4bc4d47b6fb349: Linus Torvalds (1): Merge branch 'timers-fixes-for-linus' of git://git.kernel.org/.../tip/linux-2.6-tip Santosh Shilimkar (2): OMAP2/3/4: Convert bases in omap_globals to physical address OMAP2/3/4: ioremap address space arch/arm/mach-omap2/control.c |6 +++- arch/arm/mach-omap2/id.c |7 - arch/arm/mach-omap2/prcm.c | 16 -- arch/arm/mach-omap2/sdrc.c | 11 +- arch/arm/plat-omap/common.c| 46 ++-- arch/arm/plat-omap/include/plat/common.h | 14 arch/arm/plat-omap/include/plat/omap24xx.h |2 + arch/arm/plat-omap/include/plat/omap34xx.h |1 + 8 files changed, 66 insertions(+), 37 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] OMAP2/3/4: ioremap address space
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Tuesday, January 26, 2010 9:16 PM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; Kevin Hilman
Subject: Re: [PATCH] OMAP2/3/4: ioremap address space
* Santosh Shilimkar santosh.shilim...@ti.com [100126 00:37]:
This patch update the sdrc, prcm, tap and control module to
allocate iospace dynamically
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/control.c |6 +-
arch/arm/mach-omap2/id.c |7 ++-
arch/arm/mach-omap2/prcm.c| 16 +---
arch/arm/mach-omap2/sdrc.c| 11 +--
4 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index cdd1f35..43f8a33 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -140,7 +140,11 @@ static struct omap3_control_regs control_context;
void __init omap2_set_globals_control(struct omap_globals *omap2_globals)
{
- omap2_ctrl_base = omap2_globals-ctrl;
+ /* Static mapping, never released */
+ if (omap2_globals-ctrl) {
+ omap2_ctrl_base = ioremap(omap2_globals-ctrl, SZ_4K);
+ WARN_ON(!omap2_ctrl_base);
+ }
}
void __iomem *omap_ctrl_base_get(void)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a091b53..fb5921b 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -407,7 +407,12 @@ void __init omap2_check_revision(void)
void __init omap2_set_globals_tap(struct omap_globals *omap2_globals)
{
omap_revision = omap2_globals-class;
- tap_base = omap2_globals-tap;
+
+ /* Static mapping, never released */
+ if (omap2_globals-tap) {
+ tap_base = ioremap(omap2_globals-tap, SZ_4K);
+ WARN_ON(!tap_base);
+ }
if (cpu_is_omap34xx())
tap_prod_id = 0x0210;
Nice clean-up.
We need to check carefully that the cpu detection is done by the time
we do the ioremap.. Initially we only know the machine class such as
34xx/24xx.
Machine class is good enough to select the correct omap_global descriptor.
Isn't it ?
We have at least cpu_is_omap2420 and cpu_is_omap2430 being used in io.c,
so all these mappings may not work properly.
Also, we should merge this as one patch to keep the system booting
between the patches.
Git bisect would be problem. We can merge them together.
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] OMAP2/3/4: ioremap address space
snip
void __iomem *omap_ctrl_base_get(void)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a091b53..fb5921b 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -407,7 +407,12 @@ void __init omap2_check_revision(void)
void __init omap2_set_globals_tap(struct omap_globals *omap2_globals)
{
omap_revision = omap2_globals-class;
- tap_base = omap2_globals-tap;
+
+ /* Static mapping, never released */
+ if (omap2_globals-tap) {
+ tap_base = ioremap(omap2_globals-tap, SZ_4K);
+ WARN_ON(!tap_base);
+ }
if (cpu_is_omap34xx())
tap_prod_id = 0x0210;
Nice clean-up.
We need to check carefully that the cpu detection is done by the time
we do the ioremap.. Initially we only know the machine class such as
34xx/24xx.
Machine class is good enough to select the correct omap_global descriptor.
Isn't it ?
We have at least cpu_is_omap2420 and cpu_is_omap2430 being used in io.c,
so all these mappings may not work properly.
Also, we should merge this as one patch to keep the system booting
between the patches.
Git bisect would be problem. We can merge them together.
Merged patch attached.
Regards,
Santosh
0001-OMAP2-3-4-ioremap-omap_globals-modules.patch
Description: 0001-OMAP2-3-4-ioremap-omap_globals-modules.patch
RE: [PATCH] OMAP: UART: fix full-fifo write abort
Thanks Tony.
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, January 27, 2010 11:03 PM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; Woodruff, Richard; Ghorai, Sukumar
Subject: Re: [PATCH] OMAP: UART: fix full-fifo write abort
* Santosh Shilimkar santosh.shilim...@ti.com [100127 02:34]:
This patch is addition to the already merged commit on non-empty
uart fifo read abort. ce13d4716a276f4331d78ba28a5093a63822ab95
OMAP3630 and OMAP4430 UART IP blocks have a restriction on TX FIFO
too. If you try to write to the tx fifo when it is full, the system aborts.
This can be easily reproducible by not suppressing interconnect errors or
long duartion testing where continous prints over console from multiple
threads . This patch is addressing the issue by ensuring that write is
not issued while fifo is full. A timeout is added to avoid any hang
on fifo-full for 10 mS which is unlikely case.
Patch is validated on OMAP3630 and OMAP4 SDP.
Can you do this as needed based on the FIFO interrupt?
Fifo-interrupt based case is already handled in generic driver.
Kernel prints will still use non-interrupt mode which can still create the
issue.
At least performance use cases like MODEM, BT can make use of DMA based UART
transfer
where this limitation won't be there.
Signed-off-by: Woodruff Richard r-woodru...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
CC: Ghorai Sukumar s-gho...@ti.com
---
arch/arm/mach-omap2/serial.c | 30 --
1 files changed, 28 insertions(+), 2 deletions(-)
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
snip
+static void serial_out_override(struct uart_port *up, int offset, int
value)
+{
+ unsigned int status, tmout = 1;
+
+ /* Wait up to 10ms for the character(s) to be sent. */
+ do {
+ status = __serial_read_reg(up, UART_LSR);
+ if (--tmout == 0)
+ break;
+ udelay(1);
+ } while (!(status UART_LSR_THRE));
+
+ __serial_write_reg(up, offset, value);
Do you really want to have a udelay on every TX?
How about:
status = __serial_read_reg(up, UART_LSR);
while (!(status UART_LSR_THRE)) {
if (--tmout == 0)
break;
udelay(1);
status = __serial_read_reg(up, UART_LSR);
}
__serial_write_reg(up, offset, value);
This is good. Will fix this.
--
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/3] OMAP4: Enable L2 cache
Tony, Here is the rebased series against 2.6.33-rc5 which adds L2 cache support on OMAP4430. I have dropped the l2 errata patch from earlier post [1] in this series since it will go through Russell's patch system. The link for patches is [2] The following changes since commit 92dcffb916d309aa01778bf8963a6932e4014d07: Linus Torvalds (1): Linux 2.6.33-rc5 Santosh Shilimkar (3): OMAP4: Add L2 Cache support OMAP4: Clean the secondary_data from L2 OMAP4: Enable L2 Cache arch/arm/configs/omap_4430sdp_defconfig|2 + arch/arm/mach-omap2/board-4430sdp.c| 33 arch/arm/mach-omap2/omap-smp.c |2 + arch/arm/mm/Kconfig|2 +- arch/arm/plat-omap/include/plat/omap44xx.h |1 + 5 files changed, 39 insertions(+), 1 deletions(-) Regards, Santosh [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg20553.html [2] http://www.spinics.net/lists/arm-kernel/msg81122.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/3] OMAP4: Enable L2 cache
Resending patches with numbers. -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Friday, January 29, 2010 5:01 PM To: Tony Lindgren Cc: Russell King; Catalin Marinas; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: [PATCH 0/3] OMAP4: Enable L2 cache Tony, Here is the rebased series against 2.6.33-rc5 which adds L2 cache support on OMAP4430. I have dropped the l2 errata patch from earlier post [1] in this series since it will go through Russell's patch system. The link for patches is [2] The following changes since commit 92dcffb916d309aa01778bf8963a6932e4014d07: Linus Torvalds (1): Linux 2.6.33-rc5 Santosh Shilimkar (3): OMAP4: Add L2 Cache support OMAP4: Clean the secondary_data from L2 OMAP4: Enable L2 Cache arch/arm/configs/omap_4430sdp_defconfig|2 + arch/arm/mach-omap2/board-4430sdp.c| 33 arch/arm/mach-omap2/omap-smp.c |2 + arch/arm/mm/Kconfig|2 +- arch/arm/plat-omap/include/plat/omap44xx.h |1 + 5 files changed, 39 insertions(+), 1 deletions(-) Regards, Santosh [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg20553.html [2] http://www.spinics.net/lists/arm-kernel/msg81122.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 -- 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/3] OMAP4: Add L2 Cache support
Thanks for quick comment.
-Original Message-
From: Catalin Marinas [mailto:catalin.mari...@arm.com]
Sent: Friday, January 29, 2010 5:46 PM
To: Shilimkar, Santosh
Cc: t...@atomide.com; linux-arm-ker...@lists.infradead.org;
r...@arm.linux.org.uk; linux-
o...@vger.kernel.org
Subject: Re: [PATCH 1/3] OMAP4: Add L2 Cache support
On Fri, 2010-01-29 at 11:46 +, Santosh Shilimkar wrote:
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -28,6 +28,7 @@
#include plat/control.h
#include plat/timer-gp.h
#include asm/hardware/gic.h
+#include asm/hardware/cache-l2x0.h
static struct platform_device sdp4430_lcd_device = {
.name = sdp4430_lcd,
@@ -49,6 +50,38 @@ static struct omap_lcd_config sdp4430_lcd_config
__initdata = {
static struct omap_board_config_kernel sdp4430_config[] __initdata = {
{ OMAP_TAG_LCD, sdp4430_lcd_config },
};
+#ifdef CONFIG_CACHE_L2X0
+static int __init omap_l2_cache_init(void)
+{
+ void __iomem *l2cache_base;
+
+ /* Static mapping, never released */
+ l2cache_base = ioremap(OMAP44XX_L2CACHE_BASE, SZ_4K);
+ BUG_ON(!l2cache_base);
+
+ /* Enable L2 Cache using secure api
+* r0 contains the value to be modified and r12 contains
+* the monitor API number. This API uses few CPU registers
+* internally and hence they need be backed up including
+* link register lr.
+*/
+ __asm__ __volatile__(
+ stmfd r13!, {r0-r12, r14}\n
+ mov r0, #1\n
+ ldr r12, =0x102\n
+ dsb\n
+ smc\n
+ ldmfd r13!, {r0-r12, r14});
Same comments as on the cache-l2x0.c changes - can you not let the
compiler choose what to saved by declaring the clobbered register in the
asm directive?
Since this code was used only ones in init, I haven't converted it to function.
With clobber list
as well as you know adding r12 to clobber list, compiler don't generate the
save code
and r11 can't be added to clobber list.
But I can do the same change as I did in the cache-l2x0.c Will send updated
version.
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/9] Initial multi-omap support for omap4
Hi all, These patches allow compiling in also omap4 into the multi-omap configuration. As I don't yet have omap4, I've only boot tested these on omap2 and omap3. Somebody with an omap4 board please boot test these with the omap3_defconfig and see what happens.. You might want to enable DEBUG_LL and EARLY_PRINTK with earlyprintk on the cmdline too. Looks like this series have some dependent series because it doesn't apply on mainline. So I tested this directly on linux-omap multi-omap4 branch. It boots sufficiently but doesn't proceed after brd_init. Didn't get much time to debug so attached log Stand alone omap_4430sdp_defconfig also didn't fully boot on the linux-omap multi-omap4. The log below shows that the serial platform data isn't configured correctly. 6io scheduler deadline registered 6io scheduler cfq registered (default) 6Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled 6serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 104) is a ST16654 6serial8250.1: ttyS0 at MMIO 0x4806a000 (irq = 105) is a ST16654 Below patch to fix the boot for omap_4430sdp_defconfig. Small typo really. diff --git a/arch/arm/plat-omap/include/plat/serial.h b/arch/arm/plat-omap/inclu index 67ffa08..83dce4c 100644 --- a/arch/arm/plat-omap/include/plat/serial.h +++ b/arch/arm/plat-omap/include/plat/serial.h @@ -33,7 +33,7 @@ /* OMAP4 serial ports */ #define OMAP4_UART1_BASE OMAP2_UART1_BASE -#define OMAP4_UART2_BASE OMAP2_UART1_BASE +#define OMAP4_UART2_BASE OMAP2_UART2_BASE #define OMAP4_UART3_BASE 0x4802 #define OMAP4_UART4_BASE 0x4806e000 For multi-omap build, for now I need to disable [*] Reset unused clocks during boot With this OMAP4430 boots with omap3_defconfig :) Regards, Santosh
RE: [PATCH 0/9] Initial multi-omap support for omap4
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Saturday, January 30, 2010 9:55 PM To: Shilimkar, Santosh Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 0/9] Initial multi-omap support for omap4 * Shilimkar, Santosh santosh.shilim...@ti.com [100130 04:49]: Hi all, These patches allow compiling in also omap4 into the multi-omap configuration. As I don't yet have omap4, I've only boot tested these on omap2 and omap3. Somebody with an omap4 board please boot test these with the omap3_defconfig and see what happens.. You might want to enable DEBUG_LL and EARLY_PRINTK with earlyprintk on the cmdline too. Looks like this series have some dependent series because it doesn't apply on mainline. So I tested this directly on linux-omap multi-omap4 branch. It boots sufficiently but doesn't proceed after brd_init. Didn't get much time to debug so attached log Stand alone omap_4430sdp_defconfig also didn't fully boot on the linux-omap multi-omap4. The log below shows that the serial platform data isn't configured correctly. 6io scheduler deadline registered 6io scheduler cfq registered (default) 6Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled 6serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 104) is a ST16654 6serial8250.1: ttyS0 at MMIO 0x4806a000 (irq = 105) is a ST16654 Below patch to fix the boot for omap_4430sdp_defconfig. Small typo really. diff --git a/arch/arm/plat-omap/include/plat/serial.h b/arch/arm/plat-omap/inclu index 67ffa08..83dce4c 100644 --- a/arch/arm/plat-omap/include/plat/serial.h +++ b/arch/arm/plat-omap/include/plat/serial.h @@ -33,7 +33,7 @@ /* OMAP4 serial ports */ #define OMAP4_UART1_BASE OMAP2_UART1_BASE -#define OMAP4_UART2_BASE OMAP2_UART1_BASE +#define OMAP4_UART2_BASE OMAP2_UART2_BASE #define OMAP4_UART3_BASE 0x4802 #define OMAP4_UART4_BASE 0x4806e000 Heh OK :) Sounds like at this point it makes sense to merge that into the original patch redo omap-for-linus partially. Can I also add your Acked-by for these patches then? Yes please. For multi-omap build, for now I need to disable [*] Reset unused clocks during boot Sounds like omap4 has some clocks left on from the bootloader that it should clk_get and clk_enable during init. That should be easy to track if you boot with debug in your cmdline and take a look at the list of unused clocks that are shut down with late_initcall. I know it hangs when it tries to cut down UART3 ( console) clock. The clock support got just recently merged and drivers are not yet migrated so, need to still depend on bootloader. The work is ongoing and soon the patches will be pushed. Few drivers are planned to be handled in hwmod way so we were holding these patches. With this OMAP4430 boots with omap3_defconfig :) Cool, thanks, good to hear! Now the only omap2/3/4 that's not booting with omap3_defconfig is 2430 because of the different clock offsets compare dot 2420. That should get fixed eventually though. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] OMAP4: Add L2 Cache support
Since this code was used only ones in init, I haven't converted it to
function. With clobber list as well as you know adding r12 to clobber
list, compiler don't generate the save code and r11 can't be added to
clobber list.
Well, we seem to have two places with the same code structure. Let's
pull them together into a common function, such as:
void omap_smc1(u32 fn, u32 arg)
{
register u32 r12 asm(r12) = fn;
register u32 r0 asm(r0) = arg;
asm volatile(
str r11, [sp], #-4\n
dsb\n
smc\n
ldr r11, [sp, #4]!
: +r (r0), +r (r12)
:
: r0-r10, lr, cc);
}
EXPORT_SYMBOL(omap_smc1);
The code there probably may not be Thumb-2 compatible.
I will re-arrange the series and sent combined the errata + l2 support
with above change since dependency.
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] cache-l2x0 and omap4 l2 support
Russell / Tony, Here is the series which combines earlier two series because of dependency and rebased against 2.6.33-rc2. This series also implements Russell's suggested combined monitor API. Tested on OMAP4430 SDP The following changes since commit abe94c756c08d50566c09a65b9c7fe72f83071c5: Linus Torvalds (1): Linux 2.6.33-rc6 Santosh Shilimkar (5): ARM: L2 : Add maintainace by line helper functions OMAP4: Add L2 Cache support OMAP4: Clean the secondary_data from L2 ARM: L2 : Errata 588369: Clean Invalidate do not invalidate clean lines OMAP4: Enable L2 Cache arch/arm/Kconfig | 13 + arch/arm/configs/omap_4430sdp_defconfig|3 + arch/arm/mach-omap2/board-4430sdp.c| 53 + arch/arm/mach-omap2/omap-smp.c |2 + arch/arm/mm/Kconfig|2 +- arch/arm/mm/cache-l2x0.c | 71 arch/arm/plat-omap/include/plat/omap44xx.h |1 + 7 files changed, 134 insertions(+), 11 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 4/5] ARM: L2 : Errata 588369: Clean Invalidate do not invalidate clean lines
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Thursday, February 04, 2010 8:13 PM
To: Shilimkar, Santosh
Cc: t...@atomide.com; Woodruff, Richard; catalin.mari...@arm.com; linux-arm-
ker...@lists.infradead.org; linux-omap@vger.kernel.org
Subject: Re: [PATCH 4/5] ARM: L2 : Errata 588369: Clean Invalidate do not
invalidate clean lines
On Thu, Feb 04, 2010 at 07:55:46PM +0530, Santosh Shilimkar wrote:
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 1a14d18..6241f10 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -56,12 +56,41 @@ static inline void l2x0_inv_line(unsigned long addr)
writel(addr, base + L2X0_INV_LINE_PA);
}
+#ifdef CONFIG_PL310_ERRATA_588369
+extern void omap_smc1(u32 fn, u32 arg);
+static void debug_writel(unsigned long val)
+{
You could move the external declaration into this function, thereby
making it entirely local to this function (and hiding it from the
file scope.)
OK
--
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] cache-l2x0 and omap4 l2 support
Tony, -Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Thursday, February 04, 2010 8:14 PM To: Shilimkar, Santosh Cc: Tony Lindgren; Catalin Marinas; linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 0/5] cache-l2x0 and omap4 l2 support On Thu, Feb 04, 2010 at 07:52:52PM +0530, Shilimkar, Santosh wrote: Russell / Tony, Here is the series which combines earlier two series because of dependency and rebased against 2.6.33-rc2. This series also implements Russell's suggested combined monitor API. Tested on OMAP4430 SDP If you fix up those two patches, I think it can to into the patch system when some acks have been received. Can you check this series and provide your ack. Will you be ok if this series gets merged through Russell's patch system ? 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 v2] OMAP: UART: fix full-fifo write abort
Tony,
Can this be merged now in linux-omap ?
-Original Message-
From: Shilimkar, Santosh
Sent: Friday, January 29, 2010 3:58 PM
To: t...@atomide.com
Cc: linux-omap@vger.kernel.org; Shilimkar, Santosh; Woodruff, Richard;
Ghorai, Sukumar
Subject: [PATCH v2] OMAP: UART: fix full-fifo write abort
This patch is addition to the already merged commit on non-empty
uart fifo read abort. ce13d4716a276f4331d78ba28a5093a63822ab95
OMAP3630 and OMAP4430 UART IP blocks have a restriction on TX FIFO
too. If you try to write to the tx fifo when it is full, the system aborts.
This can be easily reproducible by not suppressing interconnect errors or
long duration testing where continuous prints over console from multiple
threads. This patch is addressing the issue by ensuring that write is
not issued while fifo is full. A timeout is added to avoid any hang
on fifo-full for 10 mS which is unlikely case.
Patch is validated on OMAP3630 and OMAP4 SDP.
V2 version removed the additional 1 uS on every TX as per
Tony's suggestion
Signed-off-by: Woodruff Richard r-woodru...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
CC: Ghorai Sukumar s-gho...@ti.com
---
arch/arm/mach-omap2/serial.c | 30 --
1 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 8c964be..324928d 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -23,6 +23,7 @@
#include linux/serial_reg.h
#include linux/clk.h
#include linux/io.h
+#include linux/delay.h
#include plat/common.h
#include plat/board.h
@@ -139,6 +140,13 @@ static inline unsigned int serial_read_reg(struct
plat_serial8250_port *up,
return (unsigned int)__raw_readb(up-membase + offset);
}
+static inline void __serial_write_reg(struct uart_port *up, int offset,
+ int value)
+{
+ offset = up-regshift;
+ __raw_writeb(value, up-membase + offset);
+}
+
static inline void serial_write_reg(struct plat_serial8250_port *p, int
offset,
int value)
{
@@ -598,6 +606,20 @@ static unsigned int serial_in_override(struct uart_port
*up, int offset)
return __serial_read_reg(up, offset);
}
+static void serial_out_override(struct uart_port *up, int offset, int value)
+{
+ unsigned int status, tmout = 1;
+
+ status = __serial_read_reg(up, UART_LSR);
+ while (!(status UART_LSR_THRE)) {
+ /* Wait up to 10ms for the character(s) to be sent. */
+ if (--tmout == 0)
+ break;
+ udelay(1);
+ status = __serial_read_reg(up, UART_LSR);
+ }
+ __serial_write_reg(up, offset, value);
+}
void __init omap_serial_early_init(void)
{
int i;
@@ -698,11 +720,15 @@ void __init omap_serial_init_port(int port)
* omap3xxx: Never read empty UART fifo on UARTs
* with IP rev =0x52
*/
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
uart-p-serial_in = serial_in_override;
+ uart-p-serial_out = serial_out_override;
+ }
else if ((serial_read_reg(uart-p, UART_OMAP_MVER) 0xFF)
- = UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
+ = UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV) {
uart-p-serial_in = serial_in_override;
+ uart-p-serial_out = serial_out_override;
+ }
}
/**
--
1.6.0.4
--
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] OMAP2/3/4: ioremap address space
Tony,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh
Sent: Wednesday, January 27, 2010 11:14 AM
To: Tony Lindgren
Cc: linux-omap@vger.kernel.org; Kevin Hilman
Subject: RE: [PATCH] OMAP2/3/4: ioremap address space
snip
void __iomem *omap_ctrl_base_get(void)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a091b53..fb5921b 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -407,7 +407,12 @@ void __init omap2_check_revision(void)
void __init omap2_set_globals_tap(struct omap_globals *omap2_globals)
{
omap_revision = omap2_globals-class;
- tap_base = omap2_globals-tap;
+
+ /* Static mapping, never released */
+ if (omap2_globals-tap) {
+ tap_base = ioremap(omap2_globals-tap, SZ_4K);
+ WARN_ON(!tap_base);
+ }
if (cpu_is_omap34xx())
tap_prod_id = 0x0210;
Nice clean-up.
We need to check carefully that the cpu detection is done by the time
we do the ioremap.. Initially we only know the machine class such as
34xx/24xx.
Machine class is good enough to select the correct omap_global descriptor.
Isn't it ?
We have at least cpu_is_omap2420 and cpu_is_omap2430 being used in io.c,
so all these mappings may not work properly.
Also, we should merge this as one patch to keep the system booting
between the patches.
Git bisect would be problem. We can merge them together.
Merged patch attached.
How do we proceed with this? I can test this patch with omap3_defconfig and see
if
the Image works on OMAP3430, OMAP3630 and OMAP4430 SDPs.
Please suggest.
Regards,
Santosh
0001-OMAP2-3-4-ioremap-omap_globals-modules.patch
Description: 0001-OMAP2-3-4-ioremap-omap_globals-modules.patch
RE: [PATCH] OMAP2/3/4: ioremap address space
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, February 05, 2010 3:21 AM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; Kevin Hilman
Subject: Re: [PATCH] OMAP2/3/4: ioremap address space
* Shilimkar, Santosh santosh.shilim...@ti.com [100204 11:45]:
Tony,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Shilimkar, Santosh
Sent: Wednesday, January 27, 2010 11:14 AM
To: Tony Lindgren
Cc: linux-omap@vger.kernel.org; Kevin Hilman
Subject: RE: [PATCH] OMAP2/3/4: ioremap address space
snip
void __iomem *omap_ctrl_base_get(void)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a091b53..fb5921b 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -407,7 +407,12 @@ void __init omap2_check_revision(void)
void __init omap2_set_globals_tap(struct omap_globals *omap2_globals)
{
omap_revision = omap2_globals-class;
- tap_base = omap2_globals-tap;
+
+ /* Static mapping, never released */
+ if (omap2_globals-tap) {
+ tap_base = ioremap(omap2_globals-tap, SZ_4K);
+ WARN_ON(!tap_base);
+ }
if (cpu_is_omap34xx())
tap_prod_id = 0x0210;
Nice clean-up.
We need to check carefully that the cpu detection is done by the time
we do the ioremap.. Initially we only know the machine class such as
34xx/24xx.
Machine class is good enough to select the correct omap_global descriptor.
Yeah but ioremap uses cpu_is_omap2420() and cpu_is_omap2430(), so we can't
use that for setting tap_base. Basically ioremap() won't work in this
case until omap2_check_revision() is done.
I _think_ the others are safe..
You are correct.
Isn't it ?
We have at least cpu_is_omap2420 and cpu_is_omap2430 being used in io.c,
so all these mappings may not work properly.
Also, we should merge this as one patch to keep the system booting
between the patches.
Git bisect would be problem. We can merge them together.
Merged patch attached.
How do we proceed with this? I can test this patch with omap3_defconfig and
see if
the Image works on OMAP3430, OMAP3630 and OMAP4430 SDPs.
How about leave tap changes from this patcht, and ioremap the rest?
Then let's try it out in l-o master for next few weeks and then merge
it assuming things are OK.
Sound good to me. Will spin the new version with this and post.
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] OMAP2/3/4: ioremap address space
Tony,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Shilimkar, Santosh
Sent: Friday, February 05, 2010 11:02 AM
To: Tony Lindgren
Cc: linux-omap@vger.kernel.org; Kevin Hilman
Subject: RE: [PATCH] OMAP2/3/4: ioremap address space
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, February 05, 2010 3:21 AM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; Kevin Hilman
Subject: Re: [PATCH] OMAP2/3/4: ioremap address space
* Shilimkar, Santosh santosh.shilim...@ti.com [100204 11:45]:
Tony,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Shilimkar, Santosh
Sent: Wednesday, January 27, 2010 11:14 AM
To: Tony Lindgren
Cc: linux-omap@vger.kernel.org; Kevin Hilman
Subject: RE: [PATCH] OMAP2/3/4: ioremap address space
snip
void __iomem *omap_ctrl_base_get(void)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a091b53..fb5921b 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -407,7 +407,12 @@ void __init omap2_check_revision(void)
void __init omap2_set_globals_tap(struct omap_globals
*omap2_globals)
{
omap_revision = omap2_globals-class;
- tap_base = omap2_globals-tap;
+
+ /* Static mapping, never released */
+ if (omap2_globals-tap) {
+ tap_base = ioremap(omap2_globals-tap, SZ_4K);
+ WARN_ON(!tap_base);
+ }
if (cpu_is_omap34xx())
tap_prod_id = 0x0210;
Nice clean-up.
We need to check carefully that the cpu detection is done by the time
we do the ioremap.. Initially we only know the machine class such as
34xx/24xx.
Machine class is good enough to select the correct omap_global
descriptor.
Yeah but ioremap uses cpu_is_omap2420() and cpu_is_omap2430(), so we can't
use that for setting tap_base. Basically ioremap() won't work in this
case until omap2_check_revision() is done.
I _think_ the others are safe..
You are correct.
Isn't it ?
We have at least cpu_is_omap2420 and cpu_is_omap2430 being used in
io.c,
so all these mappings may not work properly.
Also, we should merge this as one patch to keep the system booting
between the patches.
Git bisect would be problem. We can merge them together.
Merged patch attached.
How do we proceed with this? I can test this patch with omap3_defconfig
and see if
the Image works on OMAP3430, OMAP3630 and OMAP4430 SDPs.
How about leave tap changes from this patcht, and ioremap the rest?
Then let's try it out in l-o master for next few weeks and then merge
it assuming things are OK.
Sound good to me. Will spin the new version with this and post.
Attached version generated against mainline with tap changes is dropped tested
on
OMAP3430 and OMAP4430 SDP
A slightly modified version because of recent uart changes also attached
Tested with linux-omap multi-omap(omap3_defconfig) build on OMAP4430 and
OMAP3430 SDP.
Regards,
Santosh
0001-V2-OMAP2-3-4-ioremap-omap_globals-modules.patch
Description: 0001-V2-OMAP2-3-4-ioremap-omap_globals-modules.patch
0001-multi-omap4-OMAP2-3-4-ioremap-omap_globals-modules.patch
Description: 0001-multi-omap4-OMAP2-3-4-ioremap-omap_globals-modules.patch
[PATCH 0/24] omap4 for 2.6.34
Tony, Here are some patches towards upcoming 34 merge window. They are generated against linux-omap master as you suggested. I am also copying Ben, Samuel, Liam, Paul and Kevin since some of the changes are in mfd, regulator, i2c and clocks. The series enables most of the core driver like WDT, RTC, McBSP, Regulator, UART,DMA and I2C on omap4 platform. This series also has few fixes towards multi-omap build. It would be nice development platform for upcoming peripheral drivers like MMC, Keyboard, Ethernet, DSS, touch screen, audio etc. The series is boot tested with multi-omap build (omap3_defconfig) on omap3430 sdp and omap4430 sdp. Also regular omap_4430sdp_defconfig and omap_3430sdp_defconfig boot tested. The following changes since commit 301f2e037b161c79bf12f4194501c9ff9c12ced3: Tony Lindgren (1): Linux-omap rebuilt: dss board changes merged Abhijit Pagare (3): omap4: clocks: Make Uart driver's clock calls OMAP4 compatible omap4: clokcs: Make gpio driver's clock calls OMAP4 compatible omap4: clocks: Make i2c driver's clock calls OMAP4 compatible Balaji T K (4): twl6030: add base addr for ID0, ID1, ID2 omap4: add i2c1 peripherals data omap4: add regulator board data for TWL6030 omap4: Enable RTC and regulator support Rajendra Nayak (1): twl6030: Fix vsel calculations in set/get voltage api's Santosh Shilimkar (16): omap 3/4: uart: fix full-fifo write abort omap2/3/4: ioremap omap_globals module omap4: sdma: Enable the idle modes on omap4 omap: sdma: Limit the secure reserve channel fix for omap3 omap4: Add needed IRQ line into irqs.h omap4: Fix omap_type() for omap4 omap 3/4: Remove overlapping mapping of L4_WKUP io space omap4: clocks: Make mcbsp driver's clock calls OMAP4 compatible omap4: clocks: Make watchdog driver's clock calls OMAP4 compatible omap4: clocks: Make dmtimer clocks calls OMAP4 compatible omap4: clocks: Remove clock hacks from timer-gp.c omap4: Enable WDT and McBSP support omap4: clocks: Convert i2c clocks data to fclks omap4: Add i2c support on omap4 platform omap4: Add i2c board support for omap4 platform omap4: multi-omap: Allow build to work arch/arm/configs/omap_4430sdp_defconfig | 46 ++- arch/arm/mach-omap2/board-4430sdp.c | 186 + arch/arm/mach-omap2/clock44xx_data.c |8 +- arch/arm/mach-omap2/control.c |6 +- arch/arm/mach-omap2/id.c |2 + arch/arm/mach-omap2/io.c | 12 -- arch/arm/mach-omap2/prcm.c| 16 ++- arch/arm/mach-omap2/sdrc.c| 11 ++- arch/arm/mach-omap2/serial.c | 55 +++-- arch/arm/mach-omap2/timer-gp.c|5 - arch/arm/plat-omap/common.c | 38 +++--- arch/arm/plat-omap/dma.c |5 +- arch/arm/plat-omap/dmtimer.c | 25 +++- arch/arm/plat-omap/gpio.c |7 +- arch/arm/plat-omap/i2c.c | 17 ++- arch/arm/plat-omap/include/plat/common.h | 12 +- arch/arm/plat-omap/include/plat/control.h |3 + arch/arm/plat-omap/include/plat/io.h |9 -- arch/arm/plat-omap/include/plat/irqs.h|5 + arch/arm/plat-omap/io.c |4 - arch/arm/plat-omap/mcbsp.c| 13 ++- drivers/i2c/busses/i2c-omap.c | 169 -- drivers/mfd/twl-core.c|7 +- drivers/regulator/twl-regulator.c | 23 +++- drivers/usb/musb/musb_core.c |4 + drivers/watchdog/Kconfig |6 +- drivers/watchdog/omap_wdt.c | 39 -- include/linux/i2c/twl.h |5 + 28 files changed, 576 insertions(+), 162 deletions(-) Regards, Santsoh -- 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/24] omap4 for 2.6.34
Resending with correct patch numbers. -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Tuesday, February 16, 2010 9:06 PM To: Tony Lindgren Cc: Ben Dooks; Samuel Ortiz; Kevin Hilman; Paul Walmsley; l...@slimlogic.co.uk; linux- o...@vger.kernel.org Subject: [PATCH 0/24] omap4 for 2.6.34 Tony, Here are some patches towards upcoming 34 merge window. They are generated against linux-omap master as you suggested. I am also copying Ben, Samuel, Liam, Paul and Kevin since some of the changes are in mfd, regulator, i2c and clocks. The series enables most of the core driver like WDT, RTC, McBSP, Regulator, UART,DMA and I2C on omap4 platform. This series also has few fixes towards multi-omap build. It would be nice development platform for upcoming peripheral drivers like MMC, Keyboard, Ethernet, DSS, touch screen, audio etc. The series is boot tested with multi-omap build (omap3_defconfig) on omap3430 sdp and omap4430 sdp. Also regular omap_4430sdp_defconfig and omap_3430sdp_defconfig boot tested. The following changes since commit 301f2e037b161c79bf12f4194501c9ff9c12ced3: Tony Lindgren (1): Linux-omap rebuilt: dss board changes merged Abhijit Pagare (3): omap4: clocks: Make Uart driver's clock calls OMAP4 compatible omap4: clokcs: Make gpio driver's clock calls OMAP4 compatible omap4: clocks: Make i2c driver's clock calls OMAP4 compatible Balaji T K (4): twl6030: add base addr for ID0, ID1, ID2 omap4: add i2c1 peripherals data omap4: add regulator board data for TWL6030 omap4: Enable RTC and regulator support Rajendra Nayak (1): twl6030: Fix vsel calculations in set/get voltage api's Santosh Shilimkar (16): omap 3/4: uart: fix full-fifo write abort omap2/3/4: ioremap omap_globals module omap4: sdma: Enable the idle modes on omap4 omap: sdma: Limit the secure reserve channel fix for omap3 omap4: Add needed IRQ line into irqs.h omap4: Fix omap_type() for omap4 omap 3/4: Remove overlapping mapping of L4_WKUP io space omap4: clocks: Make mcbsp driver's clock calls OMAP4 compatible omap4: clocks: Make watchdog driver's clock calls OMAP4 compatible omap4: clocks: Make dmtimer clocks calls OMAP4 compatible omap4: clocks: Remove clock hacks from timer-gp.c omap4: Enable WDT and McBSP support omap4: clocks: Convert i2c clocks data to fclks omap4: Add i2c support on omap4 platform omap4: Add i2c board support for omap4 platform omap4: multi-omap: Allow build to work arch/arm/configs/omap_4430sdp_defconfig | 46 ++- arch/arm/mach-omap2/board-4430sdp.c | 186 + arch/arm/mach-omap2/clock44xx_data.c |8 +- arch/arm/mach-omap2/control.c |6 +- arch/arm/mach-omap2/id.c |2 + arch/arm/mach-omap2/io.c | 12 -- arch/arm/mach-omap2/prcm.c| 16 ++- arch/arm/mach-omap2/sdrc.c| 11 ++- arch/arm/mach-omap2/serial.c | 55 +++-- arch/arm/mach-omap2/timer-gp.c|5 - arch/arm/plat-omap/common.c | 38 +++--- arch/arm/plat-omap/dma.c |5 +- arch/arm/plat-omap/dmtimer.c | 25 +++- arch/arm/plat-omap/gpio.c |7 +- arch/arm/plat-omap/i2c.c | 17 ++- arch/arm/plat-omap/include/plat/common.h | 12 +- arch/arm/plat-omap/include/plat/control.h |3 + arch/arm/plat-omap/include/plat/io.h |9 -- arch/arm/plat-omap/include/plat/irqs.h|5 + arch/arm/plat-omap/io.c |4 - arch/arm/plat-omap/mcbsp.c| 13 ++- drivers/i2c/busses/i2c-omap.c | 169 -- drivers/mfd/twl-core.c|7 +- drivers/regulator/twl-regulator.c | 23 +++- drivers/usb/musb/musb_core.c |4 + drivers/watchdog/Kconfig |6 +- drivers/watchdog/omap_wdt.c | 39 -- include/linux/i2c/twl.h |5 + 28 files changed, 576 insertions(+), 162 deletions(-) Regards, Santsoh -- 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 24/24] omap4: multi-omap: Allow build to work
Anand, -Original Message- From: Gadiyar, Anand Sent: Tuesday, February 16, 2010 9:25 PM To: Shilimkar, Santosh; t...@atomide.com Cc: linux-omap@vger.kernel.org; b...@fluff.org.uk; sa...@linux.intel.com; l...@slimlogic.co.uk; p...@pwsan.com Subject: RE: [PATCH] omap4: multi-omap: Allow build to work Shilimkar, Santosh wrote: The musb support is enable to omap3 platforms. For omap4 only board support is available and the driver still isn't supported. Because of this build with omap3_defconfig used for multi-omap doesn't work on omap4430 sdp. This patch hacks the musb probe to keep the multi-omap build working on omap4430 sdp Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- drivers/usb/musb/musb_core.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index bcce8e8..13b1c4a 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -2124,6 +2124,10 @@ static int __init musb_probe(struct platform_device *pdev) struct resource *iomem; void __iomem*base; + /* FIXME: multi-omap build to work on omap4 */ + if (cpu_is_omap44xx()) + return 0; + NAK. I'd prefer that we fix the driver issue correctly. I would have expected the driver to at least load on OMAP4 even if it does not work. Could you please describe the failure? The probe fails because the register bases aren't mapped for omap4. This is because Tony has lined-up musb board support for omap4 but corresponding usb driver patches are not yet lined up. Also, this will need to go through linux-usb. -- 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 05/24] omap4: Add needed IRQ line into irqs.h
Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, February 17, 2010 3:39 AM To: Shilimkar, Santosh Cc: t...@atomide.com; linux-omap@vger.kernel.org; b...@fluff.org.uk; sa...@linux.intel.com; l...@slimlogic.co.uk Subject: Re: [PATCH 05/24] omap4: Add needed IRQ line into irqs.h Hello Santosh, On Tue, 16 Feb 2010, Santosh Shilimkar wrote: This patch adds DSS, keyboard and ducati irq entries in irqs.h Ones omap4 hwmod is pushed on mainlie, all the irqs lines data would be availabe. Instead of this patch, why not just replace the current file with the one from the OMAP4 autogeneration scripts? I don't see why the IRQ macros should depend on hwmod availability, and it would be better to have the correct IRQ data appear in one patch, rather than having to review and approve several smaller incremental patches over time. We plan to do this but today the autogenrated file names and one in the kernel code is different. Autogenrated headers are kept in alignment with TRM naming as you know. e.g --- autogenaretd #define OMAP44XX_IRQ_MCBSP2 (22 + OMAP44XX_IRQ_GIC_START) --existing kernel #define INT_44XX_MCBSP2_IRQ (22 + IRQ_GIC_START) So instead of touching every driver file and changing it only for name changes , what we are doing 1. Created local 44xx_dma.h and 44xx_irq.h mach-omap2 directory 2. All the drivers getting converted in hwmods would use defines from above headers 3. At one point of time all the drivers would use defines from above headers and then from omap4 point of view there won't be dependency on the irqs.h and dma.h While this is ongoing, we would like the mainline kernel to have most of the drivers supported. And Hence such a patch. The same reasoning should apply the DMA data also, I'd think. DMA file will get replaced soon with auto generated since naming is aligned there. 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 13/24] omap4: clocks: Remove clock hacks from timer-gp.c
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Wednesday, February 17, 2010 12:12 AM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org; b...@fluff.org.uk; sa...@linux.intel.com; l...@slimlogic.co.uk; p...@pwsan.com Subject: Re: [PATCH 13/24] omap4: clocks: Remove clock hacks from timer-gp.c * Santosh Shilimkar santosh.shilim...@ti.com [100216 07:55]: Now the omap4 clock framework is mainline and clk_get_rate() is functional. Hence reomve the hardcoded clock hacks. Should we send this as a fix for 2.6.33, or does this depend on other patches not yet in 2.6.33? This needs the gptimer clocks updates in dmtimer. Regards, Tony This patch also fixes Division by zero in kernel. Backtrace: [c0025fb8] (dump_backtrace+0x0/0x110) from [c017febc] (dump_stack+0x18/0x1c) r7:6093 r6:c0641050 r5:c0223e78 r4:c02126b4 [c017fea4] (dump_stack+0x0/0x1c) from [c00260fc] (__div0+0x18/0x20) [c00260e4] (__div0+0x0/0x20) from [c01431fc] (Ldiv0+0x8/0x10) [c00318d4] (omap_dm_timer_stop+0x0/0xb0) from [c002c148] (omap2_gp_timer_set_mode+0x1c/0x68) r5:c0223e78 r4: [c002c12c] (omap2_gp_timer_set_mode+0x0/0x68) from [c0063270] (clockevents_set_mode+0x30/0x64) r5:c020cae0 r4: [c0063240] (clockevents_set_mode+0x0/0x64) from [c00632fc] (clockevents_exchange_device+0x30/0x9c) r5:c020cae0 r4:c02146e0 [c00632cc] (clockevents_exchange_device+0x0/0x9c) from [c00636e0] (tick_notify+0x17c/0x404) r7: r6:c0641050 r5: r4:c020cae0 [c0063564] (tick_notify+0x0/0x404) from [c005d5fc] (notifier_call_chain+0x34/0x78) [c005d5c8] (notifier_call_chain+0x0/0x78) from [c005d684] (__raw_notifier_call_chain+0x1c/0x24) [c005d668] (__raw_notifier_call_chain+0x0/0x24) from [c005d6ac] (raw_notifier_call_chain+0x20/0x28) [c005d68c] (raw_notifier_call_chain+0x0/0x28) from [c0062e78] (clockevents_do_notify+0x1c/0x24) [c0062e5c] (clockevents_do_notify+0x0/0x24) from [c0062f18] (clockevents_register_device+0x98/0xd0) [c0062e80] (clockevents_register_device+0x0/0xd0) from [c001a194] (percpu_timer_setup+0x80/0x9c) r7: r6:0002 r5:0002 r4:0003 [c001a114] (percpu_timer_setup+0x0/0x9c) from [c000e9f0] (smp_prepare_cpus+0xb0/0xe8) [c000e940] (smp_prepare_cpus+0x0/0xe8) from [c00084e8] (kernel_init+0x5c/0x1fc) r7: r6: r5: r4:c001b8a4 [c000848c] (kernel_init+0x0/0x1fc) from [c0046c50] (do_exit+0x0/0x604) r7: r6: r5: r4: Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/timer-gp.c |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c index cd04dea..74fbed8 100644 --- a/arch/arm/mach-omap2/timer-gp.c +++ b/arch/arm/mach-omap2/timer-gp.c @@ -85,8 +85,6 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode mode, case CLOCK_EVT_MODE_PERIODIC: period = clk_get_rate(omap_dm_timer_get_fclk(gptimer)) / HZ; period -= 1; - if (cpu_is_omap44xx()) - period = 0xff; /* FIXME: */ omap_dm_timer_set_load_start(gptimer, 1, 0x - period); break; case CLOCK_EVT_MODE_ONESHOT: @@ -150,9 +148,6 @@ static void __init omap2_gp_clockevent_init(void) timer-gp: omap_dm_timer_set_source() failed\n); tick_rate = clk_get_rate(omap_dm_timer_get_fclk(gptimer)); - if (cpu_is_omap44xx()) - /* Assuming 32kHz clk is driving GPT1 */ - tick_rate = 32768; /* FIXME: */ pr_info(OMAP clockevent source: GPTIMER%d at %u Hz\n, gptimer_id, tick_rate); -- 1.6.0.4 -- 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 16/24] omap4: Add i2c support on omap4 platform
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, February 17, 2010 12:21 AM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; b...@fluff.org.uk; sa...@linux.intel.com;
l...@slimlogic.co.uk;
p...@pwsan.com; Syed, Rafiuddin; Ben Dooks
Subject: Re: [PATCH 16/24] omap4: Add i2c support on omap4 platform
* Santosh Shilimkar santosh.shilim...@ti.com [100216 07:55]:
This patch is rebased version of earlier post to add I2C
driver support to OMAP4 platform. On OMAP4, all
I2C register address offsets are changed from OMAP1/2/3 I2C.
In order to not have #ifdef's at various places in code,
as well as to support multi-OMAP build, an array is created
to hold the register addresses with it's offset.
This patch was submitted, reviewed and acked on mailing list
already. For more details refer below link
http://www.mail-archive.com/linux-...@vger.kernel.org/msg02281.html
This version updated on top of 16 bit support added as part of
the commit 8bb209278e555a626f9637e844fe4c1b90e849f6
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
CC: Tony Lindgren t...@atomide.com
CC: Ben Dooks ben-li...@fluff.org
---
arch/arm/plat-omap/i2c.c | 17 -
drivers/i2c/busses/i2c-omap.c | 148
-
2 files changed, 131 insertions(+), 34 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 96d2781..f18d757 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -53,9 +53,15 @@ static struct resource i2c_resources[][2] = {
#ifdefined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
{ I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE2, INT_24XX_I2C2_IRQ) },
#endif
+#ifdefined(CONFIG_ARCH_OMAP4)
+ { I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE2, INT_44XX_I2C2_IRQ) },
+#endif
#ifdefined(CONFIG_ARCH_OMAP3)
{ I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE3, INT_34XX_I2C3_IRQ) },
#endif
+#ifdefined(CONFIG_ARCH_OMAP4)
+ { I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE3, INT_44XX_I2C3_IRQ) },
+#endif
};
This is OK, but..
#define I2C_DEV_BUILDER(bus_id, res, data) \
@@ -72,10 +78,11 @@ static struct resource i2c_resources[][2] = {
static u32 i2c_rate[ARRAY_SIZE(i2c_resources)];
static struct platform_device omap_i2c_devices[] = {
I2C_DEV_BUILDER(1, i2c_resources[0], i2c_rate[0]),
-#ifdefined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
+#ifdefined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) || \
+ defined(CONFIG_ARCH_OMAP4)
I2C_DEV_BUILDER(2, i2c_resources[1], i2c_rate[1]),
#endif
-#ifdefined(CONFIG_ARCH_OMAP3)
+#ifdefined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
I2C_DEV_BUILDER(3, i2c_resources[2], i2c_rate[2]),
#endif
};
.. the ifdefs above can be simplified to ifdef CONFIG_ARCH_OMAP2PLUS.
That is, with the patches already queued into omap for-next.
YEP
@@ -370,7 +434,11 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
internal_clk = 9600;
else
internal_clk = 4000;
- fclk_rate = clk_get_rate(dev-fclk) / 1000;
+ /* FIXME: Remove this once clock framework is available*/
+ if (dev-rev = OMAP_I2C_REV_ON_4430)
+ fclk_rate = 96000;
+ else
+ fclk_rate = clk_get_rate(dev-fclk) / 1000;
/* Compute prescaler divisor */
psc = fclk_rate / internal_clk;
Sounds like this part should no longer be needed?
Yes. I missed this
*dev-buf++ = w;
dev-buf_len--;
- /* Data reg from 2430 is 8 bit wide */
+ /* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
if (!cpu_is_omap2430()
- !cpu_is_omap34xx()) {
+ !cpu_is_omap34xx()
+ !cpu_is_omap44xx()) {
if (dev-buf_len) {
*dev-buf++ = w 8;
dev-buf_len--;
How about change this to if (cpu_class_is_omap1() || cpu_is_omap2420())?
That way it does not need to be patched for new omaps.
@@ -786,9 +857,12 @@ complete:
if (dev-buf_len) {
w = *dev-buf++;
dev-buf_len
RE: [PATCH 24/24] omap4: multi-omap: Allow build to work
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Wednesday, February 17, 2010 12:24 AM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org; b...@fluff.org.uk; sa...@linux.intel.com; l...@slimlogic.co.uk; p...@pwsan.com Subject: Re: [PATCH 24/24] omap4: multi-omap: Allow build to work * Santosh Shilimkar santosh.shilim...@ti.com [100216 07:55]: The musb support is enable to omap3 platforms. For omap4 only board support is available and the driver still isn't supported. Because of this build with omap3_defconfig used for multi-omap doesn't work on omap4430 sdp. This patch hacks the musb probe to keep the multi-omap build working on omap4430 sdp Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- drivers/usb/musb/musb_core.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index bcce8e8..13b1c4a 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -2124,6 +2124,10 @@ static int __init musb_probe(struct platform_device *pdev) struct resource *iomem; void __iomem*base; + /* FIXME: multi-omap build to work on omap4 */ + if (cpu_is_omap44xx()) + return 0; + iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!iomem || irq == 0) return -ENODEV; Should the comment here be FIXME: allow multi-omap to boot until musb is updated for omap4 instead? yeah -- 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/24] omap4 for 2.6.34
Tony, -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Wednesday, February 17, 2010 12:33 AM To: Shilimkar, Santosh Cc: Ben Dooks; Samuel Ortiz; Kevin Hilman; Paul Walmsley; l...@slimlogic.co.uk; linux- o...@vger.kernel.org Subject: Re: [PATCH 0/24] omap4 for 2.6.34 Hi, * Shilimkar, Santosh santosh.shilim...@ti.com [100216 07:33]: Tony, Here are some patches towards upcoming 34 merge window. They are generated against linux-omap master as you suggested. I am also copying Ben, Samuel, Liam, Paul and Kevin since some of the changes are in mfd, regulator, i2c and clocks. Thanks. Can you please split this into several smaller sets? 1. Core omap changes done against linux-omap master branch Send to linux-omap list with linux-arm-kernel Cc'd. ok 2. Clock framework dummy_ck changes done against linux-omap master branch. This should leave out most of the driver changes in your series. Send to linux-omap list with linux-arm-kernel Cc'd. Will do. Some clock node names are changed and since we do clk_get based on clock node names, such drivers need to change. 3. I2C changes against done against 2.6.33-rc8 + Add support for 16-bit registers Send to Ben and i2c list with linux-omap list Cc'd. ok 4. MFD changes done against 2.6.33-rc8 Send to Samuel with linux-omap list Cc'd. Sounds good. I sent this series just to ensure that we all are aligned on dependancies and also just to highlight that all of these should get merged together. Thanks for feedback. 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 16/24] omap4: Add i2c support on omap4 platform
Thanks Paul, I am just summarizing all my responses in this email. snip -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, February 17, 2010 4:51 AM To: Shilimkar, Santosh Cc: t...@atomide.com; linux-omap@vger.kernel.org; b...@fluff.org.uk; sa...@linux.intel.com; l...@slimlogic.co.uk; Nayak, Rajendra; Syed, Rafiuddin; Ben Dooks Subject: Re: [PATCH 16/24] omap4: Add i2c support on omap4 platform Hello Santosh, one general comment on this patch, before the specific comments. Rather than adding more cpu_is_omap*() all over, please instead convert this code to use flags passed in via platform_data. The I2C hwmod conversion patches are one attempt to do that via the hwmod mechanism; you can use that as an example of one way to do that with this driver. 1. As you suggested most of the driver clock related modifications can be avoided with dummy_nodes. Will do that. 2. Some drivers like gptimer, the clock node names chosen are different between omap4 and rest of the omaps. Since we do clk_get based on clk names, such cases, we need cpu check. Another way is to keep same clock nodes which means need to change database scripts. Which one you prefer ? 3. I shall the possibility of passing flags via board-files instead of cpu_is_() checks in drivers. This is ofcourse much cleaner approach if it's doable. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 02/24] omap2/3/4: ioremap omap_globals module
snip
/**
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 4f29e8c..ee9499e 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -256,11 +256,11 @@ static void __init __omap2_set_globals(struct
omap_globals *omap2_globals)
static struct omap_globals omap242x_globals = {
.class = OMAP242X_CLASS,
.tap= OMAP2_L4_IO_ADDRESS(0x48014000),
- .sdrc = OMAP2_L3_IO_ADDRESS(OMAP2420_SDRC_BASE),
- .sms= OMAP2_L3_IO_ADDRESS(OMAP2420_SMS_BASE),
- .ctrl = OMAP2_L4_IO_ADDRESS(OMAP2420_CTRL_BASE),
- .prm= OMAP2_L4_IO_ADDRESS(OMAP2420_PRM_BASE),
- .cm = OMAP2_L4_IO_ADDRESS(OMAP2420_CM_BASE),
+ .sdrc = OMAP2420_SDRC_BASE,
+ .sms= OMAP2420_SMS_BASE,
+ .ctrl = OMAP2420_CTRL_BASE,
+ .prm= OMAP2420_PRM_BASE,
+ .cm = OMAP2420_CM_BASE,
.uart1_phys = OMAP2_UART1_BASE,
.uart2_phys = OMAP2_UART2_BASE,
.uart3_phys = OMAP2_UART3_BASE,
@@ -277,11 +277,11 @@ void __init omap2_set_globals_242x(void)
static struct omap_globals omap243x_globals = {
.class = OMAP243X_CLASS,
.tap= OMAP2_L4_IO_ADDRESS(0x4900a000),
- .sdrc = OMAP2_L3_IO_ADDRESS(OMAP243X_SDRC_BASE),
- .sms= OMAP2_L3_IO_ADDRESS(OMAP243X_SMS_BASE),
- .ctrl = OMAP2_L4_IO_ADDRESS(OMAP243X_CTRL_BASE),
- .prm= OMAP2_L4_IO_ADDRESS(OMAP2430_PRM_BASE),
- .cm = OMAP2_L4_IO_ADDRESS(OMAP2430_CM_BASE),
+ .sdrc = OMAP243X_SDRC_BASE,
+ .sms= (OMAP243X_SMS_BASE),
+ .ctrl = (OMAP243X_CTRL_BASE),
+ .prm= (OMAP2430_PRM_BASE),
+ .cm = (OMAP2430_CM_BASE),
Please drop the unnecessary parentheses above and elsewhere in this file.
If the parentheses are nececessary because the macro is a composite
expression and parentheses are missing around the expression, then the
parentheses should be added around the macro contents itself.
No need of paran's. They just left out while cleaning it up.
.uart1_phys = OMAP2_UART1_BASE,
.uart2_phys = OMAP2_UART2_BASE,
.uart3_phys = OMAP2_UART3_BASE,
@@ -298,11 +298,11 @@ void __init omap2_set_globals_243x(void)
static struct omap_globals omap3_globals = {
.class = OMAP343X_CLASS,
.tap= OMAP2_L4_IO_ADDRESS(0x4830A000),
- .sdrc = OMAP2_L3_IO_ADDRESS(OMAP343X_SDRC_BASE),
- .sms= OMAP2_L3_IO_ADDRESS(OMAP343X_SMS_BASE),
- .ctrl = OMAP2_L4_IO_ADDRESS(OMAP343X_CTRL_BASE),
- .prm= OMAP2_L4_IO_ADDRESS(OMAP3430_PRM_BASE),
- .cm = OMAP2_L4_IO_ADDRESS(OMAP3430_CM_BASE),
+ .sdrc = (OMAP343X_SDRC_BASE),
+ .sms= (OMAP343X_SMS_BASE),
+ .ctrl = (OMAP343X_CTRL_BASE),
+ .prm= (OMAP3430_PRM_BASE),
+ .cm = (OMAP3430_CM_BASE),
As above.
.uart1_phys = OMAP3_UART1_BASE,
.uart2_phys = OMAP3_UART2_BASE,
.uart3_phys = OMAP3_UART3_BASE,
@@ -325,10 +325,10 @@ void __init omap2_set_globals_36xx(void)
static struct omap_globals omap4_globals = {
.class = OMAP443X_CLASS,
.tap= OMAP2_L4_IO_ADDRESS(OMAP443X_SCM_BASE),
- .ctrl = OMAP2_L4_IO_ADDRESS(OMAP443X_CTRL_BASE),
- .prm= OMAP2_L4_IO_ADDRESS(OMAP4430_PRM_BASE),
- .cm = OMAP2_L4_IO_ADDRESS(OMAP4430_CM_BASE),
- .cm2= OMAP2_L4_IO_ADDRESS(OMAP4430_CM2_BASE),
+ .ctrl = (OMAP443X_CTRL_BASE),
+ .prm= (OMAP4430_PRM_BASE),
+ .cm = (OMAP4430_CM_BASE),
+ .cm2= (OMAP4430_CM2_BASE),
As above.
.uart1_phys = OMAP4_UART1_BASE,
.uart2_phys = OMAP4_UART2_BASE,
.uart3_phys = OMAP4_UART3_BASE,
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index e04a58e..dc8a897 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -41,12 +41,12 @@ extern struct sys_timer omap_timer;
struct omap_globals {
u32 class; /* OMAP class to detect */
void __iomem*tap; /* Control module ID code */
- void __iomem*sdrc; /* SDRAM Controller */
- void __iomem*sms; /* SDRAM Memory Scheduler */
- void __iomem*ctrl; /* System Control Module */
- void __iomem*prm; /* Power and Reset Management */
- void __iomem*cm;/* Clock Management */
- void __iomem*cm2;
+ unsigned long sdrc; /* SDRAM Controller */
+ unsigned long sms;/* SDRAM Memory Scheduler */
+ unsigned long ctrl; /* System Control Module */
+ unsigned long prm;/* Power and Reset Management */
+ unsigned long cm; /* Clock Management */
+ unsigned long cm2;
Please add comments above struct omap_globals to reinforce that these are
now physical addresses.
ok
unsigned long uart1_phys;
unsigned long uart2_phys;
RE: [PATCH 05/24] omap4: Add needed IRQ line into irqs.h
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Wednesday, February 17, 2010 11:02 AM
To: Shilimkar, Santosh
Cc: t...@atomide.com; linux-omap@vger.kernel.org; b...@fluff.org.uk;
sa...@linux.intel.com;
l...@slimlogic.co.uk; Cousson, Benoit
Subject: RE: [PATCH 05/24] omap4: Add needed IRQ line into irqs.h
On Wed, 17 Feb 2010, Shilimkar, Santosh wrote:
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Wednesday, February 17, 2010 3:39 AM
To: Shilimkar, Santosh
Cc: t...@atomide.com; linux-omap@vger.kernel.org; b...@fluff.org.uk;
sa...@linux.intel.com;
l...@slimlogic.co.uk
Subject: Re: [PATCH 05/24] omap4: Add needed IRQ line into irqs.h
Hello Santosh,
On Tue, 16 Feb 2010, Santosh Shilimkar wrote:
This patch adds DSS, keyboard and ducati irq
entries in irqs.h
Ones omap4 hwmod is pushed on mainlie, all the
irqs lines data would be availabe.
Instead of this patch, why not just replace the current file with the one
from the OMAP4 autogeneration scripts? I don't see why the IRQ macros
should depend on hwmod availability, and it would be better to have the
correct IRQ data appear in one patch, rather than having to review and
approve several smaller incremental patches over time.
We plan to do this but today the autogenrated file names and one in the
kernel code is different.
File names or macro names?
Macros ofcourse
Autogenrated headers are kept in alignment
with TRM naming as you know.
e.g
--- autogenaretd
#define OMAP44XX_IRQ_MCBSP2 (22 + OMAP44XX_IRQ_GIC_START)
--existing kernel
#define INT_44XX_MCBSP2_IRQ (22 + IRQ_GIC_START)
So instead of touching every driver file and changing it only for name
changes ,
what we are doing
1. Created local 44xx_dma.h and 44xx_irq.h mach-omap2 directory
2. All the drivers getting converted in hwmods would use defines from above
headers
3. At one point of time all the drivers would use defines from above
headers and then
from omap4 point of view there won't be dependency on the irqs.h and
dma.h
While this is ongoing, we would like the mainline kernel to have most of the
drivers supported. And Hence such a patch.
I grepped through the code base for any instances of INT_44XX:
[p...@twilight current]$ fgrep -r INT_44XX . | fgrep -v
./arch/arm/plat-omap/include/plat/irqs.h
./arch/arm/mach-omap2/devices.c: .start =
INT_44XX_MAIL_U0_MPU,
./arch/arm/mach-omap2/devices.c: irq = INT_44XX_MMC4_IRQ;
./arch/arm/mach-omap2/devices.c: irq = INT_44XX_MMC5_IRQ;
./arch/arm/mach-omap2/timer-mpu.c:evt-irq = INT_44XX_LOCALTIMER_IRQ;
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4a318000, .irq =
INT_44XX_GPTIMER1 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48032000, .irq =
INT_44XX_GPTIMER2 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48034000, .irq =
INT_44XX_GPTIMER3 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48036000, .irq =
INT_44XX_GPTIMER4 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x40138000, .irq =
INT_44XX_GPTIMER5 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4013a000, .irq =
INT_44XX_GPTIMER6 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4013a000, .irq =
INT_44XX_GPTIMER7 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4013e000, .irq =
INT_44XX_GPTIMER8 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4803e000, .irq =
INT_44XX_GPTIMER9 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48086000, .irq =
INT_44XX_GPTIMER10 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48088000, .irq =
INT_44XX_GPTIMER11 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4a32, .irq =
INT_44XX_GPTIMER12 },
./arch/arm/plat-omap/gpio.c: { OMAP44XX_GPIO1_BASE, NULL,
INT_44XX_GPIO_BANK1, IH_GPIO_BASE,
./arch/arm/plat-omap/gpio.c: { OMAP44XX_GPIO2_BASE, NULL,
INT_44XX_GPIO_BANK2, IH_GPIO_BASE + 32,
./arch/arm/plat-omap/gpio.c: { OMAP44XX_GPIO3_BASE, NULL,
INT_44XX_GPIO_BANK3, IH_GPIO_BASE + 64,
./arch/arm/plat-omap/gpio.c: { OMAP44XX_GPIO4_BASE, NULL,
INT_44XX_GPIO_BANK4, IH_GPIO_BASE + 96,
./arch/arm/plat-omap/gpio.c: { OMAP44XX_GPIO5_BASE, NULL,
INT_44XX_GPIO_BANK5, IH_GPIO_BASE + 128,
./arch/arm/plat-omap/gpio.c: { OMAP44XX_GPIO6_BASE, NULL,
INT_44XX_GPIO_BANK6, IH_GPIO_BASE + 160,
./arch/arm/plat-omap/dma.c: irq = INT_44XX_SDMA_IRQ0;
[p...@twilight current]$
There are only five files to change. None of them are device
driver files, so they can all be merged through linux-omap. The
changes could easily be done in a single patch. So I see no
reason to not use the autogenerated IRQ file.
I think on you tree, you won't have DSS, AUDIO-ALSA, BRIDGE, USB etc.
All these drivers needs to be updated
RE: [PATCH 05/24] omap4: Add needed IRQ line into irqs.h
snip
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Shilimkar, Santosh
Sent: Wednesday, February 17, 2010 11:22 AM
To: Paul Walmsley
Cc: t...@atomide.com; linux-omap@vger.kernel.org; b...@fluff.org.uk;
sa...@linux.intel.com;
l...@slimlogic.co.uk; Cousson, Benoit
Subject: RE: [PATCH 05/24] omap4: Add needed IRQ line into irqs.h
Ones omap4 hwmod is pushed on mainlie, all the
irqs lines data would be availabe.
Instead of this patch, why not just replace the current file with the
one
from the OMAP4 autogeneration scripts? I don't see why the IRQ macros
should depend on hwmod availability, and it would be better to have the
correct IRQ data appear in one patch, rather than having to review and
approve several smaller incremental patches over time.
We plan to do this but today the autogenrated file names and one in the
kernel code is different.
File names or macro names?
Macros ofcourse
Autogenrated headers are kept in alignment
with TRM naming as you know.
e.g
--- autogenaretd
#define OMAP44XX_IRQ_MCBSP2 (22 + OMAP44XX_IRQ_GIC_START)
--existing kernel
#define INT_44XX_MCBSP2_IRQ (22 + IRQ_GIC_START)
So instead of touching every driver file and changing it only for name
changes ,
what we are doing
1. Created local 44xx_dma.h and 44xx_irq.h mach-omap2 directory
2. All the drivers getting converted in hwmods would use defines from
above headers
3. At one point of time all the drivers would use defines from above
headers and then
from omap4 point of view there won't be dependency on the irqs.h and
dma.h
While this is ongoing, we would like the mainline kernel to have most of
the
drivers supported. And Hence such a patch.
I grepped through the code base for any instances of INT_44XX:
[p...@twilight current]$ fgrep -r INT_44XX . | fgrep -v
./arch/arm/plat-omap/include/plat/irqs.h
./arch/arm/mach-omap2/devices.c:.start =
INT_44XX_MAIL_U0_MPU,
./arch/arm/mach-omap2/devices.c:irq = INT_44XX_MMC4_IRQ;
./arch/arm/mach-omap2/devices.c:irq = INT_44XX_MMC5_IRQ;
./arch/arm/mach-omap2/timer-mpu.c: evt-irq = INT_44XX_LOCALTIMER_IRQ;
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4a318000, .irq =
INT_44XX_GPTIMER1 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48032000, .irq =
INT_44XX_GPTIMER2 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48034000, .irq =
INT_44XX_GPTIMER3 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48036000, .irq =
INT_44XX_GPTIMER4 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x40138000, .irq =
INT_44XX_GPTIMER5 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4013a000, .irq =
INT_44XX_GPTIMER6 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4013a000, .irq =
INT_44XX_GPTIMER7 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4013e000, .irq =
INT_44XX_GPTIMER8 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4803e000, .irq =
INT_44XX_GPTIMER9 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48086000, .irq =
INT_44XX_GPTIMER10 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48088000, .irq =
INT_44XX_GPTIMER11 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4a32, .irq =
INT_44XX_GPTIMER12 },
./arch/arm/plat-omap/gpio.c:{ OMAP44XX_GPIO1_BASE, NULL,
INT_44XX_GPIO_BANK1, IH_GPIO_BASE,
./arch/arm/plat-omap/gpio.c:{ OMAP44XX_GPIO2_BASE, NULL,
INT_44XX_GPIO_BANK2, IH_GPIO_BASE +
32,
./arch/arm/plat-omap/gpio.c:{ OMAP44XX_GPIO3_BASE, NULL,
INT_44XX_GPIO_BANK3, IH_GPIO_BASE +
64,
./arch/arm/plat-omap/gpio.c:{ OMAP44XX_GPIO4_BASE, NULL,
INT_44XX_GPIO_BANK4, IH_GPIO_BASE +
96,
./arch/arm/plat-omap/gpio.c:{ OMAP44XX_GPIO5_BASE, NULL,
INT_44XX_GPIO_BANK5, IH_GPIO_BASE +
128,
./arch/arm/plat-omap/gpio.c:{ OMAP44XX_GPIO6_BASE, NULL,
INT_44XX_GPIO_BANK6, IH_GPIO_BASE +
160,
./arch/arm/plat-omap/dma.c: irq = INT_44XX_SDMA_IRQ0;
[p...@twilight current]$
There are only five files to change. None of them are device
driver files, so they can all be merged through linux-omap. The
changes could easily be done in a single patch. So I see no
reason to not use the autogenerated IRQ file.
I think on you tree, you won't have DSS, AUDIO-ALSA, BRIDGE, USB etc.
All these drivers needs to be updated as well
Having said that, I think it's best time to changes this so that
the drivers getting up streamed can use correct names directly.
Also irqs-44xx.h header inclusion can be avoided in each driver if plat/irqs.h
include it.
I can check this if this can go in the currunt series itself. At least USB
and MCPDM are the two drivers I know of, planned
RE: [PATCH 05/24] omap4: Add needed IRQ line into irqs.h
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, February 17, 2010 12:15 PM To: Shilimkar, Santosh Cc: t...@atomide.com; linux-omap@vger.kernel.org; b...@fluff.org.uk; sa...@linux.intel.com; l...@slimlogic.co.uk; Cousson, Benoit Subject: RE: [PATCH 05/24] omap4: Add needed IRQ line into irqs.h Hello Santosh, On Wed, 17 Feb 2010, Shilimkar, Santosh wrote: Having said that, I think it's best time to changes this so that the drivers getting up streamed can use correct names directly. Also irqs-44xx.h header inclusion can be avoided in each driver if plat/irqs.h include it. I can check this if this can go in the currunt series itself. At least USB and MCPDM are the two drivers I know of, planned to be lined up which will get affected. How about doing this in the .34-rc1 so that we don't break anybody ? How about just submitting the auto-generated IRQ file, convert the existing in-tree users, and leave the old macros there and mark them deprecated with a comment? Then for the next release, submit a patch to change the newly-merged users and remove the deprecated macros? Sounds ok if we can keep both exist for some time. Will do this. -- 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/9] omap4 updates for 2.6.34
This series have few omap4 updates and is based on Tony's 'omap-for-linus' branch. This series patches are part of the below series posted on linux-omap for review earlier this week. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg23939.html From the previous series, I have dropped all the clock and i2c patches because of few dependencies. The auto-generated dma and irq headers are included as per comments. The series is boot tested on omap4430 and omap4430 sdp's with multi-omap and regular defconfig builds. The following changes since commit 80c20d543d142ee54ec85259b77aaf0b83c32db5: Tony Lindgren (1): Merge branch 'omap-fixes-for-linus' into omap-for-linus Santosh Shilimkar (9): omap3/4: uart: fix full-fifo write abort omap2/3/4: ioremap omap_globals module omap4: sdma: Enable the idle modes on omap4 omap: sdma: Limit the secure reserve channel fix for omap3 omap4: Fix omap_type() for omap4 omap3/4: Remove overlapping mapping of L4_WKUP io space omap4: Add auto-generated irq and dma headers omap4: Use dma line defines from dma-44xx.h omap4: Use irq line defines from irq-44xx.h arch/arm/mach-omap2/control.c|6 +- arch/arm/mach-omap2/devices.c|8 +- arch/arm/mach-omap2/id.c |2 + arch/arm/mach-omap2/include/mach/irqs-44xx.h | 144 + arch/arm/mach-omap2/include/mach/irqs.h |1 + arch/arm/mach-omap2/io.c | 12 -- arch/arm/mach-omap2/prcm.c | 16 +++- arch/arm/mach-omap2/sdrc.c | 11 ++- arch/arm/mach-omap2/serial.c | 31 +- arch/arm/mach-omap2/timer-mpu.c |2 +- arch/arm/plat-omap/common.c | 38 arch/arm/plat-omap/devices.c |4 +- arch/arm/plat-omap/dma.c |7 +- arch/arm/plat-omap/dmtimer.c | 24 ++-- arch/arm/plat-omap/gpio.c| 12 +- arch/arm/plat-omap/include/plat/common.h | 17 ++-- arch/arm/plat-omap/include/plat/control.h|3 + arch/arm/plat-omap/include/plat/dma-44xx.h | 145 ++ arch/arm/plat-omap/include/plat/dma.h| 86 +--- arch/arm/plat-omap/include/plat/io.h |9 -- arch/arm/plat-omap/include/plat/irqs.h | 89 arch/arm/plat-omap/io.c |4 - 22 files changed, 411 insertions(+), 260 deletions(-) create mode 100644 arch/arm/mach-omap2/include/mach/irqs-44xx.h create mode 100644 arch/arm/plat-omap/include/plat/dma-44xx.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: [PATCH 7/9] omap4: Add auto-generated irq and dma headers
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, February 18, 2010 10:53 PM To: Shilimkar, Santosh Cc: t...@atomide.com; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Cousson, Benoit Subject: Re: [PATCH 7/9] omap4: Add auto-generated irq and dma headers Hello Santosh, thanks for sending these in. One minor comment: On Thu, 18 Feb 2010, Santosh Shilimkar wrote: These files are generated along with the HWMOD and will eventually be in the existing header files as soon as all drivers will be migrate to omap_hwmod / omap_device. The dma-44xx.h file should be in 'arch/arm/mach-omap2/include/mach/', but this would need dma.h header also present in the mach directory to make local include possible, like what is done for irq.h. Then the script is needed to modify the drivers to include 'mach/dma.h' instead of 'plat/dma.h'. This would be a bigger change and hence left out for now I think I originally wrote the DMA generator script, so please add a Nokia copyright and put my name in there also. After that point, it has my ack. Sure Paul. Will add that information and send updated patch. Benoit, We need to update the scripts and regenerate this. I will do that. 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/9] omap4 updates for 2.6.34
Thanks Paul !! -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, February 18, 2010 11:06 PM To: Shilimkar, Santosh Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm-kernel Subject: Re: [PATCH 0/9] omap4 updates for 2.6.34 Hi Santosh, On Thu, 18 Feb 2010, Shilimkar, Santosh wrote: This series have few omap4 updates and is based on Tony's 'omap-for-linus' branch. This series patches are part of the below series posted on linux-omap for review earlier this week. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg23939.html From the previous series, I have dropped all the clock and i2c patches because of few dependencies. The auto-generated dma and irq headers are included as per comments. The series is boot tested on omap4430 and omap4430 sdp's with multi-omap and regular defconfig builds. Aside from the two minor comments just sent, the rest of the patches are Reviewed-by: Paul Walmsley p...@pwsan.com 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 7/9] omap4: Add auto-generated irq and dma headers
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, February 18, 2010 10:53 PM To: Shilimkar, Santosh Cc: t...@atomide.com; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Cousson, Benoit Subject: Re: [PATCH 7/9] omap4: Add auto-generated irq and dma headers Hello Santosh, thanks for sending these in. One minor comment: On Thu, 18 Feb 2010, Santosh Shilimkar wrote: These files are generated along with the HWMOD and will eventually be in the existing header files as soon as all drivers will be migrate to omap_hwmod / omap_device. The dma-44xx.h file should be in 'arch/arm/mach-omap2/include/mach/', but this would need dma.h header also present in the mach directory to make local include possible, like what is done for irq.h. Then the script is needed to modify the drivers to include 'mach/dma.h' instead of 'plat/dma.h'. This would be a bigger change and hence left out for now I think I originally wrote the DMA generator script, so please add a Nokia copyright and put my name in there also. After that point, it has my ack. Updated patch attached with Paul's contributions added to the dma-44xx.h file. Regards, Santosh 0007-omap4-Add-auto-generated-irq-and-dma-headers.patch Description: 0007-omap4-Add-auto-generated-irq-and-dma-headers.patch
RE: [PATCH 2/9] omap2/3/4: ioremap omap_globals module
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, February 19, 2010 3:55 AM To: Shilimkar, Santosh Cc: t...@atomide.com; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 2/9] omap2/3/4: ioremap omap_globals module Santosh Shilimkar santosh.shilim...@ti.com writes: This is a clean-up patch towards dynamic allocation of IO space instead of using harcoded macros to calculate virtual addresses. Also update the sdrc, prcm, tap and control module to allocate iospace dynamically You should drop the referenece to the TAP here since it's dropped. As per Tony's suggestion V2 version drops tap changes becasue ioremap uses cpu_is_omap2420() and cpu_is_omap2430(), so we can't use that for setting tap_base. Hence ioremap() won't work for tap until omap2_check_revision() is done And this type of comment should come after the '---' since it's relevant to the reviewers, but not to the final git history. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com CC: Kevin Hilman khil...@deeprootsystems.com CC: Tony Lindgren t...@atomide.com After that, you can change the CC for me to a Reviewed-by. Refreshed version attached with style fix and adding the Paul, Kevin's Reviewed-by. Regards, Santosh 0002-omap2-3-4-ioremap-omap_globals-module.patch Description: 0002-omap2-3-4-ioremap-omap_globals-module.patch
RE: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
Bye the way just to add bit more clarity, this patch addresses TX
hardware restriction in the new UART IP used on omap3630 and omap4430.
First part of the fix for RX is already in mainline,
Commit: ce13d4716a276f4331d78ba28a5093a63822ab95
More details on this thread are here.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19447.html
-Original Message-
From: Shilimkar, Santosh
Sent: Thursday, February 18, 2010 2:29 PM
To: t...@atomide.com
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Shilimkar, Santosh; Woodruff,
Richard; Ghorai, Sukumar
Subject: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
This patch is addition to the already merged commit on non-empty
uart fifo read abort. ce13d4716a276f4331d78ba28a5093a63822ab95
OMAP3630 and OMAP4430 UART IP blocks have a restriction on TX FIFO
too. If you try to write to the tx fifo when it is full, the system aborts.
This can be easily reproducible by not suppressing interconnect errors or
long duration testing where continuous prints over console from multiple
threads. This patch is addressing the issue by ensuring that write is
not issued while fifo is full. A timeout is added to avoid any hang
on fifo-full for 10 mS which is unlikely case.
Patch is validated on OMAP3630 and OMAP4 SDP.
V2 version removed the additional 1 uS on every TX as per
Tony's suggestion
Signed-off-by: Woodruff Richard r-woodru...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
CC: Ghorai Sukumar s-gho...@ti.com
---
arch/arm/mach-omap2/serial.c | 31 ---
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 5f3035e..b79bc89 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -23,6 +23,7 @@
#include linux/serial_reg.h
#include linux/clk.h
#include linux/io.h
+#include linux/delay.h
#include plat/common.h
#include plat/board.h
@@ -160,6 +161,13 @@ static inline unsigned int serial_read_reg(struct
plat_serial8250_port *up,
return (unsigned int)__raw_readb(up-membase + offset);
}
+static inline void __serial_write_reg(struct uart_port *up, int offset,
+ int value)
+{
+ offset = up-regshift;
+ __raw_writeb(value, up-membase + offset);
+}
+
static inline void serial_write_reg(struct plat_serial8250_port *p, int
offset,
int value)
{
@@ -620,6 +628,20 @@ static unsigned int serial_in_override(struct uart_port
*up, int offset)
return __serial_read_reg(up, offset);
}
+static void serial_out_override(struct uart_port *up, int offset, int value)
+{
+ unsigned int status, tmout = 1;
+
+ status = __serial_read_reg(up, UART_LSR);
+ while (!(status UART_LSR_THRE)) {
+ /* Wait up to 10ms for the character(s) to be sent. */
+ if (--tmout == 0)
+ break;
+ udelay(1);
+ status = __serial_read_reg(up, UART_LSR);
+ }
+ __serial_write_reg(up, offset, value);
+}
void __init omap_serial_early_init(void)
{
int i;
@@ -721,11 +743,14 @@ void __init omap_serial_init_port(int port)
* omap3xxx: Never read empty UART fifo on UARTs
* with IP rev =0x52
*/
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
uart-p-serial_in = serial_in_override;
- else if ((serial_read_reg(uart-p, UART_OMAP_MVER) 0xFF)
- = UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
+ uart-p-serial_out = serial_out_override;
+ } else if ((serial_read_reg(uart-p, UART_OMAP_MVER) 0xFF)
+ = UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV) {
uart-p-serial_in = serial_in_override;
+ uart-p-serial_out = serial_out_override;
+ }
}
/**
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 00/11] omap updates for 2.6.34, part 4
Tony, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Saturday, February 20, 2010 5:00 AM To: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org Subject: [PATCH 00/11] omap updates for 2.6.34, part 4 Hi all, Here are few USB platform init patches that have been already posted to linux-usb and linux-omap and have been sitting in for-next. Posting them one more time to make sure people on linux-arm-kernel have seen these too. Regards, Tony --- Felipe Balbi (7): arm: omap: musb: ioremap only what's ours omap: musb: remove unused data arm: omap: musb: we can use clk framework omap: musb: remove unused soft_con field omap: musb: remove unused dma data omap: musb: remove unnecessary return omap: musb: get rid of dyn_fifo Maulik Mankad (4): USB: Add empty functions in otg.h omap: musb: Remove #ifdef from board-omap3evm.c omap: musb: Pass board specific data from board file omap: musb: Add USB support to 4430 SDP board file We need attached patch to keep multi-omap build booting on omap4 on top of this series. Regards, Santosh 0001-omap4-multi-omap-Allow-build-to-work.patch Description: 0001-omap4-multi-omap-Allow-build-to-work.patch
RE: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Anna, Suman Sent: Friday, February 19, 2010 2:37 AM To: linux-omap@vger.kernel.org Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam Subject: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning From 78d00b562548e1d95ad12a4d8121be67950daf68 Mon Sep 17 00:00:00 2001 From: Suman Anna s-a...@ti.com Date: Mon, 25 Jan 2010 18:27:21 -0600 Subject: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning Remove a compiler warning in device-specific mailbox module. Signed-off-by: Suman Anna s-a...@ti.com --- arch/arm/mach-omap2/mailbox.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 2c9fd1c..c970cf6 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -419,8 +419,10 @@ static int __devinit omap2_mbox_probe(struct platform_device *pdev) #endif return 0; +#if defined(CONFIG_ARCH_OMAP2420) /* IVA */ err_iva1: omap_mbox_unregister(mbox_dsp_info); +#endif Can't we avoid the #ifdef here? Is this omap_mbox_unregister omap2 specific? 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/5] omap: mailbox: correct OMAP4 reset logic
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Anna,
Suman
Sent: Friday, February 19, 2010 2:37 AM
To: linux-omap@vger.kernel.org
Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam
Subject: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic
From 2488815a9facca29e2da3ddd279de441a5de6a58 Mon Sep 17 00:00:00 2001
From: Suman Anna s-a...@ti.com
Date: Tue, 26 Jan 2010 16:55:29 -0600
Subject: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic
OMAP4 mailbox has a different register set. There is
no MAILBOX_SYSSTATUS register. The reset is indicated
with the SOFTRESET bit of the MAILBOX_SYSCONFIG register
itself. This bit should read 0 for a successful Reset.
Also, the SOFTRESET bit occupies bit0 and not bit1 as with
previous generations.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/mailbox.c | 38 +++---
1 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index c970cf6..88e9043 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -40,6 +40,7 @@
#define AUTOIDLE (1 0)
#define SOFTRESET(1 1)
#define SMARTIDLE(2 3)
+#define OMAP4_SOFTRESET (1 0)
/* SYSSTATUS: register bit definition */
#define RESETDONE(1 0)
@@ -99,17 +100,32 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
}
clk_enable(mbox_ick_handle);
- mbox_write_reg(SOFTRESET, MAILBOX_SYSCONFIG);
- timeout = jiffies + msecs_to_jiffies(20);
- do {
- l = mbox_read_reg(MAILBOX_SYSSTATUS);
- if (l RESETDONE)
- break;
- } while (!time_after(jiffies, timeout));
-
- if (!(l RESETDONE)) {
- pr_err(Can't take mmu out of reset\n);
- return -ENODEV;
+ if (cpu_is_omap44xx()) {
Not so strong opinion but can we make use of mailbox ip revision instead
of cpu_is_() check.
+ mbox_write_reg(OMAP4_SOFTRESET, MAILBOX_SYSCONFIG);
+ timeout = jiffies + msecs_to_jiffies(20);
+ do {
+ l = mbox_read_reg(MAILBOX_SYSCONFIG);
+ if (!(l OMAP4_SOFTRESET))
+ break;
+ } while (!time_after(jiffies, timeout));
+
+ if (l OMAP4_SOFTRESET) {
+ pr_err(Can't take mailbox out of reset\n);
+ return -ENODEV;
+ }
+ } else {
+ mbox_write_reg(SOFTRESET, MAILBOX_SYSCONFIG);
+ timeout = jiffies + msecs_to_jiffies(20);
+ do {
+ l = mbox_read_reg(MAILBOX_SYSSTATUS);
+ if (l RESETDONE)
+ break;
+ } while (!time_after(jiffies, timeout));
+
+ if (!(l RESETDONE)) {
+ pr_err(Can't take mailbox out of reset\n);
+ return -ENODEV;
+ }
}
l = mbox_read_reg(MAILBOX_REVISION);
--
1.6.6.2
--
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 3/5] omap: mailbox: correct OMAP4 SIDLEMODE logic
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Anna, Suman Sent: Friday, February 19, 2010 2:37 AM To: linux-omap@vger.kernel.org Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam Subject: [PATCH 3/5] omap: mailbox: correct OMAP4 SIDLEMODE logic From 18beb1784db07e4eb2b9d10783a309b5caccb979 Mon Sep 17 00:00:00 2001 From: Suman Anna s-a...@ti.com Date: Fri, 5 Feb 2010 17:20:26 -0600 Subject: [PATCH 3/5] omap: mailbox: correct OMAP4 SIDLEMODE logic OMAP4 mailbox has a different MAILBOX_SYSCONFIG register. There is now no AutoIdle. The SIDLEMODE bits have been right-shifted by 1 bit and now occupy bits 2 3. Signed-off-by: Suman Anna s-a...@ti.com --- arch/arm/mach-omap2/mailbox.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 88e9043..e0c1f1b 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -41,6 +41,8 @@ #define SOFTRESET(1 1) #define SMARTIDLE(2 3) #define OMAP4_SOFTRESET (1 0) +#define OMAP4_NOIDLE (1 2) +#define OMAP4_SMARTIDLE (2 2) /* SYSSTATUS: register bit definition */ #define RESETDONE(1 0) @@ -131,7 +133,10 @@ static int omap2_mbox_startup(struct omap_mbox *mbox) l = mbox_read_reg(MAILBOX_REVISION); pr_info(omap mailbox rev %d.%d\n, (l 0xf0) 4, (l 0x0f)); - l = SMARTIDLE | AUTOIDLE; + if (cpu_is_omap44xx()) IP revision check again if possible + l = OMAP4_SMARTIDLE; + else + l = SMARTIDLE | AUTOIDLE; mbox_write_reg(l, MAILBOX_SYSCONFIG); omap2_mbox_enable_irq(mbox, IRQ_RX); -- 1.6.6.2 -- 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 1/9] omap3/4: uart: fix full-fifo write abort
Thanks Tony -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Tuesday, February 23, 2010 4:37 AM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Woodruff, Richard; Ghorai, Sukumar Subject: Re: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort * Tony Lindgren t...@atomide.com [100222 13:35]: * Shilimkar, Santosh santosh.shilim...@ti.com [100218 21:22]: Bye the way just to add bit more clarity, this patch addresses TX hardware restriction in the new UART IP used on omap3630 and omap4430. First part of the fix for RX is already in mainline, Commit: ce13d4716a276f4331d78ba28a5093a63822ab95 More details on this thread are here. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19447.html Thanks, I've updated the comments for this patch with the link above and added the whole series into omap for-next. Except patches 8 and 9 as they break compile for mach-omap1 and need to be updated. I will check these two patches tony and also boot test the OMAP1. 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] omap: i2c: Add i2c support on omap4 platform
Ben,
Did you happen to look at this ?
-Original Message-
From: Shilimkar, Santosh
Sent: Friday, February 19, 2010 10:03 PM
To: ben-li...@fluff.org
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; Shilimkar,
Santosh; Syed, Rafiuddin; Cory
Maccarrone
Subject: [PATCH] omap: i2c: Add i2c support on omap4 platform
This patch is rebased version of earlier post to add I2C
driver support to OMAP4 platform. On OMAP4, all
I2C register address offsets are changed from OMAP1/2/3 I2C.
In order to not have #ifdef's at various places in code,
as well as to support multi-OMAP build, an array is created
to hold the register addresses with it's offset.
This patch was submitted, reviewed and acked on mailing list
already. For more details refer below link
http://www.mail-archive.com/linux-...@vger.kernel.org/msg02281.html
This updated verion has a depedancy on Add support for 16-bit registers
posted on linux-omap. Below is the patch-works link for the same
http://patchwork.kernel.org/patch/72295/
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Paul Walmsley p...@pwsan.com
Reviewed-by: Tony Lindgren t...@atomide.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Cory Maccarrone darkstar6...@gmail.com
---
drivers/i2c/busses/i2c-omap.c | 146
-
1 files changed, 114 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9c3ce4d..7c15496 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -44,29 +44,37 @@
/* I2C controller revisions present on specific hardware */
#define OMAP_I2C_REV_ON_2430 0x36
#define OMAP_I2C_REV_ON_3430 0x3C
+#define OMAP_I2C_REV_ON_4430 0x40
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
-#define OMAP_I2C_REV_REG 0x00
-#define OMAP_I2C_IE_REG 0x01
-#define OMAP_I2C_STAT_REG0x02
-#define OMAP_I2C_IV_REG 0x03
/* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
-#define OMAP_I2C_WE_REG 0x03
-#define OMAP_I2C_SYSS_REG0x04
-#define OMAP_I2C_BUF_REG 0x05
-#define OMAP_I2C_CNT_REG 0x06
-#define OMAP_I2C_DATA_REG0x07
-#define OMAP_I2C_SYSC_REG0x08
-#define OMAP_I2C_CON_REG 0x09
-#define OMAP_I2C_OA_REG 0x0a
-#define OMAP_I2C_SA_REG 0x0b
-#define OMAP_I2C_PSC_REG 0x0c
-#define OMAP_I2C_SCLL_REG0x0d
-#define OMAP_I2C_SCLH_REG0x0e
-#define OMAP_I2C_SYSTEST_REG 0x0f
-#define OMAP_I2C_BUFSTAT_REG 0x10
+enum {
+ OMAP_I2C_REV_REG = 0,
+ OMAP_I2C_IE_REG,
+ OMAP_I2C_STAT_REG,
+ OMAP_I2C_IV_REG,
+ OMAP_I2C_WE_REG,
+ OMAP_I2C_SYSS_REG,
+ OMAP_I2C_BUF_REG,
+ OMAP_I2C_CNT_REG,
+ OMAP_I2C_DATA_REG,
+ OMAP_I2C_SYSC_REG,
+ OMAP_I2C_CON_REG,
+ OMAP_I2C_OA_REG,
+ OMAP_I2C_SA_REG,
+ OMAP_I2C_PSC_REG,
+ OMAP_I2C_SCLL_REG,
+ OMAP_I2C_SCLH_REG,
+ OMAP_I2C_SYSTEST_REG,
+ OMAP_I2C_BUFSTAT_REG,
+ OMAP_I2C_REVNB_LO,
+ OMAP_I2C_REVNB_HI,
+ OMAP_I2C_IRQSTATUS_RAW,
+ OMAP_I2C_IRQENABLE_SET,
+ OMAP_I2C_IRQENABLE_CLR,
+};
/* I2C Interrupt Enable Register (OMAP_I2C_IE): */
#define OMAP_I2C_IE_XDR (1 14) /* TX Buffer drain int
enable */
@@ -169,6 +177,7 @@ struct omap_i2c_dev {
u32 speed; /* Speed of bus in Khz */
u16 cmd_err;
u8 *buf;
+ u8 *regs;
size_t buf_len;
struct i2c_adapter adapter;
u8 fifo_size; /* use as flag and value
@@ -187,15 +196,64 @@ struct omap_i2c_dev {
u16 westate;
};
+const static u8 reg_map[] = {
+ [OMAP_I2C_REV_REG] = 0x00,
+ [OMAP_I2C_IE_REG] = 0x01,
+ [OMAP_I2C_STAT_REG] = 0x02,
+ [OMAP_I2C_IV_REG] = 0x03,
+ [OMAP_I2C_WE_REG] = 0x03,
+ [OMAP_I2C_SYSS_REG] = 0x04,
+ [OMAP_I2C_BUF_REG] = 0x05,
+ [OMAP_I2C_CNT_REG] = 0x06,
+ [OMAP_I2C_DATA_REG] = 0x07,
+ [OMAP_I2C_SYSC_REG] = 0x08,
+ [OMAP_I2C_CON_REG] = 0x09,
+ [OMAP_I2C_OA_REG] = 0x0a,
+ [OMAP_I2C_SA_REG] = 0x0b,
+ [OMAP_I2C_PSC_REG] = 0x0c,
+ [OMAP_I2C_SCLL_REG] = 0x0d,
+ [OMAP_I2C_SCLH_REG] = 0x0e,
+ [OMAP_I2C_SYSTEST_REG] = 0x0f,
+ [OMAP_I2C_BUFSTAT_REG] = 0x10,
+};
+
+const static u8 omap4_reg_map[] = {
+ [OMAP_I2C_REV_REG] = 0x04,
+ [OMAP_I2C_IE_REG] = 0x2c,
+ [OMAP_I2C_STAT_REG] = 0x28,
+ [OMAP_I2C_IV_REG] = 0x34
RE: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
Tony, -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Tuesday, February 23, 2010 4:37 AM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Woodruff, Richard; Ghorai, Sukumar Subject: Re: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort * Tony Lindgren t...@atomide.com [100222 13:35]: * Shilimkar, Santosh santosh.shilim...@ti.com [100218 21:22]: Bye the way just to add bit more clarity, this patch addresses TX hardware restriction in the new UART IP used on omap3630 and omap4430. First part of the fix for RX is already in mainline, Commit: ce13d4716a276f4331d78ba28a5093a63822ab95 More details on this thread are here. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19447.html Thanks, I've updated the comments for this patch with the link above and added the whole series into omap for-next. Except patches 8 and 9 as they break compile for mach-omap1 and need to be updated. Patch 8 is alright and doesn't break omap1. Patch 7 and patch 9 needs update to fix the mach-omap1 build issue by moving irqs-44xx.h header file to plat-omap directory. Attached are updated 7 and 9. Build tested for omap1 (omap_generic_1710_defconfig and omap_h2_1610_defconfig) and boot tested with omap3_defconfig on omap4430sdp board. Thanks!! Regards, Santosh 0007-omap4-Add-auto-generated-irq-and-dma-headers.patch Description: 0007-omap4-Add-auto-generated-irq-and-dma-headers.patch 0009-omap4-Use-irq-line-defines-from-irq-44xx.h.patch Description: 0009-omap4-Use-irq-line-defines-from-irq-44xx.h.patch
RE: About multicore OMAP
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Jacob
john
Sent: Tuesday, February 23, 2010 6:34 PM
To: linux-omap@vger.kernel.org
Subject: About multicore OMAP
Hi Guys, I workin on OMAP4, just started,
I appreciate, if some one could brief out working drivers and SMP
benchmark data?
Welcome John !!
Can be explicit what you are looking for? Which omap4
platform do you have ?
Regards,
Santosh
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: About multicore OMAP
-Original Message- From: Jacob john [mailto:jacob.joh...@gmail.com] Sent: Tuesday, February 23, 2010 7:51 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: About multicore OMAP It's Blaze with two lcd's and pico, looks great. Can I have this linux-omap kernel running on OMAP4?, plus I'm looking for SMP benchmark results etc. Linux-omap kernel with omap_4430sdp_defconfig will boot on blaze with SMP. This won't have lot of driver support as such currently. Also L2 cache support is in on the way to make it to mainline as well. You should be able to play with this with some basic benchmark test related to CPU. Display , Audio, Pico, keypad, touchscreeen etc drivers are available with the release and you should be able get more details from the TI contact person who gave you the blaze. You can also get the performance numbers from same source Regards, Santosh
RE: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Tuesday, February 23, 2010 3:10 AM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Woodruff, Richard; Ghorai,
Sukumar
Subject: Re: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
* Shilimkar, Santosh santosh.shilim...@ti.com [100218 21:22]:
Bye the way just to add bit more clarity, this patch addresses TX
hardware restriction in the new UART IP used on omap3630 and omap4430.
First part of the fix for RX is already in mainline,
Commit: ce13d4716a276f4331d78ba28a5093a63822ab95
More details on this thread are here.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19447.html
Thanks, I've updated the comments for this patch with the link above
and added the whole series into omap for-next.
Please drop this patch since it has introduces regression on interrupt latency
while traces are enabled. Since 8250 driver calls serial_out() function is with
interrupt disabled ( spin_lock_irqsave), the interrupt latency at times is
as high as in few milliseconds because of error case.
I shall work towards this issue but for now we should drop this since the side
effect
of this change is known
-Original Message-
From: Shilimkar, Santosh
Sent: Thursday, February 18, 2010 2:29 PM
To: t...@atomide.com
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Shilimkar, Santosh;
Woodruff,
Richard; Ghorai, Sukumar
Subject: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
This patch is addition to the already merged commit on non-empty
uart fifo read abort. ce13d4716a276f4331d78ba28a5093a63822ab95
OMAP3630 and OMAP4430 UART IP blocks have a restriction on TX FIFO
too. If you try to write to the tx fifo when it is full, the system
aborts.
This can be easily reproducible by not suppressing interconnect errors or
long duration testing where continuous prints over console from multiple
threads. This patch is addressing the issue by ensuring that write is
not issued while fifo is full. A timeout is added to avoid any hang
on fifo-full for 10 mS which is unlikely case.
Patch is validated on OMAP3630 and OMAP4 SDP.
V2 version removed the additional 1 uS on every TX as per
Tony's suggestion
Signed-off-by: Woodruff Richard r-woodru...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
CC: Ghorai Sukumar s-gho...@ti.com
---
arch/arm/mach-omap2/serial.c | 31 ---
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 5f3035e..b79bc89 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -23,6 +23,7 @@
#include linux/serial_reg.h
#include linux/clk.h
#include linux/io.h
+#include linux/delay.h
#include plat/common.h
#include plat/board.h
@@ -160,6 +161,13 @@ static inline unsigned int serial_read_reg(struct
plat_serial8250_port *up,
return (unsigned int)__raw_readb(up-membase + offset);
}
+static inline void __serial_write_reg(struct uart_port *up, int offset,
+ int value)
+{
+ offset = up-regshift;
+ __raw_writeb(value, up-membase + offset);
+}
+
static inline void serial_write_reg(struct plat_serial8250_port *p, int
offset,
int value)
{
@@ -620,6 +628,20 @@ static unsigned int serial_in_override(struct
uart_port *up, int offset)
return __serial_read_reg(up, offset);
}
+static void serial_out_override(struct uart_port *up, int offset, int
value)
+{
+ unsigned int status, tmout = 1;
+
+ status = __serial_read_reg(up, UART_LSR);
+ while (!(status UART_LSR_THRE)) {
+ /* Wait up to 10ms for the character(s) to be sent. */
+ if (--tmout == 0)
+ break;
+ udelay(1);
+ status = __serial_read_reg(up, UART_LSR);
+ }
+ __serial_write_reg(up, offset, value);
+}
void __init omap_serial_early_init(void)
{
int i;
@@ -721,11 +743,14 @@ void __init omap_serial_init_port(int port)
* omap3xxx: Never read empty UART fifo on UARTs
* with IP rev =0x52
*/
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
uart-p-serial_in = serial_in_override;
- else if ((serial_read_reg(uart-p, UART_OMAP_MVER) 0xFF)
- = UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
+ uart-p-serial_out = serial_out_override;
+ } else if ((serial_read_reg(uart-p, UART_OMAP_MVER) 0xFF)
+ = UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV) {
uart-p-serial_in = serial_in_override;
+ uart-p-serial_out = serial_out_override;
+ }
}
/**
--
1.6.0.4
Regards,
Santosh
RE: About multicore OMAP
John, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Tuesday, February 23, 2010 8:01 PM To: Jacob john Cc: linux-omap@vger.kernel.org Subject: RE: About multicore OMAP -Original Message- From: Jacob john [mailto:jacob.joh...@gmail.com] Sent: Tuesday, February 23, 2010 7:51 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: About multicore OMAP It's Blaze with two lcd's and pico, looks great. Can I have this linux-omap kernel running on OMAP4?, plus I'm looking for SMP benchmark results etc. Linux-omap kernel with omap_4430sdp_defconfig will boot on blaze with SMP. This won't have lot of driver support as such currently. Also L2 cache support is in on the way to make it to mainline as well. You should be able to play with this with some basic benchmark test related to CPU. Display , Audio, Pico, keypad, touchscreeen etc drivers are available with the release and you should be able get more details from the TI contact person who gave you the blaze. You can also get the performance numbers from same source If you need the full kernel with all the drivers I mentioned above, you can use below git. http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=shortlog;h=refs/heads/L24.4 Regards, Santosh
RE: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, February 24, 2010 4:42 AM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Woodruff, Richard; Ghorai,
Sukumar
Subject: Re: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
* Shilimkar, Santosh santosh.shilim...@ti.com [100222 23:16]:
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Tuesday, February 23, 2010 4:37 AM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Woodruff, Richard; Ghorai,
Sukumar
Subject: Re: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
* Tony Lindgren t...@atomide.com [100222 13:35]:
* Shilimkar, Santosh santosh.shilim...@ti.com [100218 21:22]:
Bye the way just to add bit more clarity, this patch addresses TX
hardware restriction in the new UART IP used on omap3630 and omap4430.
First part of the fix for RX is already in mainline,
Commit: ce13d4716a276f4331d78ba28a5093a63822ab95
More details on this thread are here.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19447.html
Thanks, I've updated the comments for this patch with the link above
and added the whole series into omap for-next.
Except patches 8 and 9 as they break compile for mach-omap1
and need to be updated.
Patch 8 is alright and doesn't break omap1. Patch 7 and patch 9 needs
update to fix
the mach-omap1 build issue by moving irqs-44xx.h header file to plat-omap
directory.
Attached are updated 7 and 9.
Build tested for omap1 (omap_generic_1710_defconfig and
omap_h2_1610_defconfig) and boot
tested with omap3_defconfig on omap4430sdp board.
Next time, one patch per email please. And updates as replies
to the original patches, or else the whole series. And patches
as inline attachments.
Otherwise it's hard to keep track of the patches and comment
them.
Ok. Will take care next time.
I've updated your patch 9/9 with the following as in omap for-next
I was getting:
arch/arm/mach-omap2/usb-musb.c:97: Building for omap_3430sdp_defconfigred
(first use in this
function)
Building for
omap_3630sdp_defconfigch-omap2/usb-musb.c:97: error: (Each undeclared
identifier is reported only
once
arch/arm/mach-omap2/usb-musb.c:97: error: for each function it appears in.)
arch/arm/mach-omap2/usb-musb.c:98: error: 'INT_44XX_HS_USB_DMA' undeclared
(first use in this
function)
Looks like musb is also merged now. My yesterday's pull of omap-for-linus
didn't have musb.
Regards,
Tony
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -94,8 +94,8 @@ void __init usb_musb_init(struct omap_musb_board_data
*board_data)
musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
} else if (cpu_is_omap44xx()) {
musb_resources[0].start = OMAP44XX_HSUSB_OTG_BASE;
- musb_resources[1].start = INT_44XX_HS_USB_MC;
- musb_resources[2].start = INT_44XX_HS_USB_DMA;
+ musb_resources[1].start = OMAP44XX_IRQ_HS_USB_MC_N;
+ musb_resources[2].start = OMAP44XX_IRQ_HS_USB_DMA_N;
}
musb_resources[0].end = musb_resources[0].start + SZ_4K - 1;
Thanks for fixing 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: About multicore OMAP
-Original Message- From: Jacob john [mailto:jacob.joh...@gmail.com] Sent: Wednesday, February 24, 2010 10:16 AM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: About multicore OMAP On Tue, Feb 23, 2010 at 10:20 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: John, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Tuesday, February 23, 2010 8:01 PM To: Jacob john Cc: linux-omap@vger.kernel.org Subject: RE: About multicore OMAP -Original Message- From: Jacob john [mailto:jacob.joh...@gmail.com] Sent: Tuesday, February 23, 2010 7:51 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: About multicore OMAP It's Blaze with two lcd's and pico, looks great. Can I have this linux-omap kernel running on OMAP4?, plus I'm looking for SMP benchmark results etc. Linux-omap kernel with omap_4430sdp_defconfig will boot on blaze with SMP. This won't have lot of driver support as such currently. Also L2 cache support is in on the way to make it to mainline as well. You should be able to play with this with some basic benchmark test related to CPU. Display , Audio, Pico, keypad, touchscreeen etc drivers are available with the release and you should be able get more details from the TI contact person who gave you the blaze. You can also get the performance numbers from same source If you need the full kernel with all the drivers I mentioned above, you can use below git. http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=shortlog;h=refs/heads/L24.4 Good help so far.., wondering why two trees for OMAP4, tell me the diff b/n this list and the zoom. is there a different mailing list for zoom? confusing... and I am sorrythanks for the pointers The mailing list is only one (Linux-omap). There is no difference. Linux-omap tree is almost mainline equivalent from omap4 point of view. The features are developed on the tree I mentioned above. The tested features will be up-streamed after rebasing one by one. You will find only upstreamed/lined-up features in linux-omap tree. Regards, Santosh
RE: [PATCH 00/11] OMAP clock/hwmod: final set of 2.6.34 patches
Paul,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul
Walmsley
Sent: Tuesday, February 23, 2010 10:20 AM
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: [PATCH 00/11] OMAP clock/hwmod: final set of 2.6.34 patches
Hello,
Here are a few more OMAP clock and hwmod patches intended for 2.6.34,
posted in case anyone has any review comments.
These patches have been boot-tested on OSK5912, N800, 2430SDP,
Overo; and compile-tested on 4430SDP.
I have boot tested this series and earlier two series on OMAP4430 SDP.
They boot fine.
---
size:
text data bss dec hex filename
2882000127872 88872 3098744 2f4878 vmlinux.osk5912.orig
2882016127872 88872 3098760 2f4888 vmlinux.osk5912.patched
2324953121440 63728 2510121 264d29 vmlinux.n8x0.orig
2325885121536 63728 2511149 26512d vmlinux.n8x0.patched
3422044176928 146928 3745900 39286c vmlinux.2430sdp.orig
3423048177024 146928 3747000 392cb8 vmlinux.2430sdp.patched
6060161 1797424 5800396 13657981 d0677d vmlinux.omap3.orig
6061113 1797488 5800396 13658997 d06b75 vmlinux.omap3.patched
2049131168736 65412 2283279 22d70f vmlinux.4430sdp.orig
2050167169632 65412 2285211 22de9b vmlinux.4430sdp.patched
Paul Walmsley (7):
OMAP clock: add omap_clk_get_by_name() for use by OMAP hwmod core code
OMAP hwmod: convert hwmod to use hardware clock names rather than
clkdev dev+con
OMAP hwmod: convert header files with static allocations into C files
OMAP hwmod: add hwmod class support
OMAP clockdomain: if no autodeps exist, don't try to add or remove them
OMAP2/3 clock: combine OMAP2 3 boot-time MPU rate change code
OMAP2+ clock: revise omap2_clk_{disable,enable}()
Rajendra Nayak (1):
OMAP4: clock: Rename leaf clock nodes to end with a _ick or _fck
Santosh Shilimkar (2):
OMAP4: clock: Add dummy clock nodes for interface clocks
OMAP4: clock: Remove clock hacks from timer-gp.c
Vimarsh Zutshi (1):
From 5c87e27fd557a56aca72cd10529c3bdcb0c8a517 Mon Sep 17 00:00:00 2001
arch/arm/configs/omap_4430sdp_defconfig |7
arch/arm/mach-omap1/clock.c | 14 -
arch/arm/mach-omap1/clock_data.c |6
arch/arm/mach-omap2/Makefile | 12 -
arch/arm/mach-omap2/clock.c | 220 --
arch/arm/mach-omap2/clock.h |5
arch/arm/mach-omap2/clock2xxx.c | 34 -
arch/arm/mach-omap2/clock3xxx.c | 59 ---
arch/arm/mach-omap2/clock3xxx_data.c |2
arch/arm/mach-omap2/clock44xx_data.c | 596
++
arch/arm/mach-omap2/clockdomain.c| 16 +
arch/arm/mach-omap2/io.c | 21 -
arch/arm/mach-omap2/omap_hwmod.c | 244 ++-
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 38 +-
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 38 +-
arch/arm/mach-omap2/omap_hwmod_34xx.h| 168 ---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 181
arch/arm/mach-omap2/omap_hwmod_common_data.c | 24 +
arch/arm/mach-omap2/omap_hwmod_common_data.h | 24 +
arch/arm/mach-omap2/timer-gp.c |5
arch/arm/plat-omap/clock.c | 37 ++
arch/arm/plat-omap/include/plat/clock.h |3
arch/arm/plat-omap/include/plat/omap_hwmod.h | 71 ++-
23 files changed, 1073 insertions(+), 752 deletions(-)
rename arch/arm/mach-omap2/{omap_hwmod_2420.h = omap_hwmod_2420_data.c}
(82%)
rename arch/arm/mach-omap2/{omap_hwmod_2430.h = omap_hwmod_2430_data.c}
(83%)
delete mode 100644 arch/arm/mach-omap2/omap_hwmod_34xx.h
create mode 100644 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
create mode 100644 arch/arm/mach-omap2/omap_hwmod_common_data.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
RE: DMA example
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Philip Balister Sent: Thursday, February 25, 2010 1:04 AM To: linux-omap@vger.kernel.org Subject: DMA example I am trying to setup a dma operation to copy memory from GPMC address space into RAM. The only examples using the omap-dma api use hardware triggers. What you mean by GPMC address space. Are you trying to DMA data from NAND/NOR to SDRAM/SRAM ? When I start a transfer, I end up with a DMA transaction error when I start the transfer. Does anyone have a good example of a software transfer? Currently, I am tracing the omap dma api to see how things map into the registers Philip -- 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: DMA example
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Philip
Balister
Sent: Thursday, February 25, 2010 9:56 AM
To: Tony Lindgren
Cc: linux-omap@vger.kernel.org
Subject: Re: DMA example
On 02/24/2010 06:24 PM, Philip Balister wrote:
Any more clues?
Never mind, I am an idiot. Not out of the woods, but things are
happening again :)
Attached is the example module for memory to memory transfer. The module test
is for RAM to RAM but you can easily adapt to you need.
It's slightly old but should help you to set the dma parameters correctly
Regards,
Santosh
/*
* /vobs/wtbu/OMAPSW_L/linux/test/device_driver_test/dma/test_code/dmatest.c
*
* Dma Test Module
*
* Copyright (C) 2004-2006 Texas Instruments, Inc.
*
* This package 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.
*
* THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
* WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*/
#include linux/kernel.h
#include linux/module.h
#include linux/init.h
#include linux/proc_fs.h
#include linux/sched.h
#include asm/io.h
#include linux/version.h
/** KERNEL SPECIFIC STUFF */
#if (LINUX_VERSION_CODE = KERNEL_VERSION(2,6,00))
#include linux/dma-mapping.h
#endif /* kernel specs */
#include dmatest.h
#if (LINUX_VERSION_CODE = KERNEL_VERSION(2,6,27))
#include mach/dma.h
#else
#include asm/arch/dma.h
#endif
/** GENERAL VARS */
/* load-time options */
int debug = DEFAULT_DEBUG_LVL;
int channels = 2;
int maximum_transfers = 5; /* max transfers per channel */
int buf_size = PAGE_SIZE; /* Buffer size for each channel */
int prio = -1;
int burst = -1;
int query_idx = 0;
static struct dma_stat_id_s *stat_id;
static struct dma_buf_id_s *buf_id;
#if (LINUX_VERSION_CODE KERNEL_VERSION(2,6,00))
MODULE_PARM(debug, i);
MODULE_PARM(channels, i);
MODULE_PARM(maximum_transfers, i);
MODULE_PARM(buf_size, i);
#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
MODULE_PARM(prio, i);
MODULE_PARM(query_idx, i);
MODULE_PARM(burst, i);
#endif // CONFIG_ARCH_OMAP24XX
#else
module_param(debug, int, 0444);
module_param(channels, int, 0444);
module_param(maximum_transfers, int, 0444);
module_param(buf_size, int, 0444);
#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
module_param(prio, int, 0444);
module_param(burst, int, 0444);
module_param(query_idx, int, 0444);
#endif
#endif
struct dma_test_s {
int dev_id;
int dma_ch;
};
static struct dma_test_s dma_test[MAX_CHANNELS];
/** TEST LOGIC */
static int get_lch(int channel)
{
int i = 0;
for (i = 0; i MAX_CHANNELS; i++) {
if (dma_test[i].dma_ch == channel)
break;
}
if (i == MAX_CHANNELS)
return -EPERM;
return i;
}
static void dma_callback(int lch, u16 ch_status, void *data)
{
struct dma_test_s *t = (struct dma_test_s *)data;
int idx = get_lch(lch);
int status = 1;
FN_IN();
printk(%d: , lch);
if (lch == t-dma_ch) {
ch_status = ~(OMAP_DMA_BLOCK_IRQ);
if (!ch_status !buf_verify(buf_id, idx, buf_size)) {
printk(P\n);
status = 0;
} else {
printk(F\n);
}
/* Dont care abt the continuing the transfer */
(void)stat_update(stat_id, idx, status);
} else {
D(4, dma_callback(): Unexpected event on channel %d, lch);
}
#ifdef DMA_DUMP
{
int i;
/* Dump all the dma registers for all channels */
for (i = 0; i channels; i++) {
printk(CH %d\n, i);
omap_dump_lch_reg(dma_test[i].dma_ch);
}
}
#endif
FN_OUT(0);
}
static void __exit dmatest_cleanup(void)
{
int i;
FN_IN();
for (i = 0; i channels; i++) {
if (dma_test[i].dma_ch = 0) {
omap_stop_dma(dma_test[i].dma_ch);
omap_free_dma(dma_test[i].dma_ch);
dma_test[i].dma_ch = -1;
}
}
buf_free(buf_id, channels, buf_size);
stat_exit(stat_id);
FN_OUT(0);
}
static int __init dmatest_init(void)
{
int i;
int elem_count, frame_count;
unsigned int src, dest;
int ret = 0;
FN_IN();
if (channels MAX_CHANNELS) {
ERR(channels arg (%d) MAX_CHANNELS (%d)\n,
RE: About multicore OMAP
-Original Message-
From: Jacob john [mailto:jacob.joh...@gmail.com]
Sent: Thursday, February 25, 2010 7:37 PM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org
Subject: Re: About multicore OMAP
On Wed, Feb 24, 2010 at 10:24 AM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
-Original Message-
From: Jacob john [mailto:jacob.joh...@gmail.com]
Sent: Wednesday, February 24, 2010 10:16 AM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org
Subject: Re: About multicore OMAP
On Tue, Feb 23, 2010 at 10:20 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
John,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Shilimkar, Santosh
Sent: Tuesday, February 23, 2010 8:01 PM
To: Jacob john
Cc: linux-omap@vger.kernel.org
Subject: RE: About multicore OMAP
-Original Message-
From: Jacob john [mailto:jacob.joh...@gmail.com]
Sent: Tuesday, February 23, 2010 7:51 PM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org
Subject: Re: About multicore OMAP
It's Blaze with two lcd's and pico, looks great. Can I have this
linux-omap kernel running on OMAP4?, plus I'm looking for SMP
benchmark results etc.
Linux-omap kernel with omap_4430sdp_defconfig will boot on blaze with
SMP. This
won't have lot of driver support as such currently. Also L2 cache
support is in
on the way to make it to mainline as well. You should be able to play
with this
with some basic benchmark test related to CPU.
Display , Audio, Pico, keypad, touchscreeen etc drivers are available
with the
release and you should be able get more details from the TI contact
person who
gave you the blaze. You can also get the performance numbers from same
source
If you need the full kernel with all the drivers I mentioned above, you
can use
below git.
http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=shortlog;h=refs/heads/L24.4
Good help so far.., wondering why two trees for OMAP4, tell me the
diff b/n this list and the zoom.
is there a different mailing list for zoom? confusing... and I am
sorrythanks for the pointers
The mailing list is only one (Linux-omap). There is no difference.
Linux-omap
tree is almost mainline equivalent from omap4 point of view. The features
are developed
on the tree I mentioned above. The tested features will be up-streamed
after rebasing
one by one. You will find only upstreamed/lined-up features in linux-omap
tree.
Thanks Sentosh for your help, what do you advise? you always wanted me
to go to zoom, so I don't have to pull from Linux-omap.
When I should use zoom and when I should come back to Linux-omap?
please clarify. Good way to ask which is latest? :)
I am sorry, I am confusedhelp me
The dev.omapzoom.org trees gets updated regularly with linux-omap/maininle. So
basically
it is ( Linux-omap-master + Additional drivers including IPC). So you can use
the
git available on dev.omapzoom.org. This will enable you to have all the drivers
in
one tree.
Regards,
Santosh
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: About multicore OMAP
-Original Message- From: Jacob john [mailto:jacob.joh...@gmail.com] Sent: Thursday, February 25, 2010 7:58 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: About multicore OMAP On Thu, Feb 25, 2010 at 7:45 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: -Original Message- From: Jacob john [mailto:jacob.joh...@gmail.com] Sent: Thursday, February 25, 2010 7:37 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: About multicore OMAP On Wed, Feb 24, 2010 at 10:24 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: -Original Message- From: Jacob john [mailto:jacob.joh...@gmail.com] Sent: Wednesday, February 24, 2010 10:16 AM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: About multicore OMAP On Tue, Feb 23, 2010 at 10:20 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: John, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Tuesday, February 23, 2010 8:01 PM To: Jacob john Cc: linux-omap@vger.kernel.org Subject: RE: About multicore OMAP -Original Message- From: Jacob john [mailto:jacob.joh...@gmail.com] Sent: Tuesday, February 23, 2010 7:51 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: About multicore OMAP It's Blaze with two lcd's and pico, looks great. Can I have this linux-omap kernel running on OMAP4?, plus I'm looking for SMP benchmark results etc. Linux-omap kernel with omap_4430sdp_defconfig will boot on blaze with SMP. This won't have lot of driver support as such currently. Also L2 cache support is in on the way to make it to mainline as well. You should be able to play with this with some basic benchmark test related to CPU. Display , Audio, Pico, keypad, touchscreeen etc drivers are available with the release and you should be able get more details from the TI contact person who gave you the blaze. You can also get the performance numbers from same source If you need the full kernel with all the drivers I mentioned above, you can use below git. http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=shortlog;h=refs/heads/L24.4 Good help so far.., wondering why two trees for OMAP4, tell me the diff b/n this list and the zoom. is there a different mailing list for zoom? confusing... and I am sorrythanks for the pointers The mailing list is only one (Linux-omap). There is no difference. Linux-omap tree is almost mainline equivalent from omap4 point of view. The features are developed on the tree I mentioned above. The tested features will be up-streamed after rebasing one by one. You will find only upstreamed/lined-up features in linux-omap tree. Thanks Sentosh for your help, what do you advise? you always wanted me to go to zoom, so I don't have to pull from Linux-omap. When I should use zoom and when I should come back to Linux-omap? please clarify. Good way to ask which is latest? :) I am sorry, I am confusedhelp me The dev.omapzoom.org trees gets updated regularly with linux-omap/maininle. So basically it is ( Linux-omap-master + Additional drivers including IPC). So you can use the git available on dev.omapzoom.org. This will enable you to have all the drivers in one tree. Sounds great, appreciate this, TI gave Android kernel, so from omapzoom I get Android kernel? please share GIT url path for the same, any readme is there like Linux-omap? thanks for your help Here is the link for the android git. http://dev.omapzoom.org/?p=vikram/omap3.git;a=shortlog;h=refs/heads/android-2.6.32-omap4 Regards, Santosh
RE: [RESEND][PATCH/RFC] OMAP2: serial.c: Fix number of uarts in early_init
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, February 26, 2010 12:28 AM To: Shilimkar, Santosh Cc: Thomas Weber; Aguirre, Sergio; linux-omap@vger.kernel.org; Russell King; Kevin Hilman; Pandita, Vikram; Syed, Rafiuddin; linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org; Thomas Weber Subject: Re: [RESEND][PATCH/RFC] OMAP2: serial.c: Fix number of uarts in early_init * Shilimkar, Santosh santosh.shilim...@ti.com [100225 10:51]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, February 26, 2010 12:14 AM To: Thomas Weber; Aguirre, Sergio Cc: linux-omap@vger.kernel.org; Russell King; Kevin Hilman; Shilimkar, Santosh; Pandita, Vikram; Syed, Rafiuddin; linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org; Thomas Weber Subject: Re: [RESEND][PATCH/RFC] OMAP2: serial.c: Fix number of uarts in early_init * Thomas Weber sw...@gmx.li [100225 01:36]: The omap_serial_early_init prints the following errors: Could not get uart4_ick Could not get uart4_fck because all the uarts available in omap_uart[] will be initialized. Only omap4430 and omap3630 have 4 uarts at the moment. This patch reduces the number of uarts when cpu is not omap4430 or omap3630. ..and I only patched omap_serial_init and forgot about the omap_serial_early_init.. Looks good to me, Sergio, care to test and Ack this? Also, sounds like we still need to patch omap4 for uart4 for the clocks. Clocks will be take care automatically by nr_ports for omap4 too with this patch. Below clock changes are just cosmetic ones, isn't it ? Am I missing something? Yes sorry, I'm referring to [RFC][PATCH 0/3] OMAP3630: UART4 startup series to fix the uart4 issues for 3630, not omap4. 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: [RESEND][PATCH/RFC] OMAP2: serial.c: Fix number of uarts in early_init
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, February 26, 2010 12:14 AM
To: Thomas Weber; Aguirre, Sergio
Cc: linux-omap@vger.kernel.org; Russell King; Kevin Hilman; Shilimkar,
Santosh; Pandita, Vikram;
Syed, Rafiuddin; linux-arm-ker...@lists.infradead.org;
linux-ker...@vger.kernel.org; Thomas Weber
Subject: Re: [RESEND][PATCH/RFC] OMAP2: serial.c: Fix number of uarts in
early_init
* Thomas Weber sw...@gmx.li [100225 01:36]:
The omap_serial_early_init prints the following errors:
Could not get uart4_ick
Could not get uart4_fck
because all the uarts available in omap_uart[] will be initialized.
Only omap4430 and omap3630 have 4 uarts at the moment.
This patch reduces the number of uarts when cpu is not omap4430 or
omap3630.
..and I only patched omap_serial_init and forgot about
the omap_serial_early_init..
Looks good to me, Sergio, care to test and Ack this? Also, sounds
like we still need to patch omap4 for uart4 for the clocks.
Clocks will be take care automatically by nr_ports for omap4 too
with this patch. Below clock changes are just cosmetic ones, isn't it ?
Am I missing something?
Regards,
Tony
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/serial.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index b79bc89..da77930 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -644,16 +644,21 @@ static void serial_out_override(struct uart_port *up,
int offset, int value)
}
void __init omap_serial_early_init(void)
{
- int i;
+ int i, nr_ports;
char name[16];
+ if (!(cpu_is_omap3630() || cpu_is_omap4430()))
+ nr_ports = 3;
+ else
+ nr_ports = ARRAY_SIZE(omap_uart);
+
/*
* Make sure the serial ports are muxed on at this point.
* You have to mux them off in device drivers later on
* if not needed.
*/
- for (i = 0; i ARRAY_SIZE(omap_uart); i++) {
+ for (i = 0; i nr_ports; i++) {
struct omap_uart_state *uart = omap_uart[i];
struct platform_device *pdev = uart-pdev;
struct device *dev = pdev-dev;
@@ -669,17 +674,17 @@ void __init omap_serial_early_init(void)
continue;
}
- sprintf(name, uart%d_ick, i+1);
+ sprintf(name, uart%d_ick, i + 1);
uart-ick = clk_get(NULL, name);
if (IS_ERR(uart-ick)) {
- printk(KERN_ERR Could not get uart%d_ick\n, i+1);
+ printk(KERN_ERR Could not get uart%d_ick\n, i + 1);
uart-ick = NULL;
}
sprintf(name, uart%d_fck, i+1);
uart-fck = clk_get(NULL, name);
if (IS_ERR(uart-fck)) {
- printk(KERN_ERR Could not get uart%d_fck\n, i+1);
+ printk(KERN_ERR Could not get uart%d_fck\n, i + 1);
uart-fck = NULL;
}
--
1.6.4.4
--
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] omap: i2c: Add i2c support on omap4 platform
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, February 26, 2010 3:17 AM
To: Shilimkar, Santosh
Cc: ben-li...@fluff.org; linux-omap@vger.kernel.org;
linux-...@vger.kernel.org; Syed, Rafiuddin; Cory
Maccarrone
Subject: Re: [PATCH] omap: i2c: Add i2c support on omap4 platform
* Shilimkar, Santosh santosh.shilim...@ti.com [100222 21:58]:
Ben,
Did you happen to look at this ?
Santosh, can you please also please clarify which omaps this
patch has been tested on?
This patch is tested on OMAP3430 SDP and OMAP4430 SDP with regular defconfig
builds and multi-omap build.
-Original Message-
From: Shilimkar, Santosh
Sent: Friday, February 19, 2010 10:03 PM
To: ben-li...@fluff.org
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; Shilimkar,
Santosh; Syed, Rafiuddin;
Cory
Maccarrone
Subject: [PATCH] omap: i2c: Add i2c support on omap4 platform
This patch is rebased version of earlier post to add I2C
driver support to OMAP4 platform. On OMAP4, all
I2C register address offsets are changed from OMAP1/2/3 I2C.
In order to not have #ifdef's at various places in code,
as well as to support multi-OMAP build, an array is created
to hold the register addresses with it's offset.
This patch was submitted, reviewed and acked on mailing list
already. For more details refer below link
http://www.mail-archive.com/linux-...@vger.kernel.org/msg02281.html
This updated verion has a depedancy on Add support for 16-bit registers
posted on linux-omap. Below is the patch-works link for the same
http://patchwork.kernel.org/patch/72295/
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Paul Walmsley p...@pwsan.com
Reviewed-by: Tony Lindgren t...@atomide.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Cory Maccarrone darkstar6...@gmail.com
---
drivers/i2c/busses/i2c-omap.c | 146
-
1 files changed, 114 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9c3ce4d..7c15496 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -44,29 +44,37 @@
/* I2C controller revisions present on specific hardware */
#define OMAP_I2C_REV_ON_2430 0x36
#define OMAP_I2C_REV_ON_3430 0x3C
+#define OMAP_I2C_REV_ON_4430 0x40
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
-#define OMAP_I2C_REV_REG 0x00
-#define OMAP_I2C_IE_REG 0x01
-#define OMAP_I2C_STAT_REG0x02
-#define OMAP_I2C_IV_REG 0x03
/* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
-#define OMAP_I2C_WE_REG 0x03
-#define OMAP_I2C_SYSS_REG0x04
-#define OMAP_I2C_BUF_REG 0x05
-#define OMAP_I2C_CNT_REG 0x06
-#define OMAP_I2C_DATA_REG0x07
-#define OMAP_I2C_SYSC_REG0x08
-#define OMAP_I2C_CON_REG 0x09
-#define OMAP_I2C_OA_REG 0x0a
-#define OMAP_I2C_SA_REG 0x0b
-#define OMAP_I2C_PSC_REG 0x0c
-#define OMAP_I2C_SCLL_REG0x0d
-#define OMAP_I2C_SCLH_REG0x0e
-#define OMAP_I2C_SYSTEST_REG 0x0f
-#define OMAP_I2C_BUFSTAT_REG 0x10
+enum {
+ OMAP_I2C_REV_REG = 0,
+ OMAP_I2C_IE_REG,
+ OMAP_I2C_STAT_REG,
+ OMAP_I2C_IV_REG,
+ OMAP_I2C_WE_REG,
+ OMAP_I2C_SYSS_REG,
+ OMAP_I2C_BUF_REG,
+ OMAP_I2C_CNT_REG,
+ OMAP_I2C_DATA_REG,
+ OMAP_I2C_SYSC_REG,
+ OMAP_I2C_CON_REG,
+ OMAP_I2C_OA_REG,
+ OMAP_I2C_SA_REG,
+ OMAP_I2C_PSC_REG,
+ OMAP_I2C_SCLL_REG,
+ OMAP_I2C_SCLH_REG,
+ OMAP_I2C_SYSTEST_REG,
+ OMAP_I2C_BUFSTAT_REG,
+ OMAP_I2C_REVNB_LO,
+ OMAP_I2C_REVNB_HI,
+ OMAP_I2C_IRQSTATUS_RAW,
+ OMAP_I2C_IRQENABLE_SET,
+ OMAP_I2C_IRQENABLE_CLR,
+};
/* I2C Interrupt Enable Register (OMAP_I2C_IE): */
#define OMAP_I2C_IE_XDR (1 14) /* TX Buffer drain int
enable */
@@ -169,6 +177,7 @@ struct omap_i2c_dev {
u32 speed; /* Speed of bus in Khz */
u16 cmd_err;
u8 *buf;
+ u8 *regs;
size_t buf_len;
struct i2c_adapter adapter;
u8 fifo_size; /* use as flag and value
@@ -187,15 +196,64 @@ struct omap_i2c_dev {
u16 westate;
};
+const static u8 reg_map[] = {
+ [OMAP_I2C_REV_REG] = 0x00,
+ [OMAP_I2C_IE_REG] = 0x01,
+ [OMAP_I2C_STAT_REG] = 0x02,
+ [OMAP_I2C_IV_REG
RE: Using DEBUG_LL?
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio Sent: Friday, February 26, 2010 8:03 PM To: Tony Lindgren Cc: linux-omap@vger.kernel.org; Pandita, Vikram Subject: Using DEBUG_LL? Hi, Wit the current master branch, I tried enabling DEBUG_LL, and EARLY_PRINTK options, but I can't see the LL output as usual (#... kind of thing) on my 3630SDP. Is there a patch to enable it after the serial cleanup patches? I think DEBUG_LL on zoom boards is broken because they use external quad-uart. Vikram reported this on list some time back. 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: Using DEBUG_LL?
-Original Message- From: Gadiyar, Anand Sent: Friday, February 26, 2010 8:33 PM To: Shilimkar, Santosh; Aguirre, Sergio; Tony Lindgren Cc: linux-omap@vger.kernel.org; Pandita, Vikram Subject: RE: Using DEBUG_LL? Wit the current master branch, I tried enabling DEBUG_LL, and EARLY_PRINTK options, but I can't see the LL output as usual (#... kind of thing) on my 3630SDP. Is there a patch to enable it after the serial cleanup patches? I think DEBUG_LL on zoom boards is broken because they use external quad-uart. Vikram reported this on list some time back. No, looks like this is broken on SDPs as well. Either that, or I haven't understood how to use the early_printk option. I have the same problem on my 3430 SDP and manually patch kernel/printk.c with the patch in Tony's omap-debug branch. Missed that point. I always need patch ascii hack to printk to ger LL_DEBUG working. -- 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] omap: i2c: Add i2c support on omap4 platform
Tony,
What we do with patch now? It's more almost 6 months that this patch is
floating without merge.
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Shilimkar, Santosh
Sent: Friday, February 26, 2010 10:28 AM
To: Tony Lindgren
Cc: ben-li...@fluff.org; linux-omap@vger.kernel.org;
linux-...@vger.kernel.org; Syed, Rafiuddin; Cory
Maccarrone
Subject: RE: [PATCH] omap: i2c: Add i2c support on omap4 platform
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, February 26, 2010 3:17 AM
To: Shilimkar, Santosh
Cc: ben-li...@fluff.org; linux-omap@vger.kernel.org;
linux-...@vger.kernel.org; Syed, Rafiuddin;
Cory
Maccarrone
Subject: Re: [PATCH] omap: i2c: Add i2c support on omap4 platform
* Shilimkar, Santosh santosh.shilim...@ti.com [100222 21:58]:
Ben,
Did you happen to look at this ?
Santosh, can you please also please clarify which omaps this
patch has been tested on?
This patch is tested on OMAP3430 SDP and OMAP4430 SDP with regular defconfig
builds and multi-omap build.
-Original Message-
From: Shilimkar, Santosh
Sent: Friday, February 19, 2010 10:03 PM
To: ben-li...@fluff.org
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; Shilimkar,
Santosh; Syed, Rafiuddin;
Cory
Maccarrone
Subject: [PATCH] omap: i2c: Add i2c support on omap4 platform
This patch is rebased version of earlier post to add I2C
driver support to OMAP4 platform. On OMAP4, all
I2C register address offsets are changed from OMAP1/2/3 I2C.
In order to not have #ifdef's at various places in code,
as well as to support multi-OMAP build, an array is created
to hold the register addresses with it's offset.
This patch was submitted, reviewed and acked on mailing list
already. For more details refer below link
http://www.mail-archive.com/linux-...@vger.kernel.org/msg02281.html
This updated verion has a depedancy on Add support for 16-bit
registers
posted on linux-omap. Below is the patch-works link for the same
http://patchwork.kernel.org/patch/72295/
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Paul Walmsley p...@pwsan.com
Reviewed-by: Tony Lindgren t...@atomide.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Cory Maccarrone darkstar6...@gmail.com
---
drivers/i2c/busses/i2c-omap.c | 146
-
1 files changed, 114 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c
b/drivers/i2c/busses/i2c-omap.c
index 9c3ce4d..7c15496 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -44,29 +44,37 @@
/* I2C controller revisions present on specific hardware */
#define OMAP_I2C_REV_ON_2430 0x36
#define OMAP_I2C_REV_ON_3430 0x3C
+#define OMAP_I2C_REV_ON_4430 0x40
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
-#define OMAP_I2C_REV_REG 0x00
-#define OMAP_I2C_IE_REG0x01
-#define OMAP_I2C_STAT_REG 0x02
-#define OMAP_I2C_IV_REG0x03
/* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
-#define OMAP_I2C_WE_REG0x03
-#define OMAP_I2C_SYSS_REG 0x04
-#define OMAP_I2C_BUF_REG 0x05
-#define OMAP_I2C_CNT_REG 0x06
-#define OMAP_I2C_DATA_REG 0x07
-#define OMAP_I2C_SYSC_REG 0x08
-#define OMAP_I2C_CON_REG 0x09
-#define OMAP_I2C_OA_REG0x0a
-#define OMAP_I2C_SA_REG0x0b
-#define OMAP_I2C_PSC_REG 0x0c
-#define OMAP_I2C_SCLL_REG 0x0d
-#define OMAP_I2C_SCLH_REG 0x0e
-#define OMAP_I2C_SYSTEST_REG 0x0f
-#define OMAP_I2C_BUFSTAT_REG 0x10
+enum {
+ OMAP_I2C_REV_REG = 0,
+ OMAP_I2C_IE_REG,
+ OMAP_I2C_STAT_REG,
+ OMAP_I2C_IV_REG,
+ OMAP_I2C_WE_REG,
+ OMAP_I2C_SYSS_REG,
+ OMAP_I2C_BUF_REG,
+ OMAP_I2C_CNT_REG,
+ OMAP_I2C_DATA_REG,
+ OMAP_I2C_SYSC_REG,
+ OMAP_I2C_CON_REG,
+ OMAP_I2C_OA_REG,
+ OMAP_I2C_SA_REG,
+ OMAP_I2C_PSC_REG,
+ OMAP_I2C_SCLL_REG,
+ OMAP_I2C_SCLH_REG,
+ OMAP_I2C_SYSTEST_REG,
+ OMAP_I2C_BUFSTAT_REG,
+ OMAP_I2C_REVNB_LO,
+ OMAP_I2C_REVNB_HI,
+ OMAP_I2C_IRQSTATUS_RAW,
+ OMAP_I2C_IRQENABLE_SET
RE: [PATCH] omap: i2c: Add i2c support on omap4 platform
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Sunday, February 28, 2010 2:11 AM To: Shilimkar, Santosh Cc: ben-li...@fluff.org; linux-omap@vger.kernel.org; linux-...@vger.kernel.org; Syed, Rafiuddin; Cory Maccarrone; a...@linux-foundation.org Subject: Re: [PATCH] omap: i2c: Add i2c support on omap4 platform * Shilimkar, Santosh santosh.shilim...@ti.com [100226 20:05]: Tony, What we do with patch now? It's more almost 6 months that this patch is floating without merge. Well first we should test it for all omaps. So let's add it into omap-testing for a few days to make sure it does not break anything. Then let's ask Ben to queue it. Ok with me. 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] OMAP: DMA: Add API for setting channel dest addr
Manju,
Is this patch can build?
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of G,
Manjunath Kondaiah
Sent: Tuesday, March 02, 2010 3:46 PM
To: linux-omap@vger.kernel.org
Cc: G, Manjunath Kondaiah; Tony Lindgren; S, Venkatraman; Raja, Govindraj
Subject: [PATCH] OMAP: DMA: Add API for setting channel dest addr
The new API - omap_set_dma_dst_pos(int lch, int value) is added
for setting channel destination address in CPC/CDAC register
Cc: Tony Lindgren t...@atomide.com
Cc: S, Venkatraman svenk...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Signed-off-by: Govindraj R govindraj.r...@ti.com
---
arch/arm/plat-omap/dma.c | 17 +
arch/arm/plat-omap/include/plat/dma.h |1 +
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 2ab224c..9a2a5c4 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1109,6 +1109,23 @@ dma_addr_t omap_get_dma_dst_pos(int lch)
}
EXPORT_SYMBOL(omap_get_dma_dst_pos);
+/**
+ * omap_set_dma_dst_pos() - Set DMA channel destination address
+ * @arg1: lch DMA logical channel number
+ * @arg2: valueValue to write into CDAC register
+ *
+ * Writes value into the register CPC/CDAC
+ */
+void omap_set_dma_dst_pos(int lch, int value)
+{
+ if (cpu_is_omap15xx())
+ dma_write(CPC(lch), value);
+ else
+ dma_write(CDAC(lcd), value);
Should be dma_write(CDAC(lch), value);
+
+}
+EXPORT_SYMBOL(omap_set_dma_dst_pos);
+
int omap_get_dma_active_status(int lch)
{
return (dma_read(CCR(lch)) OMAP_DMA_CCR_EN) != 0;
diff --git a/arch/arm/plat-omap/include/plat/dma.h
b/arch/arm/plat-omap/include/plat/dma.h
index 02232ca..3b6e43e 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -509,6 +509,7 @@ extern int omap_set_dma_callback(int lch,
void *data);
extern dma_addr_t omap_get_dma_src_pos(int lch);
extern dma_addr_t omap_get_dma_dst_pos(int lch);
+extern void omap_set_dma_dst_pos(int lch, int value);
extern void omap_clear_dma(int lch);
extern int omap_get_dma_active_status(int lch);
extern int omap_dma_running(void);
--
1.6.0.4
--
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] serial: Add OMAP high-speed UART driver.
snip snip -- CDAC is a shadow register used for monitoring the DMA channel. I think it would be a lot simpler if omap_start_dma() always resets CDAC to 0, and the UART driver just not set it explicitly. This seems to be better option than exposing CDAC read/write API to other drivers since user need to write '0' before starting any DMA transfer which can be be done in omap_start_dma(). I am wondering how other drivers are using DMA transfer API's without resetting CDAC to zero. It's needed only if some one is interested in that count. UART seems to using this counter where as other driver don't. Why do you think drivers need to know about counter value ? 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] serial: Add OMAP high-speed UART driver.
-Original Message- From: G, Manjunath Kondaiah Sent: Tuesday, March 02, 2010 8:34 PM To: Shilimkar, Santosh; S, Venkatraman; Tony Lindgren; Raja, Govindraj; Greg KH; linux- ser...@vger.kernel.org; linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; Kevin Hilman; Olof Johansson Subject: RE: [PATCH] serial: Add OMAP high-speed UART driver. Santosh, -Original Message- From: Shilimkar, Santosh Sent: Tuesday, March 02, 2010 7:34 PM To: G, Manjunath Kondaiah; S, Venkatraman; Tony Lindgren; Raja, Govindraj; Greg KH; linux-ser...@vger.kernel.org; linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; Kevin Hilman; Olof Johansson Subject: RE: [PATCH] serial: Add OMAP high-speed UART driver. snip snip -- CDAC is a shadow register used for monitoring the DMA channel. I think it would be a lot simpler if omap_start_dma() always resets CDAC to 0, and the UART driver just not set it explicitly. This seems to be better option than exposing CDAC read/write API to other drivers since user need to write '0' before starting any DMA transfer which can be be done in omap_start_dma(). I am wondering how other drivers are using DMA transfer API's without resetting CDAC to zero. It's needed only if some one is interested in that count. UART seems to using this counter where as other driver don't. Why do you think drivers need to know about counter value ? Reading of non zero value(after reset to zero and enabling dma channel) from CDAC register indicates that, DMA transfer has started and user can rely on DMA4_CCENi and DMA4_CCFNi element and frame counters. If the CDAC value is zero even after starting DMA channel, indicates error. Not necessary. The DMA can still wait for the hw sync signal and the CDAC can remain 0 if the hw sync in not received. This will be any way returned by DMA error ( SYNC lost) This register was mainly suppose to be used for debug purposes. 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: About multicore OMAP
-Original Message- From: Jacob john [mailto:jacob.joh...@gmail.com] Sent: Wednesday, March 03, 2010 7:27 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: About multicore OMAP On Thu, Feb 25, 2010 at 8:04 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: -Original Message- From: Jacob john [mailto:jacob.joh...@gmail.com] Sent: Thursday, February 25, 2010 7:58 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: About multicore OMAP On Thu, Feb 25, 2010 at 7:45 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: -Original Message- From: Jacob john [mailto:jacob.joh...@gmail.com] Sent: Thursday, February 25, 2010 7:37 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: About multicore OMAP On Wed, Feb 24, 2010 at 10:24 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: -Original Message- From: Jacob john [mailto:jacob.joh...@gmail.com] Sent: Wednesday, February 24, 2010 10:16 AM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: About multicore OMAP On Tue, Feb 23, 2010 at 10:20 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: John, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Tuesday, February 23, 2010 8:01 PM To: Jacob john Cc: linux-omap@vger.kernel.org Subject: RE: About multicore OMAP -Original Message- From: Jacob john [mailto:jacob.joh...@gmail.com] Sent: Tuesday, February 23, 2010 7:51 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: About multicore OMAP It's Blaze with two lcd's and pico, looks great. Can I have this linux-omap kernel running on OMAP4?, plus I'm looking for SMP benchmark results etc. Linux-omap kernel with omap_4430sdp_defconfig will boot on blaze with SMP. This won't have lot of driver support as such currently. Also L2 cache support is in on the way to make it to mainline as well. You should be able to play with this with some basic benchmark test related to CPU. Display , Audio, Pico, keypad, touchscreeen etc drivers are available with the release and you should be able get more details from the TI contact person who gave you the blaze. You can also get the performance numbers from same source If you need the full kernel with all the drivers I mentioned above, you can use below git. http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=shortlog;h=refs/heads/L24.4 Good help so far.., wondering why two trees for OMAP4, tell me the diff b/n this list and the zoom. is there a different mailing list for zoom? confusing... and I am sorrythanks for the pointers The mailing list is only one (Linux-omap). There is no difference. Linux-omap tree is almost mainline equivalent from omap4 point of view. The features are developed on the tree I mentioned above. The tested features will be up-streamed after rebasing one by one. You will find only upstreamed/lined-up features in linux-omap tree. Thanks Sentosh for your help, what do you advise? you always wanted me to go to zoom, so I don't have to pull from Linux-omap. When I should use zoom and when I should come back to Linux-omap? please clarify. Good way to ask which is latest? :) I am sorry, I am confusedhelp me The dev.omapzoom.org trees gets updated regularly with linux-omap/maininle. So basically it is ( Linux-omap-master + Additional drivers including IPC). So you can use the git available on dev.omapzoom.org. This will enable you to have all the drivers in one tree. Sounds great, appreciate this, TI gave Android kernel, so from omapzoom I get Android kernel? please share GIT url path for the same, any readme is there like Linux-omap? thanks for your help Here is the link for the android git. http://dev.omapzoom.org/?p=vikram/omap3.git;a=shortlog;h=refs/heads/android-2.6.32-omap4 Sentosh, can I have uboot link for omap4, thanks for your help. http://dev.omapzoom.org/?p=bootloader/u-boot.git;a=shortlog;h=refs/heads/omap4_dev Regards, Santosh
RE: mainline - build breaks with omap3_defconfig
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Gadiyar, Anand Sent: Thursday, March 04, 2010 7:37 PM To: Linux OMAP Mailing List; Tony Lindgren Subject: mainline - build breaks with omap3_defconfig Hi, Felipe already reported one issue with the board-omap3touchbook.c causing a build break. After working around that, there's another build break when compiling the 4430SDP board file. CC arch/arm/mach-omap2/board-4430sdp.o /tmp/cc7lJWsG.s: Assembler messages: /tmp/cc7lJWsG.s:45: Error: selected processor does not support `dsb' /tmp/cc7lJWsG.s:46: Error: selected processor does not support `smc' make[1]: *** [arch/arm/mach-omap2/board-4430sdp.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 This one is fixed by Tony in a temporary patch Regards, Santosh build-fixes.patch Description: build-fixes.patch
RE: [PATCH] omap: i2c: Add i2c support on omap4 platform
-Original Message-
From: Ben Dooks [mailto:ben-li...@fluff.org]
Sent: Monday, March 08, 2010 3:48 AM
To: Shilimkar, Santosh
Cc: ben-li...@fluff.org; linux-omap@vger.kernel.org;
linux-...@vger.kernel.org; Syed, Rafiuddin; Cory
Maccarrone
Subject: Re: [PATCH] omap: i2c: Add i2c support on omap4 platform
On Fri, Feb 19, 2010 at 10:03:00PM +0530, Santosh Shilimkar wrote:
This patch is rebased version of earlier post to add I2C
driver support to OMAP4 platform. On OMAP4, all
I2C register address offsets are changed from OMAP1/2/3 I2C.
In order to not have #ifdef's at various places in code,
as well as to support multi-OMAP build, an array is created
to hold the register addresses with it's offset.
This patch was submitted, reviewed and acked on mailing list
already. For more details refer below link
http://www.mail-archive.com/linux-...@vger.kernel.org/msg02281.html
This updated verion has a depedancy on Add support for 16-bit registers
posted on linux-omap. Below is the patch-works link for the same
http://patchwork.kernel.org/patch/72295/
currently even with this patch applied it doesn't apply cleanly.
May be it needs refresh after recent merges? Are you ok if I refresh this patch
against latest mainline on top of below patch and repost
http://patchwork.kernel.org/patch/72295/
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Paul Walmsley p...@pwsan.com
Reviewed-by: Tony Lindgren t...@atomide.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Cory Maccarrone darkstar6...@gmail.com
---
drivers/i2c/busses/i2c-omap.c | 146
-
1 files changed, 114 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9c3ce4d..7c15496 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -44,29 +44,37 @@
/* I2C controller revisions present on specific hardware */
#define OMAP_I2C_REV_ON_2430 0x36
#define OMAP_I2C_REV_ON_3430 0x3C
+#define OMAP_I2C_REV_ON_4430 0x40
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
-#define OMAP_I2C_REV_REG 0x00
-#define OMAP_I2C_IE_REG0x01
-#define OMAP_I2C_STAT_REG 0x02
-#define OMAP_I2C_IV_REG0x03
/* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
-#define OMAP_I2C_WE_REG0x03
-#define OMAP_I2C_SYSS_REG 0x04
-#define OMAP_I2C_BUF_REG 0x05
-#define OMAP_I2C_CNT_REG 0x06
-#define OMAP_I2C_DATA_REG 0x07
-#define OMAP_I2C_SYSC_REG 0x08
-#define OMAP_I2C_CON_REG 0x09
-#define OMAP_I2C_OA_REG0x0a
-#define OMAP_I2C_SA_REG0x0b
-#define OMAP_I2C_PSC_REG 0x0c
-#define OMAP_I2C_SCLL_REG 0x0d
-#define OMAP_I2C_SCLH_REG 0x0e
-#define OMAP_I2C_SYSTEST_REG 0x0f
-#define OMAP_I2C_BUFSTAT_REG 0x10
+enum {
+ OMAP_I2C_REV_REG = 0,
+ OMAP_I2C_IE_REG,
+ OMAP_I2C_STAT_REG,
+ OMAP_I2C_IV_REG,
+ OMAP_I2C_WE_REG,
+ OMAP_I2C_SYSS_REG,
+ OMAP_I2C_BUF_REG,
+ OMAP_I2C_CNT_REG,
+ OMAP_I2C_DATA_REG,
+ OMAP_I2C_SYSC_REG,
+ OMAP_I2C_CON_REG,
+ OMAP_I2C_OA_REG,
+ OMAP_I2C_SA_REG,
+ OMAP_I2C_PSC_REG,
+ OMAP_I2C_SCLL_REG,
+ OMAP_I2C_SCLH_REG,
+ OMAP_I2C_SYSTEST_REG,
+ OMAP_I2C_BUFSTAT_REG,
+ OMAP_I2C_REVNB_LO,
+ OMAP_I2C_REVNB_HI,
+ OMAP_I2C_IRQSTATUS_RAW,
+ OMAP_I2C_IRQENABLE_SET,
+ OMAP_I2C_IRQENABLE_CLR,
+};
/* I2C Interrupt Enable Register (OMAP_I2C_IE): */
#define OMAP_I2C_IE_XDR(1 14) /* TX Buffer drain int
enable */
@@ -169,6 +177,7 @@ struct omap_i2c_dev {
u32 speed; /* Speed of bus in Khz */
u16 cmd_err;
u8 *buf;
+ u8 *regs;
size_t buf_len;
struct i2c_adapter adapter;
u8 fifo_size; /* use as flag and value
@@ -187,15 +196,64 @@ struct omap_i2c_dev {
u16 westate;
};
+const static u8 reg_map[] = {
+ [OMAP_I2C_REV_REG] = 0x00,
+ [OMAP_I2C_IE_REG] = 0x01,
+ [OMAP_I2C_STAT_REG] = 0x02,
+ [OMAP_I2C_IV_REG] = 0x03,
+ [OMAP_I2C_WE_REG] = 0x03,
+ [OMAP_I2C_SYSS_REG] = 0x04,
+ [OMAP_I2C_BUF_REG] = 0x05,
+ [OMAP_I2C_CNT_REG] = 0x06,
+ [OMAP_I2C_DATA_REG] = 0x07,
+ [OMAP_I2C_SYSC_REG] = 0x08,
+ [OMAP_I2C_CON_REG] = 0x09,
+ [OMAP_I2C_OA_REG] = 0x0a,
+ [OMAP_I2C_SA_REG] = 0x0b,
+ [OMAP_I2C_PSC_REG] = 0x0c
RE: [PATCH] omap: i2c: Add i2c support on omap4 platform
Ben, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Monday, March 08, 2010 10:31 AM To: Ben Dooks Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; Syed, Rafiuddin; Cory Maccarrone Subject: RE: [PATCH] omap: i2c: Add i2c support on omap4 platform -Original Message- From: Ben Dooks [mailto:ben-li...@fluff.org] Sent: Monday, March 08, 2010 3:48 AM To: Shilimkar, Santosh Cc: ben-li...@fluff.org; linux-omap@vger.kernel.org; linux-...@vger.kernel.org; Syed, Rafiuddin; Cory Maccarrone Subject: Re: [PATCH] omap: i2c: Add i2c support on omap4 platform On Fri, Feb 19, 2010 at 10:03:00PM +0530, Santosh Shilimkar wrote: This patch is rebased version of earlier post to add I2C driver support to OMAP4 platform. On OMAP4, all I2C register address offsets are changed from OMAP1/2/3 I2C. In order to not have #ifdef's at various places in code, as well as to support multi-OMAP build, an array is created to hold the register addresses with it's offset. This patch was submitted, reviewed and acked on mailing list already. For more details refer below link http://www.mail-archive.com/linux-...@vger.kernel.org/msg02281.html This updated verion has a depedancy on Add support for 16-bit registers posted on linux-omap. Below is the patch-works link for the same http://patchwork.kernel.org/patch/72295/ currently even with this patch applied it doesn't apply cleanly. May be it needs refresh after recent merges? Are you ok if I refresh this patch against latest mainline on top of below patch and repost http://patchwork.kernel.org/patch/72295/ Attached refreshed version which directly applies against the mainline since Add support for 16-bit registers is already merged. Boot tested on OMAP4 SDP platform. Regards, Santosh 0001-omap-i2c-Add-i2c-support-on-omap4-platform.patch Description: 0001-omap-i2c-Add-i2c-support-on-omap4-platform.patch
RE: [PATCH/RFT v3] OMAP4: fix temporary hacks that break multi-omap PM
Kevin,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin
Hilman
Sent: Tuesday, March 09, 2010 12:23 AM
To: linux-omap@vger.kernel.org
Subject: [PATCH/RFT v3] OMAP4: fix temporary hacks that break multi-omap PM
When building for multi-omap, and OMAP4 is enabled, CONFIG_ARCH_OMAP4
will be true and prevent included code from building/running for
OMAP2/3 as well.
This problem exists in io.c where some hwmod/PM/SDRC init code is
prevented from running even on OMAP2/3 when OMAP4 is included in a
multi-OMAP build.
A quick glance suggests that this #ifndef is no longer needed. The
called functions should work fine or fail gracefully in the OMAP4
case.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
Needs testing on OMAP4 since still no OMAP4 hardware here.
Did you build test this ?
This patch breaks builds on latest linux-omap master and mainline.
omap_4430sdp_defconfig
arch/arm/mach-omap2/built-in.o: In function `omap2_init_common_hw':
/work/linux-omap-2.6/arch/arm/mach-omap2/io.c:334: undefined reference to
`omap_hwmod_late_init'
/work/linux-omap-2.6/arch/arm/mach-omap2/io.c:336: undefined reference to
`omap2_sdrc_init'
make: *** [.tmp_vmlinux1] Error 1
omap3_defconfig
arch/arm/mach-omap2/built-in.o: In function `omap2_init_common_hw':
/work/linux-omap-2.6/arch/arm/mach-omap2/io.c:315: undefined reference to
`omap2430_hwmod_init'
make: *** [.tmp_vmlinux1] Error 1
Updates from v2:
- actually applies to l-o master
Updates from v1:
- removed additional #ifdef block in init_common_hw()
arch/arm/mach-omap2/io.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 402e8f0..595446f 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -309,7 +309,6 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
{
pwrdm_init(powerdomains_omap);
clkdm_init(clockdomains_omap, clkdm_autodeps);
-#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once the clkdev is ready */
if (cpu_is_omap242x())
omap2420_hwmod_init();
else if (cpu_is_omap243x())
@@ -319,7 +318,6 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
omap2_mux_init();
/* The OPP tables have to be registered before a clk init */
omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
-#endif
if (cpu_is_omap2420())
omap2420_clk_init();
@@ -333,11 +331,10 @@ void __init omap2_init_common_hw(struct
omap_sdrc_params *sdrc_cs0,
pr_err(Could not init clock framework - unknown CPU\n);
omap_serial_early_init();
-#ifndef CONFIG_ARCH_OMAP4
omap_hwmod_late_init();
omap_pm_if_init();
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
_omap2_init_reprogram_sdrc();
-#endif
+
gpmc_init();
}
--
1.7.0.2
--
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/RFT 0/2] fixes for broken PM init with multi-OMAP
Thanks Kevin, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Tuesday, March 09, 2010 10:34 PM To: linux-omap@vger.kernel.org Subject: [PATCH/RFT 0/2] fixes for broken PM init with multi-OMAP multi-OMAP builds are broken in various ways due to conditional code. Here is a small series of fixes. Build tested: omap3_defconfig, omap_4430sdp_defconfig Boot tested: omap3_defconfig on OMAP3EVM Applied this series on l-o master (dc73899a58be5e834b8df3a9049cdb1115acf175) OMAP3430 SDP boots normal. Needs boot testing on OMAP4. OMAP4 also boots with omap3_defconfig after unchecking the reset unused clock check. This is known and will be fixed soon. Applies on current l-o master branch. Kevin Hilman (2): OMAP2: cpu_is_omap2*: optimize out unused code. OMAP4: fix temporary hacks that break multi-omap PM arch/arm/mach-omap2/io.c | 13 ++--- arch/arm/plat-omap/include/plat/cpu.h |8 ++-- 2 files changed, 12 insertions(+), 9 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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/RFT 2/2] OMAP4: fix temporary hacks that break multi-omap PM
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin
Hilman
Sent: Tuesday, March 09, 2010 10:34 PM
To: linux-omap@vger.kernel.org
Subject: [PATCH/RFT 2/2] OMAP4: fix temporary hacks that break multi-omap PM
When building for multi-omap, and OMAP4 is enabled, CONFIG_ARCH_OMAP4
will be true and prevent included code from building/running for
OMAP2/3 as well.
This problem exists in io.c where some hwmod/PM/SDRC init code is
prevented from running even on OMAP2/3 when OMAP4 is included in a
multi-OMAP build.
A quick glance suggests that this #ifndef is no longer needed in most
of the cases. In the remaining cases, the function is wrapped with
if (cpu_is_omap24xx() || cpu_is_omap34xx()) which will be optimized
out for OMAP4-only builds.
Note that this is only a short-term fix. Longer-term, OMAP4
needs to create init functions for SDRC and hwmod late-init.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/io.c | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 402e8f0..f33409c 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -309,7 +309,6 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
{
pwrdm_init(powerdomains_omap);
clkdm_init(clockdomains_omap, clkdm_autodeps);
-#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once the clkdev is ready */
if (cpu_is_omap242x())
omap2420_hwmod_init();
else if (cpu_is_omap243x())
@@ -319,7 +318,6 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
omap2_mux_init();
/* The OPP tables have to be registered before a clk init */
omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
-#endif
if (cpu_is_omap2420())
omap2420_clk_init();
@@ -333,11 +331,12 @@ void __init omap2_init_common_hw(struct
omap_sdrc_params *sdrc_cs0,
pr_err(Could not init clock framework - unknown CPU\n);
omap_serial_early_init();
-#ifndef CONFIG_ARCH_OMAP4
- omap_hwmod_late_init();
+ if (cpu_is_omap24xx() || cpu_is_omap34xx()) /* FIXME: OMAP4 */
This is in pipeline with ongoing hwmod work.
+ omap_hwmod_late_init();
omap_pm_if_init();
- omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
- _omap2_init_reprogram_sdrc();
-#endif
+ if (cpu_is_omap24xx() || cpu_is_omap34xx()) { /* FIXME: OMAP4 */
This FIXME should be removed because there no SDRC on OMAP4.
+ omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
+ _omap2_init_reprogram_sdrc();
+ }
gpmc_init();
}
--
1.7.0.2
--
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: FEATURES - is it good enough (was Re: [PATCH v3 1/2] omap: introduce uart_no_empty_fifo_read feature)
Started reading threads today -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Menon, Nishanth Sent: Friday, November 20, 2009 9:47 PM To: Aguirre, Sergio Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: FEATURES - is it good enough (was Re: [PATCH v3 1/2] omap: introduce uart_no_empty_fifo_read feature) Aguirre, Sergio had written, on 11/20/2009 10:14 AM, the following: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Nishanth Menon Sent: Friday, November 20, 2009 10:10 AM To: Pandita, Vikram Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH v3 1/2] omap: introduce uart_no_empty_fifo_read feature Vikram Pandita had written, on 11/20/2009 10:02 AM, the following: Interoduce omap feature OMAP3_HAS_UART_NO_EMPTY_FIFO_READ ^ - you meant introduce On omap3630/omap4 an empty fifo read causes a crash Signed-off-by: Vikram Pandita vikram.pand...@ti.com Ack-by: Menon, Nishanth n...@ti.com ^ - :P nope you dont have my Acked-by until you change this to Acked from Ack ;).. Thanks for the simpler patch. --- arch/arm/mach-omap2/id.c |7 +++ arch/arm/plat-omap/include/plat/cpu.h |2 ++ 2 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index f48a4b2..3e266cd 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -176,6 +176,12 @@ void __init omap3_check_features(void) OMAP3_CHECK_FEATURE(status, NEON); OMAP3_CHECK_FEATURE(status, ISP); + /* On omap3630 and omap4: UART empty rx fifo read aborts */ + if (cpu_is_omap3630()) + omap3_features |= OMAP3_HAS_UART_NO_EMPTY_FIFO_READ; + if (cpu_is_omap44xx()) + omap3_features |= OMAP3_HAS_UART_NO_EMPTY_FIFO_READ; + Probably not something ot be attached in this patch, but... I'm a bit curious about something: Why touching omap3_features in OMAP4? Isn't there a omap4_features? Or even better, an omap_features? This is_feature suppose to take care of Errata's also, is it? This is errata more than a feature. We better differentiate in this regard 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: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver.
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Olof Johansson Sent: Tuesday, November 24, 2009 10:52 PM To: G, Manjunath Kondaiah Cc: Govindraj; g...@lixom.net; Tony Lindgren; linux- o...@vger.kernel.org; Pandita, Vikram; Raja, Govindraj Subject: Re: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver. On Tue, Nov 24, 2009 at 03:04:09PM +0530, G, Manjunath Kondaiah wrote: -Original Message- From: Olof Johansson [mailto:o...@lixom.net] Sent: Monday, November 23, 2009 10:36 PM To: Govindraj; g...@lixom.net Cc: Tony Lindgren; linux-omap@vger.kernel.org; Pandita, Vikram; Raja, Govindraj; G, Manjunath Kondaiah Subject: Re: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver. On Fri, Nov 20, 2009 at 03:21:26PM +0530, Govindraj wrote: I have not seen any comments on this patch series yet. Tony, Is there something I need to modify? Govindaj, I'm having problems with these patches on Zoom2 with debug board, since they don't seem to coexist very well together with 8250. Enabling both options will result in build errors. Why do we need to enable both 8250 and omap-serial for console. The console UART can be either external UART or any one of the omap UART right? You should allow both of them to be enabled at the same time, so the same kernel can for example be booted on a ZOOM2 with debug board attached (8250 on GPMC), or on a beagle/overo board. Making them exclusive would be a step backwards. More so, selecting both config option really shouldn't break the build. If one expect a build break because only one of the options can be enabled then clearly the dependency should be used so that user can select only one option at a time. 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/8] Series short description
Tony, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Thursday, November 26, 2009 5:49 AM To: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org Subject: [PATCH 0/8] Series short description Hi all, Here are some omap mux updates for review. These are intended for the v2.6.33 merge window. Initially this series changes the omap34xx mux code, I'm planning on adding 3630, 2420, and 2430 code later on. There are several reasons why we need better mux code: - We want to make the mux code more generic and this will allow us to use the internal signal names and gpio numbers instead of mux register offsets. The internal signal names stay the same across omap generations for some devices. - We need to map mux registers to GPIO registers for dynamic muxing of the GPIO pins during off-idle. - We want to be able to override the bootloader mux values for the modded boards, such as the Beagle. - We want to have the mux signals and balls available under debugfs for debugging new drivers. Some of these might eventually work for other archs too, so let me know if you have any comments on that. Thanks for the series. Managing mux is always an issue and most time consuming one. This series will improve mux code greatly. 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/8] omap2: mux: intoduce omap_mux_{read,write}
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Thursday, November 26, 2009 5:49 AM
To: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org; Mike Rapoport
Subject: [PATCH 1/8] omap2: mux: intoduce omap_mux_{read,write}
From: Mike Rapoport m...@compulab.co.il
intoduce omap_mux_{read,write}
Signed-off-by: Mike Rapoport m...@compulab.co.il
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/mux.c | 44
++--
1 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index c18a94e..64250c5 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -35,7 +35,27 @@
#ifdef CONFIG_OMAP_MUX
+#define OMAP_MUX_BASE_OFFSET 0x30/* Offset from CTRL_BASE
*/
+#define OMAP_MUX_BASE_SZ 0x5ca
+
static struct omap_mux_cfg arch_mux_cfg;
+static void __iomem *mux_base;
+
+static inline u16 omap_mux_read(u16 reg)
+{
+ if (cpu_is_omap24xx())
+ return __raw_readb(mux_base + reg);
+ else
+ return __raw_readw(mux_base + reg);
+}
+
+static inline void omap_mux_write(u16 val, u16 reg)
+{
+ if (cpu_is_omap24xx())
+ __raw_writeb(val, mux_base + reg);
This will work on board but the code relies on underneath function typecast
here. OMAP24xx reg write suppose to be 8 bit and __raw_writeb will take care of
this with forced typecast.
+ else
+ __raw_writew(val, mux_base + reg);
+}
/* NOTE: See mux.h for the enumeration */
@@ -581,10 +601,7 @@ static void __init_or_module
omap2_cfg_debug(const struct pin_config *cfg, u16 r
u16 orig;
u8 warn = 0, debug = 0;
- if (cpu_is_omap24xx())
- orig = omap_ctrl_readb(cfg-mux_reg);
- else
- orig = omap_ctrl_readw(cfg-mux_reg);
+ orig = omap_mux_read(cfg-mux_reg - OMAP_MUX_BASE_OFFSET);
#ifdef CONFIG_OMAP_MUX_DEBUG
debug = cfg-debug;
@@ -614,7 +631,7 @@ static int __init_or_module
omap24xx_cfg_reg(const struct pin_config *cfg)
if (cfg-pu_pd_val)
reg |= OMAP2_PULL_UP;
omap2_cfg_debug(cfg, reg);
- omap_ctrl_writeb(reg, cfg-mux_reg);
+ omap_mux_write(reg, cfg-mux_reg - OMAP_MUX_BASE_OFFSET);
spin_unlock_irqrestore(mux_spin_lock, flags);
return 0;
@@ -633,7 +650,7 @@ static int __init_or_module
omap34xx_cfg_reg(const struct pin_config *cfg)
spin_lock_irqsave(mux_spin_lock, flags);
reg |= cfg-mux_val;
omap2_cfg_debug(cfg, reg);
- omap_ctrl_writew(reg, cfg-mux_reg);
+ omap_mux_write(reg, cfg-mux_reg - OMAP_MUX_BASE_OFFSET);
spin_unlock_irqrestore(mux_spin_lock, flags);
return 0;
@@ -644,6 +661,21 @@ static int __init_or_module
omap34xx_cfg_reg(const struct pin_config *cfg)
int __init omap2_mux_init(void)
{
+ u32 mux_pbase;
+
+ if (cpu_is_omap2420())
+ mux_pbase = OMAP2420_CTRL_BASE + OMAP_MUX_BASE_OFFSET;
+ else if (cpu_is_omap2430())
+ mux_pbase = OMAP243X_CTRL_BASE + OMAP_MUX_BASE_OFFSET;
+ else if (cpu_is_omap34xx())
+ mux_pbase = OMAP343X_CTRL_BASE + OMAP_MUX_BASE_OFFSET;
+
+ mux_base = ioremap(mux_pbase, OMAP_MUX_BASE_SZ);
The control modules on OMAP's divided into 2 domains with different base address
1. pads in CORE power domain
2. Pads in wakeup domain.
If we map these two separately, then we can differentiate the wakeup capable
pads.
Not sure whether I am making any sense here but just thought it would be useful.
+ if (!mux_base) {
+ printk(KERN_ERR mux: Could not ioremap\n);
+ return -ENODEV;
+ }
+
if (cpu_is_omap24xx()) {
arch_mux_cfg.pins = omap24xx_pins;
arch_mux_cfg.size = OMAP24XX_PINS_SZ;
--
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 2/5] ARM: OMAP4: PM: Basic OMAP4 clock framework
Rajendra,
Some minor comments / queries
snip
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Rajendra Nayak
Sent: Tuesday, December 01, 2009 5:57 PM
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Cc: Nayak, Rajendra; Paul Walmsley; Cousson, Benoit
Subject: [PATCH 2/5] ARM: OMAP4: PM: Basic OMAP4 clock framework
This patch registers the OMAP4430 clock
nodes with the CLKDEV framework.
Enables CLKDEV for OMAP4.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/Makefile|8 +-
arch/arm/mach-omap2/clock.c |8 +
arch/arm/mach-omap2/clock44xx.c | 331
+++
arch/arm/mach-omap2/cm.h|4 +
arch/arm/mach-omap2/gpmc.c |2 +-
arch/arm/mach-omap2/io.c|4 +-
arch/arm/plat-omap/Kconfig |1 +
arch/arm/plat-omap/clock.c | 26 ---
arch/arm/plat-omap/include/mach/clock.h |3 +
9 files changed, 354 insertions(+), 33 deletions(-)
create mode 100644 arch/arm/mach-omap2/clock44xx.c
+#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is
in place */
Commenting style. This is at multiple places.
if (clk-clkdm)
omap2_clkdm_clk_disable(clk-clkdm, clk);
+#endif
}
}
@@ -448,8 +452,10 @@ int omap2_clk_enable(struct clk *clk)
int ret = 0;
.
diff --git a/arch/arm/mach-omap2/clock44xx.c b/arch/arm/mach-
omap2/clock44xx.c
new file mode 100644
index 000..e015200
--- /dev/null
+++ b/arch/arm/mach-omap2/clock44xx.c
@@ -0,0 +1,331 @@
+/*
+ * OMAP4-specific clock framework functions
+ *
+ * Copyright (C) 2009 Texas Instruments, Inc.
+ *
+ * Rajendra Nayak (rna...@ti.com)
+ *
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License version 2
as
+ * published by the Free Software Foundation.
+ */
+#undef DEBUG
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/device.h
+#include linux/list.h
+#include linux/errno.h
+#include linux/delay.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/limits.h
+#include linux/bitops.h
+
+#include mach/clock.h
+#include mach/sram.h
+#include asm/div64.h
+#include asm/clkdev.h
+
+#include mach/sdrc.h
+#include clock.h
+#include prm.h
+#include prm-regbits-44xx.h
+#include cm.h
+#include cm-regbits-44xx.h
+
+
+static const struct clkops clkops_noncore_dpll_ops;
+
+#include clock44xx.h
+
+struct omap_clk {
+ u32 cpu;
+ struct clk_lookup lk;
+};
+
+#define CLK(dev, con, ck, cp)\
+ { \
+ .cpu = cp, \
+ .lk = { \
+ .dev_id = dev, \
+ .con_id = con, \
+ .clk = ck, \
+ }, \
+ }
+
+#define CK_443X (1 0)
+
+static struct omap_clk omap44xx_clks[] = {
+ CLK(NULL, extalt_clkin_ck, extalt_clkin_ck,
CK_443X),
Are we still keeping these 'dev as NULL ? This is applicable to most of the
table. May be a follow up patch on this needed. Also lines are exceeding 80
char's in the table.
+ CLK(NULL, pad_clks_ck, pad_clks_ck,
CK_443X),
+ CLK(NULL, pad_slimbus_core_clks_ck,
pad_slimbus_core_clks_ck, CK_443X),
+ CLK(NULL, secure_32k_clk_src_ck,
secure_32k_clk_src_ck, CK_443X),
.
+static struct clk_functions omap2_clk_functions = {
+ .clk_enable = omap2_clk_enable,
+ .clk_disable= omap2_clk_disable,
+ .clk_round_rate = omap2_clk_round_rate,
+ .clk_set_rate = omap2_clk_set_rate,
+ .clk_set_parent = omap2_clk_set_parent,
+ .clk_disable_unused = omap2_clk_disable_unused,
+};
+
+/*
+ * Dummy functions for DPLL control. Plan is to re-use
+ * existing OMAP3 dpll control functions.
+ */
+
+static unsigned long omap3_dpll_recalc(struct clk *clk)
+{
+ return 0;
+}
+
+static int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
long rate)
+{
+ return 0;
+}
+
+static int omap3_noncore_dpll_enable(struct clk *clk)
+{
+ return 0;
+}
+
+static void omap3_noncore_dpll_disable(struct clk *clk)
+{
+ return;
+}
+
+static const struct clkops clkops_noncore_dpll_ops = {
+ .enable = omap3_noncore_dpll_enable,
+ .disable= omap3_noncore_dpll_disable,
+};
+
+void omap2_clk_prepare_for_reboot(void)
+{
+ return;
+}
+
+static int __init omap2_clk_arch_init(void)
+{
+ if (!mpurate)
+ return -EINVAL;
+
+
RE: [PATCH 3/5] ARM: OMAP4: PM: Move DPLL control apis to dpll.c
snip -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Nayak, Rajendra Sent: Tuesday, December 01, 2009 5:57 PM To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Cc: Nayak, Rajendra; Paul Walmsley; Cousson, Benoit Subject: [PATCH 3/5] ARM: OMAP4: PM: Move DPLL control apis to dpll.c This patch moves all the dpll control api's to a common file dpll.c. This is in preperation of omap4 support wherein most of these api's can be reused. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com --- arch/arm/mach-omap2/Makefile|3 +- arch/arm/mach-omap2/clock.h | 13 + arch/arm/mach-omap2/clock34xx.c | 511 - arch/arm/mach-omap2/clock34xx.h | 11 - arch/arm/mach-omap2/clock44xx.c |8 +- arch/arm/mach-omap2/clock44xx.h |4 - arch/arm/mach-omap2/dpll.c | 539 +++ 7 files changed, 558 insertions(+), 531 deletions(-) create mode 100644 arch/arm/mach-omap2/dpll.c On OMAP4, we might need an additional API since different DPLL outputs Like M2, M3 , M4 etc have individual gating control ( Bit 8) apart form DPLL gating. 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/6] OMAP4: update series
Tony, Russell, This series has fixes for OMAP4430 and generated against latest mainline kernel. The series is tested on OMAP4430SDP ES1.0 silicon It's needs an UART related patch which is in your(Tony's) queue. Please review the same. The following changes since commit 2588465badb648a50cd19623f0dd0063c90d4e31: Linus Torvalds (1): Merge branch 'bkl-arch-for-linus' of git://git.kernel.org/.../tip/linux-2.6-tip Santosh Shilimkar (6): OMAP4: Fix cpu detection OMAP4: Fix SRAM base and size OMAP4: Re-arrange the low level debug code OMAP4: AuxCoreBoot registers only accessible in secure mode. OMAP4: Remove the secondary wait loop. OMAP4: Sync up omap4430 defconfig arch/arm/configs/omap_4430sdp_defconfig| 146 ++-- arch/arm/mach-omap2/id.c | 27 - arch/arm/mach-omap2/include/mach/debug-macro.S | 13 ++- arch/arm/mach-omap2/omap-headsmp.S | 35 +-- arch/arm/mach-omap2/omap-smp.c | 31 ++ arch/arm/plat-omap/common.c|2 +- arch/arm/plat-omap/include/plat/cpu.h |3 +- arch/arm/plat-omap/include/plat/smp.h |2 + arch/arm/plat-omap/sram.c | 12 ++- 9 files changed, 171 insertions(+), 100 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
[PATCH 0/4] OMAP4: Enable L2 cache
Tony, Russell, This series is based on top of earlier series [1] and generated against latest Mainline. This enables the L2 cache support on OMAP4430 SDP platform. [1] http://patchwork.kernel.org/patch/66028/ [PATCH 0/6] OMAP4: update series The Errata patch [PATCH 3/4] may need to be streamlined bit since it's touching generic code. I didn't find a better way to patch this. Thanks for the review !! --- Santosh Shilimkar (4): OMAP4: Add L2 Cache support OMAP4: Clean the secondary_data from L2 ARM: L2 : Errata 588369: Clean Invalidate do not invalidate clean lines OMAP4: Enable L2 Cache arch/arm/Kconfig | 13 +++ arch/arm/configs/omap_4430sdp_defconfig|3 ++ arch/arm/mach-omap2/board-4430sdp.c| 30 ++ arch/arm/mach-omap2/omap-smp.c |2 + arch/arm/mm/Kconfig|2 +- arch/arm/mm/cache-l2x0.c | 32 arch/arm/plat-omap/include/plat/omap44xx.h |1 + 7 files changed, 82 insertions(+), 1 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/6] OMAP4: Sync up omap4430 defconfig
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Wednesday, December 09, 2009 12:29 PM To: t...@atomide.com Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; li...@arm.linux.org.uk; Shilimkar, Santosh Subject: [PATCH 6/6] OMAP4: Sync up omap4430 defconfig Enable minimum features to boot omap4430 on es1.0 samples Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/configs/omap_4430sdp_defconfig | 146 ++- 1 files changed, 84 insertions(+), 62 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index a464ca3..49df3ad 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -1,26 +1,29 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.30-rc7 -# Tue Jun 9 12:36:23 2009 +# Linux kernel version: 2.6.32 +# Sun Dec 6 23:37:45 2009 snip -# CONFIG_SYSFS_DEPRECATED=y is not set -# CONFIG_SYSFS_DEPRECATED_V2=y is not set +CONFIG_SYSFS_DEPRECATED_V2=y This is a deprecated feature and don't introduce it back again. There haven been patches in recent past to get rid of this. Thanks Vikram. The thing is some of the busy box people are using get confused and stuck without this. Do you have pointers to those 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 6/6] OMAP4: Sync up omap4430 defconfig
# Automatically generated make config: don't edit -# Linux kernel version: 2.6.30-rc7 -# Tue Jun 9 12:36:23 2009 +# Linux kernel version: 2.6.32 +# Sun Dec 6 23:37:45 2009 snip -# CONFIG_SYSFS_DEPRECATED=y is not set -# CONFIG_SYSFS_DEPRECATED_V2=y is not set +CONFIG_SYSFS_DEPRECATED_V2=y This is a deprecated feature and don't introduce it back again. There haven been patches in recent past to get rid of this. Thanks Vikram. The thing is some of the busy box people are using get confused and stuck without this. The reason is they have not upgraded to latest busybox yet. I guessed so. Time to upgrade the file system. Do you have pointers to those patches ? Here's the reference in k.org http://git.kernel.org/?p=linux/kernel/git/torvalds/linux- 2.6.git;a=commit;h=6502401d8169f76c6a72849cb55e8302226ca930 OK. Then we can get rid of this on OMAP4 too. 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/6] OMAP4: Fix cpu detection
-Original Message- From: Cousson, Benoit Sent: Thursday, December 10, 2009 1:04 AM To: Shilimkar, Santosh; t...@atomide.com Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; li...@arm.linux.org.uk Subject: RE: [PATCH 1/6] OMAP4: Fix cpu detection Hi Santosh, From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh This patch fixes the OMAP4430 cpu detection. Since the omap ID register is not fused in OMAP4430 ES1.0 silicon, identification is done using ARM CPUID register. I think that this description is not reflecting your current patch that does use the DEVICE_ID register. Yes. The second version uses ID_CODE but the commit message still refers to the 1st one. Will fix Commit message. -- 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/6] OMAP4: Fix cpu detection
Thanks Nishant !!
+ if ((hawkeye == 0xb852) (rev == 0x0)) {
+ omap_revision = OMAP4430_REV_ES1_0;
+ pr_info(OMAP%04x %s\n, omap_rev() 16, rev_name);
+ return;
+ }
+
+ printk(KERN_ERR Unknown OMAP CPU id\n);
a) Do you want to state unknown OMAP4 CPU id?
b) why not use pr_err?
OK
@@ -280,7 +280,7 @@ void __init omap2_set_globals_343x(void)
#if defined(CONFIG_ARCH_OMAP4)
static struct omap_globals omap4_globals = {
.class = OMAP443X_CLASS,
- .tap = OMAP2_L4_IO_ADDRESS(0x4830a000),
+ .tap = OMAP2_L4_IO_ADDRESS(OMAP443X_SCM_BASE),
What does this have to do with the subject of the patch? I agree it is
a good thing to have, but probably belongs elsewhere.
This is everything to do with subject. ID_CODE reg is in SCM and you
Need a right base to read that reg, Isn't it ?
.ctrl = OMAP2_L4_IO_ADDRESS(OMAP443X_CTRL_BASE),
.prm = OMAP2_L4_IO_ADDRESS(OMAP4430_PRM_BASE),
.cm = OMAP2_L4_IO_ADDRESS(OMAP4430_CM_BASE),
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 2e17890..2a141ba 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -443,7 +443,8 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP3505_REV(v) (OMAP35XX_CLASS | (0x3505 16) |
(v 12))
#define OMAP3517_REV(v) (OMAP35XX_CLASS | (0x3517 16) |
(v 12))
-#define OMAP443X_CLASS 0x44300034
+#define OMAP443X_CLASS 0x44300044
+#define OMAP4430_REV_ES1_0 0x44300044
Errr.. why? I suspect this might be to get the class and subclass right..
Dont we need an cpu_is_omap_4430() to use it correctly? (unless I
missed a pending patch series as I am checking l-o kernel codebase)..
do we need the following?
IS_OMAP_CLASS(44xx, 0x44)
IS_OMAP_SUBCLASS(443x, 0x443)
then you will have is_omap_443x() and you can now:
#define cpu_is_omap4430 is_omap443x()
This has to be done and I planning to do this in next series. This series just
enables the basic boot on ES1.0.
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 3/6] OMAP4: Re-arrange the low level debug code
-Original Message- From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com] Sent: Thursday, December 10, 2009 4:06 PM To: Shilimkar, Santosh Cc: t...@atomide.com; linux-omap@vger.kernel.org; li...@arm.linux.org.uk; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 3/6] OMAP4: Re-arrange the low level debug code Hello. Santosh Shilimkar wrote: On OMAP4430 the UART3 base address is different than that on OMAP3. Because of this existing code needs additional #ifdef'ry to accommodate that code. Hence this patch separates it. Also UART3 base address is fixed for OMAP4430 in this patch. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com [...] diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S b/arch/arm/mach- omap2/include/mach/debug-macro.S index e9f255d..b2b4b29 100644 --- a/arch/arm/mach-omap2/include/mach/debug-macro.S +++ b/arch/arm/mach-omap2/include/mach/debug-macro.S @@ -25,7 +25,7 @@ add \rx, \rx, #0x4000 @ UART 3 #endif -#elif defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4) +#elif CONFIG_ARCH_OMAP3 Why you've dropped defined()? This doesn't seem right as it should cause error when CONFIG_ARCH_OMAP3=n... Before omap4 support was added, it was as above. Now when I decided to go back and spilt it I changed it. How the ARCH flag will be n ? It will be either 0 or 1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/6 v2] OMAP4: Fix cpu detection
+void __init omap4_check_revision(void)
+{
+ u32 idcode;
+ u16 hawkeye;
+ u8 rev;
+ char *rev_name = ES1.0;
should'nt you decide this inside the rev check path?
This is initialized value by default. Since the chip is ES1.0 additionaly I am
not doing it.
e.g. for ES2.0, it would be done inside. +
+ /*
+* The IC rev detection is done with hawkeye and rev.
+* Note that rev does not map directly to defined processor
+* revision numbers as ES1.0 uses value 0.
+*/
+ idcode = read_tap_reg(OMAP_TAP_IDCODE);
+ hawkeye = (idcode 12) 0x;
+ rev = (idcode 28) 0xff;
+
+ if ((hawkeye == 0xb852) (rev == 0x0)) {
+ omap_revision = OMAP4430_REV_ES1_0;
+ pr_info(OMAP%04x %s\n, omap_rev() 16, rev_name);
wondering about the 16 part.
Why ?
+ return;
+ }
+
+ pr_err(Unknown OMAP4 CPU id\n);
+}
+
#define OMAP3_SHOW_FEATURE(feat) \
if (omap3_has_ ##feat())\
printk(#feat );
@@ -336,7 +361,7 @@ void __init omap2_check_revision(void)
omap3_check_features();
omap3_cpuinfo();
} else if (cpu_is_omap44xx()) {
- printk(KERN_INFO FIXME: CPU revision = OMAP4430\n);
+ omap4_check_revision();
return;
} else {
pr_err(OMAP revision unknown, please fix!\n);
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index cc050b3..3473a80 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -280,7 +280,7 @@ void __init omap2_set_globals_343x(void)
#if defined(CONFIG_ARCH_OMAP4)
static struct omap_globals omap4_globals = {
.class = OMAP443X_CLASS,
- .tap= OMAP2_L4_IO_ADDRESS(0x4830a000),
+ .tap= OMAP2_L4_IO_ADDRESS(OMAP443X_SCM_BASE),
.ctrl = OMAP2_L4_IO_ADDRESS(OMAP443X_CTRL_BASE),
.prm= OMAP2_L4_IO_ADDRESS(OMAP4430_PRM_BASE),
.cm = OMAP2_L4_IO_ADDRESS(OMAP4430_CM_BASE),
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 2e17890..9359785 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -176,11 +176,13 @@ IS_OMAP_CLASS(15xx, 0x15)
IS_OMAP_CLASS(16xx, 0x16)
IS_OMAP_CLASS(24xx, 0x24)
IS_OMAP_CLASS(34xx, 0x34)
+IS_OMAP_CLASS(44xx, 0x44)
IS_OMAP_SUBCLASS(242x, 0x242)
IS_OMAP_SUBCLASS(243x, 0x243)
IS_OMAP_SUBCLASS(343x, 0x343)
IS_OMAP_SUBCLASS(363x, 0x363)
+IS_OMAP_SUBCLASS(443x, 0x443)
#define cpu_is_omap7xx() 0
#define cpu_is_omap15xx() 0
@@ -408,8 +410,8 @@ IS_OMAP_TYPE(3517, 0x3517)
# if defined(CONFIG_ARCH_OMAP4)
# undef cpu_is_omap44xx
# undef cpu_is_omap443x
-# define cpu_is_omap44xx() 1
-# define cpu_is_omap443x() 1
+# define cpu_is_omap44xx() is_omap44xx()
+# define cpu_is_omap443x() is_omap443x()
# endif
/* Macros to detect if we have OMAP1 or OMAP2 */
@@ -443,7 +445,8 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP3505_REV(v)(OMAP35XX_CLASS | (0x3505 16) | (v
12))
#define OMAP3517_REV(v)(OMAP35XX_CLASS | (0x3517 16) | (v
12))
-#define OMAP443X_CLASS 0x44300034
+#define OMAP443X_CLASS 0x44300044
+#define OMAP4430_REV_ES1_0 0x44300044
/*
* omap_chip bits
neat.. thanks..
--
Regards,
Nishanth Menon
--
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 3/4] ARM: L2 : Errata 588369: Clean Invalidate do notinvalidate clean lines
Thanks for comments Catalin !!
-Original Message-
From: Catalin Marinas [mailto:catalin.mari...@arm.com]
Sent: Monday, December 14, 2009 4:07 PM
To: Shilimkar, Santosh
Cc: t...@atomide.com; linux-omap@vger.kernel.org; li...@arm.linux.org.uk;
linux-arm-
ker...@lists.infradead.org
Subject: Re: [PATCH 3/4] ARM: L2 : Errata 588369: Clean Invalidate do
notinvalidate clean lines
On Wed, 2009-12-09 at 18:43 +, Santosh Shilimkar wrote:
This patch implements the work-around for the errata 588369. The secure API
is used to alter L2 debug regsiter because of trust-zone.
[...]
+config PL310_ERRATA_588369
+ bool Clean Invalidate maintenance operations do not invalidate
clean lines
+ depends on CACHE_L2X0
+ default n
+ help
+ The PL310 L2 cache controller implements three types of Clean
+ Invalidate maintenance operations: by Physical Address
+ (offset 0x7F0), by Index/Way (0x7F8) and by Way (0x7FC).
+ They are architecturally defined to behave as the execution of a
+ clean operation followed immediately by an invalidate operation,
+ both performing to the same memory location. This functionality
+ is not correctly implemented in PL310 as clean lines are not
+ invalidated as a result of these operations
endmenu
Could you actually add a comment and a dependence on OMAP4 since this
requires the secure monitor that only TI has.
OK
+#ifdef CONFIG_PL310_ERRATA_588369
+ /*
+* Disable Write-Back and Cache Linefill (set bits [1:0] of the
Debug
+* Control Register)
+*/
+ __asm__ __volatile__(
+ stmfd r13!, {r0-r12, r14}\n
+ mov r0, #3\n
+ ldr r12, =0x100\n
+ dsb\n
+ smc\n
+ ldmfd r13!, {r0-r12, r14});
Could you actually add a function that gets called with a parameter
rather than having to similar inline asm blocks? You also don't need to
save/restore the registers if you declare them properly or use local
variables for that, the compiler does the work for you.
A function call would be better as you suggested. We will look into this.
Is a DSB needed before SMC (I'm not sure)?
That was a recommendation though not having it, I didn't observer any problems.
--
Catalin
--
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 2/4] input: misc: twl4030: move to request_threaded_irq
Felipe,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Felipe
Balbi
Sent: Monday, December 14, 2009 4:01 PM
To: linux-ker...@vger.kernel.org
Cc: Linux OMAP Mailing List; Tony Lindgren; Aaro Koskinen; David Brownell;
Linux USB Mailing List;
Anton Vorontsov; Grazvydas Ignotas; Chikkature Rajashekar, Madhusudhan; Greg
Kroah-Hartman; Mark
Brown; Samuel Ortiz; Felipe Balbi
Subject: [RFC/PATCH 2/4] input: misc: twl4030: move to request_threaded_irq
move to request_threaded_irq() on twl4030 children.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
drivers/input/misc/twl4030-pwrbutton.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/drivers/input/misc/twl4030-pwrbutton.c
b/drivers/input/misc/twl4030-pwrbutton.c
index f5fc997..cd47d9e 100644
--- a/drivers/input/misc/twl4030-pwrbutton.c
+++ b/drivers/input/misc/twl4030-pwrbutton.c
@@ -39,16 +39,6 @@ static irqreturn_t powerbutton_irq(int irq, void *_pwr)
int err;
u8 value;
-#ifdef CONFIG_LOCKDEP
- /* WORKAROUND for lockdep forcing IRQF_DISABLED on us, which
- * we don't want and can't tolerate since this is a threaded
- * IRQ and can sleep due to the i2c reads it has to issue.
- * Although it might be friendlier not to borrow this thread
- * context...
- */
- local_irq_enable();
-#endif
-
err = twl4030_i2c_read_u8(TWL4030_MODULE_PM_MASTER, value,
STS_HW_CONDITIONS);
if (!err) {
@@ -80,7 +70,7 @@ static int __devinit twl4030_pwrbutton_probe(struct
platform_device *pdev)
pwr-phys = twl4030_pwrbutton/input0;
pwr-dev.parent = pdev-dev;
- err = request_irq(irq, powerbutton_irq,
+ err = request_threaded_irq(irq, NULL, powerbutton_irq,
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
twl4030_pwrbutton, pwr);
if (err 0) {
In whole of the series the ISR you have converted to threads using threaded_irq
are very
small in size. They are like quick_change_handlers. So only advantage is the
particular
interrupt is masked for bit longer than with you change.
I might be wrong here but it might introduce the spurious IRQ's because of bit
of delay in the processing.What is the motive for this change ? Are we using
this API as it suppose to be ?
--
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 2/4] input: misc: twl4030: move to request_threaded_irq
-Original Message- From: Felipe Balbi [mailto:felipe.ba...@nokia.com] Sent: Monday, December 14, 2009 5:10 PM To: Shilimkar, Santosh Cc: Balbi Felipe (Nokia-D/Helsinki); linux-ker...@vger.kernel.org; Linux OMAP Mailing List; Tony Lindgren; Koskinen Aaro (Nokia-D/Helsinki); David Brownell; Linux USB Mailing List; Anton Vorontsov; Grazvydas Ignotas; Chikkature Rajashekar, Madhusudhan; Greg Kroah-Hartman; Mark Brown; Samuel Ortiz Subject: Re: [RFC/PATCH 2/4] input: misc: twl4030: move to request_threaded_irq Hi, On Mon, Dec 14, 2009 at 12:31:11PM +0100, ext Shilimkar, Santosh wrote: In whole of the series the ISR you have converted to threads using threaded_irq are very small in size. They are like quick_change_handlers. So only advantage is the particular interrupt is masked for bit longer than with you change. I might be wrong here but it might introduce the spurious IRQ's because of bit of delay in the processing.What is the motive for this change ? Are we using this API as it suppose to be ? the irq chip is connected through i2c and that mandate us to handle irqs in thread context. Now that we have kernel-wise api for that, we're just moving towards it instead of definint our own stuff and the lockdep shortcuts we had to put before. OK. I see your point 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: ARM tollchain support
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Niamathullah sharief Sent: Tuesday, December 15, 2009 6:22 PM To: linux-omap@vger.kernel.org Subject: ARM tollchain support Hello, I am trying to install ARM tollchain in my GCC. But i am not getting to install correctly. When i try to compile an u boot image i am getting the following errors in last few lines .. make[1]: Leaving directory `/home/ariem/Desktop/u-boot-200901-lange51/tools' make -C examples all make[1]: execvp: /home/ariem/CodeSourcery/Sourcery_G++_Lite/lib/gcc: Permission denied make[1]: Entering directory `/home/ariem/Desktop/u-boot-200901-lange51/examples' /bin/sh: /home/ariem/CodeSourcery/Sourcery_G++_Lite/lib/gcc: is a directory dirname: missing operand Try `dirname --help' for more information. /bin/sh: /home/ariem/CodeSourcery/Sourcery_G++_Lite/lib/gcc: is a directory dirname: missing operand Try `dirname --help' for more information. /home/ariem/CodeSourcery/Sourcery_G++_Lite/lib/gcc -Os -fno-strict-aliasing -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DTEXT_BASE=0x9780 -I/home/ariem/Desktop/u-boot-200901-lange51/include -fno-builtin -ffreestanding -nostdinc -isystem -pipe -DCONFIG_ARM -D__ARM__ -Wall -Wstrict-prototypes -c -o hello_world.o hello_world.c make[1]: execvp: /home/ariem/CodeSourcery/Sourcery_G++_Lite/lib/gcc: Permission denied make[1]: *** [hello_world.o] Error 127 make[1]: Leaving directory `/home/ariem/Desktop/u-boot-200901-lange51/examples' make: *** [examples] Error 2 ar...@ariem-desktop:~/Desktop/u-boot-200901-lange51$ what will be the error. can anyone tell me. i think the path exported is wrong. please help me How are you exporting the path ? Can you copy paste that here -- 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: Low level debugging using CONFIG_EARLY_PRINTK=y, omap-debug branch removed
Tony, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Wednesday, December 16, 2009 6:24 AM To: linux-omap@vger.kernel.org Subject: Low level debugging using CONFIG_EARLY_PRINTK=y, omap-debug branch removed Hi all, Recent commit 93fd03a8c6728b58879f8af20ffd55d9c32a778b added support for CONFIG_EARLY_PRINTK on ARM. Recent earlier kernels should work too by applying the patch in the commit above. This means we can now get rid of the old printk.c hack in the omap-debug branch, so I've deleted that branch. To use the earlyprintk, just do the following: 1. Make sure you have the necessary .config options set CONFIG_DEBUG_LL=y CONFIG_EARLY_PRINTK=y CONFIG_OMAP_LL_DEBUG_UART1=y # CONFIG_OMAP_LL_DEBUG_UART2 is not set # CONFIG_OMAP_LL_DEBUG_UART3 is not set The LL_DEBUG_UART above is typically 1, but it's 3 on Nokia boards. 2. Edit the kernel CMDLINE in your .config to have debug earlyprintk Optionally if you have a JTAG console, you can use CONFIG_DEBUG_ICEDCC instead LL_DEBUG_UART. I've also added these instructions to: http://www.elinux.org/Debugging_OMAP_kernel I tried this on couple of boards and at least it doesn't work with the options and mentioned bootargs. The low level debug prints are still not coming on console. I haven't debugged it though. 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: CPU consumption is going as high as 95% on ARM Cortex A8
-Original Message- From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-kernel- boun...@lists.infradead.org] On Behalf Of Hiremath, Vaibhav Sent: Thursday, December 17, 2009 11:09 AM To: li...@arm.linux.org.uk Cc: linux...@kvack.org; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: CPU consumption is going as high as 95% on ARM Cortex A8 Hi, I am seeing some strange behavior while accessing buffers through User Space (mapped using mmap call) Background :- Platform - TI AM3517 CPU - ARM Cortex A8 r...@am3517-evm:~# r...@am3517-evm:~# cat /proc/cpuinfo Processor : ARMv7 Processor rev 7 (v7l) BogoMIPS: 499.92 Features: swp half thumb fastmult vfp edsp neon vfpv3 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part: 0xc08 CPU revision: 7 Hardware: OMAP3517/AM3517 EVM Revision: 0020 Serial : r...@omap3517-evm:~# Issue/Usage :- - The V4l2-Capture driver captures the data from video decoder into buffer and the application does some processing on this buffer. The mmap implementation can be found at drivers/media/video/videobuf- dma-contig.c, function__videobuf_mmap_mapper(). Observation - The CPU consumption goes as high as 95% on read buffer operation, please note that write operation on these buffers also gives 60-70% CPU consumption. (Using memcpy/memset API's for read and write operation). Some more inputs :- -- - If I specify PAGE_READONLY or PAGE_SHARED (actual flag is L_PTE_USER) while mapping the buffer to UserSpace in mmap system call, the CPU consumption goes down to expected value (20-27%). Then I reached till the function cpu_v7_set_pte_ext, where we are configuring level 2 translation table entries, which makes use of these flags. - Below is the value of r0, r1 and r2 register (ptep, pteval, ext) in both the cases - Without PAGE_READONLY/PAGE_SHARED ptep - cfb5de10, pte - 8d200383, ext - 800 ptep - cfb5de14, pte - 8d201383, ext - 800 Which kernel version is this? Can you please also give values of PRRR, NMRR and SCTLR -- 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-v2][RFC] OMAP4: I2C Support for OMAP4430
Ben, -Original Message- From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-kernel- boun...@lists.infradead.org] On Behalf Of Syed, Rafiuddin Sent: Tuesday, December 15, 2009 5:49 PM To: Ben Dooks Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; linux-...@vger.kernel.org; ben- li...@fluff.org Subject: Re: [RESUBMIT][PATCH-v2][RFC] OMAP4: I2C Support for OMAP4430 Ben, Thu, 20 Aug 2009 14:19:04 -0700 On Tue, Aug 18, 2009 at 03:35:31PM +0530, Syed Rafiuddin wrote: Ben, On Fri, Jul 24, 2009 at 04:40:02PM +0530, Syed Rafiuddin wrote: Hi Ben, This patch adds OMAP4 support to the I2C driver. All I2C register addresses are different between OMAP1/2/3 and OMAP4. In order to not have #ifdef's at various places in code, as well as to support multi-OMAP build, Array's are created to hold the register addresses. Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com --- No comment received on this patch, Is there anything that I need to resolve? Else can this patch get merged. sorry, been busy, will look at this in the next few days. Seems like no issues with the patch since no comments received from long time. Did you get a chance to look at the patch.Could you please merge this. I can't currently think of any neater way of doing this, so i'll probably merge this. I do not see this patch merged. Is there some thing that needs to be resolved in this patch. Else can you please merge this patch. Did you get a chance to look into the patch ? If patch is fine please merge this. Haven't seen any response on this patch. Do you want a rebased version ? 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: L4 interconnect memory mapping
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Felipe Balbi Sent: Wednesday, December 30, 2009 5:20 AM To: Tony Lindgren Cc: p...@pwsan.com; linux-omap@vger.kernel.org Subject: Re: L4 interconnect memory mapping On Tue, 2009-12-29 at 15:46 -0800, Tony Lindgren wrote: * Felipe Balbi m...@felipebalbi.com [091229 15:26]: Hi, On Wed, 2009-12-30 at 01:25 +0200, Felipe Balbi wrote: Hi Tony and Paul, maybe a silly question, but here it goes: Do we have any piece of code handling the L4 interconnect memory space ? I mean, looking at omap3 TRM pages 212 - 219, I see that e.g. for the musb block we have: HS USB OTG 0x480AB000 - 0x480ABFFF 4KB Module 0x480AC000 - 0x480ACFFF 4KB L4 interconnect So the first 4K is what we pass down to drivers via struct resource and the second 4K ? What do we do with that ? no with Paul's address correct. Looks like you might want to update your earlier patch to just comment that the 8K address space for musb is 4K + 4K for L4 interconnect :) was thinking about that just now heh, but what do we do with the extra 4k ? It's the same for all other modules. Is omap_hwmod taking care of that ? I don't think you need to map 8k if there is no additional register in upper 4K. All memory spaces described as modules provide direct access to the module registers outside the L4 interconnect. All other accesses are internal to the L4 interconnect ( L4_CFG, L4_PER). Regards, Santosh
RE: [Patch v4] OMAP: sDMA driver: descriptor autoloading feature
-Original Message- From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of S, Venkatraman Sent: Monday, January 04, 2010 12:33 PM To: Tony Lindgren Cc: Russell King - ARM Linux; Shilimkar, Santosh; Kevin Hilman; linux-omap@vger.kernel.org; linux- arm-ker...@lists.infradead.org Subject: Re: [Patch v4] OMAP: sDMA driver: descriptor autoloading feature On Tue, Dec 29, 2009 at 3:18 AM, Tony Lindgren t...@atomide.com wrote: * Venkatraman S svenk...@ti.com [091211 07:01]: Here is the most updated version of the patch (thanks to Russell's review). This patch is applicable to OMAP4xxx as well as OMAP3630 Reference to previous posts v1 http://marc.info/?l=linux-omapm=125012097403050w=2 v2 http://marc.info/?l=linux-omapm=125137152606644w=2 v3 http://patchwork.kernel.org/patch/45408/ Do you have a patch for drivers/mmc/host/omap_hsmmc.c to use this feature? Or some other driver? Regards, Tony I am about to start working on omap_hsmmc to use the descriptor load feature. If the DMA changes are acceptable, I can post the driver patch as well. I don't think doing this for hsmmc makes any sense considering, the IC in which DMA descriptor is available( OMAP3630 and OMAP4), the HSMMC controller is already equipped with its dedicated DMA controller (ADMA) 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 v4] OMAP: sDMA driver: descriptor autoloading feature
I am about to start working on omap_hsmmc to use the descriptor load feature. If the DMA changes are acceptable, I can post the driver patch as well. I don't think doing this for hsmmc makes any sense considering, the IC in which DMA descriptor is available( OMAP3630 and OMAP4), the HSMMC controller is already equipped with its dedicated DMA controller (ADMA) Regards, Santosh -- AFAIK, 3630 does not have ADMA feature. In OMAP4, ADMA support is available for MMC controllers 1 and 2 only; the other 3 controllers still use sDMA. You are correct. It surely help those cases. 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] [OMAPZOOM] OMAP : DMA: added helper APIs in dma.c
By mistake I sent to '[EMAIL PROTECTED]'
From: Santosh Shilimkar [EMAIL PROTECTED]
Added helper APIs in the arch/arm/plat-omap/dma.c.Declaration was already
present in arch/arm/plat-omap/include/mach/dma.h.
APIs are 1) omap_set_dma_src_endian_type
2) omap_set_dma_dst_endian_type
3) omap_get_dma_index
Signed-off-by: Santosh Shilimkar [EMAIL PROTECTED]
---
--- omapkernel.orig/arch/arm/plat-omap/dma.c2008-10-24 12:27:56.0
+0530
+++ omapkernel/arch/arm/plat-omap/dma.c 2008-11-25 12:28:04.721536991 +0530
@@ -597,6 +597,18 @@ void omap_set_dma_dest_burst_mode(int lc
}
EXPORT_SYMBOL(omap_set_dma_dest_burst_mode);
+void omap_set_dma_src_endian_type(int lch, enum end_type etype)
+{
+ OMAP_DMA_CSDP_REG(lch) |= ((etype 0x1) 21);
+}
+EXPORT_SYMBOL(omap_set_dma_src_endian_type);
+
+void omap_set_dma_dst_endian_type(int lch, enum end_type etype)
+{
+ OMAP_DMA_CSDP_REG(lch) |= ((etype 0x1) 19);
+}
+EXPORT_SYMBOL(omap_set_dma_dst_endian_type);
+
static inline void omap_enable_channel_irq(int lch)
{
u32 status;
@@ -1020,6 +1032,26 @@ int omap_set_dma_callback(int lch,
}
EXPORT_SYMBOL(omap_set_dma_callback);
+/**
+ * @brief omap_get_dma_index : Get the element and frame number
+ * of the current logical channel
+ *
+ * @param lch : Logical channel number
+ * @param ei : Element index
+ * @param fi : Frame index
+ *
+ * @return : Success
+ */
+int omap_get_dma_index(int lch, int *ei, int *fi)
+{
+ if ((!ei) || (!fi))
+ return -EPERM;
+
+ *ei = OMAP2_DMA_CCEN_REG(lch);
+ *fi = OMAP2_DMA_CCFN_REG(lch);
+ return 0;
+}
+EXPORT_SYMBOL(omap_get_dma_index);
/*
* Returns current physical source address for the given DMA channel.
* If the channel is running the caller must disable interrupts prior calling
___
From: Pandita, Vikram
Sent: Tuesday, November 25, 2008 11:44 AM
To: Shilimkar, Santosh; Diaz Prado, Gustavo
Cc: Arce, Abraham; Olivares, Ricardo Perez; Zavala Trujillo, Diego;
Torres Martinez, Cristopherson; Kamat, Nishant
Subject: RE: DMA unresolved symbol on OmapZoom kernel
Santosh
Can you send a patch for this.
From: Shilimkar, Santosh
Sent: Monday, November 24, 2008 11:27 PM
To: Diaz Prado, Gustavo
Cc: Arce, Abraham; Olivares, Ricardo Perez; Zavala Trujillo, Diego;
Torres Martinez, Cristopherson; Kamat, Nishant; Pandita, Vikram
Subject: RE: DMA unresolved symbol on OmapZoom kernel
Hi Gus,
I just checked the OMAPZoom codebase and saw that function
'omap_set_dma_src_endian_type' is missing from dma.c
Test suite compiled because dma.h has the declaration of the function.
This function should be added to dma.c in order to use it.
Hope this clarifies.
Regards,
Santosh Shilimkar
From: Diaz Prado, Gustavo
Sent: Tuesday, November 25, 2008 6:42 AM
To: Shilimkar, Santosh
Cc: Arce, Abraham; Olivares, Ricardo Perez; Zavala Trujillo,
Diego; Torres Martinez, Cristopherson
Subject: DMA unresolved symbol on OmapZoom kernel
Good day Santosh,
We are having an issue when running the DMA testcases:
Unknown symbol omap_set_dma_src_endian_type
This message doesn't show up when we run the tests on a
different kernel than Android or OmapZoom (on 12x and 23x is ok). The testsuite
compiles fine but the test module fails due to the previous error when it is
inserted into the kernel. Could you give us some advice?
Regards,
Gus
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [OMAPZOOM] OMAP : DMA: added helper APIs in dma.c
Here is the updated patch.
From: Santosh Shilimkar [EMAIL PROTECTED]
Added helper APIs in the arch/arm/plat-omap/dma.c.Declaration was already
present in arch/arm/plat-omap/include/mach/dma.h.
APIs are 1) omap_set_dma_src_endian_type
2) omap_set_dma_dst_endian_type
3) omap_get_dma_index
Signed-off-by: Santosh Shilimkar [EMAIL PROTECTED]
---
--- omapkernel.orig/arch/arm/plat-omap/dma.c2008-11-25 20:02:37.0
+0530
+++ omapkernel/arch/arm/plat-omap/dma.c 2008-11-25 20:10:07.505112358 +0530
@@ -594,6 +594,24 @@ void omap_set_dma_dest_burst_mode(int lc
}
EXPORT_SYMBOL(omap_set_dma_dest_burst_mode);
+void omap_set_dma_src_endian_type(int lch, enum end_type etype)
+{
+ u32 csdp;
+ csdp = dma_read(CSDP(lch));
+ csdp |= ((etype 0x1) 21);
+ dma_write(csdp, CSDP(lch));
+}
+EXPORT_SYMBOL(omap_set_dma_src_endian_type);
+
+void omap_set_dma_dst_endian_type(int lch, enum end_type etype)
+{
+ u32 csdp;
+csdp = dma_read(CSDP(lch));
+csdp |= ((etype 0x1) 19);
+dma_write(csdp, CSDP(lch));
+}
+EXPORT_SYMBOL(omap_set_dma_dst_endian_type);
+
static inline void omap_enable_channel_irq(int lch)
{
u32 status;
@@ -1017,6 +1035,26 @@ int omap_set_dma_callback(int lch,
}
EXPORT_SYMBOL(omap_set_dma_callback);
+/**
+ * @brief omap_get_dma_index : Get the element and frame number
+ * of the current logical channel
+ *
+ * @param lch : Logical channel number
+ * @param ei : Element index
+ * @param fi : Frame index
+ *
+ * @return : Success
+ */
+int omap_get_dma_index(int lch, int *ei, int *fi)
+{
+ if ((!ei) || (!fi))
+ return -EPERM;
+ *ei = dma_read(CCEN(lch));
+ *fi = dma_read(CCFN(lch));
+ return 0;
+}
+EXPORT_SYMBOL(omap_get_dma_index);
+
/*
* Returns current physical source address for the given DMA channel.
* If the channel is running the caller must disable interrupts prior calling
Regards
Santosh Shilimkar--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ARM : OMAP: Pass logical DMA channel number always to callback handlers
Hi Jarkko\Tony , Recently during some debugging, I observed this patch. http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commitdiff;h=538528de0cb256f65716ab2e9613d9e920f97fe2;hp=29e8c3c304b62f31b799565c9ee85d42bd163f80 As per your description,it improves the debugging. Can you elaborate more on this ? For users this change is little confusing, if they go as per the signatures of the 'omap_request_dma_chain' and 'omap_request_dma' APIs. Also separating the callbacks for chained and non-chained transfers seems to be the practical usage in most of the cases. Also users would be only interested in 'chain_id' and not 'channel number' in case of chaining. So if it improves only debugging and some what complicates the usage, I suggest we should revert this patch. Regards, Santosh Shilimkar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [OMAPZOOM] OMAP : DMA: Spurious interrupt fix
From: Santosh Shilimkar [EMAIL PROTECTED]
This fixes the spurious interrupt issue on a DMA channel.
Signed-off-by: Santosh Shilimkar [EMAIL PROTECTED]
Acked By: Nishant Kamat [EMAIL PROTECTED]
Acked By: Gopinath Thara [EMAIL PROTECTED]
---
--- omapkernel.orig/arch/arm/plat-omap/include/mach/dma.h 2008-12-04
10:29:08.949018434 +0530
+++ omapkernel/arch/arm/plat-omap/include/mach/dma.h2008-12-04
11:14:25.359087775 +0530
@@ -67,7 +67,11 @@
#define OMAP_DMA4_CAPS_4 0x74
#define OMAP1_LOGICAL_DMA_CH_COUNT 17
+#ifdef CONFIG_OMAP_DMA_LIBRARY_CHANNELS
+#define OMAP_DMA4_LOGICAL_DMA_CH_COUNT CONFIG_OMAP_DMA_LIBRARY_CHANNELS
+#else
#define OMAP_DMA4_LOGICAL_DMA_CH_COUNT 32 /* REVISIT: Is this 32 + 2? */
+#endif
/* Common channel specific registers for omap1 */
#define OMAP1_DMA_CH_BASE(n) (0x40 * (n) + 0x00)
Index: omapkernel/arch/arm/plat-omap/Kconfig
===
--- omapkernel.orig/arch/arm/plat-omap/Kconfig 2008-12-04 10:29:08.949018434
+0530
+++ omapkernel/arch/arm/plat-omap/Kconfig 2008-12-04 10:38:21.883850512
+0530
@@ -256,6 +256,18 @@ config OMAP_SERIAL_WAKE
to data on the serial RX line. This allows you to wake the
system from serial console.
+
+config OMAP_DMA_LIBRARY_CHANNELS
+int DMA channels controlled by the kernel DMA library
+range 24 32
+depends on ARCH_OMAP3
+default 32
+help
+ Some of the OMAP System DMA channels may need to be
+ reserved for software that don't use the DMA library, such as
+ security drivers. Use this option to limit the number of channels
+ controlled by the kernel DMA library.
+
endmenu
endif
Index: omapkernel/arch/arm/configs/omap_3430sdp_defconfig
===
--- omapkernel.orig/arch/arm/configs/omap_3430sdp_defconfig 2008-12-04
10:29:08.949018434 +0530
+++ omapkernel/arch/arm/configs/omap_3430sdp_defconfig 2008-12-04
10:38:21.884850481 +0530
@@ -177,7 +177,7 @@ CONFIG_ARCH_OMAP_OTG=y
# CONFIG_ARCH_OMAP1 is not set
# CONFIG_ARCH_OMAP2 is not set
CONFIG_ARCH_OMAP3=y
-
+CONFIG_OMAP_DMA_LIBRARY_CHANNELS=24
#
# OMAP Feature Selections
#
Index: omapkernel/arch/arm/plat-omap/dma.c
===
--- omapkernel.orig/arch/arm/plat-omap/dma.c2008-12-04 10:38:16.732010840
+0530
+++ omapkernel/arch/arm/plat-omap/dma.c 2008-12-04 11:11:07.671274902 +0530
@@ -1946,7 +1946,7 @@ static int omap2_dma_handle_ch(int ch)
/* STATUS register count is from 1-32 while our is 0-31 */
static irqreturn_t omap2_dma_irq_handler(int irq, void *dev_id)
{
- u32 val;
+ u32 val, enable_reg;
int i;
val = dma_read(IRQSTATUS_L0);
@@ -1955,6 +1955,8 @@ static irqreturn_t omap2_dma_irq_handler
printk(KERN_WARNING Spurious DMA IRQ\n);
return IRQ_HANDLED;
}
+ enable_reg = dma_read(IRQENABLE_L0);
+ val = enable_reg; /* Dispatch only relevant interrupts */
for (i = 0; i dma_lch_count val != 0; i++) {
if (val 1)
omap2_dma_handle_ch(i);
Index: omapkernel/arch/arm/configs/omap_ldp_defconfig
===
--- omapkernel.orig/arch/arm/configs/omap_ldp_defconfig 2008-12-04
11:18:54.0 +0530
+++ omapkernel/arch/arm/configs/omap_ldp_defconfig 2008-12-04
11:19:33.507466484 +0530
@@ -177,6 +177,7 @@ CONFIG_ARCH_OMAP_OTG=y
# CONFIG_ARCH_OMAP1 is not set
# CONFIG_ARCH_OMAP2 is not set
CONFIG_ARCH_OMAP3=y
+CONFIG_OMAP_DMA_LIBRARY_CHANNELS=32
#
# OMAP Feature Selections
#
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][OMAP3][sDMA] : Fixing the DMA chain transfer callback.
Tony, Here is the patch for DMA to ease the chaining usage. OMAP mcbsp drivers makes use of this chaining feature but it's not pushed on mainline yet. It's available on zoom tree. Link for the same driver. http://git.omapzoom.org/?p=omapkernel.git;a=blob;f=arch/arm/mach-omap2/mcbsp.c;h=ce726c5d27eedb678ad3f981e2f5e08134e44e27;hb=2af15d1d7931a7c928d84057ed4494b77769de12 From: Santosh Shilimkar santosh.shilim...@ti.com This patch reverts back the change done on OMAP dma library. It corrects the chaining callback and reduces the complexity for the DMA users in chaining. So with this patch, drivers making use of OMAP DMA chaining feature need not built any intelligence for chain related transfers in their callback using private data. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked By : Nishant kamat nska...@ti.com --- --- omapkernel.orig/arch/arm/plat-omap/dma.c2008-12-04 11:11:07.0 +0530 +++ omapkernel/arch/arm/plat-omap/dma.c 2008-12-16 16:59:42.066118383 +0530 @@ -1936,7 +1936,11 @@ static int omap2_dma_handle_ch(int ch) } if (likely(dma_chan[ch].callback != NULL)) - dma_chan[ch].callback(ch, status, dma_chan[ch].data); + if (dma_chan[ch].chain_id != -1) + dma_chan[ch].callback(dma_chan[ch].chain_id, status, + dma_chan[ch].data); + else + dma_chan[ch].callback(ch, status, dma_chan[ch].data); dma_write(status, CSR(ch));-- 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
