Re: [PATCH 8/10 v2] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox.
From: ext C.A, Subramaniam subramaniam...@ti.com Subject: [PATCH 8/10 v2] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox. Date: Tue, 17 Nov 2009 15:51:14 +0100 Hi Tony, Following is the version 2 of Patch 8/10 (removing all #fidefs) Regards Subbu From 775dde65217785f519efe2a202489a791460f861 Mon Sep 17 00:00:00 2001 From: C A Subramaniam subramaniam...@ti.com Date: Fri, 13 Nov 2009 16:42:40 +0530 Subject: [PATCH 8/10 v2] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox. This patch adds code changes in the mailbox driver module to add support for OMAP4 mailbox. Removed #ifdef CONFIG_ARCH_OMAP4 Signed-off-by: Hari Kanigeri h-kanige...@ti.com Signed-off-by: C A Subramaniam subramaniam...@ti.com Signed-off-by: Ramesh Gupta G grgu...@ti.com --- arch/arm/mach-omap2/mailbox.c | 140 ++--- arch/arm/plat-omap/mailbox.c | 25 ++-- 2 files changed, 136 insertions(+), 29 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 5ba3aa6..d20550f 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -18,6 +18,8 @@ #include plat/mailbox.h #include mach/irqs.h +#define DRV_NAME omap2-mailbox + #define MAILBOX_REVISION 0x000 #define MAILBOX_SYSCONFIG0x010 #define MAILBOX_SYSSTATUS0x014 @@ -27,8 +29,12 @@ #define MAILBOX_IRQSTATUS(u) (0x100 + 8 * (u)) #define MAILBOX_IRQENABLE(u) (0x104 + 8 * (u)) -#define MAILBOX_IRQ_NEWMSG(u)(1 (2 * (u))) -#define MAILBOX_IRQ_NOTFULL(u) (1 (2 * (u) + 1)) +#define OMAP4_MAILBOX_IRQSTATUS(u) (0x104 + 10 * (u)) +#define OMAP4_MAILBOX_IRQENABLE(u) (0x108 + 10 * (u)) +#define OMAP4_MAILBOX_IRQENABLE_CLR(u) (0x10c + 10 * (u)) + +#define MAILBOX_IRQ_NEWMSG(m)(1 (2 * (m))) +#define MAILBOX_IRQ_NOTFULL(m) (1 (2 * (m) + 1)) /* SYSCONFIG: register bit definition */ #define AUTOIDLE (1 0) @@ -39,7 +45,11 @@ #define RESETDONE(1 0) #define MBOX_REG_SIZE0x120 + +#define OMAP4_MBOX_REG_SIZE 0x130 + #define MBOX_NR_REGS (MBOX_REG_SIZE / sizeof(u32)) +#define OMAP4_MBOX_NR_REGS (OMAP4_MBOX_REG_SIZE / sizeof(u32)) Doesn't this modification break other OMAP arch support? We need to support OMAP2/3/4 mailbox with this file. static void __iomem *mbox_base; @@ -56,7 +66,8 @@ struct omap_mbox2_priv { unsigned long irqstatus; u32 newmsg_bit; u32 notfull_bit; - u32 ctx[MBOX_NR_REGS]; + u32 ctx[OMAP4_MBOX_REG_SIZE]; Is this only valid for OMAP4? -- To unsubscribe from this list: send the line unsubscribe 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 8/10 v2] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox.
-Original Message- From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] Sent: Wednesday, November 18, 2009 1:36 PM To: C.A, Subramaniam Cc: t...@atomide.com; linux-omap@vger.kernel.org; Kanigeri, Hari; Gupta, Ramesh Subject: Re: [PATCH 8/10 v2] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox. From: ext C.A, Subramaniam subramaniam...@ti.com Subject: [PATCH 8/10 v2] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox. Date: Tue, 17 Nov 2009 15:51:14 +0100 Hi Tony, Following is the version 2 of Patch 8/10 (removing all #fidefs) Regards Subbu From 775dde65217785f519efe2a202489a791460f861 Mon Sep 17 00:00:00 2001 From: C A Subramaniam subramaniam...@ti.com Date: Fri, 13 Nov 2009 16:42:40 +0530 Subject: [PATCH 8/10 v2] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox. This patch adds code changes in the mailbox driver module to add support for OMAP4 mailbox. Removed #ifdef CONFIG_ARCH_OMAP4 Signed-off-by: Hari Kanigeri h-kanige...@ti.com Signed-off-by: C A Subramaniam subramaniam...@ti.com Signed-off-by: Ramesh Gupta G grgu...@ti.com --- arch/arm/mach-omap2/mailbox.c | 140 ++--- arch/arm/plat-omap/mailbox.c | 25 ++-- 2 files changed, 136 insertions(+), 29 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 5ba3aa6..d20550f 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -18,6 +18,8 @@ #include plat/mailbox.h #include mach/irqs.h +#define DRV_NAME omap2-mailbox + #define MAILBOX_REVISION 0x000 #define MAILBOX_SYSCONFIG 0x010 #define MAILBOX_SYSSTATUS 0x014 @@ -27,8 +29,12 @@ #define MAILBOX_IRQSTATUS(u) (0x100 + 8 * (u)) #define MAILBOX_IRQENABLE(u) (0x104 + 8 * (u)) -#define MAILBOX_IRQ_NEWMSG(u) (1 (2 * (u))) -#define MAILBOX_IRQ_NOTFULL(u) (1 (2 * (u) + 1)) +#define OMAP4_MAILBOX_IRQSTATUS(u) (0x104 + 10 * (u)) +#define OMAP4_MAILBOX_IRQENABLE(u) (0x108 + 10 * (u)) +#define OMAP4_MAILBOX_IRQENABLE_CLR(u) (0x10c + 10 * (u)) + +#define MAILBOX_IRQ_NEWMSG(m) (1 (2 * (m))) +#define MAILBOX_IRQ_NOTFULL(m) (1 (2 * (m) + 1)) /* SYSCONFIG: register bit definition */ #define AUTOIDLE (1 0) @@ -39,7 +45,11 @@ #define RESETDONE (1 0) #define MBOX_REG_SIZE 0x120 + +#define OMAP4_MBOX_REG_SIZE0x130 + #define MBOX_NR_REGS (MBOX_REG_SIZE / sizeof(u32)) +#define OMAP4_MBOX_NR_REGS (OMAP4_MBOX_REG_SIZE / sizeof(u32)) Doesn't this modification break other OMAP arch support? We need to support OMAP2/3/4 mailbox with this file. static void __iomem *mbox_base; @@ -56,7 +66,8 @@ struct omap_mbox2_priv { unsigned long irqstatus; u32 newmsg_bit; u32 notfull_bit; - u32 ctx[MBOX_NR_REGS]; + u32 ctx[OMAP4_MBOX_REG_SIZE]; This reserves the array size to be max of both the values . However, while saving and restoring the context we decide on the size based on the arch snip-- static void omap2_mbox_save_ctx(struct omap_mbox *mbox) { int i; struct omap_mbox2_priv *p = mbox-priv; int nr_regs; if (cpu_is_omap44xx()) nr_regs = OMAP4_MBOX_NR_REGS; else nr_regs = MBOX_NR_REGS; for (i = 0; i nr_regs; i++) { p-ctx[i] = mbox_read_reg(i * sizeof(u32)); dev_dbg(mbox-dev, %s: [%02x] %08x\n, __func__, i, p-ctx[i]); } } static void omap2_mbox_restore_ctx(struct omap_mbox *mbox) { int i; struct omap_mbox2_priv *p = mbox-priv; int nr_regs; if (cpu_is_omap44xx()) nr_regs = OMAP4_MBOX_NR_REGS; else nr_regs = MBOX_NR_REGS; for (i = 0; i nr_regs; i++) { mbox_write_reg(p-ctx[i], i * sizeof(u32)); dev_dbg(mbox-dev, %s: [%02x] %08x\n, __func__, i, p-ctx[i]); } } ---snip-- Please provide your commnets on the same. Is this only valid for OMAP4? -- To unsubscribe from this list: send the line unsubscribe 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 8/10 v2] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox.
Hi Subb, From: ext C.A, Subramaniam subramaniam...@ti.com Subject: RE: [PATCH 8/10 v2] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox. Date: Wed, 18 Nov 2009 09:15:42 +0100 [...] /* SYSCONFIG: register bit definition */ #define AUTOIDLE (1 0) @@ -39,7 +45,11 @@ #define RESETDONE(1 0) #define MBOX_REG_SIZE0x120 + +#define OMAP4_MBOX_REG_SIZE 0x130 + #define MBOX_NR_REGS (MBOX_REG_SIZE / sizeof(u32)) +#define OMAP4_MBOX_NR_REGS (OMAP4_MBOX_REG_SIZE / sizeof(u32)) Doesn't this modification break other OMAP arch support? We need to support OMAP2/3/4 mailbox with this file. static void __iomem *mbox_base; @@ -56,7 +66,8 @@ struct omap_mbox2_priv { unsigned long irqstatus; u32 newmsg_bit; u32 notfull_bit; - u32 ctx[MBOX_NR_REGS]; + u32 ctx[OMAP4_MBOX_REG_SIZE]; This reserves the array size to be max of both the values . However, while saving and restoring the context we decide on the size based on the arch The max array reservation may work with other omap arch as well, but at least, shoulnd't the above ctx[OMAP4_MBOX_REG_SIZE] be ctx[OMAP4_MBOX_NR_REG]? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] OMAP3 hwmod: Add automatic OCP_SYSCONFIG AUTOIDLE handling
On Wed, Nov 18, 2009 at 6:35 AM, Kevin Hilman khil...@deeprootsystems.com wrote: From: Paul Walmsley p...@pwsan.com This patch fills in the OCP_SYSCONFIG.AUTOIDLE handling in the OMAP hwmod code. After this patch, the hwmod code will set the module AUTOIDLE bit (generally module.OCP_SYSCONFIG.AUTOIDLE) to 1 by default upon enable, and 1 upon disable. You wanted to say: 0 upon disable, isn't it? -vimal If the hwmod flag HWMOD_NO_AUTOIDLE is set, AUTOIDLE will be set to 0 upon enable. Enabling module autoidle should save some power. The only reason to not set the OCP_SYSCONFIG.AUTOIDLE bit is if there is a bug in the module RTL, e.g., the MPUINTC block on OMAP3. Comments from Kevin Hilman khil...@deeprootsystems.com inspired this patch. Signed-off-by: Paul Walmsley p...@pwsan.com Tested-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/omap_hwmod.c | 50 +++--- arch/arm/plat-omap/include/plat/omap_hwmod.h | 8 - 2 files changed, 52 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 7d7b3b8..25d9484 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -210,6 +210,29 @@ static int _set_softreset(struct omap_hwmod *oh, u32 *v) } /** + * _set_module_autoidle: set the OCP_SYSCONFIG AUTOIDLE field in @v + * @oh: struct omap_hwmod * + * @autoidle: desired AUTOIDLE bitfield value (0 or 1) + * @v: pointer to register contents to modify + * + * Update the module autoidle mode bit in @v to be @autoidle for the + * @oh hwmod. Does not write to the hardware. Returns -EINVAL upon + * error or 0 upon success. + */ +static int _set_module_autoidle(struct omap_hwmod *oh, u8 autoidle, + u32 *v) +{ + if (!oh-sysconfig || + !(oh-sysconfig-sysc_flags SYSC_HAS_AUTOIDLE)) + return -EINVAL; + + *v = ~SYSC_AUTOIDLE_MASK; + *v |= autoidle SYSC_AUTOIDLE_SHIFT; + + return 0; +} + +/** * _enable_wakeup: set OCP_SYSCONFIG.ENAWAKEUP bit in the hardware * @oh: struct omap_hwmod * * @@ -560,7 +583,13 @@ static void _sysc_enable(struct omap_hwmod *oh) _set_master_standbymode(oh, idlemode, v); } - /* XXX OCP AUTOIDLE bit? */ + if (oh-sysconfig-sysc_flags SYSC_HAS_AUTOIDLE) { + idlemode = (oh-flags HWMOD_NO_AUTOIDLE) ? + 0 : 1; + _set_module_autoidle(oh, idlemode, v); + } + + /* XXX OCP ENAWAKEUP bit? */ if (oh-flags HWMOD_SET_DEFAULT_CLOCKACT oh-sysconfig-sysc_flags SYSC_HAS_CLOCKACTIVITY) @@ -625,7 +654,8 @@ static void _sysc_shutdown(struct omap_hwmod *oh) if (oh-sysconfig-sysc_flags SYSC_HAS_MIDLEMODE) _set_master_standbymode(oh, HWMOD_IDLEMODE_FORCE, v); - /* XXX clear OCP AUTOIDLE bit? */ + if (oh-sysconfig-sysc_flags SYSC_HAS_AUTOIDLE) + _set_module_autoidle(oh, 1, v); _write_sysconfig(v, oh); } @@ -951,11 +981,21 @@ static int _setup(struct omap_hwmod *oh) _enable(oh); - if (!(oh-flags HWMOD_INIT_NO_RESET)) + if (!(oh-flags HWMOD_INIT_NO_RESET)) { _reset(oh); - /* XXX OCP AUTOIDLE bit? */ - /* XXX OCP ENAWAKEUP bit? */ + /* + * XXX Do the OCP_SYSCONFIG bits need to be + * reprogrammed after a reset? If not, then this can + * be removed. If it does, then probably the + * _enable() function should be split to avoid the + * rewrite of the OCP_SYSCONFIG register. + */ + if (oh-sysconfig) { + _update_sysc_cache(oh); + _sysc_enable(oh); + } + } if (!(oh-flags HWMOD_INIT_NO_IDLE)) _idle(oh); diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h index dbdd123..ec140b0 100644 --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h @@ -50,6 +50,8 @@ struct omap_device; #define SYSC_ENAWAKEUP_MASK (1 SYSC_ENAWAKEUP_SHIFT) #define SYSC_SOFTRESET_SHIFT 1 #define SYSC_SOFTRESET_MASK (1 SYSC_SOFTRESET_SHIFT) +#define SYSC_AUTOIDLE_SHIFT 0 +#define SYSC_AUTOIDLE_MASK (1 SYSC_AUTOIDLE_SHIFT) /* OCP SYSSTATUS bit shifts/masks */ #define SYSS_RESETDONE_SHIFT 0 @@ -294,13 +296,17 @@ struct omap_hwmod_omap4_prcm { * SDRAM controller, etc. * HWMOD_INIT_NO_IDLE: don't idle this module at boot - important for SDRAM * controller, etc. + * HWMOD_NO_AUTOIDLE: disable module autoidle (OCP_SYSCONFIG.AUTOIDLE) + * when module is enabled, rather than the default, which is to + *
[PATCH] ZOOM2: PM: Add T2 keypad as wakeup source for Zoom2
From: Lesly A M x0080...@ti.com Zoom2: Add T2 Keypad as a wakeup source Changes for setting the padconf value for sys_nirq line which is connected to T2 INTR1. This will fix the T2 keypad wakeup. Signed-off-by: Lesly A M x0080...@ti.com Signed-off-by: Teerth Reddy tee...@ti.com --- arch/arm/mach-omap2/board-zoom2.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-zoom2.c b/arch/arm/mach-omap2/board-zoom2.c index 10b50f1..367215c 100644 --- a/arch/arm/mach-omap2/board-zoom2.c +++ b/arch/arm/mach-omap2/board-zoom2.c @@ -18,6 +18,7 @@ #include asm/mach-types.h #include asm/mach/arch.h +#include plat/mux.h #include plat/common.h #include plat/board.h @@ -66,10 +67,16 @@ static struct twl4030_platform_data zoom2_twldata = { extern int __init omap_zoom2_debugboard_init(void); extern void __init zoom_peripherals_init(void); +static void enable_board_wakeup_source(void) +{ + omap_cfg_reg(AF26_34XX_SYS_NIRQ); /* T2 interrupt line */ +} + static void __init omap_zoom2_init(void) { zoom_peripherals_init(); omap_zoom2_debugboard_init(); + enable_board_wakeup_source(); } static void __init omap_zoom2_map_io(void) -- To unsubscribe from this list: send the line unsubscribe 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: Scalling_setspeed doesn't work
You need to use userspace governor before trying to set speed using scalling_setspeed. Can you pls confirm that? You can select userspace governor by using below command echo userspace /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor Vishwa -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of tarek attia Sent: Tuesday, November 17, 2009 10:28 PM To: linux-omap Subject: Scalling_setspeed doesn't work When I try to change the value of (scalling_setspeed) file ,it doesn't change however it doesn't rise errors as well,,but after changing it and trying to rereading it ,I found that nothing is changed !!!? BTW:-I'm using Linux kernel(2.6.29) on the beagleboard with the power management branch Any help will be appreciated . Best Regards, tarek -- To unsubscribe from this list: send the line unsubscribe 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
[PATCH] ZOOM2: PM: Add T2 keypad as wakeup source for Zoom2
From: Lesly A M x0080...@ti.com Zoom2: Add T2 Keypad as a wakeup source Changes for setting the padconf value for sys_nirq line which is connected to T2 INTR1. This will fix the T2 keypad wakeup. Signed-off-by: Lesly A M x0080...@ti.com Signed-off-by: Teerth Reddy tee...@ti.com --- arch/arm/mach-omap2/board-zoom2.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-zoom2.c b/arch/arm/mach-omap2/board-zoom2.c index 10b50f1..367215c 100644 --- a/arch/arm/mach-omap2/board-zoom2.c +++ b/arch/arm/mach-omap2/board-zoom2.c @@ -18,6 +18,7 @@ #include asm/mach-types.h #include asm/mach/arch.h +#include plat/mux.h #include plat/common.h #include plat/board.h @@ -66,10 +67,16 @@ static struct twl4030_platform_data zoom2_twldata = { extern int __init omap_zoom2_debugboard_init(void); extern void __init zoom_peripherals_init(void); +static void enable_board_wakeup_source(void) +{ + omap_cfg_reg(AF26_34XX_SYS_NIRQ); /* T2 interrupt line */ +} + static void __init omap_zoom2_init(void) { zoom_peripherals_init(); omap_zoom2_debugboard_init(); + enable_board_wakeup_source(); } static void __init omap_zoom2_map_io(void) -- To unsubscribe from this list: send the line unsubscribe 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 8/10 v2] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox.
-Original Message- From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] Sent: Wednesday, November 18, 2009 2:01 PM To: C.A, Subramaniam Cc: t...@atomide.com; linux-omap@vger.kernel.org; Kanigeri, Hari; Gupta, Ramesh Subject: Re: [PATCH 8/10 v2] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox. Hi Subb, From: ext C.A, Subramaniam subramaniam...@ti.com Subject: RE: [PATCH 8/10 v2] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox. Date: Wed, 18 Nov 2009 09:15:42 +0100 [...] /* SYSCONFIG: register bit definition */ #define AUTOIDLE (1 0) @@ -39,7 +45,11 @@ #define RESETDONE (1 0) #define MBOX_REG_SIZE 0x120 + +#define OMAP4_MBOX_REG_SIZE0x130 + #define MBOX_NR_REGS (MBOX_REG_SIZE / sizeof(u32)) +#define OMAP4_MBOX_NR_REGS (OMAP4_MBOX_REG_SIZE / sizeof(u32)) Doesn't this modification break other OMAP arch support? We need to support OMAP2/3/4 mailbox with this file. static void __iomem *mbox_base; @@ -56,7 +66,8 @@ struct omap_mbox2_priv { unsigned long irqstatus; u32 newmsg_bit; u32 notfull_bit; - u32 ctx[MBOX_NR_REGS]; + u32 ctx[OMAP4_MBOX_REG_SIZE]; This reserves the array size to be max of both the values . However, while saving and restoring the context we decide on the size based on the arch The max array reservation may work with other omap arch as well, but at least, shoulnd't the above ctx[OMAP4_MBOX_REG_SIZE] be ctx[OMAP4_MBOX_NR_REG]? Hi Hiroshi, Yes my bad. Thank you pointing that out. I will change and send the patch afresh. -- To unsubscribe from this list: send the line unsubscribe 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] ZOOM2: PM: Add T2 keypad as wakeup source for Zoom2
This patch should be generated for arch/arm/mach-omap2/board-zoom-peripherals.c, since it is common for zoom2 and zoom3 boards. Am I right? -Manjunath -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Reddy, Teerth Sent: Wednesday, November 18, 2009 2:23 PM To: linux-omap@vger.kernel.org Cc: khil...@deeprootsystems.com Subject: [PATCH] ZOOM2: PM: Add T2 keypad as wakeup source for Zoom2 From: Lesly A M x0080...@ti.com Zoom2: Add T2 Keypad as a wakeup source Changes for setting the padconf value for sys_nirq line which is connected to T2 INTR1. This will fix the T2 keypad wakeup. Signed-off-by: Lesly A M x0080...@ti.com Signed-off-by: Teerth Reddy tee...@ti.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: [PATCH V2] FIX OMAP3:McBSP poll read and write for OMAP3
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, November 13, 2009 2:41 AM To: Varadarajan, Charu Latha Cc: linux-omap@vger.kernel.org; Syed, Rafiuddin Subject: Re: [PATCH V2] FIX OMAP3:McBSP poll read and write for OMAP3 * ch...@ti.com ch...@ti.com [091019 23:41]: omap_mcbsp_pollwrite and omap_mcbsp_pollread functions access McBSP registers as 16-bit registers. In OMAP3, McBSP registers (DRR_REG and DXR_REG) are limited to 32-bit data accesses (L4 Interconnect). 16-bit and 8-bit is not allowed and can corrupt register content. This patch adds omap3_mcbsp_pollwrite and omap3_mcbsp_pollread functions for OMAP3 cpu, inorder to perform 32 bit access of above mentioned McBSP registers. How about making the functions generic, I don't think we want to have separate omap1_mcbsp_pollread, omap2_mcbsp_pollread, omap3_mcbsp_pollread.. If it's not obvious how to implement it for some omap, just return an error based on the CPU type. My v1 patch handles this in a single generic API. [http://www.spinics.net/lists/linux-omap/msg19074.html and http://patchwork.kernel.org/patch/53631/] As per the review comments received for v1 patch, v2 patch is modified to have new API omap3_mcbsp_pollread/write in addition to omap_mcbsp_pollread/write APIs. Review comments for V1 mentioned that API signartures should not be changed from 16bit to 32 bit input parameters. If the API needs to be made generic, API signature has to be modified as given below (as in patch v1): -int omap_mcbsp_pollread(unsigned int id, u16 *buf) +int omap_mcbsp_pollread(unsigned int id, u32 *buf) If agreed for this generic API change, I shall post v3 patch which would handle cputypes dynamically inside the API Regards, Tony Signed-off-by: Charulatha V ch...@ti.com Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com --- arch/arm/plat-omap/include/mach/mcbsp.h |4 + arch/arm/plat-omap/mcbsp.c | 92 ++- 2 files changed, 95 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index 0c5f937..b0f9260 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -406,6 +406,10 @@ void omap_mcbsp_set_spi_mode(unsigned int id, const struct omap_mcbsp_spi_cfg * /* Polled read/write functions */ int omap_mcbsp_pollread(unsigned int id, u16 * buf); int omap_mcbsp_pollwrite(unsigned int id, u16 buf); + +int omap3_mcbsp_pollread(unsigned int id, u32 *buf); +int omap3_mcbsp_pollwrite(unsigned int id, u32 buf); + int omap_mcbsp_set_io_type(unsigned int id, omap_mcbsp_io_type_t io_type); #endif snip-- To unsubscribe from this list: send the line unsubscribe 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 (for-next)] ASoC: Add support for IGEP v2
(adding ALSA list to CC) Enric Balletbo i Serra wrote: From: Enric Balletbo i Serra eballe...@iseebcn.com Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com --- arch/arm/mach-omap2/Kconfig |2 +- sound/soc/omap/Kconfig |7 ++ sound/soc/omap/Makefile |2 + sound/soc/omap/igep0020.c | 148 +++ 4 files changed, 158 insertions(+), 1 deletions(-) create mode 100644 sound/soc/omap/igep0020.c diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 68866f3..6922198 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -114,7 +114,7 @@ config MACH_OMAP_3630SDP depends on ARCH_OMAP3 ARCH_OMAP34XX config MACH_IGEP0020 - bool IGEP0020 + bool IGEP v2 board depends on ARCH_OMAP3 ARCH_OMAP34XX config MACH_OMAP_4430SDP diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index 653a362..5cc8a63 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -99,3 +99,10 @@ config SND_OMAP_SOC_ZOOM2 help Say Y if you want to add support for Soc audio on Zoom2 board. +config SND_OMAP_SOC_IGEP0020 + tristate SoC Audio support for IGEP v2 + depends on TWL4030_CORE SND_OMAP_SOC MACH_IGEP0020 + select SND_OMAP_SOC_MCBSP + select SND_SOC_TWL4030 + help + Say Y if you want to add support for Soc audio on IGEP v2 board. diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index 02d6947..d4ed23a 100644 --- a/sound/soc/omap/Makefile +++ b/sound/soc/omap/Makefile @@ -16,6 +16,7 @@ snd-soc-sdp3430-objs := sdp3430.o snd-soc-omap3pandora-objs := omap3pandora.o snd-soc-omap3beagle-objs := omap3beagle.o snd-soc-zoom2-objs := zoom2.o +snd-soc-igep0020-objs := igep0020.o obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o obj-$(CONFIG_SND_OMAP_SOC_AMS_DELTA) += snd-soc-ams-delta.o @@ -27,3 +28,4 @@ obj-$(CONFIG_SND_OMAP_SOC_SDP3430) += snd-soc-sdp3430.o obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-omap3pandora.o obj-$(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE) += snd-soc-omap3beagle.o obj-$(CONFIG_SND_OMAP_SOC_ZOOM2) += snd-soc-zoom2.o +obj-$(CONFIG_SND_OMAP_SOC_IGEP0020) += snd-soc-igep0020.o diff --git a/sound/soc/omap/igep0020.c b/sound/soc/omap/igep0020.c new file mode 100644 index 000..3583c42 --- /dev/null +++ b/sound/soc/omap/igep0020.c @@ -0,0 +1,148 @@ +/* + * igep0020.c -- SoC audio for IGEP v2 + * + * Based on sound/soc/omap/overo.c by Steve Sakoman + * + * 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. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ + +#include linux/clk.h +#include linux/platform_device.h +#include sound/core.h +#include sound/pcm.h +#include sound/soc.h +#include sound/soc-dapm.h + +#include asm/mach-types.h +#include mach/hardware.h +#include mach/gpio.h +#include plat/mcbsp.h + +#include omap-mcbsp.h +#include omap-pcm.h +#include ../codecs/twl4030.h + +static int igep2_hw_params(struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *params) +{ + struct snd_soc_pcm_runtime *rtd = substream-private_data; + struct snd_soc_dai *codec_dai = rtd-dai-codec_dai; + struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai; + int ret; + + /* Set codec DAI configuration */ + ret = snd_soc_dai_set_fmt(codec_dai, + SND_SOC_DAIFMT_I2S | + SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBM_CFM); + if (ret 0) { + printk(KERN_ERR can't set codec DAI configuration\n); + return ret; + } + + /* Set cpu DAI configuration */ + ret = snd_soc_dai_set_fmt(cpu_dai, + SND_SOC_DAIFMT_I2S | + SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBM_CFM); + if (ret 0) { + printk(KERN_ERR can't set cpu DAI configuration\n); + return ret; + } + + /* Set the codec system clock for DAC and ADC */ + ret = snd_soc_dai_set_sysclk(codec_dai, 0, 2600, + SND_SOC_CLOCK_IN); + if (ret 0) { + printk(KERN_ERR can't set codec system clock\n); + return ret; + } + + return 0; +} +
RE: [PATCH (for-next)] ASoC: Add support for IGEP v2
Mike Rapoport wrote: Enric Balletbo i Serra wrote: From: Enric Balletbo i Serra eballe...@iseebcn.com Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com --- arch/arm/mach-omap2/Kconfig |2 +- sound/soc/omap/Kconfig |7 ++ sound/soc/omap/Makefile |2 + sound/soc/omap/igep0020.c | 148 +++ 4 files changed, 158 insertions(+), 1 deletions(-) create mode 100644 sound/soc/omap/igep0020.c diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 68866f3..6922198 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -114,7 +114,7 @@ config MACH_OMAP_3630SDP depends on ARCH_OMAP3 ARCH_OMAP34XX config MACH_IGEP0020 - bool IGEP0020 + bool IGEP v2 board depends on ARCH_OMAP3 ARCH_OMAP34XX config MACH_OMAP_4430SDP This part isn't relevant to ASoC. Shouldn't it go separately through linux-omap? It could possibly get folded into the patch adding this board support in the first place. - Anand -- To unsubscribe from this list: send the line unsubscribe 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 (for-next)] ASoC: Add support for IGEP v2
This part isn't relevant to ASoC. Shouldn't it go separately through linux-omap? It could possibly get folded into the patch adding this board support in the first place. - Anand Oops, sorry is a mistake I will resend the patch without this. Thanks, Enric 2009/11/18 Gadiyar, Anand gadi...@ti.com: Mike Rapoport wrote: Enric Balletbo i Serra wrote: From: Enric Balletbo i Serra eballe...@iseebcn.com Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com --- arch/arm/mach-omap2/Kconfig | 2 +- sound/soc/omap/Kconfig | 7 ++ sound/soc/omap/Makefile | 2 + sound/soc/omap/igep0020.c | 148 +++ 4 files changed, 158 insertions(+), 1 deletions(-) create mode 100644 sound/soc/omap/igep0020.c diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 68866f3..6922198 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -114,7 +114,7 @@ config MACH_OMAP_3630SDP depends on ARCH_OMAP3 ARCH_OMAP34XX config MACH_IGEP0020 - bool IGEP0020 + bool IGEP v2 board depends on ARCH_OMAP3 ARCH_OMAP34XX config MACH_OMAP_4430SDP -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [alsa-devel] Artifacts present in AIC23 capture for 48 KHz sampling rate
-Original Message- From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] Sent: Wednesday, November 18, 2009 12:39 AM To: Aggarwal, Anuj Cc: alsa-de...@alsa-project.org; linux-omap@vger.kernel.org Subject: Re: [alsa-devel] Artifacts present in AIC23 capture for 48 KHz sampling rate Aggarwal, Anuj wrote: -Original Message- From: Aggarwal, Anuj Sent: Friday, November 06, 2009 6:28 PM To: alsa-de...@alsa-project.org; 'linux-omap@vger.kernel.org' Subject: Artifacts present in AIC23 capture for 48 KHz sampling rate Hi, I am observing artifacts (sharp spikes at fixed intervals) while capturing audio on AM3517 EVM and AIC23 codec. They are present only in one of the channels when I am capturing at 48 KHz. All other sampling rates are working fine with the above said combination. I have also attached the screenshot taken with the help of Audacity utility. Here, I tried recording silence but artifacts were observed on one channel. Has anyone also observed the similar behavior with AIC23 codec? Any hints on what could be the root cause? [Aggarwal, Anuj] On further debugging, I found that the function find_rate() in sound/soc/codecs/tlv320aic23.c is not returning the correct value for capture in 48KHz sample rate. In USB mode (MCLK=12MHz), for 48KHz, it returns 0x7D (CLKOUT=0, CLKIN=1, SR[3:0]=0xF, BOSR=1, Normal=1) whereas as per the AIC23B spec, 0x7D would be BOSR = 0, USB/NORMAL = 1, SR=0xff, div2 = 1 The bug is with sr_valid_mask, static const unsigned short sr_valid_mask[] = { LOWER_GROUP|UPPER_GROUP,/* Normal, bosr - 0*/ LOWER_GROUP|UPPER_GROUP,/* Normal, bosr - 1*/ LOWER_GROUP,/* Usb, bosr - 0*/ UPPER_GROUP,/* Usb, bosr - 1*/ }; should be static const unsigned short sr_valid_mask[] = { LOWER_GROUP|UPPER_GROUP,/* Normal, bosr - 0*/ LOWER_GROUP,/* Usb, bosr - 0*/ LOWER_GROUP|UPPER_GROUP,/* Normal, bosr - 1*/ UPPER_GROUP,/* Usb, bosr - 1*/ }; Can you give this a try and let me know? [Aggarwal, Anuj] I tried this on AM3517 EVM + AIC23B; it works fine for me. But I have tested the fix only with a 12 MHz clock. Thanks for quickly fixing this. Thanks Troy -- To unsubscribe from this list: send the line unsubscribe 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 8/10 v3] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox.
Hi Tony, Following is the version 3 of patch 8/10. It removes one typo in the v2 patch that I sent out earlier. Request you to take this version of the patch. Hiroshi, Thank you for pointing out the error. Request you to please review the patch. Regards Subbu From 989d89b561ca176ddba19b0fcb5df1c2bec90d6d Mon Sep 17 00:00:00 2001 From: C A Subramaniam subramaniam...@ti.com Date: Fri, 13 Nov 2009 16:42:40 +0530 Subject: [PATCH 8/10 v3] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox. This patch adds code changes in the mailbox driver module to add support for OMAP4 mailbox. Removed #ifdefs for OMAP4 Signed-off-by: Hari Kanigeri h-kanige...@ti.com Signed-off-by: C A Subramaniam subramaniam...@ti.com Signed-off-by: Ramesh Gupta G grgu...@ti.com Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com --- arch/arm/mach-omap2/mailbox.c | 140 ++--- arch/arm/plat-omap/mailbox.c | 25 ++-- 2 files changed, 136 insertions(+), 29 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 5ba3aa6..281ab63 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -18,6 +18,8 @@ #include plat/mailbox.h #include mach/irqs.h +#define DRV_NAME omap2-mailbox + #define MAILBOX_REVISION 0x000 #define MAILBOX_SYSCONFIG 0x010 #define MAILBOX_SYSSTATUS 0x014 @@ -27,8 +29,12 @@ #define MAILBOX_IRQSTATUS(u) (0x100 + 8 * (u)) #define MAILBOX_IRQENABLE(u) (0x104 + 8 * (u)) -#define MAILBOX_IRQ_NEWMSG(u) (1 (2 * (u))) -#define MAILBOX_IRQ_NOTFULL(u) (1 (2 * (u) + 1)) +#define OMAP4_MAILBOX_IRQSTATUS(u) (0x104 + 10 * (u)) +#define OMAP4_MAILBOX_IRQENABLE(u) (0x108 + 10 * (u)) +#define OMAP4_MAILBOX_IRQENABLE_CLR(u) (0x10c + 10 * (u)) + +#define MAILBOX_IRQ_NEWMSG(m) (1 (2 * (m))) +#define MAILBOX_IRQ_NOTFULL(m) (1 (2 * (m) + 1)) /* SYSCONFIG: register bit definition */ #define AUTOIDLE (1 0) @@ -39,7 +45,11 @@ #define RESETDONE (1 0) #define MBOX_REG_SIZE 0x120 + +#define OMAP4_MBOX_REG_SIZE0x130 + #define MBOX_NR_REGS (MBOX_REG_SIZE / sizeof(u32)) +#define OMAP4_MBOX_NR_REGS (OMAP4_MBOX_REG_SIZE / sizeof(u32)) static void __iomem *mbox_base; @@ -56,7 +66,8 @@ struct omap_mbox2_priv { unsigned long irqstatus; u32 newmsg_bit; u32 notfull_bit; - u32 ctx[MBOX_NR_REGS]; + u32 ctx[OMAP4_MBOX_NR_REGS]; + unsigned long irqdisable; }; static struct clk *mbox_ick_handle; @@ -82,8 +93,9 @@ static int omap2_mbox_startup(struct omap_mbox *mbox) mbox_ick_handle = clk_get(NULL, mailboxes_ick); if (IS_ERR(mbox_ick_handle)) { - pr_err(Can't get mailboxes_ick\n); - return -ENODEV; + printk(KERN_ERR Could not get mailboxes_ick: %d\n, + PTR_ERR(mbox_ick_handle)); + return PTR_ERR(mbox_ick_handle); } clk_enable(mbox_ick_handle); @@ -115,6 +127,7 @@ static void omap2_mbox_shutdown(struct omap_mbox *mbox) { clk_disable(mbox_ick_handle); clk_put(mbox_ick_handle); + mbox_ick_handle = NULL; } /* Mailbox FIFO handle functions */ @@ -143,7 +156,7 @@ static int omap2_mbox_fifo_full(struct omap_mbox *mbox) { struct omap_mbox2_fifo *fifo = ((struct omap_mbox2_priv *)mbox-priv)-tx_fifo; - return (mbox_read_reg(fifo-fifo_stat)); + return mbox_read_reg(fifo-fifo_stat); } /* Mailbox IRQ handle functions */ @@ -163,10 +176,9 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox, { struct omap_mbox2_priv *p = (struct omap_mbox2_priv *)mbox-priv; u32 l, bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit; - - l = mbox_read_reg(p-irqenable); + l = mbox_read_reg(p-irqdisable); l = ~bit; - mbox_write_reg(l, p-irqenable); + mbox_write_reg(l, p-irqdisable); } static void omap2_mbox_ack_irq(struct omap_mbox *mbox, @@ -189,15 +201,19 @@ static int omap2_mbox_is_irq(struct omap_mbox *mbox, u32 enable = mbox_read_reg(p-irqenable); u32 status = mbox_read_reg(p-irqstatus); - return (enable status bit); + return (int)(enable status bit); } static void omap2_mbox_save_ctx(struct omap_mbox *mbox) { int i; struct omap_mbox2_priv *p = mbox-priv; - - for (i = 0; i MBOX_NR_REGS; i++) { + int nr_regs; + if (cpu_is_omap44xx()) + nr_regs = OMAP4_MBOX_NR_REGS; + else + nr_regs = MBOX_NR_REGS; + for (i = 0; i nr_regs; i++) { p-ctx[i] = mbox_read_reg(i * sizeof(u32)); dev_dbg(mbox-dev, %s: [%02x] %08x\n, __func__, @@ -209,8 +225,12 @@ static void omap2_mbox_restore_ctx(struct omap_mbox *mbox) { int i; struct
[PATCH (for-next 2)] ASoC: Add support for IGEP v2
From: Enric Balletbo i Serra eballe...@iseebcn.com Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com --- sound/soc/omap/Kconfig|7 ++ sound/soc/omap/Makefile |2 + sound/soc/omap/igep0020.c | 148 + 3 files changed, 157 insertions(+), 0 deletions(-) create mode 100644 sound/soc/omap/igep0020.c diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index 653a362..5cc8a63 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -99,3 +99,10 @@ config SND_OMAP_SOC_ZOOM2 help Say Y if you want to add support for Soc audio on Zoom2 board. +config SND_OMAP_SOC_IGEP0020 + tristate SoC Audio support for IGEP v2 + depends on TWL4030_CORE SND_OMAP_SOC MACH_IGEP0020 + select SND_OMAP_SOC_MCBSP + select SND_SOC_TWL4030 + help + Say Y if you want to add support for Soc audio on IGEP v2 board. diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index 02d6947..d4ed23a 100644 --- a/sound/soc/omap/Makefile +++ b/sound/soc/omap/Makefile @@ -16,6 +16,7 @@ snd-soc-sdp3430-objs := sdp3430.o snd-soc-omap3pandora-objs := omap3pandora.o snd-soc-omap3beagle-objs := omap3beagle.o snd-soc-zoom2-objs := zoom2.o +snd-soc-igep0020-objs := igep0020.o obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o obj-$(CONFIG_SND_OMAP_SOC_AMS_DELTA) += snd-soc-ams-delta.o @@ -27,3 +28,4 @@ obj-$(CONFIG_SND_OMAP_SOC_SDP3430) += snd-soc-sdp3430.o obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-omap3pandora.o obj-$(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE) += snd-soc-omap3beagle.o obj-$(CONFIG_SND_OMAP_SOC_ZOOM2) += snd-soc-zoom2.o +obj-$(CONFIG_SND_OMAP_SOC_IGEP0020) += snd-soc-igep0020.o diff --git a/sound/soc/omap/igep0020.c b/sound/soc/omap/igep0020.c new file mode 100644 index 000..3583c42 --- /dev/null +++ b/sound/soc/omap/igep0020.c @@ -0,0 +1,148 @@ +/* + * igep0020.c -- SoC audio for IGEP v2 + * + * Based on sound/soc/omap/overo.c by Steve Sakoman + * + * 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. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ + +#include linux/clk.h +#include linux/platform_device.h +#include sound/core.h +#include sound/pcm.h +#include sound/soc.h +#include sound/soc-dapm.h + +#include asm/mach-types.h +#include mach/hardware.h +#include mach/gpio.h +#include plat/mcbsp.h + +#include omap-mcbsp.h +#include omap-pcm.h +#include ../codecs/twl4030.h + +static int igep2_hw_params(struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *params) +{ + struct snd_soc_pcm_runtime *rtd = substream-private_data; + struct snd_soc_dai *codec_dai = rtd-dai-codec_dai; + struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai; + int ret; + + /* Set codec DAI configuration */ + ret = snd_soc_dai_set_fmt(codec_dai, + SND_SOC_DAIFMT_I2S | + SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBM_CFM); + if (ret 0) { + printk(KERN_ERR can't set codec DAI configuration\n); + return ret; + } + + /* Set cpu DAI configuration */ + ret = snd_soc_dai_set_fmt(cpu_dai, + SND_SOC_DAIFMT_I2S | + SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBM_CFM); + if (ret 0) { + printk(KERN_ERR can't set cpu DAI configuration\n); + return ret; + } + + /* Set the codec system clock for DAC and ADC */ + ret = snd_soc_dai_set_sysclk(codec_dai, 0, 2600, + SND_SOC_CLOCK_IN); + if (ret 0) { + printk(KERN_ERR can't set codec system clock\n); + return ret; + } + + return 0; +} + +static struct snd_soc_ops igep2_ops = { + .hw_params = igep2_hw_params, +}; + +/* Digital audio interface glue - connects codec -- CPU */ +static struct snd_soc_dai_link igep2_dai = { + .name = TWL4030, + .stream_name = TWL4030, + .cpu_dai = omap_mcbsp_dai[0], + .codec_dai = twl4030_dai[TWL4030_DAI_HIFI], + .ops = igep2_ops, +}; + +/* Audio machine driver */ +static struct snd_soc_card snd_soc_card_igep2 = { + .name = igep2, + .platform = omap_soc_platform, + .dai_link = igep2_dai, + .num_links =
RE: [PATCH] ZOOM2: PM: Add T2 keypad as wakeup source for Zoom2
Will move the wakeup source to arch/arm/mach-omap2/board-zoom-peripherals.c and send the patch. Regards Teerth -Original Message- From: G, Manjunath Kondaiah Sent: Wednesday, November 18, 2009 2:26 PM To: Reddy, Teerth; linux-omap@vger.kernel.org Cc: khil...@deeprootsystems.com Subject: RE: [PATCH] ZOOM2: PM: Add T2 keypad as wakeup source for Zoom2 This patch should be generated for arch/arm/mach-omap2/board-zoom-peripherals.c, since it is common for zoom2 and zoom3 boards. Am I right? -Manjunath -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Reddy, Teerth Sent: Wednesday, November 18, 2009 2:23 PM To: linux-omap@vger.kernel.org Cc: khil...@deeprootsystems.com Subject: [PATCH] ZOOM2: PM: Add T2 keypad as wakeup source for Zoom2 From: Lesly A M x0080...@ti.com Zoom2: Add T2 Keypad as a wakeup source Changes for setting the padconf value for sys_nirq line which is connected to T2 INTR1. This will fix the T2 keypad wakeup. Signed-off-by: Lesly A M x0080...@ti.com Signed-off-by: Teerth Reddy tee...@ti.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
[PATCH] ZOOM2: PM: Add T2 keypad as wakeup source for Zoom2
From: Lesly A M x0080...@ti.com Zoom2: Add T2 Keypad as a wakeup source Changes for setting the padconf value for sys_nirq line which is connected to T2 INTR1. This will fix the T2 keypad wakeup. Signed-off-by: Lesly A M x0080...@ti.com Signed-off-by: Teerth Reddy tee...@ti.com --- arch/arm/mach-omap2/board-zoom-peripherals.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-omap2/board-zoom-peripherals.c index f14baa3..d5ed73f 100755 --- a/arch/arm/mach-omap2/board-zoom-peripherals.c +++ b/arch/arm/mach-omap2/board-zoom-peripherals.c @@ -21,6 +21,7 @@ #include asm/mach/arch.h #include asm/mach/map.h +#include plat/mux.h #include plat/common.h #include plat/usb.h @@ -259,9 +260,15 @@ static int __init omap_i2c_init(void) return 0; } +static void enable_board_wakeup_source(void) +{ + omap_cfg_reg(AF26_34XX_SYS_NIRQ); /* T2 interrupt line */ +} + void __init zoom_peripherals_init(void) { omap_i2c_init(); omap_serial_init(); usb_musb_init(); + enable_board_wakeup_source(); } -- To unsubscribe from this list: send the line unsubscribe 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 (for-next 2)] ASoC: Add support for IGEP v2
(adding ALSA mailing list to CC again :) ) Enric Balletbo i Serra wrote: From: Enric Balletbo i Serra eballe...@iseebcn.com Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com --- sound/soc/omap/Kconfig|7 ++ sound/soc/omap/Makefile |2 + sound/soc/omap/igep0020.c | 148 + 3 files changed, 157 insertions(+), 0 deletions(-) create mode 100644 sound/soc/omap/igep0020.c diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index 653a362..5cc8a63 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -99,3 +99,10 @@ config SND_OMAP_SOC_ZOOM2 help Say Y if you want to add support for Soc audio on Zoom2 board. +config SND_OMAP_SOC_IGEP0020 + tristate SoC Audio support for IGEP v2 + depends on TWL4030_CORE SND_OMAP_SOC MACH_IGEP0020 + select SND_OMAP_SOC_MCBSP + select SND_SOC_TWL4030 + help + Say Y if you want to add support for Soc audio on IGEP v2 board. diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index 02d6947..d4ed23a 100644 --- a/sound/soc/omap/Makefile +++ b/sound/soc/omap/Makefile @@ -16,6 +16,7 @@ snd-soc-sdp3430-objs := sdp3430.o snd-soc-omap3pandora-objs := omap3pandora.o snd-soc-omap3beagle-objs := omap3beagle.o snd-soc-zoom2-objs := zoom2.o +snd-soc-igep0020-objs := igep0020.o obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o obj-$(CONFIG_SND_OMAP_SOC_AMS_DELTA) += snd-soc-ams-delta.o @@ -27,3 +28,4 @@ obj-$(CONFIG_SND_OMAP_SOC_SDP3430) += snd-soc-sdp3430.o obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-omap3pandora.o obj-$(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE) += snd-soc-omap3beagle.o obj-$(CONFIG_SND_OMAP_SOC_ZOOM2) += snd-soc-zoom2.o +obj-$(CONFIG_SND_OMAP_SOC_IGEP0020) += snd-soc-igep0020.o diff --git a/sound/soc/omap/igep0020.c b/sound/soc/omap/igep0020.c new file mode 100644 index 000..3583c42 --- /dev/null +++ b/sound/soc/omap/igep0020.c @@ -0,0 +1,148 @@ +/* + * igep0020.c -- SoC audio for IGEP v2 + * + * Based on sound/soc/omap/overo.c by Steve Sakoman + * + * 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. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ + +#include linux/clk.h +#include linux/platform_device.h +#include sound/core.h +#include sound/pcm.h +#include sound/soc.h +#include sound/soc-dapm.h + +#include asm/mach-types.h +#include mach/hardware.h +#include mach/gpio.h +#include plat/mcbsp.h + +#include omap-mcbsp.h +#include omap-pcm.h +#include ../codecs/twl4030.h + +static int igep2_hw_params(struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *params) +{ + struct snd_soc_pcm_runtime *rtd = substream-private_data; + struct snd_soc_dai *codec_dai = rtd-dai-codec_dai; + struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai; + int ret; + + /* Set codec DAI configuration */ + ret = snd_soc_dai_set_fmt(codec_dai, + SND_SOC_DAIFMT_I2S | + SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBM_CFM); + if (ret 0) { + printk(KERN_ERR can't set codec DAI configuration\n); + return ret; + } + + /* Set cpu DAI configuration */ + ret = snd_soc_dai_set_fmt(cpu_dai, + SND_SOC_DAIFMT_I2S | + SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBM_CFM); + if (ret 0) { + printk(KERN_ERR can't set cpu DAI configuration\n); + return ret; + } + + /* Set the codec system clock for DAC and ADC */ + ret = snd_soc_dai_set_sysclk(codec_dai, 0, 2600, + SND_SOC_CLOCK_IN); + if (ret 0) { + printk(KERN_ERR can't set codec system clock\n); + return ret; + } + + return 0; +} + +static struct snd_soc_ops igep2_ops = { + .hw_params = igep2_hw_params, +}; + +/* Digital audio interface glue - connects codec -- CPU */ +static struct snd_soc_dai_link igep2_dai = { + .name = TWL4030, + .stream_name = TWL4030, + .cpu_dai = omap_mcbsp_dai[0], + .codec_dai = twl4030_dai[TWL4030_DAI_HIFI], + .ops = igep2_ops, +}; + +/* Audio machine driver */ +static struct snd_soc_card
Re: [PATCH 3/8] OMAP3 hwmod: Add automatic OCP_SYSCONFIG AUTOIDLE handling
On Wed, 18 Nov 2009, Vimal Singh wrote: On Wed, Nov 18, 2009 at 6:35 AM, Kevin Hilman khil...@deeprootsystems.com wrote: From: Paul Walmsley p...@pwsan.com This patch fills in the OCP_SYSCONFIG.AUTOIDLE handling in the OMAP hwmod code. After this patch, the hwmod code will set the module AUTOIDLE bit (generally module.OCP_SYSCONFIG.AUTOIDLE) to 1 by default upon enable, and 1 upon disable. You wanted to say: 0 upon disable, isn't it? No, the original wording was intended, although it is somewhat confusing. This patch wasn't intended to be posted publicly; it combines two unrelated changes that should be split. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Error detecting mmc card on zoom3
I'm unable to use MMC on a zoom3 board with current linux-omap kernel. I see the following error in the bootlogs. mmci-omap-hs mmci-omap-hs.0: err -19 configuring card detect I'll take a stab at this in a couple of hours unless someone beats me to it. - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: Exporting functions doing common register access
On Wed, 18 Nov 2009, Aggarwal, Anuj wrote: [Aggarwal, Anuj] Any comments on this patch? Do I have to re-work this? Yes. omap_ctrl_*() should not be exported, as mentioned earlier. A lot of rework will be needed at some point in sound/soc/omap/ to get all of the chip- and board-integration details out of these files. DMA channels, IRQs, board data, etc. should all go into arch/arm/*omap*. plat-omap/mcbsp.c needs to be moved to somewhere under drivers/ at some point, but the platform_device setup for it should be kept under arch/arm/*omap*. In the interim, I would suggest that you remove the the clock source and receiver source change functions from omap-mcbsp.c, split them into OMAP1 and OMAP2/3 variants, and place them into arch/arm/mach-omap*/mcbsp.c. Expand struct omap_mcbsp_ops to add function pointers to those functions. Call those from soc/omap-mcbsp.c via mcbsp-pdata-ops. That way you won't need those exports. I don't understand how this code compiled on OMAP1 in any case, since it doesn't have a System Control Module. - Paul -- To unsubscribe from this list: send the line unsubscribe 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/8] OMAP: omap_device: add usecounting
Hello Kevin, On Tue, 17 Nov 2009, Kevin Hilman wrote: Add use counters to omap_device to enable multiple potential users of an omap_device. This is needed if ever there are multiple users or multiple instances of a driver with a single omap_device. Without usecounting, with multiple users, the first one to call idle may forcibly idle the device while other users are still active. Could you please send along an example of the use case for this? I would prefer not to add usecounting at this layer unless it is absolutely necessary, since only one driver should be bound to a device at a time. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] OMAP: omap_device: deactivate latency typo
Hello Kevin, On Tue, 17 Nov 2009, Kevin Hilman wrote: The deactivate hook should use 'deactivate_lat' instead of 'activate_lat' when doing checking on expected latency values. Why ? - Paul Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/plat-omap/omap_device.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index bb16e62..da649f2 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -186,7 +186,7 @@ static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat) odpl = od-pm_lats + od-pm_lat_level; if (!ignore_lat - ((od-dev_wakeup_lat + odpl-activate_lat) + ((od-dev_wakeup_lat + odpl-deactivate_lat) od-_dev_wakeup_lat_limit)) break; @@ -209,7 +209,7 @@ static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat) (%llu %d)\n, od-pdev.name, od-pdev.id, od-pm_lat_level, deact_lat, odpl-deactivate_lat); - od-dev_wakeup_lat += odpl-activate_lat; + od-dev_wakeup_lat += odpl-deactivate_lat; od-pm_lat_level++; } -- 1.6.5.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] OMAP3 hwmod: Add automatic OCP_SYSCONFIG AUTOIDLE handling
On Tue, 17 Nov 2009, Kevin Hilman wrote: From: Paul Walmsley p...@pwsan.com This patch fills in the OCP_SYSCONFIG.AUTOIDLE handling in the OMAP hwmod code. This patch actually combines two unrelated changes. I've got those split into two patches here, will post them. - Paul -- To unsubscribe from this list: send the line unsubscribe 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 8/8] OMAP: omap_device: use UINT_MAX for default wakeup latency limit
Hi Kevin, On Tue, 17 Nov 2009, Kevin Hilman wrote: The _dev_wakeup_lat_limit field of struct omap_device is u32, so use UINT_MAX instead of INT_MAX for the default maximum. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com Indeed, thanks. Will add this to the second version of the fixes series. - Paul --- arch/arm/plat-omap/omap_device.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index 83bee1c..9ec3735 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -468,7 +468,7 @@ int omap_device_enable(struct platform_device *pdev) ret = _omap_device_activate(od, IGNORE_WAKEUP_LAT); od-dev_wakeup_lat = 0; - od-_dev_wakeup_lat_limit = INT_MAX; + od-_dev_wakeup_lat_limit = UINT_MAX; od-_state = OMAP_DEVICE_STATE_ENABLED; return ret; -- 1.6.5.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] OMAP3: clock: add clockdomains for UART1 2
Hi Kevin, On Tue, 17 Nov 2009, Kevin Hilman wrote: UART1 2 were missing clockdomains resulting in broken omap_hwmod init for these devices. also looks good, will add this to the fixes series. - Paul Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/clock34xx.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h index a1b3de7..cbc3d8a 100644 --- a/arch/arm/mach-omap2/clock34xx.h +++ b/arch/arm/mach-omap2/clock34xx.h @@ -1507,6 +1507,7 @@ static struct clk uart2_fck = { .parent = core_48m_fck, .enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1), .enable_bit = OMAP3430_EN_UART2_SHIFT, + .clkdm_name = core_l4_clkdm, .recalc = followparent_recalc, }; @@ -1516,6 +1517,7 @@ static struct clk uart1_fck = { .parent = core_48m_fck, .enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1), .enable_bit = OMAP3430_EN_UART1_SHIFT, + .clkdm_name = core_l4_clkdm, .recalc = followparent_recalc, }; -- 1.6.5.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] OMAP: omap_device: use read_persistent_clock() instead of getnstimeofday()
Hi, On Tue, 17 Nov 2009, Kevin Hilman wrote: During suspend and resume, when omap_device deactivation and activation is happening, the timekeeping subsystem has likely already been suspended. Thus getnstimeofday() will fail and trigger a WARN(). Use read_persistent_clock() instead of getnstimeofday() to avoid this. Thanks, will queue in fixes series. - Paul Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/plat-omap/omap_device.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index 6a8b0ce..f6cdf1a 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -134,12 +134,12 @@ static int _omap_device_activate(struct omap_device *od, u8 ignore_lat) (od-dev_wakeup_lat = od-_dev_wakeup_lat_limit)) break; - getnstimeofday(a); + read_persistent_clock(a); /* XXX check return code */ odpl-activate_func(od); - getnstimeofday(b); + read_persistent_clock(b); c = timespec_sub(b, a); act_lat = timespec_to_ns(c) * NSEC_PER_USEC; @@ -190,12 +190,12 @@ static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat) od-_dev_wakeup_lat_limit)) break; - getnstimeofday(a); + read_persistent_clock(a); /* XXX check return code */ odpl-deactivate_func(od); - getnstimeofday(b); + read_persistent_clock(b); c = timespec_sub(b, a); deact_lat = timespec_to_ns(c) * NSEC_PER_USEC; -- 1.6.5.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html - Paul -- To unsubscribe from this list: send the line unsubscribe 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/8] OMAP: hwmod: warn on missing clockdomain
Hi Kevin On Tue, 17 Nov 2009, Kevin Hilman wrote: WARN if a clock/hwmod is missing a clockdomain association since resulting hwmod will not be able to correctly enable/disable clocks. Wouldn't this check be best placed in the clock code? Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/omap_hwmod.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 633b216..7d7b3b8 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -326,6 +326,9 @@ static int _init_main_clk(struct omap_hwmod *oh) ret = -EINVAL; oh-_clk = c; + WARN(!c-clkdm, omap_hwmod: %s: missing clockdomain for %s.\n, + oh-clkdev_con_id, c-name); + return ret; } -- 1.6.5.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8] OMAP: omap_device: warn about expected latencies only if non-zero
Hi, On Tue, 17 Nov 2009, Kevin Hilman wrote: When checking measured [de]activate latencies against expected latencies, only print warning if driver has provided a non-zero latency. This allows drivers to set their [de]activate latencies to zero when they are not known, or are don't care, and the omap_device core will not complain about unexpected latencies. I'm concerned that this will effectively mean that no driver maintainers will bother to measure these latencies. These are necessary for a reasonable implementation of omap_pm_set_max_dev_wakeup_lat(). They should not be difficult to measure: boot at the lowest-performance OPPs with the latencies uninitialized; then these warnings should indicate numbers that can be plugged back into the omap_device structure. But perhaps I am misunderstanding the point you are making? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] OMAP hwmod improvements for 2.6.33
Hello, here are some updates for the OMAP hardware module code for 2.6.33. There are likely to be more after these, but am posting these early for comments and for other branch maintainers who are interested to use in their trees. - Paul --- Paul Walmsley (4): OMAP3 hwmod: reprogram OCP_SYSCONFIG register after setting SOFTRESET OMAP3 hwmod: Add automatic OCP_SYSCONFIG AUTOIDLE handling OMAP hwmod: add names to module MPU IRQ lines OMAP3 hwmod: drop most of the OCP_SYSCONFIG.CLOCKACTIVITY code arch/arm/mach-omap2/omap_hwmod.c | 148 ++ arch/arm/plat-omap/include/plat/omap_hwmod.h | 26 - 2 files changed, 79 insertions(+), 95 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 1/4] OMAP3 hwmod: reprogram OCP_SYSCONFIG register after setting SOFTRESET
Reprogram the module's OCP_SYSCONFIG register after module reset (SOFTRESET = 1). This may not be needed, but the definition of the reset performed by the SOFTRESET bit is unclear. Kevin Hilman khil...@deeprootsystems.com tested an earlier version of this patch. Signed-off-by: Paul Walmsley p...@pwsan.com Tested-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/omap_hwmod.c | 18 +- 1 files changed, 13 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 633b216..4aab1b8 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -948,11 +948,19 @@ static int _setup(struct omap_hwmod *oh) _enable(oh); - if (!(oh-flags HWMOD_INIT_NO_RESET)) - _reset(oh); - - /* XXX OCP AUTOIDLE bit? */ - /* XXX OCP ENAWAKEUP bit? */ + if (!(oh-flags HWMOD_INIT_NO_RESET)) { + /* +* XXX Do the OCP_SYSCONFIG bits need to be +* reprogrammed after a reset? If not, then this can +* be removed. If they do, then probably the +* _enable() function should be split to avoid the +* rewrite of the OCP_SYSCONFIG register. +*/ + if (oh-sysconfig) { + _update_sysc_cache(oh); + _sysc_enable(oh); + } + } if (!(oh-flags HWMOD_INIT_NO_IDLE)) _idle(oh); -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] OMAP3 hwmod: Add automatic OCP_SYSCONFIG AUTOIDLE handling
This patch fills in the OCP_SYSCONFIG.AUTOIDLE handling in the OMAP hwmod code. After this patch, the hwmod code will set the module AUTOIDLE bit (generally module.OCP_SYSCONFIG.AUTOIDLE) to 1 by default upon enable, and 1 upon disable. If the hwmod flag HWMOD_NO_OCP_AUTOIDLE is set, AUTOIDLE will be set to 0 upon enable. Enabling module autoidle should save some power. The only reason to not set the OCP_SYSCONFIG.AUTOIDLE bit is if there is a bug in the module RTL, e.g., the MPUINTC block on OMAP3. Comments from Kevin Hilman khil...@deeprootsystems.com inspired this patch, and Kevin tested an earlier version of this patch. Signed-off-by: Paul Walmsley p...@pwsan.com Tested-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/omap_hwmod.c | 37 +- arch/arm/plat-omap/include/plat/omap_hwmod.h |8 +- 2 files changed, 42 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 4aab1b8..709ec5d 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -210,6 +210,32 @@ static int _set_softreset(struct omap_hwmod *oh, u32 *v) } /** + * _set_module_autoidle: set the OCP_SYSCONFIG AUTOIDLE field in @v + * @oh: struct omap_hwmod * + * @autoidle: desired AUTOIDLE bitfield value (0 or 1) + * @v: pointer to register contents to modify + * + * Update the module autoidle bit in @v to be @autoidle for the @oh + * hwmod. The autoidle bit controls whether the module can gate + * internal clocks automatically when it isn't doing anything; the + * exact function of this bit varies on a per-module basis. This + * function does not write to the hardware. Returns -EINVAL upon + * error or 0 upon success. + */ +static int _set_module_autoidle(struct omap_hwmod *oh, u8 autoidle, + u32 *v) +{ + if (!oh-sysconfig || + !(oh-sysconfig-sysc_flags SYSC_HAS_AUTOIDLE)) + return -EINVAL; + + *v = ~SYSC_AUTOIDLE_MASK; + *v |= autoidle SYSC_AUTOIDLE_SHIFT; + + return 0; +} + +/** * _enable_wakeup: set OCP_SYSCONFIG.ENAWAKEUP bit in the hardware * @oh: struct omap_hwmod * * @@ -557,7 +583,13 @@ static void _sysc_enable(struct omap_hwmod *oh) _set_master_standbymode(oh, idlemode, v); } - /* XXX OCP AUTOIDLE bit? */ + if (oh-sysconfig-sysc_flags SYSC_HAS_AUTOIDLE) { + idlemode = (oh-flags HWMOD_NO_OCP_AUTOIDLE) ? + 0 : 1; + _set_module_autoidle(oh, idlemode, v); + } + + /* XXX OCP ENAWAKEUP bit? */ if (oh-flags HWMOD_SET_DEFAULT_CLOCKACT oh-sysconfig-sysc_flags SYSC_HAS_CLOCKACTIVITY) @@ -622,7 +654,8 @@ static void _sysc_shutdown(struct omap_hwmod *oh) if (oh-sysconfig-sysc_flags SYSC_HAS_MIDLEMODE) _set_master_standbymode(oh, HWMOD_IDLEMODE_FORCE, v); - /* XXX clear OCP AUTOIDLE bit? */ + if (oh-sysconfig-sysc_flags SYSC_HAS_AUTOIDLE) + _set_module_autoidle(oh, 1, v); _write_sysconfig(v, oh); } diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h index dbdd123..643a972 100644 --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h @@ -50,6 +50,8 @@ struct omap_device; #define SYSC_ENAWAKEUP_MASK(1 SYSC_ENAWAKEUP_SHIFT) #define SYSC_SOFTRESET_SHIFT 1 #define SYSC_SOFTRESET_MASK(1 SYSC_SOFTRESET_SHIFT) +#define SYSC_AUTOIDLE_SHIFT0 +#define SYSC_AUTOIDLE_MASK (1 SYSC_AUTOIDLE_SHIFT) /* OCP SYSSTATUS bit shifts/masks */ #define SYSS_RESETDONE_SHIFT 0 @@ -294,13 +296,17 @@ struct omap_hwmod_omap4_prcm { * SDRAM controller, etc. * HWMOD_INIT_NO_IDLE: don't idle this module at boot - important for SDRAM * controller, etc. + * HWMOD_NO_AUTOIDLE: disable module autoidle (OCP_SYSCONFIG.AUTOIDLE) + * when module is enabled, rather than the default, which is to + * enable autoidle * HWMOD_SET_DEFAULT_CLOCKACT: program CLOCKACTIVITY bits at startup */ #define HWMOD_SWSUP_SIDLE (1 0) #define HWMOD_SWSUP_MSTANDBY (1 1) #define HWMOD_INIT_NO_RESET(1 2) #define HWMOD_INIT_NO_IDLE (1 3) -#define HWMOD_SET_DEFAULT_CLOCKACT (1 4) +#define HWMOD_NO_OCP_AUTOIDLE (1 4) +#define HWMOD_SET_DEFAULT_CLOCKACT (1 5) /* * omap_hwmod._int_flags definitions -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] OMAP hwmod: add names to module MPU IRQ lines
Replace the existing u8 array of module MPU IRQ lines with a struct that includes a name - similar to the existing struct omap_hwmod_dma_info. Device drivers can then use platform_get_resource_byname() to retrieve specific IRQs without nasty dependencies on array ordering. Thanks to Benoît Cousson b-cous...@ti.com and Kevin Hilman khil...@deeprootsystems.com for feedback on this approach. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Benoît Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/omap_hwmod.c |5 +++-- arch/arm/plat-omap/include/plat/omap_hwmod.h | 18 -- 2 files changed, 19 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 709ec5d..234567b 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -1389,8 +1389,9 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource *res) /* For each IRQ, DMA, memory area, fill in array.*/ for (i = 0; i oh-mpu_irqs_cnt; i++) { - (res + r)-start = *(oh-mpu_irqs + i); - (res + r)-end = *(oh-mpu_irqs + i); + (res + r)-name = (oh-mpu_irqs + i)-name; + (res + r)-start = (oh-mpu_irqs + i)-irq; + (res + r)-end = (oh-mpu_irqs + i)-irq; (res + r)-flags = IORESOURCE_IRQ; r++; } diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h index 643a972..007935a 100644 --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h @@ -64,7 +64,21 @@ struct omap_device; /** - * struct omap_hwmod_dma_info - MPU address space handled by the hwmod + * struct omap_hwmod_irq_info - MPU IRQs used by the hwmod + * @name: name of the IRQ channel (module local name) + * @irq_ch: IRQ channel ID + * + * @name should be something short, e.g., tx or rx. It is for use + * by platform_get_resource_byname(). It is defined locally to the + * hwmod. + */ +struct omap_hwmod_irq_info { + const char *name; + u16 irq; +}; + +/** + * struct omap_hwmod_dma_info - DMA channels used by the hwmod * @name: name of the DMA channel (module local name) * @dma_ch: DMA channel ID * @@ -379,7 +393,7 @@ struct omap_hwmod_omap4_prcm { struct omap_hwmod { const char *name; struct omap_device *od; - u8 *mpu_irqs; + struct omap_hwmod_irq_info *mpu_irqs; struct omap_hwmod_dma_info *sdma_chs; union { struct omap_hwmod_omap2_prcm omap2; -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] OMAP3 hwmod: drop most of the OCP_SYSCONFIG.CLOCKACTIVITY code
Earlier, the hwmod code had considered the OCP_SYSCONFIG.CLOCKACTIVITY bits to be incremental power saving bits, controlling internal IP block clock gates. This was a misapprehension. The CLOCKACTIVITY bits are used to indicate, in advance, which clocks will be cut when the module acknowledges an idle request. This enables the IP block to take whatever action is necessary to complete any in-progress work before asserting its IdleAck. In the current Linux-OMAP code, this implies that the clock framework should be changing module CLOCKACTIVITY bits as module clocks are enabled and disabled. We don't do that yet, but in the future, we should. This must wait until the clock tree is annotated with omap_hwmod pointers (or vice-versa). In the meantime, drop most of the hwmod code that controls CLOCKACTIVITY bits to avoid confusion. This patch has benefited from many illuminating discussions with (in alphabetical order) Benoît Cousson b-cous...@ti.com, Rajendra Nayak rna...@ti.com, and Sebastien Sabatier s-sabati...@ti.com. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rajendra Nayak rna...@ti.com Cc: Sebastien Sabatier s-sabati...@ti.com Cc: Benoît Cousson b-cous...@ti.com --- arch/arm/mach-omap2/omap_hwmod.c | 88 ++ 1 files changed, 5 insertions(+), 83 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 234567b..eedcc5f 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -591,6 +591,11 @@ static void _sysc_enable(struct omap_hwmod *oh) /* XXX OCP ENAWAKEUP bit? */ + /* +* XXX The clock framework should handle this, by +* calling into this code. But this must wait until the +* clock structures are tagged with omap_hwmod entries +*/ if (oh-flags HWMOD_SET_DEFAULT_CLOCKACT oh-sysconfig-sysc_flags SYSC_HAS_CLOCKACTIVITY) _set_clockactivity(oh, oh-sysconfig-clockact, v); @@ -917,33 +922,6 @@ static int _shutdown(struct omap_hwmod *oh) } /** - * _write_clockact_lock - set the module's clockactivity bits - * @oh: struct omap_hwmod * - * @clockact: CLOCKACTIVITY field bits - * - * Writes the CLOCKACTIVITY bits @clockact to the hwmod @oh - * OCP_SYSCONFIG register. Returns -EINVAL if the hwmod is in the - * wrong state or returns 0. - */ -static int _write_clockact_lock(struct omap_hwmod *oh, u8 clockact) -{ - u32 v; - - if (!oh-sysconfig || - !(oh-sysconfig-sysc_flags SYSC_HAS_CLOCKACTIVITY)) - return -EINVAL; - - mutex_lock(omap_hwmod_mutex); - v = oh-_sysc_cache; - _set_clockactivity(oh, clockact, v); - _write_sysconfig(v, oh); - mutex_unlock(omap_hwmod_mutex); - - return 0; -} - - -/** * _setup - do initial configuration of omap_hwmod * @oh: struct omap_hwmod * * @@ -1496,62 +1474,6 @@ int omap_hwmod_del_initiator_dep(struct omap_hwmod *oh, } /** - * omap_hwmod_set_clockact_none - set clockactivity test to BOTH - * @oh: struct omap_hwmod * - * - * On some modules, this function can affect the wakeup latency vs. - * power consumption balance. Intended to be called by the - * omap_device layer. Passes along the return value from - * _write_clockact_lock(). - */ -int omap_hwmod_set_clockact_both(struct omap_hwmod *oh) -{ - return _write_clockact_lock(oh, CLOCKACT_TEST_BOTH); -} - -/** - * omap_hwmod_set_clockact_none - set clockactivity test to MAIN - * @oh: struct omap_hwmod * - * - * On some modules, this function can affect the wakeup latency vs. - * power consumption balance. Intended to be called by the - * omap_device layer. Passes along the return value from - * _write_clockact_lock(). - */ -int omap_hwmod_set_clockact_main(struct omap_hwmod *oh) -{ - return _write_clockact_lock(oh, CLOCKACT_TEST_MAIN); -} - -/** - * omap_hwmod_set_clockact_none - set clockactivity test to ICLK - * @oh: struct omap_hwmod * - * - * On some modules, this function can affect the wakeup latency vs. - * power consumption balance. Intended to be called by the - * omap_device layer. Passes along the return value from - * _write_clockact_lock(). - */ -int omap_hwmod_set_clockact_iclk(struct omap_hwmod *oh) -{ - return _write_clockact_lock(oh, CLOCKACT_TEST_ICLK); -} - -/** - * omap_hwmod_set_clockact_none - set clockactivity test to NONE - * @oh: struct omap_hwmod * - * - * On some modules, this function can affect the wakeup latency vs. - * power consumption balance. Intended to be called by the - * omap_device layer. Passes along the return value from - * _write_clockact_lock(). - */ -int omap_hwmod_set_clockact_none(struct omap_hwmod *oh) -{ - return _write_clockact_lock(oh, CLOCKACT_TEST_NONE); -} - -/** * omap_hwmod_enable_wakeup - allow device to wake up the system * @oh: struct omap_hwmod * * -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a
Query: Enabling DEBUG_LL on Zoom2/3 boards
Vikram, With the recent changes to DEBUG_LL on Zoom2/3 boards, it looks like I can no longer get any debug UART activity if DEBUG_LL is enabled on these boards (tested on Zoom3). Is it fair to expect at least the normal UART activity to work even when CONFIG_DEBUG_LL is enabled and CONFIG_OMAP_LL_DEBUG_NONE is set? - Anand -- To unsubscribe from this list: send the line unsubscribe 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 8/10 v3] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox.
From: ext C.A, Subramaniam subramaniam...@ti.com Subject: [PATCH 8/10 v3] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox. Date: Wed, 18 Nov 2009 10:32:01 +0100 Hi Tony, Following is the version 3 of patch 8/10. It removes one typo in the v2 patch that I sent out earlier. Request you to take this version of the patch. Hiroshi, Thank you for pointing out the error. Request you to please review the patch. There may be some possibility to arrange multiple mailbox setup in more cleaner way, but for the moment it looks ok for me. -- To unsubscribe from this list: send the line unsubscribe 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: Force write last pad config register into save area
-Original Message- From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 17 November, 2009 20:34 To: Kristo Tero (Nokia-D/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP3: PM: Force write last pad config register into save area Tero Kristo tero.kri...@nokia.com writes: From: Tero Kristo tero.kri...@nokia.com Due to OMAP3 errata XYZ, the save of the last pad register (ETK_D14 and ETK_D15) can fail sometimes when there is simultaneous OCP access to the SCM register area. Fixed by writing the last register to the save area. Also, optimized the delay loop for the HW save to include an udelay(1), which limits the number of unnecessary HW accesses to SCM register area during the save. Signed-off-by: Tero Kristo tero.kri...@nokia.com I certainly like this fix much better than the original proposal: http://marc.info/?l=linux-omapm=125474186609661w=2 Pulling into PM branch after s/XYZ/1.157/ I will resend the patch when TI has confirmed the errata number. This version of the patch was also missing an #include linux/delay.h for the udelay, I missed this in the hurry, so I will add this one also. -Tero --- arch/arm/mach-omap2/pm34xx.c | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 4b01303..4ead40e 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -155,7 +155,15 @@ static void omap3_core_save_context(void) /* wait for the save to complete */ while (!(omap_ctrl_readl(OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS) PADCONF_SAVE_DONE)) -; +udelay(1); + +/* + * Force write last pad into memory, as this can fail in some + * cases according to errata XYZ + */ +omap_ctrl_writel(omap_ctrl_readl(OMAP343X_PADCONF_ETK_D14), +OMAP343X_CONTROL_MEM_WKUP + 0x2a0); + /* Save the Interrupt controller context */ omap_intc_save_context(); /* Save the GPMC context */ -- 1.5.4.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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ASoC: Correcting the config options in soc/omap/Makefile
On Tue, Nov 17, 2009 at 09:43:18PM +0530, Anuj Aggarwal wrote: Wrong config options were being used in the soc/omap/Makefile for OMAP2 OMAP3 and AM3517 EVMs. Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com Applied both, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH (for-next 2)] ASoC: Add support for IGEP v2
On Wed, Nov 18, 2009 at 11:59:08AM +0200, Mike Rapoport wrote: (adding ALSA mailing list to CC again :) ) Enric, please follow the instructions in Documentaion/SubmittingPatches when submitting patches - in particular, please do remember to CC both the maintainers for the relevant subsystems and the mailing list for the subsystem. In this case I don't have a copy of the original patch so could you please resend. -- To unsubscribe from this list: send the line unsubscribe 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: zoom2/3: make MMC slot work again
omap3: zoom2/3: make MMC slot work again Commit 12f8dfb56 accidentally broke MMC on zoom2/3. The .vmmc1 field of zoom_twldata was deleted. Restoring it allows the MMC slot to work again Signed-off-by: Anand Gadiyar gadi...@ti.com --- arch/arm/mach-omap2/board-zoom-peripherals.c |1 + 1 files changed, 1 insertion(+) Index: linux-omap-2.6/arch/arm/mach-omap2/board-zoom-peripherals.c === --- linux-omap-2.6.orig/arch/arm/mach-omap2/board-zoom-peripherals.c +++ linux-omap-2.6/arch/arm/mach-omap2/board-zoom-peripherals.c @@ -236,6 +236,7 @@ static struct twl4030_platform_data zoom .gpio = zoom_gpio_data, .keypad = zoom_kp_twl4030_data, .codec = zoom_codec_data, + .vmmc1 = zoom_vmmc1, .vmmc2 = zoom_vmmc2, .vsim = zoom_vsim, -- To unsubscribe from this list: send the line unsubscribe 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: Force write last pad config register into save area
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Wednesday, November 18, 2009 12:04 AM To: Tero Kristo Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP3: PM: Force write last pad config register into save area Tero Kristo tero.kri...@nokia.com writes: From: Tero Kristo tero.kri...@nokia.com Due to OMAP3 errata XYZ, the save of the last pad register (ETK_D14 and ETK_D15) can fail sometimes when there is simultaneous OCP access to the SCM register area. Fixed by writing the last register to the save area. Also, optimized the delay loop for the HW save to include an udelay(1), which limits the number of unnecessary HW accesses to SCM register area during the save. Signed-off-by: Tero Kristo tero.kri...@nokia.com I certainly like this fix much better than the original proposal: http://marc.info/?l=linux-omapm=125474186609661w=2 Please do not merge this patch until TI officially confirms the workaround. Pulling into PM branch after s/XYZ/1.157/ Kevin --- arch/arm/mach-omap2/pm34xx.c | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 4b01303..4ead40e 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -155,7 +155,15 @@ static void omap3_core_save_context(void) /* wait for the save to complete */ while (!(omap_ctrl_readl(OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS) PADCONF_SAVE_DONE)) - ; + udelay(1); + + /* +* Force write last pad into memory, as this can fail in some +* cases according to errata XYZ +*/ + omap_ctrl_writel(omap_ctrl_readl(OMAP343X_PADCONF_ETK_D14), + OMAP343X_CONTROL_MEM_WKUP + 0x2a0); + /* Save the Interrupt controller context */ omap_intc_save_context(); /* Save the GPMC context */ -- 1.5.4.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 -- To unsubscribe from this list: send the line unsubscribe 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
[PATCH 0/4] OMAP3: Clock changes for OMAP3630
This patch set introduces clock changes for OMAP3630. Major changes in OMAP3630 w.r.t clock are 1. Introduction of j type dpll4 2. CLKSEL filed width is increased by 1 bit for DPLL4M3, M4, M5 and M6 3. SGX can be run at 192Mhz Patch set has been created for linux-omap-pm tree Richard Woodruff (1): OMAP3:clk - introduce DPLL4 jtype support Vishwanath BS (3): OMAP3:clk - Clock Type change for OMAP3 Clocks OMAP3:clk - correct width for CLKSEL Fields OMAP3:clk - add support for 192Mhz sgx clock arch/arm/mach-omap2/clock.h | 12 +- arch/arm/mach-omap2/clock34xx.c | 438 ++- arch/arm/mach-omap2/clock34xx.h | 244 +++-- arch/arm/mach-omap2/cm-regbits-34xx.h | 11 + arch/arm/mach-omap2/id.c|4 +- arch/arm/plat-omap/include/plat/clock.h |9 +- arch/arm/plat-omap/include/plat/cpu.h |3 +- 7 files changed, 441 insertions(+), 280 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 1/4] OMAP3: introduce DPLL4 Jtype
From: Richard Woodruff r-woodru...@ti.com DPLL4 for 3630 introduces a changed block requiring special divisor bits and additional reg fields. To allow for silicons to use this, this is introduced as a omap3_has_jtype_dpll4() and is enabled for 3630 silicon Tested with 3630 ZOOM3 Signed-off-by: Richard Woodruff r-woodru...@ti.com Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Vishwanath BS vishwanath...@ti.com --- arch/arm/mach-omap2/clock34xx.c | 49 ++- arch/arm/mach-omap2/cm-regbits-34xx.h |6 +++- arch/arm/mach-omap2/id.c|4 ++- arch/arm/plat-omap/include/plat/clock.h |3 ++ arch/arm/plat-omap/include/plat/cpu.h |3 +- 5 files changed, 61 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c index da5bc1f..2c07b9e 100644 --- a/arch/arm/mach-omap2/clock34xx.c +++ b/arch/arm/mach-omap2/clock34xx.c @@ -679,6 +679,40 @@ static void omap3_noncore_dpll_disable(struct clk *clk) _omap3_noncore_dpll_stop(clk); } +/** + * lookup_dco_sddiv - Set j-type DPLL4 compensation variables + * @clk: pointer to a DPLL struct clk + * @dco: digital control oscillator selector + * @sd_div: target sigma-delta divider + * @m: DPLL multiplier to set + * @n: DPLL divider to set + */ +static void lookup_dco_sddiv(struct clk *clk, u8 *dco, u8 *sd_div, u16 +m, u8 n) { + unsigned long fint, clkinp, sd; /* watch out for overflow */ + int mod1, mod2; + + clkinp = clk-parent-rate; + fint = (clkinp / n) * m; + + if (fint 10) + *dco = 2; + else + *dco = 4; + /* +* target sigma-delta to near 250MHz +* sd = ceil[(m/(n+1)) * (clkinp_MHz / 250)] +*/ + clkinp /= 10; /* shift from MHz to 10*Hz for 38.4 and 19.2*/ + mod1 = (clkinp * m) % (250 * n); + sd = (clkinp * m) / (250 * n); + mod2 = sd % 10; + sd /= 10; + + if (mod1 + mod2) + sd++; + *sd_div = sd; +} /* Non-CORE DPLL rate set code */ @@ -711,6 +745,13 @@ static int omap3_noncore_dpll_program(struct clk *clk, u16 m, u8 n, u16 freqsel) v = ~(dd-mult_mask | dd-div1_mask); v |= m __ffs(dd-mult_mask); v |= (n - 1) __ffs(dd-div1_mask); + if (dd-jtype) { + u8 dco, sd_div; + lookup_dco_sddiv(clk, dco, sd_div, m, n); + v = ~(dd-dco_sel_mask | dd-sd_div_mask); + v |= dco __ffs(dd-dco_sel_mask); + v |= sd_div __ffs(dd-sd_div_mask); + } __raw_writel(v, dd-mult_div1_reg); /* We let the clock framework set the other output dividers later */ @@ -1026,7 +1067,7 @@ static unsigned long omap3_clkoutx2_recalc(struct clk *clk) v = __raw_readl(dd-control_reg) dd-enable_mask; v = __ffs(dd-enable_mask); - if (v != OMAP3XXX_EN_DPLL_LOCKED) + if (v != OMAP3XXX_EN_DPLL_LOCKED (!dd-jtype)) rate = clk-parent-rate; else rate = clk-parent-rate * 2; @@ -1174,6 +1215,12 @@ int __init omap2_clk_init(void) cpu_mask |= RATE_IN_3430ES2; cpu_clkflg |= CK_3430ES2; } + if (omap3_has_jtype_dpll4()) + { + dpll4_ck.dpll_data-jtype = 1; + dpll4_ck.dpll_data-dco_sel_mask = OMAP3630_PERIPH_DPLL_DCO_SEL_MASK; + dpll4_ck.dpll_data-sd_div_mask = OMAP3630_PERIPH_DPLL_SD_DIV_MASK; + } } clk_init(omap2_clk_functions); diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h b/arch/arm/mach-omap2/cm-regbits-34xx.h index 6923deb..6f2802b 100644 --- a/arch/arm/mach-omap2/cm-regbits-34xx.h +++ b/arch/arm/mach-omap2/cm-regbits-34xx.h @@ -516,9 +516,13 @@ /* CM_CLKSEL2_PLL */ #define OMAP3430_PERIPH_DPLL_MULT_SHIFT8 -#define OMAP3430_PERIPH_DPLL_MULT_MASK (0x7ff 8) +#define OMAP3430_PERIPH_DPLL_MULT_MASK (0xfff 8) #define OMAP3430_PERIPH_DPLL_DIV_SHIFT 0 #define OMAP3430_PERIPH_DPLL_DIV_MASK (0x7f 0) +#define OMAP3630_PERIPH_DPLL_DCO_SEL_SHIFT 21 +#define OMAP3630_PERIPH_DPLL_DCO_SEL_MASK (0x7 21) +#define OMAP3630_PERIPH_DPLL_SD_DIV_SHIFT 24 +#define OMAP3630_PERIPH_DPLL_SD_DIV_MASK (0xff 24) /* CM_CLKSEL3_PLL */ #define OMAP3430_DIV_96M_SHIFT 0 diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index f48a4b2..3c1194c 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -176,6 +176,8 @@ void __init omap3_check_features(void) OMAP3_CHECK_FEATURE(status, NEON); OMAP3_CHECK_FEATURE(status, ISP); + if (cpu_is_omap3630()) + omap3_features |= OMAP3_HAS_JTYPE_DPLL4; /*
[PATCH 2/4] OMAP3: Clock Type change for OMAP3 Clocks
In omap34xx_clks, CK_343X type is used by all OMAP3 family of processors. It makes more sense to name clock type as CK_3XXX since it is common to all OMAP3 processors. Signed-off-by: Vishwanath BS vishwanath...@ti.com --- arch/arm/mach-omap2/clock.h | 12 +- arch/arm/mach-omap2/clock34xx.c | 370 +++--- arch/arm/mach-omap2/clock34xx.h | 158 +++--- arch/arm/plat-omap/include/plat/clock.h |2 +- 4 files changed, 271 insertions(+), 271 deletions(-) mode change 100644 = 100755 arch/arm/mach-omap2/clock.h mode change 100644 = 100755 arch/arm/mach-omap2/clock34xx.c mode change 100644 = 100755 arch/arm/mach-omap2/clock34xx.h mode change 100644 = 100755 arch/arm/plat-omap/include/plat/clock.h diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h index 43b6bed..955bde5 --- a/arch/arm/mach-omap2/clock.h +++ b/arch/arm/mach-omap2/clock.h @@ -79,20 +79,20 @@ extern u8 cpu_mask; /* clksel_rate data common to 24xx/343x */ static const struct clksel_rate gpt_32k_rates[] = { -{ .div = 1, .val = 0, .flags = RATE_IN_24XX | RATE_IN_343X | DEFAULT_RATE }, +{ .div = 1, .val = 0, .flags = RATE_IN_24XX | RATE_IN_3XXX | DEFAULT_RATE }, { .div = 0 } }; static const struct clksel_rate gpt_sys_rates[] = { -{ .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_343X | DEFAULT_RATE }, +{ .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_3XXX | DEFAULT_RATE }, { .div = 0 } }; static const struct clksel_rate gfx_l3_rates[] = { - { .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_343X }, - { .div = 2, .val = 2, .flags = RATE_IN_24XX | RATE_IN_343X | DEFAULT_RATE }, - { .div = 3, .val = 3, .flags = RATE_IN_243X | RATE_IN_343X }, - { .div = 4, .val = 4, .flags = RATE_IN_243X | RATE_IN_343X }, + { .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_3XXX }, + { .div = 2, .val = 2, .flags = RATE_IN_24XX | RATE_IN_3XXX | DEFAULT_RATE }, + { .div = 3, .val = 3, .flags = RATE_IN_243X | RATE_IN_3XXX }, + { .div = 4, .val = 4, .flags = RATE_IN_243X | RATE_IN_3XXX }, { .div = 0 } }; diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c index 2c07b9e..be630ce --- a/arch/arm/mach-omap2/clock34xx.c +++ b/arch/arm/mach-omap2/clock34xx.c @@ -94,69 +94,69 @@ struct omap_clk { }, \ } -#define CK_343X(1 0) +#define CK_3XXX(1 0) #define CK_3430ES1 (1 1) #define CK_3430ES2 (1 2) static struct omap_clk omap34xx_clks[] = { - CLK(NULL, omap_32k_fck, omap_32k_fck, CK_343X), - CLK(NULL, virt_12m_ck, virt_12m_ck, CK_343X), - CLK(NULL, virt_13m_ck, virt_13m_ck, CK_343X), + CLK(NULL, omap_32k_fck, omap_32k_fck, CK_3XXX), + CLK(NULL, virt_12m_ck, virt_12m_ck, CK_3XXX), + CLK(NULL, virt_13m_ck, virt_13m_ck, CK_3XXX), CLK(NULL, virt_16_8m_ck, virt_16_8m_ck, CK_3430ES2), - CLK(NULL, virt_19_2m_ck, virt_19_2m_ck, CK_343X), - CLK(NULL, virt_26m_ck, virt_26m_ck, CK_343X), - CLK(NULL, virt_38_4m_ck, virt_38_4m_ck, CK_343X), - CLK(NULL, osc_sys_ck, osc_sys_ck,CK_343X), - CLK(NULL, sys_ck, sys_ck,CK_343X), - CLK(NULL, sys_altclk, sys_altclk,CK_343X), - CLK(NULL, mcbsp_clks, mcbsp_clks,CK_343X), - CLK(NULL, sys_clkout1, sys_clkout1, CK_343X), - CLK(NULL, dpll1_ck, dpll1_ck, CK_343X), - CLK(NULL, dpll1_x2_ck, dpll1_x2_ck, CK_343X), - CLK(NULL, dpll1_x2m2_ck, dpll1_x2m2_ck, CK_343X), - CLK(NULL, dpll2_ck, dpll2_ck, CK_343X), - CLK(NULL, dpll2_m2_ck, dpll2_m2_ck, CK_343X), - CLK(NULL, dpll3_ck, dpll3_ck, CK_343X), - CLK(NULL, core_ck, core_ck, CK_343X), - CLK(NULL, dpll3_x2_ck, dpll3_x2_ck, CK_343X), - CLK(NULL, dpll3_m2_ck, dpll3_m2_ck, CK_343X), - CLK(NULL, dpll3_m2x2_ck, dpll3_m2x2_ck, CK_343X), - CLK(NULL, dpll3_m3_ck, dpll3_m3_ck, CK_343X), - CLK(NULL, dpll3_m3x2_ck, dpll3_m3x2_ck, CK_343X), - CLK(NULL, emu_core_alwon_ck, emu_core_alwon_ck, CK_343X), - CLK(NULL, dpll4_ck, dpll4_ck, CK_343X), - CLK(NULL, dpll4_x2_ck, dpll4_x2_ck, CK_343X), - CLK(NULL, omap_96m_alwon_fck, omap_96m_alwon_fck, CK_343X), - CLK(NULL, omap_96m_fck, omap_96m_fck, CK_343X), - CLK(NULL, cm_96m_fck, cm_96m_fck,CK_343X), - CLK(NULL, omap_54m_fck, omap_54m_fck, CK_343X), - CLK(NULL, omap_48m_fck, omap_48m_fck, CK_343X), - CLK(NULL, omap_12m_fck, omap_12m_fck, CK_343X), - CLK(NULL, dpll4_m2_ck, dpll4_m2_ck,
Re: [PATCH] OMAP3: PM: Force write last pad config register into save area
On Wed, Nov 18, 2009 at 6:11 AM, Gopinath, Thara th...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Wednesday, November 18, 2009 12:04 AM To: Tero Kristo Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP3: PM: Force write last pad config register into save area Tero Kristo tero.kri...@nokia.com writes: From: Tero Kristo tero.kri...@nokia.com Due to OMAP3 errata XYZ, the save of the last pad register (ETK_D14 and ETK_D15) can fail sometimes when there is simultaneous OCP access to the SCM register area. Fixed by writing the last register to the save area. Also, optimized the delay loop for the HW save to include an udelay(1), which limits the number of unnecessary HW accesses to SCM register area during the save. Signed-off-by: Tero Kristo tero.kri...@nokia.com I certainly like this fix much better than the original proposal: http://marc.info/?l=linux-omapm=125474186609661w=2 Please do not merge this patch until TI officially confirms the workaround. 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
[PATCH 4/4] OMAP3: add support for 192Mhz sgx clock
SGX can run at 192MHz on 3630 and this patch has changes to support this feature. Signed-off-by: Vishwanath BS vishwanath...@ti.com --- arch/arm/mach-omap2/clock34xx.c | 10 ++ arch/arm/mach-omap2/clock34xx.h | 33 + arch/arm/mach-omap2/cm-regbits-34xx.h |2 ++ 3 files changed, 45 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c index 77b88aa..885043e 100755 --- a/arch/arm/mach-omap2/clock34xx.c +++ b/arch/arm/mach-omap2/clock34xx.c @@ -128,6 +128,7 @@ static struct omap_clk omap34xx_clks[] = { CLK(NULL, emu_core_alwon_ck, emu_core_alwon_ck, CK_3XXX), CLK(NULL, dpll4_ck, dpll4_ck, CK_3XXX), CLK(NULL, dpll4_x2_ck, dpll4_x2_ck, CK_3XXX), + CLK(NULL, omap_192m_alwon_ck, omap_192m_alwon_ck, CK_363X), CLK(NULL, omap_96m_alwon_fck, omap_96m_alwon_fck, CK_3XXX), CLK(NULL, omap_96m_fck, omap_96m_fck, CK_3XXX), CLK(NULL, cm_96m_fck, cm_96m_fck,CK_3XXX), @@ -1224,6 +1225,15 @@ int __init omap2_clk_init(void) dpll4_ck.dpll_data-sd_div_mask = OMAP3630_PERIPH_DPLL_SD_DIV_MASK; dpll4_dd.mult_mask = OMAP3630_PERIPH_DPLL_MULT_MASK; cpu_mask |= RATE_IN_363X; + cpu_clkflg |= CK_363X; + omap_96m_alwon_fck.parent = omap_192m_alwon_ck; + omap_96m_alwon_fck.init = omap2_init_clksel_parent; + omap_96m_alwon_fck.clksel_reg = + OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL), + omap_96m_alwon_fck.clksel_mask = + OMAP3630_CLKSEL_96M_MASK; + omap_96m_alwon_fck.clksel = omap_96m_alwon_fck_clksel; + omap_96m_alwon_fck.recalc = omap2_clksel_recalc; } } diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h index 93c92e5..6fe89df 100755 --- a/arch/arm/mach-omap2/clock34xx.h +++ b/arch/arm/mach-omap2/clock34xx.h @@ -654,12 +654,31 @@ static struct clk dpll4_m2x2_ck = { .recalc = omap3_clkoutx2_recalc, }; +/* Adding 192MHz Clock node needed by SGX */ +static struct clk omap_192m_alwon_ck = { + .name = omap_192m_alwon_ck, + .ops= clkops_null, + .parent = dpll4_m2x2_ck, + .recalc = followparent_recalc, +}; + /* * DPLL4 generates DPLL4_M2X2_CLK which is then routed into the PRM as * PRM_96M_ALWON_(F)CLK. Two clocks then emerge from the PRM: * 96M_ALWON_FCLK (called omap_96m_alwon_fck below) and * CM_96K_(F)CLK. */ +static const struct clksel_rate omap_96m_alwon_fck_rates[] = { + { .div = 1, .val = 1, .flags = RATE_IN_363X }, + { .div = 2, .val = 2, .flags = RATE_IN_363X | DEFAULT_RATE }, + { .div = 0 } +}; + +static const struct clksel omap_96m_alwon_fck_clksel[] = { + { .parent = omap_192m_alwon_ck, .rates = omap_96m_alwon_fck_rates }, + { .parent = NULL } +}; + static struct clk omap_96m_alwon_fck = { .name = omap_96m_alwon_fck, .ops= clkops_null, @@ -1223,6 +1242,18 @@ static const struct clksel_rate sgx_core_rates[] = { { .div = 3, .val = 0, .flags = RATE_IN_3XXX | DEFAULT_RATE }, { .div = 4, .val = 1, .flags = RATE_IN_3XXX }, { .div = 6, .val = 2, .flags = RATE_IN_3XXX }, + { .div = 2, .val = 5, .flags = RATE_IN_363X }, + { .div = 0 }, +}; + +static const struct clksel_rate sgx_192m_rates[] = { + { .div = 1, .val = 4, .flags = RATE_IN_363X | DEFAULT_RATE }, + { .div = 0 }, +}; + +static const struct clksel_rate sgx_corex2_rates[] = { + { .div = 3, .val = 6, .flags = RATE_IN_363X | DEFAULT_RATE }, + { .div = 5, .val = 7, .flags = RATE_IN_363X }, { .div = 0 }, }; @@ -1234,6 +1265,8 @@ static const struct clksel_rate sgx_96m_rates[] = { static const struct clksel sgx_clksel[] = { { .parent = core_ck,.rates = sgx_core_rates }, { .parent = cm_96m_fck, .rates = sgx_96m_rates }, + { .parent = omap_192m_alwon_ck, .rates = sgx_192m_rates }, + { .parent = corex2_fck, .rates = sgx_corex2_rates }, { .parent = NULL }, }; diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h b/arch/arm/mach-omap2/cm-regbits-34xx.h index a6383f9..39b3399 100755 --- a/arch/arm/mach-omap2/cm-regbits-34xx.h +++ b/arch/arm/mach-omap2/cm-regbits-34xx.h @@ -336,6 +336,8 @@ #define OMAP3430_CLKSEL_L4_MASK(0x3 2) #define OMAP3430_CLKSEL_L3_SHIFT 0 #define OMAP3430_CLKSEL_L3_MASK(0x3 0) +#define OMAP3630_CLKSEL_96M_SHIFT 12 +#define OMAP3630_CLKSEL_96M_MASK (0x3 12) /*
Re: [PATCH 0/8] musb: Add structure 'musb_hdrc_board_data'
Hello. Ajay Kumar Gupta wrote: This patch set adds a new structure 'musb_hdrc_board_data' to get all board specific data from board files. It is actually done to accomodate ULPI_VBUSCONTROL programming required for OMAP3EVM Rev =E which uses external Vbus supply to support 500mA. It's not clear why it was necessary to create yet another structure. You could your new field to 'struct musb_hdrc_platfrom_data'... Regards, Ajay WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Problem trying to pull particular commit from PM tree
Is it possible to back up in time on the PM tree to find a particular commit, even across rebasings? I'm interested in the commit used by TI to base their AM3517 work on which is: [Commit:ef25c2a0e0]: OMAP3: PM: defconfig: enable SRF by default. I tried: git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git git checkout -b pm origin/pm git reset --hard ef25c2a0 But that came back with: fatal: ambiguous argument 'ef25c2a0': unknown revision or path not in the working tree. My git 'fu' is pretty weak. Any ideas why this doesn't work? Thanks in advance! -- Peter Barada pet...@logicpd.com Logic Product Development, Inc. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: Exporting functions doing common register access
On Wed, 18 Nov 2009 03:40:40 -0700 (MST) Paul Walmsley p...@pwsan.com wrote: In the interim, I would suggest that you remove the the clock source and receiver source change functions from omap-mcbsp.c, split them into OMAP1 and OMAP2/3 variants, and place them into arch/arm/mach-omap*/mcbsp.c. Expand struct omap_mcbsp_ops to add function pointers to those functions. Call those from soc/omap-mcbsp.c via mcbsp-pdata-ops. That way you won't need those exports. Paul: What's your opinnion, would it be possible or would it be wise to handle these McBSP clock route setups with the clock framework instead? Functions omap_mcbsp_dai_set_clks_src and omap_mcbsp_dai_set_rcvr_src are basically just setting up the input clock for McBSP SRG or McBSP1 receiver. I don't understand how this code compiled on OMAP1 in any case, since it doesn't have a System Control Module. OMAP1 can include control.h as well :-) Access is anyway protected with the cpu_class_is_omap1(). -- Jarkko -- To unsubscribe from this list: send the line unsubscribe 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/8] OMAP: omap_device: add usecounting
Paul Walmsley p...@pwsan.com writes: Hello Kevin, On Tue, 17 Nov 2009, Kevin Hilman wrote: Add use counters to omap_device to enable multiple potential users of an omap_device. This is needed if ever there are multiple users or multiple instances of a driver with a single omap_device. Without usecounting, with multiple users, the first one to call idle may forcibly idle the device while other users are still active. Could you please send along an example of the use case for this? The current use case is the serial driver (not yet ready for posting.) While there is only a single driver bound to the omap_device, there are effectivily multiple instances of the driver. One for initial init/probe requriring and early _enable, followed by _idle in the late_init hook. Another when the actual serial driver gets started and the inactivity timers etc. start firing. These usages overlap slightly and the easiest way I saw to handle this was with usecounting. I would prefer not to add usecounting at this layer unless it is absolutely necessary, since only one driver should be bound to a device at a time. What about mulitple instances of the same driver? Or, what about drivers like i2c which might do _enable/_idle on a per-transfer basis and there might be multiple transfers pending at any given time. We already have use-counting in the clock framework for this same purpose. I'm essentially proposing the usecounting for the same reason, but it also need to protect enable/idle parts of hwmod as well. Maybe usecounting at the hwmod level is more appropriate since that's where the problem lies. I'm fine with that. 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-v5 2/4] OMAP3: Add support for NAND on ZOOM2/LDP boards
Tony, On Fri, Nov 13, 2009 at 2:14 AM, Tony Lindgren t...@atomide.com wrote: * Vimal Singh vimal.neww...@gmail.com [091110 02:08]: From 6f535d7128ca392458dd0cb31d138cda84747c06 Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Tue, 10 Nov 2009 11:42:45 +0530 Subject: [PATCH] OMAP3: Add support for NAND on ZOOM2/LDP boards [...] +static int omap_ldp_nand_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len) +{ + int ret = 0; + int chipnr; + int status; + unsigned long page; + struct nand_chip *this = mtd-priv; + printk(KERN_INFO nand_unlock: start: %08x, length: %d!\n, + (int)ofs, (int)len); + + /* select the NAND device */ + chipnr = (int)(ofs this-chip_shift); + this-select_chip(mtd, chipnr); + /* check the WP bit */ + this-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); + if ((this-read_byte(mtd) 0x80) == 0) { + printk(KERN_ERR nand_unlock: Device is write protected!\n); + ret = -EINVAL; + goto out; + } + + if ((ofs (mtd-writesize - 1)) != 0) { + printk(KERN_ERR nand_unlock: Start address must be + beginning of nand page!\n); + ret = -EINVAL; + goto out; + } + + if (len == 0 || (len (mtd-writesize - 1)) != 0) { + printk(KERN_ERR nand_unlock: Length must be a multiple of + nand page size!\n); + ret = -EINVAL; + goto out; + } + + /* submit address of first page to unlock */ + page = (unsigned long)(ofs this-page_shift); + this-cmdfunc(mtd, NAND_CMD_UNLOCK1, -1, page this-pagemask); + + /* submit ADDRESS of LAST page to unlock */ + page += (unsigned long)((ofs + len) this-page_shift) ; + this-cmdfunc(mtd, NAND_CMD_UNLOCK2, -1, page this-pagemask); + + /* call wait ready function */ + status = this-waitfunc(mtd, this); + udelay(1000); + /* see if device thinks it succeeded */ + if (status 0x01) { + /* there was an error */ + printk(KERN_ERR nand_unlock: error status =0x%08x , status); + ret = -EIO; + goto out; + } + + out: + /* de-select the NAND device */ + this-select_chip(mtd, -1); + return ret; +} Isn't the unlocking generic to the NAND device driver? Or is it somehow board specific? Yes, zoom2 boards come up with whole NAND locked, whereas it is not case for SDP boards. +static struct mtd_partition ldp_nand_partitions[] = { + /* All the partition sizes are listed in terms of NAND block size */ + { + .name = X-Loader-NAND, + .offset = 0, + .size = 4 * (64 * 2048), /* 512KB, 0x8 */ + .mask_flags = MTD_WRITEABLE, /* force read-only */ + }, + { + .name = U-Boot-NAND, + .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */ + .size = 10 * (64 * 2048), /* 1.25MB, 0x14 */ + .mask_flags = MTD_WRITEABLE, /* force read-only */ + }, + { + .name = Boot Env-NAND, + .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */ + .size = 2 * (64 * 2048), /* 256KB, 0x4 */ + }, + { + .name = Kernel-NAND, + .offset = MTDPART_OFS_APPEND, /* Offset = 0x020*/ + .size = 240 * (64 * 2048), /* 30M, 0x1E0 */ + }, +#ifdef CONFIG_MACH_OMAP_ZOOM2 + { + .name = system, + .offset = MTDPART_OFS_APPEND, /* Offset = 0x200 */ + .size = 1280 * (64 * 2048), /* 160M, 0xA00 */ + }, + { + .name = userdata, + .offset = MTDPART_OFS_APPEND, /* Offset = 0xC00 */ + .size = 256 * (64 * 2048), /* 32M, 0x200 */ + }, + { + .name = cache, + .offset = MTDPART_OFS_APPEND, /* Offset = 0xE00 */ + .size = 256 * (64 * 2048), /* 32M, 0x200 */ + }, +#else + { + .name = File System - NAND, + .offset = MTDPART_OFS_APPEND, /* Offset = 0x200 */ + .size = MTDPART_SIZ_FULL, /* 96MB, 0x600 */ + }, +#endif Please remove the ifdefs, you should be able to compile in all mach-omap2 boards into the same kernel binary. You should set the size dynamically as needed. We can always provide partitioning information from cmdline (mtdparts:). Which will anyway have higher precedence than this. Here are trying provide default static partitions. Which IMHO is fine. see this
Re: [PATCH 4/8] OMAP: omap_device: deactivate latency typo
Paul Walmsley p...@pwsan.com writes: Hello Kevin, On Tue, 17 Nov 2009, Kevin Hilman wrote: The deactivate hook should use 'deactivate_lat' instead of 'activate_lat' when doing checking on expected latency values. Why ? Hmm, looking closer, I think misunderstood the use of 'activate_lat' in the deactivate hook. I'll drop this one. 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 v3 03/04] ARM: OMAP: Rename twl4030_ in rtc-twl.c to make it generic rtc
On Thu, 1 Oct 2009 17:50:33 +0530 balaj...@ti.com wrote: From: Balaji T K balaj...@ti.com This patch renames all twl4030_ functions to twl_ so that RTC driver can be shared between Triton and Phoenix. Which tree should handle that? The two patches you sent involves both mfd and rtc and I don't have that mfd/twl.. in my tree. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] OMAP: hwmod: warn on missing clockdomain
Paul Walmsley p...@pwsan.com writes: Hi Kevin On Tue, 17 Nov 2009, Kevin Hilman wrote: WARN if a clock/hwmod is missing a clockdomain association since resulting hwmod will not be able to correctly enable/disable clocks. Wouldn't this check be best placed in the clock code? Possibly. The idea here was to flag an issue that will prevent the hwmod code from crashing. Doing something like below in the clock code may be the right place, but it creates lots of noise that didn't help debug the hwmod problem. clock omap_32k_fck is missing clockdomain clock virt_12m_ck is missing clockdomain clock virt_13m_ck is missing clockdomain clock virt_16_8m_ck is missing clockdomain clock virt_19_2m_ck is missing clockdomain clock virt_26m_ck is missing clockdomain clock virt_38_4m_ck is missing clockdomain clock osc_sys_ck is missing clockdomain clock sys_ck is missing clockdomain clock sys_altclk is missing clockdomain clock mcbsp_clks is missing clockdomain clock sys_clkout1 is missing clockdomain clock core_ck is missing clockdomain clock omap_96m_alwon_fck is missing clockdomain clock omap_96m_fck is missing clockdomain clock cm_96m_fck is missing clockdomain clock omap_54m_fck is missing clockdomain clock omap_48m_fck is missing clockdomain clock omap_12m_fck is missing clockdomain clock sys_clkout2 is missing clockdomain clock corex2_fck is missing clockdomain clock dpll1_fck is missing clockdomain clock emu_mpu_alwon_ck is missing clockdomain clock dpll2_fck is missing clockdomain clock rm_ick is missing clockdomain clock cpefuse_fck is missing clockdomain clock ts_fck is missing clockdomain clock usbtll_fck is missing clockdomain clock mcspi_fck is missing clockdomain clock mcspi_fck is missing clockdomain clock mcspi_fck is missing clockdomain clock mcspi_fck is missing clockdomain clock hdq_fck is missing clockdomain clock ssi_sst_fck is missing clockdomain clock security_l3_ick is missing clockdomain clock pka_ick is missing clockdomain clock omapctrl_ick is missing clockdomain clock security_l4_ick2 is missing clockdomain clock aes1_ick is missing clockdomain clock rng_ick is missing clockdomain clock sha11_ick is missing clockdomain clock des1_ick is missing clockdomain clock usim_fck is missing clockdomain clock sr1_fck is missing clockdomain clock sr2_fck is missing clockdomain clock secure_32k_fck is missing clockdomain clock gpt12_fck is missing clockdomain clock wdt1_fck is missing clockdomain diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c index 4716206..9022858 100644 --- a/arch/arm/mach-omap2/clock.c +++ b/arch/arm/mach-omap2/clock.c @@ -153,8 +153,10 @@ void omap2_init_clk_clkdm(struct clk *clk) { struct clockdomain *clkdm; - if (!clk-clkdm_name) + if (!clk-clkdm_name) { + pr_debug(clock %s is missing clockdomain\n, clk-name); return; + } clkdm = clkdm_lookup(clk-clkdm_name); if (clkdm) { k -- To unsubscribe from this list: send the line unsubscribe 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] V4L2: clear buf when vrfb buf not allocated
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Y, Kishore Sent: Wednesday, November 18, 2009 7:20 PM To: linux-me...@vger.kernel.org Cc: linux-omap@vger.kernel.org Subject: [PATCH] V4L2: clear buf when vrfb buf not allocated From 15246e4dfa6853d9aef48a4b8633f93efe40ed81 Mon Sep 17 00:00:00 2001 From: Kishore Y kishor...@ti.com Date: Thu, 12 Nov 2009 20:47:58 +0530 Subject: [PATCH] V4L2: clear buf when vrfb buf not allocated buffer memory is set to 0 only for the first time before the vrfb buffer is allocated Signed-off-by: Kishore Y kishor...@ti.com --- This patch is dependent on the patch [PATCH 4/4] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2 drivers/media/video/omap/omap_vout.c | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c index 7092ef2..0a9fdd7 100644 --- a/drivers/media/video/omap/omap_vout.c +++ b/drivers/media/video/omap/omap_vout.c @@ -223,9 +223,11 @@ static int omap_vout_allocate_vrfb_buffers(struct omap_vout_device *vout, unsigned int *count, int startindex) { int i, j; + int buffer_set; for (i = 0; i *count; i++) { - if (!vout-smsshado_virt_addr[i]) { + buffer_set = vout-smsshado_virt_addr[i]; + if (!buffer_set) { vout-smsshado_virt_addr[i] = omap_vout_alloc_buffer(vout-smsshado_size, vout-smsshado_phy_addr[i]); @@ -247,8 +249,10 @@ static int omap_vout_allocate_vrfb_buffers(struct omap_vout_device *vout, *count = 0; return -ENOMEM; } - memset((void *) vout-smsshado_virt_addr[i], 0, - vout-smsshado_size); + if (!buffer_set) { + memset((void *) vout-smsshado_virt_addr[i], 0, + vout-smsshado_size); + } } [Hiremath, Vaibhav] Why do we need this? Anyway if I understand correctly this function is getting called only once during REQBUF or probe, right? If you are selecting static_vrfb_allocation through module_params, then anyway REQBUF won't call this function again, since the buffers are already allocated. Thanks, Vaibhav return 0; } -- 1.5.4.3 Regards, Kishore Y Ph:- +918039813085 -- To unsubscribe from this list: send the line unsubscribe linux- media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-v5 1/4] OMAP2/3: Add support for flash on SDP boards
On Fri, Nov 13, 2009 at 2:10 AM, Tony Lindgren t...@atomide.com wrote: * Vimal Singh vimal.neww...@gmail.com [091110 02:08]: From 42f080e0915bbce1509fc8ab3773569fec0a44f1 Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Tue, 10 Nov 2009 11:39:39 +0530 Subject: [PATCH] OMAP2/3: Add support for flash on SDP boards [...] + if (!(__raw_readw(fpga_map_addr + REG_FPGA_REV))) + /* we dont have an DEBUG FPGA??? */ + /* Depend on #defines!! default to strata boot return param */ + return 0x0; Should iounmap before returning, or goto unmap. will correct it in next version. + /* S8-DIP-OFF = 1, S8-DIP-ON = 0 */ + cs = __raw_readw(fpga_map_addr + REG_FPGA_DIP_SWITCH_INPUT2) 0xf; + + /* ES2.0 SDP's onwards 4 dip switches are provided for CS */ + if (omap_rev() = OMAP3430_REV_ES1_0) + /* change (S8-1:4=DS-2:0) to (S8-4:1=DS-2:0) */ + cs = ((cs 8) 3) | ((cs 4) 1) | + ((cs 2) 1) | ((cs 1) 3); + else + /* change (S8-1:3=DS-2:0) to (S8-3:1=DS-2:0) */ + cs = ((cs 4) 2) | (cs 2) | ((cs 1) 2); + + iounmap(fpga_map_addr); + return cs; +} + +/** + * sdp3430_flash_init - Identify devices connected to GPMC and register. + * + * @return - void. + */ +void __init sdp_flash_init(void) +{ + u8 cs = 0; + u8 nandcs = GPMC_CS_NUM + 1; + u8 onenandcs = GPMC_CS_NUM + 1; + u8 idx; + unsigned char *config_sel = NULL; + + /* REVISIT: Is this return correct idx for 2430 SDP? + * for which cs configuration matches for 2430 SDP? + */ + idx = get_gpmc0_type(); + if (idx = MAX_SUPPORTED_GPMC_CONFIG) { + printk(KERN_ERR %s: Invalid chip select: %d\n, __func__, cs); + return; + } + config_sel = (unsigned char *)(chip_sel_sdp[idx]); + + /* Configure start address and size of NOR device */ + if (omap_rev() = OMAP3430_REV_ES1_0) { + sdp_nor_resource.start = FLASH_BASE_SDPV2; + sdp_nor_resource.end = FLASH_BASE_SDPV2 + + FLASH_SIZE_SDPV2 - 1; + } else { + sdp_nor_resource.start = FLASH_BASE_SDPV1; + sdp_nor_resource.end = FLASH_BASE_SDPV1 + + FLASH_SIZE_SDPV1 - 1; + } This should be done with gpmc_cs_request using the chip select and size. Please see gpmc_smc91x_init() for an example. I do not think this should be done with 'gpmc_cs_request'. NOR flashes have been treated somehow differently. + if (platform_device_register(sdp_nor_device) 0) + printk(KERN_ERR Unable to register NOR device\n); + + while (cs GPMC_CS_NUM) { + switch (config_sel[cs]) { + case PDC_NAND: + if (nandcs GPMC_CS_NUM) + nandcs = cs; + break; + case PDC_ONENAND: + if (onenandcs GPMC_CS_NUM) + onenandcs = cs; + break; + }; + cs++; + } + + if (onenandcs GPMC_CS_NUM) + printk(KERN_INFO OneNAND: Unable to find configuration + in GPMC\n ); + else + board_onenand_init(onenandcs); + + if (nandcs GPMC_CS_NUM) + printk(KERN_INFO NAND: Unable to find configuration + in GPMC\n ); + else + board_nand_init(nandcs); +} diff --git a/arch/arm/plat-omap/include/plat/board-sdp.h b/arch/arm/plat-omap/include/plat/board-sdp.h new file mode 100644 index 000..632f21a --- /dev/null +++ b/arch/arm/plat-omap/include/plat/board-sdp.h @@ -0,0 +1,15 @@ +/* + * arch/arm/plat-omap/include/plat/board-sdp.h + * + * Information structures for SDP-specific board config data + * + * Copyright (C) 2009 Nokia Corporation + * Copyright (C) 2009 Texas Instruments + * + * 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. + */ + +extern void sdp_flash_init(void); + diff --git a/arch/arm/plat-omap/include/plat/gpmc.h b/arch/arm/plat-omap/include/plat/gpmc.h index 9c99cda..c752ab7 100644 --- a/arch/arm/plat-omap/include/plat/gpmc.h +++ b/arch/arm/plat-omap/include/plat/gpmc.h @@ -27,6 +27,8 @@ #define GPMC_CONFIG 0x50 #define GPMC_STATUS 0x54 +#define GPMC_CS0_BASE 0x60 +#define GPMC_CS_SIZE 0x30 #define GPMC_CONFIG1_WRAPBURST_SUPP (1 31) #define GPMC_CONFIG1_READMULTIPLE_SUPP (1 30) -- 1.5.5 -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body
Re: [PATCH 4/4] OMAP3: add support for 192Mhz sgx clock
Sripathy, Vishwanath had written, on 11/18/2009 08:16 AM, the following: SGX can run at 192MHz on 3630 and this patch has changes to support this feature. Signed-off-by: Vishwanath BS vishwanath...@ti.com --- arch/arm/mach-omap2/clock34xx.c | 10 ++ arch/arm/mach-omap2/clock34xx.h | 33 + arch/arm/mach-omap2/cm-regbits-34xx.h |2 ++ 3 files changed, 45 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c index 77b88aa..885043e 100755 --- a/arch/arm/mach-omap2/clock34xx.c +++ b/arch/arm/mach-omap2/clock34xx.c @@ -128,6 +128,7 @@ static struct omap_clk omap34xx_clks[] = { CLK(NULL, emu_core_alwon_ck, emu_core_alwon_ck, CK_3XXX), CLK(NULL, dpll4_ck, dpll4_ck, CK_3XXX), CLK(NULL, dpll4_x2_ck,dpll4_x2_ck, CK_3XXX), + CLK(NULL, omap_192m_alwon_ck, omap_192m_alwon_ck, CK_363X), CLK(NULL, omap_96m_alwon_fck, omap_96m_alwon_fck, CK_3XXX), CLK(NULL, omap_96m_fck, omap_96m_fck, CK_3XXX), CLK(NULL, cm_96m_fck, cm_96m_fck,CK_3XXX), @@ -1224,6 +1225,15 @@ int __init omap2_clk_init(void) dpll4_ck.dpll_data-sd_div_mask = OMAP3630_PERIPH_DPLL_SD_DIV_MASK; dpll4_dd.mult_mask = OMAP3630_PERIPH_DPLL_MULT_MASK; cpu_mask |= RATE_IN_363X; + cpu_clkflg |= CK_363X; + omap_96m_alwon_fck.parent = omap_192m_alwon_ck; + omap_96m_alwon_fck.init = omap2_init_clksel_parent; + omap_96m_alwon_fck.clksel_reg = + OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL), + omap_96m_alwon_fck.clksel_mask = + OMAP3630_CLKSEL_96M_MASK; + omap_96m_alwon_fck.clksel = omap_96m_alwon_fck_clksel; + omap_96m_alwon_fck.recalc = omap2_clksel_recalc; We should not ideally be linking this to j type DPLL perhaps? are'nt these 36xx series specific? do we need FEATURE_HAS_192Mhz_CLK? that way the future AM series/37xx series could also use this. } } diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h index 93c92e5..6fe89df 100755 --- a/arch/arm/mach-omap2/clock34xx.h +++ b/arch/arm/mach-omap2/clock34xx.h @@ -654,12 +654,31 @@ static struct clk dpll4_m2x2_ck = { .recalc = omap3_clkoutx2_recalc, }; +/* Adding 192MHz Clock node needed by SGX */ +static struct clk omap_192m_alwon_ck = { + .name = omap_192m_alwon_ck, + .ops= clkops_null, + .parent = dpll4_m2x2_ck, + .recalc = followparent_recalc, +}; + /* * DPLL4 generates DPLL4_M2X2_CLK which is then routed into the PRM as * PRM_96M_ALWON_(F)CLK. Two clocks then emerge from the PRM: * 96M_ALWON_FCLK (called omap_96m_alwon_fck below) and * CM_96K_(F)CLK. */ +static const struct clksel_rate omap_96m_alwon_fck_rates[] = { + { .div = 1, .val = 1, .flags = RATE_IN_363X }, + { .div = 2, .val = 2, .flags = RATE_IN_363X | DEFAULT_RATE }, + { .div = 0 } +}; + +static const struct clksel omap_96m_alwon_fck_clksel[] = { + { .parent = omap_192m_alwon_ck, .rates = omap_96m_alwon_fck_rates }, + { .parent = NULL } +}; + static struct clk omap_96m_alwon_fck = { .name = omap_96m_alwon_fck, .ops= clkops_null, @@ -1223,6 +1242,18 @@ static const struct clksel_rate sgx_core_rates[] = { { .div = 3, .val = 0, .flags = RATE_IN_3XXX | DEFAULT_RATE }, { .div = 4, .val = 1, .flags = RATE_IN_3XXX }, { .div = 6, .val = 2, .flags = RATE_IN_3XXX }, + { .div = 2, .val = 5, .flags = RATE_IN_363X }, + { .div = 0 }, +}; + +static const struct clksel_rate sgx_192m_rates[] = { + { .div = 1, .val = 4, .flags = RATE_IN_363X | DEFAULT_RATE }, + { .div = 0 }, +}; + +static const struct clksel_rate sgx_corex2_rates[] = { + { .div = 3, .val = 6, .flags = RATE_IN_363X | DEFAULT_RATE }, + { .div = 5, .val = 7, .flags = RATE_IN_363X }, { .div = 0 }, }; @@ -1234,6 +1265,8 @@ static const struct clksel_rate sgx_96m_rates[] = { static const struct clksel sgx_clksel[] = { { .parent = core_ck,.rates = sgx_core_rates }, { .parent = cm_96m_fck, .rates = sgx_96m_rates }, + { .parent = omap_192m_alwon_ck, .rates = sgx_192m_rates }, + { .parent = corex2_fck, .rates = sgx_corex2_rates }, { .parent = NULL }, }; diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h b/arch/arm/mach-omap2/cm-regbits-34xx.h index a6383f9..39b3399 100755 --- a/arch/arm/mach-omap2/cm-regbits-34xx.h +++ b/arch/arm/mach-omap2/cm-regbits-34xx.h @@ -336,6 +336,8 @@ #define OMAP3430_CLKSEL_L4_MASK
Re: Problem trying to pull particular commit from PM tree
* Peter Barada pet...@logicpd.com [091118 06:20]: Is it possible to back up in time on the PM tree to find a particular commit, even across rebasings? I'm interested in the commit used by TI to base their AM3517 work on which is: [Commit:ef25c2a0e0]: OMAP3: PM: defconfig: enable SRF by default. I tried: git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git git checkout -b pm origin/pm git reset --hard ef25c2a0 But that came back with: fatal: ambiguous argument 'ef25c2a0': unknown revision or path not in the working tree. My git 'fu' is pretty weak. Any ideas why this doesn't work? Thanks in advance! Maybe ef25c2a0e0 is some TI internal commit? 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-v5 1/4] OMAP2/3: Add support for flash on SDP boards
* Vimal Singh vimal.neww...@gmail.com [091118 07:25]: On Fri, Nov 13, 2009 at 2:10 AM, Tony Lindgren t...@atomide.com wrote: * Vimal Singh vimal.neww...@gmail.com [091110 02:08]: From 42f080e0915bbce1509fc8ab3773569fec0a44f1 Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Tue, 10 Nov 2009 11:39:39 +0530 Subject: [PATCH] OMAP2/3: Add support for flash on SDP boards [...] + if (!(__raw_readw(fpga_map_addr + REG_FPGA_REV))) + /* we dont have an DEBUG FPGA??? */ + /* Depend on #defines!! default to strata boot return param */ + return 0x0; Should iounmap before returning, or goto unmap. will correct it in next version. + /* S8-DIP-OFF = 1, S8-DIP-ON = 0 */ + cs = __raw_readw(fpga_map_addr + REG_FPGA_DIP_SWITCH_INPUT2) 0xf; + + /* ES2.0 SDP's onwards 4 dip switches are provided for CS */ + if (omap_rev() = OMAP3430_REV_ES1_0) + /* change (S8-1:4=DS-2:0) to (S8-4:1=DS-2:0) */ + cs = ((cs 8) 3) | ((cs 4) 1) | + ((cs 2) 1) | ((cs 1) 3); + else + /* change (S8-1:3=DS-2:0) to (S8-3:1=DS-2:0) */ + cs = ((cs 4) 2) | (cs 2) | ((cs 1) 2); + + iounmap(fpga_map_addr); + return cs; +} + +/** + * sdp3430_flash_init - Identify devices connected to GPMC and register. + * + * @return - void. + */ +void __init sdp_flash_init(void) +{ + u8 cs = 0; + u8 nandcs = GPMC_CS_NUM + 1; + u8 onenandcs = GPMC_CS_NUM + 1; + u8 idx; + unsigned char *config_sel = NULL; + + /* REVISIT: Is this return correct idx for 2430 SDP? + * for which cs configuration matches for 2430 SDP? + */ + idx = get_gpmc0_type(); + if (idx = MAX_SUPPORTED_GPMC_CONFIG) { + printk(KERN_ERR %s: Invalid chip select: %d\n, __func__, cs); + return; + } + config_sel = (unsigned char *)(chip_sel_sdp[idx]); + + /* Configure start address and size of NOR device */ + if (omap_rev() = OMAP3430_REV_ES1_0) { + sdp_nor_resource.start = FLASH_BASE_SDPV2; + sdp_nor_resource.end = FLASH_BASE_SDPV2 + + FLASH_SIZE_SDPV2 - 1; + } else { + sdp_nor_resource.start = FLASH_BASE_SDPV1; + sdp_nor_resource.end = FLASH_BASE_SDPV1 + + FLASH_SIZE_SDPV1 - 1; + } This should be done with gpmc_cs_request using the chip select and size. Please see gpmc_smc91x_init() for an example. I do not think this should be done with 'gpmc_cs_request'. NOR flashes have been treated somehow differently. Can you please specify what the issue using gpmc_cs_request is? To me it seems that if you're not doing gpmc_cs_request, the gpmc can be in uninitialized state. I don't think we want to build our kernel assuming some hardcoded GPMC settings from the bootloader. 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-v5 2/4] OMAP3: Add support for NAND on ZOOM2/LDP boards
* Vimal Singh vimal.neww...@gmail.com [091118 06:38]: Tony, On Fri, Nov 13, 2009 at 2:14 AM, Tony Lindgren t...@atomide.com wrote: * Vimal Singh vimal.neww...@gmail.com [091110 02:08]: From 6f535d7128ca392458dd0cb31d138cda84747c06 Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Tue, 10 Nov 2009 11:42:45 +0530 Subject: [PATCH] OMAP3: Add support for NAND on ZOOM2/LDP boards [...] +static int omap_ldp_nand_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len) +{ + int ret = 0; + int chipnr; + int status; + unsigned long page; + struct nand_chip *this = mtd-priv; + printk(KERN_INFO nand_unlock: start: %08x, length: %d!\n, + (int)ofs, (int)len); + + /* select the NAND device */ + chipnr = (int)(ofs this-chip_shift); + this-select_chip(mtd, chipnr); + /* check the WP bit */ + this-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); + if ((this-read_byte(mtd) 0x80) == 0) { + printk(KERN_ERR nand_unlock: Device is write protected!\n); + ret = -EINVAL; + goto out; + } + + if ((ofs (mtd-writesize - 1)) != 0) { + printk(KERN_ERR nand_unlock: Start address must be + beginning of nand page!\n); + ret = -EINVAL; + goto out; + } + + if (len == 0 || (len (mtd-writesize - 1)) != 0) { + printk(KERN_ERR nand_unlock: Length must be a multiple of + nand page size!\n); + ret = -EINVAL; + goto out; + } + + /* submit address of first page to unlock */ + page = (unsigned long)(ofs this-page_shift); + this-cmdfunc(mtd, NAND_CMD_UNLOCK1, -1, page this-pagemask); + + /* submit ADDRESS of LAST page to unlock */ + page += (unsigned long)((ofs + len) this-page_shift) ; + this-cmdfunc(mtd, NAND_CMD_UNLOCK2, -1, page this-pagemask); + + /* call wait ready function */ + status = this-waitfunc(mtd, this); + udelay(1000); + /* see if device thinks it succeeded */ + if (status 0x01) { + /* there was an error */ + printk(KERN_ERR nand_unlock: error status =0x%08x , status); + ret = -EIO; + goto out; + } + + out: + /* de-select the NAND device */ + this-select_chip(mtd, -1); + return ret; +} Isn't the unlocking generic to the NAND device driver? Or is it somehow board specific? Yes, zoom2 boards come up with whole NAND locked, whereas it is not case for SDP boards. But the procedure should be done under drivers/mtd I believe using some standard tools. +static struct mtd_partition ldp_nand_partitions[] = { + /* All the partition sizes are listed in terms of NAND block size */ + { + .name = X-Loader-NAND, + .offset = 0, + .size = 4 * (64 * 2048), /* 512KB, 0x8 */ + .mask_flags = MTD_WRITEABLE, /* force read-only */ + }, + { + .name = U-Boot-NAND, + .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */ + .size = 10 * (64 * 2048), /* 1.25MB, 0x14 */ + .mask_flags = MTD_WRITEABLE, /* force read-only */ + }, + { + .name = Boot Env-NAND, + .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */ + .size = 2 * (64 * 2048), /* 256KB, 0x4 */ + }, + { + .name = Kernel-NAND, + .offset = MTDPART_OFS_APPEND, /* Offset = 0x020*/ + .size = 240 * (64 * 2048), /* 30M, 0x1E0 */ + }, +#ifdef CONFIG_MACH_OMAP_ZOOM2 + { + .name = system, + .offset = MTDPART_OFS_APPEND, /* Offset = 0x200 */ + .size = 1280 * (64 * 2048), /* 160M, 0xA00 */ + }, + { + .name = userdata, + .offset = MTDPART_OFS_APPEND, /* Offset = 0xC00 */ + .size = 256 * (64 * 2048), /* 32M, 0x200 */ + }, + { + .name = cache, + .offset = MTDPART_OFS_APPEND, /* Offset = 0xE00 */ + .size = 256 * (64 * 2048), /* 32M, 0x200 */ + }, +#else + { + .name = File System - NAND, + .offset = MTDPART_OFS_APPEND, /* Offset = 0x200 */ + .size = MTDPART_SIZ_FULL, /* 96MB, 0x600 */ + }, +#endif Please remove the ifdefs, you should be able to compile in all mach-omap2
Re: [PATCH] [mmc-omap] Add support for 16-bit and 32-bit registers
On Sat, Nov 14, 2009 at 07:24:55PM -0800, Cory Maccarrone wrote: The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring a modification of the register addresses in the mmc-omap driver. To make this as portable as possible, I made the following changes: Hmm, I would not trade portability anyone currently needs for complexity... * Moved register address offsets from drivers/mmc/host/omap.c to drivers/mmc/host/omap.h * Implemented a lookup table for 16-bit and 32-bit register offsets * Added a reg_size field in the mmc_omap_host structure * Added code in mmc_omap_probe() to populate the reg_size field based on processor in use * Added inline function to return the register offset based on the register size and register name * Modified mmc-omap driver to use the new inline function to call out register names All this could be probably done by making register definition an index and shifting it left by one or two depending on CPU. No lookup table needed. This change should allow the omap7xx-series of processors to correctly utilize the MMC driver. Did you test it? It does not work on 5910, see here: http://thread.gmane.org/gmane.linux.kernel.mmc/649 Best regards, ladis -- To unsubscribe from this list: send the line unsubscribe 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] FIX OMAP3:McBSP poll read and write for OMAP3
* Varadarajan, Charu Latha ch...@ti.com [091118 00:58]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, November 13, 2009 2:41 AM To: Varadarajan, Charu Latha Cc: linux-omap@vger.kernel.org; Syed, Rafiuddin Subject: Re: [PATCH V2] FIX OMAP3:McBSP poll read and write for OMAP3 * ch...@ti.com ch...@ti.com [091019 23:41]: omap_mcbsp_pollwrite and omap_mcbsp_pollread functions access McBSP registers as 16-bit registers. In OMAP3, McBSP registers (DRR_REG and DXR_REG) are limited to 32-bit data accesses (L4 Interconnect). 16-bit and 8-bit is not allowed and can corrupt register content. This patch adds omap3_mcbsp_pollwrite and omap3_mcbsp_pollread functions for OMAP3 cpu, inorder to perform 32 bit access of above mentioned McBSP registers. How about making the functions generic, I don't think we want to have separate omap1_mcbsp_pollread, omap2_mcbsp_pollread, omap3_mcbsp_pollread.. If it's not obvious how to implement it for some omap, just return an error based on the CPU type. My v1 patch handles this in a single generic API. [http://www.spinics.net/lists/linux-omap/msg19074.html and http://patchwork.kernel.org/patch/53631/] Well first of all we don't have any references to this function in our tree. Second, we have: #define OMAP_MCBSP_REG_DRR2 0x00 #define OMAP_MCBSP_REG_DRR1 0x02 #define OMAP_MCBSP_REG_DXR2 0x04 #define OMAP_MCBSP_REG_DXR1 0x06 Meaning that both DRR and DXR are 32-bits in length. And based on that it seems that at least omap_mcbsp_pollwrite is broken if it supports only one 16-bit write instead of 16 + 16 bits that the hardware seems to support. As per the review comments received for v1 patch, v2 patch is modified to have new API omap3_mcbsp_pollread/write in addition to omap_mcbsp_pollread/write APIs. That does not make much sense based on the fact that the hardware has 32-bits for DRR and DXR. Review comments for V1 mentioned that API signartures should not be changed from 16bit to 32 bit input parameters. If the API needs to be made generic, API signature has to be modified as given below (as in patch v1): -int omap_mcbsp_pollread(unsigned int id, u16 *buf) +int omap_mcbsp_pollread(unsigned int id, u32 *buf) If agreed for this generic API change, I shall post v3 patch which would handle cputypes dynamically inside the API To me it smells like the all drivers using the the omap_mcbsp_pollread/write are broken legacy drivers. So maybe we should just remove these two functions? If we really want to keep these around, we should review the drivers using these functions. And if we end up keeping these functions around, I like the first patch better, except it does not seem to support DRR2 and DXR2 on older hardware, so that's broken too. IMHO, we should rather set up this driver as a proper bus driver as suggested by Paul in a related thread. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] OMAP3: MCBSP: Suspend/resume failure fix
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Jarkko Nikula Sent: Saturday, November 14, 2009 1:50 PM To: Wang, Jane Cc: alsa-de...@alsa-project.org; linux-omap@vger.kernel.org; peter.ujfal...@nokia.com; broo...@opensource.wolfsonmicro.com Subject: Re: [PATCH 1/2] OMAP3: MCBSP: Suspend/resume failure fix Hi On Fri, 13 Nov 2009 11:39:47 -0600 Jane Wang jw...@ti.com wrote: McBSP fucntional clock is not disabled when suspend is triggerd which prevents PER domain entering target low-power state. To fix the problem: 1. Disable/enable McBSP functional clock for suspend/resume. 2. In addition, reconfigure McBSP, this is needed when systerm comes out of OFF state. ... --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -440,6 +440,8 @@ static inline int omap_mcbsp_get_dma_op_mode(unsigned int id) { return 0; } #endif int omap_mcbsp_request(unsigned int id); void omap_mcbsp_free(unsigned int id); +void omap_mcbsp_disable_fclk(unsigned int id); +void omap_mcbsp_enable_fclk(unsigned int id); ... --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -229,18 +229,28 @@ static int omap_mcbsp_dai_trigger(struct snd_pcm_substream *substream, int cmd, switch (cmd) { case SNDRV_PCM_TRIGGER_START: - case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: mcbsp_data-active++; omap_mcbsp_start(mcbsp_data-bus_id, play, !play); break; + case SNDRV_PCM_TRIGGER_RESUME: + mcbsp_data-active++; + omap_mcbsp_enable_fclk(mcbsp_data-bus_id); + omap_mcbsp_config(mcbsp_data-bus_id, + mcbsp_data-regs); + omap_mcbsp_start(mcbsp_data-bus_id, play, !play); + break; For me this looks more like a simple workaround for the audio case than comprehensive implementation to McBSP OFF mode context save/restore. My thoughts: 1. McBSP clock management partially moved out of low-level driver 2. McBSP client must do the context restore I do know that arch/arm/plat-omap/mcbsp.c enables the clocks in omap_mcbsp_request, I don't know do some API or feature there really require clocks (or McBSP itself) to be active just after the request time but I would look that path instead (even it is more complicated). If no API or feature would require active McBSP block before the omap_mcbsp_start call, then the clock management could be done inside the omap_mcbsp_start/-stop functions. [Aggarwal, Anuj] I tried doing that but it didn't work because before _start, we need to call set_hw_params which configures mcbsp, for which clocks are required. Also context save/restore operations belongs more to PM callbacks of .../plat-omap/mcbsp.c. Or probably that can be done also dynamically inside the omap_mcbsp_start/-stop for keeping the whole McBSP shutdown whenever it is idle. [Aggarwal, Anuj] I am sorry I couldn't understand that. Did you mean that PM hooks can be added in the mcbsp driver which can be registered and called As and when required? Any reference driver for this, if my understanding is correct? I think it's worth to look McBSP register cache concept [1] from Janusz Krzysztofik would it help all of this context save/restore operations. [Aggarwal, Anuj] I tried these two patches on omap3 evm but they didn't work for me. The system doesn't go to the suspend state when I do: echo mem /sys/power/state And the culprits were core (think sdma) and per domain. I tried disabling the mcbsp i/f clock as well but it didn't help. On mcbsp register dump, I couldn't find the sysconfig register getting configured. Could that be the root cause? -- Jarkko 1. http://www.spinics.net/lists/linux-omap/msg16720.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/3] omap: fix unlikely(x) y
* a...@linux-foundation.org a...@linux-foundation.org [091117 14:39]: From: Roel Kluin roel.kl...@gmail.com The closing parenthesis was not in the right location. I've added this to omap-fixes and will send to Linus today along with few other fixes. Andrew Russell, please let me know if you have this already queued for Linus, and I'll drop it from my queue. Regards, Tony Signed-off-by: Roel Kluin roel.kl...@gmail.com Cc: Tony Lindgren t...@atomide.com Cc: Russell King r...@arm.linux.org.uk Signed-off-by: Andrew Morton a...@linux-foundation.org --- arch/arm/plat-omap/gpio.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN arch/arm/plat-omap/gpio.c~omap-fix-unlikelyx-y arch/arm/plat-omap/gpio.c --- a/arch/arm/plat-omap/gpio.c~omap-fix-unlikelyx-y +++ a/arch/arm/plat-omap/gpio.c @@ -391,7 +391,7 @@ static inline int gpio_valid(int gpio) static int check_gpio(int gpio) { - if (unlikely(gpio_valid(gpio)) 0) { + if (unlikely(gpio_valid(gpio) 0)) { printk(KERN_ERR omap-gpio: invalid GPIO %d\n, gpio); dump_stack(); return -1; _ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] OMAP: cs should be positive in gpmc_cs_free()
* a...@linux-foundation.org a...@linux-foundation.org [091117 14:39]: From: Roel Kluin roel.kl...@gmail.com The index `cs' is signed, test whether it is negative before we release gpmc_cs_mem[cs]. I've added this too to omap-fixes and will send to Linus. Regards, Tony Signed-off-by: Roel Kluin roel.kl...@gmail.com Acked-by: Tony Lindgren t...@atomide.com Cc: Russell King r...@arm.linux.org.uk Signed-off-by: Andrew Morton a...@linux-foundation.org --- arch/arm/mach-omap2/gpmc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN arch/arm/mach-omap2/gpmc.c~omap-cs-should-be-positive-in-gpmc_cs_free arch/arm/mach-omap2/gpmc.c --- a/arch/arm/mach-omap2/gpmc.c~omap-cs-should-be-positive-in-gpmc_cs_free +++ a/arch/arm/mach-omap2/gpmc.c @@ -405,7 +405,7 @@ EXPORT_SYMBOL(gpmc_cs_request); void gpmc_cs_free(int cs) { spin_lock(gpmc_mem_lock); - if (cs = GPMC_CS_NUM || !gpmc_cs_reserved(cs)) { + if (cs = GPMC_CS_NUM || cs 0 || !gpmc_cs_reserved(cs)) { printk(KERN_ERR Trying to free non-reserved GPMC CS%d\n, cs); BUG(); spin_unlock(gpmc_mem_lock); _ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] OMAP3 hwmod: Add automatic OCP_SYSCONFIG AUTOIDLE handling
Paul Walmsley p...@pwsan.com writes: On Wed, 18 Nov 2009, Vimal Singh wrote: On Wed, Nov 18, 2009 at 6:35 AM, Kevin Hilman khil...@deeprootsystems.com wrote: From: Paul Walmsley p...@pwsan.com This patch fills in the OCP_SYSCONFIG.AUTOIDLE handling in the OMAP hwmod code. After this patch, the hwmod code will set the module AUTOIDLE bit (generally module.OCP_SYSCONFIG.AUTOIDLE) to 1 by default upon enable, and 1 upon disable. You wanted to say: 0 upon disable, isn't it? No, the original wording was intended, although it is somewhat confusing. This patch wasn't intended to be posted publicly; it combines two unrelated changes that should be split. Paul, sorry for posting this one. I didn't mean to include it in this series. 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/2] OMAP3: MCBSP: Suspend/resume failure fix
Also context save/restore operations belongs more to PM callbacks of .../plat-omap/mcbsp.c. Or probably that can be done also dynamically inside the omap_mcbsp_start/-stop for keeping the whole McBSP shutdown whenever it is idle. [Aggarwal, Anuj] I am sorry I couldn't understand that. Did you mean that PM hooks can be added in the mcbsp driver which can be registered and called As and when required? Any reference driver for this, if my understanding is correct? I think it's worth to look McBSP register cache concept [1] from Janusz Krzysztofik would it help all of this context save/restore operations. [Aggarwal, Anuj] I tried these two patches on omap3 evm but they didn't work for me. The system doesn't go to the suspend state when I do: echo mem /sys/power/state And the culprits were core (think sdma) and per domain. I tried disabling the mcbsp i/f clock as well but it didn't help. On mcbsp register dump, I couldn't find the sysconfig register getting configured. Could that be the root cause? Did you include this patch? http://git.kernel.org/?p=linux/kernel/git/broonie/sound-2.6.git;a=commit;h=9da65a99e5e6a074c586474961dbf560e439df50 Without this patch, omap_stop_dma() did not disable DMA channel. Regards, -Jane -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP: timekeeping: time should not stop during suspend
* Kevin Hilman khil...@deeprootsystems.com [091117 15:41]: During suspend, the kernel timekeeping subsystem is shut down. Before suspend and upon resume, it uses a weak function read_persistent_clock() to determine the amount of time that elapsed during suspend. This function was not implemented on OMAP, so from the timekeeping subsystem perspective (and thus userspace as well) it appeared that no time elapsed during suspend. This patch uses the 32k sync timer as a the persistent clock the 32k sync timer value converted to seconds. NOTE: This does *NOT* handle wrapping of the 32k sync timer, so wrapping of the 32k sync timer during suspend may cause problems. Also, there are not interrupts when the 32k sync timer wraps, so something else has to be done. Kevin, are you planning to queue this in your PM series for the next merge window? In that case Acked-by: Tony Lindgren t...@atomide.com If you want me to queue this as a fix for the -rc series, let me know. Regards, Tony Reported-by: Jon Hunter jon-hun...@ti.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- Since v1 of this patch, the signature of this function changed. Also note that forthcoming omap_device patches will depend on this function instead of getnstimeofday() since the timekeeping subsystem is suspended when we want to do omap_device timing measurements. arch/arm/plat-omap/common.c | 19 +++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c index cc050b3..8057966 100644 --- a/arch/arm/plat-omap/common.c +++ b/arch/arm/plat-omap/common.c @@ -172,6 +172,25 @@ unsigned long long sched_clock(void) clocksource_32k.mult, clocksource_32k.shift); } +/** + * read_persistent_clock - Return time from the persistent clock. + * + * Reads the time from a source which isn't disabled during PM: 32k sync + * Returns a timespec with tv_sec=0 and tv_nsec=0 if unsupported. + * + */ +void read_persistent_clock(struct timespec *ts) +{ + unsigned long long nsecs; + cycle_t cycles; + + ts-tv_sec = ts-tv_nsec = 0; + cycles = clocksource_32k.read(clocksource_32k); + nsecs = clocksource_cyc2ns(cycles, +clocksource_32k.mult, clocksource_32k.shift); + timespec_add_ns(ts, nsecs); +} + static int __init omap_init_clocksource_32k(void) { static char err[] __initdata = KERN_ERR -- 1.6.5.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] OMAP3 hwmod: Add automatic OCP_SYSCONFIG AUTOIDLE handling
On Wed, 18 Nov 2009, Kevin Hilman wrote: Paul, sorry for posting this one. I didn't mean to include it in this series. No worries, it was an effective motivation for me to repost the fixed split :-) Also I will take Vimal's feedback and update the commit message for the second patch. Anyway, the revised split are the first two patches posted in http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19497.html - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] OMAP clock/hwmod: fix off-by-one errors
On Wed, 18 Nov 2009, Tony Lindgren wrote: To me it sounds like this can wait until the merge window, so not adding to omap-fixes for now. Indeed, there's no rush on this one, so let's set it up for 2.6.33. I'll keep that macro in plat/system.h unless you or Russell have a better suggestion. It might be worth looking at the rest of the Linux codebase to see if there are other potential users; maybe someone might be willing to pick up a kernel-janitor task for this? Vikram, I agree with your comment. Maybe someone can send a patch to clean up ehci-hcd.c and any other users of the same idiom to use this macro for 2.6.33? Looks like also plat-omap/mailbox.c:__mbox_msg_send() and mach-omap2/powerdomain.c:pwrdm_wait_transition() would be good candidates for this, under arch/arm/*omap*. - Paul -- To unsubscribe from this list: send the line unsubscribe 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 8/10 v3] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox.
* Hiroshi DOYU hiroshi.d...@nokia.com [091118 03:52]: From: ext C.A, Subramaniam subramaniam...@ti.com Subject: [PATCH 8/10 v3] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox. Date: Wed, 18 Nov 2009 10:32:01 +0100 Hi Tony, Following is the version 3 of patch 8/10. It removes one typo in the v2 patch that I sent out earlier. Request you to take this version of the patch. Hiroshi, Thank you for pointing out the error. Request you to please review the patch. There may be some possibility to arrange multiple mailbox setup in more cleaner way, but for the moment it looks ok for me. OK, I've updated the patch in for-next. I'll post the omap4 mailbox series for review to linux-arm-kernel today. Please check that all the related patches in linux-omap for-next are OK too. 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
[PATCH 00/10] Omap mailbox updates for omap4 for 2.6.33
Hi all, Here are omap4 related mailbox changes for review. Regards, Tony --- C A Subramaniam (6): omap: mailbox: Add build specific changes to support omap mailbox omap: mailbox: Add resources and mailbox register base address for OMAP4 mailbox omap: mailbox: remove unnecessary arg for omap_mbox_msg_send omap: mailbox: Adds code changes to support OMAP4 mailbox omap: mailbox: OMAP4 Mailbox Patch to change the IRQ flag from IRQF_DISABLED to IRQF_SHARED omap: mailbox: OMAP4 Mailbox-driver Patch to support tasklet implementation Hiroshi DOYU (4): omap: mailbox: remove sequence bit checking omap: mailbox: remove class interface omap: mailbox: remove disable_/enable_mbox_irq in isr omap: mailbox: Expose omap_mbox_enable()/disable_irq() arch/arm/mach-omap2/Makefile |3 arch/arm/mach-omap2/devices.c | 36 +++- arch/arm/mach-omap2/mailbox.c | 140 -- arch/arm/plat-omap/include/plat/mailbox.h | 23 ++ arch/arm/plat-omap/include/plat/omap44xx.h |2 arch/arm/plat-omap/mailbox.c | 282 +--- 6 files changed, 217 insertions(+), 269 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
[PATCH 02/10] omap: mailbox: Add resources and mailbox register base address for OMAP4 mailbox
From: C A Subramaniam subramaniam...@ti.com This patch adds resource information of mailbox driver for OMAP4 mailbox module. Register base address also added Signed-off-by: C A Subramaniam subramaniam...@ti.com Signed-off-by: Ramesh Gupta G grgu...@ti.com Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/devices.c | 36 +--- arch/arm/plat-omap/include/plat/omap44xx.h |2 ++ 2 files changed, 29 insertions(+), 9 deletions(-) diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index 8b6cd8c..733d3dc 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -136,9 +136,10 @@ static inline void omap_init_camera(void) #if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE) -#define MBOX_REG_SIZE 0x120 +#define MBOX_REG_SIZE 0x120 -static struct resource omap2_mbox_resources[] = { +#ifdef CONFIG_ARCH_OMAP2 +static struct resource omap_mbox_resources[] = { { .start = OMAP24XX_MAILBOX_BASE, .end= OMAP24XX_MAILBOX_BASE + MBOX_REG_SIZE - 1, @@ -153,8 +154,10 @@ static struct resource omap2_mbox_resources[] = { .flags = IORESOURCE_IRQ, }, }; +#endif -static struct resource omap3_mbox_resources[] = { +#ifdef CONFIG_ARCH_OMAP3 +static struct resource omap_mbox_resources[] = { { .start = OMAP34XX_MAILBOX_BASE, .end= OMAP34XX_MAILBOX_BASE + MBOX_REG_SIZE - 1, @@ -165,6 +168,24 @@ static struct resource omap3_mbox_resources[] = { .flags = IORESOURCE_IRQ, }, }; +#endif + +#ifdef CONFIG_ARCH_OMAP4 + +#define OMAP4_MBOX_REG_SIZE0x130 +static struct resource omap_mbox_resources[] = { + { + .start = OMAP44XX_MAILBOX_BASE, + .end= OMAP44XX_MAILBOX_BASE + + OMAP4_MBOX_REG_SIZE - 1, + .flags = IORESOURCE_MEM, + }, + { + .start = INT_44XX_MAIL_U0_MPU, + .flags = IORESOURCE_IRQ, + }, +}; +#endif static struct platform_device mbox_device = { .name = omap2-mailbox, @@ -173,12 +194,9 @@ static struct platform_device mbox_device = { static inline void omap_init_mbox(void) { - if (cpu_is_omap2420()) { - mbox_device.num_resources = ARRAY_SIZE(omap2_mbox_resources); - mbox_device.resource = omap2_mbox_resources; - } else if (cpu_is_omap3430()) { - mbox_device.num_resources = ARRAY_SIZE(omap3_mbox_resources); - mbox_device.resource = omap3_mbox_resources; + if (cpu_is_omap2420() || cpu_is_omap3430() || cpu_is_omap44xx()) { + mbox_device.num_resources = ARRAY_SIZE(omap_mbox_resources); + mbox_device.resource = omap_mbox_resources; } else { pr_err(%s: platform not supported\n, __func__); return; diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h b/arch/arm/plat-omap/include/plat/omap44xx.h index 3361897..e52902a 100644 --- a/arch/arm/plat-omap/include/plat/omap44xx.h +++ b/arch/arm/plat-omap/include/plat/omap44xx.h @@ -40,5 +40,7 @@ #define OMAP44XX_LOCAL_TWD_BASE0x48240600 #define OMAP44XX_WKUPGEN_BASE 0x48281000 +#define OMAP44XX_MAILBOX_BASE (L4_44XX_BASE + 0xF4000) + #endif /* __ASM_ARCH_OMAP44XX_H */ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/10] omap: mailbox: remove sequence bit checking
From: Hiroshi DOYU hiroshi.d...@nokia.com Any protocol should be handled in the upper layer and mailbox driver shouldn't care about the contents of messages. Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/plat-omap/mailbox.c | 70 ++ 1 files changed, 4 insertions(+), 66 deletions(-) diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c index 734bff3..f82810e 100644 --- a/arch/arm/plat-omap/mailbox.c +++ b/arch/arm/plat-omap/mailbox.c @@ -28,54 +28,9 @@ #include plat/mailbox.h -static int enable_seq_bit; -module_param(enable_seq_bit, bool, 0); -MODULE_PARM_DESC(enable_seq_bit, Enable sequence bit checking.); - static struct omap_mbox *mboxes; static DEFINE_RWLOCK(mboxes_lock); -/* - * Mailbox sequence bit API - */ - -/* seq_rcv should be initialized with any value other than - * 0 and 1 31, to allow either value for the first - * message. */ -static inline void mbox_seq_init(struct omap_mbox *mbox) -{ - if (!enable_seq_bit) - return; - - /* any value other than 0 and 1 31 */ - mbox-seq_rcv = 0x; -} - -static inline void mbox_seq_toggle(struct omap_mbox *mbox, mbox_msg_t * msg) -{ - if (!enable_seq_bit) - return; - - /* add seq_snd to msg */ - *msg = (*msg 0x7fff) | mbox-seq_snd; - /* flip seq_snd */ - mbox-seq_snd ^= 1 31; -} - -static inline int mbox_seq_test(struct omap_mbox *mbox, mbox_msg_t msg) -{ - mbox_msg_t seq; - - if (!enable_seq_bit) - return 0; - - seq = msg (1 31); - if (seq == mbox-seq_rcv) - return -1; - mbox-seq_rcv = seq; - return 0; -} - /* Mailbox FIFO handle functions */ static inline mbox_msg_t mbox_fifo_read(struct omap_mbox *mbox) { @@ -113,13 +68,6 @@ static inline int is_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq) return mbox-ops-is_irq(mbox, irq); } -/* Mailbox Sequence Bit function */ -void omap_mbox_init_seq(struct omap_mbox *mbox) -{ - mbox_seq_init(mbox); -} -EXPORT_SYMBOL(omap_mbox_init_seq); - /* * message sender */ @@ -141,7 +89,6 @@ static int __mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg, void *arg) goto out; } - mbox_seq_toggle(mbox, msg); mbox_fifo_write(mbox, msg); out: return ret; @@ -254,11 +201,11 @@ static void mbox_rx_work(struct work_struct *work) /* * Mailbox interrupt handler */ -static void mbox_txq_fn(struct request_queue * q) +static void mbox_txq_fn(struct request_queue *q) { } -static void mbox_rxq_fn(struct request_queue * q) +static void mbox_rxq_fn(struct request_queue *q) { } @@ -284,11 +231,6 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox) msg = mbox_fifo_read(mbox); - if (unlikely(mbox_seq_test(mbox, msg))) { - pr_info(mbox: Illegal seq bit!(%08x)\n, msg); - if (mbox-err_notify) - mbox-err_notify(); - } blk_insert_request(q, rq, 0, (void *)msg); if (mbox-ops-type == OMAP_MBOX_TYPE1) @@ -320,7 +262,7 @@ static irqreturn_t mbox_interrupt(int irq, void *p) */ static ssize_t omap_mbox_write(struct device *dev, struct device_attribute *attr, - const char * buf, size_t count) + const char *buf, size_t count) { int ret; mbox_msg_t *p = (mbox_msg_t *)buf; @@ -357,10 +299,6 @@ omap_mbox_read(struct device *dev, struct device_attribute *attr, char *buf) blk_end_request_all(rq, 0); - if (unlikely(mbox_seq_test(mbox, *p))) { - pr_info(mbox: Illegal seq bit!(%08x) ignored\n, *p); - continue; - } p++; } @@ -383,7 +321,7 @@ static struct class omap_mbox_class = { }; static struct omap_mbox_queue *mbox_queue_alloc(struct omap_mbox *mbox, - request_fn_proc * proc, + request_fn_proc *proc, void (*work) (struct work_struct *)) { struct request_queue *q; -- To unsubscribe from this list: send the line unsubscribe 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/10] omap: mailbox: remove class interface
From: Hiroshi DOYU hiroshi.d...@nokia.com It's not used at present. Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/plat-omap/include/plat/mailbox.h |1 arch/arm/plat-omap/mailbox.c | 115 ++--- 2 files changed, 9 insertions(+), 107 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/mailbox.h b/arch/arm/plat-omap/include/plat/mailbox.h index b7a6991..319306a 100644 --- a/arch/arm/plat-omap/include/plat/mailbox.h +++ b/arch/arm/plat-omap/include/plat/mailbox.h @@ -8,7 +8,6 @@ #include linux/blkdev.h typedef u32 mbox_msg_t; -typedef void (mbox_receiver_t)(mbox_msg_t msg); struct omap_mbox; typedef int __bitwise omap_mbox_irq_t; diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c index f82810e..13ca236 100644 --- a/arch/arm/plat-omap/mailbox.c +++ b/arch/arm/plat-omap/mailbox.c @@ -71,7 +71,7 @@ static inline int is_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq) /* * message sender */ -static int __mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg, void *arg) +static int __mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg) { int ret = 0, i = 1000; @@ -82,15 +82,7 @@ static int __mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg, void *arg) return -1; udelay(1); } - - if (arg mbox-txq-callback) { - ret = mbox-txq-callback(arg); - if (ret) - goto out; - } - mbox_fifo_write(mbox, msg); - out: return ret; } @@ -152,7 +144,7 @@ static void mbox_tx_work(struct work_struct *work) tx_data = rq-special; - ret = __mbox_msg_send(mbox, tx_data-msg, tx_data-arg); + ret = __mbox_msg_send(mbox, tx_data-msg); if (ret) { enable_mbox_irq(mbox, IRQ_TX); spin_lock(q-queue_lock); @@ -180,11 +172,6 @@ static void mbox_rx_work(struct work_struct *work) mbox_msg_t msg; unsigned long flags; - if (mbox-rxq-callback == NULL) { - sysfs_notify(mbox-dev-kobj, NULL, mbox); - return; - } - while (1) { spin_lock_irqsave(q-queue_lock, flags); rq = blk_fetch_request(q); @@ -257,69 +244,6 @@ static irqreturn_t mbox_interrupt(int irq, void *p) return IRQ_HANDLED; } -/* - * sysfs files - */ -static ssize_t -omap_mbox_write(struct device *dev, struct device_attribute *attr, - const char *buf, size_t count) -{ - int ret; - mbox_msg_t *p = (mbox_msg_t *)buf; - struct omap_mbox *mbox = dev_get_drvdata(dev); - - for (; count = sizeof(mbox_msg_t); count -= sizeof(mbox_msg_t)) { - ret = omap_mbox_msg_send(mbox, be32_to_cpu(*p), NULL); - if (ret) - return -EAGAIN; - p++; - } - - return (size_t)((char *)p - buf); -} - -static ssize_t -omap_mbox_read(struct device *dev, struct device_attribute *attr, char *buf) -{ - unsigned long flags; - struct request *rq; - mbox_msg_t *p = (mbox_msg_t *) buf; - struct omap_mbox *mbox = dev_get_drvdata(dev); - struct request_queue *q = mbox-rxq-queue; - - while (1) { - spin_lock_irqsave(q-queue_lock, flags); - rq = blk_fetch_request(q); - spin_unlock_irqrestore(q-queue_lock, flags); - - if (!rq) - break; - - *p = (mbox_msg_t)rq-special; - - blk_end_request_all(rq, 0); - - p++; - } - - pr_debug(%02x %02x %02x %02x\n, buf[0], buf[1], buf[2], buf[3]); - - return (size_t) ((char *)p - buf); -} - -static DEVICE_ATTR(mbox, S_IRUGO | S_IWUSR, omap_mbox_read, omap_mbox_write); - -static ssize_t mbox_show(struct class *class, char *buf) -{ - return sprintf(buf, mbox); -} - -static CLASS_ATTR(mbox, S_IRUGO, mbox_show, NULL); - -static struct class omap_mbox_class = { - .name = omap-mailbox, -}; - static struct omap_mbox_queue *mbox_queue_alloc(struct omap_mbox *mbox, request_fn_proc *proc, void (*work) (struct work_struct *)) @@ -353,7 +277,7 @@ static void mbox_queue_free(struct omap_mbox_queue *q) kfree(q); } -static int omap_mbox_init(struct omap_mbox *mbox) +static int omap_mbox_startup(struct omap_mbox *mbox) { int ret; struct omap_mbox_queue *mq; @@ -436,7 +360,7 @@ struct omap_mbox *omap_mbox_get(const char *name) read_unlock(mboxes_lock); - ret = omap_mbox_init(mbox); + ret = omap_mbox_startup(mbox); if (ret) return ERR_PTR(-ENODEV); @@ -460,15 +384,6 @@ int omap_mbox_register(struct device *parent, struct omap_mbox *mbox) if (mbox-next)
[PATCH 05/10] omap: mailbox: remove disable_/enable_mbox_irq in isr
From: Hiroshi DOYU hiroshi.d...@nokia.com No need to handle it in isr, since irq won't happen during isr. Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/plat-omap/mailbox.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c index 13ca236..b49bb29 100644 --- a/arch/arm/plat-omap/mailbox.c +++ b/arch/arm/plat-omap/mailbox.c @@ -209,8 +209,6 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox) mbox_msg_t msg; struct request_queue *q = mbox-rxq-queue; - disable_mbox_irq(mbox, IRQ_RX); - while (!mbox_fifo_empty(mbox)) { rq = blk_get_request(q, WRITE, GFP_ATOMIC); if (unlikely(!rq)) @@ -226,7 +224,6 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox) /* no more messages in the fifo. clear IRQ source. */ ack_mbox_irq(mbox, IRQ_RX); - enable_mbox_irq(mbox, IRQ_RX); nomem: schedule_work(mbox-rxq-work); } -- To unsubscribe from this list: send the line unsubscribe 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/10] omap: mailbox: Expose omap_mbox_enable()/disable_irq()
From: Hiroshi DOYU hiroshi.d...@nokia.com Expose omap_mbox_enable()/disable_irq() Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com --- arch/arm/plat-omap/include/plat/mailbox.h | 12 arch/arm/plat-omap/mailbox.c | 12 ++-- 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/mailbox.h b/arch/arm/plat-omap/include/plat/mailbox.h index 8260a3f..bf06953 100644 --- a/arch/arm/plat-omap/include/plat/mailbox.h +++ b/arch/arm/plat-omap/include/plat/mailbox.h @@ -92,4 +92,16 @@ static inline void omap_mbox_restore_ctx(struct omap_mbox *mbox) mbox-ops-restore_ctx(mbox); } +static inline void omap_mbox_enable_irq(struct omap_mbox *mbox, + omap_mbox_irq_t irq) +{ + mbox-ops-enable_irq(mbox, irq); +} + +static inline void omap_mbox_disable_irq(struct omap_mbox *mbox, +omap_mbox_irq_t irq) +{ + mbox-ops-disable_irq(mbox, irq); +} + #endif /* MAILBOX_H */ diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c index 99ecf80..e6b3115 100644 --- a/arch/arm/plat-omap/mailbox.c +++ b/arch/arm/plat-omap/mailbox.c @@ -50,14 +50,6 @@ static inline int mbox_fifo_full(struct omap_mbox *mbox) } /* Mailbox IRQ handle functions */ -static inline void enable_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq) -{ - mbox-ops-enable_irq(mbox, irq); -} -static inline void disable_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq) -{ - mbox-ops-disable_irq(mbox, irq); -} static inline void ack_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq) { if (mbox-ops-ack_irq) @@ -144,7 +136,7 @@ static void mbox_tx_work(struct work_struct *work) ret = __mbox_msg_send(mbox, tx_data-msg); if (ret) { - enable_mbox_irq(mbox, IRQ_TX); + omap_mbox_enable_irq(mbox, IRQ_TX); spin_lock(q-queue_lock); blk_requeue_request(q, rq); spin_unlock(q-queue_lock); @@ -196,7 +188,7 @@ static void mbox_rxq_fn(struct request_queue *q) static void __mbox_tx_interrupt(struct omap_mbox *mbox) { - disable_mbox_irq(mbox, IRQ_TX); + omap_mbox_disable_irq(mbox, IRQ_TX); ack_mbox_irq(mbox, IRQ_TX); schedule_work(mbox-txq-work); } -- To unsubscribe from this list: send the line unsubscribe 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/10] omap: mailbox: Adds code changes to support OMAP4 mailbox
From: C A Subramaniam subramaniam...@ti.com This patch adds code changes in the mailbox driver module to add support for OMAP4 mailbox. Signed-off-by: Hari Kanigeri h-kanige...@ti.com Signed-off-by: C A Subramaniam subramaniam...@ti.com Signed-off-by: Ramesh Gupta G grgu...@ti.com Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/mailbox.c | 140 ++--- arch/arm/plat-omap/mailbox.c | 25 ++- 2 files changed, 136 insertions(+), 29 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 5ba3aa6..281ab63 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -18,6 +18,8 @@ #include plat/mailbox.h #include mach/irqs.h +#define DRV_NAME omap2-mailbox + #define MAILBOX_REVISION 0x000 #define MAILBOX_SYSCONFIG 0x010 #define MAILBOX_SYSSTATUS 0x014 @@ -27,8 +29,12 @@ #define MAILBOX_IRQSTATUS(u) (0x100 + 8 * (u)) #define MAILBOX_IRQENABLE(u) (0x104 + 8 * (u)) -#define MAILBOX_IRQ_NEWMSG(u) (1 (2 * (u))) -#define MAILBOX_IRQ_NOTFULL(u) (1 (2 * (u) + 1)) +#define OMAP4_MAILBOX_IRQSTATUS(u) (0x104 + 10 * (u)) +#define OMAP4_MAILBOX_IRQENABLE(u) (0x108 + 10 * (u)) +#define OMAP4_MAILBOX_IRQENABLE_CLR(u) (0x10c + 10 * (u)) + +#define MAILBOX_IRQ_NEWMSG(m) (1 (2 * (m))) +#define MAILBOX_IRQ_NOTFULL(m) (1 (2 * (m) + 1)) /* SYSCONFIG: register bit definition */ #define AUTOIDLE (1 0) @@ -39,7 +45,11 @@ #define RESETDONE (1 0) #define MBOX_REG_SIZE 0x120 + +#define OMAP4_MBOX_REG_SIZE0x130 + #define MBOX_NR_REGS (MBOX_REG_SIZE / sizeof(u32)) +#define OMAP4_MBOX_NR_REGS (OMAP4_MBOX_REG_SIZE / sizeof(u32)) static void __iomem *mbox_base; @@ -56,7 +66,8 @@ struct omap_mbox2_priv { unsigned long irqstatus; u32 newmsg_bit; u32 notfull_bit; - u32 ctx[MBOX_NR_REGS]; + u32 ctx[OMAP4_MBOX_NR_REGS]; + unsigned long irqdisable; }; static struct clk *mbox_ick_handle; @@ -82,8 +93,9 @@ static int omap2_mbox_startup(struct omap_mbox *mbox) mbox_ick_handle = clk_get(NULL, mailboxes_ick); if (IS_ERR(mbox_ick_handle)) { - pr_err(Can't get mailboxes_ick\n); - return -ENODEV; + printk(KERN_ERR Could not get mailboxes_ick: %d\n, + PTR_ERR(mbox_ick_handle)); + return PTR_ERR(mbox_ick_handle); } clk_enable(mbox_ick_handle); @@ -115,6 +127,7 @@ static void omap2_mbox_shutdown(struct omap_mbox *mbox) { clk_disable(mbox_ick_handle); clk_put(mbox_ick_handle); + mbox_ick_handle = NULL; } /* Mailbox FIFO handle functions */ @@ -143,7 +156,7 @@ static int omap2_mbox_fifo_full(struct omap_mbox *mbox) { struct omap_mbox2_fifo *fifo = ((struct omap_mbox2_priv *)mbox-priv)-tx_fifo; - return (mbox_read_reg(fifo-fifo_stat)); + return mbox_read_reg(fifo-fifo_stat); } /* Mailbox IRQ handle functions */ @@ -163,10 +176,9 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox, { struct omap_mbox2_priv *p = (struct omap_mbox2_priv *)mbox-priv; u32 l, bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit; - - l = mbox_read_reg(p-irqenable); + l = mbox_read_reg(p-irqdisable); l = ~bit; - mbox_write_reg(l, p-irqenable); + mbox_write_reg(l, p-irqdisable); } static void omap2_mbox_ack_irq(struct omap_mbox *mbox, @@ -189,15 +201,19 @@ static int omap2_mbox_is_irq(struct omap_mbox *mbox, u32 enable = mbox_read_reg(p-irqenable); u32 status = mbox_read_reg(p-irqstatus); - return (enable status bit); + return (int)(enable status bit); } static void omap2_mbox_save_ctx(struct omap_mbox *mbox) { int i; struct omap_mbox2_priv *p = mbox-priv; - - for (i = 0; i MBOX_NR_REGS; i++) { + int nr_regs; + if (cpu_is_omap44xx()) + nr_regs = OMAP4_MBOX_NR_REGS; + else + nr_regs = MBOX_NR_REGS; + for (i = 0; i nr_regs; i++) { p-ctx[i] = mbox_read_reg(i * sizeof(u32)); dev_dbg(mbox-dev, %s: [%02x] %08x\n, __func__, @@ -209,8 +225,12 @@ static void omap2_mbox_restore_ctx(struct omap_mbox *mbox) { int i; struct omap_mbox2_priv *p = mbox-priv; - - for (i = 0; i MBOX_NR_REGS; i++) { + int nr_regs; + if (cpu_is_omap44xx()) + nr_regs = OMAP4_MBOX_NR_REGS; + else + nr_regs = MBOX_NR_REGS; + for (i = 0; i nr_regs; i++) { mbox_write_reg(p-ctx[i], i * sizeof(u32)); dev_dbg(mbox-dev, %s: [%02x] %08x\n, __func__, @@ -242,7 +262,6 @@ static struct omap_mbox_ops omap2_mbox_ops = { */
[PATCH 09/10] omap: mailbox: OMAP4 Mailbox Patch to change the IRQ flag from IRQF_DISABLED to IRQF_SHARED
From: C A Subramaniam subramaniam...@ti.com Currently, this facilitates both the tesla and ducati sides to request for the same irq through an omap_mbox_get() call. Signed-off-by: C A Subramaniam subramaniam...@ti.com Signed-off-by: Ramesh Gupta G grgu...@ti.com Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/plat-omap/mailbox.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c index 2210c45..4d7947e 100644 --- a/arch/arm/plat-omap/mailbox.c +++ b/arch/arm/plat-omap/mailbox.c @@ -284,7 +284,7 @@ static int omap_mbox_startup(struct omap_mbox *mbox) write_unlock(mboxes_lock); } - ret = request_irq(mbox-irq, mbox_interrupt, IRQF_DISABLED, + ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED, mbox-name, mbox); if (unlikely(ret)) { printk(KERN_ERR -- To unsubscribe from this list: send the line unsubscribe 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/10] omap: mailbox: remove unnecessary arg for omap_mbox_msg_send
From: C A Subramaniam subramaniam...@ti.com Also removed from tx_data Signed-off-by: C A Subramaniam subramaniam...@ti.com Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/plat-omap/include/plat/mailbox.h |2 +- arch/arm/plat-omap/mailbox.c |4 +--- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/mailbox.h b/arch/arm/plat-omap/include/plat/mailbox.h index 319306a..8260a3f 100644 --- a/arch/arm/plat-omap/include/plat/mailbox.h +++ b/arch/arm/plat-omap/include/plat/mailbox.h @@ -63,7 +63,7 @@ struct omap_mbox { void(*err_notify)(void); }; -int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg, void *); +int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg); void omap_mbox_init_seq(struct omap_mbox *); struct omap_mbox *omap_mbox_get(const char *); diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c index b49bb29..99ecf80 100644 --- a/arch/arm/plat-omap/mailbox.c +++ b/arch/arm/plat-omap/mailbox.c @@ -88,7 +88,6 @@ static int __mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg) struct omap_msg_tx_data { mbox_msg_t msg; - void*arg; }; static void omap_msg_tx_end_io(struct request *rq, int error) @@ -97,7 +96,7 @@ static void omap_msg_tx_end_io(struct request *rq, int error) __blk_put_request(rq-q, rq); } -int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg, void* arg) +int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg) { struct omap_msg_tx_data *tx_data; struct request *rq; @@ -114,7 +113,6 @@ int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg, void* arg) } tx_data-msg = msg; - tx_data-arg = arg; rq-end_io = omap_msg_tx_end_io; blk_insert_request(q, rq, 0, tx_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: [PATCH 9/9 v2] omap3: pm: introduce 3630 opps
Menon, Nishanth wrote: Introduce the OMAP3630 OPPs including the defined OPP tuples. Further information on OMAP3630 can be found here: http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123navigationId=12836contentId=52606 OMAP36xx family introduces: VDD1 with 4 OPPs, of which OPP3 4 are available only on devices yet to be introduced in 36xx family. Meanwhile, VDD2 has 2 opps. Range of OPPs supported by Devices(tentative)- |-3630-600-| (default) |- 3630-800 -| (device: TBD) |- 3630-1000 -| (device: TBD) H/w OPP- OPP50 OPP100 OPP-Turbo OPP1G-SB VDD1 OPP1 OPP2 OPP3OPP4 VDD2 OPP1 OPP2 OPP2OPP2 Note: a) TI h/w naming for OPPs are now standardized in terms of OPP50, 100, Turbo and SB. This maps as shown above to the opp IDs (s/w term). b) For boards which need custom VDD1/2 OPPs, the opp table can be updated by the board file on a need basis after the omap3_pm_init_opp_table call. The OPPs introduced here are the official OPP table at this point in time. Tested on: SDP3430, SDP3630 Cc: Benoit Cousson b-cous...@ti.com Cc: Jon Hunter jon-hun...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Romit Dasgupta ro...@ti.com Cc: Sanjeev Premi pr...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com Cc: SuiLun Lam s-...@ti.com Cc: Thara Gopinath th...@ti.com Cc: Vishwanath Sripathy vishwanath...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/omap3-opp.h |9 arch/arm/mach-omap2/pm34xx.c| 87 +++--- 2 files changed, 80 insertions(+), 16 deletions(-) diff --git a/arch/arm/mach-omap2/omap3-opp.h b/arch/arm/mach-omap2/omap3-opp.h index 7f27f44..a5880b8 100644 --- a/arch/arm/mach-omap2/omap3-opp.h +++ b/arch/arm/mach-omap2/omap3-opp.h @@ -4,22 +4,31 @@ #include plat/omap-pm.h /* MPU speeds */ +#define S1000M 10 +#define S800M 8 #define S600M 6 #define S550M 55000 #define S500M 5 +#define S300M 3 #define S250M 25000 #define S125M 12500 /* DSP speeds */ +#define S875M 87500 +#define S660M 66000 +#define S520M 52000 #define S430M 43000 #define S400M 4 #define S360M 36000 +#define S260M 26000 #define S180M 18000 #define S90M9000 /* L3 speeds */ #define S83M8300 +#define S100M 1 #define S166M 16600 +#define S200M 2 extern struct omap_opp *omap3_mpu_rate_table; extern struct omap_opp *omap3_dsp_rate_table; diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 14131f8..86137bb 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -141,6 +141,41 @@ static __initdata struct omap_opp omap34xx_dsp_rate_table[] = { {0, 0, 0, 0}, }; +static __initdata struct omap_opp omap36xx_mpu_rate_table[] = { + {0, 0, 0, 0}, + /*OPP1 - 930mV - OPP50*/ + {true, S300M, VDD1_OPP1, 0x1a}, + /*OPP2 - 1.100V - OPP100*/ + {true, S600M, VDD1_OPP2, 0x28}, + /*OPP3 - 1.260V - OPP-Turbo*/ + {false, S800M, VDD1_OPP3, 0x34}, + /*OPP4 - 1.310V - OPP-SB*/ + {false, S1000M, VDD1_OPP4, 0x38}, + {0, 0, 0, 0}, +}; + +static __initdata struct omap_opp omap36xx_l3_rate_table[] = { + {0, 0, 0, 0}, + /*OPP1 - 930mV - OPP50 */ + {true, S100M, VDD2_OPP1, 0x1a}, + /*OPP2 - 1.375V - OPP100, OPP-Turbo, OPP-SB*/ Nishanth, can you correct the above comment? This should be 1.1375V and not 1.375V. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe 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] [mmc-omap] Add support for 16-bit and 32-bit registers
On Wed, Nov 18, 2009 at 10:41 AM, Ladislav Michl ladislav.mi...@seznam.cz wrote: On Sat, Nov 14, 2009 at 07:24:55PM -0800, Cory Maccarrone wrote: The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring a modification of the register addresses in the mmc-omap driver. To make this as portable as possible, I made the following changes: Hmm, I would not trade portability anyone currently needs for complexity... Agreed, this solution is more complicated than it probably needs to be. * Moved register address offsets from drivers/mmc/host/omap.c to drivers/mmc/host/omap.h * Implemented a lookup table for 16-bit and 32-bit register offsets * Added a reg_size field in the mmc_omap_host structure * Added code in mmc_omap_probe() to populate the reg_size field based on processor in use * Added inline function to return the register offset based on the register size and register name * Modified mmc-omap driver to use the new inline function to call out register names All this could be probably done by making register definition an index and shifting it left by one or two depending on CPU. No lookup table needed. Ah, good point, I hadn't considered that. I'll rework my implementation to do that and resubmit. This change should allow the omap7xx-series of processors to correctly utilize the MMC driver. Did you test it? It does not work on 5910, see here: http://thread.gmane.org/gmane.linux.kernel.mmc/649 Not sure why it wouldn't work on the 5910. I tested it on my device, and it works properly for me, but then I don't have an omap-based device that uses 32-bit register definitions. I'm confused at the post you have above though...Is that with my patch, or is that with something else? It seems to reference the status of current git, which I don't think this patch shouldn't be in. - Cory -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP: timekeeping: time should not stop during suspend
Tony Lindgren t...@atomide.com writes: * Kevin Hilman khil...@deeprootsystems.com [091117 15:41]: During suspend, the kernel timekeeping subsystem is shut down. Before suspend and upon resume, it uses a weak function read_persistent_clock() to determine the amount of time that elapsed during suspend. This function was not implemented on OMAP, so from the timekeeping subsystem perspective (and thus userspace as well) it appeared that no time elapsed during suspend. This patch uses the 32k sync timer as a the persistent clock the 32k sync timer value converted to seconds. NOTE: This does *NOT* handle wrapping of the 32k sync timer, so wrapping of the 32k sync timer during suspend may cause problems. Also, there are not interrupts when the 32k sync timer wraps, so something else has to be done. Kevin, are you planning to queue this in your PM series for the next merge window? In that case Acked-by: Tony Lindgren t...@atomide.com If you want me to queue this as a fix for the -rc series, let me know. I'll queue it for next merge window, thanks. Kevin Reported-by: Jon Hunter jon-hun...@ti.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- Since v1 of this patch, the signature of this function changed. Also note that forthcoming omap_device patches will depend on this function instead of getnstimeofday() since the timekeeping subsystem is suspended when we want to do omap_device timing measurements. arch/arm/plat-omap/common.c | 19 +++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c index cc050b3..8057966 100644 --- a/arch/arm/plat-omap/common.c +++ b/arch/arm/plat-omap/common.c @@ -172,6 +172,25 @@ unsigned long long sched_clock(void) clocksource_32k.mult, clocksource_32k.shift); } +/** + * read_persistent_clock - Return time from the persistent clock. + * + * Reads the time from a source which isn't disabled during PM: 32k sync + * Returns a timespec with tv_sec=0 and tv_nsec=0 if unsupported. + * + */ +void read_persistent_clock(struct timespec *ts) +{ +unsigned long long nsecs; +cycle_t cycles; + +ts-tv_sec = ts-tv_nsec = 0; +cycles = clocksource_32k.read(clocksource_32k); +nsecs = clocksource_cyc2ns(cycles, + clocksource_32k.mult, clocksource_32k.shift); +timespec_add_ns(ts, nsecs); +} + static int __init omap_init_clocksource_32k(void) { static char err[] __initdata = KERN_ERR -- 1.6.5.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] omap fixes for v2.6.32-rc7
Linus, Please pull few more omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus Regards, Tony The following changes since commit 156171c71a0dc4bce12b4408bb1591f8fe32dc1a: Linus Torvalds (1): Linux 2.6.32-rc7 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus Rajendra Nayak (1): omap3: clock: Fix the DPLL freqsel computations Roel Kluin (2): omap: fix unlikely(x) y OMAP: cs should be positive in gpmc_cs_free() Tero Kristo (1): omap3: clock: Fixed dpll3_m2x2 rate calculation Vimal Singh (1): omap: Fix keymap for zoom2 according to matrix keypad framwork arch/arm/mach-omap2/board-zoom2.c | 87 ++--- arch/arm/mach-omap2/clock34xx.c |2 +- arch/arm/mach-omap2/clock34xx.h |4 +- arch/arm/mach-omap2/gpmc.c|2 +- arch/arm/plat-omap/gpio.c |2 +- 5 files changed, 48 insertions(+), 49 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
Re: Problem trying to pull particular commit from PM tree
On Wed, 2009-11-18 at 08:57 -0800, Tony Lindgren wrote: * Peter Barada pet...@logicpd.com [091118 06:20]: Is it possible to back up in time on the PM tree to find a particular commit, even across rebasings? I'm interested in the commit used by TI to base their AM3517 work on which is: [Commit:ef25c2a0e0]: OMAP3: PM: defconfig: enable SRF by default. I tried: git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git git checkout -b pm origin/pm git reset --hard ef25c2a0 But that came back with: fatal: ambiguous argument 'ef25c2a0': unknown revision or path not in the working tree. My git 'fu' is pretty weak. Any ideas why this doesn't work? Thanks in advance! Maybe ef25c2a0e0 is some TI internal commit? I wouldn't think so. Their comment in the release notes is: This release package includes a series of patches on top of the pm branch maintained at http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=shortlog;h=pm;. Baseline: [Commit:ef25c2a0e0]: OMAP3: PM: defconfig: enable SRF by default. 1) How can I search the linux-omap git world to see if the commit string exists? 2) When trees are rebased, are the previous commits in the tree lost - i.e. if tree A has commits A', A'', etc, and is rebased on tree B(which does not have the commits A', A'' in it), are the commits A', A'', etc lost? Tony -- Peter Barada pet...@logicpd.com Logic Product Development, Inc. -- To unsubscribe from this list: send the line unsubscribe 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: Problem trying to pull particular commit from PM tree
On 11/18/2009 02:58 PM, Peter Barada wrote: On Wed, 2009-11-18 at 08:57 -0800, Tony Lindgren wrote: * Peter Baradapet...@logicpd.com [091118 06:20]: Is it possible to back up in time on the PM tree to find a particular commit, even across rebasings? I'm interested in the commit used by TI to base their AM3517 work on which is: [Commit:ef25c2a0e0]: OMAP3: PM: defconfig: enable SRF by default. I tried: git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git git checkout -b pm origin/pm git reset --hard ef25c2a0 But that came back with: fatal: ambiguous argument 'ef25c2a0': unknown revision or path not in the working tree. My git 'fu' is pretty weak. Any ideas why this doesn't work? Thanks in advance! Maybe ef25c2a0e0 is some TI internal commit? I wouldn't think so. Their comment in the release notes is: This release package includes a series of patches on top of the pm branch maintained at http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=shortlog;h=pm;. Baseline: [Commit:ef25c2a0e0]: OMAP3: PM: defconfig: enable SRF by default. 1) How can I search the linux-omap git world to see if the commit string exists? 2) When trees are rebased, are the previous commits in the tree lost - i.e. if tree A has commits A', A'', etc, and is rebased on tree B(which does not have the commits A', A'' in it), are the commits A', A'', etc lost? Did you try specifying the entire key 'ef25c2a0e0', not just 'ef25c2a0'? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe 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] [mmc-omap] Add support for 16-bit and 32-bit registers
On Wed, Nov 18, 2009 at 01:09:22PM -0800, Cory Maccarrone wrote: On Wed, Nov 18, 2009 at 10:41 AM, Ladislav Michl ladislav.mi...@seznam.cz wrote: Did you test it? It does not work on 5910, see here: http://thread.gmane.org/gmane.linux.kernel.mmc/649 Not sure why it wouldn't work on the 5910. I tested it on my device, and it works properly for me, but then I don't have an omap-based device that uses 32-bit register definitions. I'm confused at the post you have above though...Is that with my patch, or is that with something else? It seems to reference the status of current git, which I don't think this patch shouldn't be in. To put it clear, current git does not work and it is unrelated to your patch. If driver works for you with your patch, then either your MMC card or controller in your SoC survives multiple init sequences or it has something to do with clock settings or... You can find two more people confirming this here: http://www.spinics.net/lists/linux-omap/msg09547.html I'll probably need to find some time to read MMC spec. ladis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] OMAP3: Clock changes for OMAP3630
Sripathy, Vishwanath vishwanath...@ti.com writes: This patch set introduces clock changes for OMAP3630. Major changes in OMAP3630 w.r.t clock are 1. Introduction of j type dpll4 2. CLKSEL filed width is increased by 1 bit for DPLL4M3, M4, M5 and M6 3. SGX can be run at 192Mhz Patch set has been created for linux-omap-pm tree FYI... these patches are line-wrapped. 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: Problem trying to pull particular commit from PM tree
Peter Barada pet...@logicpd.com writes: On Wed, 2009-11-18 at 08:57 -0800, Tony Lindgren wrote: * Peter Barada pet...@logicpd.com [091118 06:20]: Is it possible to back up in time on the PM tree to find a particular commit, even across rebasings? I'm interested in the commit used by TI to base their AM3517 work on which is: [Commit:ef25c2a0e0]: OMAP3: PM: defconfig: enable SRF by default. I tried: git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git git checkout -b pm origin/pm git reset --hard ef25c2a0 But that came back with: fatal: ambiguous argument 'ef25c2a0': unknown revision or path not in the working tree. My git 'fu' is pretty weak. Any ideas why this doesn't work? Thanks in advance! Maybe ef25c2a0e0 is some TI internal commit? I wouldn't think so. Their comment in the release notes is: This release package includes a series of patches on top of the pm branch maintained at http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=shortlog;h=pm;. Baseline: [Commit:ef25c2a0e0]: OMAP3: PM: defconfig: enable SRF by default. 1) How can I search the linux-omap git world to see if the commit string exists? 2) When trees are rebased, are the previous commits in the tree lost - i.e. if tree A has commits A', A'', etc, and is rebased on tree B(which does not have the commits A', A'' in it), are the commits A', A'', etc lost? When a branch is rebased, all the commit IDs in that branch change, so finding a change by commit ID in a rebased branch (like PM branch) is impossible. 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 05/12] omap3evm: Add board revision function, v2
* Hiremath, Vaibhav hvaib...@ti.com [091116 19:56]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Tuesday, November 17, 2009 4:58 AM To: linux-arm-ker...@lists.infradead.org Cc: Gupta, Ajay Kumar; linux-omap@vger.kernel.org; Hiremath, Vaibhav; Premi, Sanjeev Subject: [PATCH 05/12] omap3evm: Add board revision function From: Ajay Kumar Gupta ajay.gu...@ti.com Added function to differentiate between the OMAP3EVM revisions. The chip-id of the ethernet PHY is being used for this purpose. Rev A to D : 0x0115 Rev = E : 0x9220 Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Signed-off-by: Sanjeev Premi pr...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/board-omap3evm.c| 33 +++ arch/arm/plat-omap/include/plat/board.h | 18 + 2 files changed, 51 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach- omap2/board-omap3evm.c index 1edf06a..6bb9a37 100644 --- a/arch/arm/mach-omap2/board-omap3evm.c +++ b/arch/arm/mach-omap2/board-omap3evm.c @@ -46,9 +46,40 @@ #define OMAP3EVM_ETHR_START0x2c00 #define OMAP3EVM_ETHR_SIZE 1024 +#define OMAP3EVM_ETHR_ID_REV 0x50 #define OMAP3EVM_ETHR_GPIO_IRQ 176 #define OMAP3EVM_SMC911X_CS5 +static u8 omap3_evm_version; + +u8 get_omap3_evm_rev(void) +{ + return omap3_evm_version; +} +EXPORT_SYMBOL(get_omap3_evm_rev); + +static void __init omap3_evm_get_revision(void) +{ + void __iomem *ioaddr; + unsigned int smsc_id; + + /* Ethernet PHY ID is stored at ID_REV register */ + ioaddr = ioremap_nocache(OMAP3EVM_ETHR_START, SZ_1K); [Hiremath, Vaibhav] I think we should check for the return value. Good catch, updated version below. Tony From f62482b652928c06c9ecfe546f03532276a6f5e6 Mon Sep 17 00:00:00 2001 From: Ajay Kumar Gupta ajay.gu...@ti.com Date: Fri, 13 Nov 2009 17:37:30 -0800 Subject: [PATCH] omap3evm: Add board revision function Added function to differentiate between the OMAP3EVM revisions. The chip-id of the ethernet PHY is being used for this purpose. Rev A to D : 0x0115 Rev = E : 0x9220 Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Signed-off-by: Sanjeev Premi pr...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c index 1edf06a..149d45c 100644 --- a/arch/arm/mach-omap2/board-omap3evm.c +++ b/arch/arm/mach-omap2/board-omap3evm.c @@ -46,9 +46,42 @@ #define OMAP3EVM_ETHR_START 0x2c00 #define OMAP3EVM_ETHR_SIZE 1024 +#define OMAP3EVM_ETHR_ID_REV 0x50 #define OMAP3EVM_ETHR_GPIO_IRQ 176 #define OMAP3EVM_SMC911X_CS 5 +static u8 omap3_evm_version; + +u8 get_omap3_evm_rev(void) +{ + return omap3_evm_version; +} +EXPORT_SYMBOL(get_omap3_evm_rev); + +static void __init omap3_evm_get_revision(void) +{ + void __iomem *ioaddr; + unsigned int smsc_id; + + /* Ethernet PHY ID is stored at ID_REV register */ + ioaddr = ioremap_nocache(OMAP3EVM_ETHR_START, SZ_1K); + if (!ioaddr) + return; + smsc_id = readl(ioaddr + OMAP3EVM_ETHR_ID_REV) 0x; + iounmap(ioaddr); + + switch (smsc_id) { + /*SMSC9115 chipset*/ + case 0x0115: + omap3_evm_version = OMAP3EVM_BOARD_GEN_1; + break; + /*SMSC 9220 chipset*/ + case 0x9220: + default: + omap3_evm_version = OMAP3EVM_BOARD_GEN_2; + } +} + static struct resource omap3evm_smc911x_resources[] = { [0] = { .start = OMAP3EVM_ETHR_START, @@ -321,6 +354,8 @@ static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = { static void __init omap3_evm_init(void) { + omap3_evm_get_revision(); + omap3_evm_i2c_init(); platform_add_devices(omap3_evm_devices, ARRAY_SIZE(omap3_evm_devices)); diff --git a/arch/arm/plat-omap/include/plat/board.h b/arch/arm/plat-omap/include/plat/board.h index c4fc69f..abb17b6 100644 --- a/arch/arm/plat-omap/include/plat/board.h +++ b/arch/arm/plat-omap/include/plat/board.h @@ -14,6 +14,18 @@ #include plat/gpio-switch.h +/* + * OMAP35x EVM revision + * Run time detection of EVM revision is done by reading Ethernet + * PHY ID - + * GEN_1 = 0x0115 + * GEN_2 = 0x9220 + */ +enum { + OMAP3EVM_BOARD_GEN_1 = 0, /* EVM Rev between A - D */ + OMAP3EVM_BOARD_GEN_2, /* EVM Rev = Rev E */ +}; + /* Different peripheral ids */ #define OMAP_TAG_CLOCK 0x4f01 #define OMAP_TAG_LCD 0x4f05 @@ -157,4 +169,10 @@ extern int omap_board_config_size; /* for TI reference platforms sharing the same debug card */ extern int debug_card_init(u32 addr, unsigned gpio); +/* OMAP3EVM revision */ +#if defined(CONFIG_MACH_OMAP3EVM) +u8 get_omap3_evm_rev(void); +#else +#define get_omap3_evm_rev() (-EINVAL) +#endif #endif
linux-next: manual merge of the input tree with the omap tree
Hi Dmitry, Today's linux-next merge of the input tree got a conflict in arch/arm/mach-omap2/board-rx51-peripherals.c between commit ebff0472f451a07fae9f4e72bdc2af4c52ebb682 (omap3: rx51: Add wl1251 wlan driver support) from the omap tree and commit 5018461a887d58f4601207deeebb7c352c2da20a (ARM OMAP3: RX-51 board - add initialization of gpio keys) from the input tree. Just overlapping additions. I fixed it up (see below) and can carry the fix as necessary. -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc arch/arm/mach-omap2/board-rx51-peripherals.c index caaeadc,a5c02a4..000 --- a/arch/arm/mach-omap2/board-rx51-peripherals.c +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c @@@ -21,53 -20,103 +21,134 @@@ #include linux/delay.h #include linux/regulator/machine.h #include linux/gpio.h + #include linux/gpio_keys.h #include linux/mmc/host.h -#include mach/mcspi.h -#include mach/mux.h -#include mach/board.h -#include mach/common.h -#include mach/dma.h -#include mach/gpmc.h -#include mach/onenand.h -#include mach/gpmc-smc91x.h +#include plat/mcspi.h +#include plat/mux.h +#include plat/board.h +#include plat/common.h +#include plat/dma.h +#include plat/gpmc.h +#include plat/onenand.h +#include plat/gpmc-smc91x.h #include mmc-twl4030.h #define SYSTEM_REV_B_USES_VAUX3 0x1699 #define SYSTEM_REV_S_USES_VAUX3 0x8 +#define RX51_WL1251_POWER_GPIO87 +#define RX51_WL1251_IRQ_GPIO 42 + +static void rx51_wl1251_set_power(bool enable); + +static struct wl12xx_platform_data wl1251_pdata = { + .set_power = rx51_wl1251_set_power, +}; + +static struct omap2_mcspi_device_config wl1251_mcspi_config = { + .turbo_mode = 0, + .single_channel = 1, +}; + +/* list all spi devices here */ +enum { + RX51_SPI_WL1251, +}; + +static struct spi_board_info rx51_peripherals_spi_board_info[] __initdata = { + [RX51_SPI_WL1251] = { + .modalias = wl1251, + .bus_num= 4, + .chip_select= 0, + .max_speed_hz = 4800, + .mode = SPI_MODE_2, + .controller_data= wl1251_mcspi_config, + .platform_data = wl1251_pdata, + }, +}; + + #if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE) + + #define RX51_GPIO_CAMERA_LENS_COVER 110 + #define RX51_GPIO_CAMERA_FOCUS68 + #define RX51_GPIO_CAMERA_CAPTURE 69 + #define RX51_GPIO_KEYPAD_SLIDE71 + #define RX51_GPIO_LOCK_BUTTON 113 + #define RX51_GPIO_PROXIMITY 89 + + #define RX51_GPIO_DEBOUNCE_TIMEOUT10 + + static struct gpio_keys_button rx51_gpio_keys[] = { + { + .desc = Camera Lens Cover, + .type = EV_SW, + .code = SW_CAMERA_LENS_COVER, + .gpio = RX51_GPIO_CAMERA_LENS_COVER, + .active_low = 1, + .debounce_interval = RX51_GPIO_DEBOUNCE_TIMEOUT, + }, { + .desc = Camera Focus, + .type = EV_KEY, + .code = KEY_CAMERA_FOCUS, + .gpio = RX51_GPIO_CAMERA_FOCUS, + .active_low = 1, + .debounce_interval = RX51_GPIO_DEBOUNCE_TIMEOUT, + }, { + .desc = Camera Capture, + .type = EV_KEY, + .code = KEY_CAMERA, + .gpio = RX51_GPIO_CAMERA_CAPTURE, + .active_low = 1, + .debounce_interval = RX51_GPIO_DEBOUNCE_TIMEOUT, + }, { + .desc = Lock Button, + .type = EV_KEY, + .code = KEY_SCREENLOCK, + .gpio = RX51_GPIO_LOCK_BUTTON, + .active_low = 1, + .debounce_interval = RX51_GPIO_DEBOUNCE_TIMEOUT, + }, { + .desc = Keypad Slide, + .type = EV_SW, + .code = SW_KEYPAD_SLIDE, + .gpio = RX51_GPIO_KEYPAD_SLIDE, + .active_low = 1, + .debounce_interval = RX51_GPIO_DEBOUNCE_TIMEOUT, + }, { + .desc = Proximity Sensor, + .type = EV_SW, + .code = SW_FRONT_PROXIMITY, + .gpio = RX51_GPIO_PROXIMITY, + .active_low = 0, + .debounce_interval = RX51_GPIO_DEBOUNCE_TIMEOUT, +
Re: linux-next: manual merge of the input tree with the omap tree
* Stephen Rothwell s...@canb.auug.org.au [091118 18:11]: Hi Dmitry, Today's linux-next merge of the input tree got a conflict in arch/arm/mach-omap2/board-rx51-peripherals.c between commit ebff0472f451a07fae9f4e72bdc2af4c52ebb682 (omap3: rx51: Add wl1251 wlan driver support) from the omap tree and commit 5018461a887d58f4601207deeebb7c352c2da20a (ARM OMAP3: RX-51 board - add initialization of gpio keys) from the input tree. Just overlapping additions. I fixed it up (see below) and can carry the fix as necessary. Thanks again for dealing with these merge conflicts again Stephen! I've cherry picked 765af10de6d93820def9978c53ed828e4d3bd4f4 from Dmitry's tree to keep things compiling. Then I've added a modified version of 5018461a887d58f4601207deeebb7c352c2da20a to omap for-next branch. Dmitry, could you please drop 5018461a887d58f4601207deeebb7c352c2da20a from your tree now? Because of us moving the omap headers from mach to plat, there will be a conflict otherwise. Sorry for all the hassles with this merge window, this should be an issue for this merge window only. Regards, Tony -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc arch/arm/mach-omap2/board-rx51-peripherals.c index caaeadc,a5c02a4..000 --- a/arch/arm/mach-omap2/board-rx51-peripherals.c +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c @@@ -21,53 -20,103 +21,134 @@@ #include linux/delay.h #include linux/regulator/machine.h #include linux/gpio.h + #include linux/gpio_keys.h #include linux/mmc/host.h -#include mach/mcspi.h -#include mach/mux.h -#include mach/board.h -#include mach/common.h -#include mach/dma.h -#include mach/gpmc.h -#include mach/onenand.h -#include mach/gpmc-smc91x.h +#include plat/mcspi.h +#include plat/mux.h +#include plat/board.h +#include plat/common.h +#include plat/dma.h +#include plat/gpmc.h +#include plat/onenand.h +#include plat/gpmc-smc91x.h #include mmc-twl4030.h #define SYSTEM_REV_B_USES_VAUX3 0x1699 #define SYSTEM_REV_S_USES_VAUX3 0x8 +#define RX51_WL1251_POWER_GPIO 87 +#define RX51_WL1251_IRQ_GPIO42 + +static void rx51_wl1251_set_power(bool enable); + +static struct wl12xx_platform_data wl1251_pdata = { +.set_power = rx51_wl1251_set_power, +}; + +static struct omap2_mcspi_device_config wl1251_mcspi_config = { +.turbo_mode = 0, +.single_channel = 1, +}; + +/* list all spi devices here */ +enum { +RX51_SPI_WL1251, +}; + +static struct spi_board_info rx51_peripherals_spi_board_info[] __initdata = { +[RX51_SPI_WL1251] = { +.modalias = wl1251, +.bus_num= 4, +.chip_select= 0, +.max_speed_hz = 4800, +.mode = SPI_MODE_2, +.controller_data= wl1251_mcspi_config, +.platform_data = wl1251_pdata, +}, +}; + + #if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE) + + #define RX51_GPIO_CAMERA_LENS_COVER 110 + #define RX51_GPIO_CAMERA_FOCUS 68 + #define RX51_GPIO_CAMERA_CAPTURE69 + #define RX51_GPIO_KEYPAD_SLIDE 71 + #define RX51_GPIO_LOCK_BUTTON 113 + #define RX51_GPIO_PROXIMITY 89 + + #define RX51_GPIO_DEBOUNCE_TIMEOUT 10 + + static struct gpio_keys_button rx51_gpio_keys[] = { + { + .desc = Camera Lens Cover, + .type = EV_SW, + .code = SW_CAMERA_LENS_COVER, + .gpio = RX51_GPIO_CAMERA_LENS_COVER, + .active_low = 1, + .debounce_interval = RX51_GPIO_DEBOUNCE_TIMEOUT, + }, { + .desc = Camera Focus, + .type = EV_KEY, + .code = KEY_CAMERA_FOCUS, + .gpio = RX51_GPIO_CAMERA_FOCUS, + .active_low = 1, + .debounce_interval = RX51_GPIO_DEBOUNCE_TIMEOUT, + }, { + .desc = Camera Capture, + .type = EV_KEY, + .code = KEY_CAMERA, + .gpio = RX51_GPIO_CAMERA_CAPTURE, + .active_low = 1, + .debounce_interval = RX51_GPIO_DEBOUNCE_TIMEOUT, + }, { + .desc = Lock Button, + .type = EV_KEY, + .code = KEY_SCREENLOCK, + .gpio = RX51_GPIO_LOCK_BUTTON, + .active_low = 1, + .debounce_interval = RX51_GPIO_DEBOUNCE_TIMEOUT, + }, { + .desc
[PATCH 2/8] AI TB: Board file of Always Innovating OMAP3-based Touch Book
Signed-off-by: Gregoire Gentil grego...@gentil.com --- arch/arm/mach-omap2/board-omap3touchbook.c | 683 1 files changed, 683 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/board-omap3touchbook.c diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c b/arch/arm/mach-omap2/board-omap3touchbook.c new file mode 100644 index 000..ad3ef6e --- /dev/null +++ b/arch/arm/mach-omap2/board-omap3touchbook.c @@ -0,0 +1,683 @@ +/* + * linux/arch/arm/mach-omap2/board-omap3touchbook.c + * + * Copyright (C) 2009 Always Innovating + * + * Modified from mach-omap2/board-omap3beagleboard.c + * + * Initial code: Grégoire Gentil, Tim Yamin + * + * 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/init.h +#include linux/platform_device.h +#include linux/delay.h +#include linux/err.h +#include linux/clk.h +#include linux/io.h +#include linux/leds.h +#include linux/gpio.h +#include linux/input.h +#include linux/gpio_keys.h + +#include linux/mtd/mtd.h +#include linux/mtd/partitions.h +#include linux/mtd/nand.h + +#include plat/mcspi.h +#include linux/spi/spi.h + +#include linux/spi/ads7846.h +#include linux/mma7455l.h + +#include plat/dmtimer.h +#include linux/backlight.h + +#include linux/regulator/machine.h +#include linux/i2c/twl4030.h + +#include mach/hardware.h +#include asm/mach-types.h +#include asm/mach/arch.h +#include asm/mach/map.h +#include asm/mach/flash.h + +#include plat/board.h +#include plat/common.h +#include plat/gpmc.h +#include plat/nand.h +#include plat/mux.h +#include plat/usb.h +#include plat/timer-gp.h + +#include mmc-twl4030.h + +#include asm/setup.h + +#define GPMC_CS0_BASE 0x60 +#define GPMC_CS_SIZE 0x30 + +#define NAND_BLOCK_SIZE SZ_128K + +#define OMAP3_AC_GPIO 136 +#define OMAP3_TS_GPIO 162 +#define TB_BL_PWM_TIMER 9 +#define TB_KILL_POWER_GPIO 168 + +unsigned long touchbook_revision; + +static struct mtd_partition omap3touchbook_nand_partitions[] = { + /* All the partition sizes are listed in terms of NAND block size */ + { + .name = X-Loader, + .offset = 0, + .size = 4 * NAND_BLOCK_SIZE, + .mask_flags = MTD_WRITEABLE, /* force read-only */ + }, + { + .name = U-Boot, + .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */ + .size = 15 * NAND_BLOCK_SIZE, + .mask_flags = MTD_WRITEABLE, /* force read-only */ + }, + { + .name = U-Boot Env, + .offset = MTDPART_OFS_APPEND, /* Offset = 0x26 */ + .size = 1 * NAND_BLOCK_SIZE, + }, + { + .name = Kernel, + .offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */ + .size = 32 * NAND_BLOCK_SIZE, + }, + { + .name = File System, + .offset = MTDPART_OFS_APPEND, /* Offset = 0x68 */ + .size = MTDPART_SIZ_FULL, + }, +}; + +static struct omap_nand_platform_data omap3touchbook_nand_data = { + .options = NAND_BUSWIDTH_16, + .parts = omap3touchbook_nand_partitions, + .nr_parts = ARRAY_SIZE(omap3touchbook_nand_partitions), + .dma_channel = -1, /* disable DMA in OMAP NAND driver */ + .nand_setup = NULL, + .dev_ready = NULL, +}; + +static struct resource omap3touchbook_nand_resource = { + .flags = IORESOURCE_MEM, +}; + +static struct platform_device omap3touchbook_nand_device = { + .name = omap2-nand, + .id = -1, + .dev = { + .platform_data = omap3touchbook_nand_data, + }, + .num_resources = 1, + .resource = omap3touchbook_nand_resource, +}; + +#include sdram-micron-mt46h32m32lf-6.h + +static struct twl4030_hsmmc_info mmc[] = { + { + .mmc = 1, + .wires = 8, + .gpio_wp = 29, + }, + {} /* Terminator */ +}; + +static struct platform_device omap3_touchbook_lcd_device = { + .name = omap3touchbook_lcd, + .id = -1, +}; + +static struct omap_lcd_config omap3_touchbook_lcd_config __initdata = { + .ctrl_name = internal, +}; + +static struct regulator_consumer_supply touchbook_vmmc1_supply = { + .supply = vmmc, +}; + +static struct regulator_consumer_supply touchbook_vsim_supply = { + .supply = vmmc_aux, +}; + +static struct gpio_led gpio_leds[]; + +static int touchbook_twl_gpio_setup(struct device *dev, + unsigned gpio, unsigned ngpio) +{ + if (system_rev = 0x20 system_rev = 0x34301000) { + omap_cfg_reg(AG9_34XX_GPIO23); + mmc[0].gpio_wp = 23; + } else { + omap_cfg_reg(AH8_34XX_GPIO29); + } + /* gpio + 0 is mmc0_cd (input/IRQ) */ + mmc[0].gpio_cd = gpio + 0; + twl4030_mmc_init(mmc); + + /* link regulators to MMC adapters */ + touchbook_vmmc1_supply.dev = mmc[0].dev; + touchbook_vsim_supply.dev = mmc[0].dev; + + /* REVISIT: need ehci-omap hooks for external VBUS + * power switch and overcurrent detect + */ + + gpio_request(gpio + 1, EHCI_nOC); + gpio_direction_input(gpio + 1); + + /* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, active low) */ + gpio_request(gpio + TWL4030_GPIO_MAX, nEN_USB_PWR); + gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); + + /* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */ +
[PATCH 7/8] AI TB: Video driver of Always Innovating OMAP3-based Touch Book
Signed-off-by: Gregoire Gentil grego...@gentil.com --- drivers/video/omap/lcd_omap3touchbook.c | 130 +++ 1 files changed, 130 insertions(+), 0 deletions(-) create mode 100644 drivers/video/omap/lcd_omap3touchbook.c diff --git a/drivers/video/omap/lcd_omap3touchbook.c b/drivers/video/omap/lcd_omap3touchbook.c new file mode 100644 index 000..5b58703 --- /dev/null +++ b/drivers/video/omap/lcd_omap3touchbook.c @@ -0,0 +1,130 @@ +/* + * LCD panel support for the Touch Book + * + * Author: Gregoire Gentil grego...@gentil.com + * + * Derived from drivers/video/omap/lcd-omap3beagle.c + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + */ + +#include linux/module.h +#include linux/platform_device.h +#include linux/gpio.h +#include linux/i2c/twl4030.h + +#include plat/mux.h +#include plat/omapfb.h +#include asm/mach-types.h + +#define LCD_PANEL_ENABLE_GPIO 176 + +static int omap3beagle_panel_init(struct lcd_panel *panel, + struct omapfb_device *fbdev) +{ + gpio_request(LCD_PANEL_ENABLE_GPIO, LCD enable); + return 0; +} + +static void omap3beagle_panel_cleanup(struct lcd_panel *panel) +{ + gpio_free(LCD_PANEL_ENABLE_GPIO); +} + +static int omap3beagle_panel_enable(struct lcd_panel *panel) +{ + gpio_set_value(LCD_PANEL_ENABLE_GPIO, 1); + return 0; +} + +static void omap3beagle_panel_disable(struct lcd_panel *panel) +{ + gpio_set_value(LCD_PANEL_ENABLE_GPIO, 0); +} + +static unsigned long omap3beagle_panel_get_caps(struct lcd_panel *panel) +{ + return 0; +} + +struct lcd_panel omap3beagle_panel = { + .name = omap3beagle, + .config = OMAP_LCDC_PANEL_TFT, + + .bpp = 16, + .data_lines = 24, + .x_res = 1024, + .y_res = 600, + .hsw = 3, + .hfp = 3, + .hbp = 39, + .vsw = 1, + .vfp = 2, + .vbp = 7, + + .pixel_clock = 64000, + + .init = omap3touchbook_panel_init, + .cleanup = omap3touchbook_panel_cleanup, + .enable = omap3touchbook_panel_enable, + .disable = omap3touchbook_panel_disable, + .get_caps = omap3touchbook_panel_get_caps, +}; + +static int omap3touchbook_panel_probe(struct platform_device *pdev) +{ + omapfb_register_panel(omap3beagle_panel); + return 0; +} + +static int omap3touchbook_panel_remove(struct platform_device *pdev) +{ + return 0; +} + +static int omap3touchbook_panel_suspend(struct platform_device *pdev, +pm_message_t mesg) +{ + return 0; +} + +static int omap3touchbook_panel_resume(struct platform_device *pdev) +{ + return 0; +} + +struct platform_driver omap3touchbook_panel_driver = { + .probe = omap3touchbook_panel_probe, + .remove = omap3touchbook_panel_remove, + .suspend = omap3touchbook_panel_suspend, + .resume = omap3touchbook_panel_resume, + .driver = { + .name = omap3touchbook_lcd, + .owner = THIS_MODULE, + }, +}; + +static int __init omap3touchbook_panel_drv_init(void) +{ + return platform_driver_register(omap3beagle_panel_driver); +} + +static void __exit omap3touchbook_panel_drv_exit(void) +{ + platform_driver_unregister(omap3touchbook_panel_driver); +} + +module_init(omap3touchbook_panel_drv_init); +module_exit(omap3touchbook_panel_drv_exit); -- 1.6.0.4 From f5576d74460c00bf82707fc9a2d4db12227b55e0 Mon Sep 17 00:00:00 2001 From: Gregoire Gentil grego...@gentil.com Date: Wed, 18 Nov 2009 18:34:14 -0800 Subject: [PATCH] Video driver of Always Innovating OMAP3-based Touch Book Signed-off-by: Gregoire Gentil grego...@gentil.com --- drivers/video/omap/lcd_omap3touchbook.c | 130 +++ 1 files changed, 130 insertions(+), 0 deletions(-) create mode 100644 drivers/video/omap/lcd_omap3touchbook.c diff --git a/drivers/video/omap/lcd_omap3touchbook.c b/drivers/video/omap/lcd_omap3touchbook.c new file mode 100644 index 000..5b58703 --- /dev/null +++ b/drivers/video/omap/lcd_omap3touchbook.c @@ -0,0 +1,130 @@ +/* + * LCD panel support for the Touch Book + * + * Author: Gregoire Gentil grego...@gentil.com + * + * Derived from drivers/video/omap/lcd-omap3beagle.c + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of +
RE: [PATCH 0/8] musb: Add structure 'musb_hdrc_board_data'
Hi, -Original Message- From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com] Sent: Wednesday, November 18, 2009 7:50 PM To: Gupta, Ajay Kumar Cc: linux-...@vger.kernel.org; davinci-linux-open-sou...@linux.davincidsp.com; coolo...@kernel.org; felipe.ba...@nokia.com; linux-omap@vger.kernel.org; Gadiyar, Anand Subject: Re: [PATCH 0/8] musb: Add structure 'musb_hdrc_board_data' Hello. Ajay Kumar Gupta wrote: This patch set adds a new structure 'musb_hdrc_board_data' to get all board specific data from board files. It is actually done to accomodate ULPI_VBUSCONTROL programming required for OMAP3EVM Rev =E which uses external Vbus supply to support 500mA. It's not clear why it was necessary to create yet another structure. You could your new field to 'struct musb_hdrc_platfrom_data'... This a actually a simpler approach and would avoid changing Davinci/BLackFin Specific files. Felipe/Anand, Is it ok to add 'extvbus' in 'musb_hdrc_platform_data' and pass this data from all OMAP board files. Anyways we do have 'musb_config' which has all platform sepecific information. -Ajay Regards, Ajay WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe 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/8] AI TB: HID file for Always Innovating OMAP3-based Touch Book keyboard
Hi Gregoire, On Wed, Nov 18, 2009 at 06:57:54PM -0800, Gregoire Gentil wrote: + +int touchbook_create_sysfs(struct hid_device *hdev) +{ + int i; + int r; + + for (i = 0; i ARRAY_SIZE(touchbook_hid_attrs); i++) { + r = device_create_file(hdev-dev, + touchbook_hid_attrs[i]); + + if (r) { + dev_err(hdev-dev, failed to create sysfs file\n); + return r; + } + } + You just reimplemented sysfs attribute group. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html