[PATCH ] omap4: Move SOC specific code from board file
This patch moves OMAP4 soc specific code from 4430sdp board file.
The change is necessary so that newer board support can be added
with minimal changes. This will be also problematic for
multi-board, multi-omap builds.
Signed-off-by: Santosh Shilimkar
---
(Because veger issue this one never made to the list )
Boot tested with regular and multi-omap defconfig on OMAP4430 and
OMAP3430 SDPs. Needs Tony's sram fix to make multi-omap boot on OMAP4.
The patch is generated against mainline v2.6.34-rc6
arch/arm/mach-omap2/Makefile|2 +-
arch/arm/mach-omap2/board-4430sdp.c | 47 +--
arch/arm/mach-omap2/include/mach/omap4-common.h | 26
arch/arm/mach-omap2/omap-smp.c |2 +-
arch/arm/mach-omap2/omap4-common.c | 74 +++
arch/arm/plat-omap/common.c |3 -
arch/arm/plat-omap/include/plat/common.h|3 -
7 files changed, 103 insertions(+), 54 deletions(-)
create mode 100644 arch/arm/mach-omap2/include/mach/omap4-common.h
create mode 100644 arch/arm/mach-omap2/omap4-common.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4b9fc57..ffe600a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -22,7 +22,7 @@ obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
# SMP support ONLY available for OMAP4
obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o
obj-$(CONFIG_LOCAL_TIMERS) += timer-mpu.o
-obj-$(CONFIG_ARCH_OMAP4) += omap44xx-smc.o
+obj-$(CONFIG_ARCH_OMAP4) += omap44xx-smc.o omap4-common.o
AFLAGS_omap44xx-smc.o :=-Wa,-march=armv7-a
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index b88f28c..0f8cd85 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -20,6 +20,7 @@
#include
#include
+#include
#include
#include
#include
@@ -29,8 +30,6 @@
#include
#include
#include
-#include
-#include
static struct platform_device sdp4430_lcd_device = {
.name = "sdp4430_lcd",
@@ -49,50 +48,6 @@ 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)
-{
- extern void omap_smc1(u32 fn, u32 arg);
- void __iomem *l2cache_base;
-
- /* To avoid code running on other OMAPs in
-* multi-omap builds
-*/
- if (!cpu_is_omap44xx())
- return -ENODEV;
-
- /* Static mapping, never released */
- l2cache_base = ioremap(OMAP44XX_L2CACHE_BASE, SZ_4K);
- BUG_ON(!l2cache_base);
-
- /* Enable PL310 L2 Cache controller */
- omap_smc1(0x102, 0x1);
-
- /* 32KB way size, 16-way associativity,
- * parity disabled
- */
- l2x0_init(l2cache_base, 0x0e05, 0xcfff);
-
- return 0;
-}
-early_initcall(omap_l2_cache_init);
-#endif
-
-static void __init gic_init_irq(void)
-{
- void __iomem *base;
-
- /* Static mapping, never released */
- base = ioremap(OMAP44XX_GIC_DIST_BASE, SZ_4K);
- BUG_ON(!base);
- gic_dist_init(0, base, 29);
-
- /* Static mapping, never released */
- gic_cpu_base_addr = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_512);
- BUG_ON(!gic_cpu_base_addr);
- gic_cpu_init(0, gic_cpu_base_addr);
-}
-
static void __init omap_4430sdp_init_irq(void)
{
omap_board_config = sdp4430_config;
diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
b/arch/arm/mach-omap2/include/mach/omap4-common.h
new file mode 100644
index 000..423af3a
--- /dev/null
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -0,0 +1,26 @@
+/*
+ * omap4-common.h: OMAP4 specific common header file
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * Author:
+ * Santosh Shilimkar
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef OMAP_ARCH_OMAP4_COMMON_H
+#define OMAP_ARCH_OMAP4_COMMON_H
+
+#ifdef CONFIG_CACHE_L2X0
+extern void __iomem *l2cache_base;
+#endif
+
+extern void __iomem *gic_cpu_base_addr;
+extern void __iomem *gic_dist_base_addr;
+
+extern void __init gic_init_irq(void);
+extern void omap_smc1(u32 fn, u32 arg);
+
+#endif
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 38153e5..1cf5231 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -24,7 +24,7 @@
#include
#include
#include
-#include
+#include
/* SCU base address */
static void __iomem *scu_base;
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
new file mode 100644
index 000..91b5d36
--- /dev/null
+++ b/arch/arm/mach-omap2/om
RE: [PATCH 06/11] omap4: Fix omap_l2_cache_init not to run for other omaps
Tony, > -Original Message- > From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-kernel- > boun...@lists.infradead.org] On Behalf Of Tony Lindgren > Sent: Saturday, May 01, 2010 2:04 AM > To: linux-arm-ker...@lists.infradead.org > Cc: linux-omap@vger.kernel.org > Subject: [PATCH 06/11] omap4: Fix omap_l2_cache_init not to run for other > omaps > > In multi-omap configuration all the initcalls run. To avoid > bad things from happening with 44xx specific initcalls on > other omaps, we need to check that the booted system is > omap4 before running. > > Signed-off-by: Tony Lindgren > --- > arch/arm/mach-omap2/board-4430sdp.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-omap2/board-4430sdp.c > b/arch/arm/mach-omap2/board-4430sdp.c > index b88f28c..e603b00 100644 > --- a/arch/arm/mach-omap2/board-4430sdp.c > +++ b/arch/arm/mach-omap2/board-4430sdp.c > @@ -55,6 +55,9 @@ static int __init omap_l2_cache_init(void) > extern void omap_smc1(u32 fn, u32 arg); > void __iomem *l2cache_base; > > + if (!cpu_is_omap44xx()) > + return -ENODEV; > + This check is already present just 3 lines below. > /* To avoid code running on other OMAPs in >* multi-omap builds >*/ > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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
Cannot wakeup the SDP2430 sometimes, related to console input.
Hi All, Recently I was working on the power management code of the Linux (and Android). My hardware platform is a TI SDP2430 board. I found the board cannot wakeup from suspend state (through a key press) sometimes. The issue was found on Android (which I ported to the board) first. Then I reproduced it on Linux. The steps are as follows: 1: boot up the omap linux kernel. 2: # echo mem > /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) 3: press a key on the twl4030 keypad, the system can wake up normally. 4: wait a few seconds, the system goes into suspend automatically. 5: press a key, the system wakes up again. 6: # ajdklfjalfjdklajfdklalghkaljhglkajklajlkjalghlkgahkajhgdkjahgkahgkjPM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) 7: press a key, the system never wakes up. Is that the console inputs in step 6 make the system crash? The kernel version is 2.6.29 with OMAP and Android patches. The console is configured to 8250_SERIAL. I know there is a pm branch of the linux omap kernel. Should I try it for this issue? Thanks in advance for any helps. Best regards, Ming NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately. Thank You! AuthenTec, Inc. http://www.authentec.com -- 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: omap-pm: omap3_pm_defconfig no longer booting on Overo
On 04/30/2010 02:54 PM, Kevin Hilman wrote: > Peter Tseng writes: > >> Since the rc5 tag, omap3_pm_defconfig from the pm branch no longer boots >> on the Gumstix Overo. >> I am certain that a build back in the rc3 days worked. Unfortunately, I >> don't know about rc4, or anything that happenend in the intervening time. >> >> Any clues on how to fix? If necessary, I'll provide what info I can to >> help diagnose the issue if told what to do. > > First step is to enable CONFIG_LL_DEBUG and CONFIG_EARLYPRINTK in the > defconfig (I should have these enabled by default in omap3_pm_defconfig) > > Then, boot adding 'earlyprintk' to your boot cmdline and post the > resulting bootlog here. Here it is. (Forgot to also send to mailing list the first time around) Peter Tseng reading uImage 2069060 bytes read Booting from mmc ... ## Booting kernel from Legacy Image at 8200 ... Image Name: Linux-2.6.34-rc5-10043-g94e884a Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2068996 Bytes = 2 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Linux version 2.6.34-rc5-10043-g94e884a (leftyl...@lefty) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #61 PREEMPT Fri Apr 30 23:00:48 EDT 2010 CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: Gumstix Overo bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x10 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: console=ttyS2,115200n8 vram=12M omapfb.mode=dvi:1024x768mr...@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait earlyprintk PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 128MB 128MB = 256MB total Memory: 255540k/255540k available, 6604k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) DMA : 0xffc0 - 0xffe0 ( 2 MB) vmalloc : 0xd080 - 0xf800 ( 632 MB) lowmem : 0xc000 - 0xd000 ( 256 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .init : 0xc0008000 - 0xc0035000 ( 180 kB) .text : 0xc0035000 - 0xc03da000 (3732 kB) .data : 0xc03da000 - 0xc041cf60 ( 268 kB) SLUB: Genslabs=9, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation. NR_IRQS:402 Clocking rate (Crystal/Core/MPU): 26.0/331/500 MHz kernel BUG at arch/arm/mach-omap2/resource34xx.c:229! Unable to handle kernel NULL pointer dereference at virtual address pgd = c0004000 [] *pgd= Internal error: Oops: 805 [#1] PREEMPT last sysfs file: Modules linked in: CPU: 0Not tainted (2.6.34-rc5-10043-g94e884a #61) PC is at __bug+0x20/0x2c LR is at vprintk+0x394/0x404 pc : []lr : []psr: 41d3 sp : c03dbf18 ip : c03dbe68 fp : c03dbf24 r10: 001f r9 : 411fc083 r8 : 80027764 r7 : c03de2d4 r6 : r5 : c041dfa0 r4 : c03f3424 r3 : r2 : c03dbe68 r1 : 81d3 r0 : 003c Flags: nZcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 10c5387f Table: 80004019 DAC: 0017 Process swapper (pid: 0, stack limit = 0xc03da2e8) Stack: (0xc03dbf18 to 0xc03dc000) bf00: c03dbf4c c03dbf28 bf20: c004c9fc c00392d8 c005598c c01ce138 c03dbf4c c03f3424 c03fa128 bf40: c03dbf6c c03dbf50 c0055c7c c004c920 c03f3424 c0031a10 0034 c002a014 bf60: c03dbf84 c03dbf70 c0055d08 c0055bf4 c03f40b0 c03f40b0 c03dbf94 c03dbf88 bf80: c0016114 c0055cb0 c03dbfac c03dbf98 c000e518 c001610c c041cf80 c002a018 bfa0: c03dbfbc c03dbfb0 c0012858 c000e43c c03dbfcc c03dbfc0 c000b458 c0012834 bfc0: c03dbff4 c03dbfd0 c0008a8c c000b42c c00086d8 c002a018 bfe0: 10c53c7d c041d320 c03dbff8 80008034 c0008934 Backtrace: [] (__bug+0x0/0x2c) from [] (init_opp+0xe8/0x118) [] (init_opp+0x0/0x118) from [] (resource_register+0x94/0xbc) r6: r5:c03fa128 r4:c03f3424 [] (resource_register+0x0/0xbc) from [] (resource_init+0x64/0x84) r6:c002a014 r5:0034 r4:c0031a10 r3:c03f3424 [] (resource_init+0x0/0x84) from [] (omap_pm_if_init+0x14/0x20) r5:c03f40b0 r4:c03f40b0 [] (omap_pm_if_init+0x0/0x20) from [] (omap2_init_common_hw+0xe8/0x19c) [] (omap2_init_common_hw+0x0/0x19c) from [] (overo_init_irq+0x30/0x4c) r5:c002a018 r4:c041cf80 [] (overo_init_irq+0x0/0x4c) from [] (init_IRQ+0x38/0x48) [] (init_IRQ+0x0/0x48) from [] (start_kernel+0x164/0x2d0) [] (start_kernel+0x0/0x2d
Re: OMAP 3530 LV-SOM support (was: Re: Patch format for submission?)
On Thu, Apr 29, 2010 at 1:18 PM, Zygo Blaxell wrote: > On Thu, Aug 20, 2009 at 06:02:06PM +0200, Stephan Linz wrote: >> Am Mittwoch, 19. August 2009 schrieb Peter Barada: >> > 1) Does anyone have a URL of the format patches should be in that are >> > submitted to the linux-omap list? >> > >> > I've got some patches to add base support for the Logic OMAP 35x SOM and >> > Torpedo boards and I'd like to submit them in the right format for >> > inclusion and push into mainline. >> >> Hi Peter, >> >> nice to see your announcement here at linux-omap. Today I've finished my own >> port for the Logic OMAP 35x SOM based on 2.6.31-rc1. We should share our >> results befor submitting any patches to the list, or not? > > That's the last message I can find from either of you on this topic. > I'm in the process of rolling yet another patch set for 2.6.32. Was any > further work done on this, or anything posted anywhere? > Zygo, No, the LogicPD OMAP 35x support didn't quite make it out to the list, we are taking another crack at it shortly and would definitely love to collaborate to get the changes out. We did create a Gitorious repo[1], but that's sitting at 2.6.31-rc1 and we've internally got a newer version of the Kernel up to date.. So we should definitely discuss off-list on how to pool our efforts to get the support into the L-O tree.. Regards -- Ashwin -- 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/11] omap2/3: Fix DEBUG_LL for omap zoom2/3
* Tony Lindgren [100430 18:33]:
>
> So far only tested on n900, will give it a try also on zoom3 after
> updating the zoom3 related patch.
And here's the updated zoom debug_ll patch, seems to work.
> --- a/arch/arm/plat-omap/include/plat/uncompress.h
> +++ b/arch/arm/plat-omap/include/plat/uncompress.h
> @@ -20,27 +20,22 @@
> #include
> #include
>
> +#include
> +#include
> #include
>
> #include
BTW, the include of asm/io.h is not needed, I'll remove that.
Regards,
Tony
>From 0130fa96f1016c25540ded86ea66f5a6198489c7 Mon Sep 17 00:00:00 2001
From: Tony Lindgren
Date: Fri, 30 Apr 2010 12:57:14 -0700
Subject: [PATCH] omap2/3: Fix DEBUG_LL for omap zoom2/3
Zoom2 and 3 have UARTs only on the external debug board.
GPMC needs to be mapped early to use it for DEBUG_LL.
Additionally, 0xfb00 overlaps with other areas, so
use 0xfa40 for the virtual address instead.
Note that with the pending serial.c patches you need to
set console=ttyS0,115200n8 as it will be the only UART
mapped. To use DEBUG_LL, you need to pass also earlyprintk
in cmdline.
Cc: Allen Pais
Cc: Vikram Pandita
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c b/arch/arm/mach-omap2/board-zoom-debugboard.c
index e15d2e8..1d7f827 100644
--- a/arch/arm/mach-omap2/board-zoom-debugboard.c
+++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
@@ -82,7 +82,7 @@ static inline void __init zoom_init_smsc911x(void)
static struct plat_serial8250_port serial_platform_data[] = {
{
- .mapbase = 0x1000,
+ .mapbase = ZOOM_UART_BASE,
.irq = OMAP_GPIO_IRQ(102),
.flags = UPF_BOOT_AUTOCONF|UPF_IOREMAP|UPF_SHARE_IRQ,
.irqflags = IRQF_SHARED | IRQF_TRIGGER_RISING,
diff --git a/arch/arm/mach-omap2/board-zoom2.c b/arch/arm/mach-omap2/board-zoom2.c
index 9a26f84..803ef14 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -91,8 +91,8 @@ static void __init omap_zoom2_map_io(void)
}
MACHINE_START(OMAP_ZOOM2, "OMAP Zoom2 board")
- .phys_io = 0x4800,
- .io_pg_offst = ((0xfa00) >> 18) & 0xfffc,
+ .phys_io = ZOOM_UART_BASE,
+ .io_pg_offst = (ZOOM_UART_VIRT >> 18) & 0xfffc,
.boot_params = 0x8100,
.map_io = omap_zoom2_map_io,
.init_irq = omap_zoom2_init_irq,
diff --git a/arch/arm/mach-omap2/board-zoom3.c b/arch/arm/mach-omap2/board-zoom3.c
index cd3e40c..3314704 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -73,8 +73,8 @@ static void __init omap_zoom_init(void)
}
MACHINE_START(OMAP_ZOOM3, "OMAP Zoom3 board")
- .phys_io = 0x4800,
- .io_pg_offst = ((0xfa00) >> 18) & 0xfffc,
+ .phys_io = ZOOM_UART_BASE,
+ .io_pg_offst = (ZOOM_UART_VIRT >> 18) & 0xfffc,
.boot_params = 0x8100,
.map_io = omap_zoom_map_io,
.init_irq = omap_zoom_init_irq,
diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S b/arch/arm/mach-omap2/include/mach/debug-macro.S
index 4976169..35b2440 100644
--- a/arch/arm/mach-omap2/include/mach/debug-macro.S
+++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
@@ -88,10 +88,10 @@ omap_uart_lsr: .word 0
b 98f
44: mov \rx, #UART_OFFSET(OMAP4_UART4_BASE)
b 98f
-95: mov \rx, #ZOOM_UART_BASE
+95: ldr \rx, =ZOOM_UART_BASE
ldr \tmp, =omap_uart_phys
str \rx, [\tmp, #0]
- mov \rx, #ZOOM_UART_VIRT
+ ldr \rx, =ZOOM_UART_VIRT
ldr \tmp, =omap_uart_virt
str \rx, [\tmp, #0]
mov \rx, #(UART_LSR << ZOOM_PORT_SHIFT)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 87f676a..3cfb425 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -166,6 +166,15 @@ static struct map_desc omap34xx_io_desc[] __initdata = {
.length = L4_EMU_34XX_SIZE,
.type = MT_DEVICE
},
+#if defined(CONFIG_DEBUG_LL) && \
+ (defined(CONFIG_MACH_OMAP_ZOOM2) || defined(CONFIG_MACH_OMAP_ZOOM3))
+ {
+ .virtual = ZOOM_UART_VIRT,
+ .pfn = __phys_to_pfn(ZOOM_UART_BASE),
+ .length = SZ_1M,
+ .type = MT_DEVICE
+ },
+#endif
};
#endif
#ifdef CONFIG_ARCH_OMAP4
diff --git a/arch/arm/plat-omap/include/plat/serial.h b/arch/arm/plat-omap/include/plat/serial.h
index 20c27b9..a680715 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -41,7 +41,7 @@
/* External port on Zoom2/3 */
#define ZOOM_UART_BASE 0x1000
-#define ZOOM_UART_VIRT 0xfb00
+#define ZOOM_UART_VIRT 0xfa40
#define OMAP_PORT_SHIFT 2
#define OMAP7XX_PORT_SHIFT 0
Re: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3
* Kevin Hilman [100430 17:05]: > Tony Lindgren writes: > > > * Kevin Hilman [100430 14:56]: > >> "Pandita, Vikram" writes: > >> > > >> > So for Tony's approach to work, .phys_io/.io_pg_offset continued to > >> > have 0x480 based mapping and for external uart zoom3 port, > >> > create this extra mapping. > >> > > >> > So find a better way from compressed.S to pass the uart number to > >> > kernel, and we can solve the problem. > >> > >> Ah, yet another reason to use a memory location instead of UART1 SCR > >> to pass the UART info (c.f. [1]) > > > > That should work if we don't need to access any L4 registers > > early on before .map_io. > > I'd say if we're accessing L4 regs before .map_io, it's a bug that > needs to be fixed, but I don't think we are. If we were, we'd notice > a hang when !CONFIG_DEBUG_LL since the .phys_io and .io_pg_offst are > only mapped in when CONFIG_DEBUG_LL=y. Yeah the current approach uses both, but only when CONFIG_DEBUG_LL=y as you noted. > I think we've been using .phys_io/.io_pg_offset incorrectly in OMAP as > an early mapping of all the IO space, when it is intended just for use > as early UART access, indicated by the comments in head.S and the > fact that it's only used when CONFIG_DEBUG_LL=y That's probably just a left over from when we could map L3 and L4 with one mapping.. Anyways, here's an experimental patch for using a memory address instead of UART1 for storing the debug port configuration in uncompress.h. So far only tested on n900, will give it a try also on zoom3 after updating the zoom3 related patch. Now the real question is: Is it safe to use the fixed memory address? #define OMAP_UART_INFO (PHYS_OFFSET + 0x3ff8) Also, another thing that needs to be checked is what happens if nothing calls printk early and the debug port address configuration is not set early.. Needs to be tested by adding printascii call only later on. Regards, Tony >From c957c9a19fb5b53c2cff4f3bc5c9481f9a4a99aa Mon Sep 17 00:00:00 2001 From: Tony Lindgren Date: Fri, 30 Apr 2010 17:39:19 -0700 Subject: [PATCH] omap: Use a memory address for storing the debug port info instead of UART1 This removes the dependency to the UART1 being available for storing the debug configuration in uncompress.h. As suggested by Cyril Chemparathy , Vikram Pandita and Kevin Hilman . Signed-off-by: Tony Lindgren diff --git a/arch/arm/mach-omap1/include/mach/debug-macro.S b/arch/arm/mach-omap1/include/mach/debug-macro.S index b6d9584..e8a8cf3 100644 --- a/arch/arm/mach-omap1/include/mach/debug-macro.S +++ b/arch/arm/mach-omap1/include/mach/debug-macro.S @@ -13,6 +13,8 @@ #include +#include + #include .pushsection .data @@ -37,23 +39,12 @@ omap_uart_virt: .word 0x0 cmp \rx, #0 @ is port configured? bne 99f @ already configured - /* Check 7XX UART1 scratchpad register for uart to use */ + /* Check the debug UART configuration set in uncompress.h */ mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? - moveq \rx, #0xff00 @ physical base address - movne \rx, #0xfe00 @ virtual base - orr \rx, \rx, #0x00fb @ OMAP1UART1 - ldrb \rx, [\rx, #(UART_SCR << OMAP7XX_PORT_SHIFT)] - cmp \rx, #0 @ anything in 7XX scratchpad? - bne 10f @ found 7XX uart - - /* Check 15xx/16xx UART1 scratchpad register for uart to use */ - mrc p15, 0, \rx, c1, c0 - tst \rx, #1 @ MMU enabled? - moveq \rx, #0xff00 @ physical base address - movne \rx, #0xfe00 @ virtual base - orr \rx, \rx, #0x00fb @ OMAP1UART1 - ldrb \rx, [\rx, #(UART_SCR << OMAP_PORT_SHIFT)] + ldreq \rx, =OMAP_UART_INFO + ldrne \rx, =__phys_to_virt(OMAP_UART_INFO) + ldr \rx, [\rx, #0] /* Select the UART to use based on the UART1 scratchpad value */ 10: cmp \rx, #0 @ no port configured? diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S b/arch/arm/mach-omap2/include/mach/debug-macro.S index 4a63a2e..4976169 100644 --- a/arch/arm/mach-omap2/include/mach/debug-macro.S +++ b/arch/arm/mach-omap2/include/mach/debug-macro.S @@ -13,6 +13,8 @@ #include +#include + #include #define UART_OFFSET(addr) ((addr) & 0x00ff) @@ -40,13 +42,12 @@ omap_uart_lsr: .word 0 cmp \rx, #0 @ is port configured? bne 99f @ already configured - /* Check UART1 scratchpad register for uart to use */ + /* Check the debug UART configuration set in uncompress.h */ mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? - moveq \rx, #0x4800 @ physical base address - movne \rx, #0xfa00 @ virtual base - orr \rx, \rx, #0x0006a000 @ uart1 on omap2/3/4 - ldrb \rx, [\rx, #(UART_SCR << OMAP_PORT_SHIFT)] @ scratchpad + ldreq \rx, =OMAP_UART_INFO + ldrne \rx, =__phys_to_virt(OMAP_UART_INFO) + ldr \rx, [\rx, #0] /* Select the UART to use based on the UART1 scratchpad value */ cmp \rx, #0 @ no port configured? diff --git a/arch/arm/plat-omap/include/plat/serial.h b/arch/arm/plat-omap/include/plat/serial.h index 83dce4c..20c27b9 100644 --- a/arch/arm/p
[PATCH 02/11] DSPBRIDGE: Rename the device context handle variables
The name of these variables contains "wmd", which refers to Windows OS,
So they are renamed as follows:
hwmd_context ==> hbridge_context
pwmd_context ==> pbridge_context
phWmdContext ==> phbridge_context
Signed-off-by: Ivan Gomez Castellanos
---
arch/arm/plat-omap/include/dspbridge/dev.h | 10 +-
arch/arm/plat-omap/include/dspbridge/io_sm.h |2 +-
drivers/dsp/bridge/pmgr/dev.c| 33 +++---
drivers/dsp/bridge/pmgr/ioobj.h |2 +-
drivers/dsp/bridge/rmgr/node.c | 19 ++--
drivers/dsp/bridge/rmgr/proc.c | 34 +++---
drivers/dsp/bridge/wmd/_deh.h|2 +-
drivers/dsp/bridge/wmd/chnl_sm.c |4 +-
drivers/dsp/bridge/wmd/io_sm.c | 136 +-
drivers/dsp/bridge/wmd/mmu_fault.c |2 +-
drivers/dsp/bridge/wmd/tiomap_io.c | 10 +-
drivers/dsp/bridge/wmd/ue_deh.c | 14 ++--
12 files changed, 135 insertions(+), 133 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dev.h
b/arch/arm/plat-omap/include/dspbridge/dev.h
index 6df8db7..5bff0b8 100644
--- a/arch/arm/plat-omap/include/dspbridge/dev.h
+++ b/arch/arm/plat-omap/include/dspbridge/dev.h
@@ -514,20 +514,20 @@ extern dsp_status dev_get_symbol(struct dev_object
*hdev_obj,
* Retrieve the WMD Context handle, as returned by the WMD_Create fxn.
* Parameters:
* hdev_obj: Handle to device object created with dev_create_device()
- * *phWmdContext: Ptr to location to store context handle.
+ * *phbridge_context: Ptr to location to store context handle.
* Returns:
* DSP_SOK:Success.
* DSP_EHANDLE:Invalid hdev_obj.
* Requires:
- * phWmdContext != NULL.
+ * phbridge_context != NULL.
* DEV Initialized.
* Ensures:
- * DSP_SOK:*phWmdContext contains context handle;
- * else: *phWmdContext is NULL;
+ * DSP_SOK:*phbridge_context contains context handle;
+ * else: *phbridge_context is NULL;
*/
extern dsp_status dev_get_wmd_context(struct dev_object *hdev_obj,
OUT struct bridge_dev_context
- **phWmdContext);
+ **phbridge_context);
/*
* dev_exit
diff --git a/arch/arm/plat-omap/include/dspbridge/io_sm.h
b/arch/arm/plat-omap/include/dspbridge/io_sm.h
index 177bfeb..1df7664 100644
--- a/arch/arm/plat-omap/include/dspbridge/io_sm.h
+++ b/arch/arm/plat-omap/include/dspbridge/io_sm.h
@@ -289,6 +289,6 @@ extern void io_sm_init(void);
* Print DSP tracebuffer.
*/
extern dsp_status print_dsp_trace_buffer(struct bridge_dev_context
-*hwmd_context);
+*hbridge_context);
#endif /* IOSM_ */
diff --git a/drivers/dsp/bridge/pmgr/dev.c b/drivers/dsp/bridge/pmgr/dev.c
index 62ff655..164b65d 100644
--- a/drivers/dsp/bridge/pmgr/dev.c
+++ b/drivers/dsp/bridge/pmgr/dev.c
@@ -64,7 +64,7 @@ struct dev_object {
struct list_head link; /* Link to next dev_object. */
u32 dev_type; /* Device Type */
struct cfg_devnode *dev_node_obj; /* Platform specific dev id */
- struct bridge_dev_context *hwmd_context;/* WMD Context Handle */
+ struct bridge_dev_context *hbridge_context; /* WMD Context Handle */
struct bridge_drv_interface wmd_interface; /* Function interface
to WMD. */
struct brd_object *lock_owner; /* Client with exclusive access. */
struct cod_manager *cod_mgr;/* Code manager handle. */
@@ -108,11 +108,10 @@ u32 dev_brd_write_fxn(void *pArb, u32 ulDspAddr, void
*pHostBuf,
DBC_REQUIRE(pHostBuf != NULL); /* Required of BrdWrite(). */
if (dev_obj) {
/* Require of BrdWrite() */
- DBC_ASSERT(dev_obj->hwmd_context != NULL);
- status =
- (*dev_obj->wmd_interface.
-pfn_brd_write) (dev_obj->hwmd_context, pHostBuf, ulDspAddr,
-ul_num_bytes, nMemSpace);
+ DBC_ASSERT(dev_obj->hbridge_context != NULL);
+ status = (*dev_obj->wmd_interface.pfn_brd_write)
+ (dev_obj->hbridge_context, pHostBuf, ulDspAddr,
+ ul_num_bytes, nMemSpace);
/* Special case of getting the address only */
if (ul_num_bytes == 0)
ul_num_bytes = 1;
@@ -177,11 +176,11 @@ dsp_status dev_create_device(OUT struct dev_object
**phDevObject,
/* Call fxn_dev_create() to get the WMD's device
* context handle. */
status = (dev_obj->wmd_interface.pfn_dev_create)
- (&dev_obj->hwmd_context, dev_obj,
+ (&dev_obj->
[PATCH 07/11] DSPBRIDGE: Rename "wmd" directory by "core"
Since "wmd" (windows mini driver) refers to Windows OS, then this
directory is renamed by "core"
Signed-off-by: Ivan Gomez Castellanos
---
drivers/dsp/bridge/Makefile | 10 +-
drivers/dsp/bridge/{wmd => core}/_cmm.h |0
drivers/dsp/bridge/{wmd => core}/_deh.h |0
drivers/dsp/bridge/{wmd => core}/_msg_sm.h|0
drivers/dsp/bridge/{wmd => core}/_tiomap.h|0
drivers/dsp/bridge/{wmd => core}/_tiomap_mmu.h|0
drivers/dsp/bridge/{wmd => core}/_tiomap_pwr.h|0
drivers/dsp/bridge/{wmd => core}/_tiomap_util.h |0
drivers/dsp/bridge/{wmd => core}/chnl_sm.c|0
drivers/dsp/bridge/{wmd => core}/io_sm.c |0
drivers/dsp/bridge/{wmd => core}/mmu_fault.c |0
drivers/dsp/bridge/{wmd => core}/mmu_fault.h |0
drivers/dsp/bridge/{wmd => core}/msg_sm.c |0
drivers/dsp/bridge/{wmd => core}/tiomap3430.c |0
drivers/dsp/bridge/{wmd => core}/tiomap3430_pwr.c |0
drivers/dsp/bridge/{wmd => core}/tiomap_io.c |0
drivers/dsp/bridge/{wmd => core}/tiomap_io.h |0
drivers/dsp/bridge/{wmd => core}/ue_deh.c |0
drivers/dsp/bridge/{wmd => core}/wdt.c|0
19 files changed, 5 insertions(+), 5 deletions(-)
rename drivers/dsp/bridge/{wmd => core}/_cmm.h (100%)
rename drivers/dsp/bridge/{wmd => core}/_deh.h (100%)
rename drivers/dsp/bridge/{wmd => core}/_msg_sm.h (100%)
rename drivers/dsp/bridge/{wmd => core}/_tiomap.h (100%)
rename drivers/dsp/bridge/{wmd => core}/_tiomap_mmu.h (100%)
rename drivers/dsp/bridge/{wmd => core}/_tiomap_pwr.h (100%)
rename drivers/dsp/bridge/{wmd => core}/_tiomap_util.h (100%)
rename drivers/dsp/bridge/{wmd => core}/chnl_sm.c (100%)
rename drivers/dsp/bridge/{wmd => core}/io_sm.c (100%)
rename drivers/dsp/bridge/{wmd => core}/mmu_fault.c (100%)
rename drivers/dsp/bridge/{wmd => core}/mmu_fault.h (100%)
rename drivers/dsp/bridge/{wmd => core}/msg_sm.c (100%)
rename drivers/dsp/bridge/{wmd => core}/tiomap3430.c (100%)
rename drivers/dsp/bridge/{wmd => core}/tiomap3430_pwr.c (100%)
rename drivers/dsp/bridge/{wmd => core}/tiomap_io.c (100%)
rename drivers/dsp/bridge/{wmd => core}/tiomap_io.h (100%)
rename drivers/dsp/bridge/{wmd => core}/ue_deh.c (100%)
rename drivers/dsp/bridge/{wmd => core}/wdt.c (100%)
diff --git a/drivers/dsp/bridge/Makefile b/drivers/dsp/bridge/Makefile
index c6f2551..97e7ec1 100644
--- a/drivers/dsp/bridge/Makefile
+++ b/drivers/dsp/bridge/Makefile
@@ -5,9 +5,9 @@ libservices = services/sync.o \
services/clk.o services/cfg.o services/reg.o \
services/regsup.o services/ntfy.o \
services/services.o
-libwmd = wmd/chnl_sm.o wmd/msg_sm.o wmd/io_sm.o wmd/tiomap3430.o \
- wmd/tiomap3430_pwr.o wmd/tiomap_io.o \
- wmd/mmu_fault.o wmd/ue_deh.o wmd/wdt.o
+libcore = core/chnl_sm.o core/msg_sm.o core/io_sm.o core/tiomap3430.o \
+ core/tiomap3430_pwr.o core/tiomap_io.o \
+ core/mmu_fault.o core/ue_deh.o core/wdt.o
libpmgr = pmgr/chnl.o pmgr/io.o pmgr/msg.o pmgr/cod.o pmgr/dev.o pmgr/wcd.o \
pmgr/dmm.o pmgr/cmm.o pmgr/dbll.o
librmgr = rmgr/dbdcd.o rmgr/disp.o rmgr/drv.o rmgr/mgr.o rmgr/node.o \
@@ -17,7 +17,7 @@ libdload = dynload/cload.o dynload/getsection.o
dynload/reloc.o \
dynload/tramp.o
libhw = hw/hw_mmu.o
-bridgedriver-objs = $(libgen) $(libservices) $(libwmd) $(libpmgr) $(librmgr) \
+bridgedriver-objs = $(libgen) $(libservices) $(libcore) $(libpmgr) $(librmgr) \
$(libdload) $(libhw)
#Machine dependent
@@ -27,7 +27,7 @@ ccflags-y += -D_TI_ -D_DB_TIOMAP -DTMS32060 \
#Header files
ccflags-y += -Idrivers/dsp/bridge/services
-ccflags-y += -Idrivers/dsp/bridge/wmd
+ccflags-y += -Idrivers/dsp/bridge/core
ccflags-y += -Idrivers/dsp/bridge/pmgr
ccflags-y += -Idrivers/dsp/bridge/rmgr
ccflags-y += -Idrivers/dsp/bridge/hw
diff --git a/drivers/dsp/bridge/wmd/_cmm.h b/drivers/dsp/bridge/core/_cmm.h
similarity index 100%
rename from drivers/dsp/bridge/wmd/_cmm.h
rename to drivers/dsp/bridge/core/_cmm.h
diff --git a/drivers/dsp/bridge/wmd/_deh.h b/drivers/dsp/bridge/core/_deh.h
similarity index 100%
rename from drivers/dsp/bridge/wmd/_deh.h
rename to drivers/dsp/bridge/core/_deh.h
diff --git a/drivers/dsp/bridge/wmd/_msg_sm.h
b/drivers/dsp/bridge/core/_msg_sm.h
similarity index 100%
rename from drivers/dsp/bridge/wmd/_msg_sm.h
rename to drivers/dsp/bridge/core/_msg_sm.h
diff --git a/drivers/dsp/bridge/wmd/_tiomap.h
b/drivers/dsp/bridge/core/_tiomap.h
similarity index 100%
rename from drivers/dsp/bridge/wmd/_tiomap.h
rename to drivers/dsp/bridge/core/_tiomap.h
diff --git a/drivers/dsp/bridge/wmd/_tiomap_mmu.h
b/drivers/dsp/bridge/core/_tiomap_mmu.h
similarity index 100%
rename from drivers/dsp/bridge/wmd/_tiomap_mmu.h
rename to drivers/dsp/bridge/core/_tiomap_mmu.h
diff --git a/drivers/dsp/bridge/wmd/_tiomap_pw
[PATCH 06/11] DSPBRIDGE: Replace code containing "wcd"
This patch gets rid of code refering to Windows OS. Since "wcd" means "windows class driver", it is changed to a name refering to Bridge API, because in Windows the wcd acts as an interface between the different layers of its driver model architecture. The following changes are done: wcd_call_dev_io_ctl ==> api_call_dev_ioctl wcd_exit ==> api_exit wcd_init ==> api_init wcd_init_complete2 ==> api_init_complete2 wcd_cmd ==> api_cmd wcd_c_refs ==> api_c_refs dw_wcd_major_version ==> brd_api_major_version dw_wcd_minor_version ==> brd_api_minor_version WCD_MAJOR_VERSION ==> BRD_API_MAJOR_VERSION WCD_MINOR_VERSION ==> BRD_API_MINOR_VERSION Signed-off-by: Ivan Gomez Castellanos --- arch/arm/plat-omap/include/dspbridge/_dcd.h | 36 arch/arm/plat-omap/include/dspbridge/dev.h |2 +- arch/arm/plat-omap/include/dspbridge/wcd.h |6 +- arch/arm/plat-omap/include/dspbridge/wmd.h |4 +- drivers/dsp/bridge/pmgr/dev.c | 17 drivers/dsp/bridge/pmgr/wcd.c | 58 +- drivers/dsp/bridge/rmgr/drv_interface.c |2 +- drivers/dsp/bridge/rmgr/dspdrv.c| 14 +++--- drivers/dsp/bridge/wmd/tiomap3430.c |6 +- 9 files changed, 73 insertions(+), 72 deletions(-) diff --git a/arch/arm/plat-omap/include/dspbridge/_dcd.h b/arch/arm/plat-omap/include/dspbridge/_dcd.h index 1350feb..589cd42 100644 --- a/arch/arm/plat-omap/include/dspbridge/_dcd.h +++ b/arch/arm/plat-omap/include/dspbridge/_dcd.h @@ -23,9 +23,9 @@ #include /* - * wcd_call_dev_io_ctl + * api_call_dev_ioctl * Purpose: - * Call the (wrapper) function for the corresponding WCD IOCTL. + * Call the (wrapper) function for the corresponding API IOCTL. * Parameters: * cmd:IOCTL id, base 0. * args: Argument structure. @@ -36,28 +36,28 @@ * Requires: * Ensures: */ -extern dsp_status wcd_call_dev_io_ctl(unsigned int cmd, +extern dsp_status api_call_dev_ioctl(unsigned int cmd, union Trapped_Args *args, u32 *pResult, void *pr_ctxt); /* - * wcd_init + * api_init * Purpose: - * Initialize WCD modules, and export WCD services to WMD's. - * This procedure is called when the class driver is loaded. + * Initialize modules used by Bridge API. + * This procedure is called when the driver is loaded. * Parameters: * Returns: * TRUE if success; FALSE otherwise. * Requires: * Ensures: */ -extern bool wcd_init(void); +extern bool api_init(void); /* - * wcd_init_complete2 + * api_init_complete2 * Purpose: - * Perform any required WCD, and WMD initialization which - * cannot not be performed in wcd_init(void) or dev_start_device() due + * Perform any required bridge initialization which cannot + * be performed in api_init() or dev_start_device() due * to the fact that some services are not yet * completely initialized. * Parameters: @@ -65,24 +65,24 @@ extern bool wcd_init(void); * DSP_SOK:Allow this device to load * DSP_EFAIL: Failure. * Requires: - * WCD initialized. + * Bridge API initialized. * Ensures: */ -extern dsp_status wcd_init_complete2(void); +extern dsp_status api_init_complete2(void); /* - * wcd_exit + * api_exit * Purpose: - * Exit all modules initialized in wcd_init(void). - * This procedure is called when the class driver is unloaded. + * Exit all modules initialized in api_init(void). + * This procedure is called when the driver is unloaded. * Parameters: * Returns: * Requires: - * wcd_init(void) was previously called. + * api_init(void) was previously called. * Ensures: - * Resources acquired in wcd_init(void) are freed. + * Resources acquired in api_init(void) are freed. */ -extern void wcd_exit(void); +extern void api_exit(void); /* MGR wrapper functions */ extern u32 mgrwrap_enum_node_info(union Trapped_Args *args, void *pr_ctxt); diff --git a/arch/arm/plat-omap/include/dspbridge/dev.h b/arch/arm/plat-omap/include/dspbridge/dev.h index c26e9d0..3ada31d 100644 --- a/arch/arm/plat-omap/include/dspbridge/dev.h +++ b/arch/arm/plat-omap/include/dspbridge/dev.h @@ -152,7 +152,7 @@ extern dsp_status dev_create_iva_device(OUT struct dev_object /* * dev_create2 * Purpose: - * After successful loading of the image from wcd_init_complete2 + * After successful loading of the image from api_init_complete2 * (PROC Auto_Start) or proc_load this fxn is called. This creates * the Node Manager and updates the DEV Object. * Parameters: diff --git a/arch/arm/plat-omap/include/dspbridge/wcd.h b/arch/arm/plat-omap/include/dspbridge/wcd.h index
[PATCH 10/11] DSPBRIDGE: Remove OS specific comments
From: Omar Ramirez Luna
As this is generic to Linux, remove obvious references to
this and other OS.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/plat-omap/include/dspbridge/dev.h | 14 +++---
arch/arm/plat-omap/include/dspbridge/dspdefs.h |4 ++--
arch/arm/plat-omap/include/dspbridge/mgr.h |2 +-
drivers/dsp/bridge/core/chnl_sm.c |2 +-
drivers/dsp/bridge/core/tiomap3430.c |6 ++
drivers/dsp/bridge/rmgr/drv.c |4 ++--
6 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dev.h
b/arch/arm/plat-omap/include/dspbridge/dev.h
index ac011cd..70eb55d 100644
--- a/arch/arm/plat-omap/include/dspbridge/dev.h
+++ b/arch/arm/plat-omap/include/dspbridge/dev.h
@@ -72,7 +72,7 @@ extern u32 dev_brd_write_fxn(void *pArb,
* to the WMD when bridge_dev_create() is called.
* pDspConfig: DSP resources, to be passed down to the WMD when
* bridge_dev_create() is called.
- * dev_node_obj: Platform (Windows) specific device node.
+ * dev_node_obj: Platform specific device node.
* Returns:
* DSP_SOK:Module is loaded, device object has been created
* DSP_EMEMORY:Insufficient memory to create needed resources.
@@ -117,7 +117,7 @@ extern dsp_status dev_create_device(OUT struct dev_object
* to the WMD when bridge_dev_create() is called.
* pDspConfig: DSP resources, to be passed down to the WMD when
* bridge_dev_create() is called.
- * dev_node_obj: Platform (Windows) specific device node.
+ * dev_node_obj: Platform specific device node.
* Returns:
* DSP_SOK:Module is loaded, device object has been created
* DSP_EMEMORY:Insufficient memory to create needed resources.
@@ -324,7 +324,7 @@ extern dsp_status dev_get_deh_mgr(struct dev_object
*hdev_obj,
* dev_create_device().
* phDevNode: Ptr to location to get the device node handle.
* Returns:
- * DSP_SOK:In Win95, returns a DEVNODE in *dev_node_obj; In NT,
???
+ * DSP_SOK:Returns a DEVNODE in *dev_node_obj.
* DSP_EHANDLE:Invalid hdev_obj.
* Requires:
* phDevNode != NULL.
@@ -700,10 +700,10 @@ extern void dev_set_msg_mgr(struct dev_object *hdev_obj,
struct msg_mgr *hmgr);
/*
* dev_start_device
* Purpose:
- * Initializes the new device with the WinBRIDGE environment. This
- * involves querying CM for allocated resources, querying the registry
- * for necessary dsp resources (requested in the INF file), and using
- * this information to create a WinBRIDGE device object.
+ * Initializes the new device with bridge environment. This involves
+ * querying CM for allocated resources, querying the registry for
+ * necessary dsp resources (requested in the INF file), and using this
+ * information to create a bridge device object.
* Parameters:
* dev_node_obj: Device node as it is know to OS.
* Returns:
diff --git a/arch/arm/plat-omap/include/dspbridge/dspdefs.h
b/arch/arm/plat-omap/include/dspbridge/dspdefs.h
index 8a1d38c..26a9988 100644
--- a/arch/arm/plat-omap/include/dspbridge/dspdefs.h
+++ b/arch/arm/plat-omap/include/dspbridge/dspdefs.h
@@ -653,7 +653,7 @@ typedef dsp_status(*fxn_chnl_registernotify)
* Parameters:
* phDevContext: Ptr to location to store a WMD device context.
* hdev_obj: Handle to a Device Object, created and managed by WCD.
- * pConfig:Ptr to configuration parameters provided by the Windows
+ * pConfig:Ptr to configuration parameters provided by the
* Configuration Manager during device loading.
* pDspConfig: DSP resources, as specified in the registry key for
this
* device.
@@ -1127,7 +1127,7 @@ struct bridge_drv_interface {
* ppDrvInterface pointer initialized to WMD's function interface.
* No system resources are acquired by this function.
* Details:
- * Win95: Called during the Device_Init phase.
+ * Called during the Device_Init phase.
*/
void bridge_drv_entry(OUT struct bridge_drv_interface **ppDrvInterface,
IN CONST char *driver_file_name);
diff --git a/arch/arm/plat-omap/include/dspbridge/mgr.h
b/arch/arm/plat-omap/include/dspbridge/mgr.h
index feb1b61..193e5e0 100644
--- a/arch/arm/plat-omap/include/dspbridge/mgr.h
+++ b/arch/arm/plat-omap/include/dspbridge/mgr.h
@@ -50,7 +50,7 @@ dsp_status mgr_wait_for_bridge_events(struct dsp_notification
* There is only one Manager Object in the DSP/BIOS Bridge.
* Parameters:
* phMgrObject:Location to store created MGR Object handle.
- * dev_node_obj: Device object as known to Windows system.
+ * dev_nod
[PATCH 04/11] DSPBRIDGE: Rename functions which contain "wmd" and remove unused prototypes
Since the "wmd" (windows mini driver) refers to Windows OS, the
following functions are renamed:
wmd_brd_delete ==> bridge_brd_delete
dev_get_wmd_context ==> dev_get_bridge_context
And the folowing prototypes are removed because they are not used:
cfg_get_wmd_file_name
wmd_tlb_dsp_va_to_mpu_pa
Signed-off-by: Ivan Gomez Castellanos
---
arch/arm/plat-omap/include/dspbridge/cfg.h | 23 ---
arch/arm/plat-omap/include/dspbridge/dev.h |7 ---
drivers/dsp/bridge/pmgr/dev.c |7 ---
drivers/dsp/bridge/rmgr/node.c |4 ++--
drivers/dsp/bridge/rmgr/proc.c |4 ++--
drivers/dsp/bridge/rmgr/pwr.c |8
drivers/dsp/bridge/wmd/_tiomap.h | 10 --
drivers/dsp/bridge/wmd/chnl_sm.c |4 ++--
drivers/dsp/bridge/wmd/io_sm.c |4 ++--
drivers/dsp/bridge/wmd/tiomap3430.c|6 +++---
drivers/dsp/bridge/wmd/ue_deh.c|2 +-
11 files changed, 24 insertions(+), 55 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/cfg.h
b/arch/arm/plat-omap/include/dspbridge/cfg.h
index 80c8fde..e99d4b4 100644
--- a/arch/arm/plat-omap/include/dspbridge/cfg.h
+++ b/arch/arm/plat-omap/include/dspbridge/cfg.h
@@ -194,29 +194,6 @@ extern dsp_status cfg_get_object(OUT u32 *pdwValue, u32
dw_type);
extern void cfg_get_perf_value(OUT bool *pfEnablePerf);
/*
- * cfg_get_wmd_file_name
- * Purpose:
- *Get the mini-driver file name for a given device.
- * Parameters:
- * dev_node_obj: Handle to the dev_node who's WMD we are querying.
- * buf_size: Size of buffer.
- * pWMDFileName: Ptr to a character buffer to hold the WMD filename.
- * Returns:
- * DSP_SOK:On success.
- * CFG_E_INVALIDHDEVNODE: dev_node_obj is invalid.
- * CFG_E_RESOURCENOTAVAIL: The filename is not available.
- * Requires:
- * CFG initialized.
- * Ensures:
- * DSP_SOK:Not more than buf_size bytes were copied
- * into pWMDFileName.
- *
- */
-extern dsp_status cfg_get_wmd_file_name(IN struct cfg_devnode *dev_node_obj,
- IN u32 buf_size,
- OUT char *pWMDFileName);
-
-/*
* cfg_get_zl_file
* Purpose:
* Retreive the ZLFile, if any, for this board.
diff --git a/arch/arm/plat-omap/include/dspbridge/dev.h
b/arch/arm/plat-omap/include/dspbridge/dev.h
index d86ecd8..c26e9d0 100644
--- a/arch/arm/plat-omap/include/dspbridge/dev.h
+++ b/arch/arm/plat-omap/include/dspbridge/dev.h
@@ -509,9 +509,10 @@ extern dsp_status dev_get_symbol(struct dev_object
*hdev_obj,
IN CONST char *pstrSym, OUT u32 * pul_value);
/*
- * dev_get_wmd_context
+ * dev_get_bridge_context
* Purpose:
- * Retrieve the WMD Context handle, as returned by the WMD_Create fxn.
+ * Retrieve the Bridge Context handle, as returned by the
+ * bridge_dev_create fxn.
* Parameters:
* hdev_obj: Handle to device object created with dev_create_device()
* *phbridge_context: Ptr to location to store context handle.
@@ -525,7 +526,7 @@ extern dsp_status dev_get_symbol(struct dev_object
*hdev_obj,
* DSP_SOK:*phbridge_context contains context handle;
* else: *phbridge_context is NULL;
*/
-extern dsp_status dev_get_wmd_context(struct dev_object *hdev_obj,
+extern dsp_status dev_get_bridge_context(struct dev_object *hdev_obj,
OUT struct bridge_dev_context
**phbridge_context);
diff --git a/drivers/dsp/bridge/pmgr/dev.c b/drivers/dsp/bridge/pmgr/dev.c
index 14e0b49..e1ebb5d 100644
--- a/drivers/dsp/bridge/pmgr/dev.c
+++ b/drivers/dsp/bridge/pmgr/dev.c
@@ -711,11 +711,12 @@ dsp_status dev_get_symbol(struct dev_object *hdev_obj,
}
/*
- * dev_get_wmd_context
+ * dev_get_bridge_context
* Purpose:
- * Retrieve the WMD Context handle, as returned by the WMD_Create fxn.
+ * Retrieve the Bridge Context handle, as returned by the
+ * bridge_dev_create fxn.
*/
-dsp_status dev_get_wmd_context(struct dev_object *hdev_obj,
+dsp_status dev_get_bridge_context(struct dev_object *hdev_obj,
OUT struct bridge_dev_context **phbridge_context)
{
dsp_status status = DSP_SOK;
diff --git a/drivers/dsp/bridge/rmgr/node.c b/drivers/dsp/bridge/rmgr/node.c
index 80a54d4..ddf54df 100644
--- a/drivers/dsp/bridge/rmgr/node.c
+++ b/drivers/dsp/bridge/rmgr/node.c
@@ -3144,7 +3144,7 @@ static u32 ovly(void *priv_ref, u32 ulDspRunAddr, u32
ulDspLoadAddr,
/* Call new MemCopy function */
intf_fxns = hnode_mgr->intf_fxns;
- status = dev_get_wmd_context(hnode_mgr->hdev_obj, &hbridge_context);
+ status = dev_get_bridge
[PATCH 09/11] DSPBRIDGE: Append the content of _dcd.h into dspapi.h
The header file _dcd.h contained the function prototypes of dspapi.c, so _dcd.h file is removed and its content is placed into dspapi.h. Signed-off-by: Ivan Gomez Castellanos --- arch/arm/plat-omap/include/dspbridge/_dcd.h | 152 - arch/arm/plat-omap/include/dspbridge/dspapi.h | 151 +++-- drivers/dsp/bridge/pmgr/dspapi.c |2 +- drivers/dsp/bridge/rmgr/drv_interface.c |2 +- drivers/dsp/bridge/rmgr/dspdrv.c |2 +- 5 files changed, 144 insertions(+), 165 deletions(-) delete mode 100644 arch/arm/plat-omap/include/dspbridge/_dcd.h diff --git a/arch/arm/plat-omap/include/dspbridge/_dcd.h b/arch/arm/plat-omap/include/dspbridge/_dcd.h deleted file mode 100644 index 4c3f701..000 --- a/arch/arm/plat-omap/include/dspbridge/_dcd.h +++ /dev/null @@ -1,152 +0,0 @@ -/* - * _dcd.h - * - * DSP-BIOS Bridge driver support functions for TI OMAP processors. - * - * Includes the wrapper functions called directly by the - * DeviceIOControl interface. - * - * Copyright (C) 2005-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. - */ - -#ifndef _WCD_ -#define _WCD_ - -#include - -/* - * api_call_dev_ioctl - * Purpose: - * Call the (wrapper) function for the corresponding API IOCTL. - * Parameters: - * cmd:IOCTL id, base 0. - * args: Argument structure. - * pResult: - * Returns: - * DSP_SOK if command called; DSP_EINVALIDARG if command not in IOCTL - * table. - * Requires: - * Ensures: - */ -extern dsp_status api_call_dev_ioctl(unsigned int cmd, - union Trapped_Args *args, - u32 *pResult, void *pr_ctxt); - -/* - * api_init - * Purpose: - * Initialize modules used by Bridge API. - * This procedure is called when the driver is loaded. - * Parameters: - * Returns: - * TRUE if success; FALSE otherwise. - * Requires: - * Ensures: - */ -extern bool api_init(void); - -/* - * api_init_complete2 - * Purpose: - * Perform any required bridge initialization which cannot - * be performed in api_init() or dev_start_device() due - * to the fact that some services are not yet - * completely initialized. - * Parameters: - * Returns: - * DSP_SOK:Allow this device to load - * DSP_EFAIL: Failure. - * Requires: - * Bridge API initialized. - * Ensures: - */ -extern dsp_status api_init_complete2(void); - -/* - * api_exit - * Purpose: - * Exit all modules initialized in api_init(void). - * This procedure is called when the driver is unloaded. - * Parameters: - * Returns: - * Requires: - * api_init(void) was previously called. - * Ensures: - * Resources acquired in api_init(void) are freed. - */ -extern void api_exit(void); - -/* MGR wrapper functions */ -extern u32 mgrwrap_enum_node_info(union Trapped_Args *args, void *pr_ctxt); -extern u32 mgrwrap_enum_proc_info(union Trapped_Args *args, void *pr_ctxt); -extern u32 mgrwrap_register_object(union Trapped_Args *args, void *pr_ctxt); -extern u32 mgrwrap_unregister_object(union Trapped_Args *args, void *pr_ctxt); -extern u32 mgrwrap_wait_for_bridge_events(union Trapped_Args *args, - void *pr_ctxt); - -extern u32 mgrwrap_get_process_resources_info(union Trapped_Args *args, - void *pr_ctxt); - -/* CPRC (Processor) wrapper Functions */ -extern u32 procwrap_attach(union Trapped_Args *args, void *pr_ctxt); -extern u32 procwrap_ctrl(union Trapped_Args *args, void *pr_ctxt); -extern u32 procwrap_detach(union Trapped_Args *args, void *pr_ctxt); -extern u32 procwrap_enum_node_info(union Trapped_Args *args, void *pr_ctxt); -extern u32 procwrap_enum_resources(union Trapped_Args *args, void *pr_ctxt); -extern u32 procwrap_get_state(union Trapped_Args *args, void *pr_ctxt); -extern u32 procwrap_get_trace(union Trapped_Args *args, void *pr_ctxt); -extern u32 procwrap_load(union Trapped_Args *args, void *pr_ctxt); -extern u32 procwrap_register_notify(union Trapped_Args *args, void *pr_ctxt); -extern u32 procwrap_start(union Trapped_Args *args, void *pr_ctxt); -extern u32 procwrap_reserve_memory(union Trapped_Args *args, void *pr_ctxt); -extern u32 procwrap_un_reserve_memory(union Trapped_Args *args, void *pr_ctxt); -extern u32 procwrap_map(union Trapped_Args *args, void *pr_ctxt); -extern u32 procwrap_un_map(union Trapped_Args *args, void *pr_ctxt); -extern u32 procwrap_flush
[PATCH 08/11] DSPBRIDGE: Rename files that refer to Windows OS
Since "wmd" (windows mini driver) and "wcd" (windows class driver)
refers to Windows OS, the following files are renamed:
wmd.h ==> dspdefs.h
wmdchnl.h ==> dspchnl.h
wmddeh.h ==> dspdeh.h
wmdio.h ==> dspio.h
wmdioctl.h ==> dspioctl.h
wmdmsg.h ==> dspmsg.h
wcd.h ==> dspapi.h
wcdioctl.h ==> dspapi-ioctl.h
wcd.c ==> dspapi.c
Signed-off-by: Ivan Gomez Castellanos
---
arch/arm/plat-omap/include/dspbridge/_chnl_sm.h|4 ++--
arch/arm/plat-omap/include/dspbridge/_dcd.h|2 +-
arch/arm/plat-omap/include/dspbridge/dev.h |2 +-
arch/arm/plat-omap/include/dspbridge/devdefs.h |2 +-
arch/arm/plat-omap/include/dspbridge/drvdefs.h |2 +-
.../dspbridge/{wcdioctl.h => dspapi-ioctl.h} |2 +-
.../include/dspbridge/{wcd.h => dspapi.h} |2 +-
.../include/dspbridge/{wmdchnl.h => dspchnl.h} |4 ++--
.../include/dspbridge/{wmd.h => dspdefs.h} |2 +-
.../include/dspbridge/{wmddeh.h => dspdeh.h} |4 ++--
.../include/dspbridge/{wmdio.h => dspio.h} |4 ++--
.../include/dspbridge/{wmdioctl.h => dspioctl.h} |2 +-
.../include/dspbridge/{wmdmsg.h => dspmsg.h} |4 ++--
drivers/dsp/bridge/Makefile|2 +-
drivers/dsp/bridge/core/_deh.h |2 +-
drivers/dsp/bridge/core/_tiomap.h |2 +-
drivers/dsp/bridge/core/chnl_sm.c |4 ++--
drivers/dsp/bridge/core/io_sm.c|6 +++---
drivers/dsp/bridge/core/mmu_fault.c|2 +-
drivers/dsp/bridge/core/msg_sm.c |2 +-
drivers/dsp/bridge/core/tiomap3430.c | 12 ++--
drivers/dsp/bridge/core/tiomap3430_pwr.c |2 +-
drivers/dsp/bridge/core/ue_deh.c |4 ++--
drivers/dsp/bridge/core/wdt.c |2 +-
drivers/dsp/bridge/pmgr/chnlobj.h |2 +-
drivers/dsp/bridge/pmgr/dev.c |2 +-
drivers/dsp/bridge/pmgr/{wcd.c => dspapi.c}|4 ++--
drivers/dsp/bridge/pmgr/ioobj.h|2 +-
drivers/dsp/bridge/pmgr/msg.c |2 +-
drivers/dsp/bridge/pmgr/msgobj.h |2 +-
drivers/dsp/bridge/rmgr/disp.c |2 +-
drivers/dsp/bridge/rmgr/drv.c |2 +-
drivers/dsp/bridge/rmgr/drv_interface.c|2 +-
drivers/dsp/bridge/rmgr/node.c |4 ++--
drivers/dsp/bridge/rmgr/proc.c |6 +++---
drivers/dsp/bridge/rmgr/pwr.c |2 +-
drivers/dsp/bridge/rmgr/strm.c |2 +-
37 files changed, 55 insertions(+), 55 deletions(-)
rename arch/arm/plat-omap/include/dspbridge/{wcdioctl.h => dspapi-ioctl.h}
(99%)
rename arch/arm/plat-omap/include/dspbridge/{wcd.h => dspapi.h} (99%)
rename arch/arm/plat-omap/include/dspbridge/{wmdchnl.h => dspchnl.h} (97%)
rename arch/arm/plat-omap/include/dspbridge/{wmd.h => dspdefs.h} (99%)
rename arch/arm/plat-omap/include/dspbridge/{wmddeh.h => dspdeh.h} (98%)
rename arch/arm/plat-omap/include/dspbridge/{wmdio.h => dspio.h} (95%)
rename arch/arm/plat-omap/include/dspbridge/{wmdioctl.h => dspioctl.h} (99%)
rename arch/arm/plat-omap/include/dspbridge/{wmdmsg.h => dspmsg.h} (96%)
rename drivers/dsp/bridge/pmgr/{wcd.c => dspapi.c} (99%)
diff --git a/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
b/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
index 8bba33f..cc998de 100644
--- a/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
+++ b/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
@@ -23,8 +23,8 @@
#ifndef _CHNL_SM_
#define _CHNL_SM_
-#include
-#include
+#include
+#include
#include
#include
diff --git a/arch/arm/plat-omap/include/dspbridge/_dcd.h
b/arch/arm/plat-omap/include/dspbridge/_dcd.h
index 589cd42..4c3f701 100644
--- a/arch/arm/plat-omap/include/dspbridge/_dcd.h
+++ b/arch/arm/plat-omap/include/dspbridge/_dcd.h
@@ -20,7 +20,7 @@
#ifndef _WCD_
#define _WCD_
-#include
+#include
/*
* api_call_dev_ioctl
diff --git a/arch/arm/plat-omap/include/dspbridge/dev.h
b/arch/arm/plat-omap/include/dspbridge/dev.h
index 3ada31d..ac011cd 100644
--- a/arch/arm/plat-omap/include/dspbridge/dev.h
+++ b/arch/arm/plat-omap/include/dspbridge/dev.h
@@ -26,7 +26,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/arch/arm/plat-omap/include/dspbridge/devdefs.h
b/arch/arm/plat-omap/include/dspbridge/devdefs.h
index 8c0adc1..600be0e 100644
--- a/arch/arm/plat-omap/include/dspbridge/devdefs.h
+++ b/arch/arm/plat-omap/include/dspbridge/devdefs.h
@@ -3,7 +3,7 @@
*
* DSP-BIOS Bridge driver support functions for TI OMAP processors.
*
- * Definition of common include typedef between wmd.h and dev.h. Required
+ * Definition of common include typedef between dspdefs.h and dev.h. Required
* to break circular dependency betwe
[PATCH 05/11] DSPBRIDGE: Replace code containing "WMD"
This patch removes references to Windows OS, and since "WMD" means windows mini driver, then it is replaced by "BRD" which means Bridge. Signed-off-by: Ivan Gomez Castellanos --- arch/arm/plat-omap/include/dspbridge/errbase.h | 12 +++--- arch/arm/plat-omap/include/dspbridge/wmd.h |2 +- arch/arm/plat-omap/include/dspbridge/wmdioctl.h | 38 +++--- drivers/dsp/bridge/rmgr/node.c |2 +- drivers/dsp/bridge/rmgr/proc.c |6 ++-- drivers/dsp/bridge/rmgr/pwr.c | 10 +++--- drivers/dsp/bridge/wmd/_tiomap.h|2 +- drivers/dsp/bridge/wmd/io_sm.c | 14 drivers/dsp/bridge/wmd/tiomap3430.c | 32 +- drivers/dsp/bridge/wmd/tiomap3430_pwr.c |4 +- 10 files changed, 61 insertions(+), 61 deletions(-) diff --git a/arch/arm/plat-omap/include/dspbridge/errbase.h b/arch/arm/plat-omap/include/dspbridge/errbase.h index d43ff86..ff0c2de 100644 --- a/arch/arm/plat-omap/include/dspbridge/errbase.h +++ b/arch/arm/plat-omap/include/dspbridge/errbase.h @@ -268,10 +268,10 @@ #define DEV_EBASE (DSP_COMP_EBASE + 0x000) /* The mini-driver expected a newer version of the class driver. */ -#define DEV_E_NEWWMD(DEV_EBASE + 0x00) +#define DEV_E_NEWBRD(DEV_EBASE + 0x00) /* bridge_drv_entry function returned a NULL function interface table. */ -#define DEV_E_NULLWMDINTF (DEV_EBASE + 0x01) +#define DEV_E_NULLBRDINTF (DEV_EBASE + 0x01) /* FAILURE Codes : LDR */ #define LDR_EBASE (DSP_COMP_EBASE + 0x100) @@ -417,16 +417,16 @@ #define SYNC_E_TIMEOUT (SYNC_EBASE + 0x01) /* FAILURE Codes : WMD */ -#define WMD_EBASE (DSP_COMP_EBASE + 0x700) +#define BRD_EBASE (DSP_COMP_EBASE + 0x700) /* A test of hardware assumptions or integrity failed. */ -#define WMD_E_HARDWARE (WMD_EBASE + 0x00) +#define BRD_E_HARDWARE (BRD_EBASE + 0x00) /* One or more configuration parameters violated WMD hardware assumptions. */ -#define WMD_E_BADCONFIG (WMD_EBASE + 0x01) +#define BRD_E_BADCONFIG (BRD_EBASE + 0x01) /* Timeout occurred waiting for a response from the hardware. */ -#define WMD_E_TIMEOUT (WMD_EBASE + 0x02) +#define BRD_E_TIMEOUT (BRD_EBASE + 0x02) /* FAILURE Codes : REG */ #define REG_EBASE (DSP_COMP_EBASE + 0x800) diff --git a/arch/arm/plat-omap/include/dspbridge/wmd.h b/arch/arm/plat-omap/include/dspbridge/wmd.h index 4355590..cebc8c5 100644 --- a/arch/arm/plat-omap/include/dspbridge/wmd.h +++ b/arch/arm/plat-omap/include/dspbridge/wmd.h @@ -41,7 +41,7 @@ * Any IOCTLS at or above this value are reserved for standard WMD * interfaces. */ -#define WMD_RESERVEDIOCTLBASE 0x8000 +#define BRD_RESERVEDIOCTLBASE 0x8000 /* Handle to mini-driver's private device context. */ struct bridge_dev_context; diff --git a/arch/arm/plat-omap/include/dspbridge/wmdioctl.h b/arch/arm/plat-omap/include/dspbridge/wmdioctl.h index ba921bc..9fe5543 100644 --- a/arch/arm/plat-omap/include/dspbridge/wmdioctl.h +++ b/arch/arm/plat-omap/include/dspbridge/wmdioctl.h @@ -27,37 +27,37 @@ * Any IOCTLS at or above this value are reserved for standard WMD * interfaces. */ -#define WMDIOCTL_RESERVEDBASE 0x8000 +#define BRDIOCTL_RESERVEDBASE 0x8000 -#define WMDIOCTL_CHNLREAD (WMDIOCTL_RESERVEDBASE + 0x10) -#define WMDIOCTL_CHNLWRITE (WMDIOCTL_RESERVEDBASE + 0x20) -#define WMDIOCTL_GETINTRCOUNT (WMDIOCTL_RESERVEDBASE + 0x30) -#define WMDIOCTL_RESETINTRCOUNT (WMDIOCTL_RESERVEDBASE + 0x40) -#define WMDIOCTL_INTERRUPTDSP (WMDIOCTL_RESERVEDBASE + 0x50) +#define BRDIOCTL_CHNLREAD (BRDIOCTL_RESERVEDBASE + 0x10) +#define BRDIOCTL_CHNLWRITE (BRDIOCTL_RESERVEDBASE + 0x20) +#define BRDIOCTL_GETINTRCOUNT (BRDIOCTL_RESERVEDBASE + 0x30) +#define BRDIOCTL_RESETINTRCOUNT (BRDIOCTL_RESERVEDBASE + 0x40) +#define BRDIOCTL_INTERRUPTDSP (BRDIOCTL_RESERVEDBASE + 0x50) /* DMMU */ -#define WMDIOCTL_SETMMUCONFIG (WMDIOCTL_RESERVEDBASE + 0x60) +#define BRDIOCTL_SETMMUCONFIG (BRDIOCTL_RESERVEDBASE + 0x60) /* PWR */ -#define WMDIOCTL_PWRCONTROL (WMDIOCTL_RESERVEDBASE + 0x70) +#define BRDIOCTL_PWRCONTROL (BRDIOCTL_RESERVEDBASE + 0x70) /* attention, modifiers: * Some of these control enumerations are made visible to user for power * control, so any changes to this list, should also be updated in the user * header file 'dbdefs.h' ***/ /* These ioctls are reserved for PWR power commands for the DSP */ -#define WMDIOCTL_DEEPSLEEP (WMDIOCTL_PWRCONTROL + 0x0) -#define WMDIOCTL_EMERGENCYSLEEP (WMDIOCTL_PWRCONTROL + 0x1) -#define WMDIOCTL_WAKEUP (WMDIOCTL_PWRCONTROL + 0x2) -#define WMDIOCTL_PWRENABLE (WMDIOCTL_PWRCONTROL
[PATCH 11/11] DSPBRIDGE: Rename header file guard macros that cointain WMD or WCD
The patch "DSPBRIDGE: Rename files that refer to Windows OS", renamed
header files, and this patch renames its include guard macros by the
corresponding new header names.
Signed-off-by: Ivan Gomez Castellanos
---
.../arm/plat-omap/include/dspbridge/dspapi-ioctl.h |6 +++---
arch/arm/plat-omap/include/dspbridge/dspchnl.h |6 +++---
arch/arm/plat-omap/include/dspbridge/dspdefs.h |6 +++---
arch/arm/plat-omap/include/dspbridge/dspdeh.h |6 +++---
arch/arm/plat-omap/include/dspbridge/dspio.h |6 +++---
arch/arm/plat-omap/include/dspbridge/dspioctl.h|6 +++---
arch/arm/plat-omap/include/dspbridge/dspmsg.h |6 +++---
7 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dspapi-ioctl.h
b/arch/arm/plat-omap/include/dspbridge/dspapi-ioctl.h
index c214ea6..f6a146e 100644
--- a/arch/arm/plat-omap/include/dspbridge/dspapi-ioctl.h
+++ b/arch/arm/plat-omap/include/dspbridge/dspapi-ioctl.h
@@ -17,8 +17,8 @@
* WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*/
-#ifndef WCDIOCTL_
-#define WCDIOCTL_
+#ifndef DSPAPIIOCTL_
+#define DSPAPIIOCTL_
#include
#include
@@ -463,4 +463,4 @@ union Trapped_Args {
#define CMM_GETHANDLE _IOR(DB, DB_IOC(DB_CMM, 2), unsigned long)
#define CMM_GETINFO_IOR(DB, DB_IOC(DB_CMM, 3), unsigned long)
-#endif /* WCDIOCTL_ */
+#endif /* DSPAPIIOCTL_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/dspchnl.h
b/arch/arm/plat-omap/include/dspbridge/dspchnl.h
index 3c6f29d..acb0691 100644
--- a/arch/arm/plat-omap/include/dspbridge/dspchnl.h
+++ b/arch/arm/plat-omap/include/dspbridge/dspchnl.h
@@ -21,8 +21,8 @@
* WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*/
-#ifndef WMDCHNL_
-#define WMDCHNL_
+#ifndef DSPCHNL_
+#define DSPCHNL_
extern dsp_status bridge_chnl_create(OUT struct chnl_mgr **phChnlMgr,
struct dev_object *hdev_obj,
@@ -69,4 +69,4 @@ extern dsp_status bridge_chnl_register_notify(struct
chnl_object *chnl_obj,
struct dsp_notification
*hnotification);
-#endif /* WMDCHNL_ */
+#endif /* DSPCHNL_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/dspdefs.h
b/arch/arm/plat-omap/include/dspbridge/dspdefs.h
index 26a9988..b25f4b2 100644
--- a/arch/arm/plat-omap/include/dspbridge/dspdefs.h
+++ b/arch/arm/plat-omap/include/dspbridge/dspdefs.h
@@ -26,8 +26,8 @@
* WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*/
-#ifndef WMD_
-#define WMD_
+#ifndef DSPDEFS_
+#define DSPDEFS_
#include
#include
@@ -1132,4 +1132,4 @@ struct bridge_drv_interface {
void bridge_drv_entry(OUT struct bridge_drv_interface **ppDrvInterface,
IN CONST char *driver_file_name);
-#endif /* WMD_ */
+#endif /* DSPDEFS_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/dspdeh.h
b/arch/arm/plat-omap/include/dspbridge/dspdeh.h
index f6a747f..81d3459 100644
--- a/arch/arm/plat-omap/include/dspbridge/dspdeh.h
+++ b/arch/arm/plat-omap/include/dspbridge/dspdeh.h
@@ -20,8 +20,8 @@
* WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*/
-#ifndef WMDDEH_
-#define WMDDEH_
+#ifndef DSPDEH_
+#define DSPDEH_
#include
@@ -45,4 +45,4 @@ extern void bridge_deh_notify(struct deh_mgr *hdeh_mgr,
u32 ulEventMask, u32 dwErrInfo);
extern void bridge_deh_release_dummy_mem(void);
-#endif /* WMDDEH_ */
+#endif /* DSPDEH_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/dspio.h
b/arch/arm/plat-omap/include/dspbridge/dspio.h
index b010d2a..a826d9d 100644
--- a/arch/arm/plat-omap/include/dspbridge/dspio.h
+++ b/arch/arm/plat-omap/include/dspbridge/dspio.h
@@ -20,8 +20,8 @@
* WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*/
-#ifndef WMDIO_
-#define WMDIO_
+#ifndef DSPIO_
+#define DSPIO_
#include
#include
@@ -38,4 +38,4 @@ extern dsp_status iva_io_on_loaded(struct io_mgr *hio_mgr);
extern dsp_status bridge_io_get_proc_load(IN struct io_mgr *hio_mgr,
OUT struct dsp_procloadstat *pProcStat);
-#endif /* WMDIO_ */
+#endif /* DSPIO_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/dspioctl.h
b/arch/arm/plat-omap/include/dspbridge/dspioctl.h
index 3f7a787..380fff5 100644
--- a/arch/arm/plat-omap/include/dspbridge/dspioctl.h
+++ b/arch/arm/plat-omap/include/dspbridge/dspioctl.h
@@ -16,8 +16,8 @@
* WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*/
-#ifndef WMDIOCTL_
-#define WMDIOCTL_
+#ifndef DSPIOCTL_
+#define DSPIOCTL_
/* Hardware Abstraction Layer */
#include
@@ -70,4 +70,4 @@ struct bridge_ioctl_extproc {
enum hw_element_size_t elem_size;
};
-#endif /* WMDIOCTL_ */
+#endif /* DSPIOCTL_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/dspmsg.h
b/arch/arm/plat-oma
[PATCH 00/11] DSPBRIDGE: Remove code and comments refering to other OS
As this code is generic to Linux, this patch series replaces code
and comments thar refers to other OS.
Ivan Gomez Castellanos (10):
DSPBRIDGE: Rename wmd_dev_context structure by bridge_dev_context
DSPBRIDGE: Rename the device context handle variables
DSPBRIDGE: Rename variables and structures which contain "wmd"
DSPBRIDGE: Rename functions which contain "wmd" and remove unused
prototypes
DSPBRIDGE: Replace code containing "WMD"
DSPBRIDGE: Replace code containing "wcd"
DSPBRIDGE: Rename "wmd" directory by "core"
DSPBRIDGE: Rename files that refer to Windows OS
DSPBRIDGE: Append the content of _dcd.h into dspapi.h
DSPBRIDGE: Rename header file guard macros that cointain WMD or WCD
Omar Ramirez Luna (1):
DSPBRIDGE: Remove OS specific comments
arch/arm/plat-omap/include/dspbridge/_chnl_sm.h|4 +-
arch/arm/plat-omap/include/dspbridge/cfg.h | 23 ---
arch/arm/plat-omap/include/dspbridge/dev.h | 49 +++---
arch/arm/plat-omap/include/dspbridge/devdefs.h |2 +-
arch/arm/plat-omap/include/dspbridge/drvdefs.h |2 +-
.../dspbridge/{wcdioctl.h => dspapi-ioctl.h} |8 +-
.../include/dspbridge/{_dcd.h => dspapi.h} | 61 ---
.../include/dspbridge/{wmdchnl.h => dspchnl.h} | 10 +-
.../include/dspbridge/{wmd.h => dspdefs.h} | 50 +++---
.../include/dspbridge/{wmddeh.h => dspdeh.h} | 10 +-
.../include/dspbridge/{wmdio.h => dspio.h} | 10 +-
.../include/dspbridge/{wmdioctl.h => dspioctl.h} | 48 +++---
.../include/dspbridge/{wmdmsg.h => dspmsg.h} | 10 +-
arch/arm/plat-omap/include/dspbridge/errbase.h | 12 +-
arch/arm/plat-omap/include/dspbridge/io_sm.h | 16 +-
arch/arm/plat-omap/include/dspbridge/mgr.h |2 +-
arch/arm/plat-omap/include/dspbridge/wcd.h | 36
drivers/dsp/bridge/Makefile| 12 +-
drivers/dsp/bridge/{wmd => core}/_cmm.h|0
drivers/dsp/bridge/{wmd => core}/_deh.h|5 +-
drivers/dsp/bridge/{wmd => core}/_msg_sm.h |0
drivers/dsp/bridge/{wmd => core}/_tiomap.h | 18 +--
drivers/dsp/bridge/{wmd => core}/_tiomap_mmu.h |2 +-
drivers/dsp/bridge/{wmd => core}/_tiomap_pwr.h | 26 ++--
drivers/dsp/bridge/{wmd => core}/_tiomap_util.h|2 +-
drivers/dsp/bridge/{wmd => core}/chnl_sm.c | 14 +-
drivers/dsp/bridge/{wmd => core}/io_sm.c | 164 +-
drivers/dsp/bridge/{wmd => core}/mmu_fault.c | 10 +-
drivers/dsp/bridge/{wmd => core}/mmu_fault.h |0
drivers/dsp/bridge/{wmd => core}/msg_sm.c |2 +-
drivers/dsp/bridge/{wmd => core}/tiomap3430.c | 185 ++--
drivers/dsp/bridge/{wmd => core}/tiomap3430_pwr.c | 25 ++--
drivers/dsp/bridge/{wmd => core}/tiomap_io.c | 10 +-
drivers/dsp/bridge/{wmd => core}/tiomap_io.h | 12 +-
drivers/dsp/bridge/{wmd => core}/ue_deh.c | 22 ++--
drivers/dsp/bridge/{wmd => core}/wdt.c |2 +-
drivers/dsp/bridge/pmgr/chnlobj.h |2 +-
drivers/dsp/bridge/pmgr/dev.c | 90 +-
drivers/dsp/bridge/pmgr/{wcd.c => dspapi.c}| 64
drivers/dsp/bridge/pmgr/ioobj.h|5 +-
drivers/dsp/bridge/pmgr/msg.c |2 +-
drivers/dsp/bridge/pmgr/msgobj.h |2 +-
drivers/dsp/bridge/rmgr/disp.c |2 +-
drivers/dsp/bridge/rmgr/drv.c |6 +-
drivers/dsp/bridge/rmgr/drv_interface.c|6 +-
drivers/dsp/bridge/rmgr/dspdrv.c | 16 +-
drivers/dsp/bridge/rmgr/node.c | 25 ++--
drivers/dsp/bridge/rmgr/proc.c | 50 +++---
drivers/dsp/bridge/rmgr/pwr.c | 36 ++--
drivers/dsp/bridge/rmgr/strm.c |2 +-
50 files changed, 565 insertions(+), 607 deletions(-)
rename arch/arm/plat-omap/include/dspbridge/{wcdioctl.h => dspapi-ioctl.h}
(99%)
rename arch/arm/plat-omap/include/dspbridge/{_dcd.h => dspapi.h} (78%)
rename arch/arm/plat-omap/include/dspbridge/{wmdchnl.h => dspchnl.h} (94%)
rename arch/arm/plat-omap/include/dspbridge/{wmd.h => dspdefs.h} (96%)
rename arch/arm/plat-omap/include/dspbridge/{wmddeh.h => dspdeh.h} (94%)
rename arch/arm/plat-omap/include/dspbridge/{wmdio.h => dspio.h} (91%)
rename arch/arm/plat-omap/include/dspbridge/{wmdioctl.h => dspioctl.h} (54%)
rename arch/arm/plat-omap/include/dspbridge/{wmdmsg.h => dspmsg.h} (93%)
delete mode 100644 arch/arm/plat-omap/include/dspbridge/wcd.h
rename drivers/dsp/bridge/{wmd => core}/_cmm.h (100%)
rename drivers/dsp/bridge/{wmd => core}/_deh.h (89%)
rename drivers/dsp/bridge/{wmd => core}/_msg_sm.h (100%)
rename drivers/dsp/bridge/{wmd => core}/_tiomap.h (95%)
rename drivers/dsp/bridge/{wmd => core}/_tiomap_mmu.h (94%)
rename drivers/dsp/bridge/{wmd => core}
[PATCH 01/11] DSPBRIDGE: Rename wmd_dev_context structure by bridge_dev_context
This change is done because "wmd" refers to Windows OS. wmd = windows mini driver And the new name "bridge_dev_context" make more sense. Signed-off-by: Ivan Gomez Castellanos --- arch/arm/plat-omap/include/dspbridge/dev.h |2 +- arch/arm/plat-omap/include/dspbridge/io_sm.h | 14 ++-- arch/arm/plat-omap/include/dspbridge/wmd.h | 30 drivers/dsp/bridge/pmgr/dev.c|4 +- drivers/dsp/bridge/pmgr/ioobj.h |3 +- drivers/dsp/bridge/rmgr/node.c |4 +- drivers/dsp/bridge/rmgr/proc.c |2 +- drivers/dsp/bridge/rmgr/pwr.c| 16 ++-- drivers/dsp/bridge/wmd/_deh.h|3 +- drivers/dsp/bridge/wmd/_tiomap.h | 12 ++-- drivers/dsp/bridge/wmd/_tiomap_mmu.h |2 +- drivers/dsp/bridge/wmd/_tiomap_pwr.h | 26 --- drivers/dsp/bridge/wmd/_tiomap_util.h|2 +- drivers/dsp/bridge/wmd/io_sm.c | 18 ++-- drivers/dsp/bridge/wmd/mmu_fault.c |8 +- drivers/dsp/bridge/wmd/tiomap3430.c | 116 +- drivers/dsp/bridge/wmd/tiomap3430_pwr.c | 19 ++-- drivers/dsp/bridge/wmd/tiomap_io.h | 12 ++-- drivers/dsp/bridge/wmd/ue_deh.c |8 +- 19 files changed, 154 insertions(+), 147 deletions(-) diff --git a/arch/arm/plat-omap/include/dspbridge/dev.h b/arch/arm/plat-omap/include/dspbridge/dev.h index 13b0cad..6df8db7 100644 --- a/arch/arm/plat-omap/include/dspbridge/dev.h +++ b/arch/arm/plat-omap/include/dspbridge/dev.h @@ -526,7 +526,7 @@ extern dsp_status dev_get_symbol(struct dev_object *hdev_obj, * else: *phWmdContext is NULL; */ extern dsp_status dev_get_wmd_context(struct dev_object *hdev_obj, - OUT struct wmd_dev_context + OUT struct bridge_dev_context **phWmdContext); /* diff --git a/arch/arm/plat-omap/include/dspbridge/io_sm.h b/arch/arm/plat-omap/include/dspbridge/io_sm.h index bebf011..177bfeb 100644 --- a/arch/arm/plat-omap/include/dspbridge/io_sm.h +++ b/arch/arm/plat-omap/include/dspbridge/io_sm.h @@ -263,21 +263,21 @@ extern dsp_status io_sh_msetting(struct io_mgr *hio_mgr, u8 desc, void *pargs); /* Maximum channel bufsize that can be used. */ extern u32 io_buf_size(struct io_mgr *hio_mgr); -extern u32 io_read_value(struct wmd_dev_context *hDevContext, u32 dwDSPAddr); +extern u32 io_read_value(struct bridge_dev_context *hDevContext, u32 dwDSPAddr); -extern void io_write_value(struct wmd_dev_context *hDevContext, +extern void io_write_value(struct bridge_dev_context *hDevContext, u32 dwDSPAddr, u32 dwValue); -extern u32 io_read_value_long(struct wmd_dev_context *hDevContext, +extern u32 io_read_value_long(struct bridge_dev_context *hDevContext, u32 dwDSPAddr); -extern void io_write_value_long(struct wmd_dev_context *hDevContext, +extern void io_write_value_long(struct bridge_dev_context *hDevContext, u32 dwDSPAddr, u32 dwValue); -extern void io_or_set_value(struct wmd_dev_context *hDevContext, +extern void io_or_set_value(struct bridge_dev_context *hDevContext, u32 dwDSPAddr, u32 dwValue); -extern void io_and_set_value(struct wmd_dev_context *hDevContext, +extern void io_and_set_value(struct bridge_dev_context *hDevContext, u32 dwDSPAddr, u32 dwValue); extern void io_intr_dsp2(IN struct io_mgr *pio_mgr, IN u16 mb_val); @@ -288,7 +288,7 @@ extern void io_sm_init(void); * print_dsp_trace_buffer * Print DSP tracebuffer. */ -extern dsp_status print_dsp_trace_buffer(struct wmd_dev_context +extern dsp_status print_dsp_trace_buffer(struct bridge_dev_context *hwmd_context); #endif /* IOSM_ */ diff --git a/arch/arm/plat-omap/include/dspbridge/wmd.h b/arch/arm/plat-omap/include/dspbridge/wmd.h index 6a41975..40be6da 100644 --- a/arch/arm/plat-omap/include/dspbridge/wmd.h +++ b/arch/arm/plat-omap/include/dspbridge/wmd.h @@ -44,7 +44,7 @@ #define WMD_RESERVEDIOCTLBASE 0x8000 /* Handle to mini-driver's private device context. */ -struct wmd_dev_context; +struct bridge_dev_context; /*--- */ /* 'Bridge MINI DRIVER FUNCTION TYPES */ @@ -67,7 +67,7 @@ struct wmd_dev_context; * DSP_SOK:Board is in BRD_IDLE state; * else: Board state is indeterminate. */ -typedef dsp_status(*fxn_brd_monitor) (struct wmd_dev_context *hDevContext); +typedef dsp_status(*fxn_brd_monitor) (struct bridge_dev_context *hDevContext); /* * fxn_brd_setstate @@ -86,7 +86,7 @@ typedef dsp_status(*fxn_brd_monitor) (struct wmd_dev_context *hDevContext); * ulBrdState <= BRD_LASTSTATE. * Update
[PATCH 03/11] DSPBRIDGE: Rename variables and structures which contain "wmd"
This patch removes code that refers to Windows OS (wmd = windows
mini driver). The following are renamed:
wmd_interface ==> bridge_interface
sz_wmd_file_name ==> bridge_file_name
dw_wmd_version ==> version
wmdioct_extproc ==> bridge_ioctl_extproc
pstrWMDFileName ==> driver_file_name
Signed-off-by: Ivan Gomez Castellanos
---
arch/arm/plat-omap/include/dspbridge/dev.h | 12
arch/arm/plat-omap/include/dspbridge/wmd.h |2 +-
arch/arm/plat-omap/include/dspbridge/wmdioctl.h |2 +-
drivers/dsp/bridge/pmgr/dev.c | 35 ---
drivers/dsp/bridge/wmd/_tiomap.h|4 +-
drivers/dsp/bridge/wmd/io_sm.c |2 +-
drivers/dsp/bridge/wmd/tiomap3430.c |9 +++--
7 files changed, 34 insertions(+), 32 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dev.h
b/arch/arm/plat-omap/include/dspbridge/dev.h
index 5bff0b8..d86ecd8 100644
--- a/arch/arm/plat-omap/include/dspbridge/dev.h
+++ b/arch/arm/plat-omap/include/dspbridge/dev.h
@@ -65,7 +65,7 @@ extern u32 dev_brd_write_fxn(void *pArb,
* 'Bridge device.
* Parameters:
* phDevObject:Ptr to location to receive the device object handle.
- * pstrWMDFileName: Name of WMD PE DLL file to load. If the absolute
+ * driver_file_name: Name of WMD PE DLL file to load. If the absolute
* path is not provided, the file is loaded through
* 'Bridge's module search path.
* pHostConfig:Host configuration information, to be passed down
@@ -88,7 +88,7 @@ extern u32 dev_brd_write_fxn(void *pArb,
* Requires:
* DEV Initialized.
* phDevObject != NULL.
- * pstrWMDFileName != NULL.
+ * driver_file_name != NULL.
* pHostConfig != NULL.
* pDspConfig != NULL.
* Ensures:
@@ -98,7 +98,7 @@ extern u32 dev_brd_write_fxn(void *pArb,
*/
extern dsp_status dev_create_device(OUT struct dev_object
**phDevObject,
- IN CONST char *pstrWMDFileName,
+ IN CONST char *driver_file_name,
IN CONST struct cfg_hostres
*pHostConfig, IN CONST struct cfg_dspres
*pDspConfig,
@@ -110,7 +110,7 @@ extern dsp_status dev_create_device(OUT struct dev_object
* Called by the operating system to load the 'Bridge Mini Driver for IVA.
* Parameters:
* phDevObject:Ptr to location to receive the device object handle.
- * pstrWMDFileName: Name of WMD PE DLL file to load. If the absolute
+ * driver_file_name: Name of WMD PE DLL file to load. If the absolute
* path is not provided, the file is loaded through
* 'Bridge's module search path.
* pHostConfig:Host configuration information, to be passed down
@@ -133,7 +133,7 @@ extern dsp_status dev_create_device(OUT struct dev_object
* Requires:
* DEV Initialized.
* phDevObject != NULL.
- * pstrWMDFileName != NULL.
+ * driver_file_name != NULL.
* pHostConfig != NULL.
* pDspConfig != NULL.
* Ensures:
@@ -143,7 +143,7 @@ extern dsp_status dev_create_device(OUT struct dev_object
*/
extern dsp_status dev_create_iva_device(OUT struct dev_object
**phDevObject,
- IN CONST char *pstrWMDFileName,
+ IN CONST char *driver_file_name,
IN CONST struct cfg_hostres
*pHostConfig,
IN CONST struct cfg_dspres *pDspConfig,
diff --git a/arch/arm/plat-omap/include/dspbridge/wmd.h
b/arch/arm/plat-omap/include/dspbridge/wmd.h
index 40be6da..4355590 100644
--- a/arch/arm/plat-omap/include/dspbridge/wmd.h
+++ b/arch/arm/plat-omap/include/dspbridge/wmd.h
@@ -1130,6 +1130,6 @@ struct bridge_drv_interface {
* Win95: Called during the Device_Init phase.
*/
void bridge_drv_entry(OUT struct bridge_drv_interface **ppDrvInterface,
- IN CONST char *pstrWMDFileName);
+ IN CONST char *driver_file_name);
#endif /* WMD_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/wmdioctl.h
b/arch/arm/plat-omap/include/dspbridge/wmdioctl.h
index 6547e38..ba921bc 100644
--- a/arch/arm/plat-omap/include/dspbridge/wmdioctl.h
+++ b/arch/arm/plat-omap/include/dspbridge/wmdioctl.h
@@ -59,7 +59,7 @@
/* Number of actual DSP-MMU TLB entrries */
#define WMDIOCTL_NUMOFMMUTLB32
-struct wmdioctl_extproc {
+struct bridge_ioctl_extproc {
u32 ul_dsp_va; /* DSP virtual address */
u32 ul_gpp_pa; /* GPP physical address */
/* GPP virtual address. __va does not work for ioremapped addresses */
diff --git a/drivers/dsp/bridge/pmgr/
Re: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3
Tony Lindgren writes: > * Kevin Hilman [100430 14:56]: >> "Pandita, Vikram" writes: >> >> [...] >> >> > --- a/arch/arm/kernel/head.S >> > +++ b/arch/arm/kernel/head.S >> > @@ -328,6 +328,16 @@ __create_page_tables: >> > add r0, r4, #0xd800 >> 18 >> > str r3, [r0] >> > #endif >> > +#if defined(CONFIG_MACH_OMAP_ZOOM2) || >> >>defined(CONFIG_MACH_OMAP_ZOOM3) >> > + /* >> > + * Zoom2 and Zoom3 have UARTs only on the debug board. >> > + * The debug board is connected to the GPMC. >> > + */ >> > + add r0, r4, #0xfa00 >> 18 >> > + orr r0, r0, #0x0040 >> 18 @ ZOOM_UART_VIRT >> > + orr r3, r7, #0x1000 @ ZOOM_UART_BASE >> > + str r3, [r0] >> > +#endif >> >> I don't see why this part is needed. The same mapping is done using >> the .io_pg_offset in the machine description which is done just before >> this in head.S >> >>> >> >>> That mapping does not cover the GPMC area where this UART is. >> >> >> >>Hmm, then shouldn't that be fixed? I understood the .phys_io and and >> >>.io_pg_offset fields of the mach_desc to be specifically for mapping >> >>the early UART, and nothing else. >> > >> > Here is the problem - with current approach we need two mappings to >> > happen and the MACHINE_START() code allows for only one via >> > .io_pg_offset and .phys_io >> > >> > Why: >> >> > Tony's approach is to pass the information about the debug uart >> > number from the UART1 Scratchpad register. >> > >> > this introduces a dependency that >> > UART1 registers also be mapped (virt<->phy). >> > >> > So for Tony's approach to work, .phys_io/.io_pg_offset continued to >> > have 0x480 based mapping and for external uart zoom3 port, >> > create this extra mapping. >> > >> > So find a better way from compressed.S to pass the uart number to >> > kernel, and we can solve the problem. >> >> Ah, yet another reason to use a memory location instead of UART1 SCR >> to pass the UART info (c.f. [1]) > > That should work if we don't need to access any L4 registers > early on before .map_io. I'd say if we're accessing L4 regs before .map_io, it's a bug that needs to be fixed, but I don't think we are. If we were, we'd notice a hang when !CONFIG_DEBUG_LL since the .phys_io and .io_pg_offst are only mapped in when CONFIG_DEBUG_LL=y. I think we've been using .phys_io/.io_pg_offset incorrectly in OMAP as an early mapping of all the IO space, when it is intended just for use as early UART access, indicated by the comments in head.S and the fact that it's only used when CONFIG_DEBUG_LL=y Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] OMAP:GPIO: Implement GPIO as a platform device
Charulatha V writes:
> This patch implements GPIO as a early platform device. Also it
> implements OMAP2PLUS specific GPIO as HWMOD FW adapted driver.
Should include a summary explanation of why you're converting to an
early platform device as well.
> Inorder to convert GPIO as platform device, modifications are
> required in clock_data.c files so that device names can be
> used to obtain clock instead of getting clocks by name/NULL ptr.
ok
> Currently early platform device register does not do device_pm_init.
> Hence pm_runtime functions are not used to enable the GPIO device
> since gpio is early platform device.
OK for now, since this isn't using runtime PM, but maybe we need a
late_initcall() here to do the device_pm_init() + pm_runtime_enable()
This change log needs more description of the intended init sequence.
Right now it seems that there are multiple init paths. Now that GPIO
is an early_platform_device, we should be able to at least make
omap_gpio_init() static and remove its usage from all the board files.
Also, the driver and device separation and init is totally mixed
together and very confusing. The platform_driver is in
plat-omap/gpio.c and should be doing the driver init:
[early_]platform_driver_register() and _probe(). The platform_device
setup is in mach-omapX/gpio*.c and where the device init should be, in
this case early_platform_add_devices().
> Signed-off-by: Charulatha V
> Signed-off-by: Rajendra Nayak
> ---
> arch/arm/mach-omap1/Makefile |6 +
> arch/arm/mach-omap1/clock_data.c |2 +-
> arch/arm/mach-omap2/Makefile |2 +-
> arch/arm/mach-omap2/clock2420_data.c | 10 +-
> arch/arm/mach-omap2/clock2430_data.c | 14 +-
> arch/arm/mach-omap2/clock3xxx_data.c | 24 +-
> arch/arm/mach-omap2/clock44xx_data.c | 24 +-
> arch/arm/plat-omap/gpio.c | 405
>
> arch/arm/plat-omap/include/plat/gpio.h | 21 ++
> 9 files changed, 220 insertions(+), 288 deletions(-)
[...]
> @@ -1621,6 +1501,34 @@ static void __init omap_gpio_show_rev(void)
> */
> static struct lock_class_key gpio_lock_class;
>
> +static int init_gpio_info(void)
> +{
> + gpio_bank_bits = 32;
> +
> + if (cpu_is_omap15xx()) {
> + gpio_bank_count = 2;
> + gpio_bank_bits = 16;
> + } else if (cpu_is_omap16xx()) {
> + gpio_bank_count = 5;
> + gpio_bank_bits = 16;
> + } else if (cpu_is_omap7xx())
> + gpio_bank_count = 7;
> + else if (cpu_is_omap242x())
> + gpio_bank_count = 4;
> + else if (cpu_is_omap243x())
> + gpio_bank_count = 5;
> + else if (cpu_is_omap34xx() || cpu_is_omap44xx())
> + gpio_bank_count = OMAP34XX_NR_GPIOS;
Both the bank count and bank bits could be part of platform_data
and set in the SoC specific init. This is the GPIO driver part
and we're trying to make this as SoC independent as possible. Anytime
you need to add a cpu_is* or #ifdef in this code indicates something
that should be part of SoC specific init and passed in.
> + gpio_bank = kzalloc(gpio_bank_count * sizeof(struct gpio_bank),
> + GFP_KERNEL);
> + if (!gpio_bank) {
> + pr_err("Memory allocation failed for gpio_bank\n");
> + return -ENOMEM;
> + }
> + return 0;
> +}
> +
> static void omap_gpio_mod_init(struct gpio_bank *bank, int id)
> {
> if (cpu_class_is_omap2()) {
> @@ -1686,16 +1594,9 @@ static void omap_gpio_mod_init(struct gpio_bank *bank,
> int id)
>
> static void __init omap_gpio_chip_init(struct gpio_bank *bank)
> {
> - int j, gpio_bank_bits = 16;
> + int j;
> static int gpio;
>
> - if (cpu_is_omap7xx() && bank->method == METHOD_GPIO_7XX)
> - gpio_bank_bits = 32; /* 7xx has 32-bit GPIOs */
> -
> - if ((bank->method == METHOD_GPIO_24XX) ||
> - (bank->method == METHOD_GPIO_44XX))
> - gpio_bank_bits = 32;
> -
> bank->mod_usage = 0;
> /* REVISIT eventually switch from OMAP-specific gpio structs
>* over to the generic ones
> @@ -1737,140 +1638,103 @@ static void __init omap_gpio_chip_init(struct
> gpio_bank *bank)
> set_irq_data(bank->irq, bank);
> }
>
> -static int __init _omap_gpio_init(void)
> +static inline void get_gpio_dbck(struct platform_device *pdev,
> + struct gpio_bank *bank)
> {
> - int i;
> - int gpio = 0;
> + if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
> + bank->dbck = clk_get(&pdev->dev, "dbck");
> + if (IS_ERR(bank->dbck))
> + pr_err("GPIO: Could not get dbck\n");
> + }
> +}
> +static int __devinit omap_gpio_probe(struct platform_device *pdev)
> +{
> + static int gpio_init_done;
> + struct omap_gpio_platform_data *pdata;
> + int id;
> struct gpio_bank *bank;
> - int bank_size = SZ_8K; /* Module 4KB +
Re: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3
* Kevin Hilman [100430 14:56]: > "Pandita, Vikram" writes: > > [...] > > > --- a/arch/arm/kernel/head.S > > +++ b/arch/arm/kernel/head.S > > @@ -328,6 +328,16 @@ __create_page_tables: > >add r0, r4, #0xd800 >> 18 > >str r3, [r0] > > #endif > > +#if defined(CONFIG_MACH_OMAP_ZOOM2) || > >>defined(CONFIG_MACH_OMAP_ZOOM3) > > + /* > > + * Zoom2 and Zoom3 have UARTs only on the debug board. > > + * The debug board is connected to the GPMC. > > + */ > > + add r0, r4, #0xfa00 >> 18 > > + orr r0, r0, #0x0040 >> 18 @ ZOOM_UART_VIRT > > + orr r3, r7, #0x1000 @ ZOOM_UART_BASE > > + str r3, [r0] > > +#endif > > I don't see why this part is needed. The same mapping is done using > the .io_pg_offset in the machine description which is done just before > this in head.S > >>> > >>> That mapping does not cover the GPMC area where this UART is. > >> > >>Hmm, then shouldn't that be fixed? I understood the .phys_io and and > >>.io_pg_offset fields of the mach_desc to be specifically for mapping > >>the early UART, and nothing else. > > > > Here is the problem - with current approach we need two mappings to > > happen and the MACHINE_START() code allows for only one via > > .io_pg_offset and .phys_io > > > > Why: > > > Tony's approach is to pass the information about the debug uart > > number from the UART1 Scratchpad register. > > > > this introduces a dependency that > > UART1 registers also be mapped (virt<->phy). > > > > So for Tony's approach to work, .phys_io/.io_pg_offset continued to > > have 0x480 based mapping and for external uart zoom3 port, > > create this extra mapping. > > > > So find a better way from compressed.S to pass the uart number to > > kernel, and we can solve the problem. > > Ah, yet another reason to use a memory location instead of UART1 SCR > to pass the UART info (c.f. [1]) That should work if we don't need to access any L4 registers early on before .map_io. Regards, Tony > Kevin > > [1] http://marc.info/?l=linux-omap&m=127266219130713&w=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
Re: [PATCH 5/9] OMAP:GPIO: Introduce support for OMAP2PLUS chip specific GPIO
Charulatha V writes:
> This patch adds support for handling GPIO as a HWMOD adapted
> platform device for OMAP2PLUS chips.
>
> Signed-off-by: Charulatha V
> ---
> arch/arm/mach-omap2/gpio.c | 101
>
> 1 files changed, 101 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-omap2/gpio.c
>
> diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
> new file mode 100644
> index 000..6424050
> --- /dev/null
> +++ b/arch/arm/mach-omap2/gpio.c
> @@ -0,0 +1,101 @@
> +/*
> + * gpio.c - OMAP2PLUS-specific gpio code
> + *
> + * Copyright (C) 2010 Texas Instruments, Inc.
> + *
> + * Author:
> + * Charulatha V
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +static int gpio_bank_count;
> +
> +struct omap_device_pm_latency omap_gpio_latency[] = {
> + [0] = {
> + .deactivate_func = omap_device_idle_hwmods,
> + .activate_func = omap_device_enable_hwmods,
> + .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
> + },
> +};
> +
> +int __init gpio_init(void)
> +{
> + int i = 0;
> + static int is_early_device = true;
> +
> + do {
> + struct omap_device *od;
> + struct omap_hwmod *oh;
> + int hw_mod_name_len = 16;
> + int l;
> + char oh_name[hw_mod_name_len];
> + struct omap_gpio_platform_data *pdata;
> + char *name = "omap-gpio";
> +
> + l = snprintf(oh_name, hw_mod_name_len, "gpio%d_hwmod", i + 1);
> + WARN(l >= hw_mod_name_len,
> + "String buffer overflow in GPIO device setup\n");
> +
Rather than iterating over the name, you should have a hwmod_class for
GPIOs and use omap_hwmod_for_each_by_class() to iterate over all the
hwmods in the GPIO class.
> + oh = omap_hwmod_lookup(oh_name);
> + if (!oh) {
> + pr_err("Could not look up %s\n", oh_name);
> + i++;
> + continue;
> + }
> +
> + pdata = kzalloc(sizeof(struct omap_gpio_platform_data),
> + GFP_KERNEL);
> + if (!pdata) {
> + pr_err("Memory allocation failed gpio%d\n", i + 1);
> + return -ENOMEM;
> + }
> + pdata->base = oh->_rt_va;
> + pdata->irq = oh->mpu_irqs[0].irq;
base address and IRQ should not be part of platform_data. platform
driver should be using platform_get_resource() for both.
> + if (cpu_is_omap24xx() || cpu_is_omap34xx())
> + pdata->method = METHOD_GPIO_24XX;
> + if (cpu_is_omap44xx())
> + pdata->method = METHOD_GPIO_44XX;
> + pdata->virtual_irq_start = IH_GPIO_BASE + 32 * i;
> + pdata->device_enable = omap_device_enable;
> + pdata->device_idle = omap_device_idle;
> + pdata->device_shutdown = omap_device_shutdown;
These aren't valid for GPIO1 which is in WKUP. Maybe we need
to check if the hwmod is not in wkup_pwrdm before setting these?
> + od = omap_device_build(name, i, oh, pdata,
> + sizeof(*pdata), omap_gpio_latency,
> + ARRAY_SIZE(omap_gpio_latency),
> + is_early_device);
> + WARN(IS_ERR(od), "Cant build omap_device for %s:%s.\n",
> + name, oh->name);
> +
> + i++;
> + } while (i < gpio_bank_count);
> + is_early_device = false;
> +
> + return 0;
> +}
> +arch_initcall(gpio_init);
> +
> +int __init omap2_gpio_init(void)
> +{
> + if (cpu_is_omap242x())
> + gpio_bank_count = 4;
> + else if (cpu_is_omap243x())
> + gpio_bank_count = 5;
> + else if (cpu_is_omap34xx() || cpu_is_omap44xx())
> + gpio_bank_count = OMAP34XX_NR_GPIOS;
The count should be gathered after iterating over the GPIO hwmod class.
and should not need cpu_is checks.
> + if (gpio_init())
> + return -EINVAL;
> +
> + early_platform_driver_register_all("earlygpio");
> + early_platform_driver_probe("earlygpio", gpio_bank_count, 0);
> + return 0;
> +}
> --
> 1.6.3.3
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: PM: Fix compilation error observed when cpufreq is disabled
Ranjith Lohithakshan writes: > On Thu, 29-Apr-10 3:00 AM +0530, Kevin Hilman wrote: >> Ranjith Lohithakshan writes: >> >>> Currently on PM branch, compilation fails when cpufreq is disabled >>> >>> arch/arm/mach-omap2/clock3xxx_data.c: In function 'omap3xxx_clk_init': >>> arch/arm/mach-omap2/clock3xxx_data.c:3563: error: 'struct clk_functions' >>> has no member named 'clk_init_cpufreq_table' >>> arch/arm/mach-omap2/clock3xxx_data.c:3564: error: >>> 'omap3_clk_init_cpufreq_table' undeclared (first use >>> in this function) >>> arch/arm/mach-omap2/clock3xxx_data.c:3564: error: (Each undeclared >>> identifier is reported only once >>> arch/arm/mach-omap2/clock3xxx_data.c:3564: error: for each function it >>> appears in.) >>> make[1]: *** [arch/arm/mach-omap2/clock3xxx_data.o] Error 1 >>> make: *** [arch/arm/mach-omap2] Error 2 >>> >>> This patch fixes the issue by avoiding runtime init of >>> clk_init_cpufreq_table in omap3xxx_clk_init and instead doing it when >>> omap2_clk_functions are defined. >>> >>> Signed-off-by: Ranjith Lohithakshan >> >> Do you still have this problem? I'm unable to reproduce on current PM >> branch. > > No, I don't see this now. Might have got fixed in some of the recent > changes. > > Just FYI, I now see a linkage error with omap3_evm_defconfig > > arch/arm/mach-omap2/built-in.o: In function `sr_configure_vp': > /tmp/ranjith/l-o-new/arch/arm/mach-omap2/smartreflex.c:315: undefined > reference to `omap_twl_uv_to_vsel' > /tmp/ranjith/l-o-new/arch/arm/mach-omap2/smartreflex.c:364: undefined > reference to `omap_twl_uv_to_vsel' > arch/arm/mach-omap2/built-in.o: In function `sr_enable': > /tmp/ranjith/l-o-new/arch/arm/mach-omap2/smartreflex.c:609: undefined > reference to `omap_twl_uv_to_vsel' > arch/arm/mach-omap2/built-in.o: In function `sr_reset_voltage': > /tmp/ranjith/l-o-new/arch/arm/mach-omap2/smartreflex.c:478: undefined > reference to `omap_twl_uv_to_vsel' > /tmp/ranjith/l-o-new/arch/arm/mach-omap2/smartreflex.c:496: undefined > reference to `omap_twl_uv_to_vsel' > make: *** [.tmp_vmlinux1] Error 1 > Yes, I saw that too when trying to reproduce your problem. SmartReflex currently has a dependency on SRF where these OPP functions are defined, and this needs to be fixed. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Query][omap iommu] Consulting iommu if a physical region is "mappable" before actually mapping it
Hi Hiroshi, While still maintaining an old camera driver version, which uses your latest iommu driver, we have come up with the following question: Can the iommu driver be "consulted" if a certain area (contiguous or not) can be mapped or not, before even trying to do it? The reason of this is that, in the camera driver case, we want to let the user know if certain capture buffer area (that will be either allocated in kernel or userspace) can be mapped later on without problems, which could help the user don't even try to allocate the buffers, and avoid a trial-and-error kind of cycle. Is that possible with current driver? If not, how complex do you think it'll be to implement that? Regards, Sergio -- 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 suspend to disk?
Cliff Brake writes: > On Thu, Apr 29, 2010 at 1:58 PM, Kevin Hilman > wrote: > >> What do you expect to gain from suspend-to-disk + snapshot boot that >> you don't already get from suspend-to-RAM using off-mode? >> >> On OMAP, with off-mode enabled, a suspend to RAM puts the entire OMAP >> into full-chip off, and essentially reboots the ARM when waking up >> from suspend (or idle) already. > > What does the resume process look like in off mode? Does the resume > pass through the bootloader? If so, are the bits that detects resume > from "off" available in U-boot? No, it does not pass through the boot loader. In general terms, resume from off-mode is the same to "normal" resume (from retention) except that some additional state has to be restored before continuing where you left off since the ARM core (as well as most the OMAP itself) was turned off. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3
"Pandita, Vikram" writes: [...] > --- a/arch/arm/kernel/head.S > +++ b/arch/arm/kernel/head.S > @@ -328,6 +328,16 @@ __create_page_tables: > add r0, r4, #0xd800 >> 18 > str r3, [r0] > #endif > +#if defined(CONFIG_MACH_OMAP_ZOOM2) || >>defined(CONFIG_MACH_OMAP_ZOOM3) > +/* > + * Zoom2 and Zoom3 have UARTs only on the debug board. > + * The debug board is connected to the GPMC. > + */ > +add r0, r4, #0xfa00 >> 18 > +orr r0, r0, #0x0040 >> 18 @ ZOOM_UART_VIRT > +orr r3, r7, #0x1000 @ ZOOM_UART_BASE > +str r3, [r0] > +#endif I don't see why this part is needed. The same mapping is done using the .io_pg_offset in the machine description which is done just before this in head.S >>> >>> That mapping does not cover the GPMC area where this UART is. >> >>Hmm, then shouldn't that be fixed? I understood the .phys_io and and >>.io_pg_offset fields of the mach_desc to be specifically for mapping >>the early UART, and nothing else. > > Here is the problem - with current approach we need two mappings to > happen and the MACHINE_START() code allows for only one via > .io_pg_offset and .phys_io > > Why: > Tony's approach is to pass the information about the debug uart > number from the UART1 Scratchpad register. > > this introduces a dependency that > UART1 registers also be mapped (virt<->phy). > > So for Tony's approach to work, .phys_io/.io_pg_offset continued to > have 0x480 based mapping and for external uart zoom3 port, > create this extra mapping. > > So find a better way from compressed.S to pass the uart number to > kernel, and we can solve the problem. Ah, yet another reason to use a memory location instead of UART1 SCR to pass the UART info (c.f. [1]) Kevin [1] http://marc.info/?l=linux-omap&m=127266219130713&w=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
RE: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3
>-Original Message- >From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >ow...@vger.kernel.org] On Behalf Of Pandita, Vikram >Sent: Friday, April 30, 2010 4:37 PM >To: Kevin Hilman; Tony Lindgren >Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; Pais, >Allen >Subject: RE: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3 > > > >>-Original Message- >>From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >>Sent: Friday, April 30, 2010 4:21 PM >>To: Tony Lindgren >>Cc: linux-arm-ker...@lists.infradead.org; Pandita, Vikram; linux- >>o...@vger.kernel.org; Pais, Allen >>Subject: Re: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3 >> >>Tony Lindgren writes: >> >>> * Kevin Hilman [100430 13:50]: Tony Lindgren writes: > Zoom2 and 3 have UARTs only on the external debug board. > GPMC needs to be mapped early to use it for DEBUG_LL. > > Additionally, 0xfb00 overlaps with other areas, so > use 0xfa40 for the virtual address instead. > > Note that with the pending serial.c patches you need to > set console=ttyS0,115200n8 as it will be the only UART > mapped. To use DEBUG_LL, you need to pass also earlyprintk > in cmdline. > > Cc: Allen Pais > Cc: Vikram Pandita > Signed-off-by: Tony Lindgren > --- > arch/arm/kernel/head.S | 10 ++ > arch/arm/mach-omap2/board-zoom-debugboard.c|2 +- > arch/arm/mach-omap2/include/mach/debug-macro.S |4 ++-- > arch/arm/mach-omap2/io.c |9 + > arch/arm/plat-omap/include/plat/serial.h |2 +- > 5 files changed, 23 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S > index eb62bf9..fd870e1 100644 > --- a/arch/arm/kernel/head.S > +++ b/arch/arm/kernel/head.S > @@ -328,6 +328,16 @@ __create_page_tables: > add r0, r4, #0xd800 >> 18 > str r3, [r0] > #endif > +#if defined(CONFIG_MACH_OMAP_ZOOM2) || >>defined(CONFIG_MACH_OMAP_ZOOM3) > +/* > + * Zoom2 and Zoom3 have UARTs only on the debug board. > + * The debug board is connected to the GPMC. > + */ > +add r0, r4, #0xfa00 >> 18 > +orr r0, r0, #0x0040 >> 18 @ ZOOM_UART_VIRT > +orr r3, r7, #0x1000 @ ZOOM_UART_BASE > +str r3, [r0] > +#endif I don't see why this part is needed. The same mapping is done using the .io_pg_offset in the machine description which is done just before this in head.S >>> >>> That mapping does not cover the GPMC area where this UART is. >> >>Hmm, then shouldn't that be fixed? I understood the .phys_io and and >>.io_pg_offset fields of the mach_desc to be specifically for mapping >>the early UART, and nothing else. > >Here is the problem - >with current approach we need two mappings to happen and the >MACHINE_START() code allows for only one via .io_pg_offset and .phys_io > >Why: >Tony's approach is to pass the information about the debug uart number from >the UART1 Scratchpad register. > >this introduces a dependency that >UART1 registers also be mapped (virt<->phy). > >So for Tony's approach to work, .phys_io/.io_pg_offset continued to have >0x480 based mapping and for external uart zoom3 port, create this extra >mapping. > >So find a better way from compressed.S to pass the uart number to kernel, >and we can solve the problem. Reference to that dependency: Commit: 0c8219f0 +/* + * Store the DEBUG_LL uart number into UART1 scratchpad register. + * See also debug-macro.S, and serial.c for related code. + * + * Please note that we currently assume that: + * - UART1 clocks are enabled for register access + * - UART1 scratchpad register can be used + */ +static void set_uart1_scratchpad(unsigned char port) > >> >>Kevin >> > >-- >To unsubscribe from this list: send the line "unsubscribe linux-omap" in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM suspend to disk?
On Thu, Apr 29, 2010 at 1:58 PM, Kevin Hilman wrote: > What do you expect to gain from suspend-to-disk + snapshot boot that > you don't already get from suspend-to-RAM using off-mode? > > On OMAP, with off-mode enabled, a suspend to RAM puts the entire OMAP > into full-chip off, and essentially reboots the ARM when waking up > from suspend (or idle) already. What does the resume process look like in off mode? Does the resume pass through the bootloader? If so, are the bits that detects resume from "off" available in U-boot? Thanks, Cliff -- 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/11] omap2/3: Fix DEBUG_LL for omap zoom2/3
>-Original Message- >From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >Sent: Friday, April 30, 2010 4:21 PM >To: Tony Lindgren >Cc: linux-arm-ker...@lists.infradead.org; Pandita, Vikram; linux- >o...@vger.kernel.org; Pais, Allen >Subject: Re: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3 > >Tony Lindgren writes: > >> * Kevin Hilman [100430 13:50]: >>> Tony Lindgren writes: >>> >>> > Zoom2 and 3 have UARTs only on the external debug board. >>> > GPMC needs to be mapped early to use it for DEBUG_LL. >>> > >>> > Additionally, 0xfb00 overlaps with other areas, so >>> > use 0xfa40 for the virtual address instead. >>> > >>> > Note that with the pending serial.c patches you need to >>> > set console=ttyS0,115200n8 as it will be the only UART >>> > mapped. To use DEBUG_LL, you need to pass also earlyprintk >>> > in cmdline. >>> > >>> > Cc: Allen Pais >>> > Cc: Vikram Pandita >>> > Signed-off-by: Tony Lindgren >>> > --- >>> > arch/arm/kernel/head.S | 10 ++ >>> > arch/arm/mach-omap2/board-zoom-debugboard.c|2 +- >>> > arch/arm/mach-omap2/include/mach/debug-macro.S |4 ++-- >>> > arch/arm/mach-omap2/io.c |9 + >>> > arch/arm/plat-omap/include/plat/serial.h |2 +- >>> > 5 files changed, 23 insertions(+), 4 deletions(-) >>> > >>> > diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S >>> > index eb62bf9..fd870e1 100644 >>> > --- a/arch/arm/kernel/head.S >>> > +++ b/arch/arm/kernel/head.S >>> > @@ -328,6 +328,16 @@ __create_page_tables: >>> > add r0, r4, #0xd800 >> 18 >>> > str r3, [r0] >>> > #endif >>> > +#if defined(CONFIG_MACH_OMAP_ZOOM2) || >defined(CONFIG_MACH_OMAP_ZOOM3) >>> > + /* >>> > + * Zoom2 and Zoom3 have UARTs only on the debug board. >>> > + * The debug board is connected to the GPMC. >>> > + */ >>> > + add r0, r4, #0xfa00 >> 18 >>> > + orr r0, r0, #0x0040 >> 18 @ ZOOM_UART_VIRT >>> > + orr r3, r7, #0x1000 @ ZOOM_UART_BASE >>> > + str r3, [r0] >>> > +#endif >>> >>> I don't see why this part is needed. The same mapping is done using >>> the .io_pg_offset in the machine description which is done just before >>> this in head.S >> >> That mapping does not cover the GPMC area where this UART is. > >Hmm, then shouldn't that be fixed? I understood the .phys_io and and >.io_pg_offset fields of the mach_desc to be specifically for mapping >the early UART, and nothing else. Here is the problem - with current approach we need two mappings to happen and the MACHINE_START() code allows for only one via .io_pg_offset and .phys_io Why: Tony's approach is to pass the information about the debug uart number from the UART1 Scratchpad register. this introduces a dependency that UART1 registers also be mapped (virt<->phy). So for Tony's approach to work, .phys_io/.io_pg_offset continued to have 0x480 based mapping and for external uart zoom3 port, create this extra mapping. So find a better way from compressed.S to pass the uart number to kernel, and we can solve the problem. > >Kevin > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3
Tony Lindgren writes: > * Kevin Hilman [100430 13:50]: >> Tony Lindgren writes: >> >> > Zoom2 and 3 have UARTs only on the external debug board. >> > GPMC needs to be mapped early to use it for DEBUG_LL. >> > >> > Additionally, 0xfb00 overlaps with other areas, so >> > use 0xfa40 for the virtual address instead. >> > >> > Note that with the pending serial.c patches you need to >> > set console=ttyS0,115200n8 as it will be the only UART >> > mapped. To use DEBUG_LL, you need to pass also earlyprintk >> > in cmdline. >> > >> > Cc: Allen Pais >> > Cc: Vikram Pandita >> > Signed-off-by: Tony Lindgren >> > --- >> > arch/arm/kernel/head.S | 10 ++ >> > arch/arm/mach-omap2/board-zoom-debugboard.c|2 +- >> > arch/arm/mach-omap2/include/mach/debug-macro.S |4 ++-- >> > arch/arm/mach-omap2/io.c |9 + >> > arch/arm/plat-omap/include/plat/serial.h |2 +- >> > 5 files changed, 23 insertions(+), 4 deletions(-) >> > >> > diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S >> > index eb62bf9..fd870e1 100644 >> > --- a/arch/arm/kernel/head.S >> > +++ b/arch/arm/kernel/head.S >> > @@ -328,6 +328,16 @@ __create_page_tables: >> >add r0, r4, #0xd800 >> 18 >> >str r3, [r0] >> > #endif >> > +#if defined(CONFIG_MACH_OMAP_ZOOM2) || defined(CONFIG_MACH_OMAP_ZOOM3) >> > + /* >> > + * Zoom2 and Zoom3 have UARTs only on the debug board. >> > + * The debug board is connected to the GPMC. >> > + */ >> > + add r0, r4, #0xfa00 >> 18 >> > + orr r0, r0, #0x0040 >> 18 @ ZOOM_UART_VIRT >> > + orr r3, r7, #0x1000 @ ZOOM_UART_BASE >> > + str r3, [r0] >> > +#endif >> >> I don't see why this part is needed. The same mapping is done using >> the .io_pg_offset in the machine description which is done just before >> this in head.S > > That mapping does not cover the GPMC area where this UART is. Hmm, then shouldn't that be fixed? I understood the .phys_io and and .io_pg_offset fields of the mach_desc to be specifically for mapping the early UART, and nothing else. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/14] omap: Make uncompress code and DEBUG_LL code generic
Tony Lindgren writes: > * Russell King - ARM Linux [100430 10:13]: >> On Fri, Apr 30, 2010 at 12:20:35PM -0400, Cyril Chemparathy wrote: >> > Hi, >> > >> > [...] >> > > To fix both problems, maybe we should just use a fixed memory location >> > > to pass this temporary data from uncompress to the kernel. We've had a >> > > similar problem on DaVinci recently and a proposal has been made (and >> > > tested) to use memory just below the page tables[3].) >> > >> > Essentially both of these approaches (internal scratch register and >> > fixed address) implement a weird back-channel communication scheme >> > between the decompresser and the debug macros. >> > >> > A more elegant solution may be as follows: >> > - pass machine_arch_type as an argument into addruart. >> >> Unfortunately, that breaks addruart. Firstly, addruart is used from >> assembly code where very limited registers are available (the fewer >> registers it clobbers the less likely debug is going to cause stuff >> to break.) > > Right, this would be tricky. > >> Secondly, the places that addruart may be called from, the location >> of the machine type number is indeterminent. Remember that this >> macro can be called when the MMU is on or off, and can be called >> before the machine_arch_type has been initialized. > > Another good point here. > >> > - move the uart base lookup logic to addruart using macros similar >> > to DEBUG_LL_*, except that these expand to assembly code this >> > time. >> > - reuse these debug-macros in uncompress.h and implement putc() and >> > flush() using addruart(), senduart(), etc. >> >> Given what I've said above about the debug macros, this is definitely the >> wrong solution. >> >> Having the decompressor macros work whatever the machine type is >> reasonable, and the machine_is_xxx() macros already work at that point, >> so there shouldn't be much of an issue there. > > Just to bring it up, there's one issue to consider here though. > When the bootloader passes a wrong machine id, chances are things > break with no debug output. > >> As far as the debug macros go, I think we're at the point where it's >> basically just far easier to leave these macros as a developer debugging >> tool and we'll just have to put up with it being something that an OMAP >> developer has to edit according to his platform to make work. >> >> After all, _NO_ production kernel what so ever should be using this >> debug support. > > Things work now for mach-omap2, but we assume the first uart is always > in the same location. If this changes, then using some fixed memory > location for storing the debug configuration is probably the best way > to go considering the issues Russell mentioned. I agree, using a fixed memory location seems the best way to keep this working across new devices with different UART1 base. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap_musb_board_data -- trouble specifying 500mA supply
On Wed, Apr 28, 2010 at 10:53 AM, Gupta, Ajay Kumar wrote:
> Hi,
>> -Original Message-
>> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>> ow...@vger.kernel.org] On Behalf Of Cliff Brake
>> Sent: Wednesday, April 28, 2010 7:40 PM
>> To: Linux OMAP Users
>> Subject: omap_musb_board_data -- trouble specifying 500mA supply
>>
>> Hello,
>>
>> We are designing a custom OMAP board that will have a 500mA supply on
>> the OTG port. It looks like the power is set with:
>>
>> struct omap_musb_board_data {
>> u8 interface_type;
>> u8 mode;
>> u8 power;
>> };
>>
>> However, with a u8, the max value is 255. Should power be changed to a
>> u16?
>
> There is already a fix submitted and is available at Greg's queue,
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/usb.current/musb-fix-power-field-to-hold-all-possible-values.patch
I'm also having trouble figuring out the correct way to convince the
OTG system not to use the internal phy VBUS power supply. Are there
any examples of a board config that does this? Perhaps the AM35xx,
etc?
Thanks,
Cliff
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader
Vimal Singh wrote:
On Thu, Apr 29, 2010 at 12:23 PM, Mike Rapoport wrote:
Vimal Singh wrote:
On Wed, Apr 28, 2010 at 9:36 PM, Mike Rapoport
wrote:
Signed-off-by: Mike Rapoport
+ if (gpmc_nand_data->keep_timings) {
+ gpmc_nand_detect_timings();
+ gpmc_nand_data->gpmc_t = &gpmc_default_timings;
+ }
+
I guess moving this part to omap2_nand_gpmc_retime will be a good idea.
As there, once we get old/default timings we can simply skip the
rounding part and directly jump to setting the timings.
This way it would be the same as to pass 'gpmc_nand_data->gpmc_t =
NULL'. If I correctly understood the previous comments ([1]), the
problem with skipping retime is that when L3 clock changes, the gpmc
timings became wrong. So, if we convert old/default timings to
nanoseconds early during startup every time retime is called it will use
the timing settings in nanoseconds thus yielding proper gpmc registers
configuration.
OK. Then I think we can at least put __rounding__ code inside an 'if'
case, something like:
if (!gpmc_nand_data->keep_timings) {
...
do rounding for supplied timings from board file.
...
}
Sure, no problem.
And, if I'm not terribly mistaken retime should be called each time L3
frequency changes, though with current kernel it's not yet the case...
Yes. This is still left.
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader
Vimal Singh wrote:
On Wed, Apr 28, 2010 at 9:36 PM, Mike Rapoport wrote:
Signed-off-by: Mike Rapoport
---
arch/arm/mach-omap2/gpmc-nand.c| 19 ++-
arch/arm/plat-omap/include/plat/nand.h |1 +
2 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index e57fb29..7c6c027 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -22,6 +22,7 @@
#define WR_RD_PIN_MONITORING 0x0060
static struct omap_nand_platform_data *gpmc_nand_data;
+static struct gpmc_timings gpmc_default_timings;
static struct resource gpmc_nand_resource = {
.flags = IORESOURCE_MEM,
@@ -34,13 +35,24 @@ static struct platform_device gpmc_nand_device = {
.resource = &gpmc_nand_resource,
};
+static void gpmc_nand_detect_timings(void)
+{
+ struct gpmc_timings t;
+
+ memset(&t, 0, sizeof(t));
+ gpmc_cs_get_timings(gpmc_nand_data->cs, &gpmc_default_timings);
+}
+
static int omap2_nand_gpmc_retime(void)
{
+ struct device *dev = &gpmc_nand_device.dev;
struct gpmc_timings t;
int err;
- if (!gpmc_nand_data->gpmc_t)
+ if (!gpmc_nand_data->gpmc_t) {
+ dev_warn(dev, "No timings provided, skipping retime\n");
return 0;
+ }
memset(&t, 0, sizeof(t));
t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->sync_clk);
@@ -112,6 +124,11 @@ int __init gpmc_nand_init(struct omap_nand_platform_data
*_nand_data)
return err;
}
+ if (gpmc_nand_data->keep_timings) {
+ gpmc_nand_detect_timings();
+ gpmc_nand_data->gpmc_t = &gpmc_default_timings;
+ }
+
I guess moving this part to omap2_nand_gpmc_retime will be a good idea.
As there, once we get old/default timings we can simply skip the
rounding part and directly jump to setting the timings.
This way it would be the same as to pass 'gpmc_nand_data->gpmc_t =
NULL'. If I correctly understood the previous comments ([1]), the
problem with skipping retime is that when L3 clock changes, the gpmc
timings became wrong. So, if we convert old/default timings to
nanoseconds early during startup every time retime is called it will use
the timing settings in nanoseconds thus yielding proper gpmc registers
configuration.
And, if I'm not terribly mistaken retime should be called each time L3
frequency changes, though with current kernel it's not yet the case...
--
[1] http://thread.gmane.org/gmane.linux.ports.arm.omap/34164/focus=34558
Rest looks fine to me.
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] omap: gpmc: add gpmc_cs_get_timings
Add gpmc_cs_get_timings counterpart of gpmc_cs_set_timings and
convinience macros to read particular timing configuration fields
Signed-off-by: Mike Rapoport
---
arch/arm/mach-omap2/gpmc.c | 76
arch/arm/plat-omap/include/plat/gpmc.h |1 +
2 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5bc3ca0..527a0da 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -163,6 +163,36 @@ unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
}
#ifdef DEBUG
+static int get_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
+ const char *name)
+#else
+static int get_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit)
+#endif
+{
+ u32 l;
+ int ticks, mask, nr_bits, time;
+
+ nr_bits = end_bit - st_bit + 1;
+ mask = ((1 << nr_bits) - 1);
+
+ l = gpmc_cs_read_reg(cs, reg);
+ ticks = (l >> st_bit) & mask;
+
+ if (ticks == 0)
+ time = 0;
+ else
+ time = gpmc_ticks_to_ns(ticks);
+
+#ifdef DEBUG
+ printk(KERN_INFO
+ "GPMC CS%d: %-10s: %3d ticks, %3d ns\n",
+ cs, name, ticks, time);
+#endif
+
+ return time;
+}
+
+#ifdef DEBUG
static int set_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
int time, const char *name)
#else
@@ -206,10 +236,14 @@ static int set_gpmc_timing_reg(int cs, int reg, int
st_bit, int end_bit,
if (set_gpmc_timing_reg(cs, (reg), (st), (end), \
t->field, #field) < 0) \
return -1
+#define GPMC_GET_ONE(reg, st, end, field) \
+ t->field = get_gpmc_timing_reg(cs, (reg), (st), (end), #field)
#else
#define GPMC_SET_ONE(reg, st, end, field) \
if (set_gpmc_timing_reg(cs, (reg), (st), (end), t->field) < 0) \
return -1
+#define GPMC_GET_ONE(reg, st, end, field) \
+ t->field = get_gpmc_timing_reg(cs, (reg), (st), (end))
#endif
int gpmc_cs_calc_divider(int cs, unsigned int sync_clk)
@@ -227,6 +261,48 @@ int gpmc_cs_calc_divider(int cs, unsigned int sync_clk)
return div;
}
+void gpmc_cs_get_timings(int cs, struct gpmc_timings *t)
+{
+ int div;
+ u32 l;
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG2, 0, 3, cs_on);
+ GPMC_GET_ONE(GPMC_CS_CONFIG2, 8, 12, cs_rd_off);
+ GPMC_GET_ONE(GPMC_CS_CONFIG2, 16, 20, cs_wr_off);
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG3, 0, 3, adv_on);
+ GPMC_GET_ONE(GPMC_CS_CONFIG3, 8, 12, adv_rd_off);
+ GPMC_GET_ONE(GPMC_CS_CONFIG3, 16, 20, adv_wr_off);
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG4, 0, 3, oe_on);
+ GPMC_GET_ONE(GPMC_CS_CONFIG4, 8, 12, oe_off);
+ GPMC_GET_ONE(GPMC_CS_CONFIG4, 16, 19, we_on);
+ GPMC_GET_ONE(GPMC_CS_CONFIG4, 24, 28, we_off);
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG5, 0, 4, rd_cycle);
+ GPMC_GET_ONE(GPMC_CS_CONFIG5, 8, 12, wr_cycle);
+ GPMC_GET_ONE(GPMC_CS_CONFIG5, 16, 20, access);
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG5, 24, 27, page_burst_access);
+
+ if (cpu_is_omap34xx()) {
+ GPMC_GET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
+ GPMC_GET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
+ }
+
+ l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+ if (l & (GPMC_CONFIG1_READTYPE_SYNC | GPMC_CONFIG1_WRITETYPE_SYNC)) {
+ div = (l & 0x03) + 1;
+#ifdef DEBUG
+ printk(KERN_INFO "GPMC CS%d CLK period is %lu ns (div %d)\n",
+ cs, (div * gpmc_get_fclk_period()) / 1000, div);
+#endif
+ t->sync_clk = (div * gpmc_get_fclk_period()) / 1000;
+ } else {
+ t->sync_clk = 0;
+ }
+}
+
int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
{
int div;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 145838a..5c345f1 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -102,6 +102,7 @@ extern void gpmc_cs_write_reg(int cs, int idx, u32 val);
extern u32 gpmc_cs_read_reg(int cs, int idx);
extern int gpmc_cs_calc_divider(int cs, unsigned int sync_clk);
extern int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t);
+extern void gpmc_cs_get_timings(int cs, struct gpmc_timings *t);
extern int gpmc_cs_request(int cs, unsigned long size, unsigned long *base);
extern void gpmc_cs_free(int cs);
extern int gpmc_cs_set_reserved(int cs, int reserved);
--
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
[PATCH v2 3/3] omap: gpmc-nand: add ability to keep timings defined by the bootloader
Signed-off-by: Mike Rapoport
---
arch/arm/mach-omap2/gpmc-nand.c| 21 +
arch/arm/plat-omap/include/plat/nand.h |1 +
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 9434c80..96f0c7f 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -22,6 +22,7 @@
#define WR_RD_PIN_MONITORING 0x0060
static struct omap_nand_platform_data *gpmc_nand_data;
+static struct gpmc_timings gpmc_default_timings;
static struct resource gpmc_nand_resource = {
.flags = IORESOURCE_MEM,
@@ -65,21 +66,28 @@ static void omap2_nand_gpmc_round_timings(struct
gpmc_timings *src,
static int omap2_nand_gpmc_retime(void)
{
+ struct device *dev = &gpmc_nand_device.dev;
+ struct gpmc_timings *gpmc_t = gpmc_nand_data->gpmc_t;
struct gpmc_timings t;
int err;
- if (!gpmc_nand_data->gpmc_t)
+ if (!gpmc_t) {
+ dev_warn(dev, "No timings provided, skipping retime\n");
return 0;
+ }
- memset(&t, 0, sizeof(t));
- omap2_nand_gpmc_round_timings(gpmc_nand_data->gpmc_t, &t);
+ if (!gpmc_nand_data->keep_timings) {
+ memset(&t, 0, sizeof(t));
+ omap2_nand_gpmc_round_timings(gpmc_nand_data->gpmc_t, &t);
+ gpmc_t = &t;
+ }
/* Configure GPMC */
gpmc_cs_write_reg(gpmc_nand_data->cs, GPMC_CS_CONFIG1,
GPMC_CONFIG1_DEVICESIZE(gpmc_nand_data->devsize) |
GPMC_CONFIG1_DEVICETYPE_NAND);
- err = gpmc_cs_set_timings(gpmc_nand_data->cs, &t);
+ err = gpmc_cs_set_timings(gpmc_nand_data->cs, gpmc_t);
if (err)
return err;
@@ -116,6 +124,11 @@ int __init gpmc_nand_init(struct omap_nand_platform_data
*_nand_data)
return err;
}
+ if (gpmc_nand_data->keep_timings) {
+ gpmc_cs_get_timings(gpmc_nand_data->cs, &gpmc_default_timings);
+ gpmc_nand_data->gpmc_t = &gpmc_default_timings;
+ }
+
err = gpmc_nand_setup();
if (err < 0) {
dev_err(dev, "NAND platform setup failed: %d\n", err);
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index f8efd54..0f727ea 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -24,6 +24,7 @@ struct omap_nand_platform_data {
void __iomem*gpmc_cs_baseaddr;
void __iomem*gpmc_baseaddr;
int devsize;
+ boolkeep_timings;
};
/* size (4 KiB) for IO mapping */
--
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
[PATCH v2 0/3] omap: gpmc-nand: add ability to keep timings defined by the bootloader
These patches add ability to keep GPMC timings configured by the bootloader. The platforms have to either define NAND GPMC timinings explicitly via gpmc_t field of omap_nand_platform_data or set keep_timings flag to allow detection of current timing configuration and its subsequent use in omap2_nand_gpmc_retime. v2 changes: - remove debug leftovers - make timing rounding depend on .keep_timing flag and introduce omap2_nand_gpmc_round_timings to facilitate this change Mike Rapoport (3): omap: gpmc: add gpmc_cs_get_timings omap: gpmc-nand: introduce omap2_nand_gpmc_round_timings helper omap: gpmc-nand: add ability to keep timings defined by the bootloader arch/arm/mach-omap2/gpmc-nand.c| 73 +++ arch/arm/mach-omap2/gpmc.c | 76 arch/arm/plat-omap/include/plat/gpmc.h |1 + arch/arm/plat-omap/include/plat/nand.h |1 + 4 files changed, 123 insertions(+), 28 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] omap: gpmc-nand: introduce omap2_nand_gpmc_round_timings helper
Signed-off-by: Mike Rapoport
---
arch/arm/mach-omap2/gpmc-nand.c | 56 +--
1 files changed, 30 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index e57fb29..9434c80 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -34,6 +34,35 @@ static struct platform_device gpmc_nand_device = {
.resource = &gpmc_nand_resource,
};
+static void omap2_nand_gpmc_round_timings(struct gpmc_timings *src,
+ struct gpmc_timings *dst)
+{
+ dst->sync_clk = gpmc_round_ns_to_ticks(src->sync_clk);
+ dst->cs_on = gpmc_round_ns_to_ticks(src->cs_on);
+ dst->adv_on = gpmc_round_ns_to_ticks(src->adv_on);
+
+ /* Read */
+ dst->adv_rd_off = gpmc_round_ns_to_ticks(src->adv_rd_off);
+ dst->oe_on = dst->adv_on;
+ dst->access = gpmc_round_ns_to_ticks(src->access);
+ dst->oe_off = gpmc_round_ns_to_ticks(src->oe_off);
+ dst->cs_rd_off = gpmc_round_ns_to_ticks(src->cs_rd_off);
+ dst->rd_cycle = gpmc_round_ns_to_ticks(src->rd_cycle);
+
+ /* Write */
+ dst->adv_wr_off = gpmc_round_ns_to_ticks(src->adv_wr_off);
+ dst->we_on = dst->oe_on;
+ if (cpu_is_omap34xx()) {
+ dst->wr_data_mux_bus = gpmc_round_ns_to_ticks(
+ src->wr_data_mux_bus);
+ dst->wr_access = gpmc_round_ns_to_ticks(
+ src->wr_access);
+ }
+ dst->we_off = gpmc_round_ns_to_ticks(src->we_off);
+ dst->cs_wr_off = gpmc_round_ns_to_ticks(src->cs_wr_off);
+ dst->wr_cycle = gpmc_round_ns_to_ticks(src->wr_cycle);
+}
+
static int omap2_nand_gpmc_retime(void)
{
struct gpmc_timings t;
@@ -43,32 +72,7 @@ static int omap2_nand_gpmc_retime(void)
return 0;
memset(&t, 0, sizeof(t));
- t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->sync_clk);
- t.cs_on = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->cs_on);
- t.adv_on = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->adv_on);
-
- /* Read */
- t.adv_rd_off = gpmc_round_ns_to_ticks(
- gpmc_nand_data->gpmc_t->adv_rd_off);
- t.oe_on = t.adv_on;
- t.access = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->access);
- t.oe_off = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->oe_off);
- t.cs_rd_off = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->cs_rd_off);
- t.rd_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->rd_cycle);
-
- /* Write */
- t.adv_wr_off = gpmc_round_ns_to_ticks(
- gpmc_nand_data->gpmc_t->adv_wr_off);
- t.we_on = t.oe_on;
- if (cpu_is_omap34xx()) {
- t.wr_data_mux_bus = gpmc_round_ns_to_ticks(
- gpmc_nand_data->gpmc_t->wr_data_mux_bus);
- t.wr_access = gpmc_round_ns_to_ticks(
- gpmc_nand_data->gpmc_t->wr_access);
- }
- t.we_off = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->we_off);
- t.cs_wr_off = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->cs_wr_off);
- t.wr_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->wr_cycle);
+ omap2_nand_gpmc_round_timings(gpmc_nand_data->gpmc_t, &t);
/* Configure GPMC */
gpmc_cs_write_reg(gpmc_nand_data->cs, GPMC_CS_CONFIG1,
--
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
Re: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3
* Kevin Hilman [100430 13:50]: > Tony Lindgren writes: > > > Zoom2 and 3 have UARTs only on the external debug board. > > GPMC needs to be mapped early to use it for DEBUG_LL. > > > > Additionally, 0xfb00 overlaps with other areas, so > > use 0xfa40 for the virtual address instead. > > > > Note that with the pending serial.c patches you need to > > set console=ttyS0,115200n8 as it will be the only UART > > mapped. To use DEBUG_LL, you need to pass also earlyprintk > > in cmdline. > > > > Cc: Allen Pais > > Cc: Vikram Pandita > > Signed-off-by: Tony Lindgren > > --- > > arch/arm/kernel/head.S | 10 ++ > > arch/arm/mach-omap2/board-zoom-debugboard.c|2 +- > > arch/arm/mach-omap2/include/mach/debug-macro.S |4 ++-- > > arch/arm/mach-omap2/io.c |9 + > > arch/arm/plat-omap/include/plat/serial.h |2 +- > > 5 files changed, 23 insertions(+), 4 deletions(-) > > > > diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S > > index eb62bf9..fd870e1 100644 > > --- a/arch/arm/kernel/head.S > > +++ b/arch/arm/kernel/head.S > > @@ -328,6 +328,16 @@ __create_page_tables: > > add r0, r4, #0xd800 >> 18 > > str r3, [r0] > > #endif > > +#if defined(CONFIG_MACH_OMAP_ZOOM2) || defined(CONFIG_MACH_OMAP_ZOOM3) > > + /* > > +* Zoom2 and Zoom3 have UARTs only on the debug board. > > +* The debug board is connected to the GPMC. > > +*/ > > + add r0, r4, #0xfa00 >> 18 > > + orr r0, r0, #0x0040 >> 18 @ ZOOM_UART_VIRT > > + orr r3, r7, #0x1000 @ ZOOM_UART_BASE > > + str r3, [r0] > > +#endif > > I don't see why this part is needed. The same mapping is done using > the .io_pg_offset in the machine description which is done just before > this in head.S That mapping does not cover the GPMC area where this UART is. 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 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3
Tony Lindgren writes: > Zoom2 and 3 have UARTs only on the external debug board. > GPMC needs to be mapped early to use it for DEBUG_LL. > > Additionally, 0xfb00 overlaps with other areas, so > use 0xfa40 for the virtual address instead. > > Note that with the pending serial.c patches you need to > set console=ttyS0,115200n8 as it will be the only UART > mapped. To use DEBUG_LL, you need to pass also earlyprintk > in cmdline. > > Cc: Allen Pais > Cc: Vikram Pandita > Signed-off-by: Tony Lindgren > --- > arch/arm/kernel/head.S | 10 ++ > arch/arm/mach-omap2/board-zoom-debugboard.c|2 +- > arch/arm/mach-omap2/include/mach/debug-macro.S |4 ++-- > arch/arm/mach-omap2/io.c |9 + > arch/arm/plat-omap/include/plat/serial.h |2 +- > 5 files changed, 23 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S > index eb62bf9..fd870e1 100644 > --- a/arch/arm/kernel/head.S > +++ b/arch/arm/kernel/head.S > @@ -328,6 +328,16 @@ __create_page_tables: > add r0, r4, #0xd800 >> 18 > str r3, [r0] > #endif > +#if defined(CONFIG_MACH_OMAP_ZOOM2) || defined(CONFIG_MACH_OMAP_ZOOM3) > + /* > + * Zoom2 and Zoom3 have UARTs only on the debug board. > + * The debug board is connected to the GPMC. > + */ > + add r0, r4, #0xfa00 >> 18 > + orr r0, r0, #0x0040 >> 18 @ ZOOM_UART_VIRT > + orr r3, r7, #0x1000 @ ZOOM_UART_BASE > + str r3, [r0] > +#endif I don't see why this part is needed. The same mapping is done using the .io_pg_offset in the machine description which is done just before this in head.S Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in omap3_defconfig
* Tony Lindgren [100430 13:32]: > Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC > at least on zoom3 for multi-omap. Disable CONFIG_FB until the > omap FB code is fixed. This one I'll drop as soon as the problem is sorted out with CONFIG_FB_OMAP. 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 2/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader
On Wed, Apr 28, 2010 at 9:36 PM, Mike Rapoport wrote:
> Signed-off-by: Mike Rapoport
> ---
> arch/arm/mach-omap2/gpmc-nand.c | 19 ++-
> arch/arm/plat-omap/include/plat/nand.h | 1 +
> 2 files changed, 19 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
> index e57fb29..7c6c027 100644
> --- a/arch/arm/mach-omap2/gpmc-nand.c
> +++ b/arch/arm/mach-omap2/gpmc-nand.c
> @@ -22,6 +22,7 @@
> #define WR_RD_PIN_MONITORING 0x0060
>
> static struct omap_nand_platform_data *gpmc_nand_data;
> +static struct gpmc_timings gpmc_default_timings;
>
> static struct resource gpmc_nand_resource = {
> .flags = IORESOURCE_MEM,
> @@ -34,13 +35,24 @@ static struct platform_device gpmc_nand_device = {
> .resource = &gpmc_nand_resource,
> };
>
> +static void gpmc_nand_detect_timings(void)
> +{
> + struct gpmc_timings t;
> +
> + memset(&t, 0, sizeof(t));
> + gpmc_cs_get_timings(gpmc_nand_data->cs, &gpmc_default_timings);
> +}
> +
> static int omap2_nand_gpmc_retime(void)
> {
> + struct device *dev = &gpmc_nand_device.dev;
> struct gpmc_timings t;
> int err;
>
> - if (!gpmc_nand_data->gpmc_t)
> + if (!gpmc_nand_data->gpmc_t) {
> + dev_warn(dev, "No timings provided, skipping retime\n");
> return 0;
> + }
>
> memset(&t, 0, sizeof(t));
> t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->sync_clk);
> @@ -112,6 +124,11 @@ int __init gpmc_nand_init(struct omap_nand_platform_data
> *_nand_data)
> return err;
> }
>
> + if (gpmc_nand_data->keep_timings) {
> + gpmc_nand_detect_timings();
> + gpmc_nand_data->gpmc_t = &gpmc_default_timings;
> + }
> +
I guess moving this part to omap2_nand_gpmc_retime will be a good idea.
As there, once we get old/default timings we can simply skip the
rounding part and directly jump to setting the timings.
Rest looks fine to me.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/11] omap2/3/4: Dissable CONFIG_PM_VERBOSE in omap3_defconfig
It's too noisy. Signed-off-by: Tony Lindgren --- arch/arm/configs/omap3_defconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/omap3_defconfig b/arch/arm/configs/omap3_defconfig index a846836..7855edb 100644 --- a/arch/arm/configs/omap3_defconfig +++ b/arch/arm/configs/omap3_defconfig @@ -444,7 +444,7 @@ CONFIG_BINFMT_MISC=y # CONFIG_PM=y CONFIG_PM_DEBUG=y -CONFIG_PM_VERBOSE=y +# CONFIG_PM_VERBOSE is not set CONFIG_CAN_PM_TRACE=y CONFIG_PM_SLEEP=y CONFIG_SUSPEND=y -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in omap3_defconfig
Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC at least on zoom3 for multi-omap. Disable CONFIG_FB until the omap FB code is fixed. This allows booting omap3_defconfig on various omaps. Tested on 2420-n8x0, 3430-n900, 3630-zoom3 and 4430-blaze. Note that n8x0 still has issues with starting user space because of TLS and VFP. Signed-off-by: Tony Lindgren --- arch/arm/configs/omap3_defconfig | 10 +- 1 files changed, 1 insertions(+), 9 deletions(-) diff --git a/arch/arm/configs/omap3_defconfig b/arch/arm/configs/omap3_defconfig index 7855edb..1efb833 100644 --- a/arch/arm/configs/omap3_defconfig +++ b/arch/arm/configs/omap3_defconfig @@ -1359,16 +1359,8 @@ CONFIG_FB_TILEBLITTING=y # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set # CONFIG_FB_BROADSHEET is not set -CONFIG_FB_OMAP=y +# CONFIG_FB_OMAP is not set CONFIG_FB_OMAP_LCD_VGA=y -# CONFIG_FB_OMAP_031M3R is not set -# CONFIG_FB_OMAP_048M3R is not set -CONFIG_FB_OMAP_079M3R=y -# CONFIG_FB_OMAP_092M9R is not set -# CONFIG_FB_OMAP_LCDC_EXTERNAL is not set -# CONFIG_FB_OMAP_LCD_MIPID is not set -# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set -CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2 # CONFIG_OMAP2_DSS is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=y -- 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 08/11] omap2/3/4: Make omap3_defconfig usable on Nokia boards
The bootloader on Nokia boards does not support updating the kernel cmdline. For the other boards, the bootloader provided cmdline will be used instead. To mount root on n8x0, compile in also the MMC_OMAP. It seems that the best way to mount root with the new kernels on Nokia boards is to mount root on mmcblk0p2. Note that n8x0 current has several issues booting with omap3_defconfig: The bootloader has a 2MB limit for loading kernels, so you may want to use kexec. Also ARMv6 does not currently work with ARMv7 for VFP and TLS. Signed-off-by: Tony Lindgren --- arch/arm/configs/omap3_defconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/configs/omap3_defconfig b/arch/arm/configs/omap3_defconfig index 01e5986..d2ab492 100644 --- a/arch/arm/configs/omap3_defconfig +++ b/arch/arm/configs/omap3_defconfig @@ -391,7 +391,7 @@ CONFIG_ALIGNMENT_TRAP=y # CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 -CONFIG_CMDLINE="root=/dev/nfs nfsroot=192.168.0.1:/home/user/buildroot ip=192.168.0.2:192.168.0.1:192.168.0.1:255.255.255.0:tgt:eth0:off rw console=ttyS2,115200n8" +CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyS2,115200" # CONFIG_XIP_KERNEL is not set CONFIG_KEXEC=y CONFIG_ATAGS_PROC=y @@ -1687,7 +1687,7 @@ CONFIG_SDIO_UART=y # MMC/SD/SDIO Host Controller Drivers # # CONFIG_MMC_SDHCI is not set -# CONFIG_MMC_OMAP is not set +CONFIG_MMC_OMAP=y CONFIG_MMC_OMAP_HS=y # CONFIG_MMC_AT91 is not set # CONFIG_MMC_ATMELMCI is not set -- 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 09/11] omap2/3/4: Update PMIC options for TWL and Menelaus chips
These are needed for mounting root on MMC on many boards. Also disable CONFIG_WATCHDOG_NOWAYOUT, that can keep the system from running with external watchdogs. Signed-off-by: Tony Lindgren --- arch/arm/configs/omap3_defconfig | 13 +++-- 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/arch/arm/configs/omap3_defconfig b/arch/arm/configs/omap3_defconfig index d2ab492..a846836 100644 --- a/arch/arm/configs/omap3_defconfig +++ b/arch/arm/configs/omap3_defconfig @@ -1263,7 +1263,7 @@ CONFIG_HWMON=y # CONFIG_SENSORS_LIS3_I2C is not set # CONFIG_THERMAL is not set CONFIG_WATCHDOG=y -CONFIG_WATCHDOG_NOWAYOUT=y +# CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers @@ -1292,9 +1292,9 @@ CONFIG_MFD_CORE=y # CONFIG_HTC_EGPIO is not set # CONFIG_HTC_PASIC3 is not set # CONFIG_TPS65010 is not set -# CONFIG_MENELAUS is not set +CONFIG_MENELAUS=y CONFIG_TWL4030_CORE=y -# CONFIG_TWL4030_POWER is not set +CONFIG_TWL4030_POWER=y CONFIG_TWL4030_CODEC=y # CONFIG_MFD_TMIO is not set # CONFIG_MFD_T7L66XB is not set @@ -1313,7 +1313,7 @@ CONFIG_TWL4030_CODEC=y # CONFIG_AB4500_CORE is not set CONFIG_REGULATOR=y # CONFIG_REGULATOR_DEBUG is not set -CONFIG_REGULATOR_FIXED_VOLTAGE=y +# CONFIG_REGULATOR_FIXED_VOLTAGE is not set # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REGULATOR_USERSPACE_CONSUMER is not set # CONFIG_REGULATOR_BQ24022 is not set @@ -1321,8 +1321,8 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y # CONFIG_REGULATOR_MAX8660 is not set CONFIG_REGULATOR_TWL4030=y # CONFIG_REGULATOR_LP3971 is not set -# CONFIG_REGULATOR_TPS65023 is not set -# CONFIG_REGULATOR_TPS6507X is not set +CONFIG_REGULATOR_TPS65023=y +CONFIG_REGULATOR_TPS6507X=y # CONFIG_MEDIA_SUPPORT is not set # @@ -1752,6 +1752,7 @@ CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_DRV_PCF8583 is not set # CONFIG_RTC_DRV_M41T80 is not set # CONFIG_RTC_DRV_BQ32K is not set +CONFIG_RTC_DRV_TWL92330=y CONFIG_RTC_DRV_TWL4030=y # CONFIG_RTC_DRV_S35390A is not set # CONFIG_RTC_DRV_FM3130 is not set -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/11] omap4: Fix omap_l2_cache_init not to run for other omaps
In multi-omap configuration all the initcalls run. To avoid bad things from happening with 44xx specific initcalls on other omaps, we need to check that the booted system is omap4 before running. Signed-off-by: Tony Lindgren --- arch/arm/mach-omap2/board-4430sdp.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index b88f28c..e603b00 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -55,6 +55,9 @@ static int __init omap_l2_cache_init(void) extern void omap_smc1(u32 fn, u32 arg); void __iomem *l2cache_base; + if (!cpu_is_omap44xx()) + return -ENODEV; + /* To avoid code running on other OMAPs in * multi-omap builds */ -- 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 07/11] omap2/3/4: Add new boards to omap3_defconfig
Enable 2430 omaps and the missing boards. Signed-off-by: Tony Lindgren --- arch/arm/configs/omap3_defconfig |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/configs/omap3_defconfig b/arch/arm/configs/omap3_defconfig index d6ad921..01e5986 100644 --- a/arch/arm/configs/omap3_defconfig +++ b/arch/arm/configs/omap3_defconfig @@ -264,7 +264,7 @@ CONFIG_MACH_OMAP_GENERIC=y # OMAP Core Type # CONFIG_ARCH_OMAP2420=y -# CONFIG_ARCH_OMAP2430 is not set +CONFIG_ARCH_OMAP2430=y CONFIG_ARCH_OMAP3430=y CONFIG_OMAP_PACKAGE_CBB=y CONFIG_OMAP_PACKAGE_CUS=y @@ -276,8 +276,9 @@ CONFIG_OMAP_PACKAGE_CBP=y CONFIG_MACH_OMAP2_TUSB6010=y CONFIG_MACH_OMAP_H4=y CONFIG_MACH_OMAP_APOLLON=y -# CONFIG_MACH_OMAP_2430SDP is not set +CONFIG_MACH_OMAP_2430SDP=y CONFIG_MACH_OMAP3_BEAGLE=y +CONFIG_MACH_DEVKIT8000=y CONFIG_MACH_OMAP_LDP=y CONFIG_MACH_OVERO=y CONFIG_MACH_OMAP3EVM=y -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/11] omap4: Fix multiboot with CONFIG_PM and CONFIG_ARCH_OMAP3 selected
We cannot use the omap34xx_sram_init(). It needs to be implemented
for omap4. Otherwise we get an error and the system won't boot:
Unhandled fault: imprecise external abort (0x1406) at 0xea963e94
...
Fix this by adding a dummy omap44xx_sram_init().
Signed-off-by: Tony Lindgren
---
arch/arm/plat-omap/sram.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 51f4dfb..226b2e8 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -437,6 +437,20 @@ static inline int omap34xx_sram_init(void)
}
#endif
+#ifdef CONFIG_ARCH_OMAP4
+int __init omap44xx_sram_init(void)
+{
+ printk(KERN_ERR "FIXME: %s not implemented\n", __func__);
+
+ return -ENODEV;
+}
+#else
+static inline int omap44xx_sram_init(void)
+{
+ return 0;
+}
+#endif
+
int __init omap_sram_init(void)
{
omap_detect_sram();
@@ -451,7 +465,7 @@ int __init omap_sram_init(void)
else if (cpu_is_omap34xx())
omap34xx_sram_init();
else if (cpu_is_omap44xx())
- omap34xx_sram_init(); /* FIXME: */
+ omap44xx_sram_init();
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/11] omap3: Remove non-muxable ball entries for 3630
These are currently non-muxable, so let's save some memory
and remove them. Otherwise we get the following warnings:
mux: Unknown ball offset 0x5e
mux: Unknown ball offset 0x60
mux: Unknown ball offset 0x62
...
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/mux34xx.c | 86 -
1 files changed, 0 insertions(+), 86 deletions(-)
diff --git a/arch/arm/mach-omap2/mux34xx.c b/arch/arm/mach-omap2/mux34xx.c
index 07aa7b3..2ff4dce 100644
--- a/arch/arm/mach-omap2/mux34xx.c
+++ b/arch/arm/mach-omap2/mux34xx.c
@@ -1901,26 +1901,15 @@ struct omap_ball __initdata omap36xx_cbp_ball[] = {
_OMAP3_BALLENTRY(GPMC_A8, "m3", "ab18"),
_OMAP3_BALLENTRY(GPMC_A9, "l3", "ac19"),
_OMAP3_BALLENTRY(GPMC_CLK, "t4", "w2"),
- _OMAP3_BALLENTRY(GPMC_D0, "k1", "m2"),
- _OMAP3_BALLENTRY(GPMC_D1, "l1", "m1"),
_OMAP3_BALLENTRY(GPMC_D10, "p1", "ab4"),
_OMAP3_BALLENTRY(GPMC_D11, "r1", "ac4"),
_OMAP3_BALLENTRY(GPMC_D12, "r2", "ab6"),
_OMAP3_BALLENTRY(GPMC_D13, "t2", "ac6"),
_OMAP3_BALLENTRY(GPMC_D14, "w1", "ab7"),
_OMAP3_BALLENTRY(GPMC_D15, "y1", "ac7"),
- _OMAP3_BALLENTRY(GPMC_D2, "l2", "n2"),
- _OMAP3_BALLENTRY(GPMC_D3, "p2", "n1"),
- _OMAP3_BALLENTRY(GPMC_D4, "t1", "r2"),
- _OMAP3_BALLENTRY(GPMC_D5, "v1", "r1"),
- _OMAP3_BALLENTRY(GPMC_D6, "v2", "t2"),
- _OMAP3_BALLENTRY(GPMC_D7, "w2", "t1"),
- _OMAP3_BALLENTRY(GPMC_D8, "h2", "ab3"),
_OMAP3_BALLENTRY(GPMC_D9, "k2", "ac3"),
- _OMAP3_BALLENTRY(GPMC_NADV_ALE, "f3", "w1"),
_OMAP3_BALLENTRY(GPMC_NBE0_CLE, "g3", "ac12"),
_OMAP3_BALLENTRY(GPMC_NBE1, "u3", NULL),
- _OMAP3_BALLENTRY(GPMC_NCS0, "g4", "y2"),
_OMAP3_BALLENTRY(GPMC_NCS1, "h3", "y1"),
_OMAP3_BALLENTRY(GPMC_NCS2, "v8", NULL),
_OMAP3_BALLENTRY(GPMC_NCS3, "u8", NULL),
@@ -1928,10 +1917,7 @@ struct omap_ball __initdata omap36xx_cbp_ball[] = {
_OMAP3_BALLENTRY(GPMC_NCS5, "r8", NULL),
_OMAP3_BALLENTRY(GPMC_NCS6, "p8", NULL),
_OMAP3_BALLENTRY(GPMC_NCS7, "n8", NULL),
- _OMAP3_BALLENTRY(GPMC_NOE, "g2", "v2"),
- _OMAP3_BALLENTRY(GPMC_NWE, "f4", "v1"),
_OMAP3_BALLENTRY(GPMC_NWP, "h1", "ab10"),
- _OMAP3_BALLENTRY(GPMC_WAIT0, "m8", "ab12"),
_OMAP3_BALLENTRY(GPMC_WAIT1, "l8", "ac10"),
_OMAP3_BALLENTRY(GPMC_WAIT2, "k8", NULL),
_OMAP3_BALLENTRY(GPMC_WAIT3, "j8", NULL),
@@ -1948,8 +1934,6 @@ struct omap_ball __initdata omap36xx_cbp_ball[] = {
_OMAP3_BALLENTRY(HSUSB0_DIR, "r28", NULL),
_OMAP3_BALLENTRY(HSUSB0_NXT, "t26", NULL),
_OMAP3_BALLENTRY(HSUSB0_STP, "t25", NULL),
- _OMAP3_BALLENTRY(I2C1_SCL, "k21", NULL),
- _OMAP3_BALLENTRY(I2C1_SDA, "j21", NULL),
_OMAP3_BALLENTRY(I2C2_SCL, "af15", NULL),
_OMAP3_BALLENTRY(I2C2_SDA, "ae15", NULL),
_OMAP3_BALLENTRY(I2C3_SCL, "af14", NULL),
@@ -1958,11 +1942,6 @@ struct omap_ball __initdata omap36xx_cbp_ball[] = {
_OMAP3_BALLENTRY(I2C4_SDA, "ae26", NULL),
_OMAP3_BALLENTRY(JTAG_EMU0, "aa11", NULL),
_OMAP3_BALLENTRY(JTAG_EMU1, "aa10", NULL),
- _OMAP3_BALLENTRY(JTAG_RTCK, "aa12", NULL),
- _OMAP3_BALLENTRY(JTAG_TCK, "aa13", NULL),
- _OMAP3_BALLENTRY(JTAG_TDI, "aa20", NULL),
- _OMAP3_BALLENTRY(JTAG_TDO, "aa19", NULL),
- _OMAP3_BALLENTRY(JTAG_TMS_TMSC, "aa18", NULL),
_OMAP3_BALLENTRY(MCBSP1_CLKR, "y21", NULL),
_OMAP3_BALLENTRY(MCBSP1_CLKX, "w21", NULL),
_OMAP3_BALLENTRY(MCBSP1_DR, "u21", NULL),
@@ -2010,77 +1989,12 @@ struct omap_ball __initdata omap36xx_cbp_ball[] = {
_OMAP3_BALLENTRY(SDMMC2_DAT5, "ah3", NULL),
_OMAP3_BALLENTRY(SDMMC2_DAT6, "af3", NULL),
_OMAP3_BALLENTRY(SDMMC2_DAT7, "ae3", NULL),
- _OMAP3_BALLENTRY(SDRC_A0, NULL, "n22"),
- _OMAP3_BALLENTRY(SDRC_A1, NULL, "n23"),
- _OMAP3_BALLENTRY(SDRC_A10, NULL, "v22"),
- _OMAP3_BALLENTRY(SDRC_A11, NULL, "v23"),
- _OMAP3_BALLENTRY(SDRC_A12, NULL, "w22"),
- _OMAP3_BALLENTRY(SDRC_A13, NULL, "w23"),
- _OMAP3_BALLENTRY(SDRC_A14, NULL, "y22"),
- _OMAP3_BALLENTRY(SDRC_A2, NULL, "p22"),
- _OMAP3_BALLENTRY(SDRC_A3, NULL, "p23"),
- _OMAP3_BALLENTRY(SDRC_A4, NULL, "r22"),
- _OMAP3_BALLENTRY(SDRC_A5, NULL, "r23"),
- _OMAP3_BALLENTRY(SDRC_A6, NULL, "t22"),
- _OMAP3_BALLENTRY(SDRC_A7, NULL, "t23"),
- _OMAP3_BALLENTRY(SDRC_A8, NULL, "u22"),
- _OMAP3_BALLENTRY(SDRC_A9, NULL, "u23"),
- _OMAP3_BALLENTRY(SDRC_BA0, "h9", "ab21"),
- _OMAP3_BALLENTRY(SDRC_BA1, "h10", "ac21"),
_OMAP3_BALLENTRY(SDRC_CKE0, "h16", "j22"),
_OMAP3_BALLENTRY(SDRC_CKE1, "h17", "j23"),
- _OMAP3_BALLENTRY(SDRC_CLK, "a13", "a11"),
- _OMAP3_BALLENTRY(SDRC_D0, NULL, "j2"),
- _OMAP3_BALLENTRY(SDRC_D1, NULL, "j1"),
- _OMAP3_BALLENTRY(SDRC_D10, "c15", "b14"),
- _OMAP3_BALLENTRY(SDRC_D11, "b16", "a14"),
- _OMAP
[PATCH 03/11] omap3: Fix compile for board-cm-t35
Otherwise we can get the following error: error: variable 'tdo24m_mcspi_config' has initializer but incomplete type ... Signed-off-by: Tony Lindgren --- arch/arm/mach-omap2/board-cm-t35.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c index 2de4f79..e679a2c 100644 --- a/arch/arm/mach-omap2/board-cm-t35.c +++ b/arch/arm/mach-omap2/board-cm-t35.c @@ -45,6 +45,7 @@ #include #include #include +#include #include -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3
Zoom2 and 3 have UARTs only on the external debug board.
GPMC needs to be mapped early to use it for DEBUG_LL.
Additionally, 0xfb00 overlaps with other areas, so
use 0xfa40 for the virtual address instead.
Note that with the pending serial.c patches you need to
set console=ttyS0,115200n8 as it will be the only UART
mapped. To use DEBUG_LL, you need to pass also earlyprintk
in cmdline.
Cc: Allen Pais
Cc: Vikram Pandita
Signed-off-by: Tony Lindgren
---
arch/arm/kernel/head.S | 10 ++
arch/arm/mach-omap2/board-zoom-debugboard.c|2 +-
arch/arm/mach-omap2/include/mach/debug-macro.S |4 ++--
arch/arm/mach-omap2/io.c |9 +
arch/arm/plat-omap/include/plat/serial.h |2 +-
5 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index eb62bf9..fd870e1 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -328,6 +328,16 @@ __create_page_tables:
add r0, r4, #0xd800 >> 18
str r3, [r0]
#endif
+#if defined(CONFIG_MACH_OMAP_ZOOM2) || defined(CONFIG_MACH_OMAP_ZOOM3)
+ /*
+* Zoom2 and Zoom3 have UARTs only on the debug board.
+* The debug board is connected to the GPMC.
+*/
+ add r0, r4, #0xfa00 >> 18
+ orr r0, r0, #0x0040 >> 18 @ ZOOM_UART_VIRT
+ orr r3, r7, #0x1000 @ ZOOM_UART_BASE
+ str r3, [r0]
+#endif
#endif
mov pc, lr
ENDPROC(__create_page_tables)
diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c
b/arch/arm/mach-omap2/board-zoom-debugboard.c
index e15d2e8..1d7f827 100644
--- a/arch/arm/mach-omap2/board-zoom-debugboard.c
+++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
@@ -82,7 +82,7 @@ static inline void __init zoom_init_smsc911x(void)
static struct plat_serial8250_port serial_platform_data[] = {
{
- .mapbase= 0x1000,
+ .mapbase= ZOOM_UART_BASE,
.irq= OMAP_GPIO_IRQ(102),
.flags = UPF_BOOT_AUTOCONF|UPF_IOREMAP|UPF_SHARE_IRQ,
.irqflags = IRQF_SHARED | IRQF_TRIGGER_RISING,
diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S
b/arch/arm/mach-omap2/include/mach/debug-macro.S
index 4a63a2e..231ea27 100644
--- a/arch/arm/mach-omap2/include/mach/debug-macro.S
+++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
@@ -87,10 +87,10 @@ omap_uart_lsr: .word 0
b 98f
44:mov \rx, #UART_OFFSET(OMAP4_UART4_BASE)
b 98f
-95:mov \rx, #ZOOM_UART_BASE
+95:ldr \rx, =ZOOM_UART_BASE
ldr \tmp, =omap_uart_phys
str \rx, [\tmp, #0]
- mov \rx, #ZOOM_UART_VIRT
+ ldr \rx, =ZOOM_UART_VIRT
ldr \tmp, =omap_uart_virt
str \rx, [\tmp, #0]
mov \rx, #(UART_LSR << ZOOM_PORT_SHIFT)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 87f676a..3cfb425 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -166,6 +166,15 @@ static struct map_desc omap34xx_io_desc[] __initdata = {
.length = L4_EMU_34XX_SIZE,
.type = MT_DEVICE
},
+#if defined(CONFIG_DEBUG_LL) &&
\
+ (defined(CONFIG_MACH_OMAP_ZOOM2) || defined(CONFIG_MACH_OMAP_ZOOM3))
+ {
+ .virtual= ZOOM_UART_VIRT,
+ .pfn= __phys_to_pfn(ZOOM_UART_BASE),
+ .length = SZ_1M,
+ .type = MT_DEVICE
+ },
+#endif
};
#endif
#ifdef CONFIG_ARCH_OMAP4
diff --git a/arch/arm/plat-omap/include/plat/serial.h
b/arch/arm/plat-omap/include/plat/serial.h
index 83dce4c..9ec7eab 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -39,7 +39,7 @@
/* External port on Zoom2/3 */
#define ZOOM_UART_BASE 0x1000
-#define ZOOM_UART_VIRT 0xfb00
+#define ZOOM_UART_VIRT 0xfa40
#define OMAP_PORT_SHIFT2
#define OMAP7XX_PORT_SHIFT 0
--
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 01/11] omap2/3/4: Fix multi.h when omap3 and omap4 are selected without omap2
Otherwise we'll get an error about get_irqnr_and_base being defined twice. Add an entry for omap4, and use ARCH_OMAP3 for omap3 instead of ARCH_OMAP3430. Also fix the check for omap1 to use ARCH_OMAP2PLUS to avoid having to add ARCH_OMAP4 separately there. Signed-off-by: Tony Lindgren --- arch/arm/plat-omap/include/plat/multi.h | 16 1 files changed, 12 insertions(+), 4 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/multi.h b/arch/arm/plat-omap/include/plat/multi.h index f235d32..ffd909f 100644 --- a/arch/arm/plat-omap/include/plat/multi.h +++ b/arch/arm/plat-omap/include/plat/multi.h @@ -61,9 +61,9 @@ # define OMAP_NAME omap16xx # endif #endif -#if (defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)) +#ifdef CONFIG_ARCH_OMAP2PLUS # if (defined(OMAP_NAME) || defined(MULTI_OMAP1)) -# error "OMAP1 and OMAP2 can't be selected at the same time" +# error "OMAP1 and OMAP2PLUS can't be selected at the same time" # endif #endif #ifdef CONFIG_ARCH_OMAP2420 @@ -82,12 +82,20 @@ # define OMAP_NAME omap2430 # endif #endif -#ifdef CONFIG_ARCH_OMAP3430 +#ifdef CONFIG_ARCH_OMAP3 # ifdef OMAP_NAME # undef MULTI_OMAP2 # define MULTI_OMAP2 # else -# define OMAP_NAME omap3430 +# define OMAP_NAME omap3 +# endif +#endif +#ifdef CONFIG_ARCH_OMAP4 +# ifdef OMAP_NAME +# undef MULTI_OMAP2 +# define MULTI_OMAP2 +# else +# define OMAP_NAME omap4 # endif #endif -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/11] omap2/3/4: Multi-omap updates to boot test with omap3_defconfig
Hi all, This series makes the omap3_defconfig bootable on most mach-omap2 boards. So far I've boot tested omap3_defconfig on: BOARD OMAPARM NOTES n8002420ARMv6 Userspace won't boot because of TLS and VFP issues n9003430ARMV7 zoom3 3630ARMV7 blaze 4430ARMV7 CONFIG_SMP disabled I've pushed these into multi-omap branch in the linux omap tree, would like to hear status of other boards booting with omap3_defconfig with these patches. CONFIG_FB_OMAP is now disabled until some weirdness on at least zoom3 is sorted out. And, you need to disable CONFIG_KPROBES on 2.6.34-rc6 until that fix is in mainline. Anyways, let's use omap3_defconfing from now on to compile and boot test every patch as a sanity test. Regards, Tony --- Tony Lindgren (11): omap2/3/4: Fix multi.h when omap3 and omap4 are selected without omap2 omap2/3: Fix DEBUG_LL for omap zoom2/3 omap3: Fix compile for board-cm-t35 omap3: Remove non-muxable ball entries for 3630 omap4: Fix multiboot with CONFIG_PM and CONFIG_ARCH_OMAP3 selected omap4: Fix omap_l2_cache_init not to run for other omaps omap2/3/4: Add new boards to omap3_defconfig omap2/3/4: Make omap3_defconfig usable on Nokia boards omap2/3/4: Update PMIC options for TWL and Menelaus chips omap2/3/4: Dissable CONFIG_PM_VERBOSE in omap3_defconfig omap2/3/4: Disable CONFIG_FB_OMAP in omap3_defconfig arch/arm/configs/omap3_defconfig | 34 - arch/arm/kernel/head.S | 10 +++ arch/arm/mach-omap2/board-4430sdp.c|3 + arch/arm/mach-omap2/board-cm-t35.c |1 arch/arm/mach-omap2/board-zoom-debugboard.c|2 - arch/arm/mach-omap2/include/mach/debug-macro.S |4 + arch/arm/mach-omap2/io.c |9 +++ arch/arm/mach-omap2/mux34xx.c | 86 arch/arm/plat-omap/include/plat/multi.h| 16 +++- arch/arm/plat-omap/include/plat/serial.h |2 - arch/arm/plat-omap/sram.c | 16 11 files changed, 68 insertions(+), 115 deletions(-) -- Signature -- 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/7] OMAP4-HSMMC: Adding HSMMC support for OMAP4430 Board file
On Wed, Apr 21, 2010 at 11:49:55PM +0530, kishore kadiyala wrote:
> @@ -99,6 +110,17 @@ static struct regulator_consumer_supply
> sdp4430_vmmc_supply[]
> },
> };
>
> +static int __init sdp4430_mmc_init(void)
> +{
> + omap2_hsmmc_init(mmc);
> +
> + /* link regulators to MMC adapters ... we "know" the
> + * regulators will be set up only *after* we return.
> + */
> + sdp4430_vmmc_supply[0].dev = mmc[0].dev;
> + sdp4430_vmmc_supply[1].dev = mmc[1].dev;
> + return 0;
> +}
There should be a blank line between functions.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
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 5/7] OMAP4-HSMMC: Adds Dummy Interface clock's for MMC controllers
On Wed, Apr 21, 2010 at 11:50:56PM +0530, kishore kadiyala wrote: > This patch adds dummy Interface clocks for MMC controllers Looks to me as if it changes the formatting; it doesn't seem to be adding anything. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- 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: [2.6.34-rc6] ARM: build breaks with KPROBES
On Fri, Apr 30, 2010 at 12:51:49PM +0530, Shilimkar, Santosh wrote: > Russell, > > The latest mainline ARM build breaks with KPROBES enabled. Anand > Gadiyar did git bisect and figured out that below commit breaks the build. > commit :4260415f6a3b92c5c986398d96c314df37a4ccbf Did you read the comments in the commit message to understand why .previous is dangerous? > I tried matching the sections but failed to fix the build error. Below > is the hack patch to keep build working. The previous section is not .text, but: #ifdef CONFIG_KPROBES .section.kprobes.text,"ax",%progbits #else .text #endif Either change the preceding .data to .pushsection .data, and the following .text to .popsection, or duplicate the above ifdef; .pushsection/.popsection is _far_ safer than using .previous. -- 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: [2.6.34-rc6] ARM: build breaks with KPROBES
On Fri, Apr 30, 2010 at 02:57:20PM +0530, Shilimkar, Santosh wrote: > >From 2660d4ca5d77406fc8d46a5c0f18127332914604 Mon Sep 17 00:00:00 2001 > From: Santosh Shilimkar > Date: Fri, 30 Apr 2010 12:41:16 +0530 > Subject: [PATCH] ARM: Fix build break with KPROBES enabled > > With CONFIG_KPROBES enabled two section are getting created which > leads to below build break. 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 02/14] omap: Make uncompress code and DEBUG_LL code generic
On Tue, 2010-01-26 at 12:12 -0800, Tony Lindgren wrote: > Define arch_decomp_setup() the same way as some other > architectures do. Use arch_id to configure the debug uart > based on the machine_is by storing it into the uart > scratchpad register for DEBUG_LL code to use. > > Note that to avoid merge conflicts, this patch is using > hardcoded register r1 until tmp register is being passed > for all addruart macros. > > Signed-off-by: Tony Lindgren This has been working well, but has a couple serious limitations: 1. assumes bootloader has enabled UART1 clocks 2. assumes all SoCs supported have the same UART1 base With more platforms using USB-based UARTs, assumption (1) may not be safe for very long, as bootloaders for these platforms don't really *need* to enable UART1. Currently, they happen to mainly because of copied init code from other platforms. But more importantly, there are more OMAP derivative parts coming soon, and one in particular coming soon[1] breaks assumption 2 by having a different UART1 base (yes, it's branded as a DaVinci, but it's an OMAP core as far as linux is concerned. Don't get me started on TI branding.) To fix both problems, maybe we should just use a fixed memory location to pass this temporary data from uncompress to the kernel. We've had a similar problem on DaVinci recently and a proposal has been made (and tested) to use memory just below the page tables[2].) Any comments on this proposal? or alternative suggestions? Kevin [1] http://www.ti.com/ww/en/dsp/davinci-netra/index.shtml [2] https://patchwork.kernel.org/patch/94724/ -- 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/14] omap: Make uncompress code and DEBUG_LL code generic
On Fri, Apr 30, 2010 at 12:20:35PM -0400, Cyril Chemparathy wrote: > Hi, > > [...] > > To fix both problems, maybe we should just use a fixed memory location > > to pass this temporary data from uncompress to the kernel. We've had a > > similar problem on DaVinci recently and a proposal has been made (and > > tested) to use memory just below the page tables[3].) > > Essentially both of these approaches (internal scratch register and > fixed address) implement a weird back-channel communication scheme > between the decompresser and the debug macros. > > A more elegant solution may be as follows: > - pass machine_arch_type as an argument into addruart. Unfortunately, that breaks addruart. Firstly, addruart is used from assembly code where very limited registers are available (the fewer registers it clobbers the less likely debug is going to cause stuff to break.) Secondly, the places that addruart may be called from, the location of the machine type number is indeterminent. Remember that this macro can be called when the MMU is on or off, and can be called before the machine_arch_type has been initialized. > - move the uart base lookup logic to addruart using macros similar > to DEBUG_LL_*, except that these expand to assembly code this > time. > - reuse these debug-macros in uncompress.h and implement putc() and > flush() using addruart(), senduart(), etc. Given what I've said above about the debug macros, this is definitely the wrong solution. Having the decompressor macros work whatever the machine type is reasonable, and the machine_is_xxx() macros already work at that point, so there shouldn't be much of an issue there. As far as the debug macros go, I think we're at the point where it's basically just far easier to leave these macros as a developer debugging tool and we'll just have to put up with it being something that an OMAP developer has to edit according to his platform to make work. After all, _NO_ production kernel what so ever should be using this debug support. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader
On Thu, Apr 29, 2010 at 12:23 PM, Mike Rapoport wrote:
> Vimal Singh wrote:
>>
>> On Wed, Apr 28, 2010 at 9:36 PM, Mike Rapoport
>> wrote:
>>>
>>> Signed-off-by: Mike Rapoport
>>> + if (gpmc_nand_data->keep_timings) {
>>> + gpmc_nand_detect_timings();
>>> + gpmc_nand_data->gpmc_t = &gpmc_default_timings;
>>> + }
>>> +
>>
>> I guess moving this part to omap2_nand_gpmc_retime will be a good idea.
>> As there, once we get old/default timings we can simply skip the
>> rounding part and directly jump to setting the timings.
>
> This way it would be the same as to pass 'gpmc_nand_data->gpmc_t =
> NULL'. If I correctly understood the previous comments ([1]), the
> problem with skipping retime is that when L3 clock changes, the gpmc
> timings became wrong. So, if we convert old/default timings to
> nanoseconds early during startup every time retime is called it will use
> the timing settings in nanoseconds thus yielding proper gpmc registers
> configuration.
OK. Then I think we can at least put __rounding__ code inside an 'if'
case, something like:
if (!gpmc_nand_data->keep_timings) {
...
do rounding for supplied timings from board file.
...
}
> And, if I'm not terribly mistaken retime should be called each time L3
> frequency changes, though with current kernel it's not yet the case...
Yes. This is still left.
--
Regards,
Vimal Singh
--
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/14] omap: Make uncompress code and DEBUG_LL code generic
Hi, [...] > To fix both problems, maybe we should just use a fixed memory location > to pass this temporary data from uncompress to the kernel. We've had a > similar problem on DaVinci recently and a proposal has been made (and > tested) to use memory just below the page tables[3].) Essentially both of these approaches (internal scratch register and fixed address) implement a weird back-channel communication scheme between the decompresser and the debug macros. A more elegant solution may be as follows: - pass machine_arch_type as an argument into addruart. - move the uart base lookup logic to addruart using macros similar to DEBUG_LL_*, except that these expand to assembly code this time. - reuse these debug-macros in uncompress.h and implement putc() and flush() using addruart(), senduart(), etc. This way, both the decompresser and the kernel debug macros end up using machine_arch_type to get to the right debug uart, without resorting to underhand back-channel tricks. Any thoughts? -- Cyril. -- 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] DSPBRIDGE: MMU-Fault debugging enhancements
Hi, >-Original Message- >From: Felipe Contreras [mailto:felipe.contre...@gmail.com] >Sent: Friday, April 30, 2010 10:21 AM >To: Guzman Lugo, Fernando; Ramos Falcon, Ernesto >Cc: linux-omap@vger.kernel.org; Hiroshi DOYU; Ameya Palande; >felipe.contre...@nokia.com >Subject: Re: [PATCH] DSPBRIDGE: MMU-Fault debugging enhancements > >On Fri, Apr 9, 2010 at 3:15 AM, Guzman Lugo, Fernando >wrote: >> From db3d76a2e89a1c227322a2732ddf7ebf5cd4b4cf Mon Sep 17 00:00:00 2001 >> From: Ernesto Ramos >> Date: Wed, 24 Mar 2010 11:12:05 -0600 >> Subject: [PATCH] DSPBRIDGE: MMU-Fault debugging enhancements >> >> These changes allow for DSP task information to be printed >> by the MPU dspbridge when DSP MMU fault ocurrs. >> >> Signed-off-by: Cris Jansson >> [change to open source coding style] >> Signed-off-by: Ernesto Ramos > >This patch seems to be doing a lot of things. Couldn't it have been split? > >Also, from the commit message it seems to implement a new feature, >however, I heard it's supposed to fix memory corruption too. Is that >true? If that's the case the code that fixes that would have to be >separate. > >I understand this patch was already pushed to dspbridge branch, but I >think such important changes should be properly recorded in the >history. > >Cheers. > Hi Felipe, I agree important changes must be properly recorded but in this case the patch introduces only one new feature and because of the way that it is implemented using gpt8 overflow interrupt instead of mailbox to inform about the MMU Fault, the problem of the memory corruption was fixed indirectly, however these changes are part of the feature design itself and I don't see the need to split this new feature. Saludos, Ernesto >-- >Felipe Contreras-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] can:ti_hecc: board specific hookup on AM3517EVM
> -Original Message- > From: Govindarajan, Sriramakrishnan > Sent: Tuesday, February 23, 2010 12:08 PM > To: linux-omap@vger.kernel.org > Cc: Gole, Anant; Govindarajan, Sriramakrishnan > Subject: [PATCH 2/2] can:ti_hecc: board specific hookup on AM3517EVM > > Add board specific hookup for TI HECC driver on > AM3517 EVM > > Signed-off-by: Sriramakrishnan > Acked-by: Anant Gole > --- > The driver requires that CAN_STB signal be driven low to enable > CAN PHY. Currently this is being managed from U-boot. Will submit a patch > for handling this as part of board init sequence. > > arch/arm/mach-omap2/board-am3517evm.c | 38 > + > arch/arm/mach-omap2/include/mach/am35xx.h | 10 +++ > 2 files changed, 48 insertions(+), 0 deletions(-) > [Sriram] Tony, there hasn't been any review comments on this patch for long. Do you any comments on this patch? If not can please apply this patch Regards Sriram -- 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 4/4] OMAP3: PM: export chip IDCODE, Production ID and Die ID
On Wed, Apr 28, 2010 at 06:21:02PM +0200, ext Kevin Hilman wrote: > Eduardo Valentin writes: > > > From: Eduardo Valentin > > > > This patch exports the OMAP3 IDCODE and Production ID to userspace > > via /proc/cpuinfo using the system_soc_info. > > > > Die ID is also exported depending on what users pass as kernel > > parameter. It is same protection mechanism made for x86 product > > number. So, if user passes "omap3_die_id" parameter, it will append > > die id code into /proc/cpuinfo as well. A Kconfig option has been > > added as well, so it can be configurable during compilation time. > > > > This can be used to track down silicon specific issues. The info is > > exported via /proc/cpuinfo because then it can be possible to include this > > in corematic dumps. > > > > This is based on Peter De Schrijver patch, which export same info via sysfs. > > > > Signed-off-by: Eduardo Valentin > > Re: $SUBJECT, why the PM: prefix? Yes indeed, no need to be PM bound. > > Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Disable the non working eMMC on Zoom2/3
> > > > > > > Hmm, finally got around looking into this again. Looks like the mmc > > > > is now working on my zoom3 with the current Linus' tree at commit > > > > 7c6bd2010fced38444c9fd658f4c6ce61bd185bf. So I guess something that > > > > we had in omap-fixes fixed this. Or maybe some fix for drivers/mmc? > > > > > > > > This is with the debug_ll patch applied: > > > > > > > > https://patchwork.kernel.org/patch/87532/ > > > > > > For the microSD card, turns out the card I used was flakey. So > > > that should explain some of the problems. I'm almost certain > > > I tried with two different cards earlier though. In any case, > > > let's assume the problem is only the eMMC. > > > > > Sorry, I did not get a complete picture. Your earlier email said that > with > > Linus tree eMMC on your Zoom3 is working. Is that correct? > > Nope, now the microSD is working, eMMC is not working. > > > IMHO, an omap level fix can not solve the problem with eMMC because as I > can > > see from the log you provided above that a 16G device is detected as 1G. > > This is certainly due to the issue I mentioned earlier. > > OK This means that some production boards still have this issue with eMMC. So my patch disables the support for MMC2 on zoom boards. Would you consider that? Regards, Madhu > > 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
[RFC] [PATCH 2/2] Platform changes for CMA3000
>From 68cde2e0304b1bd44e9fdbfbaa071e91cfcad419 Mon Sep 17 00:00:00 2001
From: Hemanth V
Date: Fri, 30 Apr 2010 11:56:30 +0530
Subject: [PATCH] Platform changes for CMA3000
Signed-off-by: Hemanth V
---
arch/arm/mach-omap2/board-4430sdp.c | 38 ++-
1 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 72e7b14..717ad4b 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -39,9 +40,12 @@
#include
#include
#include
+#include
#include
#include "mmc-twl4030.h"
+#define OMAP4_CMA3000ACCL_GPIO 186
+
static int sdp4430_keymap[] = {
KEY(0, 0, KEY_E),
KEY(0, 1, KEY_R),
@@ -503,6 +507,18 @@ static struct twl4030_platform_data sdp4430_twldata = {
.bci= &sdp4430_bci_data,
};
+static struct cma3000_platform_data cma3000_platform_data = {
+ .fuzz_x = 25,
+ .fuzz_y = 25,
+ .fuzz_z = 25,
+ .g_range = CMARANGE_8G,
+ .mode = CMAMODE_MOTDET,
+ .mdthr = 0x8,
+ .mdfftmr = 0x33,
+ .ffthr = 0x8,
+ .irqflags = IRQF_TRIGGER_HIGH,
+};
+
static struct i2c_board_info __initdata sdp4430_i2c_boardinfo[] = {
{
I2C_BOARD_INFO("twl6030", 0x48),
@@ -526,6 +542,14 @@ static struct i2c_board_info __initdata
sdp4430_i2c_3_boardinfo[] = {
},
};
+static struct i2c_board_info __initdata sdp4430_i2c_4_boardinfo[] = {
+ {
+ I2C_BOARD_INFO("cma3000_accl", 0x1c),
+ .platform_data = &cma3000_platform_data,
+ .irq = OMAP_GPIO_IRQ(OMAP4_CMA3000ACCL_GPIO),
+ },
+};
+
static int __init omap4_i2c_init(void)
{
/* Phoenix Audio IC needs I2C1 to srat with 400 KHz and less */
@@ -535,7 +559,8 @@ static int __init omap4_i2c_init(void)
ARRAY_SIZE(sdp4430_i2c_2_boardinfo));
omap_register_i2c_bus(3, 400, sdp4430_i2c_3_boardinfo,
ARRAY_SIZE(sdp4430_i2c_3_boardinfo));
- omap_register_i2c_bus(4, 400, 0, 0);
+ omap_register_i2c_bus(4, 400, sdp4430_i2c_4_boardinfo,
+ ARRAY_SIZE(sdp4430_i2c_4_boardinfo));
return 0;
}
@@ -578,6 +603,16 @@ static void omap_ethernet_init(void)
gpio_direction_input(34);
}
+static void omap_cma3000accl_init(void)
+{
+
+ if (gpio_request(OMAP4_CMA3000ACCL_GPIO, "Accelerometer") < 0) {
+ pr_err("Accelerometer GPIO request failed\n");
+ return;
+ }
+ gpio_direction_input(OMAP4_CMA3000ACCL_GPIO);
+
+}
static void __init omap_4430sdp_init(void)
{
omap4_i2c_init();
@@ -591,6 +626,7 @@ static void __init omap_4430sdp_init(void)
sdp4430_spi_board_info[0].irq = gpio_to_irq(34);
spi_register_board_info(sdp4430_spi_board_info,
ARRAY_SIZE(sdp4430_spi_board_info));
+ omap_cma3000accl_init();
}
--
1.5.6.3
--
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] OMAP3EVM: Update pad configuration for wakeup enabled pads
On Thu, 29-Apr-10 7:41 PM +0530, Kevin Hilman wrote: > Ranjith Lohithakshan writes: > >> On Wed, 28-Apr-10 11:53 PM +0530, Kevin Hilman wrote: >>> Ranjith Lohithakshan writes: >>> Kevin, On Tue, 27-Apr-10 8:46 PM +0530, Kevin Hilman wrote: > Ranjith Lohithakshan writes: > >> OMAP3530 TRM section 7.4.4.4.2 requires OFFOUTENABLE to be set (active >> low) >> if wakeup capabilities are enabled on a pad. During OFF mode testing >> on OMAP3530 EVM, it was observed that the device was not residing in >> the OFF state. The device enters into the OFF state and immediately exits >> from that state as if an IO wakeup event has occured. The issue was >> traced >> down to the pad configuration of wkaeup enabled pad's. > Nice. > >> Also, the pad configuration is included only if the respective drivers >> are >> enabled in the defconfig. > Hmm, do you really want this? If you don't have the driver enabled, > you have to rely on the bootloader settings of these pads which may > also be wrong and trigger an IO wakeup as well. The thought process was that, for example, if keypad is not enabled in a system configuration you probably don't want to see a wakeup occurring if someone presses a key stroke. I understand the concern that you have raised regarding bootloader mis-configurations. My impression was that the bootloaders typically set the mux modes and pull up's/downs and dont really program or enable the wakeup capability. But we cannot depend on that thumb rule. >>> Unfortunately, Bootloaders don't "typically" do anything. They are >>> routinely hacked/patched and cannot be trusted at all. >>> What is your recommendation? >>> First, I suggest you fix the OFFOUTENABLE bug in a single patch >>> without introducing the #ifdefs. Then, address the enable/disable of >>> the wakeups in a separate patch. >> I will do that. >> >>> Next, ideally wakeups should not be configured a this level of board >>> code. There are APIs for that: enable_irq_wake()/disable_irq_wake() >>> >>> For GPIOs (like the touchscreen), you really need to enable wakeups >>> using existing APIs, either in the driver or in board init code and be >>> sure there is an interrupt handler. Please see the 'Known Problems' >>> section of the OMAP PM wiki[2] where it talks about GPIO wakeups. >>> Below[2] is an test patch I've used. >> I have pushed a patch on ads7846 to linux-input some time ago adding >> wakeup support. >> >> fdba2bb : Input: ads7846 - add wakeup support >> >> There is now a wakeup flag added to the ads7846 platform data which can >> enabled at the board level. Once this is set , the driver will do an >> enable_irq_wake. The patch is now accepted and in mainline. I will >> remove the wakeup mux configuration from the board file and instead will >> just set the wakeup flag in the ads7846 platform data. I will submit a patch with the necessary changes. > Brilliant! you're several steps ahead of me. Would you mind > submitting a patch to l-o to enable that for SDP and omap3evm so I > can drop my suggested patch? > >> The keypad uses a pin in the non-gpio mode. Is enable_irq_wake supported >> for non-gpio mode? > > Not currently, as enable_irq_wake() ends up calling into the > irq_chip's set_wake() method. This then calls into the OMAP GPIO > layer as plat-omap/gpio.c:gpio_wake_enable() > > For now, the keypad could just use the mux API at runtime like SDP does > to enable wakeups when needed. > > Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP 3530 LV-SOM support (was: Re: Patch format for submission?)
On Thu, Aug 20, 2009 at 06:02:06PM +0200, Stephan Linz wrote: > Am Mittwoch, 19. August 2009 schrieb Peter Barada: > > 1) Does anyone have a URL of the format patches should be in that are > > submitted to the linux-omap list? > > > > I've got some patches to add base support for the Logic OMAP 35x SOM and > > Torpedo boards and I'd like to submit them in the right format for > > inclusion and push into mainline. > > Hi Peter, > > nice to see your announcement here at linux-omap. Today I've finished my own > port for the Logic OMAP 35x SOM based on 2.6.31-rc1. We should share our > results befor submitting any patches to the list, or not? That's the last message I can find from either of you on this topic. I'm in the process of rolling yet another patch set for 2.6.32. Was any further work done on this, or anything posted anywhere? -- 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] omap3: Fix 3630 mux errors
From: Allen Pais
The omap3630 has more mux signals than 34xx. The additional
pins exist in omap36xx_cbp_subset, but are not initialized
as the superset is missing these offsets. This causes the
following errors during the boot:
mux: Unknown ball offset 0x5e
mux: Unknown ball offset 0x60
mux: Unknown ball offset 0x62
mux: Unknown ball offset 0x64
mux: Unknown ball offset 0x66
mux: Unknown ball offset 0x68
mux: Unknown ball offset 0x6a
mux: Unknown ball offset 0x6c
mux: Unknown ball offset 0x90
mux: Unknown ball offset 0x7e
mux: Unknown ball offset 0x92
mux: Unknown ball offset 0x94
mux: Unknown ball offset 0x9c
mux: Unknown ball offset 0x18a
mux: Unknown ball offset 0x18c
mux: Unknown ball offset 0xa1e
mux: Unknown ball offset 0x9ee
mux: Unknown ball offset 0x9f2
mux: Unknown ball offset 0xa20
mux: Unknown ball offset 0x9f0
mux: Unknown ball offset 0x574
mux: Unknown ball offset 0x576
mux: Unknown ball offset 0x588
mux: Unknown ball offset 0x58a
mux: Unknown ball offset 0x58c
mux: Unknown ball offset 0x58e
mux: Unknown ball offset 0x590
mux: Unknown ball offset 0x578
mux: Unknown ball offset 0x57a
mux: Unknown ball offset 0x57c
mux: Unknown ball offset 0x57e
mux: Unknown ball offset 0x580
mux: Unknown ball offset 0x582
mux: Unknown ball offset 0x584
mux: Unknown ball offset 0x586
mux: Unknown ball offset 0x570
mux: Unknown ball offset 0x572
mux: Unknown ball offset 0x40
mux: Unknown ball offset 0x0
mux: Unknown ball offset 0x2
mux: Unknown ball offset 0x14
mux: Unknown ball offset 0x16
mux: Unknown ball offset 0x18
mux: Unknown ball offset 0x1a
mux: Unknown ball offset 0x1c
mux: Unknown ball offset 0x1e
mux: Unknown ball offset 0x20
mux: Unknown ball offset 0x22
mux: Unknown ball offset 0x24
mux: Unknown ball offset 0x26
mux: Unknown ball offset 0x4
mux: Unknown ball offset 0x28
mux: Unknown ball offset 0x2a
mux: Unknown ball offset 0x2c
mux: Unknown ball offset 0x2e
mux: Unknown ball offset 0x30
mux: Unknown ball offset 0x32
mux: Unknown ball offset 0x34
mux: Unknown ball offset 0x36
mux: Unknown ball offset 0x38
mux: Unknown ball offset 0x3a
mux: Unknown ball offset 0x6
mux: Unknown ball offset 0x3c
mux: Unknown ball offset 0x3e
mux: Unknown ball offset 0x8
mux: Unknown ball offset 0xa
mux: Unknown ball offset 0xc
mux: Unknown ball offset 0xe
mux: Unknown ball offset 0x10
mux: Unknown ball offset 0x12
mux: Unknown ball offset 0x59e
mux: Unknown ball offset 0x5a0
mux: Unknown ball offset 0x5a2
mux: Unknown ball offset 0x5a4
mux: Unknown ball offset 0x42
mux: Unknown ball offset 0x44
mux: Unknown ball offset 0x46
mux: Unknown ball offset 0x48
mux: Unknown ball offset 0x59a
mux: Unknown ball offset 0x596
mux: Unknown ball offset 0x592
mux: Unknown ball offset 0x594
mux: Unknown ball offset 0x598
mux: Unknown ball offset 0x59c
mux: Unknown ball offset 0x9d4
Fix this by adding the missing offsets to omap3 superset.
Note that additionally the uninitialized pins need to be
skipped on 34xx.
Reported-by: Manjunatha GK
Signed-off-by: Allen Pais
Signed-off-by: Manjunatha GK
Cc: Tony Lindgren
Cc: Paul Walmsley
---
arch/arm/mach-omap2/mux34xx.c | 256 +
1 files changed, 256 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux34xx.c b/arch/arm/mach-omap2/mux34xx.c
index 07aa7b3..4a28e6f 100644
--- a/arch/arm/mach-omap2/mux34xx.c
+++ b/arch/arm/mach-omap2/mux34xx.c
@@ -696,6 +696,262 @@ static struct omap_mux __initdata omap3_muxmodes[] = {
_OMAP3_MUXENTRY(SAD2D_MCAD36, 0,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL),
+
+ _OMAP3_MUXENTRY(GPMC_D0, 0,
+ NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+ _OMAP3_MUXENTRY(GPMC_D1, 0,
+ NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+ _OMAP3_MUXENTRY(GPMC_D2, 0,
+ NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+ _OMAP3_MUXENTRY(GPMC_D3, 0,
+ NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+ _OMAP3_MUXENTRY(GPMC_D4, 0,
+ NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+ _OMAP3_MUXENTRY(GPMC_D5, 0,
+ NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+ _OMAP3_MUXENTRY(GPMC_D6, 0,
+ NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+ _OMAP3_MUXENTRY(GPMC_D7, 0,
+ NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+ _OMAP3_MUXENTRY(GPMC_NADV_ALE, 0,
+ NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+ _OMAP3_MUXENTRY(GPMC_NCS0, 0,
+ NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+ _OMAP3_MUXENTRY(GPMC_NOE, 0,
+ NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+ _OMAP3_MUXENTRY(GPMC_NWE, 0,
+ NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+
Re: [PATCH] omap3: Fix 3630 mux errors
* Manjunatha GK [100429 00:23]: > From: Allen Pais > > The omap3630 has more mux signals than 34xx. The additional > pins exist in omap36xx_cbp_subset, but are not initialized > as the superset is missing these offsets. This causes the > following errors during the boot: I have an earlier version of this queued up, will take a look and see if they're the same: https://patchwork.kernel.org/patch/87555/ 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: omap-pm: omap3_pm_defconfig no longer booting on Overo
Peter Tseng writes: > Since the rc5 tag, omap3_pm_defconfig from the pm branch no longer boots > on the Gumstix Overo. > I am certain that a build back in the rc3 days worked. Unfortunately, I > don't know about rc4, or anything that happenend in the intervening time. > > Any clues on how to fix? If necessary, I'll provide what info I can to > help diagnose the issue if told what to do. First step is to enable CONFIG_LL_DEBUG and CONFIG_EARLYPRINTK in the defconfig (I should have these enabled by default in omap3_pm_defconfig) Then, boot adding 'earlyprintk' to your boot cmdline and post the resulting bootlog here. Thanks, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] omap4: Move SOC specific code from board file
This patch moves OMAP4 soc specific code from 4430sdp board file.
The change is necessary so that newer board support can be added
with minimal changes. This will be also problematic for
multi-board, multi-omap builds.
Signed-off-by: Santosh Shilimkar
---
Boot tested with regular and multi-omap defconfig on OMAP4430 and
OMAP3430 SDPs. OMAP4430 still needs to fix unused clock and pm to
make it boot with multi-omap build.
arch/arm/mach-omap2/Makefile|2 +-
arch/arm/mach-omap2/board-4430sdp.c | 47 +--
arch/arm/mach-omap2/include/mach/omap4-common.h | 26
arch/arm/mach-omap2/omap-smp.c |2 +-
arch/arm/mach-omap2/omap4-common.c | 73 +++
arch/arm/plat-omap/common.c |3 -
arch/arm/plat-omap/include/plat/common.h|3 -
7 files changed, 102 insertions(+), 54 deletions(-)
create mode 100644 arch/arm/mach-omap2/include/mach/omap4-common.h
create mode 100644 arch/arm/mach-omap2/omap4-common.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4b9fc57..ffe600a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -22,7 +22,7 @@ obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
# SMP support ONLY available for OMAP4
obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o
obj-$(CONFIG_LOCAL_TIMERS) += timer-mpu.o
-obj-$(CONFIG_ARCH_OMAP4) += omap44xx-smc.o
+obj-$(CONFIG_ARCH_OMAP4) += omap44xx-smc.o omap4-common.o
AFLAGS_omap44xx-smc.o :=-Wa,-march=armv7-a
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index b88f28c..0f8cd85 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -20,6 +20,7 @@
#include
#include
+#include
#include
#include
#include
@@ -29,8 +30,6 @@
#include
#include
#include
-#include
-#include
static struct platform_device sdp4430_lcd_device = {
.name = "sdp4430_lcd",
@@ -49,50 +48,6 @@ 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)
-{
- extern void omap_smc1(u32 fn, u32 arg);
- void __iomem *l2cache_base;
-
- /* To avoid code running on other OMAPs in
-* multi-omap builds
-*/
- if (!cpu_is_omap44xx())
- return -ENODEV;
-
- /* Static mapping, never released */
- l2cache_base = ioremap(OMAP44XX_L2CACHE_BASE, SZ_4K);
- BUG_ON(!l2cache_base);
-
- /* Enable PL310 L2 Cache controller */
- omap_smc1(0x102, 0x1);
-
- /* 32KB way size, 16-way associativity,
- * parity disabled
- */
- l2x0_init(l2cache_base, 0x0e05, 0xcfff);
-
- return 0;
-}
-early_initcall(omap_l2_cache_init);
-#endif
-
-static void __init gic_init_irq(void)
-{
- void __iomem *base;
-
- /* Static mapping, never released */
- base = ioremap(OMAP44XX_GIC_DIST_BASE, SZ_4K);
- BUG_ON(!base);
- gic_dist_init(0, base, 29);
-
- /* Static mapping, never released */
- gic_cpu_base_addr = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_512);
- BUG_ON(!gic_cpu_base_addr);
- gic_cpu_init(0, gic_cpu_base_addr);
-}
-
static void __init omap_4430sdp_init_irq(void)
{
omap_board_config = sdp4430_config;
diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
b/arch/arm/mach-omap2/include/mach/omap4-common.h
new file mode 100644
index 000..423af3a
--- /dev/null
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -0,0 +1,26 @@
+/*
+ * omap4-common.h: OMAP4 specific common header file
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * Author:
+ * Santosh Shilimkar
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef OMAP_ARCH_OMAP4_COMMON_H
+#define OMAP_ARCH_OMAP4_COMMON_H
+
+#ifdef CONFIG_CACHE_L2X0
+extern void __iomem *l2cache_base;
+#endif
+
+extern void __iomem *gic_cpu_base_addr;
+extern void __iomem *gic_dist_base_addr;
+
+extern void __init gic_init_irq(void);
+extern void omap_smc1(u32 fn, u32 arg);
+
+#endif
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 38153e5..1cf5231 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -24,7 +24,7 @@
#include
#include
#include
-#include
+#include
/* SCU base address */
static void __iomem *scu_base;
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
new file mode 100644
index 000..075aad4
--- /dev/null
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -0,0 +1,73 @@
+/*
+ * OMAP4 specific common source file.
+ *
+
RE: [PATCH 1/4] omap: mailbox cleanup: convert rwlocks to spinlock
Ohad,
Looks like the conversion was missed in few places resulting in compile
warnings.
Please see the below fix. Let me know if you agree with the change.
#
[PATCH] omap: mailbox: rwlocks to spinlock: compilation fix
fixed the missed rwlocks in few places resultion in following
compiler warning.
arch/arm/plat-omap/mailbox.c: In function 'omap_mbox_startup':
arch/arm/plat-omap/mailbox.c:246: warning: passing argument 1 of
'_raw_write_lock' from incompatible pointer type
arch/arm/plat-omap/mailbox.c:251: warning: passing argument 1 of
'_raw_write_unlock' from incompatible pointer type
arch/arm/plat-omap/mailbox.c:255: warning: passing argument 1 of
'_raw_write_unlock' from incompatible pointer type
arch/arm/plat-omap/mailbox.c: In function 'omap_mbox_fini':
arch/arm/plat-omap/mailbox.c:301: warning: passing argument 1 of
'_raw_write_lock' from incompatible pointer type
arch/arm/plat-omap/mailbox.c:306: warning: passing argument 1 of
'_raw_write_unlock' from incompatible pointer type
Signed-off-by: Hari Kanigeri
---
arch/arm/plat-omap/mailbox.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 27a8d98..d6a700d 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -243,16 +243,16 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
struct omap_mbox_queue *mq;
if (likely(mbox->ops->startup)) {
- write_lock(&mboxes_lock);
+ spin_lock(&mboxes_lock);
if (!mbox_configured)
ret = mbox->ops->startup(mbox);
if (unlikely(ret)) {
- write_unlock(&mboxes_lock);
+ spin_unlock(&mboxes_lock);
return ret;
}
mbox_configured++;
- write_unlock(&mboxes_lock);
+ spin_unlock(&mboxes_lock);
}
ret = request_irq(mbox->irq, mbox_interrupt, IRQF_SHARED,
@@ -298,12 +298,12 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
free_irq(mbox->irq, mbox);
if (likely(mbox->ops->shutdown)) {
- write_lock(&mboxes_lock);
+ spin_lock(&mboxes_lock);
if (mbox_configured > 0)
mbox_configured--;
if (!mbox_configured)
mbox->ops->shutdown(mbox);
- write_unlock(&mboxes_lock);
+ spin_unlock(&mboxes_lock);
}
}
--
> -Original Message-
> From: Ohad Ben-Cohen [mailto:o...@wizery.com]
> Sent: Tuesday, April 27, 2010 12:56 PM
> To: linux-omap@vger.kernel.org
> Cc: Kanigeri, Hari; Hiroshi Doyu; Ohad Ben-Cohen
> Subject: [PATCH 1/4] omap: mailbox cleanup: convert rwlocks
> to spinlock
>
> rwlocks are slower and have potential starvation issues so
> spinlocks are generally preferred
>
> Signed-off-by: Ohad Ben-Cohen
> ---
> arch/arm/plat-omap/mailbox.c | 20 ++--
> 1 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/plat-omap/mailbox.c
> b/arch/arm/plat-omap/mailbox.c index 08a2df7..d73d51a 100644
> --- a/arch/arm/plat-omap/mailbox.c
> +++ b/arch/arm/plat-omap/mailbox.c
> @@ -31,7 +31,7 @@
>
> static struct workqueue_struct *mboxd;
> static struct omap_mbox *mboxes;
> -static DEFINE_RWLOCK(mboxes_lock);
> +static DEFINE_SPINLOCK(mboxes_lock);
>
> static int mbox_configured;
>
> @@ -330,14 +330,14 @@ struct omap_mbox *omap_mbox_get(const
> char *name)
> struct omap_mbox *mbox;
> int ret;
>
> - read_lock(&mboxes_lock);
> + spin_lock(&mboxes_lock);
> mbox = *(find_mboxes(name));
> if (mbox == NULL) {
> - read_unlock(&mboxes_lock);
> + spin_unlock(&mboxes_lock);
> return ERR_PTR(-ENOENT);
> }
>
> - read_unlock(&mboxes_lock);
> + spin_unlock(&mboxes_lock);
>
> ret = omap_mbox_startup(mbox);
> if (ret)
> @@ -363,15 +363,15 @@ int omap_mbox_register(struct device
> *parent, struct omap_mbox *mbox)
> if (mbox->next)
> return -EBUSY;
>
> - write_lock(&mboxes_lock);
> + spin_lock(&mboxes_lock);
> tmp = find_mboxes(mbox->name);
> if (*tmp) {
> ret = -EBUSY;
> - write_unlock(&mboxes_lock);
> + spin_unlock(&mboxes_lock);
> goto err_find;
> }
> *tmp = mbox;
> - write_unlock(&mboxes_lock);
> + spin_unlock(&mboxes_lock);
>
> return 0;
>
> @@ -384,18 +384,18 @@ int omap_mbox_unregister(struct
> omap_mbox *mbox) {
> struct omap_mbox **tmp;
>
> - write_lock(&mboxes_lock);
> + spin_lock(&mboxes_lock);
> tmp = &mboxes;
> while (*tmp) {
> if (mbox == *tmp) {
> *tmp = mbox->next;
> mbox->next = NULL;
> - write_unlock(
JFFS2 summary support : problem
Hi, I am working on TI OMAP3 platform and was looking to reduce the JFFS2 mount time (NAND). I have selected CONFIG_JFFS2_SUMMARY, but not working fully, its giving ECC error (at end of this email) after add a new file in JFFS2. Without this option its working fine; but taking long time to mount. Please let me know if I am missing anything -http://dev.omapzoom.org/pub/scm/integration/kernel-omap3.git [*] JFFS2 summary support (EXPERIMENTAL) i.e. CONFIG_JFFS2_SUMMARY=y => I have created and flushed jffs2 image with summary nodes, as- sumtool -n -e 0x2 -p -i rootdir.jffs2 -o rootdir-sum.jffs2 # mount -t jffs2 /dev/mtdblock4 /mnt JFFS2 notice: (640) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. # umount /mnt ==> I checked this multiple time and no issue. # # mount -t jffs2 /dev/mtdblock4 /mnt JFFS2 notice: (644) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. # vi /mnt/test.c (created a new file) # umount /mnt # mount -t jffs2 /dev/mtdblock4 /mnt mtd->read(0x1fb04 bytes from 0x8de04fc) returned ECC error mtd->read(0x9a74 bytes from 0x8df658c) returned ECC error Empty flash at 0x08df6588 ends at 0x08df6800 JFFS2 notice: (656) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. mtd->read(0x7bc bytes from 0x8df6844) returned ECC error Is there another way to fix the problem? Am I missing any patch or missing any configuration? Thanks & regards, Ghorai -- 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: [2.6.34-rc6] ARM: build breaks with KPROBES
> -Original Message- > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > Sent: Friday, April 30, 2010 1:18 PM > To: Shilimkar, Santosh > Cc: linux-arm-ker...@lists.infradead.org; Linux-OMAP > Subject: Re: [2.6.34-rc6] ARM: build breaks with KPROBES > > On Fri, Apr 30, 2010 at 12:51:49PM +0530, Shilimkar, Santosh wrote: > > Russell, > > > > The latest mainline ARM build breaks with KPROBES enabled. Anand > > Gadiyar did git bisect and figured out that below commit breaks the build. > > commit :4260415f6a3b92c5c986398d96c314df37a4ccbf > > Did you read the comments in the commit message to understand why > .previous is dangerous? > > > I tried matching the sections but failed to fix the build error. Below > > is the hack patch to keep build working. > > The previous section is not .text, but: > > #ifdef CONFIG_KPROBES > .section.kprobes.text,"ax",%progbits > #else > .text > #endif > > Either change the preceding .data to .pushsection .data, and the following > .text to .popsection, or duplicate the above ifdef; .pushsection/.popsection > is _far_ safer than using .previous. OK. Here is the updated patch based on your suggestion. >From 2660d4ca5d77406fc8d46a5c0f18127332914604 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar Date: Fri, 30 Apr 2010 12:41:16 +0530 Subject: [PATCH] ARM: Fix build break with KPROBES enabled With CONFIG_KPROBES enabled two section are getting created which leads to below build break. LOG: AS arch/arm/kernel/entry-armv.o arch/arm/kernel/entry-armv.S: Assembler messages: arch/arm/kernel/entry-armv.S:431: Error: symbol ret_from_exception is in a different section arch/arm/kernel/entry-armv.S:490: Error: symbol ret_from_exception is in a different section arch/arm/kernel/entry-armv.S:491: Error: symbol __und_usr_unknown is in a different section This was introduced by commit 4260415f6a3b92c5c986398d96c314df37a4ccbf Signed-off-by: Santosh Shilimkar Reported-by: Anand Gadiyar --- arch/arm/kernel/entry-armv.S |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index e6a0fb0..7ee48e7 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -676,10 +676,10 @@ do_fpe: * lr = unrecognised FP instruction return address */ - .data + .pushsection .data ENTRY(fp_enter) .word no_fp - .text + .popsection ENTRY(no_fp) mov pc, lr -- 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 02/14] omap: Make uncompress code and DEBUG_LL code generic
* Russell King - ARM Linux [100430 10:13]: > On Fri, Apr 30, 2010 at 12:20:35PM -0400, Cyril Chemparathy wrote: > > Hi, > > > > [...] > > > To fix both problems, maybe we should just use a fixed memory location > > > to pass this temporary data from uncompress to the kernel. We've had a > > > similar problem on DaVinci recently and a proposal has been made (and > > > tested) to use memory just below the page tables[3].) > > > > Essentially both of these approaches (internal scratch register and > > fixed address) implement a weird back-channel communication scheme > > between the decompresser and the debug macros. > > > > A more elegant solution may be as follows: > > - pass machine_arch_type as an argument into addruart. > > Unfortunately, that breaks addruart. Firstly, addruart is used from > assembly code where very limited registers are available (the fewer > registers it clobbers the less likely debug is going to cause stuff > to break.) Right, this would be tricky. > Secondly, the places that addruart may be called from, the location > of the machine type number is indeterminent. Remember that this > macro can be called when the MMU is on or off, and can be called > before the machine_arch_type has been initialized. Another good point here. > > - move the uart base lookup logic to addruart using macros similar > > to DEBUG_LL_*, except that these expand to assembly code this > > time. > > - reuse these debug-macros in uncompress.h and implement putc() and > > flush() using addruart(), senduart(), etc. > > Given what I've said above about the debug macros, this is definitely the > wrong solution. > > Having the decompressor macros work whatever the machine type is > reasonable, and the machine_is_xxx() macros already work at that point, > so there shouldn't be much of an issue there. Just to bring it up, there's one issue to consider here though. When the bootloader passes a wrong machine id, chances are things break with no debug output. > As far as the debug macros go, I think we're at the point where it's > basically just far easier to leave these macros as a developer debugging > tool and we'll just have to put up with it being something that an OMAP > developer has to edit according to his platform to make work. > > After all, _NO_ production kernel what so ever should be using this > debug support. Things work now for mach-omap2, but we assume the first uart is always in the same location. If this changes, then using some fixed memory location for storing the debug configuration is probably the best way to go considering the issues Russell mentioned. 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
omap-pm: omap3_pm_defconfig no longer booting on Overo
Since the rc5 tag, omap3_pm_defconfig from the pm branch no longer boots on the Gumstix Overo. I am certain that a build back in the rc3 days worked. Unfortunately, I don't know about rc4, or anything that happenend in the intervening time. Any clues on how to fix? If necessary, I'll provide what info I can to help diagnose the issue if told what to do. Peter Tseng -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: PM: Registering sgx device and it's platform data
Manjunatha GK writes: > The SGX powervr_device is registered with it's platform specific > data to provide information about setting constraint through > omap_pm_set_min_bus_tput. > > Signed-off-by: Preshit Agarwal > Signed-off-by: Manjunatha GK > Cc: Tony Lindgren > Cc: Kevin Hilman > Cc: Mike Turquette > Cc: Hemanth V Re: $SUBJECT, why the PM: prefix? Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM suspend to disk?
Peter Tseng writes: > I last posted a few weeks ago; I'm Peter Tseng, using the Gumstix Overo > for a project. I'm interested in power management and a few related > things. A few of the things I am interested in are suspend to disk and > snapshot boot. > > I found a page on elinux.org with a few notes on the issue for ARM. > However, it looks to be a bit outdated: > http://elinux.org/Suspend_To_Disk_For_ARM > > I am wondering how applicable anything on this page is to the current > omap-pm developments. Or, if not, any pointers on how it might be done - > for example, if I felt like I should do some hacking to try to get this > working and contribute these back, a general outline of what I might > have to do) Not really and answer to your question since I don't know the answer, but just curious about your goals, since there may be an easier way. What do you expect to gain from suspend-to-disk + snapshot boot that you don't already get from suspend-to-RAM using off-mode? On OMAP, with off-mode enabled, a suspend to RAM puts the entire OMAP into full-chip off, and essentially reboots the ARM when waking up from suspend (or idle) already. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] omap: mailbox cleanup: convert rwlocks to spinlock
On Thu, Apr 29, 2010 at 4:14 PM, Ohad Ben-Cohen wrote:
> Hi Hari,
>
> On Thu, Apr 29, 2010 at 3:44 PM, Kanigeri, Hari wrote:
>> Ohad,
>>
>> Looks like the conversion was missed in few places resulting in compile
>> warnings.
>
> Thanks for pointing that out - that's really strange, it somehow
> slipped in the rebase.
>
> The interesting part is that because you compile for OMAP4 (SMP),
> you got to see the warnings, while I didn't because I compiled for OMAP3
> (in the UP case there's no real locking and both types of locks are
> actually the same).
>
>>
>> Please see the below fix. Let me know if you agree with the change.
>
> Sure. I'll add that missing part back together with the review comments,
> and submit a v2 patchset.
If anyone needs the complete patch now, the original can be found here:
http://dev.omapzoom.org/?p=tisyslink/kernel-syslink.git;a=commitdiff;h=8da0385a57cc470ee0a013b164fd3d2438455e79
Thanks,
Ohad.
>
> Thanks again,
> Ohad.
>
>
>>
>> #
>> [PATCH] omap: mailbox: rwlocks to spinlock: compilation fix
>>
>> fixed the missed rwlocks in few places resultion in following
>> compiler warning.
>>
>> arch/arm/plat-omap/mailbox.c: In function 'omap_mbox_startup':
>> arch/arm/plat-omap/mailbox.c:246: warning: passing argument 1 of
>> '_raw_write_lock' from incompatible pointer type
>> arch/arm/plat-omap/mailbox.c:251: warning: passing argument 1 of
>> '_raw_write_unlock' from incompatible pointer type
>> arch/arm/plat-omap/mailbox.c:255: warning: passing argument 1 of
>> '_raw_write_unlock' from incompatible pointer type
>> arch/arm/plat-omap/mailbox.c: In function 'omap_mbox_fini':
>> arch/arm/plat-omap/mailbox.c:301: warning: passing argument 1 of
>> '_raw_write_lock' from incompatible pointer type
>> arch/arm/plat-omap/mailbox.c:306: warning: passing argument 1 of
>> '_raw_write_unlock' from incompatible pointer type
>>
>> Signed-off-by: Hari Kanigeri
>> ---
>> arch/arm/plat-omap/mailbox.c | 10 +-
>> 1 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
>> index 27a8d98..d6a700d 100644
>> --- a/arch/arm/plat-omap/mailbox.c
>> +++ b/arch/arm/plat-omap/mailbox.c
>> @@ -243,16 +243,16 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
>> struct omap_mbox_queue *mq;
>>
>> if (likely(mbox->ops->startup)) {
>> - write_lock(&mboxes_lock);
>> + spin_lock(&mboxes_lock);
>> if (!mbox_configured)
>> ret = mbox->ops->startup(mbox);
>>
>> if (unlikely(ret)) {
>> - write_unlock(&mboxes_lock);
>> + spin_unlock(&mboxes_lock);
>> return ret;
>> }
>> mbox_configured++;
>> - write_unlock(&mboxes_lock);
>> + spin_unlock(&mboxes_lock);
>> }
>>
>> ret = request_irq(mbox->irq, mbox_interrupt, IRQF_SHARED,
>> @@ -298,12 +298,12 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
>> free_irq(mbox->irq, mbox);
>>
>> if (likely(mbox->ops->shutdown)) {
>> - write_lock(&mboxes_lock);
>> + spin_lock(&mboxes_lock);
>> if (mbox_configured > 0)
>> mbox_configured--;
>> if (!mbox_configured)
>> mbox->ops->shutdown(mbox);
>> - write_unlock(&mboxes_lock);
>> + spin_unlock(&mboxes_lock);
>> }
>> }
>>
>> --
>>
>>
>>
>>> -Original Message-
>>> From: Ohad Ben-Cohen [mailto:o...@wizery.com]
>>> Sent: Tuesday, April 27, 2010 12:56 PM
>>> To: linux-omap@vger.kernel.org
>>> Cc: Kanigeri, Hari; Hiroshi Doyu; Ohad Ben-Cohen
>>> Subject: [PATCH 1/4] omap: mailbox cleanup: convert rwlocks
>>> to spinlock
>>>
>>> rwlocks are slower and have potential starvation issues so
>>> spinlocks are generally preferred
>>>
>>> Signed-off-by: Ohad Ben-Cohen
>>> ---
>>> arch/arm/plat-omap/mailbox.c | 20 ++--
>>> 1 files changed, 10 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/arch/arm/plat-omap/mailbox.c
>>> b/arch/arm/plat-omap/mailbox.c index 08a2df7..d73d51a 100644
>>> --- a/arch/arm/plat-omap/mailbox.c
>>> +++ b/arch/arm/plat-omap/mailbox.c
>>> @@ -31,7 +31,7 @@
>>>
>>> static struct workqueue_struct *mboxd;
>>> static struct omap_mbox *mboxes;
>>> -static DEFINE_RWLOCK(mboxes_lock);
>>> +static DEFINE_SPINLOCK(mboxes_lock);
>>>
>>> static int mbox_configured;
>>>
>>> @@ -330,14 +330,14 @@ struct omap_mbox *omap_mbox_get(const
>>> char *name)
>>> struct omap_mbox *mbox;
>>> int ret;
>>>
>>> - read_lock(&mboxes_lock);
>>> + spin_lock(&mboxes_lock);
>>> mbox = *(find_mboxes(name));
>>> if (mbox == NULL) {
>>> - read_unlock(&mboxes_lock);
>>> + spin_unlock(&mboxes_lock);
>>> return ERR_PTR(-ENOENT);
>>> }
>>>
>>> - read_unlock
[PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature
>From 1c63dd42fc6c563c931168779ce73401332faa52 Mon Sep 17 00:00:00 2001
From: Venkatraman S
Date: Thu, 29 Apr 2010 22:43:31 +0530
Subject: [PATCH 2/2] omap hsmmc: adaptation of sdma descriptor
autoloading feature
Start to use the sDMA descriptor autoloading feature.
For large datablocks, the MMC driver has to repeatedly setup,
program and teardown the dma channel for each element of the
sglist received in omap_hsmmc_request.
By using descriptor autoloading, transfers from / to each element of
the sglist is pre programmed into a linked list. The sDMA driver
completes the entire transaction and provides a single interrupt.
Due to this, number of dma interrupts for a typical 100MB transfer on the MMC is
reduced from 25000 to about 400 (approximate). Transfer speeds are
improved by ~5%.
(Though it varies on the size of read / write & improves on huge transfers)
Descriptor autoloading is available only in 3630 and 4430 (as of now).
Hence normal DMA mode is also retained.
Signed-off-by: Venkatraman S
CC: Adrian Hunter
CC: Madhusudhan C
CC: Shilimkar Santosh
CC: Tony Lindgren
---
Changes since previous version
* Rebased to Adrian Hunter's interrupt syncronisation patch
https://patchwork.kernel.org/patch/94670/
* Rename ICR name definition
drivers/mmc/host/omap_hsmmc.c | 148 ++--
1 files changed, 125 insertions(+), 23 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 65093d4..095fd94 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -102,6 +102,8 @@
#define SRD(1 << 26)
#define SOFTRESET (1 << 1)
#define RESETDONE (1 << 0)
+/* End of superblock indicator for sglist transfers */
+#define DMA_ICR_SGLIST_END 0x4D00
/*
* FIXME: Most likely all the data using these _DEVID defines should come
@@ -118,6 +120,12 @@
#define OMAP_MMC_MASTER_CLOCK 9600
#define DRIVER_NAME"mmci-omap-hs"
+#define DMA_TYPE_NODMA 0
+#define DMA_TYPE_SDMA 1
+#define DMA_TYPE_SDMA_DLOAD 2
+
+#define DMA_CTRL_BUF_SIZE (PAGE_SIZE * 3)
+
/* Timeouts for entering power saving states on inactivity, msec */
#define OMAP_MMC_DISABLED_TIMEOUT 100
#define OMAP_MMC_SLEEP_TIMEOUT 1000
@@ -170,7 +178,11 @@ struct omap_hsmmc_host {
u32 bytesleft;
int suspended;
int irq;
- int use_dma, dma_ch;
+ int dma_caps;
+ int dma_in_use;
+ int dma_ch;
+ void*dma_ctrl_buf;
+ dma_addr_t dma_ctrl_buf_phy;
int dma_line_tx, dma_line_rx;
int slot_id;
int got_dbclk;
@@ -527,7 +539,7 @@ static void omap_hsmmc_enable_irq(struct
omap_hsmmc_host *host)
{
unsigned int irq_mask;
- if (host->use_dma)
+ if (host->dma_in_use)
irq_mask = INT_EN_MASK & ~(BRR_ENABLE | BWR_ENABLE);
else
irq_mask = INT_EN_MASK;
@@ -813,7 +825,7 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
*host, struct mmc_command *cmd,
cmdreg &= ~(DDIR);
}
- if (host->use_dma)
+ if (host->dma_in_use)
cmdreg |= DMA_EN;
host->req_in_progress = 1;
@@ -842,7 +854,7 @@ static void omap_hsmmc_request_done(struct
omap_hsmmc_host *host, struct mmc_req
omap_hsmmc_disable_irq(host);
/* Do not complete the request if DMA is still in progress */
- if (mrq->data && host->use_dma && dma_ch != -1)
+ if (mrq->data && host->dma_in_use && dma_ch != -1)
return;
host->mrq = NULL;
mmc_request_done(host->mmc, mrq);
@@ -920,7 +932,7 @@ static void omap_hsmmc_dma_cleanup(struct
omap_hsmmc_host *host, int errno)
host->dma_ch = -1;
spin_unlock(&host->irq_lock);
- if (host->use_dma && dma_ch != -1) {
+ if (host->dma_in_use && dma_ch != -1) {
dma_unmap_sg(mmc_dev(host->mmc), host->data->sg, host->dma_len,
omap_hsmmc_get_dma_dir(host, host->data));
omap_free_dma(dma_ch);
@@ -1266,7 +1278,6 @@ static void omap_hsmmc_config_dma_params(struct
omap_hsmmc_host *host,
omap_hsmmc_get_dma_sync_dev(host, data),
!(data->flags & MMC_DATA_WRITE));
- omap_start_dma(dma_ch);
}
/*
@@ -1279,21 +1290,23 @@ static void omap_hsmmc_dma_cb(int lch, u16
ch_status, void *cb_data)
int dma_ch, req_in_progress;
if (ch_status & OMAP2_DMA_MISALIGNED_ERR_IRQ)
- dev_dbg(mmc_dev(host->mmc), "MISALIGNED_ADRS_ERR\n");
+ dev_dbg(mmc_dev(host->mmc), "Misaligned address error\n");
spin_lock(&host->irq_lock);
if (host->dma_ch < 0) {
[PATCH v8 1/2] sDMA: descriptor autoloading feature
>From d46f8a00728cc6c1fbdfce69435759c8cc49f25c Mon Sep 17 00:00:00 2001
From: Venkatraman S
Date: Thu, 29 Apr 2010 22:34:04 +0530
Subject: [PATCH 1/2] sDMA: descriptor autoloading feature
Add sDMA driver support for descriptor autoloading feature.
Descriptor autoloading is OMAP sDMA v5 hardware capability that can
be exploited for scatter gather
scenarios, currently available in OMAP3630 and OMAP4430.
The feature works as described below.
1) A sDMA channel is programmed to be in 'linked list' mode.
2) The client (sDMA user) provides a list of descriptors in a linked
list format.
3) Each of the 'descriptor' (element in the linked list) contains an
updated set of DMA
configuration register values.
4) Client starts DMA transfer.
5) sDMA controller loads the first element to its register
configuration memory and executes the
transfer.
6) After completion, loads the next element (in linked list) to
configuration memory and executes
the transfer, without MCU intervention.
7) Interrupt is generated after all transfers are completed; this
can be configured to be done
differently.
Configurations and additional features
1) Fast mode & non-fast mode
Fast mode/non-fast decides on how the first transfer begins.
In non-fast mode, the first
element in the linked list is loaded only after completing the
transfer according to the
configurations already in the sDMA channel registers. In fast mode,
the loading of the first
element precedes the transfer.
2) Pause / resume of transfers
A transfer can be paused after a descriptor set has been loaded,
provided the 'pause
bit' is set in the linked list element.
An ongoing transfer cannot be paused. If the 'pause bit' is set,
transfer is not
started after loading the register set from memory.
Such a transfer can be resumed later.
3) Descriptor types
3 possible configurations of descriptors (initialized as linked list
elements)
are possible. Type 1 provides the maximum flexibility, which contains
most
register definitions of a DMA logical channel. Fewer options are
present in type
2. Type 3 can just modify source/destinations address of transfers. In
all
transfers, unmodified registers settings are maintained for the next
transfer.
Patch provides options / API for
1) Setting up a descriptor loading for DMA channel for sg type
transfers
2) configuration with linked list elements
3) Starting / pause and resume of the said transfers, query state
4) Clearing the sglist mode
Signed-off-by: Venkatraman S
CC: Adrian Hunter
CC: Madhusudhan C
CC: Shilimkar Santosh
CC: Tony Lindgren
---
Changes from v7:
* Added wmb() calls between descriptor data structure update and
start/resume of transfer
* Added proper commit log about the feature
arch/arm/plat-omap/dma.c | 289 -
arch/arm/plat-omap/include/plat/dma.h | 170 +++
2 files changed, 458 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index f6c9bdc..d8d4df8 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -46,12 +46,40 @@ enum { DMA_CH_ALLOC_DONE, DMA_CH_PARAMS_SET_DONE,
DMA_CH_STARTED,
enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
#endif
+/* CDP Register bitmaps */
+#define DMA_LIST_CDP_DST_VALID (BIT(0))
+#define DMA_LIST_CDP_SRC_VALID (BIT(2))
+#define DMA_LIST_CDP_TYPE1 (BIT(4))
+#define DMA_LIST_CDP_TYPE2 (BIT(5))
+#define DMA_LIST_CDP_TYPE3 (BIT(4) | BIT(5))
+#define DMA_LIST_CDP_PAUSEMODE (BIT(7))
+#define DMA_LIST_CDP_LISTMODE (BIT(8))
+#define DMA_LIST_CDP_FASTMODE (BIT(10))
+/* CAPS register bitmaps */
+#define DMA_CAPS_SGLIST_SUPPORT(BIT(20))
+
+#define DMA_LIST_DESC_PAUSE(BIT(0))
+#define DMA_LIST_DESC_SRC_VALID(BIT(24))
+#define DMA_LIST_DESC_DST_VALID(BIT(26))
+#define DMA_LIST_DESC_BLK_END (BIT(28))
+
#define OMAP_DMA_ACTIVE0x01
#define OMAP2_DMA_CSR_CLEAR_MASK 0xffe
#define OMAP_FUNC_MUX_ARM_BASE (0xfffe1000 + 0xec)
+#define OMAP_DMA_INVALID_FRAME_COUNT (0x)
+#define OMAP_DMA_INVALID_ELEM_COUNT(0xff)
+#define OMAP_DMA_INVALID_DESCRIPTOR_POINTER(0xfffc)
static int enable_1510_mode;
+static int dma_caps0_status;
+
+struct omap_dma_list_config_params {
+ unsigned int num_elem;
+ struct omap_dma_sglist_node *sghead;
+ dma_addr_t sgheadphy;
+ unsigned int pausenode;
+};
static struct omap_dma_global_context_registers {
u32 dma_irqenable_l0;
@@ -74,9 +102,10 @@ struct omap_dma_lch {
int next_linked_ch;
int state;
int chain_id;
-
int status;
+ struct omap_dma_list_config_params list_config;
#endif
+
long flags;
};
@@ -214,6 +243,76 @@ static void clear_lch_regs(int lch)
Re: [PATCH] OMAP3EVM: Update pad configuration for wakeup enabled pads
Ranjith Lohithakshan writes: > On Wed, 28-Apr-10 11:53 PM +0530, Kevin Hilman wrote: >> Ranjith Lohithakshan writes: >> >>> Kevin, >>> >>> On Tue, 27-Apr-10 8:46 PM +0530, Kevin Hilman wrote: Ranjith Lohithakshan writes: > OMAP3530 TRM section 7.4.4.4.2 requires OFFOUTENABLE to be set (active > low) > if wakeup capabilities are enabled on a pad. During OFF mode testing > on OMAP3530 EVM, it was observed that the device was not residing in > the OFF state. The device enters into the OFF state and immediately exits > from that state as if an IO wakeup event has occured. The issue was traced > down to the pad configuration of wkaeup enabled pad's. Nice. > Also, the pad configuration is included only if the respective drivers are > enabled in the defconfig. Hmm, do you really want this? If you don't have the driver enabled, you have to rely on the bootloader settings of these pads which may also be wrong and trigger an IO wakeup as well. >>> The thought process was that, for example, if keypad is not enabled >>> in a system configuration you probably don't want to see a wakeup >>> occurring if someone presses a key stroke. I understand the concern >>> that you have raised regarding bootloader mis-configurations. My >>> impression was that the bootloaders typically set the mux modes and >>> pull up's/downs and dont really program or enable the wakeup >>> capability. But we cannot depend on that thumb rule. >> >> Unfortunately, Bootloaders don't "typically" do anything. They are >> routinely hacked/patched and cannot be trusted at all. >> >>> What is your recommendation? >> >> First, I suggest you fix the OFFOUTENABLE bug in a single patch >> without introducing the #ifdefs. Then, address the enable/disable of >> the wakeups in a separate patch. > > I will do that. > >> Next, ideally wakeups should not be configured a this level of board >> code. There are APIs for that: enable_irq_wake()/disable_irq_wake() >> >> For GPIOs (like the touchscreen), you really need to enable wakeups >> using existing APIs, either in the driver or in board init code and be >> sure there is an interrupt handler. Please see the 'Known Problems' >> section of the OMAP PM wiki[2] where it talks about GPIO wakeups. >> Below[2] is an test patch I've used. > > I have pushed a patch on ads7846 to linux-input some time ago adding > wakeup support. > > fdba2bb : Input: ads7846 - add wakeup support > > There is now a wakeup flag added to the ads7846 platform data which can > enabled at the board level. Once this is set , the driver will do an > enable_irq_wake. The patch is now accepted and in mainline. I will > remove the wakeup mux configuration from the board file and instead will > just set the wakeup flag in the ads7846 platform data. Brilliant! you're several steps ahead of me. Would you mind submitting a patch to l-o to enable that for SDP and omap3evm so I can drop my suggested patch? > The keypad uses a pin in the non-gpio mode. Is enable_irq_wake supported > for non-gpio mode? Not currently, as enable_irq_wake() ends up calling into the irq_chip's set_wake() method. This then calls into the OMAP GPIO layer as plat-omap/gpio.c:gpio_wake_enable() For now, the keypad could just use the mux API at runtime like SDP does to enable wakeups when needed. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] DSPBRIDGE: use dm timer framework for gpt timers
Benoit Cousson writes: > On 4/28/2010 10:50 PM, Kevin Hilman wrote: >> Nishanth Menon writes: >> >>> Kevin Hilman had written, on 04/28/2010 12:59 PM, the following: Omar Ramirez Luna writes: > On 4/28/2010 11:36 AM, Menon, Nishanth wrote: >> Kevin Hilman had written, on 04/28/2010 11:29 AM, the following: >>> Omar Ramirez Luna writes: >>> On 4/28/2010 2:46 AM, Felipe Contreras wrote: > On Wed, Apr 28, 2010 at 4:29 AM, Omar Ramirez > Lunawrote: >> This patch switches to use DM timer framework instead of >> a custom one for GPT timers, currently dsp can make use of >> gpt 5, 6, 7 or 8. > I heard someone that was using gpt 8 for something else. Is it > possible to configure dsp-bridge to not use it? > There are two scenarios: 1. The request comes from the DSP side (afaik for video use case), the change should be in the DSP side binaries to request some other gpt instead. I don't know how possible is to get this changed. 2. bridge driver also requests gpt8 whenever a mmu fault is triggered, this to set a timer to interrupt the dsp after the mmu fault dump has been finished, I think this can be easily replaced in bridge to use some other gpt, but "1" is still there. (besides a new patch is needed to remove direct access to dm timer inside ue_deh and make it to go through dsp-clock) >>> Why does Bridge care at all which specific timers it requests? They >>> are all the same, with the exception of GPT1 which is in the WKUP >>> powerdomain and already used as the kernel clocksource. >>> >>> Bridge should just use the generic _request() instead of >>> _request_specific() >>> >> trouble I believe is that DSP BIOS uses a specific timer. >> > yes, dsp side wants: > bios --> GPT5 (only used during boot up -> baseimage load) > load monitoring --> GPT 6 (used while the dsp is awake) > AV Sync --> GPT 8 (based on use case) > > to generate the interrupt for mmu fault case it needs one connected to > the dsp interrupt line and only 5, 6, 7 or 8 apply. Then DSP bios is broken by hard-coding *general purpose* timers. >>> /me just eats my own words. >>> Not really.. I just got educated internally that DSP does not get >>> interrupts from all GPTs. >>> Ref: http://focus.ti.com/pdfs/wtbu/SWPU114Q_PrelimFinal_EPDF_03_05_2009.pdf >>> page 1753 -> only mentioned these timers can generate interrupts for >>> DSP, and hence for BIOS's usage. >> >> OK, now that part makes sense. > > This issue will be even worse on OMAP4 with the CortexM3 (aka Ducati), > because several IPs like GPIO or GPTIMER will have different IRQ / > functionality / power partitioning depending of the instance. > One of the proposed solution we considered, at least for the GPTIMERs, > was to add an extra API that can allow to request a timer based on the > needed capabilities and not based on index. > > We can easily encode in each GPTIMER HWMOD the specificity of an > instance like (HAS_DSP_IRQ, HAS_IPU_IRQ, HAS_PWM, IN_WKUP_DOMAIN, > IN_AUDIO_DOMAIN...). > Driver can then use a request_timer_per_functionalies(HAS_DSP_IRQ | > HAS_IPU_IRQ...). > It will allow driver to be much more independent of the current IP > implementation for an OMAP version. > > Any thoughts? Yes, this sounds much better. It makes a lot more sense than hard-coding specific GPT numbers. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 0/2] sDMA descriptor autoloading feature
This patch series is the introduction of new sDMA feature: descriptor autoloading (v8) and it's adoption by the OMAP HSMMC driver. The previous version (v7) was blocked on achieving proper interrupt syncronisation between the MMC and DMA callback in the HSMMC driver. Thanks to Adrian Hunter's patch, https://patchwork.kernel.org/patch/94670/ this has been cleaned up. Current version is based on for-next branch + Adrian Hunter's interrupt syncronisation patch (https://patchwork.kernel.org/patch/94670) Changes since v7: * Removed the 'fix race condition between DMA and HSMMC callback' part of the series * Added memory barries in start and resume sglist transfer for cpu buffer syncronization * Cleanup and comments This has been tested on OMAP3430, OMAP3630 and OMAP4430 SDP for MMC file transfer and as boot file system. Venkatraman S: sDMA: descriptor autoloading feature MMC: omap hsmmc adoption of descriptor autoloading feature arch/arm/plat-omap/dma.c | 289 - arch/arm/plat-omap/include/plat/dma.h | 170 +++ drivers/mmc/host/omap_hsmmc.c | 148 ++--- 3 files changed, 583 insertions(+), 24 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3: PM: Registering sgx device and it's platform data
The SGX powervr_device is registered with it's platform specific
data to provide information about setting constraint through
omap_pm_set_min_bus_tput.
Signed-off-by: Preshit Agarwal
Signed-off-by: Manjunatha GK
Cc: Tony Lindgren
Cc: Kevin Hilman
Cc: Mike Turquette
Cc: Hemanth V
---
arch/arm/mach-omap2/devices.c | 26 ++-
arch/arm/mach-omap2/include/mach/omap_sgxdef.h | 11 ++
2 files changed, 35 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-omap2/include/mach/omap_sgxdef.h
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2271b9b..b624f13 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -26,7 +26,7 @@
#include
#include
#include
-
+#include
#include "mux.h"
#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
@@ -786,6 +786,28 @@ static inline void omap_hdq_init(void)
static inline void omap_hdq_init(void) {}
#endif
+struct sgx_platform_data omap_sgx_data = {
+#ifdef CONFIG_PM
+ .set_min_bus_tput = omap_pm_set_min_bus_tput,
+#else
+ .set_min_bus_tput = NULL;
+#endif
+};
+
+static struct platform_device powervr_device = {
+ .name= "pvrsrvkm",
+ .id = -1,
+ .dev= {
+ .platform_data = &omap_sgx_data,
+ }
+};
+
+static void omap_init_sgx(void)
+{
+ (void) platform_device_register(&powervr_device);
+}
+
+
/*-*/
static int __init omap2_init_devices(void)
@@ -800,7 +822,7 @@ static int __init omap2_init_devices(void)
omap_hdq_init();
omap_init_sti();
omap_init_sha1_md5();
-
+ omap_init_sgx();
return 0;
}
arch_initcall(omap2_init_devices);
diff --git a/arch/arm/mach-omap2/include/mach/omap_sgxdef.h
b/arch/arm/mach-omap2/include/mach/omap_sgxdef.h
new file mode 100644
index 000..5d90a6a
--- /dev/null
+++ b/arch/arm/mach-omap2/include/mach/omap_sgxdef.h
@@ -0,0 +1,11 @@
+#ifndef OMAP_SGXDEF_H
+#define OMAP_SGXDEF_H
+
+#include
+
+struct sgx_platform_data {
+ void(*set_min_bus_tput)(struct device *dev, u8 agent_id,
+ unsigned long r);
+};
+
+#endif
--
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: [PATCHv3 00/22] OMAP3: PM: Smartreflex and voltage revamp
"Gopinath, Thara" writes: >>>-Original Message- >>>From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >>>Sent: Wednesday, April 28, 2010 12:48 AM >>>To: Gopinath, Thara >>>Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, >>>Vishwanath; Sawant, Anand >>>Subject: Re: [PATCHv3 00/22] OMAP3: PM: Smartreflex and voltage revamp >>> >>>Thara Gopinath writes: >>> The main motivations behind this patch series are the following 1. Making smartreflex a platform driver with omap-device layer. 2. Separating voltage specific code from smartreflex.c and other locations and consolidating them into voltage.c and voltage.h. 3. Smartreflex module can have Class 1 Class 2 or Class 3 implementations depending on the PMIC in use. Making smartreflex.c capable of handling both the Class 2 and 3 implementaions and separating out class specific code into a separate class driver. 4. Remove dependencies on opp id in the smartreflex and voltage drivers 5. Implementating latest TI recommended register settings for Smartreflex and Voltage processor module as well as recommended sequences for enabling and disabling of Smartreflex and Voltage processor modules. 6. Implementing VP force update method of voltage scaling which is again TI hardware recommended. What this patch series does not address are 1. Separating PMIC specific portions from smartreflex and voltage code. 2. OMAP3630 and OMP4 smartreflex support. This patch series is based on Kevin's PM tree origin/pm-wip-opp branch and is dependent on the following patches not yet applied onto this branch. http://patchwork.kernel.org/patch/81504/ http://patchwork.kernel.org/patch/81606/ This patch series has been tested on OMAP3430 SDP with basic power management tests including the dvfs scripts. >>> >>>First some general comments... >>> >>>- check multi-line comment style >>> >>>- use of dev_err() instead of pr_err() (or dev_* instead of pr_*) >>> wherever you have a valid platform_device. This will print messages >>> with the specific SR device name so you get more detailed messages. >>> It will also avoid you having to use sr_info->srid since that >>> number is already part of the device name. >>> >>>And now, IMHO, this is getting close enough, where I think it's >>>getting mostly ready for submission upstream. To that end, I think >>>it's time to start creating this series against mainline, instead of >>>against the PM branch. >>> >>>This is basically a rewrite, so I think it makes sense to breifly >>>summarize the history in the first patch, but then build from scratch >>>against mainline (except for SRF changes which will have to be a >>>separate series based on the PM branch.) >>> >>>As it is, the series is getting hard to follow as there are several >>>things that are cleaned up from the old code and then removed later in >>>the series etc. For that reason, I'd now like to see this as a fresh >>>series against mainline. >>> >>>Actually, currnely it will have to be based on my pm-vc branch which >>>is a small series of VC init/setup patches that I'll be queueing for >>>2.6.35, but itself is based on mainline. >>> >>>The SR series could broken up as follows (only a suggestion) >>> >>>- Creation of voltage layer: current pm-vc branch + voltage.c >>> >>>- Creation of device/platform init: hwmods, sr_device.c >>> >>>- Creation of driver: smartreflex*.[ch], sr_device.c > > Kevin, > > I could create this series against mainline but I need OPP layer for voltage > layer.. > Ah, yes. Sorry. Please create against pm-opp, which is based on mainline. I am working on reorganizing pm-opp for upstream. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6.34-rc6] ARM: build breaks with KPROBES
Russell, The latest mainline ARM build breaks with KPROBES enabled. Anand Gadiyar did git bisect and figured out that below commit breaks the build. commit :4260415f6a3b92c5c986398d96c314df37a4ccbf I tried matching the sections but failed to fix the build error. Below is the hack patch to keep build working. Regards, Santosh *** ARM: Build break with KPROBES enabled With CONFIG_KPROBES enabled two section are getting created which leads to below buid break. LOG: AS arch/arm/kernel/entry-armv.o arch/arm/kernel/entry-armv.S: Assembler messages: arch/arm/kernel/entry-armv.S:431: Error: symbol ret_from_exception is in a different section arch/arm/kernel/entry-armv.S:490: Error: symbol ret_from_exception is in a different section arch/arm/kernel/entry-armv.S:491: Error: symbol __und_usr_unknown is in a different section Signed-off-by: Santosh Shilimkar Reported-by: Anand Gadiyar --- arch/arm/kernel/entry-armv.S |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index e6a0fb0..db4ec05 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -679,7 +679,7 @@ do_fpe: .data ENTRY(fp_enter) .word no_fp - .text + .previous ENTRY(no_fp) mov pc, lr -- 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 1/4] omap: mailbox cleanup: convert rwlocks to spinlock
Hi Hari,
On Thu, Apr 29, 2010 at 3:44 PM, Kanigeri, Hari wrote:
> Ohad,
>
> Looks like the conversion was missed in few places resulting in compile
> warnings.
Thanks for pointing that out - that's really strange, it somehow
slipped in the rebase.
The interesting part is that because you compile for OMAP4 (SMP),
you got to see the warnings, while I didn't because I compiled for OMAP3
(in the UP case there's no real locking and both types of locks are
actually the same).
>
> Please see the below fix. Let me know if you agree with the change.
Sure. I'll add that missing part back together with the review comments,
and submit a v2 patchset.
Thanks again,
Ohad.
>
> #
> [PATCH] omap: mailbox: rwlocks to spinlock: compilation fix
>
> fixed the missed rwlocks in few places resultion in following
> compiler warning.
>
> arch/arm/plat-omap/mailbox.c: In function 'omap_mbox_startup':
> arch/arm/plat-omap/mailbox.c:246: warning: passing argument 1 of
> '_raw_write_lock' from incompatible pointer type
> arch/arm/plat-omap/mailbox.c:251: warning: passing argument 1 of
> '_raw_write_unlock' from incompatible pointer type
> arch/arm/plat-omap/mailbox.c:255: warning: passing argument 1 of
> '_raw_write_unlock' from incompatible pointer type
> arch/arm/plat-omap/mailbox.c: In function 'omap_mbox_fini':
> arch/arm/plat-omap/mailbox.c:301: warning: passing argument 1 of
> '_raw_write_lock' from incompatible pointer type
> arch/arm/plat-omap/mailbox.c:306: warning: passing argument 1 of
> '_raw_write_unlock' from incompatible pointer type
>
> Signed-off-by: Hari Kanigeri
> ---
> arch/arm/plat-omap/mailbox.c | 10 +-
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
> index 27a8d98..d6a700d 100644
> --- a/arch/arm/plat-omap/mailbox.c
> +++ b/arch/arm/plat-omap/mailbox.c
> @@ -243,16 +243,16 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
> struct omap_mbox_queue *mq;
>
> if (likely(mbox->ops->startup)) {
> - write_lock(&mboxes_lock);
> + spin_lock(&mboxes_lock);
> if (!mbox_configured)
> ret = mbox->ops->startup(mbox);
>
> if (unlikely(ret)) {
> - write_unlock(&mboxes_lock);
> + spin_unlock(&mboxes_lock);
> return ret;
> }
> mbox_configured++;
> - write_unlock(&mboxes_lock);
> + spin_unlock(&mboxes_lock);
> }
>
> ret = request_irq(mbox->irq, mbox_interrupt, IRQF_SHARED,
> @@ -298,12 +298,12 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
> free_irq(mbox->irq, mbox);
>
> if (likely(mbox->ops->shutdown)) {
> - write_lock(&mboxes_lock);
> + spin_lock(&mboxes_lock);
> if (mbox_configured > 0)
> mbox_configured--;
> if (!mbox_configured)
> mbox->ops->shutdown(mbox);
> - write_unlock(&mboxes_lock);
> + spin_unlock(&mboxes_lock);
> }
> }
>
> --
>
>
>
>> -Original Message-
>> From: Ohad Ben-Cohen [mailto:o...@wizery.com]
>> Sent: Tuesday, April 27, 2010 12:56 PM
>> To: linux-omap@vger.kernel.org
>> Cc: Kanigeri, Hari; Hiroshi Doyu; Ohad Ben-Cohen
>> Subject: [PATCH 1/4] omap: mailbox cleanup: convert rwlocks
>> to spinlock
>>
>> rwlocks are slower and have potential starvation issues so
>> spinlocks are generally preferred
>>
>> Signed-off-by: Ohad Ben-Cohen
>> ---
>> arch/arm/plat-omap/mailbox.c | 20 ++--
>> 1 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm/plat-omap/mailbox.c
>> b/arch/arm/plat-omap/mailbox.c index 08a2df7..d73d51a 100644
>> --- a/arch/arm/plat-omap/mailbox.c
>> +++ b/arch/arm/plat-omap/mailbox.c
>> @@ -31,7 +31,7 @@
>>
>> static struct workqueue_struct *mboxd;
>> static struct omap_mbox *mboxes;
>> -static DEFINE_RWLOCK(mboxes_lock);
>> +static DEFINE_SPINLOCK(mboxes_lock);
>>
>> static int mbox_configured;
>>
>> @@ -330,14 +330,14 @@ struct omap_mbox *omap_mbox_get(const
>> char *name)
>> struct omap_mbox *mbox;
>> int ret;
>>
>> - read_lock(&mboxes_lock);
>> + spin_lock(&mboxes_lock);
>> mbox = *(find_mboxes(name));
>> if (mbox == NULL) {
>> - read_unlock(&mboxes_lock);
>> + spin_unlock(&mboxes_lock);
>> return ERR_PTR(-ENOENT);
>> }
>>
>> - read_unlock(&mboxes_lock);
>> + spin_unlock(&mboxes_lock);
>>
>> ret = omap_mbox_startup(mbox);
>> if (ret)
>> @@ -363,15 +363,15 @@ int omap_mbox_register(struct device
>> *parent, struct omap_mbox *mbox)
>> if (mbox->next)
>> return -EBUSY;
>>
>> - write_lock(&mboxes_lock);
>> + spin_lock(&mboxes_lock);
>> tmp = find_mboxes(mbox->name);
>> if (*tmp) {
>>
Possible bug in onenand_base ?
Hello all,
After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
Flex-OneNAND support) the onenand support for my device is broken.
Before this commit when I run the nandtest program all is ok
---
# nandtest /dev/mtd3
ECC corrections: 0
ECC failures : 0
Bad blocks : 0
BBT blocks : 0
002c: checking...
Finished pass 1 successfully
--
Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
fails with:
---
# nandtest /dev/mtd3
ECC corrections: 0
ECC failures : 0
Bad blocks : 0
BBT blocks : 0
: reading...
[ 299.092041] onenand_wait: ECC error = 0x8488
( ... lots of ECC errors ... )
[ 299.092041] onenand_wait: ECC error = 0x8488
ECC failed at
: checking...
compare failed. seed 1804289383
Byte 0x1 is 5a should be da
Byte 0x3 is 82 should be 92
Byte 0x4 is 10 should be 1a
( ... )
---
Investigating a little I see a significant difference introduced by
this patch. In line
347:page = (int) (addr - onenand_addr(this, block)) >>
this->page_shift; (patch applied)
instead of
347:page = (int) (addr >> this->page_shift); (without patch)
I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
the line 347 and now works again. Fantastic, but I suspect this is not
the proper solution (probably this breaks other onenands devices, I
can't test).
I'm just introducing in OneNAND devices so anyone can help me to
understand and solve the problem ? Note that my device is a Numonyx
4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
page )
Thanks in advance,
///:~Enric
---
diff --git a/drivers/mtd/onenand/onenand_base.c
b/drivers/mtd/onenand/onenand_base.c
index 081f97d..b1d50a3 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
int cmd, loff_t addr, size_t le
default:
block = (int) onenand_block(this, addr);
- page = (int) (addr - onenand_addr(this, block)) >>
this->page_shift;
+ page = (int) (addr >> this->page_shift);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
---
--
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 00/22] OMAP3: PM: Smartreflex and voltage revamp
>>-Original Message- >>From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >>Sent: Wednesday, April 28, 2010 12:48 AM >>To: Gopinath, Thara >>Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, >>Vishwanath; Sawant, Anand >>Subject: Re: [PATCHv3 00/22] OMAP3: PM: Smartreflex and voltage revamp >> >>Thara Gopinath writes: >> >>> The main motivations behind this patch series are the following >>> 1. Making smartreflex a platform driver with omap-device layer. >>> 2. Separating voltage specific code from smartreflex.c and other >>>locations and consolidating them into voltage.c and voltage.h. >>> 3. Smartreflex module can have Class 1 Class 2 or Class 3 implementations >>>depending on the PMIC in use. Making smartreflex.c capable >>>of handling both the Class 2 and 3 implementaions and separating out >>>class specific code into a separate class driver. >>> 4. Remove dependencies on opp id in the smartreflex and >>>voltage drivers >>> 5. Implementating latest TI recommended register settings for >>> Smartreflex and Voltage processor module as well as recommended >>> sequences for enabling and disabling of Smartreflex and Voltage >>> processor modules. >>> 6. Implementing VP force update method of voltage scaling which is >>>again TI hardware recommended. >>> >>> What this patch series does not address are >>> 1. Separating PMIC specific portions from smartreflex and voltage code. >>> 2. OMAP3630 and OMP4 smartreflex support. >>> >>> This patch series is based on Kevin's PM tree origin/pm-wip-opp branch >>> and is dependent on the following patches not yet applied onto this branch. >>> >>> http://patchwork.kernel.org/patch/81504/ >>> http://patchwork.kernel.org/patch/81606/ >>> >>> This patch series has been tested on OMAP3430 SDP with basic power >>> management tests including the dvfs scripts. >> >>First some general comments... >> >>- check multi-line comment style >> >>- use of dev_err() instead of pr_err() (or dev_* instead of pr_*) >> wherever you have a valid platform_device. This will print messages >> with the specific SR device name so you get more detailed messages. >> It will also avoid you having to use sr_info->srid since that >> number is already part of the device name. >> >>And now, IMHO, this is getting close enough, where I think it's >>getting mostly ready for submission upstream. To that end, I think >>it's time to start creating this series against mainline, instead of >>against the PM branch. >> >>This is basically a rewrite, so I think it makes sense to breifly >>summarize the history in the first patch, but then build from scratch >>against mainline (except for SRF changes which will have to be a >>separate series based on the PM branch.) >> >>As it is, the series is getting hard to follow as there are several >>things that are cleaned up from the old code and then removed later in >>the series etc. For that reason, I'd now like to see this as a fresh >>series against mainline. >> >>Actually, currnely it will have to be based on my pm-vc branch which >>is a small series of VC init/setup patches that I'll be queueing for >>2.6.35, but itself is based on mainline. >> >>The SR series could broken up as follows (only a suggestion) >> >>- Creation of voltage layer: current pm-vc branch + voltage.c >> >>- Creation of device/platform init: hwmods, sr_device.c >> >>- Creation of driver: smartreflex*.[ch], sr_device.c Kevin, I could create this series against mainline but I need OPP layer for voltage layer.. Regards, Thara >>These should each have a brief summary of history and main >>contributors, but you as primary author. >> >>Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: PM: Fix compilation error observed when cpufreq is disabled
On Thu, 29-Apr-10 3:00 AM +0530, Kevin Hilman wrote: > Ranjith Lohithakshan writes: > >> Currently on PM branch, compilation fails when cpufreq is disabled >> >> arch/arm/mach-omap2/clock3xxx_data.c: In function 'omap3xxx_clk_init': >> arch/arm/mach-omap2/clock3xxx_data.c:3563: error: 'struct clk_functions' >> has no member named 'clk_init_cpufreq_table' >> arch/arm/mach-omap2/clock3xxx_data.c:3564: error: >> 'omap3_clk_init_cpufreq_table' undeclared (first use >> in this function) >> arch/arm/mach-omap2/clock3xxx_data.c:3564: error: (Each undeclared >> identifier is reported only once >> arch/arm/mach-omap2/clock3xxx_data.c:3564: error: for each function it >> appears in.) >> make[1]: *** [arch/arm/mach-omap2/clock3xxx_data.o] Error 1 >> make: *** [arch/arm/mach-omap2] Error 2 >> >> This patch fixes the issue by avoiding runtime init of >> clk_init_cpufreq_table in omap3xxx_clk_init and instead doing it when >> omap2_clk_functions are defined. >> >> Signed-off-by: Ranjith Lohithakshan > > Do you still have this problem? I'm unable to reproduce on current PM branch. No, I don't see this now. Might have got fixed in some of the recent changes. Just FYI, I now see a linkage error with omap3_evm_defconfig arch/arm/mach-omap2/built-in.o: In function `sr_configure_vp': /tmp/ranjith/l-o-new/arch/arm/mach-omap2/smartreflex.c:315: undefined reference to `omap_twl_uv_to_vsel' /tmp/ranjith/l-o-new/arch/arm/mach-omap2/smartreflex.c:364: undefined reference to `omap_twl_uv_to_vsel' arch/arm/mach-omap2/built-in.o: In function `sr_enable': /tmp/ranjith/l-o-new/arch/arm/mach-omap2/smartreflex.c:609: undefined reference to `omap_twl_uv_to_vsel' arch/arm/mach-omap2/built-in.o: In function `sr_reset_voltage': /tmp/ranjith/l-o-new/arch/arm/mach-omap2/smartreflex.c:478: undefined reference to `omap_twl_uv_to_vsel' /tmp/ranjith/l-o-new/arch/arm/mach-omap2/smartreflex.c:496: undefined reference to `omap_twl_uv_to_vsel' make: *** [.tmp_vmlinux1] Error 1 - Ranjith -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3: Fix 3630 mux errors
* Tony Lindgren [100429 11:20]: > * Manjunatha GK [100429 00:23]: > > From: Allen Pais > > > > The omap3630 has more mux signals than 34xx. The additional > > pins exist in omap36xx_cbp_subset, but are not initialized > > as the superset is missing these offsets. This causes the > > following errors during the boot: > > I have an earlier version of this queued up, will take a look > and see if they're the same: > > https://patchwork.kernel.org/patch/87555/ Turns out these are all non-muxable pins. So the right fix is to remove them from the 3630 ball table. Will post a patch shortly for this along with my other fixes. 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] OMAP3EVM: Update pad configuration for wakeup enabled pads
On Wed, 28-Apr-10 11:53 PM +0530, Kevin Hilman wrote:
> Ranjith Lohithakshan writes:
>
>> Kevin,
>>
>> On Tue, 27-Apr-10 8:46 PM +0530, Kevin Hilman wrote:
>>> Ranjith Lohithakshan writes:
>>>
OMAP3530 TRM section 7.4.4.4.2 requires OFFOUTENABLE to be set (active low)
if wakeup capabilities are enabled on a pad. During OFF mode testing
on OMAP3530 EVM, it was observed that the device was not residing in
the OFF state. The device enters into the OFF state and immediately exits
from that state as if an IO wakeup event has occured. The issue was traced
down to the pad configuration of wkaeup enabled pad's.
>>> Nice.
>>>
Also, the pad configuration is included only if the respective drivers are
enabled in the defconfig.
>>> Hmm, do you really want this? If you don't have the driver enabled,
>>> you have to rely on the bootloader settings of these pads which may
>>> also be wrong and trigger an IO wakeup as well.
>> The thought process was that, for example, if keypad is not enabled
>> in a system configuration you probably don't want to see a wakeup
>> occurring if someone presses a key stroke. I understand the concern
>> that you have raised regarding bootloader mis-configurations. My
>> impression was that the bootloaders typically set the mux modes and
>> pull up's/downs and dont really program or enable the wakeup
>> capability. But we cannot depend on that thumb rule.
>
> Unfortunately, Bootloaders don't "typically" do anything. They are
> routinely hacked/patched and cannot be trusted at all.
>
>> What is your recommendation?
>
> First, I suggest you fix the OFFOUTENABLE bug in a single patch
> without introducing the #ifdefs. Then, address the enable/disable of
> the wakeups in a separate patch.
I will do that.
> Next, ideally wakeups should not be configured a this level of board
> code. There are APIs for that: enable_irq_wake()/disable_irq_wake()
>
> For GPIOs (like the touchscreen), you really need to enable wakeups
> using existing APIs, either in the driver or in board init code and be
> sure there is an interrupt handler. Please see the 'Known Problems'
> section of the OMAP PM wiki[2] where it talks about GPIO wakeups.
> Below[2] is an test patch I've used.
I have pushed a patch on ads7846 to linux-input some time ago adding
wakeup support.
fdba2bb : Input: ads7846 - add wakeup support
There is now a wakeup flag added to the ads7846 platform data which can
enabled at the board level. Once this is set , the driver will do an
enable_irq_wake. The patch is now accepted and in mainline. I will
remove the wakeup mux configuration from the board file and instead will
just set the wakeup flag in the ads7846 platform data.
The keypad uses a pin in the non-gpio mode. Is enable_irq_wake supported
for non-gpio mode?
> For MPU IRQs, the IRQ wake APIs don't quite work as expected. You
> can look at board-3430sdp.c to see how wakeups are enabled there.
> If you want to make that conditional on the T2 driver being installed,
> it could be part of the T2 init process.
>
Thanks for the pointers.
>
> [1] http://elinux.org/OMAP_Power_Management#Known_Problems
>
> [2]
> commit a12a1b43c75795fa106d1222730591354209c037
> Author: Kevin Hilman
> Date: Wed Sep 9 11:58:20 2009 -0700
>
> OMAP3: PM: Enable touchscreen GPIO wakeups on SDP and omap3evm
>
> For the GPIO wakeup to work, the GPIO IRQ must be configured as a
> wakeup IRQ.
>
> In addition, a corresponding interrupt handler must be used and enabled
> so that after coming out of idle/suspend the interrupt will be cleared.
> Otherwise, a pending GPIO IRQ will prevent future idle request. (c.f.
> GPIO 'Interrupt and Wakeup' section of the TRM, specifically the
> subsection 'Involved Configuration Registers'.)
>
> Signed-off-by: Kevin Hilman
>
> diff --git a/arch/arm/mach-omap2/board-3430sdp.c
> b/arch/arm/mach-omap2/board-3430sdp.c
> index c1742d0..96f921e 100644
> --- a/arch/arm/mach-omap2/board-3430sdp.c
> +++ b/arch/arm/mach-omap2/board-3430sdp.c
> @@ -24,6 +24,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
> #include
> @@ -140,6 +142,11 @@ static struct twl4030_keypad_data sdp3430_kp_data = {
>
> static int ts_gpio; /* Needed for ads7846_get_pendown_state */
>
> +static irqreturn_t dummy_interrupt_handler (int irq, void *dev_id)
> +{
> + return IRQ_HANDLED;
> +}
> +
> /**
> * @brief ads7846_dev_init : Requests & sets GPIO line for pen-irq
> *
> @@ -147,6 +154,8 @@ static int ts_gpio; /* Needed for
> ads7846_get_pendown_state */
> */
> static void ads7846_dev_init(void)
> {
> + int ret;
> +
> if (gpio_request(ts_gpio, "ADS7846 pendown") < 0) {
> printk(KERN_ERR "can't get ads746 pen down GPIO\n");
> return;
> @@ -156,6 +165,12 @@ static void ads7846_dev_init(void)
>
> omap_set_gpio_debounce(ts_gpio, 1);
> omap_set_gpio_d
RE: [PATCH] OMAP3: PM: Registering sgx device and it's platform data
> -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Thursday, April 29, 2010 7:35 PM > To: G, Manjunath Kondaiah > Cc: linux-omap@vger.kernel.org; Agarwal, Preshit; Tony > Lindgren; Turquette, Mike; V, Hemanth > Subject: Re: [PATCH] OMAP3: PM: Registering sgx device and > it's platform data > > Manjunatha GK writes: > > > The SGX powervr_device is registered with it's platform specific > > data to provide information about setting constraint through > > omap_pm_set_min_bus_tput. > > > > Signed-off-by: Preshit Agarwal > > Signed-off-by: Manjunatha GK > > Cc: Tony Lindgren > > Cc: Kevin Hilman > > Cc: Mike Turquette > > Cc: Hemanth V > > Re: $SUBJECT, why the PM: prefix? Since omap_sgx_data is under CONFIG_PM flag, hence title was prefixed with "PM". I will remove the same in next version of the patch. -Manjunath -- 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
Real Estate Agents - 1 million records with emails
We have many package deals on sale this week, here is one: Physicians (34 specialties) - 788k records, 17k emails, 200k fax numbers Hospitals - 23,747 Hospital Administrators in over 7,145 Hospitals (full contact info no emails) Dentists - 164k records, 45k emails, 77k fax numbers Chiropractors - 108,421 total records * 3,414 emails * 6,553 fax numbers Pharmaceutical Companies - Email only list 47,000 emails of pharma company employees All complete lists above: $395 There are more packages and not just for healthcare contact me here for more info or to get samples: ilene.ol...@goodlists.co.cc To invoke no further correspondence status please send an email to disapp...@goodlists.co.cc -- 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/14] omap: Make uncompress code and DEBUG_LL code generic
[resend to include RMK] On Tue, 2010-01-26 at 12:12 -0800, Tony Lindgren wrote: > Define arch_decomp_setup() the same way as some other > architectures do. Use arch_id to configure the debug uart > based on the machine_is by storing it into the uart > scratchpad register for DEBUG_LL code to use. > > Note that to avoid merge conflicts, this patch is using > hardcoded register r1 until tmp register is being passed > for all addruart macros. This patch (now in mainline[1]) has been working well, but has a couple serious limitations: 1. assumes bootloader has enabled UART1 clocks 2. assumes all OMAPs supported have the same UART1 base With more platforms using USB-based UARTs, assumption (1) may not be safe for very long, as bootloaders for these platforms don't really *need* to enable UART1. Currently, they happen to mainly because of copied init code from other platforms. But more importantly, there are more OMAP derivative parts coming soon, and one in particular coming soon[2] breaks assumption 2 by having a different UART1 base (yes, it's branded as a DaVinci, but it's an OMAP core as far as linux is concerned. Don't get me started on TI branding.) To fix both problems, maybe we should just use a fixed memory location to pass this temporary data from uncompress to the kernel. We've had a similar problem on DaVinci recently and a proposal has been made (and tested) to use memory just below the page tables[3].) Any comments on this proposal? or alternative suggestions? Kevin [1] commit 0c8219f0302d0d27fda52c790d38406801e547ec [1] http://www.ti.com/ww/en/dsp/davinci-netra/index.shtml [2] https://patchwork.kernel.org/patch/94724/ -- 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] DSPBRIDGE: MMU-Fault debugging enhancements
On Fri, Apr 9, 2010 at 3:15 AM, Guzman Lugo, Fernando wrote: > From db3d76a2e89a1c227322a2732ddf7ebf5cd4b4cf Mon Sep 17 00:00:00 2001 > From: Ernesto Ramos > Date: Wed, 24 Mar 2010 11:12:05 -0600 > Subject: [PATCH] DSPBRIDGE: MMU-Fault debugging enhancements > > These changes allow for DSP task information to be printed > by the MPU dspbridge when DSP MMU fault ocurrs. > > Signed-off-by: Cris Jansson > [change to open source coding style] > Signed-off-by: Ernesto Ramos This patch seems to be doing a lot of things. Couldn't it have been split? Also, from the commit message it seems to implement a new feature, however, I heard it's supposed to fix memory corruption too. Is that true? If that's the case the code that fixes that would have to be separate. I understand this patch was already pushed to dspbridge branch, but I think such important changes should be properly recorded in the history. Cheers. -- Felipe Contreras -- 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
