Re: [PATCH] OMAP2/3: Add support for flash on SDP boards
Hi Tony, Are you OK with below patch? I have not received any comment yet. In case this patch is OK, can you please push it? -vimal On Wed, Aug 19, 2009 at 10:14 AM, vimal singhvimalsi...@ti.com wrote: Add support for flash on SDP boards. NAND, NOR and OneNAND are supported. Only tested on 3430SDP (ES2 and ES3.1), somebody please test on 2430SDP and check the chips select for 2430SDP. Also note that: For OneNAND: in the earlier 2430SDP code the kernel partition was set to only 1MB instead of 2MB on 3430SDP. If people want the old partition sizes back on 2430SDP, please provide a patch. For NAND: 'U-Boot', 'Boot Env' and 'Kernel' partitions sizes increased by few blocks to provide few spare blocks for NAND bab block management in u-boot. If people want old partition sizes, please provide a patch. Signed-off-by: Vimal Singh vimalsi...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Makefile | 2 arch/arm/mach-omap2/board-2430sdp.c | 2 arch/arm/mach-omap2/board-3430sdp.c | 2 arch/arm/mach-omap2/board-sdp-flash.c | 326 + arch/arm/mach-omap2/board-sdp.h | 15 + arch/arm/plat-omap/include/mach/gpmc.h | 2 6 files changed, 349 insertions(+) Index: linux-omap-2.6/arch/arm/mach-omap2/Makefile === --- linux-omap-2.6.orig/arch/arm/mach-omap2/Makefile +++ linux-omap-2.6/arch/arm/mach-omap2/Makefile @@ -48,6 +48,7 @@ obj-$(CONFIG_OMAP_IOMMU) += $(iommu-y) obj-$(CONFIG_MACH_OMAP_GENERIC) += board-generic.o obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o obj-$(CONFIG_MACH_OMAP_2430SDP) += board-2430sdp.o \ + board-sdp-flash.o \ mmc-twl4030.o obj-$(CONFIG_MACH_OMAP_APOLLON) += board-apollon.o obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o \ @@ -61,6 +62,7 @@ obj-$(CONFIG_MACH_OMAP3EVM) += board-om obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \ mmc-twl4030.o obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o \ + board-sdp-flash.o \ mmc-twl4030.o obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \ Index: linux-omap-2.6/arch/arm/mach-omap2/board-2430sdp.c === --- linux-omap-2.6.orig/arch/arm/mach-omap2/board-2430sdp.c +++ linux-omap-2.6/arch/arm/mach-omap2/board-2430sdp.c @@ -38,6 +38,7 @@ #include mach/usb.h #include mach/gpmc-smc91x.h +#include board-sdp.h #include mmc-twl4030.h #define SDP2430_CS0_BASE 0x0400 @@ -210,6 +211,7 @@ static void __init omap_2430sdp_init(voi twl4030_mmc_init(mmc); usb_musb_init(); board_smc91x_init(); + sdp_flash_init(); /* Turn off secondary LCD backlight */ ret = gpio_request(SECONDARY_LCD_GPIO, Secondary LCD backlight); Index: linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c === --- linux-omap-2.6.orig/arch/arm/mach-omap2/board-3430sdp.c +++ linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c @@ -41,6 +41,7 @@ #include mach/keypad.h #include mach/gpmc-smc91x.h +#include board-sdp.h #include sdram-qimonda-hyb18m512160af-6.h #include mmc-twl4030.h @@ -494,6 +495,7 @@ static void __init omap_3430sdp_init(voi omap_serial_init(sdp3430_uart_config); usb_musb_init(); board_smc91x_init(); + sdp_flash_init(); usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61); } Index: linux-omap-2.6/arch/arm/mach-omap2/board-sdp-flash.c === --- /dev/null +++ linux-omap-2.6/arch/arm/mach-omap2/board-sdp-flash.c @@ -0,0 +1,326 @@ +/* + * arch/arm/mach-omap2/board-sdp-flash.c + * + * Copyright (C) 2009 Nokia Corporation + * Copyright (C) 2009 Texas Instruments + * + * Modified from mach-omap2/board-3430sdp-flash.c + * Author: Vimal Singh vimalsi...@ti.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/kernel.h +#include linux/platform_device.h +#include linux/mtd/mtd.h +#include linux/mtd/partitions.h +#include linux/io.h + +#include asm/mach/flash.h +#include mach/onenand.h +#include mach/gpmc.h +#include mach/nand.h + +#define REG_FPGA_REV 0x10 +#define REG_FPGA_DIP_SWITCH_INPUT2 0x60 +#define MAX_SUPPORTED_GPMC_CONFIG 3 + +/* various memory
RE: [PATCH 1/5] OMAP1/2/3/4: DEBUG_LL: cleanup
Vikram, Thanks for this clean-up series !! Couple of comments. snip snip -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Pandita, Vikram Sent: Friday, August 21, 2009 11:25 PM To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.arm.linux.org.uk Cc: Pandita, Vikram Subject: [PATCH 1/5] OMAP1/2/3/4: DEBUG_LL: cleanup of arch/arm/plat-omap/include/mach/debug- macro.S Signed-off-by: Vikram Pandita vikram.pand...@ti.com --- arch/arm/plat-omap/Kconfig| 50 ++-- - arch/arm/plat-omap/include/mach/common.h |7 +++ arch/arm/plat-omap/include/mach/debug-macro.S | 40 arch/arm/plat-omap/include/mach/uncompress.h | 12 + 4 files changed, 54 insertions(+), 55 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index ab9f9ef..2fefb64 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -162,21 +162,43 @@ config OMAP_DM_TIMER help Select this option if you want to use OMAP Dual-Mode timers. + Specify the Physical address of Low level debug UART + Specify 0x0 in case you do not want DEBUG_LL functions to iterfere with your board uarts + + OMAP1: + --- + UART1 - 0xfffb (default) + UART2 - 0xfffb0800 + UART3 - 0xfffb9800 (sx1, palmtt) + + OMAP2: + --- + UART1 - 0x4806a000 (default) + UART2 - 0x4806c000 + UART3 - 0x4806e000 (N8X0) + + OMAP3/4: + --- + UART1 - 0x4806a000 (default: except following) + UART2 - 0x4806c000 + UART3 - 0x4902 (rx51, beagle, pendora, ldp, overo) OMAP4 UART3 base address is 0x4802 + UART4 - 0x4806e000 + UART_EXT - 0x1000 (zoom2: Debug uart is on external debug board) - -#elif defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4) - moveq \rx, #0x4800@ physical base address - movne \rx, #0xd800@ virtual base - orr \rx, \rx, #0x0006a000 -#ifdef CONFIG_OMAP_LL_DEBUG_UART2 - add \rx, \rx, #0x2000 @ UART 2 -#endif -#ifdef CONFIG_OMAP_LL_DEBUG_UART3 - add \rx, \rx, #0x00fb @ UART 3 This was already wrong for OMAP4 - add \rx, \rx, #0x6000 -#endif + /* omap1 */ + ldr \rx, =CONFIG_OMAP_DEBUG_LL_UART_PHY_ADDR @ physical base address + subne \rx, #CONFIG_OMAP_DEBUG_LL_UART_PHY_ADDR, #OMAP1_IO_OFFSET @ virtual base +#else + /* omap2/omap3/omap4 */ + ldr \rx, =CONFIG_OMAP_DEBUG_LL_UART_PHY_ADDR @ physical base address + orrne \rx, \rx, #OMAP2_IO_OFFSET @ virtual base #endif .endm diff --git a/arch/arm/plat-omap/include/mach/uncompress.h b/arch/arm/plat- omap/include/mach/uncompress.h index 0814c5f..0e21eb3 100644 --- a/arch/arm/plat-omap/include/mach/uncompress.h +++ b/arch/arm/plat-omap/include/mach/uncompress.h @@ -38,14 +38,8 @@ static void putc(int c) return; #endif -#ifdef CONFIG_ARCH_OMAP -#ifdef CONFIG_OMAP_LL_DEBUG_UART3 - uart = (volatile u8 *)(OMAP_UART3_BASE); -#elif defined(CONFIG_OMAP_LL_DEBUG_UART2) - uart = (volatile u8 *)(OMAP_UART2_BASE); -#else - uart = (volatile u8 *)(OMAP_UART1_BASE); -#endif +#if defined(CONFIG_DEBUG_LL) + uart = (volatile u8 *)(CONFIG_OMAP_DEBUG_LL_UART_PHY_ADDR); #ifdef CONFIG_ARCH_OMAP1 /* Determine which serial port to use */ @@ -62,7 +56,6 @@ static void putc(int c) return; } while (0); #endif /* CONFIG_ARCH_OMAP1 */ -#endif Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2] ARM: OMAP4: Boot up crash 2.6.31-rc6
Thanks Kevin!! -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, August 21, 2009 9:30 PM To: Shilimkar, Santosh Cc: Russell King; Tony Lindgren; linux-omap@vger.kernel.org; linux-arm- ker...@lists.arm.linux.org.uk Subject: Re: [PATCH 0/2] ARM: OMAP4: Boot up crash 2.6.31-rc6 Shilimkar, Santosh santosh.shilim...@ti.com writes: Russell, On the mainline 2.6.31-rc6, OMAP4 boot is crashing. Also serial code in the linux-next branch isn't merge correctly and needs reworked patches. Can you please see if they are ok? After the fix I suggested on patch 2/2, I'm OK with these. Tony, should I pull these into my fixes queue, or do you want to merge them directly. We will need them in your for-next branch to resolve the problems in linux-next. I will submit new version with you comment. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 v2] ARM: OMAP4: Fix NULL pointer dereference crash.
After the patch series [PATCH 00/14] OMAP PM fixes for .31-rc
merge in 2.6.31-rc5, the kernel crashed during boot on OMAP4430.
This patch fixes it by adding UART4 support and related code.
Without this patch omap_serial_init() would produce NULL pointer
dereference and kernel crashes in the bootup on OMAP4430 platform.
Some more info on the merge issue can be found here.
More info- http://lkml.org/lkml/2009/8/20/192
Note: While merging this patch,IO_ADDRESS needs to be changed
to OMAP2_IO_ADDRESS if the Tony's below series is already merged in.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg15072.html
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/board-4430sdp.c |2 +-
arch/arm/mach-omap2/serial.c| 27 ++-
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index b0c7402..1b22307 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -39,7 +39,7 @@ static struct platform_device *sdp4430_devices[] __initdata =
{
};
static struct omap_uart_config sdp4430_uart_config __initdata = {
- .enabled_uarts = (1 0) | (1 1) | (1 2),
+ .enabled_uarts = (1 0) | (1 1) | (1 2) | (1 3),
};
static struct omap_lcd_config sdp4430_lcd_config __initdata = {
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index a7421a5..e1be77b 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -112,7 +112,21 @@ static struct plat_serial8250_port serial_platform_data2[]
= {
.flags = 0
}
};
-
+#ifdef CONFIG_ARCH_OMAP4
+static struct plat_serial8250_port serial_platform_data3[] = {
+ {
+ .membase= IO_ADDRESS(OMAP_UART4_BASE),
+ .mapbase= OMAP_UART4_BASE,
+ .irq= 70,
+ .flags = UPF_BOOT_AUTOCONF,
+ .iotype = UPIO_MEM,
+ .regshift = 2,
+ .uartclk= OMAP24XX_BASE_BAUD * 16,
+ }, {
+ .flags = 0
+ }
+};
+#endif
static inline unsigned int serial_read_reg(struct plat_serial8250_port *up,
int offset)
{
@@ -550,6 +564,17 @@ static struct omap_uart_state omap_uart[OMAP_MAX_NR_PORTS]
= {
},
},
},
+#ifdef CONFIG_ARCH_OMAP4
+ {
+ .pdev = {
+ .name = serial8250,
+ .id = PLAT8250_DEV_FOURPORT,
+ .dev= {
+ .platform_data = serial_platform_data3,
+ },
+ },
+ },
+#endif
};
void __init omap_serial_init(void)
--
1.5.4.7
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2 v2] ARM: OMAP4: Bypass the clock check.
Second reason of OMAP4 boot failure on 2.6.31.rc6, the UART
platform data is not getting registered to kernel.
Registration was failing because of clock check failure in
omap_serial_init().
Below patch fix the same.
OMAP4 clock framework patches are still getting discussed on mailing
list so till then we need this.
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/serial.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index e1be77b..6bbdfe0 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -620,8 +620,11 @@ void __init omap_serial_init(void)
uart-fck = NULL;
}
- if (!uart-ick || !uart-fck)
- continue;
+ /* FIXME: Remove this once the clkdev is ready */
+ if (!cpu_is_omap44xx()) {
+ if (!uart-ick || !uart-fck)
+ continue;
+ }
uart-num = i;
p-private_data = uart;
--
1.5.4.7
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Cleanup DEBUG_LL infrastructure
Vikram Pandita wrote: Patch1/2: clean up the DEBUG_LL infrastructure. Patch3: add DEBUG_LL support for Zoom2 board Patch4/5: some Zoom2 fixes Vikram Pandita (5): OMAP1/2/3/4: DEBUG_LL: cleanup OMAP1/2/3/4: Adapt board files for cleand DEBUG_LL interface OMAP: Zoom2: Add DEBUG_LL interface using external Quart OMAP: Zoom2: Fix serial break OMAP: Zoom2: Release Dbg board detect gpio Thanks for this patch series, makes my zoom2 bootable again. Graeme -- To unsubscribe from this list: send the line unsubscribe 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: fix lockdep warning caused by omap3_pm_init
From: Ming Lei tom.leim...@gmail.com This patch uses kmalloc(size,GFP_ATOMIC) instead of kmalloc(size,GFP_KERNEL) to allocate memory for instance of struct power_state in pwrdms_setup(), since it may be called by pwrdm_for_each() with irq disabled. It is a easy fix for the following lockdep warning caused by kmalloc(size,GFP_KERNEL) in pwrdms_setup(): Power Management for TI OMAP3. [ cut here ] WARNING: at kernel/lockdep.c:2282 lockdep_trace_alloc+0xe8/0xfc() Modules linked in: [c0032ccc] (unwind_backtrace+0x0/0xec) from [c0056934] (warn_slowpath_common+0x48/0x60) [c0056934] (warn_slowpath_common+0x48/0x60) from [c007da10] (lockdep_trace_alloc+0xe8/0xfc) [c007da10] (lockdep_trace_alloc+0xe8/0xfc) from [c00cd9bc] (kmem_cache_alloc+0x28/0x178) [c00cd9bc] (kmem_cache_alloc+0x28/0x178) from [c000f184] (pwrdms_setup+0x30/0xf8) [c000f184] (pwrdms_setup+0x30/0xf8) from [c00381c4] (pwrdm_for_each+0x64/0x84) [c00381c4] (pwrdm_for_each+0x64/0x84) from [c000ef60] (omap3_pm_init+0x3f4/0x5ac) [c000ef60] (omap3_pm_init+0x3f4/0x5ac) from [c002c2c0] (do_one_initcall+0x30/0x1d4) [c002c2c0] (do_one_initcall+0x30/0x1d4) from [c00088d8] (kernel_init+0xa4/0x118) [c00088d8] (kernel_init+0xa4/0x118) from [c002ddf8] (kernel_thread_exit+0x0/0x8) ---[ end trace 1e06f8d97dc5a19b ]--- --- This patch is against linux-2.6.31-rc7. Signed-off-by: Ming Lei tom.leim...@gmail.com --- arch/arm/mach-omap2/pm34xx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 488d595..d67b781 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -665,7 +665,7 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm) if (!pwrdm-pwrsts) return 0; - pwrst = kmalloc(sizeof(struct power_state), GFP_KERNEL); + pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC); if (!pwrst) return -ENOMEM; pwrst-pwrdm = pwrdm; -- 1.6.0.GIT -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] OMAP1/2/3/4: DEBUG_LL: cleanup
Vikram Pandita wrote:
This patch cleans up the DEBUG_LL infrastructure for omap boards.
Thanks Vikram, this is indeed in need of some cleanup. But I have some
comments about the approach taken.
This approach still doesn't solve one of the fundamental problems with
the current implementation. It prevents using a single kernel across
multiple boards. If we could drop the compile-time decision in favor of
a runtime one based on machine-type, we could use a single base
defconfig that would be able to be tested on all omap3 boards for example.
For the zImage UART output (uncompress.h) there is a global variable
__machine_arch_type which could be used to check the board type and set
variable for UART base and shift. We do this on DaVinci.
For debug output (debug-macro.S) those macros should be changed to use
variables for UART base and shift also. While you're in changing the
board files, you could also add something like this to each:
#ifdef CONFIG_SERIAL_8250_CONSOLE
static int __init board_console_init(void)
{
return add_preferred_console(ttyS, UART#, 115200);
}
console_initcall(board_console_init);
#endif
This also allows the board to boot using a default UART even without
having the console= on the cmdline.
There is one catch to doing this at runtime instead of compile time.
The variables for the UART base and shift have to be set very early in
the boot, otherwise any errors from the early ARM asm boot (head.S) will
be missed.
For starters, they could be assingned in the board map_io hook, but we'd
still miss the debug prints if there were any errors parsing the
machine_type and processor_type early in the boot (head.S)
I'd be ok with this limitation for a first pass because it's still
better than what we currently have in l-o, but I'd like to hear if
others had some ideas for how we might do dynamic decisions on UART
based on board-type very early in the boot.
Kevin
The three stages of log printing infrastructure is using their own #defines
The patch integrates the three stages to use the same variable.
Three stages are:
Stage 1: Prints - Uncompressing Linux..
File getting used: arch/arm/plat-omap/include/mach/uncompress.h
Stage 2: Prints - 5Linux version 2.6.31
File getting used: arch/arm/plat-omap/include/mach/debug-macro.S
Stage 3: Kernel ttyS console takes over
On enabling the DEBUG_LL menuconfig item
[Kernel Hacking - Kernel low-level debugging functions]
the following entry gets auto selected
[Systerm Type - TI OMAP Implementations - Low-level Debug console UART]
This is the physical address of the UART getting used for the board.
The physical address of debug uart is provided as a menuconfig option now.
Issue with current system:
(a) Zoom2 board has a detachable debug board having the TL16CP754 Quad uart
chip.
If the debug board is not attached, _NO_ debug uart is available.
OMAP internal uarts are not used for traces on zoom2 board.
Current framework does not account for boards that may not have a debug uart
at all. The Stage 1 always accesses one of the uarts. Thats fixed now.
(b) this patch does a cleanup of arch/arm/plat-omap/include/mach/debug-macro.S
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
arch/arm/plat-omap/Kconfig| 50 ++---
arch/arm/plat-omap/include/mach/common.h |7 +++
arch/arm/plat-omap/include/mach/debug-macro.S | 40
arch/arm/plat-omap/include/mach/uncompress.h | 12 +
4 files changed, 54 insertions(+), 55 deletions(-)
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index ab9f9ef..2fefb64 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -162,21 +162,43 @@ config OMAP_DM_TIMER
help
Select this option if you want to use OMAP Dual-Mode timers.
-choice
- prompt Low-level debug console UART
- depends on ARCH_OMAP
- default OMAP_LL_DEBUG_UART1
-
-config OMAP_LL_DEBUG_UART1
- bool UART1
-
-config OMAP_LL_DEBUG_UART2
- bool UART2
-config OMAP_LL_DEBUG_UART3
- bool UART3
-
-endchoice
+config OMAP_DEBUG_LL_UART_PHY_ADDR
+ hex Low-level debug console UART Physical Address
+ depends on ARCH_OMAP DEBUG_LL
+
+ default 0xfffb0800 if ARCH_OMAP1 (MACH_OMAP_PALMTT || MACH_SX1)
+ default 0xfffb if ARCH_OMAP1
+ default 0x4806e000 if ARCH_OMAP2 MACH_NOKIA_N8X0
+ default 0x4806a000 if ARCH_OMAP2
+ default 0x4902 if ARCH_OMAP3 (MACH_NOKIA_RX51 ||
MACH_OMAP_BEAGLE)
+ default 0x4902 if ARCH_OMAP3 (MACH_OMAP3_PANDORA ||
MACH_OMAP_LDP || MACH_OVERO)
+ default 0x1000 if ARCH_OMAP3 MACH_OMAP_ZOOM2
+ default 0x4806a000 if ARCH_OMAP3
+ default 0x4806a000 if ARCH_OMAP4
+ help
+ Specify the Physical address of Low level debug UART
+ Specify 0x0 in case you do not want DEBUG_LL functions to iterfere
with your board uarts
+
+ OMAP1:
+
Re: [PATCH v2 08/11] OMAP2/3 board-*.c files: read bootloader configuration earlier
Hi Paul,
Paul Walmsley p...@pwsan.com writes:
Most board-*.c files read configuration data from the bootloader in
their .init_machine() function. This needs to happen earlier, at some
point before omap2_init_common_hw() is called. This is because a
future patch will use the bootloader serial console port information
to enable the UART clocks earlier, immediately after omap2_clk_init().
This is in turn necessary since otherwise clock tree usecounts on
clocks like dpll4_m2x2_ck will be bogus, which can cause the
currently-active console UART clock to be disabled during boot.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/board-2430sdp.c | 17 -
arch/arm/mach-omap2/board-3430sdp.c | 18 +-
arch/arm/mach-omap2/board-apollon.c | 20 ++--
arch/arm/mach-omap2/board-generic.c | 14 +++---
arch/arm/mach-omap2/board-h4.c | 20 ++--
arch/arm/mach-omap2/board-ldp.c | 20 ++--
arch/arm/mach-omap2/board-omap3beagle.c | 26 +-
arch/arm/mach-omap2/board-omap3evm.c | 14 +++---
arch/arm/mach-omap2/board-omap3pandora.c | 20 ++--
arch/arm/mach-omap2/board-overo.c| 20 ++--
arch/arm/mach-omap2/board-rx51.c |4 ++--
arch/arm/mach-omap2/board-zoom2.c| 18 +-
arch/arm/mach-omap2/io.c |2 ++
arch/arm/mach-omap2/serial.c | 14 +-
arch/arm/plat-omap/include/mach/serial.h |3 +++
15 files changed, 123 insertions(+), 107 deletions(-)
This one needs an update to apply on omap/master since Tony has
done the serial init rework which touches all these board files as well :(
Kevin
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 8ec2a13..06c644d 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -139,13 +139,6 @@ static inline void board_smc91x_init(void)
#endif
-static void __init omap_2430sdp_init_irq(void)
-{
- omap2_init_common_hw(NULL, NULL);
- omap_init_irq();
- omap_gpio_init();
-}
-
static struct omap_uart_config sdp2430_uart_config __initdata = {
.enabled_uarts = ((1 0) | (1 1) | (1 2)),
};
@@ -155,6 +148,14 @@ static struct omap_board_config_kernel sdp2430_config[]
= {
{OMAP_TAG_LCD, sdp2430_lcd_config},
};
+static void __init omap_2430sdp_init_irq(void)
+{
+ omap_board_config = sdp2430_config;
+ omap_board_config_size = ARRAY_SIZE(sdp2430_config);
+ omap2_init_common_hw(NULL, NULL);
+ omap_init_irq();
+ omap_gpio_init();
+}
static struct twl4030_gpio_platform_data sdp2430_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
@@ -205,8 +206,6 @@ static void __init omap_2430sdp_init(void)
omap2430_i2c_init();
platform_add_devices(sdp2430_devices, ARRAY_SIZE(sdp2430_devices));
- omap_board_config = sdp2430_config;
- omap_board_config_size = ARRAY_SIZE(sdp2430_config);
omap_serial_init();
twl4030_mmc_init(mmc);
usb_musb_init();
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index ac262cd..e51c124 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -167,13 +167,6 @@ static struct platform_device *sdp3430_devices[]
__initdata = {
sdp3430_lcd_device,
};
-static void __init omap_3430sdp_init_irq(void)
-{
- omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL);
- omap_init_irq();
- omap_gpio_init();
-}
-
static struct omap_uart_config sdp3430_uart_config __initdata = {
.enabled_uarts = ((1 0) | (1 1) | (1 2)),
};
@@ -187,6 +180,15 @@ static struct omap_board_config_kernel sdp3430_config[]
__initdata = {
{ OMAP_TAG_LCD, sdp3430_lcd_config },
};
+static void __init omap_3430sdp_init_irq(void)
+{
+ omap_board_config = sdp3430_config;
+ omap_board_config_size = ARRAY_SIZE(sdp3430_config);
+ omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL);
+ omap_init_irq();
+ omap_gpio_init();
+}
+
static int sdp3430_batt_table[] = {
/* 0 C*/
30800, 29500, 28300, 27100,
@@ -482,8 +484,6 @@ static void __init omap_3430sdp_init(void)
{
omap3430_i2c_init();
platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
- omap_board_config = sdp3430_config;
- omap_board_config_size = ARRAY_SIZE(sdp3430_config);
if (omap_rev() OMAP3430_REV_ES1_0)
ts_gpio = SDP3430_TS_GPIO_IRQ_SDPV2;
else
diff --git a/arch/arm/mach-omap2/board-apollon.c
b/arch/arm/mach-omap2/board-apollon.c
index dcfc20d..8e063ba 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -248,14
Re: [PATCH 4/5] OMAP: Zoom2: Fix serial break
Vikram Pandita vikram.pand...@ti.com writes:
Fix the break in Zoom2 Quad uart debug port support.
Patch by Kevin Hilman fd455ea899b5a14 caused a break as it introuduced
per port PLATFORM id and Zoom2 was not tested with this change.
...because working zoom2 UART support was not yet upstream.
For Zoom2 serial port, add platform id as 4
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/board-zoom-debugboard.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c
b/arch/arm/mach-omap2/board-zoom-debugboard.c
index f8b0726..4dd714d 100644
--- a/arch/arm/mach-omap2/board-zoom-debugboard.c
+++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
@@ -97,7 +97,7 @@ static struct plat_serial8250_port serial_platform_data[] =
{
static struct platform_device zoom2_debugboard_serial_device = {
.name = serial8250,
- .id = PLAT8250_DEV_PLATFORM1,
+ .id = PLAT8250_DEV_FOURPORT,
Using FOURPORT isn't right either. Just use a number.
If you're OK with the version below, I'll pull it into my fixes queue.
I've also updated the changelog to explain the problem instead of just
fix the break... This fix messages are not useful when looking back
through the changelog history.
I don't currently have access to a Zoom2, so this has not been tested.
Kevin
commit c52bc1989540d1305aa5372a73bc6096636c8432
Author: Vikram Pandita vikram.pand...@ti.com
Date: Fri Aug 21 13:11:06 2009 -0500
OMAP: Zoom2: update serial platform_data id for external UART
Now that on-chip UARTs each have separate platform_data, the external
UART needs an non-conflicting ID. Since there are 3 on-chip UARTs,
the Zoom2 external UART will be registered after as the fourth.
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c
b/arch/arm/mach-omap2/board-zoom-debugboard.c
index bac5c43..66fe940 100644
--- a/arch/arm/mach-omap2/board-zoom-debugboard.c
+++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
@@ -94,7 +94,7 @@ static struct plat_serial8250_port serial_platform_data[] = {
static struct platform_device zoom2_debugboard_serial_device = {
.name = serial8250,
- .id = PLAT8250_DEV_PLATFORM1,
+ .id = 3,
.dev= {
.platform_data = serial_platform_data,
},
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/3] RTC platform data structure defined
ch...@ti.com writes:
This series contains patches which
1. define TWL4030 rtc platform data which has msecure gpio line info
2. initialise msecure gpio line from rtc driver
3. twl core file passes rtc platform data from board file to rtc
driver
4. Board files handle mux configuration of msecure gpio line
This series applies on top of linux-2.6.31-rc5.
CharuLatha (4):
[PATCH 0/3] RTC platform data structure defined
Normally, PATCH 0/n is a summary of the other patches, and does not
include a patch itself.
I recommend using 'git format-patch' which will take care of the
formatting and the numbering for you.
[PATCH 1/3] RTC periodic interrupts enabling and msecure init
[PATCH 2/3] handling rtc platform data
[PATCH 3/3] board files do msecure line mux configuration
Structure twl4030_rtc_platform_data is defined with msecure_gpio in it.
This structure would be initialised in board file.
RTC msecure line initialization happens in RTC driver.
The same structure can be used for any future enhancements in RTC.
Signed-off-by: Charulatha V ch...@ti.com
---
include/linux/i2c/twl4030.h |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/linux/i2c/twl4030.h b/include/linux/i2c/twl4030.h
index 15edfaa..6ae582b 100644
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -341,6 +341,13 @@ struct twl4030_gpio_platform_data {
unsigned gpio, unsigned ngpio);
};
+struct twl4030_rtc_platform_data {
+ int msecure_gpio;
+ /* More structures/elements can be added
+ * for future Triton RTC driver enhancements
+ */
very true, but does not need to be documented.
+};
+
struct twl4030_madc_platform_data {
int irq_line;
};
@@ -395,6 +402,7 @@ struct twl4030_platform_data {
unsignedirq_base, irq_end;
struct twl4030_bci_platform_data*bci;
struct twl4030_gpio_platform_data *gpio;
+ struct twl4030_rtc_platform_data*rtc;
struct twl4030_madc_platform_data *madc;
struct twl4030_keypad_data *keypad;
struct twl4030_usb_data *usb;
--
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
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: [RFC][PATCH 1/3] RTC periodic interrupts enabling and msecure init
Roger Quadros ext-roger.quad...@nokia.com writes:
ext ch...@ti.com wrote:
Triton2 RTC code changes for fixing periodic interrupt feature in RTC.
rtc-twlcore.c does initialisation of the msecure gpio pin. Board
files indicate msecure gpio line through twl4030 platform
data. twl4030-core.c passes this information to RTC driver.
Board files does msecure gpio mux configuration.
Signed-off-by: Charulatha V ch...@ti.com
Periodic interrupts and msecure are 2 different entities. I think they
should be implemented in different patches.
Agreed. The fix part of this should be a separated out with a
detailed description of both the problem and the fix.
Kevin
---
drivers/rtc/rtc-twl4030.c | 63
-
1 files changed, 62 insertions(+), 1 deletions(-)
diff --git a/drivers/rtc/rtc-twl4030.c b/drivers/rtc/rtc-twl4030.c
index 9c8c70c..614adf0 100644
--- a/drivers/rtc/rtc-twl4030.c
+++ b/drivers/rtc/rtc-twl4030.c
@@ -29,7 +29,12 @@
#include linux/interrupt.h
#include linux/i2c/twl4030.h
+#include linux/gpio.h
+/*
+ * To find if the value is a power of two
+ */
+#define is_power_of_two(x)(!((x) ((x)-1)))
/*
* RTC block register offsets (use TWL_MODULE_RTC)
@@ -86,6 +91,37 @@
/*--*/
/*
+ * msecure line initialisation for TWL4030 RTC registers write access
+ */
+static int msecure_init(struct twl4030_rtc_platform_data *pdata)
+{
+int ret = 0;
+if (pdata == NULL)
+goto out;
+
+ret = gpio_request(pdata-msecure_gpio, msecure);
+if (ret 0) {
if (ret) should suffice
+pr_err(twl4030_rtc: can't reserve msecure GPIO:%d !\n
+RTC functionality will not be available\n,
+pdata-msecure_gpio);
+goto out;
+}
+/*
+ * TWL4030 will be in secure mode if msecure line from OMAP is low.
+ * Make msecure line high in order to change the TWL4030 RTC time
+ * and calender registers.
+ */
+ret = gpio_direction_output(pdata-msecure_gpio, 1);
+if (ret 0)
ditto
+pr_err(twl4030_rtc: can't set msecure GPIO direction:%d !\n
+RTC functionality will not be available\n,
+pdata-msecure_gpio);
+
+out:
+return ret;
+}
+
+/*
* Supports 1 byte read from TWL4030 RTC register.
*/
static int twl4030_rtc_read_u8(u8 *data, u8 reg)
@@ -128,7 +164,6 @@ static int set_rtc_irq_bit(unsigned char bit)
int ret;
val = rtc_irq_bits | bit;
-val = ~BIT_RTC_INTERRUPTS_REG_EVERY_M;
ret = twl4030_rtc_write_u8(val, REG_RTC_INTERRUPTS_REG);
if (ret == 0)
rtc_irq_bits = val;
@@ -318,6 +353,25 @@ out:
return ret;
}
+static int twl4030_rtc_irq_set_freq(struct device *dev, int freq)
+{
+int ret, val = 1;
+int regbit = 0;
+
+if ((!is_power_of_2(freq)) || (freq 8) || (freq = 0))
+return -EINVAL;
0 is valid freq. it means disable periodic interrupts.
+
+while ((freq val) == 0) {
+val = val 1;
+regbit++;
+}
as per your implementation, if user sets interrupt rate of 4 Hz then
you will set regbit to 2 which means interrupt every hour?
i.e. 0.00027 Hz. no?
+ret = set_rtc_irq_bit(regbit);
+if (ret)
+dev_err(dev, rtc_irq_set_freq error %d\n, ret);
+
+return ret;
+}
+
static irqreturn_t twl4030_rtc_interrupt(int irq, void *rtc)
{
unsigned long events = 0;
@@ -383,6 +437,7 @@ static struct rtc_class_ops twl4030_rtc_ops = {
.set_alarm = twl4030_rtc_set_alarm,
.alarm_irq_enable = twl4030_rtc_alarm_irq_enable,
.update_irq_enable = twl4030_rtc_update_irq_enable,
+.irq_set_freq = twl4030_rtc_irq_set_freq,
IMHO this does not make sense.
twl4030 supports a max interrupt rate of 1 Hz (i.e. 1 sec). So you can
only support freq values of 0 and 1 i.e. 0 for disabled and 1 for 1
sec interrupt.
This functionality is already achieved by update_irq_enable.
-roger
--
To unsubscribe from this list: send the line unsubscribe 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
