date:20100401


Hi,

On Wed, Mar 31, 2010 at 02:23:52PM +0200, ext Charulatha V wrote:

diff --git a/arch/arm/mach-omap1/include/mach/gpio.h 
b/arch/arm/mach-omap1/include/mach/gpio.h
index e737706..c4945d7 100644
--- a/arch/arm/mach-omap1/include/mach/gpio.h
+++ b/arch/arm/mach-omap1/include/mach/gpio.h
@@ -3,3 +3,91 @@
 */

#include plat/gpio.h
+
+/*
+ * OMAP1510 GPIO registers
+ */
+#define OMAP1510_GPIO_BASE 0xfffce000
+#define OMAP1510_GPIO_DATA_INPUT   0x00
+#define OMAP1510_GPIO_DATA_OUTPUT  0x04
+#define OMAP1510_GPIO_DIR_CONTROL  0x08
+#define OMAP1510_GPIO_INT_CONTROL  0x0c
+#define OMAP1510_GPIO_INT_MASK 0x10
+#define OMAP1510_GPIO_INT_STATUS   0x14
+#define OMAP1510_GPIO_PIN_CONTROL  0x18
+
+#define OMAP1510_IH_GPIO_BASE  64
+
+/*
+ * OMAP1610 specific GPIO registers
+ */
+#define OMAP1610_GPIO1_BASE0xfffbe400
+#define OMAP1610_GPIO2_BASE0xfffbec00
+#define OMAP1610_GPIO3_BASE0xfffbb400
+#define OMAP1610_GPIO4_BASE0xfffbbc00
+#define OMAP1610_GPIO_REVISION 0x
+#define OMAP1610_GPIO_SYSCONFIG0x0010
+#define OMAP1610_GPIO_SYSSTATUS0x0014
+#define OMAP1610_GPIO_IRQSTATUS1   0x0018
+#define OMAP1610_GPIO_IRQENABLE1   0x001c
+#define OMAP1610_GPIO_WAKEUPENABLE 0x0028
+#define OMAP1610_GPIO_DATAIN   0x002c
+#define OMAP1610_GPIO_DATAOUT  0x0030
+#define OMAP1610_GPIO_DIRECTION0x0034
+#define OMAP1610_GPIO_EDGE_CTRL1   0x0038
+#define OMAP1610_GPIO_EDGE_CTRL2   0x003c
+#define OMAP1610_GPIO_CLEAR_IRQENABLE1 0x009c
+#define OMAP1610_GPIO_CLEAR_WAKEUPENA  0x00a8
+#define OMAP1610_GPIO_CLEAR_DATAOUT0x00b0
+#define OMAP1610_GPIO_SET_IRQENABLE1   0x00dc
+#define OMAP1610_GPIO_SET_WAKEUPENA0x00e8
+#define OMAP1610_GPIO_SET_DATAOUT  0x00f0
+
+/*
+ * OMAP7XX specific GPIO registers
+ */
+#define OMAP7XX_GPIO1_BASE 0xfffbc000
+#define OMAP7XX_GPIO2_BASE 0xfffbc800
+#define OMAP7XX_GPIO3_BASE 0xfffbd000
+#define OMAP7XX_GPIO4_BASE 0xfffbd800
+#define OMAP7XX_GPIO5_BASE 0xfffbe000
+#define OMAP7XX_GPIO6_BASE 0xfffbe800
+#define OMAP7XX_GPIO_DATA_INPUT0x00
+#define OMAP7XX_GPIO_DATA_OUTPUT   0x04
+#define OMAP7XX_GPIO_DIR_CONTROL   0x08
+#define OMAP7XX_GPIO_INT_CONTROL   0x0c
+#define OMAP7XX_GPIO_INT_MASK  0x10
+#define OMAP7XX_GPIO_INT_STATUS0x14
+
+#define OMAP1_MPUIO_VBASE  OMAP1_MPUIO_BASE
+#define OMAP1_MPUIO_BASE   0xfffb5000
+
+#if (defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850))
+#define OMAP_MPUIO_INPUT_LATCH 0x00
+#define OMAP_MPUIO_OUTPUT  0x02
+#define OMAP_MPUIO_IO_CNTL 0x04
+#define OMAP_MPUIO_KBR_LATCH   0x08
+#define OMAP_MPUIO_KBC 0x0a
+#define OMAP_MPUIO_GPIO_EVENT_MODE 0x0c
+#define OMAP_MPUIO_GPIO_INT_EDGE   0x0e
+#define OMAP_MPUIO_KBD_INT 0x10
+#define OMAP_MPUIO_GPIO_INT0x12
+#define OMAP_MPUIO_KBD_MASKIT  0x14
+#define OMAP_MPUIO_GPIO_MASKIT 0x16
+#define OMAP_MPUIO_GPIO_DEBOUNCING 0x18
+#define OMAP_MPUIO_LATCH   0x1a
+#else
+#define OMAP_MPUIO_INPUT_LATCH 0x00
+#define OMAP_MPUIO_OUTPUT  0x04
+#define OMAP_MPUIO_IO_CNTL 0x08
+#define OMAP_MPUIO_KBR_LATCH   0x10
+#define OMAP_MPUIO_KBC 0x14
+#define OMAP_MPUIO_GPIO_EVENT_MODE 0x18
+#define OMAP_MPUIO_GPIO_INT_EDGE   0x1c
+#define OMAP_MPUIO_KBD_INT 0x20
+#define OMAP_MPUIO_GPIO_INT0x24
+#define OMAP_MPUIO_KBD_MASKIT  0x28
+#define OMAP_MPUIO_GPIO_MASKIT 0x2c
+#define OMAP_MPUIO_GPIO_DEBOUNCING 0x30
+#define OMAP_MPUIO_LATCH   0x34
+#endif


Add prefixes to these defines and remove the ifdefs.
This breaks multi-omap builds.


-struct gpio_bank {
-   unsigned long pbase;
-   void __iomem *base;
-   u16 irq;
-   u16 virtual_irq_start;
-   int method;
-#if defined(CONFIG_ARCH_OMAP16XX) || defined(CONFIG_ARCH_OMAP2PLUS)
-   u32 suspend_wakeup;
-   u32 saved_wakeup;
-#endif
-#ifdef CONFIG_ARCH_OMAP2PLUS
-   u32 non_wakeup_gpios;
-   u32 enabled_non_wakeup_gpios;
-
-   u32 saved_datain;
-   u32 saved_fallingdetect;
-   u32 saved_risingdetect;
-#endif
-   u32 level_mask;
-   u32 toggle_mask;
-   spinlock_t lock;
-   struct gpio_chip chip;
-   struct clk *dbck;
-   u32 mod_usage;
-};


defines are fine, but this structure belongs to this driver. Nobody else 
should need to poke on it. Keep it here.



@@ -625,10 +421,12 @@ void omap_set_gpio_debounce(int gpio, int enable)
   bank = get_gpio_bank(gpio);
   reg = bank-base;

+#ifdef CONFIG_ARCH_OMAP2PLUS
   if (cpu_is_omap44xx())
   reg += OMAP4_GPIO_DEBOUNCENABLE;
   else
   reg +=

Re: [PATCH 2/8] OMAP3:GPIO:Add support for early platform gpio device


On Wed, Mar 31, 2010 at 02:23:53PM +0200, ext Charulatha V wrote:

This patch adds support for implementing OMAP3 GPIO as an
early platform device and adds gpio_init specific to OMAP3

This patch adds device structures for each GPIO device in
OMAP3 architecture. These strutures are not created in a
separate *_data.c file because these structures would be
removed once the driver gets adapted to HWMOD way.

Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap2/gpio3xxx.c  |  351 +++
arch/arm/mach-omap2/include/mach/gpio.h |   13 +-
2 files changed, 363 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpio3xxx.c

diff --git a/arch/arm/mach-omap2/gpio3xxx.c b/arch/arm/mach-omap2/gpio3xxx.c
new file mode 100644
index 000..8f404e7
--- /dev/null
+++ b/arch/arm/mach-omap2/gpio3xxx.c
@@ -0,0 +1,351 @@
+/*
+ * gpio3xxx.c - OMAP3-specific gpio code
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * Author:
+ * Charulatha V ch...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include plat/gpio.h
+
+/*
+ * OMAP3 GPIO reg offsets
+ */
+static struct gpio_reg_offset omap3_gpio_reg = {
+   .data_in= OMAP24XX_GPIO_DATAIN,
+   .data_out   = OMAP24XX_GPIO_DATAOUT,
+   .data_out_set   = OMAP24XX_GPIO_SETDATAOUT,
+   .data_out_clear = OMAP24XX_GPIO_CLEARDATAOUT,
+   .dir_ctrl   = OMAP24XX_GPIO_OE,
+   .irq_status0= OMAP24XX_GPIO_IRQSTATUS1,
+   .irq_status1= OMAP24XX_GPIO_IRQSTATUS2,
+   .irq_mask   = OMAP24XX_GPIO_IRQENABLE1,
+   .irq_set= OMAP24XX_GPIO_SETIRQENABLE1,
+   .irq_clear  = OMAP24XX_GPIO_CLEARIRQENABLE1,
+   .irq_mask_bits  = 0x,
+   .irq_inv= 0,
+   .wkup_enable= OMAP24XX_GPIO_WAKE_EN,
+   .wkup_clear = OMAP24XX_GPIO_CLEARWKUENA,
+   .wkup_set   = OMAP24XX_GPIO_SETWKUENA,
+   .debounce_ena   = OMAP24XX_GPIO_DEBOUNCE_EN,
+   .debounce_val   = OMAP24XX_GPIO_DEBOUNCE_VAL,
+   .ctrl   = OMAP24XX_GPIO_CTRL,
+   .syscfg = OMAP24XX_GPIO_SYSCONFIG,
+   .leveldetect0   = OMAP24XX_GPIO_LEVELDETECT0,
+   .leveldetect1   = OMAP24XX_GPIO_LEVELDETECT1,
+   .rise_detect= OMAP24XX_GPIO_RISINGDETECT,
+   .fall_detect= OMAP24XX_GPIO_FALLINGDETECT,
+   .rev_reg= OMAP24XX_GPIO_REVISION,
+};
+
+/*
+ * OMAP3 GPIO1 interface data
+ */
+static struct __initdata resource omap3_gpio1_resources[] = {
+   {
+   .start  = OMAP34XX_GPIO1_BASE,
+   .end= OMAP34XX_GPIO1_BASE + OMAP3_GPIO_AS_LEN - 1,


OMAP34XX_GPIO1_BASE + SZ_4K - 1


+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = INT_34XX_GPIO_BANK1,
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
+static struct __initdata omap_gpio_platform_data omap3_gpio1_config = {
+   .ick_name = gpio1_ick,
+   .dbck_name = gpio1_dbck,


do not pass clock names. Update the clkdev entries clk*_data.c


+int __init omap3_early_init_gpio(struct platform_device ***pdev)


I don't see the point in passing ***pdev.


+int __init omap3_gpio_dev_reg(void)
+{
+   if (cpu_is_omap34xx()) {
+   platform_device_register(omap3_gpio1);
+   platform_device_register(omap3_gpio2);
+   platform_device_register(omap3_gpio3);
+   platform_device_register(omap3_gpio4);
+   platform_device_register(omap3_gpio5);
+   platform_device_register(omap3_gpio6);
+   }


platform_add_devices(omap3_gpio_early_dev,
ARRAY_SIZE(omap3_gpio_early_dev);

--
balbi
--
To unsubscribe from this list: send the line unsubscribe 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] OMAP2:GPIO:Add support for early platform gpio device


On Wed, Mar 31, 2010 at 02:23:54PM +0200, ext Charulatha V wrote:

+static inline struct gpio_bank *omap2_get_gpio_bank(int gpio,
+   struct gpio_bank *gpio_bank)
+{
+   if (cpu_is_omap24xx())
+   return gpio_bank[gpio  5];
+   BUG();


so if we build support omap 2420 and 3430 we will have a BUG() ??

--
balbi
--
To unsubscribe from this list: send the line unsubscribe 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] OMAP:GPIO:Move architecture specific macros to specific header



 -Original Message-
 From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
 Sent: Thursday, April 01, 2010 12:47 PM
 To: Varadarajan, Charulatha
 Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com; 
 t...@atomide.com
 Subject: Re: [PATCH 1/8] OMAP:GPIO:Move architecture specific macros to 
 specific
 header
 
 Hi,
 
 On Wed, Mar 31, 2010 at 02:23:52PM +0200, ext Charulatha V wrote:
 diff --git a/arch/arm/mach-omap1/include/mach/gpio.h b/arch/arm/mach-
 omap1/include/mach/gpio.h
 index e737706..c4945d7 100644
 --- a/arch/arm/mach-omap1/include/mach/gpio.h
 +++ b/arch/arm/mach-omap1/include/mach/gpio.h
 @@ -3,3 +3,91 @@
   */
 
  #include plat/gpio.h
 +
 +/*
 + * OMAP1510 GPIO registers
 + */
 +#define OMAP1510_GPIO_BASE 0xfffce000
 +#define OMAP1510_GPIO_DATA_INPUT   0x00
 +#define OMAP1510_GPIO_DATA_OUTPUT  0x04
 +#define OMAP1510_GPIO_DIR_CONTROL  0x08
 +#define OMAP1510_GPIO_INT_CONTROL  0x0c
 +#define OMAP1510_GPIO_INT_MASK 0x10
 +#define OMAP1510_GPIO_INT_STATUS   0x14
 +#define OMAP1510_GPIO_PIN_CONTROL  0x18
 +
 +#define OMAP1510_IH_GPIO_BASE  64
 +
 +/*
 + * OMAP1610 specific GPIO registers
 + */
 +#define OMAP1610_GPIO1_BASE0xfffbe400
 +#define OMAP1610_GPIO2_BASE0xfffbec00
 +#define OMAP1610_GPIO3_BASE0xfffbb400
 +#define OMAP1610_GPIO4_BASE0xfffbbc00
 +#define OMAP1610_GPIO_REVISION 0x
 +#define OMAP1610_GPIO_SYSCONFIG0x0010
 +#define OMAP1610_GPIO_SYSSTATUS0x0014
 +#define OMAP1610_GPIO_IRQSTATUS1   0x0018
 +#define OMAP1610_GPIO_IRQENABLE1   0x001c
 +#define OMAP1610_GPIO_WAKEUPENABLE 0x0028
 +#define OMAP1610_GPIO_DATAIN   0x002c
 +#define OMAP1610_GPIO_DATAOUT  0x0030
 +#define OMAP1610_GPIO_DIRECTION0x0034
 +#define OMAP1610_GPIO_EDGE_CTRL1   0x0038
 +#define OMAP1610_GPIO_EDGE_CTRL2   0x003c
 +#define OMAP1610_GPIO_CLEAR_IRQENABLE1 0x009c
 +#define OMAP1610_GPIO_CLEAR_WAKEUPENA  0x00a8
 +#define OMAP1610_GPIO_CLEAR_DATAOUT0x00b0
 +#define OMAP1610_GPIO_SET_IRQENABLE1   0x00dc
 +#define OMAP1610_GPIO_SET_WAKEUPENA0x00e8
 +#define OMAP1610_GPIO_SET_DATAOUT  0x00f0
 +
 +/*
 + * OMAP7XX specific GPIO registers
 + */
 +#define OMAP7XX_GPIO1_BASE 0xfffbc000
 +#define OMAP7XX_GPIO2_BASE 0xfffbc800
 +#define OMAP7XX_GPIO3_BASE 0xfffbd000
 +#define OMAP7XX_GPIO4_BASE 0xfffbd800
 +#define OMAP7XX_GPIO5_BASE 0xfffbe000
 +#define OMAP7XX_GPIO6_BASE 0xfffbe800
 +#define OMAP7XX_GPIO_DATA_INPUT0x00
 +#define OMAP7XX_GPIO_DATA_OUTPUT   0x04
 +#define OMAP7XX_GPIO_DIR_CONTROL   0x08
 +#define OMAP7XX_GPIO_INT_CONTROL   0x0c
 +#define OMAP7XX_GPIO_INT_MASK  0x10
 +#define OMAP7XX_GPIO_INT_STATUS0x14
 +
 +#define OMAP1_MPUIO_VBASE  OMAP1_MPUIO_BASE
 +#define OMAP1_MPUIO_BASE   0xfffb5000
 +
 +#if (defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850))
 +#define OMAP_MPUIO_INPUT_LATCH 0x00
 +#define OMAP_MPUIO_OUTPUT  0x02
 +#define OMAP_MPUIO_IO_CNTL 0x04
 +#define OMAP_MPUIO_KBR_LATCH   0x08
 +#define OMAP_MPUIO_KBC 0x0a
 +#define OMAP_MPUIO_GPIO_EVENT_MODE 0x0c
 +#define OMAP_MPUIO_GPIO_INT_EDGE   0x0e
 +#define OMAP_MPUIO_KBD_INT 0x10
 +#define OMAP_MPUIO_GPIO_INT0x12
 +#define OMAP_MPUIO_KBD_MASKIT  0x14
 +#define OMAP_MPUIO_GPIO_MASKIT 0x16
 +#define OMAP_MPUIO_GPIO_DEBOUNCING 0x18
 +#define OMAP_MPUIO_LATCH   0x1a
 +#else
 +#define OMAP_MPUIO_INPUT_LATCH 0x00
 +#define OMAP_MPUIO_OUTPUT  0x04
 +#define OMAP_MPUIO_IO_CNTL 0x08
 +#define OMAP_MPUIO_KBR_LATCH   0x10
 +#define OMAP_MPUIO_KBC 0x14
 +#define OMAP_MPUIO_GPIO_EVENT_MODE 0x18
 +#define OMAP_MPUIO_GPIO_INT_EDGE   0x1c
 +#define OMAP_MPUIO_KBD_INT 0x20
 +#define OMAP_MPUIO_GPIO_INT0x24
 +#define OMAP_MPUIO_KBD_MASKIT  0x28
 +#define OMAP_MPUIO_GPIO_MASKIT 0x2c
 +#define OMAP_MPUIO_GPIO_DEBOUNCING 0x30
 +#define OMAP_MPUIO_LATCH   0x34
 +#endif
 
 Add prefixes to these defines and remove the ifdefs.
 This breaks multi-omap builds.

AFAIK multi-omap build not applicable for OMAP1

 
 -struct gpio_bank {
 -   unsigned long pbase;
 -   void __iomem *base;
 -   u16 irq;
 -   u16 virtual_irq_start;
 -   int method;
 -#if defined(CONFIG_ARCH_OMAP16XX) || defined(CONFIG_ARCH_OMAP2PLUS)
 -   u32 suspend_wakeup;
 -   u32 saved_wakeup;
 -#endif
 -#ifdef CONFIG_ARCH_OMAP2PLUS
 -   u32 non_wakeup_gpios;
 -   u32 enabled_non_wakeup_gpios;
 -
 -   u32 saved_datain;
 -   u32 saved_fallingdetect;
 -   u32 saved_risingdetect;
 -#endif
 -   u32 level_mask;
 -   u32 toggle_mask;
 -   spinlock_t

RE: [PATCH 3/8] OMAP2:GPIO:Add support for early platform gpio device



 -Original Message-
 From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
 Sent: Thursday, April 01, 2010 12:56 PM
 To: Varadarajan, Charulatha
 Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com; 
 t...@atomide.com
 Subject: Re: [PATCH 3/8] OMAP2:GPIO:Add support for early platform gpio device
 
 On Wed, Mar 31, 2010 at 02:23:54PM +0200, ext Charulatha V wrote:
 +static inline struct gpio_bank *omap2_get_gpio_bank(int gpio,
 +   struct gpio_bank *gpio_bank)
 +{
 +   if (cpu_is_omap24xx())
 +   return gpio_bank[gpio  5];
 +   BUG();
 
 so if we build support omap 2420 and 3430 we will have a BUG() ??

Multi-OMAP build will not give a BUG(). If this function is called during 
non-3430 OMAP arch, it will have a BUG().

 
 --
 balbi
--
To unsubscribe from this list: send the line unsubscribe 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] OMAP2:GPIO:Add support for early platform gpio device



 -Original Message-
 From: Varadarajan, Charulatha
 Sent: Thursday, April 01, 2010 2:24 PM
 To: 'felipe.ba...@nokia.com'
 Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com; 
 t...@atomide.com
 Subject: RE: [PATCH 3/8] OMAP2:GPIO:Add support for early platform gpio device
 
 
 
  -Original Message-
  From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
  Sent: Thursday, April 01, 2010 12:56 PM
  To: Varadarajan, Charulatha
  Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com;
 t...@atomide.com
  Subject: Re: [PATCH 3/8] OMAP2:GPIO:Add support for early platform gpio 
  device
 
  On Wed, Mar 31, 2010 at 02:23:54PM +0200, ext Charulatha V wrote:
  +static inline struct gpio_bank *omap2_get_gpio_bank(int gpio,
  +   struct gpio_bank *gpio_bank)
  +{
  +   if (cpu_is_omap24xx())
  +   return gpio_bank[gpio  5];
  +   BUG();
 
  so if we build support omap 2420 and 3430 we will have a BUG() ??
 
 Multi-OMAP build will not give a BUG(). If this function is called during 
 non-3430
 OMAP arch, it will have a BUG().

A correction - it would give BUG() for non-24xx OMAP, if called.

 
 
  --
  balbi
--
To unsubscribe from this list: send the line unsubscribe 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] OMAP3:GPIO:Add support for early platform gpio device



 -Original Message-
 From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
 Sent: Thursday, April 01, 2010 12:53 PM
 To: Varadarajan, Charulatha
 Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com; 
 t...@atomide.com
 Subject: Re: [PATCH 2/8] OMAP3:GPIO:Add support for early platform gpio device
 
 On Wed, Mar 31, 2010 at 02:23:53PM +0200, ext Charulatha V wrote:
 This patch adds support for implementing OMAP3 GPIO as an
 early platform device and adds gpio_init specific to OMAP3
 
 This patch adds device structures for each GPIO device in
 OMAP3 architecture. These strutures are not created in a
 separate *_data.c file because these structures would be
 removed once the driver gets adapted to HWMOD way.
 
 Signed-off-by: Charulatha V ch...@ti.com
 ---
  arch/arm/mach-omap2/gpio3xxx.c  |  351 
  +++
  arch/arm/mach-omap2/include/mach/gpio.h |   13 +-
  2 files changed, 363 insertions(+), 1 deletions(-)
  create mode 100644 arch/arm/mach-omap2/gpio3xxx.c
 
 diff --git a/arch/arm/mach-omap2/gpio3xxx.c b/arch/arm/mach-omap2/gpio3xxx.c
 new file mode 100644
 index 000..8f404e7
 --- /dev/null
 +++ b/arch/arm/mach-omap2/gpio3xxx.c
 @@ -0,0 +1,351 @@
 +/*
 + * gpio3xxx.c - OMAP3-specific gpio code
 + *
 + * Copyright (C) 2010 Texas Instruments, Inc.
 + *
 + * Author:
 + *  Charulatha V ch...@ti.com
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#include plat/gpio.h
 +
 +/*
 + * OMAP3 GPIO reg offsets
 + */
 +static struct gpio_reg_offset omap3_gpio_reg = {
 +.data_in= OMAP24XX_GPIO_DATAIN,
 +.data_out   = OMAP24XX_GPIO_DATAOUT,
 +.data_out_set   = OMAP24XX_GPIO_SETDATAOUT,
 +.data_out_clear = OMAP24XX_GPIO_CLEARDATAOUT,
 +.dir_ctrl   = OMAP24XX_GPIO_OE,
 +.irq_status0= OMAP24XX_GPIO_IRQSTATUS1,
 +.irq_status1= OMAP24XX_GPIO_IRQSTATUS2,
 +.irq_mask   = OMAP24XX_GPIO_IRQENABLE1,
 +.irq_set= OMAP24XX_GPIO_SETIRQENABLE1,
 +.irq_clear  = OMAP24XX_GPIO_CLEARIRQENABLE1,
 +.irq_mask_bits  = 0x,
 +.irq_inv= 0,
 +.wkup_enable= OMAP24XX_GPIO_WAKE_EN,
 +.wkup_clear = OMAP24XX_GPIO_CLEARWKUENA,
 +.wkup_set   = OMAP24XX_GPIO_SETWKUENA,
 +.debounce_ena   = OMAP24XX_GPIO_DEBOUNCE_EN,
 +.debounce_val   = OMAP24XX_GPIO_DEBOUNCE_VAL,
 +.ctrl   = OMAP24XX_GPIO_CTRL,
 +.syscfg = OMAP24XX_GPIO_SYSCONFIG,
 +.leveldetect0   = OMAP24XX_GPIO_LEVELDETECT0,
 +.leveldetect1   = OMAP24XX_GPIO_LEVELDETECT1,
 +.rise_detect= OMAP24XX_GPIO_RISINGDETECT,
 +.fall_detect= OMAP24XX_GPIO_FALLINGDETECT,
 +.rev_reg= OMAP24XX_GPIO_REVISION,
 +};
 +
 +/*
 + * OMAP3 GPIO1 interface data
 + */
 +static struct __initdata resource omap3_gpio1_resources[] = {
 +{
 +.start  = OMAP34XX_GPIO1_BASE,
 +.end= OMAP34XX_GPIO1_BASE + OMAP3_GPIO_AS_LEN - 1,
 
 OMAP34XX_GPIO1_BASE + SZ_4K - 1
 
 +.flags  = IORESOURCE_MEM,
 +},
 +{
 +.start  = INT_34XX_GPIO_BANK1,
 +.flags  = IORESOURCE_IRQ,
 +},
 +};
 +
 +static struct __initdata omap_gpio_platform_data omap3_gpio1_config = {
 +.ick_name = gpio1_ick,
 +.dbck_name = gpio1_dbck,
 
 do not pass clock names. Update the clkdev entries clk*_data.c

Agreed. These patches are in preparation for HWMOD. Once GPIO driver gets
adapted to HWMOD, this would be removed.

 
 +int __init omap3_early_init_gpio(struct platform_device ***pdev)
 
 I don't see the point in passing ***pdev.

It is required to get the early init device structure which is SoC specific.

 
 +int __init omap3_gpio_dev_reg(void)
 +{
 +if (cpu_is_omap34xx()) {
 +platform_device_register(omap3_gpio1);
 +platform_device_register(omap3_gpio2);
 +platform_device_register(omap3_gpio3);
 +platform_device_register(omap3_gpio4);
 +platform_device_register(omap3_gpio5);
 +platform_device_register(omap3_gpio6);
 +}
 
 platform_add_devices(omap3_gpio_early_dev,
   ARRAY_SIZE(omap3_gpio_early_dev);
 
 --
 balbi
--
To unsubscribe from this list: send the line unsubscribe 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] OMAP2:GPIO:Add support for early platform gpio device


On Thu, Apr 01, 2010 at 10:53:48AM +0200, ext Varadarajan, Charulatha wrote:




-Original Message-
From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
Sent: Thursday, April 01, 2010 12:56 PM
To: Varadarajan, Charulatha
Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com; 
t...@atomide.com
Subject: Re: [PATCH 3/8] OMAP2:GPIO:Add support for early platform gpio device

On Wed, Mar 31, 2010 at 02:23:54PM +0200, ext Charulatha V wrote:
+static inline struct gpio_bank *omap2_get_gpio_bank(int gpio,
+   struct gpio_bank *gpio_bank)
+{
+   if (cpu_is_omap24xx())
+   return gpio_bank[gpio  5];
+   BUG();

so if we build support omap 2420 and 3430 we will have a BUG() ??


Multi-OMAP build will not give a BUG(). If this function is called 
during non-3430 OMAP arch, it will have a BUG().


still, you shouldn't sprinkle BUG() around the code this can cause some 
hard to find kernel oopses. Just return NULL.


--
balbi
--
To unsubscribe from this list: send the line unsubscribe 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] OMAP:GPIO:Move architecture specific macros to specific header


On Thu, Apr 01, 2010 at 10:52:42AM +0200, ext Varadarajan, Charulatha wrote:




-Original Message-
From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
Sent: Thursday, April 01, 2010 12:47 PM
To: Varadarajan, Charulatha
Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com; 
t...@atomide.com
Subject: Re: [PATCH 1/8] OMAP:GPIO:Move architecture specific macros to specific
header

Hi,

On Wed, Mar 31, 2010 at 02:23:52PM +0200, ext Charulatha V wrote:
diff --git a/arch/arm/mach-omap1/include/mach/gpio.h b/arch/arm/mach-
omap1/include/mach/gpio.h
index e737706..c4945d7 100644
--- a/arch/arm/mach-omap1/include/mach/gpio.h
+++ b/arch/arm/mach-omap1/include/mach/gpio.h
@@ -3,3 +3,91 @@
  */

 #include plat/gpio.h
+
+/*
+ * OMAP1510 GPIO registers
+ */
+#define OMAP1510_GPIO_BASE 0xfffce000
+#define OMAP1510_GPIO_DATA_INPUT   0x00
+#define OMAP1510_GPIO_DATA_OUTPUT  0x04
+#define OMAP1510_GPIO_DIR_CONTROL  0x08
+#define OMAP1510_GPIO_INT_CONTROL  0x0c
+#define OMAP1510_GPIO_INT_MASK 0x10
+#define OMAP1510_GPIO_INT_STATUS   0x14
+#define OMAP1510_GPIO_PIN_CONTROL  0x18
+
+#define OMAP1510_IH_GPIO_BASE  64
+
+/*
+ * OMAP1610 specific GPIO registers
+ */
+#define OMAP1610_GPIO1_BASE0xfffbe400
+#define OMAP1610_GPIO2_BASE0xfffbec00
+#define OMAP1610_GPIO3_BASE0xfffbb400
+#define OMAP1610_GPIO4_BASE0xfffbbc00
+#define OMAP1610_GPIO_REVISION 0x
+#define OMAP1610_GPIO_SYSCONFIG0x0010
+#define OMAP1610_GPIO_SYSSTATUS0x0014
+#define OMAP1610_GPIO_IRQSTATUS1   0x0018
+#define OMAP1610_GPIO_IRQENABLE1   0x001c
+#define OMAP1610_GPIO_WAKEUPENABLE 0x0028
+#define OMAP1610_GPIO_DATAIN   0x002c
+#define OMAP1610_GPIO_DATAOUT  0x0030
+#define OMAP1610_GPIO_DIRECTION0x0034
+#define OMAP1610_GPIO_EDGE_CTRL1   0x0038
+#define OMAP1610_GPIO_EDGE_CTRL2   0x003c
+#define OMAP1610_GPIO_CLEAR_IRQENABLE1 0x009c
+#define OMAP1610_GPIO_CLEAR_WAKEUPENA  0x00a8
+#define OMAP1610_GPIO_CLEAR_DATAOUT0x00b0
+#define OMAP1610_GPIO_SET_IRQENABLE1   0x00dc
+#define OMAP1610_GPIO_SET_WAKEUPENA0x00e8
+#define OMAP1610_GPIO_SET_DATAOUT  0x00f0
+
+/*
+ * OMAP7XX specific GPIO registers
+ */
+#define OMAP7XX_GPIO1_BASE 0xfffbc000
+#define OMAP7XX_GPIO2_BASE 0xfffbc800
+#define OMAP7XX_GPIO3_BASE 0xfffbd000
+#define OMAP7XX_GPIO4_BASE 0xfffbd800
+#define OMAP7XX_GPIO5_BASE 0xfffbe000
+#define OMAP7XX_GPIO6_BASE 0xfffbe800
+#define OMAP7XX_GPIO_DATA_INPUT0x00
+#define OMAP7XX_GPIO_DATA_OUTPUT   0x04
+#define OMAP7XX_GPIO_DIR_CONTROL   0x08
+#define OMAP7XX_GPIO_INT_CONTROL   0x0c
+#define OMAP7XX_GPIO_INT_MASK  0x10
+#define OMAP7XX_GPIO_INT_STATUS0x14
+
+#define OMAP1_MPUIO_VBASE  OMAP1_MPUIO_BASE
+#define OMAP1_MPUIO_BASE   0xfffb5000
+
+#if (defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850))
+#define OMAP_MPUIO_INPUT_LATCH 0x00
+#define OMAP_MPUIO_OUTPUT  0x02
+#define OMAP_MPUIO_IO_CNTL 0x04
+#define OMAP_MPUIO_KBR_LATCH   0x08
+#define OMAP_MPUIO_KBC 0x0a
+#define OMAP_MPUIO_GPIO_EVENT_MODE 0x0c
+#define OMAP_MPUIO_GPIO_INT_EDGE   0x0e
+#define OMAP_MPUIO_KBD_INT 0x10
+#define OMAP_MPUIO_GPIO_INT0x12
+#define OMAP_MPUIO_KBD_MASKIT  0x14
+#define OMAP_MPUIO_GPIO_MASKIT 0x16
+#define OMAP_MPUIO_GPIO_DEBOUNCING 0x18
+#define OMAP_MPUIO_LATCH   0x1a
+#else
+#define OMAP_MPUIO_INPUT_LATCH 0x00
+#define OMAP_MPUIO_OUTPUT  0x04
+#define OMAP_MPUIO_IO_CNTL 0x08
+#define OMAP_MPUIO_KBR_LATCH   0x10
+#define OMAP_MPUIO_KBC 0x14
+#define OMAP_MPUIO_GPIO_EVENT_MODE 0x18
+#define OMAP_MPUIO_GPIO_INT_EDGE   0x1c
+#define OMAP_MPUIO_KBD_INT 0x20
+#define OMAP_MPUIO_GPIO_INT0x24
+#define OMAP_MPUIO_KBD_MASKIT  0x28
+#define OMAP_MPUIO_GPIO_MASKIT 0x2c
+#define OMAP_MPUIO_GPIO_DEBOUNCING 0x30
+#define OMAP_MPUIO_LATCH   0x34
+#endif

Add prefixes to these defines and remove the ifdefs.
This breaks multi-omap builds.


AFAIK multi-omap build not applicable for OMAP1


yes, and we should try to fix that.


-struct gpio_bank {
-   unsigned long pbase;
-   void __iomem *base;
-   u16 irq;
-   u16 virtual_irq_start;
-   int method;
-#if defined(CONFIG_ARCH_OMAP16XX) || defined(CONFIG_ARCH_OMAP2PLUS)
-   u32 suspend_wakeup;
-   u32 saved_wakeup;
-#endif
-#ifdef CONFIG_ARCH_OMAP2PLUS
-   u32 non_wakeup_gpios;
-   u32 enabled_non_wakeup_gpios;
-
-   u32 saved_datain;
-   u32 saved_fallingdetect;
-   u32 saved_risingdetect;
-#endif
-   u32 level_mask;
-   u32 toggle_mask;
-   spinlock_t lock;
-

Re: [PATCH 2/8] OMAP3:GPIO:Add support for early platform gpio device

* Varadarajan, Charulatha ch...@ti.com [100401 01:54]:
 
 
  -Original Message-
  From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
  Sent: Thursday, April 01, 2010 12:53 PM
  To: Varadarajan, Charulatha
  Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com; 
  t...@atomide.com
  Subject: Re: [PATCH 2/8] OMAP3:GPIO:Add support for early platform gpio 
  device
  
  On Wed, Mar 31, 2010 at 02:23:53PM +0200, ext Charulatha V wrote:
  This patch adds support for implementing OMAP3 GPIO as an
  early platform device and adds gpio_init specific to OMAP3
  
  This patch adds device structures for each GPIO device in
  OMAP3 architecture. These strutures are not created in a
  separate *_data.c file because these structures would be
  removed once the driver gets adapted to HWMOD way.
  
  Signed-off-by: Charulatha V ch...@ti.com
  ---
   arch/arm/mach-omap2/gpio3xxx.c  |  351 
   +++
   arch/arm/mach-omap2/include/mach/gpio.h |   13 +-
   2 files changed, 363 insertions(+), 1 deletions(-)
   create mode 100644 arch/arm/mach-omap2/gpio3xxx.c
  
  --- /dev/null
  +++ b/arch/arm/mach-omap2/gpio3xxx.c
  +
  +static struct __initdata omap_gpio_platform_data omap3_gpio1_config = {
  +  .ick_name = gpio1_ick,
  +  .dbck_name = gpio1_dbck,
  
  do not pass clock names. Update the clkdev entries clk*_data.c
 
 Agreed. These patches are in preparation for HWMOD. Once GPIO driver gets
 adapted to HWMOD, this would be removed.

Still need to change it before hwmod. No passing of clock names has been
needed for quite a while now.

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/8] OMAP3:GPIO:Add support for early platform gpio device

* Charulatha V ch...@ti.com [100331 05:15]:
 This patch adds support for implementing OMAP3 GPIO as an
 early platform device and adds gpio_init specific to OMAP3
 
 This patch adds device structures for each GPIO device in
 OMAP3 architecture. These strutures are not created in a
 separate *_data.c file because these structures would be
 removed once the driver gets adapted to HWMOD way.
 
 Signed-off-by: Charulatha V ch...@ti.com
 ---
  arch/arm/mach-omap2/gpio3xxx.c  |  351 
 +++
  arch/arm/mach-omap2/include/mach/gpio.h |   13 +-
  2 files changed, 363 insertions(+), 1 deletions(-)
  create mode 100644 arch/arm/mach-omap2/gpio3xxx.c
 
 diff --git a/arch/arm/mach-omap2/gpio3xxx.c b/arch/arm/mach-omap2/gpio3xxx.c
 new file mode 100644
 index 000..8f404e7
 --- /dev/null
 +++ b/arch/arm/mach-omap2/gpio3xxx.c
 @@ -0,0 +1,351 @@
 +/*
 + * gpio3xxx.c - OMAP3-specific gpio code
 + *
 + * Copyright (C) 2010 Texas Instruments, Inc.
 + *
 + * Author:
 + *   Charulatha V ch...@ti.com
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#include plat/gpio.h
 +
 +/*
 + * OMAP3 GPIO reg offsets
 + */
 +static struct gpio_reg_offset omap3_gpio_reg = {
 + .data_in= OMAP24XX_GPIO_DATAIN,
 + .data_out   = OMAP24XX_GPIO_DATAOUT,
 + .data_out_set   = OMAP24XX_GPIO_SETDATAOUT,
 + .data_out_clear = OMAP24XX_GPIO_CLEARDATAOUT,
 + .dir_ctrl   = OMAP24XX_GPIO_OE,
 + .irq_status0= OMAP24XX_GPIO_IRQSTATUS1,
 + .irq_status1= OMAP24XX_GPIO_IRQSTATUS2,
 + .irq_mask   = OMAP24XX_GPIO_IRQENABLE1,
 + .irq_set= OMAP24XX_GPIO_SETIRQENABLE1,
 + .irq_clear  = OMAP24XX_GPIO_CLEARIRQENABLE1,
 + .irq_mask_bits  = 0x,
 + .irq_inv= 0,
 + .wkup_enable= OMAP24XX_GPIO_WAKE_EN,
 + .wkup_clear = OMAP24XX_GPIO_CLEARWKUENA,
 + .wkup_set   = OMAP24XX_GPIO_SETWKUENA,
 + .debounce_ena   = OMAP24XX_GPIO_DEBOUNCE_EN,
 + .debounce_val   = OMAP24XX_GPIO_DEBOUNCE_VAL,
 + .ctrl   = OMAP24XX_GPIO_CTRL,
 + .syscfg = OMAP24XX_GPIO_SYSCONFIG,
 + .leveldetect0   = OMAP24XX_GPIO_LEVELDETECT0,
 + .leveldetect1   = OMAP24XX_GPIO_LEVELDETECT1,
 + .rise_detect= OMAP24XX_GPIO_RISINGDETECT,
 + .fall_detect= OMAP24XX_GPIO_FALLINGDETECT,
 + .rev_reg= OMAP24XX_GPIO_REVISION,
 +};

Can we use just a omap specific shift here? Or is the register
ordering different too?

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: [PATCHV3 0/2] MPU/IVA bypass clock configuration

2010-04-01 Thread Paul Walmsley

Hi Vishwanath,

On Thu, 1 Apr 2010, Vishwanath BS wrote:

 DSP usage at VDD1 OPP1 and OPP2 with Smartreflex enabled and any MM
 UCs running DSP codec was earlier restricted as DSP crashed.
 The root cause is wrong DPLL1/DPLL2 Bypass clock at VDD1 OPP1 and OPP2.
 The solution is to make sure DPLL1/DPLL2 bypass clock is always less
 than maximum supported frequency for the specific OPP.
 Typically these settings are to be done in bootloaders.
 
 All the patches have been tested on OMAP3630 ZOOM3  platform.
 Comments adressed in V3:
 1. Used clk_set_rate API instead of directly writing to registers
 2. Split the patch into 2 patches.
 
 Vishwanath BS (4):
   OMAP3: Set MPU and IVA bypass Clock Divider
   OMAP3 PM: Set MPU and IVA bypass clock dividers in DVFS

On what tree do these patches apply?


- 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/8] OMAP2:GPIO:Add support for early platform gpio device



 -Original Message-
 From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
 Sent: Thursday, April 01, 2010 2:29 PM
 To: Varadarajan, Charulatha
 Cc: Balbi Felipe (Nokia-D/Helsinki); linux-omap@vger.kernel.org; Nayak, 
 Rajendra;
 p...@pwsan.com; t...@atomide.com
 Subject: Re: [PATCH 3/8] OMAP2:GPIO:Add support for early platform gpio device
 
 On Thu, Apr 01, 2010 at 10:53:48AM +0200, ext Varadarajan, Charulatha wrote:
 
 
  -Original Message-
  From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
  Sent: Thursday, April 01, 2010 12:56 PM
  To: Varadarajan, Charulatha
  Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com;
 t...@atomide.com
  Subject: Re: [PATCH 3/8] OMAP2:GPIO:Add support for early platform gpio 
  device
 
  On Wed, Mar 31, 2010 at 02:23:54PM +0200, ext Charulatha V wrote:
  +static inline struct gpio_bank *omap2_get_gpio_bank(int gpio,
  +   struct gpio_bank *gpio_bank)
  +{
  +   if (cpu_is_omap24xx())
  +   return gpio_bank[gpio  5];
  +   BUG();
 
  so if we build support omap 2420 and 3430 we will have a BUG() ??
 
 Multi-OMAP build will not give a BUG(). If this function is called
 during non-3430 OMAP arch, it will have a BUG().
 
 still, you shouldn't sprinkle BUG() around the code this can cause some
 hard to find kernel oopses. Just return NULL.

Okay.

 
 --
 balbi
--
To unsubscribe from this list: send the line unsubscribe 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] OMAP3:GPIO:Add support for early platform gpio device



 -Original Message-
 From: Tony Lindgren [mailto:t...@atomide.com]
 Sent: Thursday, April 01, 2010 2:42 PM
 To: Varadarajan, Charulatha
 Cc: felipe.ba...@nokia.com; linux-omap@vger.kernel.org; Nayak, Rajendra;
 p...@pwsan.com
 Subject: Re: [PATCH 2/8] OMAP3:GPIO:Add support for early platform gpio device
 
 * Varadarajan, Charulatha ch...@ti.com [100401 01:54]:
 
 
   -Original Message-
   From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
   Sent: Thursday, April 01, 2010 12:53 PM
   To: Varadarajan, Charulatha
   Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com;
 t...@atomide.com
   Subject: Re: [PATCH 2/8] OMAP3:GPIO:Add support for early platform gpio 
   device
  
   On Wed, Mar 31, 2010 at 02:23:53PM +0200, ext Charulatha V wrote:
   This patch adds support for implementing OMAP3 GPIO as an
   early platform device and adds gpio_init specific to OMAP3
   
   This patch adds device structures for each GPIO device in
   OMAP3 architecture. These strutures are not created in a
   separate *_data.c file because these structures would be
   removed once the driver gets adapted to HWMOD way.
   
   Signed-off-by: Charulatha V ch...@ti.com
   ---
arch/arm/mach-omap2/gpio3xxx.c  |  351
 +++
arch/arm/mach-omap2/include/mach/gpio.h |   13 +-
2 files changed, 363 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpio3xxx.c
   
   --- /dev/null
   +++ b/arch/arm/mach-omap2/gpio3xxx.c
   +
   +static struct __initdata omap_gpio_platform_data omap3_gpio1_config = {
   +.ick_name = gpio1_ick,
   +.dbck_name = gpio1_dbck,
  
   do not pass clock names. Update the clkdev entries clk*_data.c
 
  Agreed. These patches are in preparation for HWMOD. Once GPIO driver gets
  adapted to HWMOD, this would be removed.
 
 Still need to change it before hwmod. No passing of clock names has been
 needed for quite a while now.
 

Okay.

 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: [PATCHV3 1/2] OMAP3: Set MPU and IVA bypass Clock Divider

2010-04-01 Thread Paul Walmsley

On Thu, 1 Apr 2010, Vishwanath BS wrote:

 DSP usage at VDD1 OPP1 and OPP2 with Smartreflex enabled and any MM
 UCs running DSP codec was earlier restricted as DSP crashed.
 The root cause is wrong DPLL1/DPLL2 Bypass clock at VDD1 OPP1 and OPP2.
 The solution is to make sure DPLL1/DPLL2 bypass clock is always less
 than maximum supported frequency for the specific OPP.
 
 Signed-off-by: Vishwanath BS vishwanath...@ti.com
 ---
  arch/arm/mach-omap2/clock3xxx_data.c |   12 
  1 files changed, 12 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/clock3xxx_data.c 
 b/arch/arm/mach-omap2/clock3xxx_data.c
 index d5153b6..d8e57a6
 --- a/arch/arm/mach-omap2/clock3xxx_data.c
 +++ b/arch/arm/mach-omap2/clock3xxx_data.c

...

 @@ -3597,5 +3601,13 @@ int __init omap3xxx_clk_init(void)
   sdrc_ick_p = clk_get(NULL, sdrc_ick);
   arm_fck_p = clk_get(NULL, arm_fck);
  
 + /* Set the bypass clock dividers for DPLL1 and DPLL2 */
 + if (cpu_is_omap3630()) {
 + clk_set_rate(dpll1_fck, 4/2);
 + clk_set_rate(dpll2_fck, 4/2);
 + } else {
 + clk_set_rate(dpll1_fck, 33200/4);
 + clk_set_rate(dpll2_fck, 33200/4);
 + }

This code is highly OPP-specific.  Why is this code needed here?  
Shouldn't the code in resource34xx.c be sufficient?


- 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: [PATCHV3 0/2] MPU/IVA bypass clock configuration

2010-04-01 Thread Sripathy, Vishwanath

 -Original Message-
 From: Paul Walmsley [mailto:p...@pwsan.com]
 Sent: Thursday, April 01, 2010 2:46 PM
 To: Sripathy, Vishwanath
 Cc: linux-omap@vger.kernel.org
 Subject: Re: [PATCHV3 0/2] MPU/IVA bypass clock configuration

 Hi Vishwanath,

 On Thu, 1 Apr 2010, Vishwanath BS wrote:

  DSP usage at VDD1 OPP1 and OPP2 with Smartreflex enabled and any MM
  UCs running DSP codec was earlier restricted as DSP crashed.
  The root cause is wrong DPLL1/DPLL2 Bypass clock at VDD1 OPP1 and OPP2.
  The solution is to make sure DPLL1/DPLL2 bypass clock is always less
  than maximum supported frequency for the specific OPP.
  Typically these settings are to be done in bootloaders.

  All the patches have been tested on OMAP3630 ZOOM3  platform.
  Comments adressed in V3:
  1. Used clk_set_rate API instead of directly writing to registers
  2. Split the patch into 2 patches.

  Vishwanath BS (4):
  OMAP3: Set MPU and IVA bypass Clock Divider
  OMAP3 PM: Set MPU and IVA bypass clock dividers in DVFS

 On what tree do these patches apply?
I have applied them on top of wip_opp branch in Kevin's PM branch.
Regards
Vishwa

 - 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] OMAP2PLUS:GPIO:Add OMAP2PLUS specific gpio support

* Charulatha V ch...@ti.com [100331 05:15]:
 --- /dev/null
 +++ b/arch/arm/mach-omap2/gpio.c
 @@ -0,0 +1,36 @@
 +/*
 + * gpio.c - OMAP2PLUS architecture specific common gpio code
 + *
 + * Copyright (C) 2010 Texas Instruments, Inc.
 + *
 + * Author:
 + *   Charulatha V ch...@ti.com
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#include mach/gpio.h

Should be include linux/gpio.h

 +void __init omap_gpio_early_init(void)
 +{
 + struct platform_device **pdev;
 + int no_of_dev;
 +
 + if (cpu_is_omap24xx()) {
 + omap2_gpio_init_data();
 + no_of_dev = omap2_early_init_gpio(pdev);
 + } else if (cpu_is_omap34xx()) {
 + omap3_gpio_init_data();
 + no_of_dev = omap3_early_init_gpio(pdev);
 + } else if (cpu_is_omap44xx()) {
 + omap4_gpio_init_data();
 + no_of_dev = omap4_early_init_gpio(pdev);
 + } else
 + return;
 +
 + early_platform_add_devices(pdev, no_of_dev);
 + early_platform_driver_register_all(earlygpio);
 + early_platform_driver_probe(earlygpio, no_of_dev, 0);
 +}
 diff --git a/arch/arm/mach-omap2/include/mach/gpio.h 
 b/arch/arm/mach-omap2/include/mach/gpio.h
 index d2d9d17..3a0fcb1 100644
 --- a/arch/arm/mach-omap2/include/mach/gpio.h
 +++ b/arch/arm/mach-omap2/include/mach/gpio.h
 @@ -115,4 +115,5 @@ extern void omap4_gpio_init_data(void);
  extern int omap2_early_init_gpio(struct platform_device ***pdev);
  extern int omap3_early_init_gpio(struct platform_device ***pdev);
  extern int omap4_early_init_gpio(struct platform_device ***pdev);
 +extern void __init omap_gpio_early_init(void);
  #endif

Uhh, is this some April fool's day joke? :)

To me it looks like you have no need for ***pdev, just swap the init
code around so the omap specific code calls omap_gpio_init with the
platform data.

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 2/8] OMAP3:GPIO:Add support for early platform gpio device

* Charulatha V ch...@ti.com [100331 05:15]:
 +
 +int __init omap3_early_init_gpio(struct platform_device ***pdev)
 +{
 + *pdev = omap3_gpio_early_dev;
 + return OMAP34XX_NR_GPIOS;
 +}

...

 +int __init omap3_gpio_dev_reg(void)
 +{
 + if (cpu_is_omap34xx()) {
 + platform_device_register(omap3_gpio1);
 + platform_device_register(omap3_gpio2);
 + platform_device_register(omap3_gpio3);
 + platform_device_register(omap3_gpio4);
 + platform_device_register(omap3_gpio5);
 + platform_device_register(omap3_gpio6);
 + }
 + return 0;
 +}
 +arch_initcall(omap3_gpio_dev_reg);

Just call omap_gpio_init for each platform data.

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 7/8] OMAP2PLUS:GPIO:Move gpio_init from board files to init_common_hw

* Charulatha V ch...@ti.com [100331 05:15]:
 This is preparation for early platform device implementation
 for GPIO in OMAP2PLUS. This patch moves initialization of gpio
 from board files to omap2_init_common_hw API in io.c
 
 Init_irq needs to be done before gpio_init, the init_irq
 is called before omap2_init_common_hw in board files

Nope. We want to call omap2_init_common_hw as early as
possible, otherwise the cpu detection won't work.

What omaps have you tested this series on?

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 8/8] OMAP:GPIO:Common platform code for all OMAPs

* Charulatha V ch...@ti.com [100331 05:15]:
 This patch adds support for common GPIO code in plat-omap layer
 to perform most common operations for all OMAPs. This is handled
 by getting function pointers and register offsets from
 architecture specific files in mach-omap layer.
 
 The common APIs are handled by plat-omap/gpio.c file. Specific function,
 eg., get_gpio_bank, set_gpio_triggering, etc., are handled differently
 in different architectures. Hence they are handled in mach-omap layer.
 
 This patch also adds support for passing platform_data for OMAP2PLUS.
 For OMAP1, it still supports the old way of doing omap_gpio_init which
 would be handled in mach-omap1 layer.
 
 This patch is in prepartion for HWMOD FW adaptation for GPIO module.

Sounds like this needs to be broken down into smaller patches. Let's first
get initializing things with platform data working, only then start patching
the functional code.

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: [RFC/PATCHv2 2/4] arm: omap: gpio: implement set_debounce method


On Thu, Apr 01, 2010 at 11:29:16AM +0200, ext Grazvydas Ignotas wrote:

Hmh, dbck is shared by the whole GPIO bank, so what happens if someone
calls _set_gpio_debounce(bank, 1, 310) and then
_set_gpio_debounce(bank, 2, 0)? This should leave debounce enabled for
GPIO1, but you'll disable dbck on second call. GPIOs 0-31 share the
same bank.


but why would you call _set_gpio_debounce(bank, 2 0); without setting a 
real debounce value before ?



There is also an issue if somebody calls _set_gpio_debounce(bank, 1,
310) and _set_gpio_debounce(bank, 2, 620), the second call will
override debounce setting of GPIO1 (as it's shared by the whole bank).
This might be not what the user intended, would be useful to detect
this and warn the user.


good point. As this is RFC, I'll wait until everybody comments.

--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCHv2 2/4] arm: omap: gpio: implement set_debounce method

2010-04-01 Thread Grazvydas Ignotas

On Thu, Apr 1, 2010 at 12:32 PM, Felipe Balbi felipe.ba...@nokia.com wrote:
 On Thu, Apr 01, 2010 at 11:29:16AM +0200, ext Grazvydas Ignotas wrote:

 Hmh, dbck is shared by the whole GPIO bank, so what happens if someone
 calls _set_gpio_debounce(bank, 1, 310) and then
 _set_gpio_debounce(bank, 2, 0)? This should leave debounce enabled for
 GPIO1, but you'll disable dbck on second call. GPIOs 0-31 share the
 same bank.

 but why would you call _set_gpio_debounce(bank, 2 0); without setting a real
 debounce value before ?

ok then you could call
  _set_gpio_debounce(bank, 1, 310);
  _set_gpio_debounce(bank, 2, 310);
  _set_gpio_debounce(bank, 2, 0);

The problem here is that debounce is still active for GPIO1, but you
disable dbck for the whole bank.


 There is also an issue if somebody calls _set_gpio_debounce(bank, 1,
 310) and _set_gpio_debounce(bank, 2, 620), the second call will
 override debounce setting of GPIO1 (as it's shared by the whole bank).
 This might be not what the user intended, would be useful to detect
 this and warn the user.

 good point. As this is RFC, I'll wait until everybody comments.

 --
 balbi

--
To unsubscribe from this list: send the line unsubscribe 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] OMAP:GPIO:Move architecture specific macros to specific header

* Varadarajan, Charulatha ch...@ti.com [100401 01:48]:
  
  Add prefixes to these defines and remove the ifdefs.
  This breaks multi-omap builds.
 
 AFAIK multi-omap build not applicable for OMAP1

Wrong. Multi-omap for omap1 has been mostly working for
about 5 years. In general, we don't want to apply patches
that obviously break things like that.

If you take a look at arch/arm/mach-omap1/Kconfig, there's
no choice there between omap1 socs.
 
  
  -struct gpio_bank {
  -   unsigned long pbase;
  -   void __iomem *base;
  -   u16 irq;
  -   u16 virtual_irq_start;
  -   int method;
  -#if defined(CONFIG_ARCH_OMAP16XX) || defined(CONFIG_ARCH_OMAP2PLUS)
  -   u32 suspend_wakeup;
  -   u32 saved_wakeup;
  -#endif
  -#ifdef CONFIG_ARCH_OMAP2PLUS
  -   u32 non_wakeup_gpios;
  -   u32 enabled_non_wakeup_gpios;
  -
  -   u32 saved_datain;
  -   u32 saved_fallingdetect;
  -   u32 saved_risingdetect;
  -#endif
  -   u32 level_mask;
  -   u32 toggle_mask;
  -   spinlock_t lock;
  -   struct gpio_chip chip;
  -   struct clk *dbck;
  -   u32 mod_usage;
  -};
  
  defines are fine, but this structure belongs to this driver. Nobody else
  should need to poke on it. Keep it here.
 
 This would get used in mach-omap layers in the later patches.
 Hence moving it to gpio.h

Why would the hwmod code need to know about the register layout?
That's totally gpio specific.
 
  @@ -625,10 +421,12 @@ void omap_set_gpio_debounce(int gpio, int enable)
  bank = get_gpio_bank(gpio);
  reg = bank-base;
  
  +#ifdef CONFIG_ARCH_OMAP2PLUS
  if (cpu_is_omap44xx())
  reg += OMAP4_GPIO_DEBOUNCENABLE;
  else
  reg += OMAP24XX_GPIO_DEBOUNCE_EN;
  +#endif
  
  you should try to remove ifdefs not add more.
 
 As mentioned in the beginning of this patch, these are
 only temporary and all possible #ifdefs are removed at
 the end of this patch series when plat-omap/gpio.c handles
 only common APIs.

You need to first implement just initializing things using the
platform data. Only then start messing with the functions.

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: [RFC] Initial attempt to make ARM use LMB

* Jeremy Kerr jeremy.k...@canonical.com [100330 23:39]:
 Hi Russell,
 
  LMB... logical memory blocks.
 
 Nice, will be good for the DT work too.

Great, very nice clean up!

Acked-by: Tony Lindgren t...@atomide.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] OMAP3: mailbox initialization for all omap versions

* Hiroshi DOYU hiroshi.d...@nokia.com [100329 02:05]:
 From: Balbi Felipe (Nokia-D/Helsinki) felipe.ba...@nokia.com
 Subject: Re: [PATCH] OMAP3: mailbox initialization for all omap versions
 Date: Mon, 29 Mar 2010 09:01:45 +0200

  in that case, wouldn't it be better to split that into 
  arch/arm/omap1/mbox.c arch/arm/omap2/mbox24xx.c 
  arch/arm/omap2/mbox34xx.c arch/arm/omap2/mbox44xx.c ??

  that way we don't need ifdefs on the code and we will only compile what 
  we really need.

 This is feasible.
 But I'm not so sure whether adding 4 new files with around only 10
 lines code is acceptable or not.

 Tony, any comment on the above?

 Basically there could be the case we need all resources if we want to
 support omap1, 2, 3 and 4 at the same time, and the appropriate one
 will be chosen at run time by CPUID. I'm not sure how mature omap
 multi arch support is practically, but it's better to keep it as much
 as possbile.

I like Felipe's suggestion of adding devices2420.c, devices34xx.c,
devices44xx.c or similar. Then do the device init from those with
a arch_initcall that returns immediately if not running on the right
soc.

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

[RESEND: PATCH-V6 0/2] OMAP2/3: Add V4L2 display driver support

2010-04-01 Thread hvaibhav

From: Vaibhav Hiremath hvaib...@ti.com

The previous patch submission had a dependancy on ti-media directory patch,
and since we were not having any conclusion on that patch, I have created
omap directory (device specific name) and moved V4L2 driver
(as of now applicable to OMAP2/3 devices) to this new
directory so that atleast v4l2 display driver can be unblocked and get
merged to main-line.

Vaibhav Hiremath (2):
  OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2
  OMAP2/3: Add V4L2 DSS driver support in device.c

 arch/arm/mach-omap2/devices.c   |   28 +
 drivers/media/video/Kconfig |2 +
 drivers/media/video/Makefile|2 +
 drivers/media/video/omap/Kconfig|   11 +
 drivers/media/video/omap/Makefile   |7 +
 drivers/media/video/omap/omap_vout.c| 2655 +++
 drivers/media/video/omap/omap_voutdef.h |  148 ++
 drivers/media/video/omap/omap_voutlib.c |  258 +++
 drivers/media/video/omap/omap_voutlib.h |   34 +
 9 files changed, 3145 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/omap/Kconfig
 create mode 100644 drivers/media/video/omap/Makefile
 create mode 100644 drivers/media/video/omap/omap_vout.c
 create mode 100644 drivers/media/video/omap/omap_voutdef.h
 create mode 100644 drivers/media/video/omap/omap_voutlib.c
 create mode 100644 drivers/media/video/omap/omap_voutlib.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 2/2] OMAP2/3: Add V4L2 DSS driver support in device.c

2010-04-01 Thread hvaibhav

From: Vaibhav Hiremath hvaib...@ti.com


Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
 arch/arm/mach-omap2/devices.c |   28 
 1 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 18ad931..7aaffe7 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -763,6 +763,33 @@ static inline void omap_hdq_init(void)
 static inline void omap_hdq_init(void) {}
 #endif
 
+/*---*/
+
+#if defined(CONFIG_VIDEO_OMAP2_VOUT) || \
+   defined(CONFIG_VIDEO_OMAP2_VOUT_MODULE)
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
+static struct resource omap_vout_resource[3 - CONFIG_FB_OMAP2_NUM_FBS] = {
+};
+#else
+static struct resource omap_vout_resource[2] = {
+};
+#endif
+
+static struct platform_device omap_vout_device = {
+   .name   = omap_vout,
+   .num_resources  = ARRAY_SIZE(omap_vout_resource),
+   .resource   = omap_vout_resource[0],
+   .id = -1,
+};
+static void omap_init_vout(void)
+{
+   if (platform_device_register(omap_vout_device)  0)
+   printk(KERN_ERR Unable to register OMAP-VOUT device\n);
+}
+#else
+static inline void omap_init_vout(void) {}
+#endif
+
 /*-*/
 
 static int __init omap2_init_devices(void)
@@ -777,6 +804,7 @@ static int __init omap2_init_devices(void)
omap_hdq_init();
omap_init_sti();
omap_init_sha1_md5();
+   omap_init_vout();
 
return 0;
 }
-- 
1.6.2.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCHv2 2/4] arm: omap: gpio: implement set_debounce method


On Thu, Apr 01, 2010 at 11:37:16AM +0200, ext Grazvydas Ignotas wrote:

On Thu, Apr 1, 2010 at 12:32 PM, Felipe Balbi felipe.ba...@nokia.com wrote:

On Thu, Apr 01, 2010 at 11:29:16AM +0200, ext Grazvydas Ignotas wrote:


Hmh, dbck is shared by the whole GPIO bank, so what happens if someone
calls _set_gpio_debounce(bank, 1, 310) and then
_set_gpio_debounce(bank, 2, 0)? This should leave debounce enabled for
GPIO1, but you'll disable dbck on second call. GPIOs 0-31 share the
same bank.


but why would you call _set_gpio_debounce(bank, 2 0); without setting a real
debounce value before ?


ok then you could call
 _set_gpio_debounce(bank, 1, 310);
 _set_gpio_debounce(bank, 2, 310);
 _set_gpio_debounce(bank, 2, 0);

The problem here is that debounce is still active for GPIO1, but you
disable dbck for the whole bank.


but then you enabled the clock twice. There's refcounting for the clock.

--
balbi
--
To unsubscribe from this list: send the line unsubscribe 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: Where did the twl4030 battery charging code go?

* Peter Barada peter.bar...@gmail.com [100330 08:55]:
 I'm looking in linux-2.6.33-rc3 to turn on the battery backup charger
 to get the RTC working on a Logic SOM, and I don't see
 drivers/mfd/twl4030_bci_battery.c anymore.
 
 Digging through Tony's trees I find it was removed way back at::
 
 http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff;h=b122a4b8a18ebbb0b5de90baeb54650a53cd9d7d
 
 Did this code resurface anywhere in the new kernels?

If it's not in mainline, we don't have it queued anywhere else.
The missing pieces should be sent via the MFD list after the
necessary cleanups.

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] OMAP3EVM: Made backlight GPIO default state to off

* Hiremath, Vaibhav hvaib...@ti.com [100330 01:07]:
 
  -Original Message-
  From: Hiremath, Vaibhav
  Sent: Monday, March 22, 2010 6:41 PM
  To: linux-omap@vger.kernel.org
  Cc: tomi.valkei...@nokia.com; t...@atomide.com; Hiremath, Vaibhav
  Subject: [PATCH 1/2] OMAP3EVM: Made backlight GPIO default state to off
  
  From: Vaibhav Hiremath hvaib...@ti.com
  
  If you choose default output to DVI, the LCD backlight still
  gets powered, since panel-disable function never gets called for LCD.
  
  So, during init put backlight GPIO to off state and the driverr
  code will decide which output to enable explicitly.
  
 [Hiremath, Vaibhav] Tony,
 
 Do you see any issues with this patch? I think we can merge this patch series.

Looks like a valid fix to me.

Tony
 
 Thanks,
 Vaibhav
 
  Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
  ---
   arch/arm/mach-omap2/board-omap3evm.c |5 -
   1 files changed, 4 insertions(+), 1 deletions(-)
  
  diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
  omap2/board-omap3evm.c
  index 74bbdcb..f2a52c3 100644
  --- a/arch/arm/mach-omap2/board-omap3evm.c
  +++ b/arch/arm/mach-omap2/board-omap3evm.c
  @@ -420,7 +420,10 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
  
  /* TWL4030_GPIO_MAX + 0 == ledA, LCD Backlight control */
  gpio_request(gpio + TWL4030_GPIO_MAX, EN_LCD_BKL);
  -   gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
  +   if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2)
  +   gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1);
  +   else
  +   gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
  
  /* gpio + 7 == DVI Enable */
  gpio_request(gpio + 7, EN_DVI);
  --
  1.6.2.4
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP3: mailbox initialization for all omap versions

2010-04-01 Thread Hiroshi DOYU

From: ext Tony Lindgren t...@atomide.com
Subject: Re: [PATCH] OMAP3: mailbox initialization for all omap versions
Date: Thu, 1 Apr 2010 11:52:04 +0200

 * Hiroshi DOYU hiroshi.d...@nokia.com [100329 02:05]:
 From: Balbi Felipe (Nokia-D/Helsinki) felipe.ba...@nokia.com
 Subject: Re: [PATCH] OMAP3: mailbox initialization for all omap versions
 Date: Mon, 29 Mar 2010 09:01:45 +0200

  in that case, wouldn't it be better to split that into 
  arch/arm/omap1/mbox.c arch/arm/omap2/mbox24xx.c 
  arch/arm/omap2/mbox34xx.c arch/arm/omap2/mbox44xx.c ??

  that way we don't need ifdefs on the code and we will only compile what 
  we really need.

 This is feasible.
 But I'm not so sure whether adding 4 new files with around only 10
 lines code is acceptable or not.

 Tony, any comment on the above?

 Basically there could be the case we need all resources if we want to
 support omap1, 2, 3 and 4 at the same time, and the appropriate one
 will be chosen at run time by CPUID. I'm not sure how mature omap
 multi arch support is practically, but it's better to keep it as much
 as possbile.

 I like Felipe's suggestion of adding devices2420.c, devices34xx.c,
 devices44xx.c or similar. Then do the device init from those with
 a arch_initcall that returns immediately if not running on the right
 soc.

Ok, let's procced with this. I'll post something later.

--
To unsubscribe from this list: send the line unsubscribe 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] Fix omap 1-wire driver compilation

Hi,

* Amit Kucheria amit.kuche...@verdurent.com [100322 05:37]:
 Patch from the Ubuntu omap tree[1] follows.

Thanks, can you please resend it to Evgeniy Polyakov john...@2ka.mipt.ru
for merging.

Acked-by: Tony Lindgren t...@atomide.com

 Regards,
 Amit
 
 [1].
 http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=shortlog;h=refs/heads/ti-omap
 
 From 2f101ae458745c1787869cf6907d459c3bc9425e Mon Sep 17 00:00:00 2001
 Message-Id: 
 2f101ae458745c1787869cf6907d459c3bc9425e.1269261108.git.amit.kuche...@verdurent.com
 From: Amit Kucheria amit.kuche...@canonical.com
 Date: Wed, 10 Mar 2010 14:10:54 +0200
 Subject: [PATCH] UBUNTU: [Upstream] Fix omap 1-wire driver compilation
 
 This fixes the following error message:
 
 drivers/w1/masters/omap_hdq.c: In function 'hdq_wait_for_flag':
 drivers/w1/masters/omap_hdq.c:137: error: implicit declaration of function
 'schedule_timeout_uninterruptible'
 drivers/w1/masters/omap_hdq.c: In function 'hdq_write_byte':
 drivers/w1/masters/omap_hdq.c:177: error: 'TASK_UNINTERRUPTIBLE' undeclared
 (first use in this function)
 drivers/w1/masters/omap_hdq.c:177: error: (Each undeclared identifier is
 reported only once
 drivers/w1/masters/omap_hdq.c:177: error: for each function it appears in.)
 drivers/w1/masters/omap_hdq.c:177: error: implicit declaration of function
 'schedule_timeout'
 drivers/w1/masters/omap_hdq.c: In function 'hdq_isr':
 drivers/w1/masters/omap_hdq.c:221: error: 'TASK_NORMAL' undeclared (first use
 in this function)
 drivers/w1/masters/omap_hdq.c: In function 'omap_hdq_break':
 drivers/w1/masters/omap_hdq.c:316: error: 'TASK_UNINTERRUPTIBLE' undeclared
 (first use in this function)
 
 Signed-off-by: Amit Kucheria amit.kuche...@canonical.com
 ---
  drivers/w1/masters/omap_hdq.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c
 index 0d92969..2c2bd35 100644
 --- a/drivers/w1/masters/omap_hdq.c
 +++ b/drivers/w1/masters/omap_hdq.c
 @@ -15,6 +15,7 @@
  #include linux/err.h
  #include linux/clk.h
  #include linux/io.h
 +#include linux/sched.h
  
  #include asm/irq.h
  #include mach/hardware.h
 -- 
 1.6.3.3
 
 -- 
 -
 Amit Kucheria, Kernel Developer, Verdurent
 -
 --
 To unsubscribe from this list: send the line unsubscribe 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: Where did the twl4030 battery charging code go?


On Thu, Apr 01, 2010 at 12:16:20PM +0200, ext Tony Lindgren wrote:

If it's not in mainline, we don't have it queued anywhere else.
The missing pieces should be sent via the MFD list after the
necessary cleanups.


for this case, I suggest adding power_supply list and maintainers to the 
loop.


--
balbi
--
To unsubscribe from this list: send the line unsubscribe 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] OMAP3:GPIO:Add support for early platform gpio device



 -Original Message-
 From: Tony Lindgren [mailto:t...@atomide.com]
 Sent: Thursday, April 01, 2010 2:44 PM
 To: Varadarajan, Charulatha
 Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com
 Subject: Re: [PATCH 2/8] OMAP3:GPIO:Add support for early platform gpio device
 
 * Charulatha V ch...@ti.com [100331 05:15]:
  This patch adds support for implementing OMAP3 GPIO as an
  early platform device and adds gpio_init specific to OMAP3
 
  This patch adds device structures for each GPIO device in
  OMAP3 architecture. These strutures are not created in a
  separate *_data.c file because these structures would be
  removed once the driver gets adapted to HWMOD way.
 
  Signed-off-by: Charulatha V ch...@ti.com
  ---
   arch/arm/mach-omap2/gpio3xxx.c  |  351 
  +++
   arch/arm/mach-omap2/include/mach/gpio.h |   13 +-
   2 files changed, 363 insertions(+), 1 deletions(-)
   create mode 100644 arch/arm/mach-omap2/gpio3xxx.c
 
  diff --git a/arch/arm/mach-omap2/gpio3xxx.c b/arch/arm/mach-omap2/gpio3xxx.c
  new file mode 100644
  index 000..8f404e7
  --- /dev/null
  +++ b/arch/arm/mach-omap2/gpio3xxx.c
  @@ -0,0 +1,351 @@
  +/*
  + * gpio3xxx.c - OMAP3-specific gpio code
  + *
  + * Copyright (C) 2010 Texas Instruments, Inc.
  + *
  + * Author:
  + * Charulatha V ch...@ti.com
  + *
  + * This program is free software; you can redistribute it and/or modify
  + * it under the terms of the GNU General Public License version 2 as
  + * published by the Free Software Foundation.
  + */
  +
  +#include plat/gpio.h
  +
  +/*
  + * OMAP3 GPIO reg offsets
  + */
  +static struct gpio_reg_offset omap3_gpio_reg = {
  +   .data_in= OMAP24XX_GPIO_DATAIN,
  +   .data_out   = OMAP24XX_GPIO_DATAOUT,
  +   .data_out_set   = OMAP24XX_GPIO_SETDATAOUT,
  +   .data_out_clear = OMAP24XX_GPIO_CLEARDATAOUT,
  +   .dir_ctrl   = OMAP24XX_GPIO_OE,
  +   .irq_status0= OMAP24XX_GPIO_IRQSTATUS1,
  +   .irq_status1= OMAP24XX_GPIO_IRQSTATUS2,
  +   .irq_mask   = OMAP24XX_GPIO_IRQENABLE1,
  +   .irq_set= OMAP24XX_GPIO_SETIRQENABLE1,
  +   .irq_clear  = OMAP24XX_GPIO_CLEARIRQENABLE1,
  +   .irq_mask_bits  = 0x,
  +   .irq_inv= 0,
  +   .wkup_enable= OMAP24XX_GPIO_WAKE_EN,
  +   .wkup_clear = OMAP24XX_GPIO_CLEARWKUENA,
  +   .wkup_set   = OMAP24XX_GPIO_SETWKUENA,
  +   .debounce_ena   = OMAP24XX_GPIO_DEBOUNCE_EN,
  +   .debounce_val   = OMAP24XX_GPIO_DEBOUNCE_VAL,
  +   .ctrl   = OMAP24XX_GPIO_CTRL,
  +   .syscfg = OMAP24XX_GPIO_SYSCONFIG,
  +   .leveldetect0   = OMAP24XX_GPIO_LEVELDETECT0,
  +   .leveldetect1   = OMAP24XX_GPIO_LEVELDETECT1,
  +   .rise_detect= OMAP24XX_GPIO_RISINGDETECT,
  +   .fall_detect= OMAP24XX_GPIO_FALLINGDETECT,
  +   .rev_reg= OMAP24XX_GPIO_REVISION,
  +};
 
 Can we use just a omap specific shift here? Or is the register
 ordering different too?

The register ordering is more or less same for OMAP2PLUS, but in
OMAP1 some registers don't even exist. 

 
 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 7/8] OMAP2PLUS:GPIO:Move gpio_init from board files to init_common_hw

 -Original Message-
 From: Tony Lindgren [mailto:t...@atomide.com]
 Sent: Thursday, April 01, 2010 3:03 PM
 To: Varadarajan, Charulatha
 Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com
 Subject: Re: [PATCH 7/8] OMAP2PLUS:GPIO:Move gpio_init from board files to
 init_common_hw

 * Charulatha V ch...@ti.com [100331 05:15]:
  This is preparation for early platform device implementation
  for GPIO in OMAP2PLUS. This patch moves initialization of gpio
  from board files to omap2_init_common_hw API in io.c

  Init_irq needs to be done before gpio_init, the init_irq
  is called before omap2_init_common_hw in board files

 Nope. We want to call omap2_init_common_hw as early as
 possible, otherwise the cpu detection won't work.

 What omaps have you tested this series on?

I tested it on 3430SDP, 4430SDP and zoom3 and did not face
any problem. I will keep this point in mind while creating
next version of patches.

 Tony

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/8] OMAP3:GPIO:Add support for early platform gpio device



 -Original Message-
 From: Tony Lindgren [mailto:t...@atomide.com]
 Sent: Thursday, April 01, 2010 3:01 PM
 To: Varadarajan, Charulatha
 Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com
 Subject: Re: [PATCH 2/8] OMAP3:GPIO:Add support for early platform gpio device
 
 * Charulatha V ch...@ti.com [100331 05:15]:
  +
  +int __init omap3_early_init_gpio(struct platform_device ***pdev)
  +{
  +   *pdev = omap3_gpio_early_dev;
  +   return OMAP34XX_NR_GPIOS;
  +}
 
 ...
 
  +int __init omap3_gpio_dev_reg(void)
  +{
  +   if (cpu_is_omap34xx()) {
  +   platform_device_register(omap3_gpio1);
  +   platform_device_register(omap3_gpio2);
  +   platform_device_register(omap3_gpio3);
  +   platform_device_register(omap3_gpio4);
  +   platform_device_register(omap3_gpio5);
  +   platform_device_register(omap3_gpio6);
  +   }
  +   return 0;
  +}
  +arch_initcall(omap3_gpio_dev_reg);
 
 Just call omap_gpio_init for each platform data.

I miss something here. Please provide more info.

 
 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/8] OMAP:GPIO:Move architecture specific macros to specific header

 -Original Message-
 From: Tony Lindgren [mailto:t...@atomide.com]
 Sent: Thursday, April 01, 2010 3:11 PM
 To: Varadarajan, Charulatha
 Cc: felipe.ba...@nokia.com; linux-omap@vger.kernel.org; Nayak, Rajendra;
 p...@pwsan.com
 Subject: Re: [PATCH 1/8] OMAP:GPIO:Move architecture specific macros to 
 specific
 header

 * Varadarajan, Charulatha ch...@ti.com [100401 01:48]:

   Add prefixes to these defines and remove the ifdefs.
   This breaks multi-omap builds.

  AFAIK multi-omap build not applicable for OMAP1

 Wrong. Multi-omap for omap1 has been mostly working for
 about 5 years. In general, we don't want to apply patches
 that obviously break things like that.

These macros already existed in plat/gpio.c and I just moved
it to gpio.h. It was not newly introduced by me.

Please point to a defconfig that takes care of multi-omap1 build
similar to what we have for OMAP2PLUS so that we can take
care of this in the future.

 If you take a look at arch/arm/mach-omap1/Kconfig, there's
 no choice there between omap1 socs.

   -struct gpio_bank {
   -   unsigned long pbase;
   -   void __iomem *base;
   -   u16 irq;
   -   u16 virtual_irq_start;
   -   int method;
   -#if defined(CONFIG_ARCH_OMAP16XX) || defined(CONFIG_ARCH_OMAP2PLUS)
   -   u32 suspend_wakeup;
   -   u32 saved_wakeup;
   -#endif
   -#ifdef CONFIG_ARCH_OMAP2PLUS
   -   u32 non_wakeup_gpios;
   -   u32 enabled_non_wakeup_gpios;
   -
   -   u32 saved_datain;
   -   u32 saved_fallingdetect;
   -   u32 saved_risingdetect;
   -#endif
   -   u32 level_mask;
   -   u32 toggle_mask;
   -   spinlock_t lock;
   -   struct gpio_chip chip;
   -   struct clk *dbck;
   -   u32 mod_usage;
   -};

   defines are fine, but this structure belongs to this driver. Nobody else
   should need to poke on it. Keep it here.

  This would get used in mach-omap layers in the later patches.
  Hence moving it to gpio.h

 Why would the hwmod code need to know about the register layout?
 That's totally gpio specific.

Yes, they are GPIO specific and not used in hwmod code. They are 
used in the OMAP specific GPIO code (eg., set gpio triggering 
is handled different for different OMAPs and they need this structure).

   @@ -625,10 +421,12 @@ void omap_set_gpio_debounce(int gpio, int enable)
   bank = get_gpio_bank(gpio);
   reg = bank-base;

   +#ifdef CONFIG_ARCH_OMAP2PLUS
   if (cpu_is_omap44xx())
   reg += OMAP4_GPIO_DEBOUNCENABLE;
   else
   reg += OMAP24XX_GPIO_DEBOUNCE_EN;
   +#endif

   you should try to remove ifdefs not add more.

  As mentioned in the beginning of this patch, these are
  only temporary and all possible #ifdefs are removed at
  the end of this patch series when plat-omap/gpio.c handles
  only common APIs.

 You need to first implement just initializing things using the
 platform data. Only then start messing with the functions.

Okay.

 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: [RFC/PATCHv2 2/4] arm: omap: gpio: implement set_debounce method

2010-04-01 Thread Grazvydas Ignotas

On Thu, Apr 1, 2010 at 1:10 PM, Felipe Balbi felipe.ba...@nokia.com wrote:
 On Thu, Apr 01, 2010 at 11:37:16AM +0200, ext Grazvydas Ignotas wrote:

 On Thu, Apr 1, 2010 at 12:32 PM, Felipe Balbi felipe.ba...@nokia.com
 wrote:

 On Thu, Apr 01, 2010 at 11:29:16AM +0200, ext Grazvydas Ignotas wrote:

 Hmh, dbck is shared by the whole GPIO bank, so what happens if someone
 calls _set_gpio_debounce(bank, 1, 310) and then
 _set_gpio_debounce(bank, 2, 0)? This should leave debounce enabled for
 GPIO1, but you'll disable dbck on second call. GPIOs 0-31 share the
 same bank.

 but why would you call _set_gpio_debounce(bank, 2 0); without setting a
 real
 debounce value before ?

 ok then you could call
  _set_gpio_debounce(bank, 1, 310);
  _set_gpio_debounce(bank, 2, 310);
  _set_gpio_debounce(bank, 2, 0);

 The problem here is that debounce is still active for GPIO1, but you
 disable dbck for the whole bank.

 but then you enabled the clock twice. There's refcounting for the clock.

Oh, it's fine then, forgot about clock refcounting.
--
To unsubscribe from this list: send the line unsubscribe 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: mailbox initialization for all omap versions


Hi,

On Thu, Apr 01, 2010 at 01:26:29PM +0200, Doyu Hiroshi (Nokia-D/Helsinki) wrote:

+static int __init omap24xx_init_devices(void)
+{
+   if (!cpu_is_omap24xx())
+   return;


return 0
here.


+static int __init omap44xx_init_devices(void)
+{
+   if (!cpu_is_omap44xx())
+   return;


return 0
here too :-)

other than that, to me it looks a lot cleaner. Then we can start moving 
any other device registration that still lies in devices.c to the new 
files


--
balbi
--
To unsubscribe from this list: send the line unsubscribe 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 V4 0/2] OMAP3: Dynamic Calculation of SDRC stall latency during DVFS

2010-04-01 Thread Pramod Gurav

From: Pramod Gurav pramod.gu...@ti.com 

The patch has the changes to calculate the dpll3 clock stabilization
delay dynamically. The SRAM delay is calibrated during bootup using the
gptimers and used while calculating the stabilization delay. By using
the dynamic method the dependency on the type of cache being used is
removed.

Formula to calculate the DVFS latency for 3430 and 3630 are different.
The second patch implements the formula for later.

This Version of patches adds optimisation to the formula implementation.

Teerth Reddy (1):
  OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS
Pramod Gurav (1):
  OMAP3630 SDRC: Change in DVFS Latency Formula for OMAP3630

 arch/arm/mach-omap2/clkt34xx_dpll3m2.c |   71 +++-
 arch/arm/mach-omap2/clock34xx.h|2 +
 arch/arm/mach-omap2/clock3xxx.c|2 +-
 arch/arm/mach-omap2/clock3xxx.h|1 +
 arch/arm/mach-omap2/clock3xxx_data.c   |   13 ++
 arch/arm/mach-omap2/sram34xx.S |8 
 arch/arm/plat-omap/include/plat/sram.h |4 ++
 arch/arm/plat-omap/sram.c  |   51 +++
 8 files changed, 140 insertions(+), 12 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 v4 1/2] OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS

2010-04-01 Thread Pramod Gurav

From: Teerth Reddy tee...@ti.com 

The patch has the changes to calculate the dpll3 clock stabilization
delay dynamically. The SRAM delay is calibrated during bootup using the
gptimers and used while calculating the stabilization delay. By using
the dynamic method the dependency on the type of cache being used is
removed. Hence there is no need of loop based calculation.

The wait time for L3 clock stabilization is calculated using the formula
= 4*REFCLK + 8*CLKOUTX2,
which uses the M, N and M2 read from the registers.
Since this gives slightly less value, 2us is added as buffer for safety.
This works fine for omap3.

Signed-off-by: Teerth Reddy tee...@ti.com
Signed-off-by: Romit Dasgupta ro...@ti.com
Signed-off-by: Pramod Gurav pramod.gu...@ti.com
Signed-off-by: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Ambresh K ambr...@ti.com

---
 arch/arm/mach-omap2/clkt34xx_dpll3m2.c |   56 +--
 arch/arm/mach-omap2/clock34xx.h|2 +
 arch/arm/mach-omap2/clock3xxx.c|2 +-
 arch/arm/mach-omap2/clock3xxx.h|1 +
 arch/arm/mach-omap2/clock3xxx_data.c   |   13 +++
 arch/arm/mach-omap2/sram34xx.S |8 
 arch/arm/plat-omap/include/plat/sram.h |4 ++
 arch/arm/plat-omap/sram.c  |   51 +
 8 files changed, 125 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c 
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index b2b1e37..6ad18f2 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -24,13 +24,22 @@
 #include plat/clock.h
 #include plat/sram.h
 #include plat/sdrc.h
+#include plat/prcm.h
 
 #include clock.h
 #include clock3xxx.h
 #include clock34xx.h
 #include sdrc.h
 
-#define CYCLES_PER_MHZ 100
+#defineCYCLES_PER_MHZ  100
+
+#defineDPLL_M_MASK 0x7ff
+#defineDPLL_N_MASK 0x7f
+#defineDPLL_M2_MASK0x1f
+#defineSHIFT_DPLL_M16
+#defineSHIFT_DPLL_N8
+#defineSHIFT_DPLL_M2   27
+#defineSCALING_FACTOR  10
 
 /*
  * CORE DPLL (DPLL3) M2 divider rate programming functions
@@ -51,10 +60,14 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned 
long rate)
 {
u32 new_div = 0;
u32 unlock_dll = 0;
-   u32 c;
-   unsigned long validrate, sdrcrate, _mpurate;
+   u32 c, delay_sram;
+   u32 clk_sel_regval, sys_clk;
+   u32 m, n, m2;
+   u32 sys_clk_rate, sdrc_clk_stab;
+   u32 refclk, clkoutx2, switch_latency;
struct omap_sdrc_params *sdrc_cs0;
struct omap_sdrc_params *sdrc_cs1;
+   unsigned long validrate, sdrcrate, _mpurate;
int ret;
 
if (!clk || !rate)
@@ -79,16 +92,37 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned 
long rate)
unlock_dll = 1;
}
 
+   clk_sel_regval = __raw_readl(clk-clksel_reg);
+
+   /* Get the M, N and M2 values required for getting sdrc clk stab */
+   m = (clk_sel_regval  SHIFT_DPLL_M)  DPLL_M_MASK;
+   n = (clk_sel_regval  SHIFT_DPLL_N)  DPLL_N_MASK;
+   m2 = (clk_sel_regval  SHIFT_DPLL_M2)  DPLL_M2_MASK;
+
+   sys_clk_rate = (sys_ck_p-rate) / CYCLES_PER_MHZ;
+
+   _mpurate = arm_fck_p-rate / CYCLES_PER_MHZ;
+
+   delay_sram = delay_sram_val();
+   sys_clk = (1  SCALING_FACTOR) / sys_clk_rate;
+   clkoutx2 = (sys_clk * (n + 1) * m2) / (2 * m);
+
+   /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */
+   refclk = (n + 1) * sys_clk;
+   switch_latency =  (4 * refclk) + (8 * clkoutx2);
+
+   /* Adding 2000 ns to sdrc clk stab */
+   sdrc_clk_stab =  switch_latency + 2000;
+
/*
-* XXX This only needs to be done when the CPU frequency changes
+* Calculate the number of MPU cycles
+* to wait for SDRC to stabilize
 */
-   _mpurate = arm_fck_p-rate / CYCLES_PER_MHZ;
-   c = (_mpurate  SDRC_MPURATE_SCALE)  SDRC_MPURATE_BASE_SHIFT;
-   c += 1;  /* for safety */
-   c *= SDRC_MPURATE_LOOPS;
-   c = SDRC_MPURATE_SCALE;
-   if (c == 0)
-   c = 1;
+   c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2))  SCALING_FACTOR;
+
+   pr_debug(m = %d, n = %d, m2 =%d\n, m, n, m2);
+   pr_debug(switch_latency = %d, sys_clk_rate = %d, cycles = %d\n,
+   switch_latency, sys_clk_rate, c);
 
pr_debug(clock: changing CORE DPLL rate from %lu to %lu\n, clk-rate,
 validrate);
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 628e8de..a9f2204 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -12,4 +12,6 @@ extern const struct clkops clkops_omap3430es2_ssi_wait;
 extern const struct clkops

[PATCH v1 2/2] OMAP3630 SDRC: Change in DVFS Latency Formula for OMAP3630

2010-04-01 Thread Pramod Gurav

To calculate the dpll3 M2 clock stabilization delay dynamically and wait
time for L3 M2 clock stabilization are different for 3430  3630 and is
as follows:
3430: 4*REFCLK + 8*CLKOUTX2
3630: 2*SYS_CLK + 10*CLKOUTX2
REFCLK  CLKOUTX2 are derived from M, N, M2  and DPLL reference clock.

Incase of 3430 a 2usec and 3630 1usec buffer time is added for safety.

Signed-off-by: Pramod Gurav pramod.gu...@ti.com
Signed-off-by: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Ambresh K ambr...@ti.com

---
 arch/arm/mach-omap2/clkt34xx_dpll3m2.c |   27 +--
 1 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c 
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index 6ad18f2..af0807a 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -39,6 +39,12 @@
 #defineSHIFT_DPLL_M16
 #defineSHIFT_DPLL_N8
 #defineSHIFT_DPLL_M2   27
+
+/*
+ * While calculating M2 stabilization delay, especially the formula
+ * used for 3630 computes to zero. So to avoid calculation truncating to
+ * zero, SCALING_FACTOR is used appropriately.
+ */
 #defineSCALING_FACTOR  10
 
 /*
@@ -107,12 +113,21 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned 
long rate)
sys_clk = (1  SCALING_FACTOR) / sys_clk_rate;
clkoutx2 = (sys_clk * (n + 1) * m2) / (2 * m);
 
-   /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */
-   refclk = (n + 1) * sys_clk;
-   switch_latency =  (4 * refclk) + (8 * clkoutx2);
-
-   /* Adding 2000 ns to sdrc clk stab */
-   sdrc_clk_stab =  switch_latency + 2000;
+   /*
+* wait time for L3 clk stabilization
+* for OMAP3430 = 4*REFCLK + 8*CLKOUTX2
+* for OMAP3630 = 2*REFCLK + 8*CLKOUTX2
+*/
+   if (cpu_is_omap3630()) {
+   switch_latency = (2 * sys_clk) + (10 * clkoutx2);
+   /* Adding 1000 nano seconds to sdrc clk stab */
+   sdrc_clk_stab = switch_latency + 1000;
+   } else {
+   refclk = (n + 1) * sys_clk;
+   switch_latency =  (4 * refclk) + (8 * clkoutx2);
+   /* Adding 2000 ns to sdrc clk stab */
+   sdrc_clk_stab =  switch_latency + 2000;
+   }
 
/*
 * Calculate the number of MPU cycles
-- 
1.6.0.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] OMAP3EVM: Made backlight GPIO default state to off

Hi,

On Mon, 2010-03-22 at 14:11 +0100, ext hvaib...@ti.com wrote:
 From: Vaibhav Hiremath hvaib...@ti.com
 
 If you choose default output to DVI, the LCD backlight still
 gets powered, since panel-disable function never gets called for LCD.
 
 So, during init put backlight GPIO to off state and the driverr
 code will decide which output to enable explicitly.

I'm not sure I understand this patch. You talk about choosing default
output (via kernel boot args, I presume), but the code checks for EVM
revision. What is the connection between EVM revision and selecting
display output?

 Tomi


--
To unsubscribe from this list: send the line unsubscribe 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: I2C: Errata i207: Clear wrong RDR interrupt

2010-04-01 Thread Manjunatha GK

Under certain rare conditions, I2C_STAT[13].RDR bit may be set
and the corresponding interrupt fire, even there is no data in
the receive FIFO, or the I2C data transfer is still ongoing.
These spurious RDR events must be ignored by the software.

This patch handles and ignores RDR spurious interrupts.

Reviewed-by: Kalliguddi, Hema hem...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: ben-li...@fluff.org
Cc: Kalliguddi, Hema hem...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f2019d2..acf4076 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -796,6 +796,19 @@ complete:
}
if (stat  (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
u8 num_bytes = 1;
+
+   /*
+* OMAP3 I2C Errata ID: i207
+* Under certain rare conditions, RDR could be set again
+* when the bus is busy, then clear and ignore the 
interrupt
+*/
+   if (!(stat  OMAP_I2C_STAT_RRDY)  (stat 
+   OMAP_I2C_STAT_BB)) {
+   /* clear RDR */
+   omap_i2c_ack_stat(dev, stat  
OMAP_I2C_STAT_RDR);
+   dev_err(dev-dev, I2C: RDR when bus is 
busy.\n);
+   return IRQ_HANDLED;
+   }
if (dev-fifo_size) {
if (stat  OMAP_I2C_STAT_RRDY)
num_bytes = dev-fifo_size;
-- 
1.6.0.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: LCD LS037V7DW01: Add Backlight driver support

Hi,

Two comments below

On Mon, 2010-03-22 at 14:11 +0100, ext hvaib...@ti.com wrote:
 From: Vaibhav Hiremath hvaib...@ti.com
 
 Tested on OMAP3EVM for OMAP3530 and AM/DM 3730.
 
 Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
 ---
  arch/arm/mach-omap2/board-omap3evm.c   |   32 
  .../video/omap2/displays/panel-sharp-ls037v7dw01.c |   75 
 
  2 files changed, 107 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
 b/arch/arm/mach-omap2/board-omap3evm.c
 index f2a52c3..ad74340 100644
 --- a/arch/arm/mach-omap2/board-omap3evm.c
 +++ b/arch/arm/mach-omap2/board-omap3evm.c
 @@ -253,6 +253,36 @@ static void omap3_evm_disable_lcd(struct omap_dss_device 
 *dssdev)
   lcd_enabled = 0;
  }
  
 +/*
 + * PWMA/B register offsets (TWL4030_MODULE_PWMA)
 + */
 +#define TWL_LED_EN   0x0
 +#define TWL_LED_PWMON0x0
 +#define TWL_LED_PWMOFF   0x1
 +
 +static void omap3evm_set_bl_intensity(struct omap_dss_device *dssdev, int 
 level)
 +{
 + unsigned char c;
 +
 + if (level  100)
 + return;
 + /*
 +  * Enable LEDA for backlight
 +  */
 + twl_i2c_write_u8(TWL4030_MODULE_LED, 0x11, TWL_LED_EN);
 +
 + c = ((125 * (100 - level)) / 100);
 + if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2) {
 + c += 1;
 + twl_i2c_write_u8(TWL4030_MODULE_PWMA, 0x7F, TWL_LED_PWMOFF);
 + twl_i2c_write_u8(TWL4030_MODULE_PWMA, c, TWL_LED_PWMON);
 + } else {
 + c += 2;
 + twl_i2c_write_u8(TWL4030_MODULE_PWMA, 0x1, TWL_LED_PWMON);
 + twl_i2c_write_u8(TWL4030_MODULE_PWMA, c, TWL_LED_PWMOFF);
 + }
 +}
 +
  static struct omap_dss_device omap3_evm_lcd_device = {
   .name   = lcd,
   .driver_name= sharp_ls_panel,
 @@ -260,6 +290,8 @@ static struct omap_dss_device omap3_evm_lcd_device = {
   .phy.dpi.data_lines = 18,
   .platform_enable= omap3_evm_enable_lcd,
   .platform_disable   = omap3_evm_disable_lcd,
 + .max_backlight_level= 100,
 + .set_backlight  = omap3evm_set_bl_intensity,
  };
  
  static int omap3_evm_enable_tv(struct omap_dss_device *dssdev)
 diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c 
 b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
 index 8d51a5e..d4fcd69 100644
 --- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
 +++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
 @@ -20,10 +20,16 @@
  #include linux/module.h
  #include linux/delay.h
  #include linux/device.h
 +#include linux/backlight.h
 +#include linux/fb.h
  #include linux/err.h
  
  #include plat/display.h
  
 +struct sharp_data {
 + struct backlight_device *bl;
 +};
 +
  static struct omap_video_timings sharp_ls_timings = {
   .x_res = 480,
   .y_res = 640,
 @@ -39,18 +45,87 @@ static struct omap_video_timings sharp_ls_timings = {
   .vbp= 1,
  };
  
 +static int sharp_ls_bl_update_status(struct backlight_device *bl)
 +{
 + struct omap_dss_device *dssdev = dev_get_drvdata(bl-dev);
 + int level;
 +
 + if (!dssdev-set_backlight)
 + return -EINVAL;
 +
 + if (bl-props.fb_blank == FB_BLANK_UNBLANK 
 + bl-props.power == FB_BLANK_UNBLANK)
 + level = bl-props.brightness;
 + else
 + level = 0;
 +
 + return dssdev-set_backlight(dssdev, level);

I think you should check if dssdev-set_backlight is NULL. Some boards
may not have set_backlight.

Also, you could divide this to board file patch and panel patch. That
way I can queue up the panel patch, and the board patch may go through
Tony.

 Tomi


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/14] omap DEBUG_LL and multiboot changes for 2.6.34

* Gadiyar, Anand gadi...@ti.com [100324 04:39]:
 Tony Lindgren wrote:
  These patches clean up the DEBUG_LL code for mach-omap1 and mach-omap2
  and then makes multiboot work for mach-omap2.
  
  Note that these patches currently allow only multiboot for 2420 + 36xx.
  Adding 2430 and omap4 needs further work.
  
 
 Tony,
 
 Purely out of curiosity (triggered by someone asking about 2430SDP on
 the list), do you know what it'll take to get mutli-boot working on 2430?

It should work assuming the debug_ll code worked earlier. Do you have
the right serial port connected and CONFIG_EARLYPRINTK enabled? You
also need earlyprink on the kernel cmdline.
 
 I'm not familiar with those boards of course - does anyone still have
 them around?

Yeah, looks like people are using 2430.

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] OMAP3EVM: Made backlight GPIO default state to off

2010-04-01 Thread Hiremath, Vaibhav

 -Original Message-
 From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
 Sent: Thursday, April 01, 2010 5:25 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org; t...@atomide.com
 Subject: Re: [PATCH 1/2] OMAP3EVM: Made backlight GPIO default state to off

 Hi,

 On Mon, 2010-03-22 at 14:11 +0100, ext hvaib...@ti.com wrote:
  From: Vaibhav Hiremath hvaib...@ti.com

  If you choose default output to DVI, the LCD backlight still
  gets powered, since panel-disable function never gets called for LCD.

  So, during init put backlight GPIO to off state and the driverr
  code will decide which output to enable explicitly.

 I'm not sure I understand this patch. You talk about choosing default
 output (via kernel boot args, I presume),
[Hiremath, Vaibhav] yes you are correct. I am talking about default output 
selection using bootargs.

 but the code checks for EVM
 revision. What is the connection between EVM revision and selecting
 display output?
[Hiremath, Vaibhav] Ohh ok, I think you are not aware that we do have 2 version 
of EVM's. EVM-1 with positive (backlight gpio) polarity and EVM-2 with negative 
(backlight gpio) polarity. 

The code is doing exactly same.

Thanks,
Vaibhav

  Tomi

--
To unsubscribe from this list: send the line unsubscribe 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: LCD LS037V7DW01: Add Backlight driver support

2010-04-01 Thread Hiremath, Vaibhav


 -Original Message-
 From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
 Sent: Thursday, April 01, 2010 5:30 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org
 Subject: Re: [PATCH] OMAP: LCD LS037V7DW01: Add Backlight driver support
 
 Hi,
 
 Two comments below
 
 On Mon, 2010-03-22 at 14:11 +0100, ext hvaib...@ti.com wrote:
  From: Vaibhav Hiremath hvaib...@ti.com
 
  Tested on OMAP3EVM for OMAP3530 and AM/DM 3730.
 
  Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
  ---
   arch/arm/mach-omap2/board-omap3evm.c   |   32 
   .../video/omap2/displays/panel-sharp-ls037v7dw01.c |   75
 
   2 files changed, 107 insertions(+), 0 deletions(-)
 
  diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
 omap2/board-omap3evm.c
  index f2a52c3..ad74340 100644
  --- a/arch/arm/mach-omap2/board-omap3evm.c
  +++ b/arch/arm/mach-omap2/board-omap3evm.c
  @@ -253,6 +253,36 @@ static void omap3_evm_disable_lcd(struct
 omap_dss_device *dssdev)
  lcd_enabled = 0;
   }
 
  +/*
  + * PWMA/B register offsets (TWL4030_MODULE_PWMA)
  + */
  +#define TWL_LED_EN 0x0
  +#define TWL_LED_PWMON  0x0
  +#define TWL_LED_PWMOFF 0x1
  +
  +static void omap3evm_set_bl_intensity(struct omap_dss_device *dssdev, int
 level)
  +{
  +   unsigned char c;
  +
  +   if (level  100)
  +   return;
  +   /*
  +* Enable LEDA for backlight
  +*/
  +   twl_i2c_write_u8(TWL4030_MODULE_LED, 0x11, TWL_LED_EN);
  +
  +   c = ((125 * (100 - level)) / 100);
  +   if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2) {
  +   c += 1;
  +   twl_i2c_write_u8(TWL4030_MODULE_PWMA, 0x7F, TWL_LED_PWMOFF);
  +   twl_i2c_write_u8(TWL4030_MODULE_PWMA, c, TWL_LED_PWMON);
  +   } else {
  +   c += 2;
  +   twl_i2c_write_u8(TWL4030_MODULE_PWMA, 0x1, TWL_LED_PWMON);
  +   twl_i2c_write_u8(TWL4030_MODULE_PWMA, c, TWL_LED_PWMOFF);
  +   }
  +}
  +
   static struct omap_dss_device omap3_evm_lcd_device = {
  .name   = lcd,
  .driver_name= sharp_ls_panel,
  @@ -260,6 +290,8 @@ static struct omap_dss_device omap3_evm_lcd_device = {
  .phy.dpi.data_lines = 18,
  .platform_enable= omap3_evm_enable_lcd,
  .platform_disable   = omap3_evm_disable_lcd,
  +   .max_backlight_level= 100,
  +   .set_backlight  = omap3evm_set_bl_intensity,
   };
 
   static int omap3_evm_enable_tv(struct omap_dss_device *dssdev)
  diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
 b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
  index 8d51a5e..d4fcd69 100644
  --- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
  +++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
  @@ -20,10 +20,16 @@
   #include linux/module.h
   #include linux/delay.h
   #include linux/device.h
  +#include linux/backlight.h
  +#include linux/fb.h
   #include linux/err.h
 
   #include plat/display.h
 
  +struct sharp_data {
  +   struct backlight_device *bl;
  +};
  +
   static struct omap_video_timings sharp_ls_timings = {
  .x_res = 480,
  .y_res = 640,
  @@ -39,18 +45,87 @@ static struct omap_video_timings sharp_ls_timings = {
  .vbp= 1,
   };
 
  +static int sharp_ls_bl_update_status(struct backlight_device *bl)
  +{
  +   struct omap_dss_device *dssdev = dev_get_drvdata(bl-dev);
  +   int level;
  +
  +   if (!dssdev-set_backlight)
  +   return -EINVAL;
  +
  +   if (bl-props.fb_blank == FB_BLANK_UNBLANK 
  +   bl-props.power == FB_BLANK_UNBLANK)
  +   level = bl-props.brightness;
  +   else
  +   level = 0;
  +
  +   return dssdev-set_backlight(dssdev, level);
 
 I think you should check if dssdev-set_backlight is NULL. Some boards
 may not have set_backlight.
 
 Also, you could divide this to board file patch and panel patch. That
 way I can queue up the panel patch, and the board patch may go through
 Tony.
[Hiremath, Vaibhav] Thanks and I will submit reworked patch soon.

Thanks,
Vaibhav

 
  Tomi
 

--
To unsubscribe from this list: send the line unsubscribe 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: DMA: Init CDAC to zero

2010-04-01 Thread G, Manjunath Kondaiah

Hi Tony,
If there are no further comments on below patches, can you please
push the patches

https://patchwork.kernel.org/patch/83540/
https://patchwork.kernel.org/patch/83541/

-Manjunath 

 -Original Message-
 From: G, Manjunath Kondaiah 
 Sent: Thursday, March 04, 2010 7:46 AM
 To: linux-omap@vger.kernel.org
 Cc: G, Manjunath Kondaiah; Tony Lindgren; Shilimkar, Santosh; 
 Raja, Govindraj; Kevin Hilman
 Subject: [PATCH v2] OMAP: DMA: Init CDAC to zero
 
 The register DMA4_CDAC needs to be initialized to zero
 before starting DMA transfer.
 
 Cc: Tony Lindgren t...@atomide.com
 Cc: Santosh Shilimkar santosh.shilim...@ti.com
 Cc: Govindraj R govindraj.r...@ti.com
 Cc: Kevin Hilman khil...@deeprootsystems.com
 Reported-by:S, Venkatraman svenk...@ti.com
 Signed-off-by: Manjunatha GK manj...@ti.com
 ---
 It was aligned to reset CDAC to zero in omap_start_dma(int lch)
 instead of creating new API for accessing CDAC register.
 
 Discussion thread is at:
 http://patchwork.kernel.org/patch/83176/
 http://patchwork.kernel.org/patch/82948/
 
 v2 changes:
 Fixed multiline comments as per CodingStyle
 
  arch/arm/plat-omap/dma.c |9 +
  1 files changed, 9 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
 index 2ab224c..f6c9bdc 100644
 --- a/arch/arm/plat-omap/dma.c
 +++ b/arch/arm/plat-omap/dma.c
 @@ -936,6 +936,15 @@ void omap_start_dma(int lch)
  {
   u32 l;
  
 + /*
 +  * The CPC/CDAC register needs to be initialized to zero
 +  * before starting dma transfer.
 +  */
 + if (cpu_is_omap15xx())
 + dma_write(0, CPC(lch));
 + else
 + dma_write(0, CDAC(lch));
 +
   if (!omap_dma_in_1510_mode()  dma_chan[lch].next_lch != -1) {
   int next_lch, cur_lch;
   char dma_chan_link_map[OMAP_DMA4_LOGICAL_DMA_CH_COUNT];
 -- 
 1.6.3.3
 
 --
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH] ASoC: OMAP: Fix capture pointer handling for OMAP1510 to work correctly with recent ALSA PCM code

2010-04-01 Thread Mark Brown

On Mon, Mar 29, 2010 at 02:14:51PM +0200, Janusz Krzysztofik wrote:

 I should have mention that I was already aware of your patch; applied alone, 
 it didn't solve the problem for me. However, when configuring ALSA with 
 debugging turned off, I have to use both patches, yours and mine, in order to 
 get things working.

Any updates on this one?
--
To unsubscribe from this list: send the line unsubscribe 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: mailbox initialization for all omap versions

2010-04-01 Thread Paul Walmsley

Hi Hiroshi,

On Thu, 1 Apr 2010, Hiroshi DOYU wrote:

From: Hiroshi DOYU hiroshi.d...@nokia.com
Subject: Re: [PATCH] OMAP3: mailbox initialization for all omap versions
Date: Thu, 01 Apr 2010 13:23:36 +0300 (EEST)

From: ext Tony Lindgren t...@atomide.com
Subject: Re: [PATCH] OMAP3: mailbox initialization for all omap versions
Date: Thu, 1 Apr 2010 11:52:04 +0200

* Hiroshi DOYU hiroshi.d...@nokia.com [100329 02:05]:
From: Balbi Felipe (Nokia-D/Helsinki) felipe.ba...@nokia.com
Subject: Re: [PATCH] OMAP3: mailbox initialization for all omap versions
Date: Mon, 29 Mar 2010 09:01:45 +0200

in that case, wouldn't it be better to split that into
arch/arm/omap1/mbox.c arch/arm/omap2/mbox24xx.c
arch/arm/omap2/mbox34xx.c arch/arm/omap2/mbox44xx.c ??

that way we don't need ifdefs on the code and we will only compile what
we really need.

This is feasible.
But I'm not so sure whether adding 4 new files with around only 10
lines code is acceptable or not.

Tony, any comment on the above?

Basically there could be the case we need all resources if we want to
support omap1, 2, 3 and 4 at the same time, and the appropriate one
will be chosen at run time by CPUID. I'm not sure how mature omap
multi arch support is practically, but it's better to keep it as much
as possbile.

I like Felipe's suggestion of adding devices2420.c, devices34xx.c,
devices44xx.c or similar. Then do the device init from those with
a arch_initcall that returns immediately if not running on the right
soc.

Ok, let's procced with this. I'll post something later.

Something like the following?

Is it possible to try a hwmod conversion of this? Similar to the UART,
HSMMC, etc. work that Kevin has queued in his pm-wip/hwmods branch:

http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=shortlog;h=refs/heads/pm-wip/hwmods

Otherwise this will all have to be redone when the mailbox is converted to
use hwmod.

- 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] OMAP3: mailbox initialization for all omap versions

* Paul Walmsley p...@pwsan.com [100401 05:29]:
Hi Hiroshi,

On Thu, 1 Apr 2010, Hiroshi DOYU wrote:

From: Hiroshi DOYU hiroshi.d...@nokia.com
Subject: Re: [PATCH] OMAP3: mailbox initialization for all omap versions
Date: Thu, 01 Apr 2010 13:23:36 +0300 (EEST)

From: ext Tony Lindgren t...@atomide.com
Subject: Re: [PATCH] OMAP3: mailbox initialization for all omap versions
Date: Thu, 1 Apr 2010 11:52:04 +0200

in that case, wouldn't it be better to split that into
arch/arm/omap1/mbox.c arch/arm/omap2/mbox24xx.c
arch/arm/omap2/mbox34xx.c arch/arm/omap2/mbox44xx.c ??

that way we don't need ifdefs on the code and we will only compile
what
we really need.

This is feasible.
But I'm not so sure whether adding 4 new files with around only 10
lines code is acceptable or not.

Tony, any comment on the above?

Ok, let's procced with this. I'll post something later.

Something like the following?

Is it possible to try a hwmod conversion of this? Similar to the UART,
HSMMC, etc. work that Kevin has queued in his pm-wip/hwmods branch:

http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=shortlog;h=refs/heads/pm-wip/hwmods

Otherwise this will all have to be redone when the mailbox is converted to
use hwmod.

Sounds like a plan to me.

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] OMAP3: mailbox initialization for all omap versions

2010-04-01 Thread Hiroshi DOYU

From: ext Paul Walmsley p...@pwsan.com
Subject: Re: [PATCH] OMAP3: mailbox initialization for all omap versions
Date: Thu, 1 Apr 2010 14:33:22 +0200

 Hi Hiroshi,

 On Thu, 1 Apr 2010, Hiroshi DOYU wrote:

 From: Hiroshi DOYU hiroshi.d...@nokia.com
 Subject: Re: [PATCH] OMAP3: mailbox initialization for all omap versions
 Date: Thu, 01 Apr 2010 13:23:36 +0300 (EEST)

  From: ext Tony Lindgren t...@atomide.com
  Subject: Re: [PATCH] OMAP3: mailbox initialization for all omap versions
  Date: Thu, 1 Apr 2010 11:52:04 +0200

  * Hiroshi DOYU hiroshi.d...@nokia.com [100329 02:05]:
  From: Balbi Felipe (Nokia-D/Helsinki) felipe.ba...@nokia.com
  Subject: Re: [PATCH] OMAP3: mailbox initialization for all omap versions
  Date: Mon, 29 Mar 2010 09:01:45 +0200

   in that case, wouldn't it be better to split that into 
   arch/arm/omap1/mbox.c arch/arm/omap2/mbox24xx.c 
   arch/arm/omap2/mbox34xx.c arch/arm/omap2/mbox44xx.c ??

   that way we don't need ifdefs on the code and we will only compile 
   what 
   we really need.

  This is feasible.
  But I'm not so sure whether adding 4 new files with around only 10
  lines code is acceptable or not.

  Tony, any comment on the above?

  Basically there could be the case we need all resources if we want to
  support omap1, 2, 3 and 4 at the same time, and the appropriate one
  will be chosen at run time by CPUID. I'm not sure how mature omap
  multi arch support is practically, but it's better to keep it as much
  as possbile.

  I like Felipe's suggestion of adding devices2420.c, devices34xx.c,
  devices44xx.c or similar. Then do the device init from those with
  a arch_initcall that returns immediately if not running on the right
  soc.

  Ok, let's procced with this. I'll post something later.

 Something like the following?

 Is it possible to try a hwmod conversion of this?  Similar to the UART, 
 HSMMC, etc. work that Kevin has queued in his pm-wip/hwmods branch:

I haven't followed this, but this looks more decriptive. I'll try.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCHv2 2/4] arm: omap: gpio: implement set_debounce method

2010-04-01 Thread Jani Nikula

On Thu, Apr 1, 2010 at 12:32, Felipe Balbi felipe.ba...@nokia.com wrote:
 On Thu, Apr 01, 2010 at 11:29:16AM +0200, ext Grazvydas Ignotas wrote:

 There is also an issue if somebody calls _set_gpio_debounce(bank, 1,
 310) and _set_gpio_debounce(bank, 2, 620), the second call will
 override debounce setting of GPIO1 (as it's shared by the whole bank).
 This might be not what the user intended, would be useful to detect
 this and warn the user.

 good point. As this is RFC, I'll wait until everybody comments.

Hi Felipe -

You might want to have a look at [1] on irq debouncing. The hardware
support for debouncing varies (bank/gpio restrictions, debounce
timeouts, no support at all, what else?) so how can the users of this
interface rely on debouncing? What are the guarantees? AFAICS e.g.
gpio-keys would have to do software debouncing anyway.

[1] http://lkml.org/lkml/2008/9/24/325

BR,
Jani.
--
To unsubscribe from this list: send the line unsubscribe 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/2] [STAGING] Synaptic Touchscreen Driver

2010-04-01 Thread Hemanth V

This series of 2 patches are for the synaptic
touchscreen driver in staging. This adds
support for threaded irq and some cleanup.


Hemanth V (2)

PATCH [1/2] Remove non-standard multi touch support
PATCH [2/2] Add threaded IRQ support

 drivers/staging/dream/synaptics_i2c_rmi.c |   26 +- 1 
files changed, 5 insertions(+), 21 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/2] [STAGING] Synaptic : Remove non-standard multi touch support

2010-04-01 Thread Hemanth V

From dbd87fbdf5be92351f81030a133e57d96634a3d3 Mon Sep 17 00:00:00 2001 From: 
Hemanth V heman...@ti.com
Date: Thu, 1 Apr 2010 17:26:49 +0530
Subject: [PATCH] Remove non-standard multi touch support


Signed-off-by: Hemanth V heman...@ti.com
---
 drivers/staging/dream/synaptics_i2c_rmi.c |   15 ---
 1 files changed, 0 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/dream/synaptics_i2c_rmi.c 
b/drivers/staging/dream/synaptics_i2c_rmi.c index 4de6bc9..7c1b980 100644
--- a/drivers/staging/dream/synaptics_i2c_rmi.c
+++ b/drivers/staging/dream/synaptics_i2c_rmi.c
@@ -108,9 +108,7 @@ static void decode_report(struct synaptics_ts_data *ts, u8 
*buf)
int f, a;
int base = 2;
int z = buf[1];
-   int w = buf[0]  4;
int finger = buf[0]  7;
-   int finger2_pressed;

for (f = 0; f  2; f++) {
u32 flip_flag = SYNAPTICS_FLIP_X;
@@ -150,14 +148,7 @@ static void decode_report(struct synaptics_ts_data *ts, u8 
*buf)
input_report_abs(ts-input_dev, ABS_Y, pos[0][1]);
}
input_report_abs(ts-input_dev, ABS_PRESSURE, z);
-   input_report_abs(ts-input_dev, ABS_TOOL_WIDTH, w);
input_report_key(ts-input_dev, BTN_TOUCH, finger);
-   finger2_pressed = finger  1  finger != 7;
-   input_report_key(ts-input_dev, BTN_2, finger2_pressed);
-   if (finger2_pressed) {
-   input_report_abs(ts-input_dev, ABS_HAT0X, pos[1][0]);
-   input_report_abs(ts-input_dev, ABS_HAT0Y, pos[1][1]);
-   }
input_sync(ts-input_dev);
 }

@@ -346,11 +337,6 @@ static void compute_areas(struct synaptics_ts_data *ts,
 -inactive_area_top, max_y + inactive_area_bottom,
 fuzz_y, 0);
input_set_abs_params(ts-input_dev, ABS_PRESSURE, 0, 255, fuzz_p, 0);
-   input_set_abs_params(ts-input_dev, ABS_TOOL_WIDTH, 0, 15, fuzz_w, 0); 
-input_set_abs_params(ts-input_dev, ABS_HAT0X, -inactive_area_left, -  
  
   max_x + inactive_area_right, fuzz_x, 0);
-   input_set_abs_params(ts-input_dev, ABS_HAT0Y, -inactive_area_top, -
 max_y + inactive_area_bottom, fuzz_y, 0);
 }

 static struct synaptics_i2c_rmi_platform_data fake_pdata;
@@ -486,7 +472,6 @@ static int __devinit synaptics_ts_probe(
__set_bit(EV_SYN, ts-input_dev-evbit);
__set_bit(EV_KEY, ts-input_dev-evbit);
__set_bit(BTN_TOUCH, ts-input_dev-keybit);
-   __set_bit(BTN_2, ts-input_dev-keybit);
__set_bit(EV_ABS, ts-input_dev-evbit);

compute_areas(ts, pdata, max_x, max_y);
-- 
1.5.6.3





--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] [STAGING] Synaptic : Add threaded IRQ support

2010-04-01 Thread Hemanth V

From d04802248f813fea756e2714805bb61c86397a56 Mon Sep 17 00:00:00 2001 From: 
Hemanth V heman...@ti.com
Date: Thu, 1 Apr 2010 17:27:39 +0530
Subject: [PATCH] Add threaded IRQ support


Signed-off-by: Hemanth V heman...@ti.com
---
 drivers/staging/dream/synaptics_i2c_rmi.c |   11 +--
 1 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/dream/synaptics_i2c_rmi.c 
b/drivers/staging/dream/synaptics_i2c_rmi.c index 7c1b980..f2e333e 100644
--- a/drivers/staging/dream/synaptics_i2c_rmi.c
+++ b/drivers/staging/dream/synaptics_i2c_rmi.c
@@ -198,8 +198,6 @@ static void synaptics_ts_work_func(struct work_struct *work)

decode_report(ts, buf);
}
-   if (ts-use_irq)
-   enable_irq(ts-client-irq);
 }

 static enum hrtimer_restart synaptics_ts_timer_func(struct hrtimer *timer)
@@ -217,8 +215,7 @@ static irqreturn_t synaptics_ts_irq_handler(int irq, void 
*dev_id)
 {
struct synaptics_ts_data *ts = dev_id;

-   disable_irq_nosync(ts-client-irq);
-   queue_work(synaptics_wq, ts-work);
+   synaptics_ts_work_func(ts-work);
return IRQ_HANDLED;
 }

@@ -484,8 +481,10 @@ static int __devinit synaptics_ts_probe(
goto err_input_register_device_failed;
}
if (client-irq) {
-   ret = request_irq(client-irq, synaptics_ts_irq_handler,
- 0, client-name, ts);
+   ret = request_threaded_irq(client-irq, NULL,
+   synaptics_ts_irq_handler,
+   IRQF_TRIGGER_LOW|IRQF_ONESHOT,
+   client-name, ts);
if (ret == 0) {
ret = i2c_set(ts, 0xf1, 0x01, enable abs int);
if (ret)
-- 
1.5.6.3





--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/2] OMAP3EVM: Made backlight GPIO default state to off

On Thu, 2010-04-01 at 14:11 +0200, ext Hiremath, Vaibhav wrote:
  -Original Message-
  From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
  Sent: Thursday, April 01, 2010 5:25 PM
  To: Hiremath, Vaibhav
  Cc: linux-omap@vger.kernel.org; t...@atomide.com
  Subject: Re: [PATCH 1/2] OMAP3EVM: Made backlight GPIO default state to off

  Hi,

  On Mon, 2010-03-22 at 14:11 +0100, ext hvaib...@ti.com wrote:
   From: Vaibhav Hiremath hvaib...@ti.com

   If you choose default output to DVI, the LCD backlight still
   gets powered, since panel-disable function never gets called for LCD.

   So, during init put backlight GPIO to off state and the driverr
   code will decide which output to enable explicitly.

  I'm not sure I understand this patch. You talk about choosing default
  output (via kernel boot args, I presume),
 [Hiremath, Vaibhav] yes you are correct. I am talking about default output 
 selection using bootargs.

  but the code checks for EVM
  revision. What is the connection between EVM revision and selecting
  display output?
 [Hiremath, Vaibhav] Ohh ok, I think you are not aware that we do have 2 
 version of EVM's. EVM-1 with positive (backlight gpio) polarity and EVM-2 
 with negative (backlight gpio) polarity. 

 The code is doing exactly same.

Ok. But I still don't understand the relation with the patch comment,
and the code. Shouldn't you anyway initialize the backlight gpio
properly depending on the EVM revision, no matter if DVI is the default
output or not?

Perhaps the comment could be clarified. But the code looks fine:

Acked-by: Tomi Valkeinen tomi.valkei...@nokia.com

 Tomi

--
To unsubscribe from this list: send the line unsubscribe 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: DSS2: GFX FIFO UNDERFLOW issue fixed

On Mon, 2010-03-22 at 14:09 +0100, ext hvaib...@ti.com wrote:
 From: Vaibhav Hiremath hvaib...@ti.com
 
 In case of 720P with 90/270 degree rotation, the system reports
 GFX_FIFO_UNDERFLOW error which usually happens if DSS DMA is not able to fill
 the FIFO as per requirement.
 
 In TRM (section 11.2.6.1.3), where is has been clearly mentioned that,
 
 To improve the performance on 90 degree rotation, split the data access on
 write side and not read side.
 
 That means, read should always happen on 0 degree and write should go to
 respective rotation view.

I haven't had time to look at this patch yet. I'll try to do it next
week.

However, I knew that TRM text when I was writing the code. The reason I
chose to use 0 degree view for omapfb and change the view from DSS side
was that it was difficult to handle mmapped areas in this case, if I
recall right. I have to say I don't exactly remember what the problems
were, so I need to read the code and think about this again.

Hmm, perhaps it was so that if you choose to change omapfb's VRFB view,
you can only do that if nothing is mmapped. Which means that either you
can only use one rotation angle defined at boot time, or you need
carefully to remove all mmappings, including fb console, then change the
view and recreate the mapping. And one requirement was that the rotation
should be changeable at runtime, which made the select the current
approach.

 Tomi


--
To unsubscribe from this list: send the line unsubscribe 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: I2C: Errata i207: Clear wrong RDR interrupt

2010-04-01 Thread Nishanth Menon


G, Manjunath Kondaiah had written, on 04/01/2010 07:20 AM, the following:

Under certain rare conditions, I2C_STAT[13].RDR bit may be set
and the corresponding interrupt fire, even there is no data in
the receive FIFO, or the I2C data transfer is still ongoing.
These spurious RDR events must be ignored by the software.

This patch handles and ignores RDR spurious interrupts.

Reviewed-by: Kalliguddi, Hema hem...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: ben-li...@fluff.org
Cc: Kalliguddi, Hema hem...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f2019d2..acf4076 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -796,6 +796,19 @@ complete:
}
if (stat  (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
u8 num_bytes = 1;
+
+   /*
+* OMAP3 I2C Errata ID: i207
+* Under certain rare conditions, RDR could be set again
+* when the bus is busy, then clear and ignore the 
interrupt
+*/
+   if (!(stat  OMAP_I2C_STAT_RRDY)  (stat 
+   OMAP_I2C_STAT_BB)) {
+   /* clear RDR */
+   omap_i2c_ack_stat(dev, stat  
OMAP_I2C_STAT_RDR);
+   dev_err(dev-dev, I2C: RDR when bus is 
busy.\n);
+   return IRQ_HANDLED;
+   }

couple of comments after reading thru the errata:
a) the sequence in the errata doc is:
if (stat  OMAP_I2C_STAT_RDR) { /* This is cleaner that using an obtuse 
check using !(stat  OMAP_I2C_STAT_RRDY) */
	omap_i2c_ack_stat(dev, stat  OMAP_I2C_STAT_RDR); /* dummy read - i 
think this needs clarification as to why */
	if (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG)  OMAP_I2C_STAT_BB) /* 
reason for the i2c_read_reg is because errata mentions a dummy stat read 
 which might mean something for BB - I am not sure may need to be 
checked with H/w team. */
		continue; /* recheck - faster response compared to return and re 
generate interrupt */

}


b) does this apply to  OMAP2 and OMAP4?

(unrelated sidenote: my usual crib: we probably need an errata 
management system soon considering the erratas that are getting 
workedaround  in code.. :( )..

if (dev-fifo_size) {
if (stat  OMAP_I2C_STAT_RRDY)
num_bytes = dev-fifo_size;



--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 0/2] Enable CAN peripheral support on AM3517

2010-04-01 Thread Govindarajan, Sriramakrishnan

 -Original Message-
 From: Govindarajan, Sriramakrishnan
 Sent: Friday, February 26, 2010 5:37 PM
 To: linux-omap@vger.kernel.org
 Cc: Gole, Anant; Govindarajan, Sriramakrishnan
 Subject: [PATCH v2 0/2] Enable CAN peripheral support on AM3517

 AM3517 platform includes the ti-hecc CAN peripheral. This patch
 series enables support for the ti-hecc peripheral on AM3517 platform.
 This patch series has been validated on AM3517EVM.

 This patch is generated against tip of linux-omap.

 Sriramakrishnan (2):
   can:ti_hecc: board specific hookup on AM3517EVM
   can:ti_hecc: Enable CAN support on AM3517.

  arch/arm/configs/am3517_evm_defconfig |   22 +---
  arch/arm/mach-omap2/board-am3517evm.c |   38
 +
  arch/arm/mach-omap2/include/mach/am35xx.h |9 +++
  3 files changed, 65 insertions(+), 4 deletions(-)

[Sriram]  Tony, 
Any comments on this patch
Thanks,
Sriram

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv3 0/3] Add support for TCA6416 based Keypad driver.

2010-04-01 Thread Govindarajan, Sriramakrishnan

 -Original Message-
 From: Govindarajan, Sriramakrishnan
 Sent: Tuesday, March 23, 2010 8:41 PM
 To: linux-omap@vger.kernel.org; linux-in...@vger.kernel.org
 Cc: Govindarajan, Sriramakrishnan
 Subject: [PATCHv3 0/3] Add support for TCA6416 based Keypad driver.

 AM3517 EVM with APPS board includes keys interfaced to TCA6416 IO expander
 User keys are connected as GPIO lines to TCA6416 IO expander. Unlike the
 case with generic gpio-keypad driver individual keys do not generate an
 interrupt event. Hence we implement a simple keypad driver, that
 registers as direct I2C client.

 The implementation has been tested on AM3517 EVM with the driver tested
 in polling mode.

 Version3 is refreshed against the tip of linux-omap and
 file mode issues from the previous version is fixed.

 Sriramakrishnan (3):
   TCA6416 keypad : Implement keypad driver for keys interfaced to
 TCA6416
   AM3517: Board hookup for TCA6416 keypad driver.
   AM3517 EVM : Enable TCA6416 keypad.

  arch/arm/configs/am3517_evm_defconfig   |   16 ++-
  arch/arm/mach-omap2/board-am3517evm.c   |   47 -
  drivers/input/keyboard/Kconfig  |   16 ++
  drivers/input/keyboard/Makefile |1 +
  drivers/input/keyboard/tca6416-keypad.c |  354
 +++
  include/linux/tca6416_keypad.h  |   34 +++
  6 files changed, 462 insertions(+), 6 deletions(-)
  create mode 100644 drivers/input/keyboard/tca6416-keypad.c
  create mode 100644 include/linux/tca6416_keypad.h

[Sriram] All,
Any feedback on this updated patch series?
Thanks
Sriram

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] OMAP GPTimer for OProfile(Errata#628216)

2010-04-01 Thread Manjunatha GK

From: DebBarma, Tarun Kanti tarun.ka...@ti.com

[ARM Cortex-A8 Errata 628216]
If a Perf Counter OVFL occurs simultaneously with an update to a CP14 or
CP15 register, the OVFL status can be lost.

In order to workaround problem in Cortex-A8 Performance Counter, OMAP
GPTIMER is used by OProfile.

Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Siarhei Siamashka siarhei.siamas...@nokia.com
Cc: Manjunatha GK manj...@ti.com
---
 arch/arm/Kconfig  |   59 +++---
 arch/arm/oprofile/Makefile|1 +
 arch/arm/oprofile/common.c|4 +
 arch/arm/oprofile/op_arm_model.h  |1 +
 arch/arm/oprofile/op_model_omap_gptimer.c |   96 +
 5 files changed, 153 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/oprofile/op_model_omap_gptimer.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 410d3e3..a753c8c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -175,27 +175,70 @@ config ARM_L1_CACHE_SHIFT_6
help
  Setting ARM L1 cache line size to 64 Bytes.
 
-if OPROFILE
+menuconfig INSTRUMENTATION
+   boolInstrumentation Support
+   default y
+   ---help---
+ Say Y here to get to see options related to performance measurement,
+ system-wide debugging and testing. This option alone does not add any
+ kernel code.
+
+ If you say N, all options in this submenu will be skipped and
+ disabled. If you're trying to debug the kernel itself, check the
+ Kernel Hacking menu.
+
+if INSTRUMENTATION
+
+config PROFILING
+   bool Profiling support
+   help
+ Say Y here to enable the extended profiling support mechanisms
+ used by profilers such as OProfile.
+
+config OPROFILE
+   tristate OProfile system profiling
+   depends on PROFILING
+   help
+ OProfile is a profiling system capable of profiling the
+ whole system, including the kernel, kernel modules, libraries,
+ and applications.
+
+ If unsure, say N.
+choice
+prompt Oprofile Mode
+depends on OPROFILE
+default OPROFILE_OMAP_GPTIMER
 
 config OPROFILE_ARMV6
-   def_bool y
+   bool Oprofile ARMv6
depends on CPU_V6  !SMP
select OPROFILE_ARM11_CORE
 
 config OPROFILE_MPCORE
-   def_bool y
+   bool Oprofile MPcore
depends on CPU_V6  SMP
select OPROFILE_ARM11_CORE
 
-config OPROFILE_ARM11_CORE
-   bool
-
 config OPROFILE_ARMV7
-   def_bool y
+   bool Oprofile ARMv7
depends on CPU_V7  !SMP
+   help
+ Uses Performance counters for profiling
+
+config OPROFILE_OMAP_GPTIMER
+   bool Oprofile GPTimer
+   depends on ARCH_OMAP
+   select OMAP_32K_TIMER
+   select OMAP_DM_TIMER
+   help
+ Uses GPTIMER for profiling. Currently this is the preferred
+ way since Performance counters have known bugs in Cortex-A8
+endchoice
+
+config OPROFILE_ARM11_CORE
bool
 
-endif
+endif # INSTRUMENTATION
 
 config VECTORS_BASE
hex
diff --git a/arch/arm/oprofile/Makefile b/arch/arm/oprofile/Makefile
index 88e31f5..fc2bc02 100644
--- a/arch/arm/oprofile/Makefile
+++ b/arch/arm/oprofile/Makefile
@@ -8,6 +8,7 @@ DRIVER_OBJS = $(addprefix ../../../drivers/oprofile/, \
 
 oprofile-y := $(DRIVER_OBJS) common.o backtrace.o
 oprofile-$(CONFIG_CPU_XSCALE)  += op_model_xscale.o
+oprofile-$(CONFIG_OPROFILE_OMAP_GPTIMER)   += op_model_omap_gptimer.o
 oprofile-$(CONFIG_OPROFILE_ARM11_CORE) += op_model_arm11_core.o
 oprofile-$(CONFIG_OPROFILE_ARMV6)  += op_model_v6.o
 oprofile-$(CONFIG_OPROFILE_MPCORE) += op_model_mpcore.o
diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
index 3fcd752..9eb2b9b 100644
--- a/arch/arm/oprofile/common.c
+++ b/arch/arm/oprofile/common.c
@@ -133,6 +133,10 @@ int __init oprofile_arch_init(struct oprofile_operations 
*ops)
 
ops-backtrace = arm_backtrace;
 
+#ifdef CONFIG_OPROFILE_OMAP_GPTIMER
+   spec = op_omap_gptimer_spec;
+#endif
+
 #ifdef CONFIG_CPU_XSCALE
spec = op_xscale_spec;
 #endif
diff --git a/arch/arm/oprofile/op_arm_model.h b/arch/arm/oprofile/op_arm_model.h
index 8c4e4f6..55f22e4 100644
--- a/arch/arm/oprofile/op_arm_model.h
+++ b/arch/arm/oprofile/op_arm_model.h
@@ -24,6 +24,7 @@ struct op_arm_model_spec {
 extern struct op_arm_model_spec op_xscale_spec;
 #endif
 
+extern struct op_arm_model_spec op_omap_gptimer_spec;
 extern struct op_arm_model_spec op_armv6_spec;
 extern struct op_arm_model_spec op_mpcore_spec;
 extern struct op_arm_model_spec op_armv7_spec;
diff --git a/arch/arm/oprofile/op_model_omap_gptimer.c 
b/arch/arm/oprofile/op_model_omap_gptimer.c
new file mode 100644
index 000..49bab30
--- /dev/null
+++ b/arch/arm/oprofile/op_model_omap_gptimer.c
@@ -0,0 +1,96 @@
+/**
+ * OMAP gptimer based event monitor driver for oprofile
+ *
+ * Copyright (C) 2009 Nokia

RE: [PATCH] OMAP GPTimer for OProfile(Errata#628216)

2010-04-01 Thread Shilimkar, Santosh

Tarun,
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
 Manjunatha GK
 Sent: Thursday, April 01, 2010 8:54 PM
 To: linux-omap@vger.kernel.org
 Cc: DebBarma, Tarun Kanti; Siarhei Siamashka; G, Manjunath Kondaiah
 Subject: [PATCH] OMAP GPTimer for OProfile(Errata#628216)
 
 From: DebBarma, Tarun Kanti tarun.ka...@ti.com
 
 [ARM Cortex-A8 Errata 628216]
 If a Perf Counter OVFL occurs simultaneously with an update to a CP14 or
 CP15 register, the OVFL status can be lost.
 
 In order to workaround problem in Cortex-A8 Performance Counter, OMAP
 GPTIMER is used by OProfile.
 
 Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
 Cc: Siarhei Siamashka siarhei.siamas...@nokia.com
 Cc: Manjunatha GK manj...@ti.com
 ---
  arch/arm/Kconfig  |   59 +++---
  arch/arm/oprofile/Makefile|1 +
  arch/arm/oprofile/common.c|4 +
  arch/arm/oprofile/op_arm_model.h  |1 +
  arch/arm/oprofile/op_model_omap_gptimer.c |   96 
 +
  5 files changed, 153 insertions(+), 8 deletions(-)
  create mode 100644 arch/arm/oprofile/op_model_omap_gptimer.c
 
 diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
 index 410d3e3..a753c8c 100644
 --- a/arch/arm/Kconfig
 +++ b/arch/arm/Kconfig
 @@ -175,27 +175,70 @@ config ARM_L1_CACHE_SHIFT_6
   help
 Setting ARM L1 cache line size to 64 Bytes.
 
 -if OPROFILE
 +menuconfig INSTRUMENTATION
 + boolInstrumentation Support
 + default y
 + ---help---
 +   Say Y here to get to see options related to performance measurement,
 +   system-wide debugging and testing. This option alone does not add any
 +   kernel code.
 +
 +   If you say N, all options in this submenu will be skipped and
 +   disabled. If you're trying to debug the kernel itself, check the
 +   Kernel Hacking menu.
 +
 +if INSTRUMENTATION
 +
 +config PROFILING
 + bool Profiling support
 + help
 +   Say Y here to enable the extended profiling support mechanisms
 +   used by profilers such as OProfile.
 +
 +config OPROFILE
 + tristate OProfile system profiling
 + depends on PROFILING
 + help
 +   OProfile is a profiling system capable of profiling the
 +   whole system, including the kernel, kernel modules, libraries,
 +   and applications.
 +
 +   If unsure, say N.
 +choice
 +prompt Oprofile Mode
 +depends on OPROFILE
 +default OPROFILE_OMAP_GPTIMER
 
  config OPROFILE_ARMV6
 - def_bool y
 + bool Oprofile ARMv6
   depends on CPU_V6  !SMP
   select OPROFILE_ARM11_CORE
 
  config OPROFILE_MPCORE
 - def_bool y
 + bool Oprofile MPcore
   depends on CPU_V6  SMP
   select OPROFILE_ARM11_CORE
 
 -config OPROFILE_ARM11_CORE
 - bool
 -
  config OPROFILE_ARMV7
 - def_bool y
 + bool Oprofile ARMv7
   depends on CPU_V7  !SMP
 + help
 +   Uses Performance counters for profiling
 +
 +config OPROFILE_OMAP_GPTIMER
 + bool Oprofile GPTimer
 + depends on ARCH_OMAP
 + select OMAP_32K_TIMER
 + select OMAP_DM_TIMER
 + help
 +   Uses GPTIMER for profiling. Currently this is the preferred
 +   way since Performance counters have known bugs in Cortex-A8
 +endchoice
 +
 +config OPROFILE_ARM11_CORE
   bool
 
 -endif
 +endif # INSTRUMENTATION

Do you need so many KConfig entries??
  config VECTORS_BASE
   hex
 diff --git a/arch/arm/oprofile/Makefile b/arch/arm/oprofile/Makefile
 index 88e31f5..fc2bc02 100644
 --- a/arch/arm/oprofile/Makefile
 +++ b/arch/arm/oprofile/Makefile
 @@ -8,6 +8,7 @@ DRIVER_OBJS = $(addprefix ../../../drivers/oprofile/, \
 
  oprofile-y   := $(DRIVER_OBJS) common.o backtrace.o
  oprofile-$(CONFIG_CPU_XSCALE)+= op_model_xscale.o
 +oprofile-$(CONFIG_OPROFILE_OMAP_GPTIMER) += op_model_omap_gptimer.o
  oprofile-$(CONFIG_OPROFILE_ARM11_CORE)   += op_model_arm11_core.o
  oprofile-$(CONFIG_OPROFILE_ARMV6)+= op_model_v6.o
  oprofile-$(CONFIG_OPROFILE_MPCORE)   += op_model_mpcore.o
 diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
 index 3fcd752..9eb2b9b 100644
 --- a/arch/arm/oprofile/common.c
 +++ b/arch/arm/oprofile/common.c
 @@ -133,6 +133,10 @@ int __init oprofile_arch_init(struct oprofile_operations 
 *ops)
 
   ops-backtrace = arm_backtrace;
 
 +#ifdef CONFIG_OPROFILE_OMAP_GPTIMER
 + spec = op_omap_gptimer_spec;
 +#endif
 +
  #ifdef CONFIG_CPU_XSCALE
   spec = op_xscale_spec;
  #endif
 diff --git a/arch/arm/oprofile/op_arm_model.h 
 b/arch/arm/oprofile/op_arm_model.h
 index 8c4e4f6..55f22e4 100644
 --- a/arch/arm/oprofile/op_arm_model.h
 +++ b/arch/arm/oprofile/op_arm_model.h
 @@ -24,6 +24,7 @@ struct op_arm_model_spec {
  extern struct op_arm_model_spec op_xscale_spec;
  #endif
 
 +extern struct op_arm_model_spec op_omap_gptimer_spec;
  extern struct op_arm_model_spec

Re: [PATCH] OMAP GPTimer for OProfile(Errata#628216)

2010-04-01 Thread Siarhei Siamashka

On Thursday 01 April 2010 18:24:08 ext Manjunatha GK wrote:
 From: DebBarma, Tarun Kanti tarun.ka...@ti.com

 [ARM Cortex-A8 Errata 628216]
 If a Perf Counter OVFL occurs simultaneously with an update to a CP14 or
 CP15 register, the OVFL status can be lost.

 In order to workaround problem in Cortex-A8 Performance Counter, OMAP
 GPTIMER is used by OProfile.

Thanks for digging this up. But even though GPTIMER has a lower overhead,
there is actually a better (more portable) fix which is on the way into
mainline kernel:
http://marc.info/?l=oprofile-listm=126754919315010w=2

Samples collection frequency can be adjusted by another patch (the default
128Hz used on most ARM boards/devices is way too low).

oprofile kernel module can be loaded with 'timer=1' parameter to override
the use of buggy Cortex-A8 PMU.

-- 
Best regards,
Siarhei Siamashka
--
To unsubscribe from this list: send the line unsubscribe 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: Fix for bus width which improves SD card's peformance.

2010-04-01 Thread Madhusudhan



 -Original Message-
 From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com]
 Sent: Thursday, April 01, 2010 1:32 AM
 To: Madhusudhan
 Cc: Vimal Singh; t...@atomide.com; svenk...@ti.com; linux-
 o...@vger.kernel.org; linux-ker...@vger.kernel.org;
 jarkko.lavi...@nokia.com
 Subject: Re: [PATCH-V2] OMAP: Fix for bus width which improves SD card's
 peformance.
 
 On Wed, Mar 31, 2010 at 10:07 PM, Madhusudhan madhu...@ti.com wrote:
 
 
  -Original Message-
  From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com]
  Sent: Wednesday, March 31, 2010 2:03 AM
  To: Vimal Singh
  Cc: Madhusudhan; t...@atomide.com; svenk...@ti.com; linux-
  o...@vger.kernel.org; linux-ker...@vger.kernel.org;
  jarkko.lavi...@nokia.com
  Subject: Re: [PATCH-V2] OMAP: Fix for bus width which improves SD
 card's
  peformance.
 
  Sorry for that and here's the Updated one.
 
  From: Kishore Kadiyala kishore.kadiy...@ti.com
 
  This patch improves low speeds for SD cards.
  OMAP-MMC controller's can support maximum bus width of '8'.
  when bus width is mentioned as 8 in controller data,the SD
  stack will check whether bus width is 4 and if not it will
  set bus width to 1 and there by degrading performance.
  This patch fixes the issue and improves the performance of
  SD cards.
 
  Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
  Signed-off-by: Venkatraman S svenk...@ti.com
  Acked-by: Madhusudhan Chikkature madhu...@ti.com
 
  ---
  In V2 : Appended Signed-off by Venkat and Ack by Madhu
 
   Here are my experiment numbers, on a Class 6 SDHC card:
   Read peformance is increased by 220%
   Write Performance is increased by 52%
 
   drivers/mmc/host/omap_hsmmc.c |    2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)
 
  diff --git a/drivers/mmc/host/omap_hsmmc.c
 b/drivers/mmc/host/omap_hsmmc.c
  index 83f0aff..8c97c22 100644
  --- a/drivers/mmc/host/omap_hsmmc.c
  +++ b/drivers/mmc/host/omap_hsmmc.c
  @@ -2092,7 +2092,7 @@ static int __init omap_hsmmc_probe(struct
                     MMC_CAP_WAIT_WHILE_BUSY;
 
        if (mmc_slot(host).wires = 8)
  -             mmc-caps |= MMC_CAP_8_BIT_DATA;
  +             mmc-caps |= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA);
        else if (mmc_slot(host).wires = 4)
                mmc-caps |= MMC_CAP_4_BIT_DATA;
 
  Kishore,
 
  Since this patch is not yet pushed it makes sense to fix the readability
  issue.
 
  Since 8-bit is the max how about:
 
          if (mmc_slot(host).wires == 8)
                  mmc-caps |= MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA;
          if (mmc_slot(host).wires == 4)
                  mmc-caps |= MMC_CAP_4_BIT_DATA;
 
 Madhu,
 
 In the above snippet, it checks whether wires are 8 or  4 and if not
 neither set's  capability  to 1.
 Does it make sense to check whether the  wires are 8,4,1 and if not
 any[8,4,1] throw error and come out.
 
It is good enough to just check for 8-bit and 4-bit. The 1-bit does not need
any explicit check since it is default.

Regards,
Madhu

 Regards,
 Kishore
  This would be little easy to read the code.
 
  Can you please repost the patch??
 
  Regards,
  Madhu
 
  --
  1.6.3.3
 
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] [STAGING] Synaptic : Remove non-standard multi touch support

2010-04-01 Thread Pavel Machek

On Thu 2010-04-01 18:46:19, Hemanth V wrote:
 From dbd87fbdf5be92351f81030a133e57d96634a3d3 Mon Sep 17 00:00:00 2001 From: 
 Hemanth V heman...@ti.com
 Date: Thu, 1 Apr 2010 17:26:49 +0530
 Subject: [PATCH] Remove non-standard multi touch support
 
 
 Signed-off-by: Hemanth V heman...@ti.com

ack.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] [STAGING] Synaptic : Add threaded IRQ support

2010-04-01 Thread Pavel Machek

On Thu 2010-04-01 18:46:27, Hemanth V wrote:
 From d04802248f813fea756e2714805bb61c86397a56 Mon Sep 17 00:00:00 2001 From: 
 Hemanth V heman...@ti.com
 Date: Thu, 1 Apr 2010 17:27:39 +0530
 Subject: [PATCH] Add threaded IRQ support
 
 
 Signed-off-by: Hemanth V heman...@ti.com

Ack.

And wow, I did not expect it to be as simple.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] [STAGING] Synaptic Touchscreen Driver

2010-04-01 Thread Pavel Machek

On Thu 2010-04-01 18:46:12, Hemanth V wrote:
 This series of 2 patches are for the synaptic
 touchscreen driver in staging. This adds
 support for threaded irq and some cleanup.

Thanks!

You probably want to post full source of syn*_i2c_rmi.c here, so that
it gets review, and may be moved to drivers/input in 2.6.35...

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [RFC/PATCHv2 2/4] arm: omap: gpio: implement set_debounce method

On Thu, Apr 01, 2010 at 04:11:27PM +0300, Jani Nikula wrote:
 On Thu, Apr 1, 2010 at 12:32, Felipe Balbi felipe.ba...@nokia.com wrote:
  On Thu, Apr 01, 2010 at 11:29:16AM +0200, ext Grazvydas Ignotas wrote:
 
  There is also an issue if somebody calls _set_gpio_debounce(bank, 1,
  310) and _set_gpio_debounce(bank, 2, 620), the second call will
  override debounce setting of GPIO1 (as it's shared by the whole bank).
  This might be not what the user intended, would be useful to detect
  this and warn the user.
 
  good point. As this is RFC, I'll wait until everybody comments.
 
 Hi Felipe -
 
 You might want to have a look at [1] on irq debouncing. The hardware
 support for debouncing varies (bank/gpio restrictions, debounce
 timeouts, no support at all, what else?) so how can the users of this
 interface rely on debouncing? What are the guarantees? AFAICS e.g.
 gpio-keys would have to do software debouncing anyway.
 
 [1] http://lkml.org/lkml/2008/9/24/325

I think we could provide a generic software debouncing mechanism, sure,
but if the hardware supports it, why not using ?

I believe Dave's approach is really good, this is just another way to do
it. The difference with this patch is that we have control over the
debouncing time.

-- 
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] Disable the non working eMMC on Zoom2/3

2010-04-01 Thread Madhusudhan



 -Original Message-
 From: Ghorai, Sukumar [mailto:s-gho...@ti.com]
 Sent: Wednesday, March 31, 2010 11:03 PM
 To: Chikkature Rajashekar, Madhusudhan; t...@atomide.com
 Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org
 Subject: RE: [PATCH] Disable the non working eMMC on Zoom2/3
 
 Madhu,
 
  -Original Message-
  From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
  ow...@vger.kernel.org] On Behalf Of Chikkature Rajashekar, Madhusudhan
  Sent: 2010-04-01 05:56
  To: t...@atomide.com
  Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org
  Subject: [PATCH] Disable the non working eMMC on Zoom2/3
 
  From: Madhusudhan Chikkature madhu...@ti.com
  Date: Wed, 31 Mar 2010 12:29:19 -0400
  Subject: [PATCH] Zoom2/3: Disable MMC
 
  The eMMC on Zoom2/3 seems to have a lower EXT_CSD Rev.This causes the
  writes to fail since the card size is not detected correctly by the MMC
  core. Disable the MMC2 support for Zoom2/3.
 
 
 [Ghorai] Please let us know the EXT_CSD Rev you see in zoom3 and the exact
 problem. Because we never face any issue for eMMC in ZOOM3. Because we
 have the same eMMC device in 3630-SDP and could have the same problem.


On Zoom3 the EXT_CSD Rev reported by eMMC is zero. See the log attached.

Hence the failures which are reported by people on the list. I had already
bought this problem up on the list previously and was discussed, right?
From the log you can also see that a 16GB device is detected as a 1GB.

Regards,
Madhu

 
  Signed-off-by: Madhusudhan Chikkature madhu...@ti.com
  ---
   arch/arm/mach-omap2/board-zoom-peripherals.c |   30 ---
 --
  -
   1 files changed, 0 insertions(+), 30 deletions(-)
 
  diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
  b/arch/arm/mach-omap2/board-zoom-peripherals.c
  index 6b39849..ac791d2 100644
  --- a/arch/arm/mach-omap2/board-zoom-peripherals.c
  +++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
  @@ -102,10 +102,6 @@ static struct regulator_consumer_supply
  zoom_vsim_supply = {
  .supply = vmmc_aux,
   };
 
  -static struct regulator_consumer_supply zoom_vmmc2_supply = {
  -   .supply = vmmc,
  -};
  -
   /* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
   static struct regulator_init_data zoom_vmmc1 = {
  .constraints = {
  @@ -121,21 +117,6 @@ static struct regulator_init_data zoom_vmmc1 = {
  .consumer_supplies  = zoom_vmmc1_supply,
   };
 
  -/* VMMC2 for MMC2 card */
  -static struct regulator_init_data zoom_vmmc2 = {
  -   .constraints = {
  -   .min_uV = 185,
  -   .max_uV = 185,
  -   .apply_uV   = true,
  -   .valid_modes_mask   = REGULATOR_MODE_NORMAL
  -   | REGULATOR_MODE_STANDBY,
  -   .valid_ops_mask = REGULATOR_CHANGE_MODE
  -   | REGULATOR_CHANGE_STATUS,
  -   },
  -   .num_consumer_supplies  = 1,
  -   .consumer_supplies  = zoom_vmmc2_supply,
  -};
  -
   /* VSIM for OMAP VDD_MMC1A (i/o for DAT4..DAT7) */
   static struct regulator_init_data zoom_vsim = {
  .constraints = {
  @@ -159,15 +140,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
  .gpio_wp= -EINVAL,
  .power_saving   = true,
  },
  -   {
  -   .name   = internal,
  -   .mmc= 2,
  -   .wires  = 8,
  -   .gpio_cd= -EINVAL,
  -   .gpio_wp= -EINVAL,
  -   .nonremovable   = true,
  -   .power_saving   = true,
  -   },
  {}  /* Terminator */
   };
 
  @@ -183,7 +155,6 @@ static int zoom_twl_gpio_setup(struct device *dev,
  */
  zoom_vmmc1_supply.dev = mmc[0].dev;
  zoom_vsim_supply.dev = mmc[0].dev;
  -   zoom_vmmc2_supply.dev = mmc[1].dev;
 
  return 0;
   }
  @@ -241,7 +212,6 @@ static struct twl4030_platform_data zoom_twldata = {
  .keypad = zoom_kp_twl4030_data,
  .codec  = zoom_codec_data,
  .vmmc1  = zoom_vmmc1,
  -   .vmmc2  = zoom_vmmc2,
  .vsim   = zoom_vsim,
 
   };
  --
  1.6.3.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
dhcp 0x8000 madhu/uImagelo
LAN9x18 (0x9221) detected.
Read mac address: 00:08:EE:03:2A:5B
start Auto negotiation... (take ~2sec)
Auto negotiation complete, 100BaseTX, full duplex
BOOTP broadcast 1
*** Unhandled DHCP Option in OFFER/ACK: 43
*** Unhandled DHCP Option in OFFER/ACK: 44
*** Unhandled DHCP Option in OFFER/ACK: 46
*** Unhandled DHCP Option in OFFER/ACK: 43
*** Unhandled DHCP Option in OFFER/ACK: 44
*** Unhandled DHCP Option in OFFER/ACK: 46
DHCP client bound to address 128.247.79.222
TFTP from server 128.247.75.101; our IP address is 128.247.79.222; sending 
through gateway

Re: [RFC/PATCHv2 2/4] arm: omap: gpio: implement set_debounce method

2010-04-01 Thread Mark Brown

On Thu, Apr 01, 2010 at 07:42:50PM +0300, Felipe Balbi wrote:
 On Thu, Apr 01, 2010 at 04:11:27PM +0300, Jani Nikula wrote:

  You might want to have a look at [1] on irq debouncing. The hardware
  support for debouncing varies (bank/gpio restrictions, debounce
  timeouts, no support at all, what else?) so how can the users of this
  interface rely on debouncing? What are the guarantees? AFAICS e.g.
  gpio-keys would have to do software debouncing anyway.

 I think we could provide a generic software debouncing mechanism, sure,
 but if the hardware supports it, why not using ?

I tend to agree here, especially for GPIOs on slow buses like I2C or
which may be used as wake sources.  I guess ideally we want something
like the LEDs do with blinking where we use the hardware feature if
present and suitable but fall back on software emulation transparently
if it's not available or can't be configured appropriately.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCHv2 2/4] arm: omap: gpio: implement set_debounce method