Re: [PATCH 8/10 v2] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox.

[Hiroshi DOYU]

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.

[C.A, Subramaniam]

 

 -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.

[Hiroshi DOYU]

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

[Vimal Singh]

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

[Reddy, Teerth]

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

[Sripathy, Vishwanath]

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

[Reddy, Teerth]

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.

[C.A, Subramaniam]

 -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

[G, Manjunath Kondaiah]

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

[Varadarajan, Charu Latha]

 

-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

[Mike Rapoport]

(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

[Gadiyar, Anand]

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

[Enric Balletbò i Serra]

 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

[Aggarwal, Anuj]

 -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.

[C.A, Subramaniam]

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

[Enric Balletbo i Serra]

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

[Reddy, Teerth]

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

[Reddy, Teerth]

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

[Mike Rapoport]

(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

[Paul Walmsley]

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

[Gadiyar, Anand]

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

[Paul Walmsley]

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

[Paul Walmsley]

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

[Paul Walmsley]

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

[Paul Walmsley]

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

[Paul Walmsley]

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

[Paul Walmsley]

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()

[Paul Walmsley]

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

[Paul Walmsley]

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

[Paul Walmsley]

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

[Paul Walmsley]

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

[Paul Walmsley]

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

[Paul Walmsley]

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

[Paul Walmsley]

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

[Paul Walmsley]

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

[Gadiyar, Anand]

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.

[Hiroshi DOYU]

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

[Tero.Kristo]

 

-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

[Mark Brown]

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

[Mark Brown]

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

[Anand Gadiyar]

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

[Gopinath, Thara]

-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

[Sripathy, Vishwanath]

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

[Sripathy, Vishwanath]

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

[Sripathy, Vishwanath]

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

[Kevin Hilman]

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

[Sripathy, Vishwanath]

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'

[Sergei Shtylyov]

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

[Peter Barada]

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

[Jarkko Nikula]

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

[Kevin Hilman]

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

[Vimal Singh]

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

[Kevin Hilman]

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

[Alessandro Zummo]

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

[Kevin Hilman]

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

[Hiremath, Vaibhav]

 -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

[Vimal Singh]

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

[Nishanth Menon]

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

[Tony Lindgren]

* 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

[Tony Lindgren]

* 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

[Tony Lindgren]

* 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

[Ladislav Michl]

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

[Tony Lindgren]

* 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

[Aggarwal, Anuj]

 -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

[Tony Lindgren]

* 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()

[Tony Lindgren]

* 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

[Kevin Hilman]

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

[Wang, Jane]

  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

[Tony Lindgren]

* 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

[Paul Walmsley]

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

[Paul Walmsley]

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.

[Tony Lindgren]

* 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

[Tony Lindgren]

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

[Tony Lindgren]

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

[Tony Lindgren]

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

[Tony Lindgren]

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

[Tony Lindgren]

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()

[Tony Lindgren]

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

[Tony Lindgren]

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

[Tony Lindgren]

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

[Tony Lindgren]

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

[Jon Hunter]

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

[Cory Maccarrone]

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

[Kevin Hilman]

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

[Tony Lindgren]

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

[Peter Barada]

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

[Gary Thomas]

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

[Ladislav Michl]

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

[Kevin Hilman]

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

[Kevin Hilman]

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

[Tony Lindgren]

* 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

[Stephen Rothwell]

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

[Tony Lindgren]

* 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

[Gregoire Gentil]

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

[Gregoire Gentil]

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'

[Gupta, Ajay Kumar]

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

[Dmitry Torokhov]

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