Re: [PATCH] mfd: Add PWM1 and PWM2 support to twl6030-pwm

[Hemanth V]

> From: Hemanth V 
> Date: Fri, 26 Aug 2011 10:49:29 +0530
> Subject: [PATCH] Add PWM1 and PWM2 support to twl6030-pwm driver

Samuel, any comments on this patch.

Thanks
Hemanth

>
> This patch adds support for PWM1/PWM2. TWL6030 PWM driver also
> supports Indicator LED PWM. Function pointers are defined for
> for init, enable, disable and configuration for both Indicator LED
> PWM (led_pwm) and PWM1/PWM2 (std_pwm)
>
> Tested-by: Tomi Valkeinen 
> Signed-off-by: Hemanth V 
> ---
>  drivers/mfd/twl6030-pwm.c |  324 ++--
>  1 files changed, 309 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/mfd/twl6030-pwm.c b/drivers/mfd/twl6030-pwm.c
> index e8fee14..8d9c3f5 100644
> --- a/drivers/mfd/twl6030-pwm.c
> +++ b/drivers/mfd/twl6030-pwm.c
> @@ -5,6 +5,9 @@
>   * Copyright (C) 2010 Texas Instruments
>   * Author: Hemanth V 
>   *
> + * Added support for PWM1, PWM2
> + * Hemanth V 
> + *
>   * This program is free software; you can redistribute it and/or modify it
>   * under the terms of the GNU General Public License version 2 as published 
> by
>   * the Free Software Foundation.
> @@ -36,7 +39,9 @@
>  #define PWM_CTRL2_CURR_02(2 << 4)
>
>  /* LED supply source */
> +#define PWM_CTRL2_SRC_VBUS   (0 << 2)
>  #define PWM_CTRL2_SRC_VAC(1 << 2)
> +#define PWM_CTRL2_SRC_EXT(2 << 2)
>
>  /* LED modes */
>  #define PWM_CTRL2_MODE_HW(0 << 0)
> @@ -45,12 +50,53 @@
>
>  #define PWM_CTRL2_MODE_MASK  0x3
>
> +/* PWMs supported by driver */
> +#define PWM_ID_LED   1
> +#define PWM_ID_PWM1  2
> +#define PWM_ID_PWM2  3
> +
> +#define LED_PWM1ON   0x00
> +#define LED_PWM1OFF  0x01
> +#define LED_PWM2ON   0x03
> +#define LED_PWM2OFF  0x04
> +#define TWL6030_TOGGLE3  0x92
> +#define PWMSTATUS2   0x94
> +
> +/* Defines for TOGGLE3 register */
> +#define PWM2EN   (1 << 5)
> +#define PWM2S(1 << 4)
> +#define PWM2R(1 << 3)
> +#define PWM1EN   (1 << 2)
> +#define PWM1S(1 << 1)
> +#define PWM1R(1 << 0)
> +
> +/* Defines for PWMSTATUS2 register */
> +#define PWM1_CLK_EN  (1 << 1)
> +#define PWM2_CLK_EN  (1 << 3)
> +#define  TRUE1
> +#define  FALSE   0
> +
> +static DEFINE_MUTEX(pwm_lock);
> +static LIST_HEAD(pwm_list);
> +
> +struct pwm_device;
> +
> +struct pwm_ops {
> + int (*config)(struct pwm_device *, int, int);
> + int (*enable)(struct pwm_device *);
> + void(*disable)(struct pwm_device *);
> + int (*init)(struct pwm_device *);
> +};
> +
>  struct pwm_device {
> - const char *label;
> - unsigned int pwm_id;
> + struct list_headnode;
> + const char  *label;
> + unsigned intpwm_id;
> + unsigned intuse_count;
> + struct pwm_ops  *ops;
>  };
>
> -int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
> +int led_pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
>  {
>   u8 duty_cycle;
>   int ret;
> @@ -69,9 +115,8 @@ int pwm_config(struct pwm_device *pwm, int duty_ns, int 
> period_ns)
>   }
>   return 0;
>  }
> -EXPORT_SYMBOL(pwm_config);
>
> -int pwm_enable(struct pwm_device *pwm)
> +int led_pwm_enable(struct pwm_device *pwm)
>  {
>   u8 val;
>   int ret;
> @@ -95,9 +140,8 @@ int pwm_enable(struct pwm_device *pwm)
>   twl_i2c_read_u8(TWL6030_MODULE_ID1, &val, LED_PWM_CTRL2);
>   return 0;
>  }
> -EXPORT_SYMBOL(pwm_enable);
>
> -void pwm_disable(struct pwm_device *pwm)
> +void led_pwm_disable(struct pwm_device *pwm)
>  {
>   u8 val;
>   int ret;
> @@ -120,37 +164,284 @@ void pwm_disable(struct pwm_device *pwm)
>   }
>   return;
>  }
> -EXPORT_SYMBOL(pwm_disable);
>
> -struct pwm_device *pwm_request(int pwm_id, const char *label)
> +int led_pwm_init(struct pwm_device *pwm)
>  {
>   u8 val;
>   int ret;
> +
> + val = PWM_CTRL2_DIS_PD | PWM_CTRL2_CURR_02 | PWM_CTRL2_SRC_VBUS |
> + PWM_CTRL2_MODE_HW;
> +
> + ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, val, LED_PWM_CTRL2);
> +
> + return ret;
> +}
> +
> +static struct pwm_ops pwm_led = {
> + .config = led_pwm_config,
> + .enable = led_pwm_enable,
> + .disable = led_pwm_disable,
> + .init = led_pwm_i

[PATCH] mfd: Add PWM1 and PWM2 support to twl6030-pwm

[Hemanth V]

From: Hemanth V 
Date: Fri, 26 Aug 2011 10:49:29 +0530
Subject: [PATCH] Add PWM1 and PWM2 support to twl6030-pwm driver

This patch adds support for PWM1/PWM2. TWL6030 PWM driver also
supports Indicator LED PWM. Function pointers are defined for
for init, enable, disable and configuration for both Indicator LED
PWM (led_pwm) and PWM1/PWM2 (std_pwm)

Tested-by: Tomi Valkeinen 
Signed-off-by: Hemanth V 
---
 drivers/mfd/twl6030-pwm.c |  324 ++--
 1 files changed, 309 insertions(+), 15 deletions(-)

diff --git a/drivers/mfd/twl6030-pwm.c b/drivers/mfd/twl6030-pwm.c
index e8fee14..8d9c3f5 100644
--- a/drivers/mfd/twl6030-pwm.c
+++ b/drivers/mfd/twl6030-pwm.c
@@ -5,6 +5,9 @@
  * Copyright (C) 2010 Texas Instruments
  * Author: Hemanth V 
  *
+ * Added support for PWM1, PWM2
+ * Hemanth V 
+ *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License version 2 as published by
  * the Free Software Foundation.
@@ -36,7 +39,9 @@
 #define PWM_CTRL2_CURR_02  (2 << 4)

 /* LED supply source */
+#define PWM_CTRL2_SRC_VBUS (0 << 2)
 #define PWM_CTRL2_SRC_VAC  (1 << 2)
+#define PWM_CTRL2_SRC_EXT  (2 << 2)

 /* LED modes */
 #define PWM_CTRL2_MODE_HW  (0 << 0)
@@ -45,12 +50,53 @@

 #define PWM_CTRL2_MODE_MASK0x3

+/* PWMs supported by driver */
+#define PWM_ID_LED 1
+#define PWM_ID_PWM12
+#define PWM_ID_PWM23
+
+#define LED_PWM1ON 0x00
+#define LED_PWM1OFF0x01
+#define LED_PWM2ON 0x03
+#define LED_PWM2OFF0x04
+#define TWL6030_TOGGLE30x92
+#define PWMSTATUS2 0x94
+
+/* Defines for TOGGLE3 register */
+#define PWM2EN (1 << 5)
+#define PWM2S  (1 << 4)
+#define PWM2R  (1 << 3)
+#define PWM1EN (1 << 2)
+#define PWM1S  (1 << 1)
+#define PWM1R  (1 << 0)
+
+/* Defines for PWMSTATUS2 register */
+#define PWM1_CLK_EN(1 << 1)
+#define PWM2_CLK_EN(1 << 3)
+#defineTRUE1
+#defineFALSE   0
+
+static DEFINE_MUTEX(pwm_lock);
+static LIST_HEAD(pwm_list);
+
+struct pwm_device;
+
+struct pwm_ops {
+   int (*config)(struct pwm_device *, int, int);
+   int (*enable)(struct pwm_device *);
+   void(*disable)(struct pwm_device *);
+   int (*init)(struct pwm_device *);
+};
+
 struct pwm_device {
-   const char *label;
-   unsigned int pwm_id;
+   struct list_headnode;
+   const char  *label;
+   unsigned intpwm_id;
+   unsigned intuse_count;
+   struct pwm_ops  *ops;
 };

-int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
+int led_pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
 {
u8 duty_cycle;
int ret;
@@ -69,9 +115,8 @@ int pwm_config(struct pwm_device *pwm, int duty_ns, int 
period_ns)
}
return 0;
 }
-EXPORT_SYMBOL(pwm_config);

-int pwm_enable(struct pwm_device *pwm)
+int led_pwm_enable(struct pwm_device *pwm)
 {
u8 val;
int ret;
@@ -95,9 +140,8 @@ int pwm_enable(struct pwm_device *pwm)
twl_i2c_read_u8(TWL6030_MODULE_ID1, &val, LED_PWM_CTRL2);
return 0;
 }
-EXPORT_SYMBOL(pwm_enable);

-void pwm_disable(struct pwm_device *pwm)
+void led_pwm_disable(struct pwm_device *pwm)
 {
u8 val;
int ret;
@@ -120,37 +164,284 @@ void pwm_disable(struct pwm_device *pwm)
}
return;
 }
-EXPORT_SYMBOL(pwm_disable);

-struct pwm_device *pwm_request(int pwm_id, const char *label)
+int led_pwm_init(struct pwm_device *pwm)
 {
u8 val;
int ret;
+
+   val = PWM_CTRL2_DIS_PD | PWM_CTRL2_CURR_02 | PWM_CTRL2_SRC_VBUS |
+   PWM_CTRL2_MODE_HW;
+
+   ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, val, LED_PWM_CTRL2);
+
+   return ret;
+}
+
+static struct pwm_ops pwm_led = {
+   .config = led_pwm_config,
+   .enable = led_pwm_enable,
+   .disable = led_pwm_disable,
+   .init = led_pwm_init,
+};
+
+int std_pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
+{
+   int ret = 0, level, pwm_id, reg;
+
+   level = (duty_ns * PWM_CTRL1_MAX) / period_ns;
+   pwm_id = pwm->pwm_id;
+
+   if (pwm_id == PWM_ID_PWM1)
+   reg = LED_PWM1ON;
+   else
+   reg = LED_PWM2ON;
+
+   if (level > 1) {
+   if (level == 255)
+   level = 0x7F;
+   else
+   level = (~(level/2)) & 0x7F;
+
+   ret = twl_i2c_write_u8(TWL_MODULE_PWM, level, reg);
+   }
+
+   return ret;
+}
+
+void std_pwm_disable(struct pwm_device *pwm)
+{
+
+   int ret, pwm_id;
+   bool pwm1_en

Re: I2C Touchscreen OMAP OOPS

[Hemanth V]

- Original Message - 
From: "David Lynch Jr." 

To: "Linux OMAP Mailing List" 
Cc: ; 
Sent: Tuesday, January 04, 2011 12:26 PM
Subject: I2C Touchscreen OMAP OOPS



I am trying to get a vendor provided I2C touchscreen driver working with
android froyo with a 2.6.32 linux kernel for a client. I have fixed alot
of things and I am down to one serious problem remaining.

The driver is oops'ing reading the touchscreen data in omap_i2c_xfer.
I tried to figure out what was going on by printk tracing omap_i2c_xfer,
but the problem goes away - mostly with a few judiciously inserted
printk's

I tried backporting the 2.6.37 i2c-omap code, but that does nto change
behavior.

What is "scheduling while atomic" ? and what am I trying to look for ?
Is the root of this problem in the touchscreen driver ? omap_i2c or
should I be looking elsewhere ?


Looks like your touchscreen driver is trying to do i2c transfer in IRQ 
context,

hence the error.




r...@beagleboard:~# evtest /dev/input/event1
Input driver version is 1.0.0evdev.c(EVIOCGBIT): Suspicious buffer size
511, limiting output to 64 bytes. See
http://userweb.kernel.org/~dtor/eviocgbit-bug.html

Input device ID: bus 0x18 vendor 0xdead product 0x534 version 0x1
Input device name: "sitronix_ts"
Supported events:
 Event type 0 (Sync)
 Event type 1 (Key)
   Event code 330 (Touch)
 Event type 3 (Absolute)
   Event code 0 (X)
 Value  0
 Min0
 Max  480
   Event code 1 (Y)
 Value  0
 Min0
 Max  256
Testing ... (interrupt to exit)
BUG: scheduling while atomic: swapper/0/0x00010003
Unable to handle kernel NULL pointer dereference at virtual address

pgd = c0004000
[] *pgd=
Internal error: Oops: 8007 [#1] PREEMPT
last sysfs
file: 
/sys/devices/platform/mmci-omap-hs.0/mmc_host/mmc0/mmc0:/block/mmcblk0/size

Modules linked in:
CPU: 0Not tainted  (2.6.32 #98)
PC is at 0x0
LR is at enqueue_task+0x28/0x34
pc : [<>]lr : []psr: 2193
sp : c04dbc30  ip : 0016  fp : c04dbc44
r10:   r9 :   r8 : 0002
r7 :   r6 :   r5 : c04e8cc8  r4 : c04dcfa8
r3 :   r2 : 0001  r1 : c04dcfa8  r0 : c04e8cc8
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 8c8c8019  DAC: 0017

LR: 0xc005aa2c:
aa2c  e8bd8800 e92d4800 e59100c4 e28db004 e352 03ac 13a0
e8bd8800
aa4c  e92d48f0 e1c040d0 e1a06002 e1a07003 e0566004 e0c77005 e28db014
e1a021a6
aa6c  e1a031c7 e1822e87 e0944002 e0a55003 e1c040f0 e8bd88f0 e352
e92d48d8
aa8c  e1a04001 e28db014 11c165d8 11c168f8 e5943028 e1a01004 e5933004
e12fff33
aaac  e3a03001 e584304c e8bd88d8 e92d4b78 e2525000 e28db01c e1a06000
e1a04001
aacc  0a10 e1c127d0 e1921003 0a08 e1c485d8 e2840078 e0582002
e0c93003
aaec  ebd6 e3a02000 e3a03000 e1c427f0 ea04 e59f3030 e2840090
e5932000
ab0c  e3a03000 ebcd e5943028 e1a6 e1a01004 e1a02005 e5933008
e12fff33

SP: 0xc04dbbb0:
bbb0  000f 0010  30303033 0031  

bbd0    c04dbc1c   c0034bf0 c04e8cc8
c04dcfa8
bbf0  0001  c04dcfa8 c04e8cc8   0002

bc10   c04dbc44 0016 c04dbc30 c005aaac  2193

bc30   c04e8cc8  c04da000 c04dbc54 c005ab70 
c04dcfa8
bc50  c04dbc7c c005e9b8 c044d812 8193 c05257f0 cf91e010 0001
cf91e01c
bc70  0001 0003 c04dbca4 c005aef0  0113 1004

bc90  0039 0001 601f c04e92d4 c04dbcbc c005cf14 
35303135

FP: 0xc04dbbc4:
bbc4       c04dbc1c 

bbe4  c0034bf0 c04e8cc8 c04dcfa8 0001  c04dcfa8 c04e8cc8

bc04   0002   c04dbc44 0016 c04dbc30
c005aaac
bc24   2193   c04e8cc8  c04da000
c04dbc54
bc44  c005ab70  c04dcfa8 c04dbc7c c005e9b8 c044d812 8193
c05257f0
bc64  cf91e010 0001 cf91e01c 0001 0003 c04dbca4 c005aef0

bc84  0113 1004  0039 0001 601f c04e92d4
c04dbcbc
bca4  c005cf14  35303135 63303536 cf91e000 c04dbdec c024626c
cf85bb00

R0: 0xc04e8c48:
8c48        

8c68      000f4240 000f4240 000f4240
004c4b40
8c88  004c4b40 000f4240 0003d090 0003d090 0001 c04e8c9c c04e8c9c
000f4240
8ca8  000e7ef0 0001 c04e8cb0 c04e8cb0 cc901b18 c0525278 0004
0001
8cc8    0070 0176 018b 013b 

8ce8   268a 9fd5    

8d08    cd9c987c 0008   c04e8d20
c04e8d20
8d28       c04e8cc8 


R1: 0xc04dcf28:
cf28  c01bf6e4 c037cf08 c01bf70c c037cf10 c01bf748 c037cf18 c01da958
c037cf20
cf48  

Re: [PATCH 1/3] omap4: Add platform changes for Ambient Light sensor

[Hemanth V]

- Original Message - 
From: "Hemanth V" 

To: 
Sent: Thursday, December 02, 2010 12:59 PM
Subject: [PATCH 1/3] omap4: Add platform changes for Ambient Light sensor



From 10f5f9f918e197f4052ac66b4e4cfb4b72646878 Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Wed, 1 Dec 2010 16:28:51 +0530
Subject: [PATCH] omap4: Add platform changes for Ambient Light sensor

Register BH1780GLI Ambient light sensor, which is an I2C device
for 4430SDP board.


Tony, would you be pulling these patches for the next merge window.

Thanks
Hemanth



Signed-off-by: Hemanth V 
---
BH1780GLI Driver is part of mainline kernel

arch/arm/mach-omap2/board-4430sdp.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c

index 49b5a7b..d8ef903 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -465,6 +465,9 @@ static struct i2c_board_info __initdata 
sdp4430_i2c_3_boardinfo[] = {

 {
 I2C_BOARD_INFO("tmp105", 0x48),
 },
+ {
+ I2C_BOARD_INFO("bh1780", 0x29),
+ },
};
static struct i2c_board_info __initdata sdp4430_i2c_4_boardinfo[] = {
 {
--
1.5.4.3



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



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

[RESEND] [PATCH 3/3] omap4: Platform changes for CMA3000 Accelerometer driver

[Hemanth V]

Pl ignore the earlier patch, which seems to have rebasing issues.

Thanks
Hemanth

>From 42cb400c1bd3878977bc8fd416c9c39f81bed674 Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Thu, 2 Dec 2010 12:44:19 +0530
Subject: [PATCH] omap4: Platform changes for CMA3000 Accelerometer driver

Update 4430 SDP board file with platform data for accelerometer driver

Signed-off-by: Hemanth V 
---
CMA3000 Driver is queued up for 2.6.38 merge window

 arch/arm/mach-omap2/board-4430sdp.c |   30 ++
 1 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index ea56c30..6bda335 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #include 
 #include 
@@ -45,6 +47,7 @@
 #define ETH_KS8851_POWER_ON48
 #define ETH_KS8851_QUART   138
 #define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO   184
+#define OMAP4_CMA3000ACCL_GPIO 186
 #define OMAP4_SFH7741_ENABLE_GPIO  188

 static struct gpio_led sdp4430_gpio_leds[] = {
@@ -477,6 +480,27 @@ static struct twl4030_platform_data sdp4430_twldata = {
.vaux3  = &sdp4430_vaux3,
 };

+static struct cma3000_platform_data cma3000_platform_data = {
+   .fuzz_x = 25,
+   .fuzz_y = 25,
+   .fuzz_z = 25,
+   .g_range= CMARANGE_8G,
+   .mode   = CMAMODE_MOTDET,
+   .mdthr  = 0x8,
+   .mdfftmr= 0x33,
+   .ffthr  = 0x8,
+   .irqflags   = IRQF_TRIGGER_HIGH,
+};
+
+static void omap_cma3000accl_init(void)
+{
+   if (gpio_request(OMAP4_CMA3000ACCL_GPIO, "Accelerometer") < 0) {
+   pr_err("Accelerometer GPIO request failed\n");
+   return;
+   }
+   gpio_direction_input(OMAP4_CMA3000ACCL_GPIO);
+}
+
 static struct i2c_board_info __initdata sdp4430_i2c_boardinfo[] = {
{
I2C_BOARD_INFO("twl6030", 0x48),
@@ -497,6 +521,11 @@ static struct i2c_board_info __initdata 
sdp4430_i2c_4_boardinfo[] = {
{
I2C_BOARD_INFO("hmc5843", 0x1e),
},
+   {
+   I2C_BOARD_INFO("cma3000_d01", 0x1c),
+   .platform_data = &cma3000_platform_data,
+   .irq = OMAP_GPIO_IRQ(OMAP4_CMA3000ACCL_GPIO),
+   },
 };
 static int __init omap4_i2c_init(void)
 {
@@ -570,6 +599,7 @@ static void __init omap_4430sdp_init(void)
spi_register_board_info(sdp4430_spi_board_info,
ARRAY_SIZE(sdp4430_spi_board_info));
}
+   omap_cma3000accl_init();
 }

 static void __init omap_4430sdp_map_io(void)
-- 
1.5.4.3




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

[PATCH 3/3] omap4: Platform changes for CMA3000 Accelerometer driver

[Hemanth V]

>From 0ce7ea442ffbe89f563baa993669a4216b2ccffa Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Thu, 2 Dec 2010 12:44:19 +0530
Subject: [PATCH] omap4: Platform changes for CMA3000 Accelerometer driver

Update 4430SDP board file with platform data for accelerometer driver

Signed-off-by: Hemanth V 
---
CMA3000 Driver is queued up for 2.6.38 merge window

 arch/arm/mach-omap2/board-4430sdp.c |   30 ++
 1 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index ea56c30..c336673 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #include 
 #include 
@@ -45,6 +47,7 @@
 #define ETH_KS8851_POWER_ON48
 #define ETH_KS8851_QUART   138
 #define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO   184
+#define OMAP4_CMA3000ACCL_GPIO 186
 #define OMAP4_SFH7741_ENABLE_GPIO  188

 static struct gpio_led sdp4430_gpio_leds[] = {
@@ -477,6 +480,27 @@ static struct twl4030_platform_data sdp4430_twldata = {
.vaux3  = &sdp4430_vaux3,
 };

+static struct cma3000_platform_data cma3000_platform_data = {
+   .fuzz_x = 25,
+   .fuzz_y = 25,
+   .fuzz_z = 25,
+   .g_range= CMARANGE_8G,
+   .mode   = CMAMODE_MOTDET,
+   .mdthr  = 0x8,
+   .mdfftmr= 0x33,
+   .ffthr  = 0x8,
+   .irqflags   = IRQF_TRIGGER_HIGH,
+};
+
+static void omap_cma3000accl_init(void)
+{
+   if (gpio_request(OMAP4_CMA3000ACCL_GPIO, "Accelerometer") < 0) {
+   pr_err("Accelerometer GPIO request failed\n");
+   return;
+   }
+   gpio_direction_input(OMAP4_CMA3000ACCL_GPIO);
+}
+
 static struct i2c_board_info __initdata sdp4430_i2c_boardinfo[] = {
{
I2C_BOARD_INFO("twl6030", 0x48),
@@ -497,6 +521,11 @@ static struct i2c_board_info __initdata 
sdp4430_i2c_4_boardinfo[] = {
{
I2C_BOARD_INFO("hmc5843", 0x1e),
},
+   {
+   I2C_BOARD_INFO("cma3000_d01", 0x1c),
+   .platform_data = &cma3000_platform_data,
+   .irq = OMAP_GPIO_IRQ(OMAP4_CMA3000ACCL_GPIO),
+   },
 };
 static int __init omap4_i2c_init(void)
 {
@@ -531,6 +560,7 @@ static void __init omap_sfh7741prox_init(void)
 __func__, OMAP4_SFH7741_ENABLE_GPIO, error);
gpio_free(OMAP4_SFH7741_ENABLE_GPIO);
}
+   omap_cma3000accl_init();
 }

 #ifdef CONFIG_OMAP_MUX
-- 
1.5.4.3


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

[PATCH 2/3] omap4: Add platform changes for PWM LED

[Hemanth V]

>From b90e733faa2fcbe4241dcce01c7722e77c91705f Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Wed, 1 Dec 2010 17:51:10 +0530
Subject: [PATCH] omap4: Add platform changes for PWM LED

Register TWL6030 PWM, which is used as charging LED

Signed-off-by: Hemanth V 
---
TWL6030 PWM driver is part of mainline kernel

 arch/arm/mach-omap2/board-4430sdp.c |   24 
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index d8ef903..ea56c30 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -97,6 +98,28 @@ static struct gpio_led_platform_data sdp4430_led_data = {
.num_leds   = ARRAY_SIZE(sdp4430_gpio_leds),
 };

+static struct led_pwm sdp4430_pwm_leds[] = {
+   {
+   .name   = "omap4:green:chrg",
+   .pwm_id = 1,
+   .max_brightness = 255,
+   .pwm_period_ns  = 7812500,
+   },
+};
+
+static struct led_pwm_platform_data sdp4430_pwm_data = {
+   .num_leds   = ARRAY_SIZE(sdp4430_pwm_leds),
+   .leds   = sdp4430_pwm_leds,
+};
+
+static struct platform_device sdp4430_leds_pwm = {
+   .name   = "leds_pwm",
+   .id = -1,
+   .dev= {
+   .platform_data = &sdp4430_pwm_data,
+   },
+};
+
 static int omap_prox_activate(struct device *dev)
 {
gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 1);
@@ -204,6 +227,7 @@ static struct platform_device *sdp4430_devices[] __initdata 
= {
&sdp4430_lcd_device,
&sdp4430_gpio_keys_device,
&sdp4430_leds_gpio,
+   &sdp4430_leds_pwm,
 };

 static struct omap_lcd_config sdp4430_lcd_config __initdata = {
-- 
1.5.4.3



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

[PATCH 1/3] omap4: Add platform changes for Ambient Light sensor

[Hemanth V]

>From 10f5f9f918e197f4052ac66b4e4cfb4b72646878 Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Wed, 1 Dec 2010 16:28:51 +0530
Subject: [PATCH] omap4: Add platform changes for Ambient Light sensor

Register BH1780GLI Ambient light sensor, which is an I2C device
for 4430SDP board.

Signed-off-by: Hemanth V 
---
BH1780GLI Driver is part of mainline kernel

 arch/arm/mach-omap2/board-4430sdp.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 49b5a7b..d8ef903 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -465,6 +465,9 @@ static struct i2c_board_info __initdata 
sdp4430_i2c_3_boardinfo[] = {
{
I2C_BOARD_INFO("tmp105", 0x48),
},
+   {
+   I2C_BOARD_INFO("bh1780", 0x29),
+   },
 };
 static struct i2c_board_info __initdata sdp4430_i2c_4_boardinfo[] = {
{
-- 
1.5.4.3



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

Re: PATCH V4 1/2] input: CMA3000 Accelerometer Driver

[Hemanth V]

- Original Message - 
From: "Dmitry Torokhov" 


Yep, almost there.

Hemanth, does the driver still work if you apply the patch below?


Yes works pretty well, Thanks for your efforts

Some minor changes as below required.




+struct cma3000_accl_data {
+ const struct cma3000_bus_ops *bus_ops;
+ const struct cma3000_platform_data *pdata;
+
+ struct device *dev;
+ struct input_dev *input_dev;
+
+ int bit_to_mg;
+ int irq;
+
+ int g_range;
+ u8 mode;
+
+ struct mutex mutex;


Need a comment to overcome checkpatch warning.



- pr_info("CMA3000 Accelerometer : Revision %x\n", ret);
+ data->dev = dev;
+ data->input_dev = input_dev;
+ data->bus_ops = bops;
+ data->pdata = pdata;


Need to add data->irq = irq, else exit routine will dump stack



- data->input_dev->name = "cma3000-accelerometer";
+ data->g_range = pdata->g_range;
+ if (data->g_range != CMARANGE_2G && data->g_range != CMA3000_RANGE8G) {


Need to change this to "data->g_range != CMARANGE_2G   && data->g_range != 
CMARANGE_8G "



- input_set_abs_params(data->input_dev, ABS_Z, -g_range,
- g_range, fuzz_z, 0);
- input_set_abs_params(data->input_dev, ABS_MISC, 0,
- 1, 0, 0);


We use this ABS_MISC event to report free fall.



--
To unsubscribe from this list: send the line "unsubscribe 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] input: CMA3000 Accelerometer Driver

[Hemanth V]

>From 9985dc1211ae33baa877489c26920dfd1c29bb35 Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Thu, 26 Aug 2010 17:44:48 +0530
Subject: [PATCH] input: CMA3000 Accelerometer Driver

Add support for CMA3000 Tri-axis accelerometer, which
supports Motion detect, Measurement and Free fall modes.
CMA3000 supports both I2C/SPI bus for communication, currently the
driver supports I2C based communication.

Driver reports acceleration data through input subsystem

Signed-off-by: Hemanth V 
Reviewed-by: Jonathan Cameron 
Reviewed-by: Sergio Aguirre 
Reviewed-by: Shubhrajyoti 
---
This is V4 of patch, which currently doesnot support a
sysfs interface. Discussions are ongoing to create a
standard sysfs interface for sensors under input subsystem.
This interface would be adopted by the driver subsequently.

 Documentation/input/cma3000_d0x.txt  |  115 
 drivers/input/misc/Kconfig   |   24 +++
 drivers/input/misc/Makefile  |2 +
 drivers/input/misc/cma3000_d0x.c |  334 ++
 drivers/input/misc/cma3000_d0x.h |   53 ++
 drivers/input/misc/cma3000_d0x_i2c.c |  142 ++
 include/linux/input/cma3000.h|   60 ++
 7 files changed, 730 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/input/cma3000_d0x.txt
 create mode 100644 drivers/input/misc/cma3000_d0x.c
 create mode 100644 drivers/input/misc/cma3000_d0x.h
 create mode 100644 drivers/input/misc/cma3000_d0x_i2c.c
 create mode 100644 include/linux/input/cma3000.h

diff --git a/Documentation/input/cma3000_d0x.txt 
b/Documentation/input/cma3000_d0x.txt
new file mode 100644
index 000..9cc46af
--- /dev/null
+++ b/Documentation/input/cma3000_d0x.txt
@@ -0,0 +1,115 @@
+Kernel driver for CMA3000-D0x
+
+
+Supported chips:
+* VTI CMA3000-D0x
+Datasheet:
+  CMA3000-D0X Product Family Specification 8281000A.02.pdf
+  <http://www.vti.fi/en/>
+
+Author: Hemanth V 
+
+
+Description
+---
+CMA3000 Tri-axis accelerometer supports Motion detect, Measurement and
+Free fall modes.
+
+Motion Detect Mode: Its the low power mode where interrupts are generated only
+when motion exceeds the defined thresholds.
+
+Measurement Mode: This mode is used to read the acceleration data on X,Y,Z
+axis and supports 400, 100, 40 Hz sample frequency.
+
+Free fall Mode: This mode is intented to save system resources.
+
+Threshold values: Chip supports defining threshold values for above modes
+which includes time and g value. Refer product specifications for more details.
+
+CMA3000 chip supports mutually exclusive I2C and SPI interfaces for
+communication, currently the driver supports I2C based communication only.
+Initial configuration for bus mode is set in non volatile memory and can later
+be modified through bus interface command.
+
+Driver reports acceleration data through input subsystem. It generates ABS_MISC
+event with value 1 when free fall is detected.
+
+Platform data need to be configured for initial default values.
+
+Platform Data
+-
+fuzz_x: Noise on X Axis
+
+fuzz_y: Noise on Y Axis
+
+fuzz_z: Noise on Z Axis
+
+g_range: G range in milli g i.e 2000 or 8000
+
+mode: Default Operating mode
+
+mdthr: Motion detect g range threshold value
+
+mdfftmr: Motion detect and free fall time threshold value
+
+ffthr: Free fall g range threshold value
+
+Input Interface
+--
+Input driver version is 1.0.0
+Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0
+Input device name: "cma3000-accelerometer"
+Supported events:
+  Event type 0 (Sync)
+  Event type 3 (Absolute)
+Event code 0 (X)
+  Value 47
+  Min-8000
+  Max 8000
+  Fuzz 200
+Event code 1 (Y)
+  Value-28
+  Min-8000
+  Max 8000
+  Fuzz 200
+Event code 2 (Z)
+  Value905
+  Min-8000
+  Max 8000
+  Fuzz 200
+Event code 40 (Misc)
+  Value  0
+  Min0
+  Max1
+  Event type 4 (Misc)
+
+
+Register/Platform parameters Description
+
+
+mode:
+   0: power down mode
+   1: 100 Hz Measurement mode
+   2: 400 Hz Measurement mode
+   3: 40 Hz Measurement mode
+   4: Motion Detect mode (default)
+   5: 100 Hz Free fall mode
+   6: 40 Hz Free fall mode
+   7: Power off mode
+
+grange:
+   2000: 2000 mg or 2G Range
+   8000: 8000 mg or 8G Range
+
+mdthr:
+   X: X * 71mg (8G Range)
+   X: X * 18mg (2G Range)
+
+mdfftmr:
+   X: (X & 0x70) * 100 ms (MDTMR)
+  (X & 0x0F) * 2.5 ms (FFTMR 400 Hz)
+  (X & 0x0F) * 10 ms  (FFTMR 100 Hz)
+
+ffthr:
+   X: (X >> 2) * 18mg (2G Range)
+   X: (X & 0x0F) * 71 mg (8G Range)
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index b99b8cb..d5e5fd6 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -448,4 +448,28 @@ conf

[PATCH V4 2/2] omap4: platform changes for CMA3000

[Hemanth V]

>From 8082870cc704d901d98cf0d6af90e45860927ceb Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Thu, 26 Aug 2010 17:49:12 +0530
Subject: [PATCH] Platform changes for CMA3000 Accelerometer driver

Update 4430 SDP board file with platform data for accelerometer driver
and select the driver in kconfig

Signed-off-by: Hemanth V 
---
 arch/arm/mach-omap2/Kconfig |2 ++
 arch/arm/mach-omap2/board-4430sdp.c |   30 ++
 2 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index a928fd6..e87c049 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -255,6 +255,8 @@ config MACH_OMAP_4430SDP
depends on ARCH_OMAP4
select INPUT_TOUCHSCREEN
select TOUCHSCREEN_SYNTM12XX
+   select INPUT_MISC
+   select INPUT_CMA3000
+   select INPUT_CMA3000_I2C

 config MACH_OMAP4_PANDA
bool "OMAP4 Panda Board"
diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index ed78cdb..8b94f1f 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -23,6 +23,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #include 
 #include 
@@ -44,6 +46,7 @@
 #define ETH_KS8851_QUART   138
 #define OMAP4SDP_MDM_PWR_EN_GPIO   157
 #define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO   184
+#define OMAP4_CMA3000ACCL_GPIO 186
 #define OMAP4_SFH7741_ENABLE_GPIO  188

 static struct gpio_led sdp4430_gpio_leds[] = {
@@ -485,6 +488,27 @@ static struct twl4030_platform_data sdp4430_twldata = {
.vaux3  = &sdp4430_vaux3,
 };

+static struct cma3000_platform_data cma3000_platform_data = {
+   .fuzz_x = 25,
+   .fuzz_y = 25,
+   .fuzz_z = 25,
+   .g_range = CMARANGE_8G,
+   .mode = CMAMODE_MOTDET,
+   .mdthr = 0x8,
+   .mdfftmr = 0x33,
+   .ffthr = 0x8,
+   .irqflags = IRQF_TRIGGER_HIGH,
+};
+
+static void omap_cma3000accl_init(void)
+{
+   if (gpio_request(OMAP4_CMA3000ACCL_GPIO, "Accelerometer") < 0) {
+   pr_err("Accelerometer GPIO request failed\n");
+   return;
+   }
+   gpio_direction_input(OMAP4_CMA3000ACCL_GPIO);
+}
+
 static struct i2c_board_info __initdata sdp4430_i2c_boardinfo[] = {
{
I2C_BOARD_INFO("twl6030", 0x48),
@@ -518,6 +542,11 @@ static struct i2c_board_info __initdata 
sdp4430_i2c_4_boardinfo[] = {
{
I2C_BOARD_INFO("hmc5843", 0x1e),
},
+   {
+   I2C_BOARD_INFO("cma3000_d01", 0x1c),
+   .platform_data = &cma3000_platform_data,
+   .irq = OMAP_GPIO_IRQ(OMAP4_CMA3000ACCL_GPIO),
+   },
 };

 static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
@@ -570,6 +599,7 @@ static void __init omap_sfh7741prox_init(void)
 __func__, OMAP4_SFH7741_ENABLE_GPIO, error);
gpio_free(OMAP4_SFH7741_ENABLE_GPIO);
}
+   omap_cma3000accl_init();
 }

 static void __init omap_4430sdp_init(void)
-- 
1.5.4.3

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

Re: [PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition

[Hemanth V]

- Original Message - 
From: "Gregory CLEMENT" 
To: "linux-omap" ; 

Cc: "David Brownell" ; "Grant Likely" 
; "Kevin Hilman" 

Sent: Thursday, November 25, 2010 3:49 AM
Subject: [PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after 
off-mode transition



As request by Grant Likely, there is no more cover letter. Full changelog 
is following.
I am still reluctant to add this changelog in the patch description, as it 
adds no value to
the patch itself: when it was needed I try to updat comments or patch 
description.
I understand that Grant Likely would need an ack from other user as this 
patch fix a corner case.
Kevin Hilman made a few comments on this patch so he could add his "Ack 
by" or at least his "Review by".




I was trying to run some tests with this patch. I find that the resume 
function registered by this patch doesnot seem to
get called during system wide suspend/resume, since spi_resume only calls 
the resume routine registered by spi client driver.

Is there something I am missing.

Thanks
Hemanth


--
To unsubscribe from this list: send the line "unsubscribe 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] Add OMAP Support for Generic PWM Devices using Dual-mode Timers

[Hemanth V]

- Original Message - 
From: "Grant Erickson" 

To: "Hemanth V" 
Cc: "Tony Lindgren" ; 
Sent: Tuesday, November 16, 2010 11:15 PM
Subject: Re: [PATCH] Add OMAP Support for Generic PWM Devices using 
Dual-mode Timers






Boards can register such devices using platform data such as in the
following
example:

static struct omap2_pwm_platform_config pwm_config = {
.timer_id   = 10,   // GPT10_PWM_EVT


Since only specific GPTs can be configured for PWM, can some check
we added in probe function?


Yes, that check is already present in the probe function:

   pwm->dm_timer = omap_dm_timer_request_specific(pdata->timer_id);

   if (pwm->dm_timer == NULL) {
   status = -ENOENT;
   goto err_free;
   }



Since only GPT8 to GPT11 can be configured for PWM output on OMAP3,
I was thinking if a suitable check can be added.

Thanks
Hemanth 


--
To unsubscribe from this list: send the line "unsubscribe 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] Add OMAP Support for Generic PWM Devices using Dual-mode Timers

[Hemanth V]

- Original Message - 
From: "Grant Erickson" 

To: 
Cc: "Tony Lindgren" 
Sent: Monday, November 15, 2010 12:58 AM
Subject: [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode 
Timers




This patch adds support to request and use one or more of the OMAP
dual-mode timers as a generic PWM device compatible with other generic
PWM drivers such as the PWM backlight or PWM beeper driver.


Generally PWMs are supported on PMIC chip.  Is this driver intended for use
when OMAP is used standalone.



Boards can register such devices using platform data such as in the 
following

example:

static struct omap2_pwm_platform_config pwm_config = {
.timer_id   = 10,   // GPT10_PWM_EVT


Since only specific GPTs can be configured for PWM, can some check
we added in probe function.


.polarity   = 1 // Active-high
};

static struct platform_device pwm_device = {
.name   = "omap-pwm",
.id = 0,
.dev= {
.platform_data  = &pwm_config
}
};

Signed-off-by: Grant Erickson 

---

arch/arm/plat-omap/Kconfig|9 +
arch/arm/plat-omap/Makefile   |2 +
arch/arm/plat-omap/include/plat/pwm.h |   29 ++
arch/arm/plat-omap/pwm.c  |  450 
+


Can the above file  be part of mach-omap2, since comment say its 
specifically

for OMAP2/3 or will this work on OMAP1 also.



4 files changed, 490 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 92c5bb7..4797b0e 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -164,6 +164,15 @@ config OMAP_DM_TIMER
 help
 Select this option if you want to use OMAP Dual-Mode timers.

+config HAVE_PWM
+   bool "Use PWM timers"
+   depends on OMAP_DM_TIMER
+   help
+ Select this option if you want to be able to request and use
+ one or more of the OMAP dual-mode timers as a generic PWM device
+ compatible with other generic PWM drivers such as the backlight 
or

+ beeper driver.
+
config OMAP_SERIAL_WAKE
 bool "Enable wake-up events for serial ports"
 depends on ARCH_OMAP1 && OMAP_MUX
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index a4a1285..9e5347b 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -32,3 +32,5 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o

obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
+
+obj-$(CONFIG_HAVE_PWM) += pwm.o
diff --git a/arch/arm/plat-omap/include/plat/pwm.h 
b/arch/arm/plat-omap/include/plat/pwm.h

new file mode 100644
index 000..04030cd
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/pwm.h
@@ -0,0 +1,29 @@
+/*
+ *Copyright (c) 2010 Grant Erickson 
+ *
+ *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.
+ *
+ *Description:
+ *  This file is defines platform-specific configuration data for
+ *  the OMAP generic PWM platform driver.
+ */
+
+#ifndef _OMAP2_PWM_H
+#define _OMAP2_PWM_H
+
+/**
+ * struct omap2_pwm_platform_config - OMAP platform-specific data for 
PWMs

+ * @timer_id: the OMAP dual-mode timer ID.
+ * @polarity: the polarity (active-high or -low) of the PWM.
+ *
+ * This identifies the OMAP dual-mode timer (dmtimer) that will be bound
+ * to the PWM.
+ */
+struct omap2_pwm_platform_config {
+ int timer_id;
+ bool polarity;
+};
+
+#endif /* _OMAP2_PWM_H */
diff --git a/arch/arm/plat-omap/pwm.c b/arch/arm/plat-omap/pwm.c
new file mode 100644
index 000..c6d103d
--- /dev/null
+++ b/arch/arm/plat-omap/pwm.c
@@ -0,0 +1,450 @@
+/*
+ *Copyright (c) 2010 Grant Erickson 
+ *
+ *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.
+ *
+ *Description:
+ *  This file is the core OMAP2/3 support for the generic, Linux
+ *  PWM driver / controller, using the OMAP's dual-mode timers.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Preprocessor Definitions */
+
+#undef OMAP_PWM_DEBUG
+
+#if defined(OMAP_PWM_DEBUG)
+#define DBG(args...) \
+ do { \
+ pr_info(args); \
+ } while (0)
+#define DEV_DBG(dev, args...) \
+ do { \
+ dev_info(dev, args); \
+ } while (0)
+#else
+#define DBG(args...) \
+ do { } while (0)
+#define DEV_DBG(dev, args...) \
+ do { } while (0)
+#endif /* defined(OMAP_PWM_DEBUG) */
+
+#define DM_TIMER_LOAD_MIN 0xFFFE
+
+/* Type Definitions */
+
+/**
+ * struct pwm_device - opaque internal PWM device instance state
+ * @head: list head for all PWMs managed by this driver.
+ * @pdev: corresponding platform device associated with this device 
instance.

+ * @dm_timer: correspo

Re: [PATCH v2 2/2] spi: Force CS to be in inactive state after off-mode transition

[Hemanth V]

- Original Message - 
From: "Gregory CLEMENT" 
To: "spi-devel-general" ; 
"linux-omap" 
Cc: "David Brownell" ; "Grant Likely" 
; "Kevin Hilman" 

Sent: Wednesday, November 10, 2010 4:02 PM
Subject: [PATCH v2 2/2] spi: Force CS to be in inactive state after off-mode 
transition



When SPI wake up from OFF mode, CS is in the wrong state: force it to the 
inactive state.


During the system life, I monitored the CS behavior using a oscilloscope. 
I also activated debug in omap2_mcspi, so I saw when driver disable the 
clocks and restore context when device is not used.

Each time the CS was in the correct state.
It was only when system was put suspend to ram with off-mode activated 
that on resume the CS was in wrong state( ie activated).




Just to confirm the understanding. Are saying  CHCONF[6]  EPOL bit
setting and CS state did not match and is actually a hardware bug. If so
could u let us know which platform u are testing this on.

Thanks
Hemanth


Signed-off-by: Gregory CLEMENT 
---
 drivers/spi/omap2_mcspi.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..938f14c 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1139,6 +1139,15 @@ static u8 __initdata spi4_txdma_id[] = {
 };
 #endif
 +/* When SPI wake up, CS is in wrong state: force it to unactive state*/
+static void omap2_mcspi_resume(struct spi_device *spi)
+{
+ omap2_mcspi_enable_clocks( spi_master_get_devdata(spi->master));
+ /* We need to togle CS state for OMAP take this chang in account*/
+ omap2_mcspi_force_cs(spi, 1);
+ omap2_mcspi_force_cs(spi, 0);
+ omap2_mcspi_disable_clocks( spi_master_get_devdata(spi->master));
+}
 static int __init omap2_mcspi_probe(struct platform_device *pdev)
 {
 struct spi_master *master;
@@ -1194,6 +1203,7 @@ static int __init omap2_mcspi_probe(struct 
platform_device *pdev)

 master->transfer = omap2_mcspi_transfer;
 master->cleanup = omap2_mcspi_cleanup;
 master->num_chipselect = num_chipselect;
+ master->resume = omap2_mcspi_resume;
  dev_set_drvdata(&pdev->dev, master);
 -- 1.7.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



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

Re: [PATCH V3 1/2] input: CMA3000 Accelerometer driver

[Hemanth V]

rqflags = data->pdata.irqflags;
+
+ data->input_dev = input_allocate_device();
+ if (data->input_dev == NULL) {
+ ret = -ENOMEM;
+ dev_err(&data->client->dev,
+ "Failed to allocate input device\n");
+ goto err_op1_failed;
+ }
+
+ data->input_dev->name = "cma3000-acclerometer";
+
+#if defined CONFIG_INPUT_CMA3000_I2C || defined
CONFIG_INPUT_CMA3000_I2C_MODULE
+ data->input_dev->id.bustype = BUS_I2C;
+#endif
+
+  __set_bit(EV_ABS, data->input_dev->evbit);
+  __set_bit(EV_MSC, data->input_dev->evbit);
+
+ input_set_abs_params(data->input_dev, ABS_X, -g_range,
+ g_range, fuzz_x, 0);
+ input_set_abs_params(data->input_dev, ABS_Y, -g_range,
+ g_range, fuzz_y, 0);
+ input_set_abs_params(data->input_dev, ABS_Z, -g_range,
+ g_range, fuzz_z, 0);
+ input_set_abs_params(data->input_dev, ABS_MISC, 0,
+ 1, 0, 0);
+
+ mutex_init(&data->mutex);
+
+ ret = request_threaded_irq(data->client->irq, NULL,
+ cma3000_thread_irq,
+ irqflags | IRQF_ONESHOT,
+ data->client->name, data);
+
+ if (ret < 0) {
+ dev_err(&data->client->dev,
+ "request_threaded_irq failed\n");
+ goto err_op2_failed;
+ }
+
+ ret = sysfs_create_group(&data->client->dev.kobj,
&cma3000_attr_group);
+ if (ret) {
+ dev_err(&data->client->dev,
+ "failed to create sysfs entries\n");
+ goto err_op2_failed;
+ }
+
+ ret = input_register_device(data->input_dev);
+ if (ret) {
+ dev_err(&data->client->dev,
+ "Unable to register input device\n");
+ goto err_op2_failed;


Shouldn't you have and err_op3 here to remove the created group on 
failure?


Yes this needs to be added, will fix




+ }
+
+ return 0;
+


These error cases do not seem to be complete.
Some of the missing cases are the removal of the sysfs group, destroying 
of the request_thread_irq and freeing of the input device before
registering it.  I hope these are not handled in a different API this 
makes the code hard to verify and validate proper error handling.


Yes, will fix sysfs and irq freeing. Freeing for input device refers
to allocation done through input_allocate_device




+err_op2_failed:
+ mutex_destroy(&data->mutex);
+err_op1_failed:
+ if (data->input_dev != NULL)
+ input_free_device(data->input_dev);
+
+ return ret;
+}
+EXPORT_SYMBOL(cma3000_init);



Why do you export this call and expose it in the header file?


Same comment as above




+
+int cma3000_exit(struct cma3000_accl_data *data)
+{
+ int ret;
+
+ ret = cma3000_poweroff(data);
+
+ if (data->client->irq)
+ free_irq(data->client->irq, data);
+
+ sysfs_remove_group(&data->client->dev.kobj, &cma3000_attr_group);
+ mutex_destroy(&data->mutex);
+ input_unregister_device(data->input_dev);
+ return ret;
+}
+EXPORT_SYMBOL(cma3000_exit);


Why do you export this call and expose it in the header file?


Same comment as above




+
+MODULE_DESCRIPTION("CMA3000-D0x Accelerometer Driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Hemanth V ");
diff --git a/drivers/input/misc/cma3000_d0x.h
b/drivers/input/misc/cma3000_d0x.h
new file mode 100644
index 000..107b5fa
--- /dev/null
+++ b/drivers/input/misc/cma3000_d0x.h
@@ -0,0 +1,53 @@
+/*
+ * cma3000_d0x.h
+ * VTI CMA3000_D0x Accelerometer driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Hemanth V 
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms of the GNU General Public License version 2 as
published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
along with
+ * this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef _INPUT_CMA3000_H
+#define _INPUT_CMA3000_H
+
+#include 
+#include 
+
+struct cma3000_accl_data;
+
+struct cma3000_bus_ops {
+ u16 bustype;
+ int (*read) (struct cma3000_accl_data *, u8, char *);
+ int (*write) (struct cma3000_accl_data *, u8, u8, char *);
+};
+
+struct cma3000_accl_data {
+#if defined CONFIG_INPUT_CMA3000_I2C || defined
CONFIG_INPUT_CMA3000_I2C_MODULE
+ struct i2c_client *client;
+#endif
+ struct input_d

Re: [PATCH 1/7] pwm: Add pwm core driver

[Hemanth V]

- Original Message - 
From: "Arun Murthy" 




The existing pwm based led and backlight driver makes use of the
pwm(include/linux/pwm.h). So all the board specific pwm drivers will
be exposing the same set of function name as in include/linux/pwm.h.
As a result build fails in case of multi soc environments where each soc
has a pwm device in it.


This seems very specific to ST environment,  looking at the driver list from
( [PATCH 4/7] pwm: Align existing pwm drivers with pwm-core ) it seems
most multi SOC environments might support PWM in either one of the SOC.

arch/arm/plat-mxc/pwm.c
arch/arm/plat-pxa/pwm.c
arch/arm/plat-samsung/pwm.c
arch/mips/jz4740/pwm.c
drivers/mfd/twl6030-pwm.c

Unless people have examples of other SOCs which might use this,
the better approach might be to go for a custom driver rather than changing
the framework.

Thanks
Hemanth 


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

Re: [PATCH V3 1/2] input: CMA3000 Accelerometer driver

[Hemanth V]

- Original Message - 
From: "Jonathan Cameron" 

To: "Dmitry Torokhov" 
Cc: "Hemanth V" ; ; 
; 

Sent: Tuesday, September 14, 2010 6:40 PM
Subject: Re: [PATCH V3 1/2] input: CMA3000 Accelerometer driver



On 09/14/10 09:00, Dmitry Torokhov wrote:

On Wed, Sep 08, 2010 at 12:37:40PM +0100, Jonathan Cameron wrote:


I'm happy to see your driver go in as it is currently, what bothers me 
is that we will end

up with incompatible interfaces for all the accelerometers Dmitry takes!



This is a valid concern. How about I chicken out and will not merge any
new sysfs knobs until you guys decide on reasonable interface? Most set
up is done by board code anyways, sysfs is more of nice-to-have?

Hemanth, would removing the sysfs hooks from this driver be ok with you?
I'd personally have favoured a merge, add new interfaces when agreed and
deprecate old ones approach, but it is Dmitry's call.  Perhaps it is 
better

to get the majority of the device functionality in place now and add
the bells and whistles later.

For input device things are probably mostly fixed for a particular board
design.  There are definitely interesting things one can do if the knobs
are available but they (I think) mostly fall outside of using the device
for input!



Dmitry, Jonathan

I am ok to remove the sysfs entries for now, but would cause some 
limitations
like not being able to change sampling frequency / disabling interrupts 
runtime.


Wanted to clarify if the intention is to come up with a standard sysfs 
interface

for all accelerometer drivers under input/misc including adxl34x.

Thanks
Hemanth 


--
To unsubscribe from this list: send the line "unsubscribe 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 V3 2/2] omap4: platform changes for CMA3000

[Hemanth V]

>From 8082870cc704d901d98cf0d6af90e45860927ceb Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Thu, 26 Aug 2010 17:49:12 +0530
Subject: [PATCH] Platform changes for CMA3000 Accelerometer driver

Update 4430 SDP board file with platform data for accelerometer driver
and select the driver in kconfig

Signed-off-by: Hemanth V 
---
 arch/arm/mach-omap2/Kconfig |2 ++
 arch/arm/mach-omap2/board-4430sdp.c |   30 ++
 2 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index a928fd6..e87c049 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -255,6 +255,8 @@ config MACH_OMAP_4430SDP
depends on ARCH_OMAP4
select INPUT_TOUCHSCREEN
select TOUCHSCREEN_SYNTM12XX
+   select INPUT_MISC
+   select INPUT_CMA3000_I2C

 config MACH_OMAP4_PANDA
bool "OMAP4 Panda Board"
diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index ed78cdb..8b94f1f 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -23,6 +23,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #include 
 #include 
@@ -44,6 +46,7 @@
 #define ETH_KS8851_QUART   138
 #define OMAP4SDP_MDM_PWR_EN_GPIO   157
 #define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO   184
+#define OMAP4_CMA3000ACCL_GPIO 186
 #define OMAP4_SFH7741_ENABLE_GPIO  188

 static struct gpio_led sdp4430_gpio_leds[] = {
@@ -485,6 +488,27 @@ static struct twl4030_platform_data sdp4430_twldata = {
.vaux3  = &sdp4430_vaux3,
 };

+static struct cma3000_platform_data cma3000_platform_data = {
+   .fuzz_x = 25,
+   .fuzz_y = 25,
+   .fuzz_z = 25,
+   .g_range = CMARANGE_8G,
+   .mode = CMAMODE_MOTDET,
+   .mdthr = 0x8,
+   .mdfftmr = 0x33,
+   .ffthr = 0x8,
+   .irqflags = IRQF_TRIGGER_HIGH,
+};
+
+static void omap_cma3000accl_init(void)
+{
+   if (gpio_request(OMAP4_CMA3000ACCL_GPIO, "Accelerometer") < 0) {
+   pr_err("Accelerometer GPIO request failed\n");
+   return;
+   }
+   gpio_direction_input(OMAP4_CMA3000ACCL_GPIO);
+}
+
 static struct i2c_board_info __initdata sdp4430_i2c_boardinfo[] = {
{
I2C_BOARD_INFO("twl6030", 0x48),
@@ -518,6 +542,11 @@ static struct i2c_board_info __initdata 
sdp4430_i2c_4_boardinfo[] = {
{
I2C_BOARD_INFO("hmc5843", 0x1e),
},
+   {
+   I2C_BOARD_INFO("cma3000_accl", 0x1c),
+   .platform_data = &cma3000_platform_data,
+   .irq = OMAP_GPIO_IRQ(OMAP4_CMA3000ACCL_GPIO),
+   },
 };

 static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
@@ -570,6 +599,7 @@ static void __init omap_sfh7741prox_init(void)
 __func__, OMAP4_SFH7741_ENABLE_GPIO, error);
gpio_free(OMAP4_SFH7741_ENABLE_GPIO);
}
+   omap_cma3000accl_init();
 }

 static void __init omap_4430sdp_init(void)
-- 
1.5.4.3



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

[PATCH V3 1/2] input: CMA3000 Accelerometer driver

[Hemanth V]

>From d18a8425a427b97a372bfcd9018e89e93fcad486 Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Thu, 26 Aug 2010 17:44:48 +0530
Subject: [PATCH] input: CMA3000 Accelerometer Driver

This patch adds support for CMA3000 Tri-axis accelerometer, which
supports Motion detect, Measurement and Free fall modes.
CMA3000 supports both I2C/SPI bus for communication, currently the
driver supports I2C based communication.

Driver reports acceleration data through input subsystem and supports
sysfs for configuration changes.

This is V3 of patch, which fixes open source review comments

Signed-off-by: Hemanth V 
Reviewed-by: Jonathan Cameron 
---
 Documentation/input/cma3000_d0x.txt  |  112 ++
 drivers/input/misc/Kconfig   |   25 ++
 drivers/input/misc/Makefile  |2 +
 drivers/input/misc/cma3000_d0x.c |  632 ++
 drivers/input/misc/cma3000_d0x.h |   53 +++
 drivers/input/misc/cma3000_d0x_i2c.c |  144 
 include/linux/input/cma3000.h|   60 
 7 files changed, 1028 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/input/cma3000_d0x.txt
 create mode 100644 drivers/input/misc/cma3000_d0x.c
 create mode 100644 drivers/input/misc/cma3000_d0x.h
 create mode 100644 drivers/input/misc/cma3000_d0x_i2c.c
 create mode 100644 include/linux/input/cma3000.h

diff --git a/Documentation/input/cma3000_d0x.txt 
b/Documentation/input/cma3000_d0x.txt
new file mode 100644
index 000..29ab6b7
--- /dev/null
+++ b/Documentation/input/cma3000_d0x.txt
@@ -0,0 +1,112 @@
+Kernel driver for CMA3000-D0x
+
+
+Supported chips:
+* VTI CMA3000-D0x
+Datasheet:
+  CMA3000-D0X Product Family Specification 8281000A.02.pdf
+
+Author: Hemanth V 
+
+
+Description
+---
+CMA3000 Tri-axis accelerometer supports Motion detect, Measurement and
+Free fall modes.
+
+Motion Detect Mode: Its the low power mode where interrupts are generated only
+when motion exceeds the defined thresholds.
+
+Measurement Mode: This mode is used to read the acceleration data on X,Y,Z
+axis and supports 400, 100, 40 Hz sample frequency.
+
+Free fall Mode: This mode is intented to save system resources.
+
+Threshold values: Chip supports defining threshold values for above modes
+which includes time and g value. Refer product specifications for more details.
+
+CMA3000 supports both I2C/SPI bus for communication, currently the driver
+supports I2C based communication.
+
+Driver reports acceleration data through input subsystem and supports sysfs
+for configuration changes. It generates ABS_MISC event with value 1 when
+free fall is detected.
+
+Platform data need to be configured for initial default values.
+
+Platform Data
+-
+fuzz_x: Noise on X Axis
+
+fuzz_y: Noise on Y Axis
+
+fuzz_z: Noise on Z Axis
+
+g_range: G range in milli g i.e 2000 or 8000
+
+mode: Default Operating mode
+
+mdthr: Motion detect threshold value
+
+mdfftmr: Motion detect and free fall time value
+
+ffthr: Free fall threshold value
+
+Input Interface
+--
+Input driver version is 1.0.0
+Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0
+Input device name: "cma3000-acclerometer"
+Supported events:
+  Event type 0 (Sync)
+  Event type 3 (Absolute)
+Event code 0 (X)
+  Value 47
+  Min-8000
+  Max 8000
+  Fuzz 200
+Event code 1 (Y)
+  Value-28
+  Min-8000
+  Max 8000
+  Fuzz 200
+Event code 2 (Z)
+  Value905
+  Min-8000
+  Max 8000
+  Fuzz 200
+Event code 40 (Misc)
+  Value  0
+  Min0
+  Max1
+  Event type 4 (Misc)
+
+Sysfs entries
+-
+
+mode:
+   0: power down mode
+   1: 100 Hz Measurement mode
+   2: 400 Hz Measurement mode
+   3: 40 Hz Measurement mode
+   4: Motion Detect mode (default)
+   5: 100 Hz Free fall mode
+   6: 40 Hz Free fall mode
+   7: Power off mode
+
+grange:
+   2000: 2000 mg or 2G Range
+   8000: 8000 mg or 8G Range
+
+mdthr:
+   X: X * 71mg (8G Range)
+   X: X * 18mg (2G Range)
+
+mdfftmr:
+   X: (X & 0x70) * 100 ms (MDTMR)
+  (X & 0x0F) * 2.5 ms (FFTMR 400 Hz)
+  (X & 0x0F) * 10 ms  (FFTMR 100 Hz)
+
+ffthr:
+   X: (X >> 2) * 18mg (2G Range)
+   X: (X & 0x0F) * 71 mg (8G Range)
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index b49e233..8d718a5 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -438,4 +438,29 @@ config INPUT_ADXL34X_SPI
  To compile this driver as a module, choose M here: the
  module will be called adxl34x-spi.

+config INPUT_CMA3000
+   tristate "VTI CMA3000 Tri-axis accelerometer"
+   default n
+   help
+ Say Y here if you want to use VTI CMA3000_D0x Accelerometer
+ driver
+
+ This driver currently only supports I2C interface to the
+  

Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver

[Hemanth V]

- Original Message - 
From: "Dmitry Torokhov" 

Hi Hemanth,

On Fri, Sep 03, 2010 at 04:02:11PM +0530, Hemanth V wrote:

>
>
>Do not like repeated release of resources in main and error path... Can
>we do it like:
>
>...
>disable_irq();
>error = cma3000_set(data, CMA3000_CTRL, ctrl, "ctrl");
>if (!error) {
>/* Settling time delay required after mode change */
>msleep(CMA3000_SETDELAY);
>}
>enable_irq();
>out:
>mutex_unlock();
>return error ? error : count;

I am thinking I can just add the below statement, and should be able to
remove repeated release.

return error ? error : count;



That would make us sleep for CMA3000_SETDELAY even in case of failure...
... But that should be OK.


I suppose it should not sleep if its the modified code segment as below

   error = CMA3000_SET(data, CMA3000_CTRL, ctrl, "ctrl");
   if (error < 0)
   goto err_op3_failed;

   /* Settling time delay required after mode change */
   msleep(CMA3000_SETDELAY);

err_op3_failed:
   enable_irq(data->client->irq);
err_op2_failed:
   mutex_unlock(&data->mutex);
err_op1_failed:
   return (error ? error : count);





>>+
>>+ if (data->client->irq) {
>>+ ret = request_threaded_irq(data->client->irq, NULL,
>>+ cma3000_thread_irq,
>>+ irqflags | IRQF_ONESHOT,
>>+ data->client->name, data);
>>+
>>+ if (ret < 0) {
>>+ dev_err(&data->client->dev,
>>+ "request_threaded_irq failed\n");
>>+ goto err_op1_failed;
>>+ }
>>+ }
>
>What is the utility of the driver when there is no IRQ line?

Not sure I fully understand your comments.
Currently probe would return a failure.



You have a check for data->client->irq != 0 and finish probe() with
success in case it is 0. The question is what is the use of the
device/driver combo in case when data->client->irq == 0?


Yes agreed, will add a error scenario when data->client->irq == 0


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

Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver

[Hemanth V]

Dmitry, thanks for the review. Comments inline.

Hemanth
- Original Message - 
From: "Dmitry Torokhov" 

To: "Hemanth V" 
Cc: ; ; 


Sent: Monday, August 30, 2010 12:19 AM
Subject: Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver



Hi Hemanth,

On Fri, May 21, 2010 at 12:22:57PM +0530, Hemanth V wrote:

From: Hemanth V 
Date: Thu, 20 May 2010 20:18:17 +0530
Subject: [PATCH] input: CMA3000 Accelerometer Driver

This patch adds support for CMA3000 Tri-axis accelerometer, which
supports Motion detect, Measurement and Free fall modes.
CMA3000 supports both I2C/SPI bus for communication, currently the
driver supports I2C based communication.

Driver reports acceleration data through input subsystem and supports
sysfs for configuration changes.

This is V2 of patch, which fixes open source review comments

Signed-off-by: Hemanth V 
Cc: Dmitry Torokhov 
---
 Documentation/input/cma3000_d0x.txt  |  112 ++
 drivers/input/misc/Kconfig   |7 +
 drivers/input/misc/Makefile  |1 +
 drivers/input/misc/cma3000_d0x.c |  633 
++

 drivers/input/misc/cma3000_d0x.h |   46 +++
 drivers/input/misc/cma3000_d0x_i2c.c |  136 
 include/linux/i2c/cma3000.h  |   60 
 7 files changed, 995 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/input/cma3000_d0x.txt
 create mode 100644 drivers/input/misc/cma3000_d0x.c
 create mode 100644 drivers/input/misc/cma3000_d0x.h
 create mode 100644 drivers/input/misc/cma3000_d0x_i2c.c
 create mode 100644 include/linux/i2c/cma3000.h

diff --git a/Documentation/input/cma3000_d0x.txt 
b/Documentation/input/cma3000_d0x.txt

new file mode 100644
index 000..29ab6b7
--- /dev/null
+++ b/Documentation/input/cma3000_d0x.txt
@@ -0,0 +1,112 @@
+Kernel driver for CMA3000-D0x
+
+
+Supported chips:
+* VTI CMA3000-D0x
+Datasheet:
+  CMA3000-D0X Product Family Specification 8281000A.02.pdf
+
+Author: Hemanth V 
+
+
+Description
+---
+CMA3000 Tri-axis accelerometer supports Motion detect, Measurement and
+Free fall modes.
+
+Motion Detect Mode: Its the low power mode where interrupts are 
generated only

+when motion exceeds the defined thresholds.
+
+Measurement Mode: This mode is used to read the acceleration data on 
X,Y,Z

+axis and supports 400, 100, 40 Hz sample frequency.
+
+Free fall Mode: This mode is intented to save system resources.
+
+Threshold values: Chip supports defining threshold values for above 
modes
+which includes time and g value. Refer product specifications for more 
details.

+
+CMA3000 supports both I2C/SPI bus for communication, currently the 
driver

+supports I2C based communication.
+
+Driver reports acceleration data through input subsystem and supports 
sysfs

+for configuration changes. It generates ABS_MISC event with value 1 when
+free fall is detected.
+
+Platform data need to be configured for initial default values.
+
+Platform Data
+-
+fuzz_x: Noise on X Axis
+
+fuzz_y: Noise on Y Axis
+
+fuzz_z: Noise on Z Axis
+
+g_range: G range in milli g i.e 2000 or 8000
+
+mode: Default Operating mode
+
+mdthr: Motion detect threshold value
+
+mdfftmr: Motion detect and free fall time value
+
+ffthr: Free fall threshold value
+
+Input Interface
+--
+Input driver version is 1.0.0
+Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0
+Input device name: "cma3000-acclerometer"
+Supported events:
+  Event type 0 (Sync)
+  Event type 3 (Absolute)
+Event code 0 (X)
+  Value 47
+  Min-8000
+  Max 8000
+  Fuzz 200
+Event code 1 (Y)
+  Value-28
+  Min-8000
+  Max 8000
+  Fuzz 200
+Event code 2 (Z)
+  Value905
+  Min-8000
+  Max 8000
+  Fuzz 200
+Event code 40 (Misc)
+  Value  0
+  Min0
+  Max1
+  Event type 4 (Misc)
+
+Sysfs entries
+-
+
+mode:
+ 0: power down mode
+ 1: 100 Hz Measurement mode
+ 2: 400 Hz Measurement mode
+ 3: 40 Hz Measurement mode
+ 4: Motion Detect mode (default)
+ 5: 100 Hz Free fall mode
+ 6: 40 Hz Free fall mode
+ 7: Power off mode
+
+grange:
+ 2000: 2000 mg or 2G Range
+ 8000: 8000 mg or 8G Range
+
+mdthr:
+ X: X * 71mg (8G Range)
+ X: X * 18mg (2G Range)
+
+mdfftmr:
+ X: (X & 0x70) * 100 ms (MDTMR)
+(X & 0x0F) * 2.5 ms (FFTMR 400 Hz)
+(X & 0x0F) * 10 ms  (FFTMR 100 Hz)
+
+ffthr:
+   X: (X >> 2) * 18mg (2G Range)
+   X: (X & 0x0F) * 71 mg (8G Range)
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 1cf25ee..043ee8d 100755
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -340,4 +340,11 @@
   To compile this driver as a module, choose M here: the
   module will be called pcap_keys.

+config INPUT_CMA3000_I2C
+ bool "VTI CMA3000 Tri-axis accelerometer"


Why is it boolean? It should be possible to confi

RE: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver

[Hemanth V]

From: "Murphy, Dan" 
> Hemanth
> I have a few comments on this patch.
>
> +static ssize_t cma3000_store_attr_mdfftmr(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct cma3000_accl_data *data = platform_get_drvdata(pdev);
> + unsigned long val;
> + int error;
> +
> + error = strict_strtoul(buf, 0, &val);
> + if (error)
> + return error;
> +
> + mutex_lock(&data->mutex);
> + data->pdata.mdfftmr = val;
> +
> + disable_irq(data->client->irq);
> You should use disable_irq_nosync here.  This may not work properly on SMP.

Can u explain why disable_irq will not work on SMP.

>
>> +if (val == CMARANGE_2G) {
>> +ctrl |= CMA3000_RANGE2G;
>> +data->pdata.g_range = CMARANGE_2G;
>> +} else if (val == CMARANGE_8G) {
>> +ctrl |= CMA3000_RANGE8G;
>> +data->pdata.g_range = CMARANGE_8G;
>
> Why are you modifying the platform data?  Why not just keep it in a global or 
> a glocal structure and modify it that way?

If you look carefully, the variable data is indeed a local structure.

>> +} else {
>> +error = -EINVAL;
>> +goto err_op_failed;
>> +}
>> +
>> +g_range = data->pdata.g_range;
>> +fuzz_x = data->pdata.fuzz_x;
>> +fuzz_y = data->pdata.fuzz_y;
>> +fuzz_z = data->pdata.fuzz_z;
> Why are you storing these locally and then using them once can't we eliminate 
> these completely and just pass the platform data values into the set
> params?

I belive this is already discussed and agreed upon in the previous thread of 
discussion.
Pl refer the same.

>> +
>> +disable_irq(data->client->irq);
> You should use disable_irq_nosync here.  This may not work properly on SMP.
>

Same comment as above

>> +cma3000_set(data, CMA3000_CTRL, ctrl, "ctrl");
>> +
>> +input_set_abs_params(data->input_dev, ABS_X, -g_range,
>> +g_range, fuzz_x, 0);
>> +input_set_abs_params(data->input_dev, ABS_Y, -g_range,
>> +g_range, fuzz_y, 0);
>> +input_set_abs_params(data->input_dev, ABS_Z, -g_range,
>> +g_range, fuzz_z, 0);
> Don't necessarily agree with modifying the parameters for the input device on 
> the fly.  Some implementations may be a read once on init and do not
> go back and check this.

Its the user space code that can modify the grange if required, so I suppose it 
will need to check
these values after modifying the range.

>
>
> + ret = request_threaded_irq(data->client->irq, NULL,
> + cma3000_thread_irq,
> + irqflags | IRQF_ONESHOT,
> + data->client->name, data);
>
> This is implemented wrong.  You are doing a lot of processing in the IRQ 
> context here.  Especially calls out to a peripheral.  The NULL should be
> your handler thread where you do all the device processing.

Are u sure u are referring to threaded irq, all the processing is being done in 
thread
context. Pl refer documentation for more details on threaded irqs.

>
> Also this implementation only suggests that the HW has the IRQ connected what 
> about devices that the IRQ line was not connected?
>
This is currently not implemented, since I am not aware of any boards with this 
configuration. A polling method could be added
in future if the need arises.



--
To unsubscribe from this list: send the line "unsubscribe 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 V2 1/2] input: CMA3000 Accelerometer driver

[Hemanth V]

- Original Message - 
From: "Jonathan Cameron" 

To: "Hemanth V" 
Cc: ; ; 


Sent: Friday, May 21, 2010 5:27 PM
Subject: Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver



On 05/21/10 07:52, Hemanth V wrote:

From: Hemanth V 
Date: Thu, 20 May 2010 20:18:17 +0530
Subject: [PATCH] input: CMA3000 Accelerometer Driver

This patch adds support for CMA3000 Tri-axis accelerometer, which
supports Motion detect, Measurement and Free fall modes.
CMA3000 supports both I2C/SPI bus for communication, currently the
driver supports I2C based communication.

Driver reports acceleration data through input subsystem and supports
sysfs for configuration changes.

This is V2 of patch, which fixes open source review comments



Hi,

The driver is nice and clean.

Still leaving aside the long argued question of whether this should be
in input.  If you care for my views on that there are plenty or other
threads! There are a few things I'd still like to suggest:



Jonathan, Andrew

Is there any way forward for this patch, I am unable to induce any response
from the input maintainer

Thanks
Hemanth 


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

[RFC] [PATCH] mfd: Support for TWL6030 PWM

[Hemanth V]

>From 2c6efcebf2790a4c968309360cfc3559b6d9c110 Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Thu, 8 Jul 2010 17:04:06 +0530
Subject: [PATCH] Add support for TWL6030 PWM

TWL6030 supports PWM (Pulse Width Modulator) which is used
to control charging LED. PWM allows for controlling brightness.
This patch implements the APIs required by leds-pwm driver.

Signed-off-by: Hemanth V 
---
 drivers/mfd/Kconfig   |9 +++
 drivers/mfd/Makefile  |3 +-
 drivers/mfd/twl6030-pwm.c |  163 +
 3 files changed, 174 insertions(+), 1 deletions(-)
 create mode 100644 drivers/mfd/twl6030-pwm.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index c7c11ef..4459fe5 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -162,6 +162,15 @@ config TWL6030_GPADC
  Say yes here if you want support for the TWL6030 General Purpose
  A/D Convertor.

+config TWL6030_PWM
+   tristate "TWL6030 PWM (Pulse Width Modulator) Support"
+   depends on TWL4030_CORE
+   select HAVE_PWM
+   default n
+   help
+ Say yes here if you want support for TWL6030 PWM.
+ This is used to control charging LED brightness.
+
 config MFD_TMIO
bool
default n
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 204a974..e697101 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_TWL4030_CORE)+= twl-core.o twl4030-irq.o 
twl6030-irq.o
 obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
 obj-$(CONFIG_TWL4030_CODEC)+= twl4030-codec.o
 obj-$(CONFIG_TWL6030_GPADC)+= twl6030-gpadc.o
+obj-$(CONFIG_TWL6030_PWM)  += twl6030-pwm.o

 obj-$(CONFIG_MFD_MC13783)  += mc13783-core.o

@@ -63,4 +64,4 @@ obj-$(CONFIG_AB3100_OTP)  += ab3100-otp.o
 obj-$(CONFIG_AB4500_CORE)  += ab4500-core.o
 obj-$(CONFIG_MFD_TIMBERDALE)+= timberdale.o
 obj-$(CONFIG_PMIC_ADP5520) += adp5520.o
-obj-$(CONFIG_LPC_SCH)  += lpc_sch.o
\ No newline at end of file
+obj-$(CONFIG_LPC_SCH)  += lpc_sch.o
diff --git a/drivers/mfd/twl6030-pwm.c b/drivers/mfd/twl6030-pwm.c
new file mode 100644
index 000..5d25bdc
--- /dev/null
+++ b/drivers/mfd/twl6030-pwm.c
@@ -0,0 +1,163 @@
+/*
+ * twl6030_pwm.c
+ * Driver for PHOENIX (TWL6030) Pulse Width Modulator
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Hemanth V 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define LED_PWM_CTRL1  0xF4
+#define LED_PWM_CTRL2  0xF5
+
+/* Max value for CTRL1 register */
+#define PWM_CTRL1_MAX  255
+
+/* Pull down disable */
+#define PWM_CTRL2_DIS_PD   (1 << 6)
+
+/* Current control 2.5 milli Amps */
+#define PWM_CTRL2_CURR_02  (2 << 4)
+
+/* LED supply source */
+#define PWM_CTRL2_SRC_VAC  (1 << 2)
+
+/* LED modes */
+#define PWM_CTRL2_MODE_HW  (0 << 0)
+#define PWM_CTRL2_MODE_SW  (1 << 0)
+#define PWM_CTRL2_MODE_DIS (2 << 0)
+
+#define PWM_CTRL2_MODE_MASK0x3
+
+struct pwm_device {
+   const char *label;
+   unsigned int pwm_id;
+};
+
+int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
+{
+   u8 duty_cycle;
+   int ret;
+
+   if (pwm == NULL || period_ns == 0 || duty_ns > period_ns)
+   return -EINVAL;
+
+   duty_cycle = (duty_ns * PWM_CTRL1_MAX) / period_ns;
+
+   ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, duty_cycle, LED_PWM_CTRL1);
+
+   if (ret < 0) {
+   pr_err("%s: Failed to configure PWM, Error %d\n",
+   pwm->label, ret);
+   return ret;
+   }
+   return 0;
+}
+EXPORT_SYMBOL(pwm_config);
+
+int pwm_enable(struct pwm_device *pwm)
+{
+   u8 val;
+   int ret;
+
+   ret = twl_i2c_read_u8(TWL6030_MODULE_ID1, &val, LED_PWM_CTRL2);
+   if (ret < 0) {
+   pr_err("%s: Failed to enable PWM, Error %d\n", pwm->label, ret);
+   return ret;
+   }
+
+   /* Change mode to software control */
+   val &= ~PWM_CTRL2_MODE_MASK;
+   val |= PWM_CTRL2_MODE_SW;
+
+   ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, val, LED_PWM_CTRL2);
+   if (ret < 0) {
+   pr_err("%s: Failed to enable PWM, Error %d\n", pwm->label, ret);
+   return ret;
+   }
+
+   twl_i2c_read_u8(TWL

Re: PATCH[V2 1/3]: Update Platform files for SPI

[Hemanth V]

> On Thu, Feb 18, 2010 at 11:29 AM, Grant Likely
>  wrote:
>> On Thu, Feb 18, 2010 at 10:09 AM, Tony Lindgren  wrote:
>>> * Grant Likely  [100218 08:26]:
>>>> On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren  wrote:
>>>> > * Hemanth V  [100203 02:19]:
>>>> >> From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001
>>>> >> From: Hemanth V 
>>>> >> Date: Fri, 27 Nov 2009 14:22:30 +0530
>>>> >> Subject: [PATCH] Update platform files
>>>> >>
>>>> >> This patch updates platform files for
>>>> >> fifo, slave support
>>>> >>
>>>> >> Signed-off-by: Hemanth V 
>>>> >
>>>> > This should get merged via the spi-devel list with the other patches.
>>>> >
>>>> > Acked-by: Tony Lindgren 
>>>>
>>>> Tony, do you want me to add your acked-by to patches 2 & 3?
>>>
>>> No thanks, I've only looked at them briefly.
>>
>> Okay, thanks.
>>
>> Hemanth, I'm going to drop this series for the moment.  I'd like to
>> see some feedback/acks from current users and maintainers of the
>> omap2_mcspi driver before I merge support, especially now when the
>> merge window is about to open and it hasn't gotten any linux-next
>> exposure.
>>
>>>> Also, what is your feeling about patch 3/3, spi slave support.  spi
>>>> slave usage model is still a matter under debate, but that patch
>>>> doesn't touch core spi code, so I'm okay to merge it as a
>>>> driver-specific feature.  However, I'm not convinced that it is
>>>> actually a useful patch to merge yet, so I'll defer to you on this
>>>> one.  Thoughts?
>>>
>>> Up to you to decide. But here's my experience so far..
>>>
>>> Based on my experience if temporary hacks are merged, then nobody
>>> bothers to clean them up properly afterwards and the clean-up task
>>> unfairly falls on the maintainer.
>>>
>>> So IMHO, hacks like that are better floating on the mailing list
>>> until they're properly done. It's best to concentrate on getting
>>> the core things done right to make long term support easier.
>>
>> Right, I agree.  I'll ignore patch 3 entirely until I at least see a
>> patch for an in-tree user.
>
> Hi Hemanth.  Could you please respin patches 1 and 2 against
> 2.6.35-rc3?  The current patches do not apply anymore.
>

Grant,

Govindraj marked in this mail would rebase the patches and post the
same.

Thanks
Hemanth


--
To unsubscribe from this list: send the line "unsubscribe 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] OMAP4: Add support for PWM LED

[Hemanth V]

- Original Message - 
From: "Tony Lindgren" 

To: "Hemanth V" 
Cc: 
Sent: Thursday, July 01, 2010 4:07 PM
Subject: Re: [PATCH 2/2] OMAP4: Add support for PWM LED



* Hemanth V  [100630 17:12]:

From 713727188b99465341767eedaa42004862261211 Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Wed, 30 Jun 2010 18:16:33 +0530
Subject: [PATCH] OMAP4: Add support for PWM LED

TWL6030 supports PWM (Pulse Width Modulator) which is used
to control charging LED. This allows for controlling brightness
This patch implements the APIs needed by leds-pwm driver.





--- /dev/null
+++ b/arch/arm/mach-omap2/twl6030_pwm.c
@@ -0,0 +1,168 @@
+/*
+ * twl6030_pwm.c
+ * Driver for PHOENIX (TWL6030) Pulse Width Modulator


This should go to somewhere under drivers instead of
arch/arm/mach-omap2.


Tony, since PWM is specific to each platform, they are typically
under platform folder. Some examples below

arch/arm/plat-mxc/pwm.c
arch/arm/plat-pxa/pwm.c
arch/arm/plat-samsung/pwm.c

--
To unsubscribe from this list: send the line "unsubscribe 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] OMAP4: Add support for PWM LED

[Hemanth V]

>From 713727188b99465341767eedaa42004862261211 Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Wed, 30 Jun 2010 18:16:33 +0530
Subject: [PATCH] OMAP4: Add support for PWM LED

TWL6030 supports PWM (Pulse Width Modulator) which is used
to control charging LED. This allows for controlling brightness
This patch implements the APIs needed by leds-pwm driver.

Signed-off-by: Hemanth V 
---
 arch/arm/mach-omap2/Kconfig |1 +
 arch/arm/mach-omap2/Makefile|2 +
 arch/arm/mach-omap2/board-4430sdp.c |   25 +
 arch/arm/mach-omap2/twl6030_pwm.c   |  168 +++
 4 files changed, 196 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/twl6030_pwm.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b31b6f1..da10997 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -156,6 +156,7 @@ config MACH_OMAP_3630SDP
 config MACH_OMAP_4430SDP
bool "OMAP 4430 SDP board"
depends on ARCH_OMAP4
+   select HAVE_PWM

 config OMAP3_EMU
bool "OMAP3 debugging peripherals"
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 6c6d7c6..778affc 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -161,3 +161,5 @@ obj-y   += $(nand-m) 
$(nand-y)

 smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o
 obj-y  += $(smc91x-m) $(smc91x-y)
+
+obj-$(CONFIG_LEDS_PWM) += twl6030_pwm.o
diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index b213032..b901b9d 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -89,6 +90,29 @@ static struct platform_device sdp4430_leds_gpio = {
.platform_data = &sdp4430_led_data,
},
 };
+
+static struct led_pwm sdp4430_pwm_leds[] = {
+   {
+   .name = "omap4:green:chrg",
+   .pwm_id = 1,
+   .max_brightness = 255,
+   .pwm_period_ns = 7812500,
+   },
+};
+
+static struct led_pwm_platform_data sdp4430_pwm_data = {
+   .num_leds = 1,
+   .leds = sdp4430_pwm_leds,
+};
+
+static struct platform_device sdp4430_leds_pwm = {
+   .name   = "leds_pwm",
+   .id = -1,
+   .dev= {
+   .platform_data = &sdp4430_pwm_data,
+   },
+};
+
 static struct spi_board_info sdp4430_spi_board_info[] __initdata = {
{
.modalias   = "ks8851",
@@ -162,6 +186,7 @@ static struct platform_device sdp4430_lcd_device = {
 static struct platform_device *sdp4430_devices[] __initdata = {
&sdp4430_lcd_device,
&sdp4430_leds_gpio,
+   &sdp4430_leds_pwm,
 };

 static struct omap_lcd_config sdp4430_lcd_config __initdata = {
diff --git a/arch/arm/mach-omap2/twl6030_pwm.c 
b/arch/arm/mach-omap2/twl6030_pwm.c
new file mode 100644
index 000..5140a92
--- /dev/null
+++ b/arch/arm/mach-omap2/twl6030_pwm.c
@@ -0,0 +1,168 @@
+/*
+ * twl6030_pwm.c
+ * Driver for PHOENIX (TWL6030) Pulse Width Modulator
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Hemanth V 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define LED_PWM_CTRL1  0xF4
+#define LED_PWM_CTRL2  0xF5
+
+/* Max value for CTRL1 register */
+#define PWM_CTRL1_MAX  255
+
+/* Pull down disable */
+#define PWM_CTRL2_DIS_PD   (1 << 6)
+
+/* Current control 0, 1, 2.5, 5 mA */
+#define PWM_CTRL2_CURR_00  (0 << 4)
+#define PWM_CTRL2_CURR_01  (1 << 4)
+#define PWM_CTRL2_CURR_02  (2 << 4)
+#define PWM_CTRL2_CURR_05  (3 << 4)
+
+/* LED supply source */
+#define PWM_CTRL2_SRC_VBUS (0 << 2)
+#define PWM_CTRL2_SRC_VAC  (1 << 2)
+#define PWM_CTRL2_SRC_EXT  (2 << 2)
+
+/* LED modes */
+#define PWM_CTRL2_MODE_HW  (0 << 0)
+#define PWM_CTRL2_MODE_SW  (1 << 0)
+#define PWM_CTRL2_MODE_DIS (2 << 0)
+
+#define PWM_CTRL2_MODE_MASK0x3
+
+struct pwm_device {
+   const char *label;
+   unsigned int pwm_id;
+};
+
+int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
+{
+   u8 duty_cycle;
+   int ret;
+
+   if (p

[PATCH 1/2] OMAP4: Add GPIO LED support

[Hemanth V]

>From c17be0bcb4c92df5b5aabdad9034ff7ef427f618 Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Wed, 30 Jun 2010 18:03:09 +0530
Subject: [PATCH] OMAP4: Add GPIO LED support

This patch adds support for GPIO LEDs present on OMAP4
SDP and Blaze boards. This basically adds platform data
required by leds-gpio driver

Signed-off-by: Hemanth V 
---
 arch/arm/mach-omap2/board-4430sdp.c |   50 +++
 1 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 4bb2c5d..b213032 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -40,6 +41,54 @@
 #define ETH_KS8851_POWER_ON48
 #define ETH_KS8851_QUART   138

+static struct gpio_led sdp4430_gpio_leds[] = {
+   {
+   .name   = "omap4:green:debug0",
+   .gpio   = 61,
+   },
+   {
+   .name   = "omap4:green:debug1",
+   .gpio   = 30,
+   },
+   {
+   .name   = "omap4:green:debug2",
+   .gpio   = 7,
+   },
+   {
+   .name   = "omap4:green:debug3",
+   .gpio   = 8,
+   },
+   {
+   .name   = "omap4:green:debug4",
+   .gpio   = 50,
+   },
+   {
+   .name   = "omap4:blue:user",
+   .gpio   = 169,
+   },
+   {
+   .name   = "omap4:red:user",
+   .gpio   = 170,
+   },
+   {
+   .name   = "omap4:green:user",
+   .gpio   = 139,
+   },
+
+};
+
+static struct gpio_led_platform_data sdp4430_led_data = {
+   .leds   = sdp4430_gpio_leds,
+   .num_leds   = ARRAY_SIZE(sdp4430_gpio_leds),
+};
+
+static struct platform_device sdp4430_leds_gpio = {
+   .name   = "leds-gpio",
+   .id = -1,
+   .dev= {
+   .platform_data = &sdp4430_led_data,
+   },
+};
 static struct spi_board_info sdp4430_spi_board_info[] __initdata = {
{
.modalias   = "ks8851",
@@ -112,6 +161,7 @@ static struct platform_device sdp4430_lcd_device = {

 static struct platform_device *sdp4430_devices[] __initdata = {
&sdp4430_lcd_device,
+   &sdp4430_leds_gpio,
 };

 static struct omap_lcd_config sdp4430_lcd_config __initdata = {
-- 
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 V2] misc : ROHM BH1780GLI Ambient light sensor Driver

[Hemanth V]

- Original Message - 
From: "Andrew Morton" 

To: "Jonathan Cameron" 
Cc: "Hemanth V" ; ; 
; "Daniel Mack" ; "Jonathan 
Cameron" ; "Wolfram Sang" 

Sent: Wednesday, June 02, 2010 2:24 AM
Subject: Re: [PATCH V2] misc : ROHM BH1780GLI Ambient light sensor Driver



On Tue, 01 Jun 2010 21:39:10 +0100
Jonathan Cameron  wrote:


>
> It would be most useful if the changelog were to fully describe the
> proposed kernel<->userspace interface.  That's the most important part
> of the driver, because it's the only part we can never change.
>
> There is a desultory effort to maintain sysfs API descriptions under
> Documentation/ABI/.  I'd have thought that it would be appropriate to
> document this driver's ABI in there.
Agreed, but we get back to the debate of what we should standardise on.


I'd suggest standardising on one of the existing drivers.  That way we
have two compliant drivers and only need to change (n-2) others.  If we
pick some new standard then we need to change (n) drivers.



Currently this driver follows the same sysfs convention as supported
by isl29003.c in drivers/misc. 


--
To unsubscribe from this list: send the line "unsubscribe 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 V2 2/2] Platform changes for CMA3000

[Hemanth V]

- Original Message - 
From: "Tony Lindgren" 

To: "Hemanth V" 
Cc: ; ; 


Sent: Tuesday, June 01, 2010 2:05 PM
Subject: Re: [RFC ] [PATCH V2 2/2] Platform changes for CMA3000



* Hemanth V  [100521 09:49]:

From: Hemanth V 
Date: Thu, 20 May 2010 20:33:03 +0530
Subject: [PATCH] Platform changes for CMA3000 Accelerometer driver


Patch description?

This basically adds platform changes i.e platform data and GPIO 
configuration.
Thought I could get away without duplicating the info :) 


--
To unsubscribe from this list: send the line "unsubscribe 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] misc : ROHM BH1780GLI Ambient light sensor Driver

[Hemanth V]

- Original Message -
From: "Jonathan Cameron"
> On 05/26/10 09:30, Hemanth V wrote:
>>> From: Hemanth V 
>>> Date: Fri, 21 May 2010 15:52:03 +0530
>>> Subject: [PATCH] misc: ROHM BH1780GLI Ambient light sensor Driver
>>>
>>> This patch adds support for ROHM BH1780GLI Ambient light sensor.
>>>
>>> BH1780 supports I2C interface. Driver supports read/update of power state 
>>> and
>>> read of lux value (through SYSFS). Writing value 3 to power_state enables 
>>> the
>>> sensor and current lux value could be read.
>>>
>> Jonathan, Daniel
>>
>> If there are no more comments, do you know howto push this to linus tree.

> It's in misc, so send a copy (with reference back to review thread)
> to Andrew Morton 
>
> Andrew tends to pick things up eventually for lkml, but he'll notice
> it quicker if you cc him in on relevant emails!
>

Andrew,

Could you pull the patch listed in https://patchwork.kernel.org/patch/101860/

This is version 2 of the patch. Review comments and discussion are listed part
of https://patchwork.kernel.org/patch/101396/

Thanks
Hemanth


--
To unsubscribe from this list: send the line "unsubscribe 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] misc : ROHM BH1780GLI Ambient light sensor Driver

[Hemanth V]

> From: Hemanth V 
> Date: Fri, 21 May 2010 15:52:03 +0530
> Subject: [PATCH] misc: ROHM BH1780GLI Ambient light sensor Driver
>
> This patch adds support for ROHM BH1780GLI Ambient light sensor.
>
> BH1780 supports I2C interface. Driver supports read/update of power state and
> read of lux value (through SYSFS). Writing value 3 to power_state enables the
> sensor and current lux value could be read.
>
Jonathan, Daniel

If there are no more comments, do you know howto push this to linus tree.

Thanks
Hemanth

> Signed-off-by: Hemanth V 
> Reviewed-by: Daniel Mack 
> Acked-by: Jonathan Cameron 
> ---
>  drivers/misc/Kconfig |   10 ++
>  drivers/misc/Makefile|1 +
>  drivers/misc/bh1780gli.c |  273 
> ++
>  3 files changed, 284 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/misc/bh1780gli.c
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 0d0d625..3f5bf0f 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -278,6 +278,16 @@ config SENSORS_TSL2550
> This driver can also be built as a module.  If so, the module
> will be called tsl2550.
>
> +config SENSORS_BH1780
> + tristate "ROHM BH1780GLI ambient light sensor"
> + depends on I2C && SYSFS
> + help
> +   If you say yes here you get support for the ROHM BH1780GLI
> +   ambient light sensor.
> +
> +   This driver can also be built as a module.  If so, the module
> +   will be called bh1780gli.
> +
>  config EP93XX_PWM
>   tristate "EP93xx PWM support"
>   depends on ARCH_EP93XX
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 7b6f7ee..c479d91 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -30,3 +30,4 @@ obj-$(CONFIG_IWMC3200TOP)  += iwmc3200top/
>  obj-y+= eeprom/
>  obj-y+= cb710/
>  obj-$(CONFIG_VMWARE_BALLOON) += vmware_balloon.o
> +obj-$(CONFIG_SENSORS_BH1780) += bh1780gli.o
> diff --git a/drivers/misc/bh1780gli.c b/drivers/misc/bh1780gli.c
> new file mode 100644
> index 000..774531d
> --- /dev/null
> +++ b/drivers/misc/bh1780gli.c
> @@ -0,0 +1,273 @@
> +/*
> + * bh1780gli.c
> + * ROHM Ambient Light Sensor Driver
> + *
> + * Copyright (C) 2010 Texas Instruments
> + * Author: Hemanth V 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define BH1780_REG_CONTROL   0x80
> +#define BH1780_REG_PARTID0x8A
> +#define BH1780_REG_MANFID0x8B
> +#define BH1780_REG_DLOW  0x8C
> +#define BH1780_REG_DHIGH 0x8D
> +
> +#define BH1780_REVMASK   (0xf)
> +#define BH1780_POWMASK   (0x3)
> +#define BH1780_POFF  (0x0)
> +#define BH1780_PON   (0x3)
> +
> +/* power on settling time in ms */
> +#define BH1780_PON_DELAY 2
> +
> +struct bh1780_data {
> + struct i2c_client *client;
> + int power_state;
> + /* lock for sysfs operations */
> + struct mutex lock;
> +};
> +
> +static int bh1780_write(struct bh1780_data *ddata, u8 reg, u8 val, char *msg)
> +{
> + int ret = i2c_smbus_write_byte_data(ddata->client, reg, val);
> + if (ret < 0)
> + dev_err(&ddata->client->dev,
> + "i2c_smbus_write_byte_data failed error %d\
> + Register (%s)\n", ret, msg);
> + return ret;
> +}
> +
> +static int bh1780_read(struct bh1780_data *ddata, u8 reg, char *msg)
> +{
> + int ret = i2c_smbus_read_byte_data(ddata->client, reg);
> + if (ret < 0)
> + dev_err(&ddata->client->dev,
> + "i2c_smbus_read_byte_data failed error %d\
> +  Register (%s)\n", ret, msg);
> + return ret;
> +}
> +
> +static ssize_t bh1780_show_lux(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + s

[PATCH V2] misc : ROHM BH1780GLI Ambient light sensor Driver

[Hemanth V]

From: Hemanth V 
Date: Fri, 21 May 2010 15:52:03 +0530
Subject: [PATCH] misc: ROHM BH1780GLI Ambient light sensor Driver

This patch adds support for ROHM BH1780GLI Ambient light sensor.

BH1780 supports I2C interface. Driver supports read/update of power state and
read of lux value (through SYSFS). Writing value 3 to power_state enables the
sensor and current lux value could be read.

Signed-off-by: Hemanth V 
Reviewed-by: Daniel Mack 
Acked-by: Jonathan Cameron 
---
 drivers/misc/Kconfig |   10 ++
 drivers/misc/Makefile|1 +
 drivers/misc/bh1780gli.c |  273 ++
 3 files changed, 284 insertions(+), 0 deletions(-)
 create mode 100644 drivers/misc/bh1780gli.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 0d0d625..3f5bf0f 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -278,6 +278,16 @@ config SENSORS_TSL2550
  This driver can also be built as a module.  If so, the module
  will be called tsl2550.

+config SENSORS_BH1780
+   tristate "ROHM BH1780GLI ambient light sensor"
+   depends on I2C && SYSFS
+   help
+ If you say yes here you get support for the ROHM BH1780GLI
+ ambient light sensor.
+
+ This driver can also be built as a module.  If so, the module
+ will be called bh1780gli.
+
 config EP93XX_PWM
tristate "EP93xx PWM support"
depends on ARCH_EP93XX
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 7b6f7ee..c479d91 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_IWMC3200TOP)  += iwmc3200top/
 obj-y  += eeprom/
 obj-y  += cb710/
 obj-$(CONFIG_VMWARE_BALLOON)   += vmware_balloon.o
+obj-$(CONFIG_SENSORS_BH1780)   += bh1780gli.o
diff --git a/drivers/misc/bh1780gli.c b/drivers/misc/bh1780gli.c
new file mode 100644
index 000..774531d
--- /dev/null
+++ b/drivers/misc/bh1780gli.c
@@ -0,0 +1,273 @@
+/*
+ * bh1780gli.c
+ * ROHM Ambient Light Sensor Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Hemanth V 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define BH1780_REG_CONTROL 0x80
+#define BH1780_REG_PARTID  0x8A
+#define BH1780_REG_MANFID  0x8B
+#define BH1780_REG_DLOW0x8C
+#define BH1780_REG_DHIGH   0x8D
+
+#define BH1780_REVMASK (0xf)
+#define BH1780_POWMASK (0x3)
+#define BH1780_POFF(0x0)
+#define BH1780_PON (0x3)
+
+/* power on settling time in ms */
+#define BH1780_PON_DELAY   2
+
+struct bh1780_data {
+   struct i2c_client *client;
+   int power_state;
+   /* lock for sysfs operations */
+   struct mutex lock;
+};
+
+static int bh1780_write(struct bh1780_data *ddata, u8 reg, u8 val, char *msg)
+{
+   int ret = i2c_smbus_write_byte_data(ddata->client, reg, val);
+   if (ret < 0)
+   dev_err(&ddata->client->dev,
+   "i2c_smbus_write_byte_data failed error %d\
+   Register (%s)\n", ret, msg);
+   return ret;
+}
+
+static int bh1780_read(struct bh1780_data *ddata, u8 reg, char *msg)
+{
+   int ret = i2c_smbus_read_byte_data(ddata->client, reg);
+   if (ret < 0)
+   dev_err(&ddata->client->dev,
+   "i2c_smbus_read_byte_data failed error %d\
+Register (%s)\n", ret, msg);
+   return ret;
+}
+
+static ssize_t bh1780_show_lux(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct bh1780_data *ddata = platform_get_drvdata(pdev);
+   int lsb, msb;
+
+   lsb = bh1780_read(ddata, BH1780_REG_DLOW, "DLOW");
+   if (lsb < 0)
+   return lsb;
+
+   msb = bh1780_read(ddata, BH1780_REG_DHIGH, "DHIGH");
+   if (msb < 0)
+   return msb;
+
+   return sprintf(buf, "%d\n", (msb << 8) | lsb);
+}
+
+static ssize_t bh1780_show_power_state(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct platform_device *pdev = to_platform_dev

Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver

[Hemanth V]

- Original Message - 
From: "Jonathan Cameron" 

To: "Hemanth V" 
Cc: ; ; 


Sent: Friday, May 21, 2010 5:27 PM
Subject: Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver



On 05/21/10 07:52, Hemanth V wrote:

From: Hemanth V 
Date: Thu, 20 May 2010 20:18:17 +0530
Subject: [PATCH] input: CMA3000 Accelerometer Driver

This patch adds support for CMA3000 Tri-axis accelerometer, which
supports Motion detect, Measurement and Free fall modes.
CMA3000 supports both I2C/SPI bus for communication, currently the
driver supports I2C based communication.

Driver reports acceleration data through input subsystem and supports
sysfs for configuration changes.

This is V2 of patch, which fixes open source review comments



Hi,

The driver is nice and clean.

Still leaving aside the long argued question of whether this should be
in input.  If you care for my views on that there are plenty or other
threads! There are a few things I'd still like to suggest:
Attribute naming:  The names you have gone with are way too short. The
  documentation helps, but if possible it is always nice to have
  names that are effectively human readable. 'mdfftmr' is rather
  cryptic!   Also I know you aren't trying to write a general
  interface here, but it would be nice if the units of these
  magic attributes were not dependant on the current mode.
  The snag here is that this is a user visible interface, so it
  is rather frowned upon to change it later.  I guess you could
  get away with adding some more attributes, say:
  mdfftmr_scale (which could just be a string and hence floating point)



I have tried to keep the same naming convention as mentioned in
product specs for easy reference.


Documentation: I'd have prefered to see the sysfs attributes documented
   in Documentation/abi/  (but that is just a matter of personal
   taste. I don't think there are any hard and fast rules on this
   yet)

I'm still not keen on naming the files with a wild card. Also, if the d0x
is relevant, why is this not reflected in Kconfig?



Yes I can add it to Kconfig, basically this again comes from product
specs


The one thing that really bothers me is the setting of a precendent
wrt to the attribute naming.

What you have here won't generalise well, particularly wrt to controls
relating to the on chip motion and free fall detectors.  We've been round
the houses with this in IIO and I fully admit we still haven't gotten it
right there.  The advantage on this stuff that we have is that, as we
are in staging, we can mess around the userspace abi till we get it right.
In mainline things are by convention much more rigid!

Still it's a good driver and obviously some of the above issues are pretty
general.

To that end, having stated my reservations, you can add

Reviewed-by: Jonathan Cameron 


Thanks, will add the same to patch




(not ack as I'm indicating that whilst I think it is a worthwhile addition
I'm not entirely happy with some aspects of the driver).



Signed-off-by: Hemanth V 
Cc: Dmitry Torokhov 
---
 Documentation/input/cma3000_d0x.txt  |  112 ++
 drivers/input/misc/Kconfig   |7 +
 drivers/input/misc/Makefile  |1 +
 drivers/input/misc/cma3000_d0x.c |  633 
++

 drivers/input/misc/cma3000_d0x.h |   46 +++
 drivers/input/misc/cma3000_d0x_i2c.c |  136 
 include/linux/i2c/cma3000.h  |   60 
 7 files changed, 995 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/input/cma3000_d0x.txt
 create mode 100644 drivers/input/misc/cma3000_d0x.c
 create mode 100644 drivers/input/misc/cma3000_d0x.h
 create mode 100644 drivers/input/misc/cma3000_d0x_i2c.c
 create mode 100644 include/linux/i2c/cma3000.h

diff --git a/Documentation/input/cma3000_d0x.txt 
b/Documentation/input/cma3000_d0x.txt

new file mode 100644
index 000..29ab6b7
--- /dev/null
+++ b/Documentation/input/cma3000_d0x.txt
@@ -0,0 +1,112 @@
+Kernel driver for CMA3000-D0x
+
+
+Supported chips:
+* VTI CMA3000-D0x
+Datasheet:
+  CMA3000-D0X Product Family Specification 8281000A.02.pdf
+
+Author: Hemanth V 
+
+
+Description
+---
+CMA3000 Tri-axis accelerometer supports Motion detect, Measurement and
+Free fall modes.
+
+Motion Detect Mode: Its the low power mode where interrupts are 
generated only

+when motion exceeds the defined thresholds.
+
+Measurement Mode: This mode is used to read the acceleration data on 
X,Y,Z

+axis and supports 400, 100, 40 Hz sample frequency.
+
+Free fall Mode: This mode is intented to save system resources.
+
+Threshold values: Chip supports defining threshold values for above 
modes
+which includes time and g value. Refer product specifications for more 
details.

+
+CMA3000 supports both I2C/SPI bus for communication, currently the 
driver

+supports I2C based communication.
+
+Driver reports accelera

Re: [RFC] [PATCH] misc : ROHM BH1780GLI Ambient light sensor Driver

[Hemanth V]

- Original Message - 
From: "Daniel Mack" 

To: "Hemanth V" 
Cc: ; ; 


Sent: Friday, May 21, 2010 6:16 PM
Subject: Re: [RFC] [PATCH] misc : ROHM BH1780GLI Ambient light sensor Driver



On Fri, May 21, 2010 at 06:10:00PM +0530, Hemanth V wrote:

>On Fri, May 21, 2010 at 05:05:50PM +0530, Hemanth V wrote:
>>+ mutex_lock(&ddata->lock);
>>+
>>+ error = bh1780_write(ddata, BH1780_REG_CONTROL, val, "CONTROL");
>>+ if (error < 0) {
>>+ mutex_unlock(&ddata->lock);
>>+ return error;
>>+ }
>>+
>>+ msleep(BH1780_PON_DELAY);
>
>Hmm, what do you wait for here?

Settling time delay required before lux read out


I thought so, but in fact you're just delaying the next two lines by
that:


>>+ ddata->power_state = val;
>>+ mutex_unlock(&ddata->lock);


... which doesn't make sense to me.

I can believe there is need to wait for the value to settle, but I think
it's the wrong place where you're doing it currently.



I could move it one line down,  but not really release the mutex.
Which other place would you suggest.


--
To unsubscribe from this list: send the line "unsubscribe 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] misc : ROHM BH1780GLI Ambient light sensor Driver

[Hemanth V]

- Original Message - 
From: "Daniel Mack" 

To: "Hemanth V" 
Cc: ; ; 


Sent: Friday, May 21, 2010 5:33 PM
Subject: Re: [RFC] [PATCH] misc : ROHM BH1780GLI Ambient light sensor Driver



Hi,

On Fri, May 21, 2010 at 05:05:50PM +0530, Hemanth V wrote:

Corrected the mailing list, should be linux-kernel

This patch adds support for ROHM BH1780GLI Ambient light sensor.

BH1780 supports I2C interface. Driver supports read/update of power state 
and
read of lux value (through SYSFS). Writing value 3 to power_state enables 
the

sensor and current lux value could be read.


FWIW, this looks pretty good to me, just some minor things below.


Thanks for the review comment, responses inline



Daniel


Signed-off-by: Hemanth V 
---
 drivers/misc/Kconfig |   11 ++
 drivers/misc/Makefile|1 +
 drivers/misc/bh1780gli.c |  278 
++

 3 files changed, 290 insertions(+), 0 deletions(-)
 create mode 100644 drivers/misc/bh1780gli.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 0d0d625..0687a0c 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -278,6 +278,17 @@ config SENSORS_TSL2550
   This driver can also be built as a module.  If so, the module
   will be called tsl2550.

+config SENSORS_BH1780
+ tristate "ROHM BH1780GLI ambient light sensor"
+ depends on I2C && SYSFS
+ help
+   If you say yes here you get support for the ROHM BH1780GLI
+   ambient light sensor.
+
+   This driver can also be built as a module.  If so, the module
+   will be called bh1780gli.
+
+
 config EP93XX_PWM
 tristate "EP93xx PWM support"
 depends on ARCH_EP93XX
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 7b6f7ee..c479d91 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_IWMC3200TOP)  += iwmc3200top/
 obj-y += eeprom/
 obj-y += cb710/
 obj-$(CONFIG_VMWARE_BALLOON) += vmware_balloon.o
+obj-$(CONFIG_SENSORS_BH1780) += bh1780gli.o
diff --git a/drivers/misc/bh1780gli.c b/drivers/misc/bh1780gli.c
new file mode 100644
index 000..9b4137d
--- /dev/null
+++ b/drivers/misc/bh1780gli.c
@@ -0,0 +1,278 @@
+/*
+ * bh1780gli.c
+ * ROHM Ambient Light Sensor Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Hemanth V 
+ *
+ * This program is free software; you can redistribute it and/or modify 
it
+ * under the terms of the GNU General Public License version 2 as 
published by

+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but 
WITHOUT

+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License 
for

+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License 
along with

+ * this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define BH1780_REG_CONTROL 0x80
+#define BH1780_REG_PARTID  0x8A
+#define BH1780_REG_MANFID  0x8B
+#define BH1780_REG_DLOW0x8C
+#define BH1780_REG_DHIGH   0x8D
+
+#define BH1780_REVMASK(0xf)
+#define BH1780_POWMASK(0x3)
+#define BH1780_POFF   (0x0)
+#define BH1780_PON(0x3)


Just a nit ... something's wrong with the indentation here.


Will fix




+/* power on settling time in ms */
+#define BH1780_PON_DELAY  2
+
+struct bh1780_data {
+ struct i2c_client *client;
+ int power_state;
+ /* lock for sysfs operations */
+ struct mutex lock;
+};
+
+int bh1780_write(struct bh1780_data *ddata, u8 reg, u8 val, char *msg)


Should be static.


Yes, agreed



+{
+ int ret = i2c_smbus_write_byte_data(ddata->client, reg, val);
+ if (ret < 0)
+ dev_err(&ddata->client->dev,
+ "i2c_smbus_write_byte_data failed error %d\
+ Register (%s)\n", ret, msg);
+ return ret;
+}
+
+int bh1780_read(struct bh1780_data *ddata, u8 reg, char *msg)


Dito.


Yes, agreed



+{
+ int ret = i2c_smbus_read_byte_data(ddata->client, reg);
+ if (ret < 0)
+ dev_err(&ddata->client->dev,
+ "i2c_smbus_read_byte_data failed error %d\
+ Register (%s)\n", ret, msg);
+ return ret;
+}
+
+static ssize_t bh1780_show_lux(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+
+ struct platform_device *pdev = to_platform_device(dev);
+ struct bh1780_data *ddata = platform_get_drvdata(pdev);
+ int lsb, msb;
+
+ lsb = bh1780_read(ddata, BH1780_REG_DLOW, "DLOW");
+ if (lsb < 0)
+ return lsb;
+
+ msb = bh1780_read(ddata, BH1780_REG_DHIGH, "DHIGH");
+ if (msb < 0)
+ return msb;
+
+ return sprintf(buf, "%d\n", (msb << 8) | lsb);
+}
+
+static ssize_t bh1780_show_power_state(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct bh1780_data *ddata = platform_get_drvdata(

[RFC] [PATCH] misc : ROHM BH1780GLI Ambient light sensor Driver

[Hemanth V]

From: Hemanth V 
Date: Fri, 21 May 2010 15:52:03 +0530
Subject: [PATCH] misc: ROHM BH1780GLI Ambient light sensor Driver

Corrected the mailing list, should be linux-kernel

This patch adds support for ROHM BH1780GLI Ambient light sensor.

BH1780 supports I2C interface. Driver supports read/update of power state and
read of lux value (through SYSFS). Writing value 3 to power_state enables the
sensor and current lux value could be read.

Signed-off-by: Hemanth V 
---
 drivers/misc/Kconfig |   11 ++
 drivers/misc/Makefile|1 +
 drivers/misc/bh1780gli.c |  278 ++
 3 files changed, 290 insertions(+), 0 deletions(-)
 create mode 100644 drivers/misc/bh1780gli.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 0d0d625..0687a0c 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -278,6 +278,17 @@ config SENSORS_TSL2550
  This driver can also be built as a module.  If so, the module
  will be called tsl2550.

+config SENSORS_BH1780
+   tristate "ROHM BH1780GLI ambient light sensor"
+   depends on I2C && SYSFS
+   help
+ If you say yes here you get support for the ROHM BH1780GLI
+ ambient light sensor.
+
+ This driver can also be built as a module.  If so, the module
+ will be called bh1780gli.
+
+
 config EP93XX_PWM
tristate "EP93xx PWM support"
depends on ARCH_EP93XX
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 7b6f7ee..c479d91 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_IWMC3200TOP)  += iwmc3200top/
 obj-y  += eeprom/
 obj-y  += cb710/
 obj-$(CONFIG_VMWARE_BALLOON)   += vmware_balloon.o
+obj-$(CONFIG_SENSORS_BH1780)   += bh1780gli.o
diff --git a/drivers/misc/bh1780gli.c b/drivers/misc/bh1780gli.c
new file mode 100644
index 000..9b4137d
--- /dev/null
+++ b/drivers/misc/bh1780gli.c
@@ -0,0 +1,278 @@
+/*
+ * bh1780gli.c
+ * ROHM Ambient Light Sensor Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Hemanth V 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define BH1780_REG_CONTROL 0x80
+#define BH1780_REG_PARTID  0x8A
+#define BH1780_REG_MANFID  0x8B
+#define BH1780_REG_DLOW0x8C
+#define BH1780_REG_DHIGH   0x8D
+
+#define BH1780_REVMASK(0xf)
+#define BH1780_POWMASK(0x3)
+#define BH1780_POFF  (0x0)
+#define BH1780_PON(0x3)
+
+/* power on settling time in ms */
+#define BH1780_PON_DELAY  2
+
+struct bh1780_data {
+   struct i2c_client *client;
+   int power_state;
+   /* lock for sysfs operations */
+   struct mutex lock;
+};
+
+int bh1780_write(struct bh1780_data *ddata, u8 reg, u8 val, char *msg)
+{
+   int ret = i2c_smbus_write_byte_data(ddata->client, reg, val);
+   if (ret < 0)
+   dev_err(&ddata->client->dev,
+   "i2c_smbus_write_byte_data failed error %d\
+   Register (%s)\n", ret, msg);
+   return ret;
+}
+
+int bh1780_read(struct bh1780_data *ddata, u8 reg, char *msg)
+{
+   int ret = i2c_smbus_read_byte_data(ddata->client, reg);
+   if (ret < 0)
+   dev_err(&ddata->client->dev,
+   "i2c_smbus_read_byte_data failed error %d\
+Register (%s)\n", ret, msg);
+   return ret;
+}
+
+static ssize_t bh1780_show_lux(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+
+   struct platform_device *pdev = to_platform_device(dev);
+   struct bh1780_data *ddata = platform_get_drvdata(pdev);
+   int lsb, msb;
+
+   lsb = bh1780_read(ddata, BH1780_REG_DLOW, "DLOW");
+   if (lsb < 0)
+   return lsb;
+
+   msb = bh1780_read(ddata, BH1780_REG_DHIGH, "DHIGH");
+   if (msb < 0)
+   return msb;
+
+   return sprintf(buf, "%d\n", (msb << 8) | lsb);
+}
+
+static ssize_t bh1780_show_power_state(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct platform_device *pdev = to_platform_dev

[RFC] [PATCH] misc : ROHM BH1780GLI Ambient light sensor Driver

[Hemanth V]

From: Hemanth V 
Date: Fri, 21 May 2010 15:52:03 +0530
Subject: [PATCH] misc: ROHM BH1780GLI Ambient light sensor Driver

This patch adds support for ROHM BH1780GLI Ambient light sensor.

BH1780 supports I2C interface. Driver supports read/update of power state and
read of lux value (through SYSFS). Writing value 3 to power_state enables the
sensor and current lux value could be read.

Signed-off-by: Hemanth V 
---
 drivers/misc/Kconfig |   11 ++
 drivers/misc/Makefile|1 +
 drivers/misc/bh1780gli.c |  278 ++
 3 files changed, 290 insertions(+), 0 deletions(-)
 create mode 100644 drivers/misc/bh1780gli.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 0d0d625..0687a0c 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -278,6 +278,17 @@ config SENSORS_TSL2550
  This driver can also be built as a module.  If so, the module
  will be called tsl2550.

+config SENSORS_BH1780
+   tristate "ROHM BH1780GLI ambient light sensor"
+   depends on I2C && SYSFS
+   help
+ If you say yes here you get support for the ROHM BH1780GLI
+ ambient light sensor.
+
+ This driver can also be built as a module.  If so, the module
+ will be called bh1780gli.
+
+
 config EP93XX_PWM
tristate "EP93xx PWM support"
depends on ARCH_EP93XX
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 7b6f7ee..c479d91 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_IWMC3200TOP)  += iwmc3200top/
 obj-y  += eeprom/
 obj-y  += cb710/
 obj-$(CONFIG_VMWARE_BALLOON)   += vmware_balloon.o
+obj-$(CONFIG_SENSORS_BH1780)   += bh1780gli.o
diff --git a/drivers/misc/bh1780gli.c b/drivers/misc/bh1780gli.c
new file mode 100644
index 000..9b4137d
--- /dev/null
+++ b/drivers/misc/bh1780gli.c
@@ -0,0 +1,278 @@
+/*
+ * bh1780gli.c
+ * ROHM Ambient Light Sensor Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Hemanth V 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define BH1780_REG_CONTROL 0x80
+#define BH1780_REG_PARTID  0x8A
+#define BH1780_REG_MANFID  0x8B
+#define BH1780_REG_DLOW0x8C
+#define BH1780_REG_DHIGH   0x8D
+
+#define BH1780_REVMASK(0xf)
+#define BH1780_POWMASK(0x3)
+#define BH1780_POFF  (0x0)
+#define BH1780_PON(0x3)
+
+/* power on settling time in ms */
+#define BH1780_PON_DELAY  2
+
+struct bh1780_data {
+   struct i2c_client *client;
+   int power_state;
+   /* lock for sysfs operations */
+   struct mutex lock;
+};
+
+int bh1780_write(struct bh1780_data *ddata, u8 reg, u8 val, char *msg)
+{
+   int ret = i2c_smbus_write_byte_data(ddata->client, reg, val);
+   if (ret < 0)
+   dev_err(&ddata->client->dev,
+   "i2c_smbus_write_byte_data failed error %d\
+   Register (%s)\n", ret, msg);
+   return ret;
+}
+
+int bh1780_read(struct bh1780_data *ddata, u8 reg, char *msg)
+{
+   int ret = i2c_smbus_read_byte_data(ddata->client, reg);
+   if (ret < 0)
+   dev_err(&ddata->client->dev,
+   "i2c_smbus_read_byte_data failed error %d\
+Register (%s)\n", ret, msg);
+   return ret;
+}
+
+static ssize_t bh1780_show_lux(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+
+   struct platform_device *pdev = to_platform_device(dev);
+   struct bh1780_data *ddata = platform_get_drvdata(pdev);
+   int lsb, msb;
+
+   lsb = bh1780_read(ddata, BH1780_REG_DLOW, "DLOW");
+   if (lsb < 0)
+   return lsb;
+
+   msb = bh1780_read(ddata, BH1780_REG_DHIGH, "DHIGH");
+   if (msb < 0)
+   return msb;
+
+   return sprintf(buf, "%d\n", (msb << 8) | lsb);
+}
+
+static ssize_t bh1780_show_power_state(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct bh1780_data *ddata = platform_

[RFC ] [PATCH V2 2/2] Platform changes for CMA3000

[Hemanth V]

From: Hemanth V 
Date: Thu, 20 May 2010 20:33:03 +0530
Subject: [PATCH] Platform changes for CMA3000 Accelerometer driver


Signed-off-by: Hemanth V 
---
 arch/arm/mach-omap2/board-4430sdp.c |   37 ++-
 1 files changed, 36 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 3005558..b5b3d0b 100755
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -19,9 +19,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -66,6 +68,8 @@ static struct platform_device sdp4430_proximity_device = {
},
 };

+#define OMAP4_CMA3000ACCL_GPIO 186
+
 static int sdp4430_keymap[] = {
KEY(0, 0, KEY_E),
KEY(0, 1, KEY_R),
@@ -575,6 +579,18 @@ static struct twl4030_platform_data sdp4430_twldata = {
.vaux3  = &sdp4430_vaux3,
 };

+static struct cma3000_platform_data cma3000_platform_data = {
+   .fuzz_x = 25,
+   .fuzz_y = 25,
+   .fuzz_z = 25,
+   .g_range = CMARANGE_8G,
+   .mode = CMAMODE_MOTDET,
+   .mdthr = 0x8,
+   .mdfftmr = 0x33,
+   .ffthr = 0x8,
+   .irqflags = IRQF_TRIGGER_HIGH,
+};
+
 static struct i2c_board_info __initdata sdp4430_i2c_boardinfo[] = {
{
I2C_BOARD_INFO("twl6030", 0x48),
@@ -598,6 +614,14 @@ static struct i2c_board_info __initdata 
sdp4430_i2c_3_boardinfo[] = {
},
 };

+static struct i2c_board_info __initdata sdp4430_i2c_4_boardinfo[] = {
+   {
+   I2C_BOARD_INFO("cma3000_accl", 0x1c),
+   .platform_data = &cma3000_platform_data,
+   .irq = OMAP_GPIO_IRQ(OMAP4_CMA3000ACCL_GPIO),
+   },
+};
+
 static int __init omap4_i2c_init(void)
 {
/* Phoenix Audio IC needs I2C1 to start with 400 KHz and less */
@@ -607,7 +631,8 @@ static int __init omap4_i2c_init(void)
ARRAY_SIZE(sdp4430_i2c_2_boardinfo));
omap_register_i2c_bus(3, 400, sdp4430_i2c_3_boardinfo,
ARRAY_SIZE(sdp4430_i2c_3_boardinfo));
-   omap_register_i2c_bus(4, 400, NULL, 0);
+   omap_register_i2c_bus(4, 400, sdp4430_i2c_4_boardinfo,
+   ARRAY_SIZE(sdp4430_i2c_4_boardinfo));
return 0;
 }

@@ -661,6 +686,15 @@ fail1:
gpio_free(OMAP4_SFH7741_SENSOR_OUTPUT_GPIO);
 }

+static void omap_cma3000accl_init(void)
+{
+   if (gpio_request(OMAP4_CMA3000ACCL_GPIO, "Accelerometer") < 0) {
+   pr_err("Accelerometer GPIO request failed\n");
+   return;
+   }
+   gpio_direction_input(OMAP4_CMA3000ACCL_GPIO);
+}
+
 static void __init omap_4430sdp_init(void)
 {
int status;
@@ -686,6 +720,7 @@ static void __init omap_4430sdp_init(void)
ARRAY_SIZE(sdp4430_spi_board_info));
}
omap_sfh7741prox_init();
+   omap_cma3000accl_init();
 }

 static void __init omap_4430sdp_map_io(void)
-- 
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

[RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver

[Hemanth V]

From: Hemanth V 
Date: Thu, 20 May 2010 20:18:17 +0530
Subject: [PATCH] input: CMA3000 Accelerometer Driver

This patch adds support for CMA3000 Tri-axis accelerometer, which
supports Motion detect, Measurement and Free fall modes.
CMA3000 supports both I2C/SPI bus for communication, currently the
driver supports I2C based communication.

Driver reports acceleration data through input subsystem and supports
sysfs for configuration changes.

This is V2 of patch, which fixes open source review comments

Signed-off-by: Hemanth V 
Cc: Dmitry Torokhov 
---
 Documentation/input/cma3000_d0x.txt  |  112 ++
 drivers/input/misc/Kconfig   |7 +
 drivers/input/misc/Makefile  |1 +
 drivers/input/misc/cma3000_d0x.c |  633 ++
 drivers/input/misc/cma3000_d0x.h |   46 +++
 drivers/input/misc/cma3000_d0x_i2c.c |  136 
 include/linux/i2c/cma3000.h  |   60 
 7 files changed, 995 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/input/cma3000_d0x.txt
 create mode 100644 drivers/input/misc/cma3000_d0x.c
 create mode 100644 drivers/input/misc/cma3000_d0x.h
 create mode 100644 drivers/input/misc/cma3000_d0x_i2c.c
 create mode 100644 include/linux/i2c/cma3000.h

diff --git a/Documentation/input/cma3000_d0x.txt 
b/Documentation/input/cma3000_d0x.txt
new file mode 100644
index 000..29ab6b7
--- /dev/null
+++ b/Documentation/input/cma3000_d0x.txt
@@ -0,0 +1,112 @@
+Kernel driver for CMA3000-D0x
+
+
+Supported chips:
+* VTI CMA3000-D0x
+Datasheet:
+  CMA3000-D0X Product Family Specification 8281000A.02.pdf
+
+Author: Hemanth V 
+
+
+Description
+---
+CMA3000 Tri-axis accelerometer supports Motion detect, Measurement and
+Free fall modes.
+
+Motion Detect Mode: Its the low power mode where interrupts are generated only
+when motion exceeds the defined thresholds.
+
+Measurement Mode: This mode is used to read the acceleration data on X,Y,Z
+axis and supports 400, 100, 40 Hz sample frequency.
+
+Free fall Mode: This mode is intented to save system resources.
+
+Threshold values: Chip supports defining threshold values for above modes
+which includes time and g value. Refer product specifications for more details.
+
+CMA3000 supports both I2C/SPI bus for communication, currently the driver
+supports I2C based communication.
+
+Driver reports acceleration data through input subsystem and supports sysfs
+for configuration changes. It generates ABS_MISC event with value 1 when
+free fall is detected.
+
+Platform data need to be configured for initial default values.
+
+Platform Data
+-
+fuzz_x: Noise on X Axis
+
+fuzz_y: Noise on Y Axis
+
+fuzz_z: Noise on Z Axis
+
+g_range: G range in milli g i.e 2000 or 8000
+
+mode: Default Operating mode
+
+mdthr: Motion detect threshold value
+
+mdfftmr: Motion detect and free fall time value
+
+ffthr: Free fall threshold value
+
+Input Interface
+--
+Input driver version is 1.0.0
+Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0
+Input device name: "cma3000-acclerometer"
+Supported events:
+  Event type 0 (Sync)
+  Event type 3 (Absolute)
+Event code 0 (X)
+  Value 47
+  Min-8000
+  Max 8000
+  Fuzz 200
+Event code 1 (Y)
+  Value-28
+  Min-8000
+  Max 8000
+  Fuzz 200
+Event code 2 (Z)
+  Value905
+  Min-8000
+  Max 8000
+  Fuzz 200
+Event code 40 (Misc)
+  Value  0
+  Min0
+  Max1
+  Event type 4 (Misc)
+
+Sysfs entries
+-
+
+mode:
+   0: power down mode
+   1: 100 Hz Measurement mode
+   2: 400 Hz Measurement mode
+   3: 40 Hz Measurement mode
+   4: Motion Detect mode (default)
+   5: 100 Hz Free fall mode
+   6: 40 Hz Free fall mode
+   7: Power off mode
+
+grange:
+   2000: 2000 mg or 2G Range
+   8000: 8000 mg or 8G Range
+
+mdthr:
+   X: X * 71mg (8G Range)
+   X: X * 18mg (2G Range)
+
+mdfftmr:
+   X: (X & 0x70) * 100 ms (MDTMR)
+  (X & 0x0F) * 2.5 ms (FFTMR 400 Hz)
+  (X & 0x0F) * 10 ms  (FFTMR 100 Hz)
+
+ffthr:
+   X: (X >> 2) * 18mg (2G Range)
+   X: (X & 0x0F) * 71 mg (8G Range)
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 1cf25ee..043ee8d 100755
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -340,4 +340,11 @@
  To compile this driver as a module, choose M here: the
  module will be called pcap_keys.

+config INPUT_CMA3000_I2C
+   bool "VTI CMA3000 Tri-axis accelerometer"
+   depends on I2C && SYSFS
+   help
+ Say Y here if you want to use VTI CMA3000 Accelerometer
+ through I2C interface.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 07ee237..011161d 100644
--- a/drivers/input/misc/Makefile
+++ b/

Re: [RFC][PATCHv3 1/2] SFH7741: proximity sensor driver support

[Hemanth V]

> On Thu, May 13, 2010 at 12:16:16PM +0530, Hemanth V wrote:
>> - Original Message - From: "Christoph Fritz"
>> 
>> To: "Dmitry Torokhov" 
>> Cc: "Jonathan Cameron" ; "Datta, Shubhrajyoti"
>> ; ;
>> 
>> Sent: Thursday, May 13, 2010 1:38 AM
>> Subject: Re: [RFC][PATCHv3 1/2] SFH7741: proximity sensor driver support
>>
>>
>> >On Wed, 2010-05-12 at 11:29 -0700, Dmitry Torokhov wrote:
>> >>On Wed, May 12, 2010 at 07:15:22PM +0100, Jonathan Cameron wrote:
>> >>> Hi,
>> >>>
>> >>> I was wondering if you could provide a bit more detail on what this
>> >>> driver is actually doing?  My appologies if I have missed a
>> >>> previous explanation.  If so, please add a Documentation file
>> >>> to explain what is going on.
>> >>>
>> >>> The driver you have here does virtually nothing itself.  It takes
>> >>> both its source of interrupt and read function from platform
>> >>> data. Given the value is always 0 or 1, I'm guessing you are
>> >>> simply reading a gpio pin. That makes this effectively a button
>> >>> and doesn't require any specific code.  The fact it is a
>> >>> proximity sensor isn't relevant to anything other than perhaps
>> >>> the name.
>> >>
>> >>Excellent point. Maybe it should simply use gpio_keys driver with
>> >>SW_FRONT_PROXIMITY code.
>> >>
>> >
>> >I had a look into the datasheet, this SFH 7741 has one Schmitt trigger
>> >output: So yes, it's a "key" even without chatter.
>> >
>> Output being configured as GPIO  is specific to OMAP4 board, SFH7741
>> doesnot really
>> mandate this. The idea behind this driver is to provide a generic
>> interface and
>> hooks for platform specific configuration.
>>
>
> Realistically, what are the options though? The only sane solution is to
> hook it to a GPIO pin, isn't it?
>

One option I could think of is that output could be configured directly as
an interrupt line, rather than a gpio based interrupt. Yes, probably
gpio would be the most used option, but it would be good to make the driver
generic





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

Re: [RFC] [PATCH 1/2] CMA3000 Accelerometer Driver

[Hemanth V]

- Original Message -
From: "Jonathan Cameron" 
>
> Hi Hemanth,
>
> Quick comments below.  I haven't commented much on the
> input aspects, just stuck to the more general driver aspects.

Thanks for the comments, responses inline. I am hoping for
some more wider review.

> As ever at the moment, the should this be in input question is
> open, but if Dmitry is happy to take it then that's fine with me.
>

Dmitry, your thoughts on this

> Jonathan
>
>>>From d2842ba67e142e78b2554cebb01341c76b84b693 Mon Sep 17 00:00:00 2001
>> From: Hemanth V 
>> Date: Fri, 30 Apr 2010 11:55:10 +0530
>> Subject: [PATCH] CMA3000 Accelerometer Driver
>>
>> This patch adds support for CMA3000 Tri-axis accelerometer, which
>> supports Motion detect, Measurement and Free fall modes.
>> CMA3000 supports both I2C/SPI bus for communication, currently the
>> driver supports I2C based communication.
>>
>> Driver reports acceleration data through input subsystem and supports
>> sysfs for configuration changes.
>>
>> This chip is currently used with OMAP4 based boards
>>
>> Thanks to Ossi Kauppinen  for the support
>> provided during development
>>
>> Signed-off-by: Hemanth V 
>> ---
>>  drivers/input/misc/Kconfig   |9 +
>>  drivers/input/misc/Makefile  |1 +
>>  drivers/input/misc/cma3000_d0x.c |  627 
>> ++
>>  drivers/input/misc/cma3000_d0x.h |   46 +++
>>  drivers/input/misc/cma3000_d0x_i2c.c |  136 
>>  include/linux/i2c/cma3000.h  |   60 
>>  6 files changed, 879 insertions(+), 0 deletions(-)
> General convention is pick a device and name driver after it. Avoids confusion
> in future.

I am not sure I fully understand your comment, cma3000 being the family and 
cma300_d0x
being the specific chip

>>  create mode 100644 drivers/input/misc/cma3000_d0x.c
>>  create mode 100644 drivers/input/misc/cma3000_d0x.h
>>  create mode 100644 drivers/input/misc/cma3000_d0x_i2c.c
>>  create mode 100644 include/linux/i2c/cma3000.h
>>
>> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
>> index 16ec523..4752a00 100644
>> --- a/drivers/input/misc/Kconfig
>> +++ b/drivers/input/misc/Kconfig
>> @@ -319,4 +319,13 @@ config INPUT_PCAP
>>To compile this driver as a module, choose M here: the
>>module will be called pcap_keys.
>>
>> +config INPUT_CMA3000_I2C
>> +tristate "VTI CMA3000 Tri-axis accelerometer"
>> +depends on I2C
>> +help
>> +  Say Y here if you want to use VTI CMA3000 Accelerometer
>> +  through I2C interface.
>> +
>> +  To compile this driver as a module, choose M here: the
>> +  module will be called cma3000_dxx
>>  endif
>> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
>> index a8b8485..94d6eda 100644
>> --- a/drivers/input/misc/Makefile
>> +++ b/drivers/input/misc/Makefile
>> @@ -30,4 +30,4 @@ obj-$(CONFIG_INPUT_WINBOND_CIR)+= winbond-cir.o
>>  obj-$(CONFIG_INPUT_WISTRON_BTNS)+= wistron_btns.o
>>  obj-$(CONFIG_INPUT_WM831X_ON)   += wm831x-on.o
>>  obj-$(CONFIG_INPUT_YEALINK) += yealink.o
>> -
>> +obj-$(CONFIG_INPUT_CMA3000_I2C) += cma3000_d0x_i2c.o 
>> cma3000_d0x.o
>> diff --git a/drivers/input/misc/cma3000_d0x.c 
>> b/drivers/input/misc/cma3000_d0x.c
>> new file mode 100644
>> index 000..c0d0ea1
>> --- /dev/null
>> +++ b/drivers/input/misc/cma3000_d0x.c
>> @@ -0,0 +1,627 @@
>> +/*
>> + * cma3000_d0x.c
>> + * VTI CMA3000_D0x Accelerometer driver
>> + *  Supports I2C/SPI interfaces
> The device, might but I'm not seeing SPI here.  Please clear out the define 
> bits about
> i2c in the code as they aren't currently relevant.

Yes, will add defines related to SPI.


>> + *
>> + * Copyright (C) 2010 Texas Instruments
>> + * Author: Hemanth V 
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published 
>> by
>> + * the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful, but 
>> WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License

Re: [RFC][PATCHv3 1/2] SFH7741: proximity sensor driver support

[Hemanth V]

- Original Message - 
From: "Christoph Fritz" 

To: "Dmitry Torokhov" 
Cc: "Jonathan Cameron" ; "Datta, Shubhrajyoti" 
; ; 


Sent: Thursday, May 13, 2010 1:38 AM
Subject: Re: [RFC][PATCHv3 1/2] SFH7741: proximity sensor driver support



On Wed, 2010-05-12 at 11:29 -0700, Dmitry Torokhov wrote:

On Wed, May 12, 2010 at 07:15:22PM +0100, Jonathan Cameron wrote:
> Hi,
>
> I was wondering if you could provide a bit more detail on what this
> driver is actually doing?  My appologies if I have missed a
> previous explanation.  If so, please add a Documentation file
> to explain what is going on.
>
> The driver you have here does virtually nothing itself.  It takes
> both its source of interrupt and read function from platform
> data. Given the value is always 0 or 1, I'm guessing you are
> simply reading a gpio pin. That makes this effectively a button
> and doesn't require any specific code.  The fact it is a
> proximity sensor isn't relevant to anything other than perhaps
> the name.

Excellent point. Maybe it should simply use gpio_keys driver with
SW_FRONT_PROXIMITY code.



I had a look into the datasheet, this SFH 7741 has one Schmitt trigger
output: So yes, it's a "key" even without chatter.

Output being configured as GPIO  is specific to OMAP4 board, SFH7741 doesnot 
really
mandate this. The idea behind this driver is to provide a generic interface 
and

hooks for platform specific configuration.

Will using gpio_keys make this very specific to platform configuration.

Thanks
Hemanth



--
To unsubscribe from this list: send the line "unsubscribe 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: [RFC] [PATCH 1/2] CMA3000 Accelerometer Driver

[Hemanth V]

> From d2842ba67e142e78b2554cebb01341c76b84b693 Mon Sep 17 00:00:00 2001
> From: Hemanth V 
> Date: Fri, 30 Apr 2010 11:55:10 +0530
> Subject: [PATCH] CMA3000 Accelerometer Driver
>
> This patch adds support for CMA3000 Tri-axis accelerometer, which
> supports Motion detect, Measurement and Free fall modes.
> CMA3000 supports both I2C/SPI bus for communication, currently the
> driver supports I2C based communication.

Dimitry, Did you get a chance to look at this
series.

Thanks
Hemanth

>
> Driver reports acceleration data through input subsystem and supports
> sysfs for configuration changes.
>
> This chip is currently used with OMAP4 based boards
>
> Thanks to Ossi Kauppinen  for the support
> provided during development
>
> Signed-off-by: Hemanth V 
> ---
>  drivers/input/misc/Kconfig   |9 +
>  drivers/input/misc/Makefile  |1 +
>  drivers/input/misc/cma3000_d0x.c |  627 
> ++
>  drivers/input/misc/cma3000_d0x.h |   46 +++
>  drivers/input/misc/cma3000_d0x_i2c.c |  136 
>  include/linux/i2c/cma3000.h  |   60 
>  6 files changed, 879 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/input/misc/cma3000_d0x.c
>  create mode 100644 drivers/input/misc/cma3000_d0x.h
>  create mode 100644 drivers/input/misc/cma3000_d0x_i2c.c
>  create mode 100644 include/linux/i2c/cma3000.h
>
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 16ec523..4752a00 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -319,4 +319,13 @@ config INPUT_PCAP
> To compile this driver as a module, choose M here: the
> module will be called pcap_keys.
>
> +config INPUT_CMA3000_I2C
> + tristate "VTI CMA3000 Tri-axis accelerometer"
> + depends on I2C
> + help
> +   Say Y here if you want to use VTI CMA3000 Accelerometer
> +   through I2C interface.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called cma3000_dxx
>  endif
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index a8b8485..94d6eda 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -30,4 +30,4 @@ obj-$(CONFIG_INPUT_WINBOND_CIR) += winbond-cir.o
>  obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
>  obj-$(CONFIG_INPUT_WM831X_ON)+= wm831x-on.o
>  obj-$(CONFIG_INPUT_YEALINK)  += yealink.o
> -
> +obj-$(CONFIG_INPUT_CMA3000_I2C)  += cma3000_d0x_i2c.o 
> cma3000_d0x.o
> diff --git a/drivers/input/misc/cma3000_d0x.c 
> b/drivers/input/misc/cma3000_d0x.c
> new file mode 100644
> index 000..c0d0ea1
> --- /dev/null
> +++ b/drivers/input/misc/cma3000_d0x.c
> @@ -0,0 +1,627 @@
> +/*
> + * cma3000_d0x.c
> + * VTI CMA3000_D0x Accelerometer driver
> + *   Supports I2C/SPI interfaces
> + *
> + * Copyright (C) 2010 Texas Instruments
> + * Author: Hemanth V 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "cma3000_d0x.h"
> +
> +#define CMA3000_WHOAMI  0x00
> +#define CMA3000_REVID   0x01
> +#define CMA3000_CTRL0x02
> +#define CMA3000_STATUS  0x03
> +#define CMA3000_RSTR0x04
> +#define CMA3000_INTSTATUS   0x05
> +#define CMA3000_DOUTX   0x06
> +#define CMA3000_DOUTY   0x07
> +#define CMA3000_DOUTZ   0x08
> +#define CMA3000_MDTHR   0x09
> +#define CMA3000_MDFFTMR 0x0A
> +#define CMA3000_FFTHR   0x0B
> +
> +#define CMA3000_RANGE2G(1 << 7)
> +#define CMA3000_RANGE8G(0 << 7)
> +#define CMA3000_MODEMASK(7 << 1)
> +#define CMA3000_GRANGEMASK  (1 << 7)
> +
> +#define CMA3000_STATUS_PERR1
> +#define CMA3000_INTSTATUS_FFDET (1 << 2)
> +
> +/* Settling time delay in ms */
> +#define CMA3000_SETDELAY30
> +
> +/* Delay for clearing interrupt in us */
> +#define CMA3000_INTDELAY44
> +
> +
> +/

RE: [RFC][PATCH1/2] SFH7741: proximity sensor driver support

[Hemanth V]

>> - Original Message -
>> From: "Datta, Shubhrajyoti" 
>> >
>> > From: Datta, Shubhrajyoti
>> > Sent: Monday, May 03, 2010 11:07 AM
>> > To: Datta, Shubhrajyoti
>> > Subject: [RFC][PATCH1/2] SFH7741: proximity sensor driver support
>> >
>>
>> > +
>> > +static irqreturn_t sfh7741_isr(int irq, void *dev_id)
>> > +{
>> > + struct sfh7741_drvdata *ddata = dev_id;
>> > +
>> > + int proximity = gpio_get_value(ddata->proximity_out);
>> > + input_report_abs(ddata->input, ABS_DISTANCE, proximity);
>> > + input_sync(ddata->input);
>> > +
>> > + return IRQ_HANDLED;
>> > +}
>> > +
>> > +static int __devinit sfh7741_setup(struct device *dev,
>> > + struct sfh7741_drvdata *ddata
>> > + )
>> > +{
>> > + int  error;
>> > + char *desc = "sfh7741";
>> > +
>> > + error = gpio_request(ddata->proximity_out, desc);
>> > + if (error < 0) {
>> > + dev_err(dev, "failed to request GPIO %d, error %d\n",
>> > + ddata->proximity_out, error);
>> > + return error;
>> > + }
>> > +
>> > + error = gpio_direction_input(ddata->proximity_out);
>> > + if (error < 0) {
>> > + dev_err(dev, "failed to configure direction for GPIO %d,\
>> > + error %d\n", ddata->proximity_out, error);
>> > + goto fail1;
>> > + }
>> > +
>>
>> General comment about GPIO,
>> It might be better to have GPIO configuration as part of board file,
>> rather than being part of the driver. This is should make the driver
>> more generic.
> I read GPIO in the ISR how can I take care of that?

A generic read function pointer could be defined as part
of platform data, which could be used to retieve gpio value


--
To unsubscribe from this list: send the line "unsubscribe 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][PATCH1/2] SFH7741: proximity sensor driver support

[Hemanth V]

- Original Message - 
From: "Datta, Shubhrajyoti" 


From: Datta, Shubhrajyoti
Sent: Monday, May 03, 2010 11:07 AM
To: Datta, Shubhrajyoti
Subject: [RFC][PATCH1/2] SFH7741: proximity sensor driver support

Driver support for the proximity sensor SFH7741.

Signed-off-by: Shubhro 
---
drivers/input/misc/Kconfig|9 ++
drivers/input/misc/Makefile   |1 +
drivers/input/misc/sfh7741.c  |  308 
+

include/linux/input/sfh7741.h |   14 ++
4 files changed, 332 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/misc/sfh7741.c
create mode 100644 include/linux/input/sfh7741.h

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 16ec523..5919358 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -319,4 +319,13 @@ config INPUT_PCAP
   To compile this driver as a module, choose M here: the
   module will be called pcap_keys.

+config SENSORS_SFH7741
+ tristate "Proximity sensor"
+ default y
+ help
+   Say Y here if you want to use proximity sensor sfh7741.
+
+   To compile this driver as a module, choose M here: the
+   module will be called sfh7741.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index a8b8485..b2cac12 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -30,4 +30,5 @@ obj-$(CONFIG_INPUT_WINBOND_CIR) += winbond-cir.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
obj-$(CONFIG_INPUT_YEALINK) += yealink.o
+obj-$(CONFIG_SENSORS_SFH7741) += sfh7741.o

diff --git a/drivers/input/misc/sfh7741.c b/drivers/input/misc/sfh7741.c
new file mode 100644
index 000..b4febfe
--- /dev/null
+++ b/drivers/input/misc/sfh7741.c
@@ -0,0 +1,308 @@
+/*
+ * sfh7741.c
+ *
+ * SFH7741 Proximity Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Author: Shubhrajyoti Datta 
+ *
+ * This program is free software; you can redistribute it and/or modify 
it
+ * under the terms of the GNU General Public License version 2 as 
published by

+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 
USA

+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct sfh7741_drvdata {
+ struct input_dev *input;
+ int proximity_out;
+ int gpio_en;
+};
+
+static DEFINE_MUTEX(prox_enable_mutex);


This mutex can be included as part of driver data structure


+static int prox_enable = 1;


Same comment as above


+
+static irqreturn_t sfh7741_isr(int irq, void *dev_id)
+{
+ struct sfh7741_drvdata *ddata = dev_id;
+
+ int proximity = gpio_get_value(ddata->proximity_out);
+ input_report_abs(ddata->input, ABS_DISTANCE, proximity);
+ input_sync(ddata->input);
+
+ return IRQ_HANDLED;
+}
+
+static int __devinit sfh7741_setup(struct device *dev,
+ struct sfh7741_drvdata *ddata
+ )
+{
+ int  error;
+ char *desc = "sfh7741";
+
+ error = gpio_request(ddata->proximity_out, desc);
+ if (error < 0) {
+ dev_err(dev, "failed to request GPIO %d, error %d\n",
+ ddata->proximity_out, error);
+ return error;
+ }
+
+ error = gpio_direction_input(ddata->proximity_out);
+ if (error < 0) {
+ dev_err(dev, "failed to configure direction for GPIO %d,\
+ error %d\n", ddata->proximity_out, error);
+ goto fail1;
+ }
+


General comment about GPIO,
It might be better to have GPIO configuration as part of board file,
rather than being part of the driver. This is should make the driver
more generic.



+ error = request_threaded_irq(gpio_to_irq(ddata->proximity_out) , NULL ,
+ sfh7741_isr,
+ IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING
+ | IRQF_ONESHOT,
+ desc, ddata);
+ if (error) {
+ dev_err(dev, "Unable to claim irq %d; error %d\n",
+ gpio_to_irq(ddata->proximity_out), error);
+ goto fail1;
+ }
+
+ error = gpio_request(ddata->gpio_en, desc);
+ if (error < 0) {
+ dev_err(dev, "failed to request GPIO %d, error %d\n",
+ ddata->gpio_en, error);
+ goto fail2;
+ }
+
+ error = gpio_direction_output(ddata->gpio_en , 1);
+ if (error < 0) {
+ dev_err(dev, "%s: GPIO configuration failed: GPIO %d,\
+ error %d\n",__func__, ddata->gpio_en, error);
+ goto fail3;
+ }
+ return 0;
+
+fail3:
+ gpio_free(ddata->gpio_en);
+fail2:
+ free_irq(gpio_to_irq(ddata->proximity_out), &ddata);
+fail1:
+ gpio_free(ddata->proximity_out);
+ return error;
+}
+
+static ssize_t set_prox_state(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int state , error;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct sfh7741_drvdata *ddata = platform_get_drvdata(pdev);
+
+ if (sscan

[RFC] [PATCH 2/2] Platform changes for CMA3000

[Hemanth V]

>From 68cde2e0304b1bd44e9fdbfbaa071e91cfcad419 Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Fri, 30 Apr 2010 11:56:30 +0530
Subject: [PATCH] Platform changes for CMA3000


Signed-off-by: Hemanth V 
---
 arch/arm/mach-omap2/board-4430sdp.c |   38 ++-
 1 files changed, 37 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 72e7b14..717ad4b 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -39,9 +40,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "mmc-twl4030.h"

+#define OMAP4_CMA3000ACCL_GPIO 186
+
 static int sdp4430_keymap[] = {
KEY(0, 0, KEY_E),
KEY(0, 1, KEY_R),
@@ -503,6 +507,18 @@ static struct twl4030_platform_data sdp4430_twldata = {
.bci= &sdp4430_bci_data,
 };

+static struct cma3000_platform_data cma3000_platform_data = {
+   .fuzz_x = 25,
+   .fuzz_y = 25,
+   .fuzz_z = 25,
+   .g_range = CMARANGE_8G,
+   .mode = CMAMODE_MOTDET,
+   .mdthr = 0x8,
+   .mdfftmr = 0x33,
+   .ffthr = 0x8,
+   .irqflags = IRQF_TRIGGER_HIGH,
+};
+
 static struct i2c_board_info __initdata sdp4430_i2c_boardinfo[] = {
{
I2C_BOARD_INFO("twl6030", 0x48),
@@ -526,6 +542,14 @@ static struct i2c_board_info __initdata 
sdp4430_i2c_3_boardinfo[] = {
},
 };

+static struct i2c_board_info __initdata sdp4430_i2c_4_boardinfo[] = {
+   {
+   I2C_BOARD_INFO("cma3000_accl", 0x1c),
+   .platform_data = &cma3000_platform_data,
+   .irq = OMAP_GPIO_IRQ(OMAP4_CMA3000ACCL_GPIO),
+   },
+};
+
 static int __init omap4_i2c_init(void)
 {
/* Phoenix Audio IC needs I2C1 to srat with 400 KHz and less */
@@ -535,7 +559,8 @@ static int __init omap4_i2c_init(void)
ARRAY_SIZE(sdp4430_i2c_2_boardinfo));
omap_register_i2c_bus(3, 400, sdp4430_i2c_3_boardinfo,
ARRAY_SIZE(sdp4430_i2c_3_boardinfo));
-   omap_register_i2c_bus(4, 400, 0, 0);
+   omap_register_i2c_bus(4, 400, sdp4430_i2c_4_boardinfo,
+   ARRAY_SIZE(sdp4430_i2c_4_boardinfo));

return 0;
 }
@@ -578,6 +603,16 @@ static void omap_ethernet_init(void)
gpio_direction_input(34);
 }

+static void omap_cma3000accl_init(void)
+{
+
+   if (gpio_request(OMAP4_CMA3000ACCL_GPIO, "Accelerometer") < 0) {
+   pr_err("Accelerometer GPIO request failed\n");
+   return;
+   }
+   gpio_direction_input(OMAP4_CMA3000ACCL_GPIO);
+
+}
 static void __init omap_4430sdp_init(void)
 {
omap4_i2c_init();
@@ -591,6 +626,7 @@ static void __init omap_4430sdp_init(void)
sdp4430_spi_board_info[0].irq = gpio_to_irq(34);
spi_register_board_info(sdp4430_spi_board_info,
ARRAY_SIZE(sdp4430_spi_board_info));
+   omap_cma3000accl_init();

 }

-- 
1.5.6.3



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

[RFC] [PATCH 1/2] CMA3000 Accelerometer Driver

[Hemanth V]

>From d2842ba67e142e78b2554cebb01341c76b84b693 Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Fri, 30 Apr 2010 11:55:10 +0530
Subject: [PATCH] CMA3000 Accelerometer Driver

This patch adds support for CMA3000 Tri-axis accelerometer, which
supports Motion detect, Measurement and Free fall modes.
CMA3000 supports both I2C/SPI bus for communication, currently the
driver supports I2C based communication.

Driver reports acceleration data through input subsystem and supports
sysfs for configuration changes.

This chip is currently used with OMAP4 based boards

Thanks to Ossi Kauppinen  for the support
provided during development

Signed-off-by: Hemanth V 
---
 drivers/input/misc/Kconfig   |9 +
 drivers/input/misc/Makefile  |1 +
 drivers/input/misc/cma3000_d0x.c |  627 ++
 drivers/input/misc/cma3000_d0x.h |   46 +++
 drivers/input/misc/cma3000_d0x_i2c.c |  136 
 include/linux/i2c/cma3000.h  |   60 
 6 files changed, 879 insertions(+), 0 deletions(-)
 create mode 100644 drivers/input/misc/cma3000_d0x.c
 create mode 100644 drivers/input/misc/cma3000_d0x.h
 create mode 100644 drivers/input/misc/cma3000_d0x_i2c.c
 create mode 100644 include/linux/i2c/cma3000.h

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 16ec523..4752a00 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -319,4 +319,13 @@ config INPUT_PCAP
  To compile this driver as a module, choose M here: the
  module will be called pcap_keys.

+config INPUT_CMA3000_I2C
+   tristate "VTI CMA3000 Tri-axis accelerometer"
+   depends on I2C
+   help
+ Say Y here if you want to use VTI CMA3000 Accelerometer
+ through I2C interface.
+
+ To compile this driver as a module, choose M here: the
+ module will be called cma3000_dxx
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index a8b8485..94d6eda 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -30,4 +30,4 @@ obj-$(CONFIG_INPUT_WINBOND_CIR)   += winbond-cir.o
 obj-$(CONFIG_INPUT_WISTRON_BTNS)   += wistron_btns.o
 obj-$(CONFIG_INPUT_WM831X_ON)  += wm831x-on.o
 obj-$(CONFIG_INPUT_YEALINK)+= yealink.o
-
+obj-$(CONFIG_INPUT_CMA3000_I2C)+= cma3000_d0x_i2c.o 
cma3000_d0x.o
diff --git a/drivers/input/misc/cma3000_d0x.c b/drivers/input/misc/cma3000_d0x.c
new file mode 100644
index 000..c0d0ea1
--- /dev/null
+++ b/drivers/input/misc/cma3000_d0x.c
@@ -0,0 +1,627 @@
+/*
+ * cma3000_d0x.c
+ * VTI CMA3000_D0x Accelerometer driver
+ * Supports I2C/SPI interfaces
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Hemanth V 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cma3000_d0x.h"
+
+#define CMA3000_WHOAMI  0x00
+#define CMA3000_REVID   0x01
+#define CMA3000_CTRL0x02
+#define CMA3000_STATUS  0x03
+#define CMA3000_RSTR0x04
+#define CMA3000_INTSTATUS   0x05
+#define CMA3000_DOUTX   0x06
+#define CMA3000_DOUTY   0x07
+#define CMA3000_DOUTZ   0x08
+#define CMA3000_MDTHR   0x09
+#define CMA3000_MDFFTMR 0x0A
+#define CMA3000_FFTHR   0x0B
+
+#define CMA3000_RANGE2G(1 << 7)
+#define CMA3000_RANGE8G(0 << 7)
+#define CMA3000_MODEMASK(7 << 1)
+#define CMA3000_GRANGEMASK  (1 << 7)
+
+#define CMA3000_STATUS_PERR1
+#define CMA3000_INTSTATUS_FFDET (1 << 2)
+
+/* Settling time delay in ms */
+#define CMA3000_SETDELAY30
+
+/* Delay for clearing interrupt in us */
+#define CMA3000_INTDELAY44
+
+
+/*
+ * Bit weights in mg for each of the seven bits,
+ * eight bit is the sign bit
+ */
+static int bit_to_2g[7] = {18, 36, 71, 143, 286, 571, 1142};
+static int bit_to_8g[7] = {71, 143, 286, 571, 1142, 2286, 4571};
+
+/*
+ * Conversion for each of the eight modes to g, depending
+ * on G range i.e 2G or 8G
+ */
+
+static int *mode_to_mg[8][2] = {
+   {NULL, NULL },
+   {bit_to_8g, bit_to_2g},
+   {bit_to_8g, bit_to_2g},
+   {bit_to_8g, bit_to_8g},
+   {bit_to_8g, bit_to_8g},
+   {bit_to_8g, bit_to_2g},
+   {bit_to_8g, bit_to_2g},
+   {NULL, NULL },
+};
+
+static ssize_t cma3000_show_attr_mode(struct device *dev,
+  

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

[Hemanth V]

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


Signed-off-by: Hemanth V 
---
 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

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

[Hemanth V]

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


Signed-off-by: Hemanth V 
---
 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 0/2] [STAGING] Synaptic Touchscreen Driver

[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

Re: Merge plans for Staging Synaptics Touchscreen Driver

[Hemanth V]

>> Hi!
>>
>>> Are there any plans to merge the synaptics touchscreen driver
>>> (drivers/staging/dream/synaptics_i2c_rmi.c) to
>>> drivers/input/touchscreen. We are interested in the same
>>> since OMAP3 based Zoom boards use this touchscreen.
>>
>> Plans are, but day job interferes with them.
>>
>>> Pl add (if required) below tested by for the staging driver.
>
>>
>> 1) are you able to use driver in staging?
>
> Yes I am able to use staging driver for single
> touch events.
>
>>
>> at minimum, non-standard multitouch support needs to be removed before
>> merging to input. Do you have time to help?
>
> Could you review the below patch.

Forgot to remove unused variables in earlier patch, here's
the updated one.


---

Remove non-standard multi touch support.

Signed-off-by: Hemanth V 

diff --git a/drivers/staging/dream/synaptics_i2c_rmi.c 
b/drivers/staging/dream/synaptics_i2c_rmi.c
index 4de6bc9..f3bc7d6 100644
--- a/drivers/staging/dream/synaptics_i2c_rmi.c
+++ b/drivers/staging/dream/synaptics_i2c_rmi.c
@@ -108,9 +108,6 @@ 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 +147,6 @@ 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);
 }




--
To unsubscribe from this list: send the line "unsubscribe 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: Merge plans for Staging Synaptics Touchscreen Driver

[Hemanth V]

> Hi!
>
>> Are there any plans to merge the synaptics touchscreen driver
>> (drivers/staging/dream/synaptics_i2c_rmi.c) to
>> drivers/input/touchscreen. We are interested in the same
>> since OMAP3 based Zoom boards use this touchscreen.
>
> Plans are, but day job interferes with them.
>
>> Pl add (if required) below tested by for the staging driver.

>
> 1) are you able to use driver in staging?

Yes I am able to use staging driver for single
touch events.

>
> at minimum, non-standard multitouch support needs to be removed before
> merging to input. Do you have time to help?

Could you review the below patch.

Thanks
Hemanth

---

Remove non-standard multi touch support.

Signed-off-by: Hemanth V 

diff --git a/drivers/staging/dream/synaptics_i2c_rmi.c 
b/drivers/staging/dream/synaptics_i2c_rmi.c
index 4de6bc9..34449ad 100644
--- a/drivers/staging/dream/synaptics_i2c_rmi.c
+++ b/drivers/staging/dream/synaptics_i2c_rmi.c
@@ -150,14 +150,6 @@ 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);
 }



--
To unsubscribe from this list: send the line "unsubscribe 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: Merge plans for Staging Synaptics Touchscreen Driver

[Hemanth V]

> Hi Hemanth,
>
>> -Original Message-
>> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>> ow...@vger.kernel.org] On Behalf Of V, Hemanth
>> Sent: Tuesday, March 23, 2010 4:29 AM
>> To: pa...@ucw.cz; linux-in...@vger.kernel.org
>> Cc: linux-omap@vger.kernel.org
>> Subject: Merge plans for Staging Synaptics Touchscreen Driver
>>
>> Hi All,
>>
>> Are there any plans to merge the synaptics touchscreen driver
>> (drivers/staging/dream/synaptics_i2c_rmi.c) to
>> drivers/input/touchscreen. We are interested in the same
>> since OMAP3 based Zoom boards use this touchscreen.
>
> Can you please elaborate on the specific Synaptics touchscreen chip you're 
> attempting to drive?
>

Sergio,

The current driver available in staging directory is for
Synaptics RMI3 chip 511-99-01F

Thanks
Hemanth


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

Merge plans for Staging Synaptics Touchscreen Driver

[Hemanth V]

Hi All,

Are there any plans to merge the synaptics touchscreen driver
(drivers/staging/dream/synaptics_i2c_rmi.c) to
drivers/input/touchscreen. We are interested in the same
since OMAP3 based Zoom boards use this touchscreen.

Pl add (if required) below tested by for the staging driver.

Tested-By: Hemanth V 

Thanks
Hemanth

--
To unsubscribe from this list: send the line "unsubscribe 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 V2 3/3] Add support for Slave mode

[Hemanth V]

Pl also find the patch attached, incase corrupted by mailer

Thanks
Hemanth

>From ae4c6a91bbcfc842f97cf48dd13f6de02baae1d3 Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Fri, 27 Nov 2009 14:37:20 +0530
Subject: [PATCH 3/3] Add McSPI slave support.

This patch adds support for mcspi slave mode.

Signed-off-by: Hemanth V 
---
 drivers/spi/omap2_mcspi.c |   24 ++--
 1 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 75a3f04..03d61cf 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -428,6 +428,18 @@ static void omap2_mcspi_set_master_mode(struct spi_master
*master)
omap2_mcspi_ctx[master->bus_num - 1].modulctrl = l;
 }

+static void omap2_mcspi_set_slave_mode(struct spi_master *master)
+{
+   u32 l;
+
+   l = mcspi_read_reg(master, OMAP2_MCSPI_MODULCTRL);
+   MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_STEST, 0);
+   MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_MS, 1);
+   mcspi_write_reg(master, OMAP2_MCSPI_MODULCTRL, l);
+
+   omap2_mcspi_ctx[master->bus_num - 1].modulctrl = l;
+}
+
 static int mcspi_wait_for_reg_bit(void __iomem *reg, unsigned long bit)
 {
unsigned long timeout;
@@ -827,10 +839,11 @@ static int omap2_mcspi_setup_transfer(struct spi_device
*spi,
l &= ~(OMAP2_MCSPI_CHCONF_IS|OMAP2_MCSPI_CHCONF_DPE1);
l |= OMAP2_MCSPI_CHCONF_DPE0;
} else {
-   return -EINVAL;
+   l |= OMAP2_MCSPI_CHCONF_IS;
+   l |= OMAP2_MCSPI_CHCONF_DPE1;
+   l &= ~OMAP2_MCSPI_CHCONF_DPE0;
}

-
/* wordlength */
l &= ~OMAP2_MCSPI_CHCONF_WL_MASK;
l |= (word_len - 1) << 7;
@@ -1214,7 +1227,6 @@ static int __init omap2_mcspi_reset(struct omap2_mcspi
*mcspi)
 {
struct spi_master   *master = mcspi->master;
u32 tmp;
-   u32 error = 0;

if (omap2_mcspi_enable_clocks(mcspi))
return -1;
@@ -1238,10 +1250,10 @@ static int __init omap2_mcspi_reset(struct omap2_mcspi
*mcspi)
if (mcspi->mcspi_mode == OMAP2_MCSPI_MASTER)
omap2_mcspi_set_master_mode(master);
else
-   error = -EINVAL;
+   omap2_mcspi_set_slave_mode(master);

omap2_mcspi_disable_clocks(mcspi);
-   return error;
+   return 0;
 }

 static u8 __initdata spi1_rxdma_id [] = {
@@ -1353,7 +1365,7 @@ static int __init omap2_mcspi_probe(struct
platform_device *pdev)

mcspi = spi_master_get_devdata(master);
mcspi->master = master;
-   mcspi->mcspi_mode = OMAP2_MCSPI_MASTER;
+   mcspi->mcspi_mode = pdata->mode;
mcspi->dma_mode = pdata->dma_mode;
mcspi->force_cs_mode = pdata->force_cs_mode;

-- 
1.6.3.3


0003-Add-McSPI-slave-support.patch
Description: Binary data

[RESEND] [PATCH V2 2/3]: Adds support for FIFO

[Hemanth V]

Pl also find the patch attached, incase corrupted by mailer

Thanks
Hemanth

>From 00ae9791a5461fece3c3a89527cf3e8648352c32 Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Wed, 2 Dec 2009 18:13:13 +0530
Subject: [PATCH 2/3] Adds support for FIFO and auto chip select mode

DMA and FIFO could be enabled together for better throughput.
Platform config parameters have been added to enable these
features on any particular McSPI controller.

FIFO can be enabled by defining fifo_depth parameter. fifo_depth needs
to be a multiple of buffer size that is used for read/write.

Auto chip select mode can be enabled by setting force_cs_mode
to zero

Signed-off-by: Hemanth V 
---
 drivers/spi/omap2_mcspi.c |  338 -
 1 files changed, 302 insertions(+), 36 deletions(-)

diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 715c518..75a3f04 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -37,10 +37,11 @@

 #include 
 #include 
+#include 


 #define OMAP2_MCSPI_MAX_FREQ   4800
-
+#define OMAP2_MCSPI_MAX_FIFODEPTH   64
 /* OMAP2 has 3 SPI controllers, while OMAP3 has 4 */
 #define OMAP2_MCSPI_MAX_CTRL   4

@@ -52,6 +53,7 @@
 #define OMAP2_MCSPI_WAKEUPENABLE   0x20
 #define OMAP2_MCSPI_SYST   0x24
 #define OMAP2_MCSPI_MODULCTRL  0x28
+#define OMAP2_MCSPI_XFERLEVEL  0x7c

 /* per-channel banks, 0x14 bytes each, first is: */
 #define OMAP2_MCSPI_CHCONF00x2c
@@ -88,11 +90,15 @@
 #define OMAP2_MCSPI_CHCONF_IS  BIT(18)
 #define OMAP2_MCSPI_CHCONF_TURBO   BIT(19)
 #define OMAP2_MCSPI_CHCONF_FORCE   BIT(20)
+#define OMAP2_MCSPI_CHCONF_FFETBIT(27)
+#define OMAP2_MCSPI_CHCONF_FFERBIT(28)

 #define OMAP2_MCSPI_CHSTAT_RXS BIT(0)
 #define OMAP2_MCSPI_CHSTAT_TXS BIT(1)
 #define OMAP2_MCSPI_CHSTAT_EOT BIT(2)

+#define OMAP2_MCSPI_IRQ_EOWBIT(17)
+
 #define OMAP2_MCSPI_CHCTRL_EN  BIT(0)

 #define OMAP2_MCSPI_WAKEUPENABLE_WKEN  BIT(0)
@@ -128,6 +134,10 @@ struct omap2_mcspi {
unsigned long   phys;
/* SPI1 has 4 channels, while SPI2 has 2 */
struct omap2_mcspi_dma  *dma_channels;
+   u8  mcspi_mode;
+   u8  dma_mode;
+   u8  force_cs_mode;
+   u16 fifo_depth;
 };

 struct omap2_mcspi_cs {
@@ -151,6 +161,37 @@ struct omap2_mcspi_regs {

 static struct omap2_mcspi_regs omap2_mcspi_ctx[OMAP2_MCSPI_MAX_CTRL];

+#ifdef CONFIG_SPI_DEBUG
+struct reg_type {
+   char name[40];
+   int offset;
+};
+
+static struct reg_type reg_map[] = {
+   {"MCSPI_REV", 0x0},
+   {"MCSPI_SYSCONFIG", 0x10},
+   {"MCSPI_SYSSTATUS", 0x14},
+   {"MCSPI_IRQSTATUS", 0x18},
+   {"MCSPI_IRQENABLE", 0x1C},
+   {"MCSPI_WAKEUPENABLE", 0x20},
+   {"MCSPI_SYST", 0x24},
+   {"MCSPI_MODULCTRL", 0x28},
+   {"MCSPI_XFERLEVEL", 0x7c},
+   {"CH0", 0x2C},
+   {"CH1", 0x40},
+   {"CH2", 0x54},
+   {"CH3", 0x68}
+};
+
+static struct reg_type ch_reg_type[] = {
+   {"CONF", 0x00},
+   {"STAT", 0x04},
+   {"CTRL", 0x08},
+   {"TX", 0x0C},
+   {"RX", 0x10},
+};
+#endif
+
 static struct workqueue_struct *omap2_mcspi_wq;

 #define MOD_REG_BIT(val, mask, set) do { \
@@ -221,6 +262,39 @@ static void omap2_mcspi_set_dma_req(const struct
spi_device *spi,
mcspi_write_chconf0(spi, l);
 }

+#ifdef CONFIG_SPI_DEBUG
+static int
+omap2_mcspi_dump_regs(struct spi_master *master)
+{
+   u32 spi_base;
+   u32 reg;
+   u32 channel;
+   struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+
+   spi_base = (u32)mcspi->base;
+
+   for (reg = 0; (reg < ARRAY_SIZE(reg_map)); reg++) {
+   struct reg_type *reg_d = ®_map[reg];
+   u32 base1 = spi_base + reg_d->offset;
+   if (reg_d->name[0] == 'C') {
+   for (channel = 0; (channel < (ARRAY_SIZE(ch_reg_type)));
+   channel++) {
+   struct reg_type *reg_c = &ch_reg_type[channel];
+   u32 base2 = base1 + reg_c->offset;
+   pr_debug("MCSPI_%s%s [0x%08X] = 0x%08X\n",
+  reg_d->name, reg_c->name, base2,
+  __raw_readl(base2));
+   }
+   } else {
+   pr_debug("%s : [0x%08X] = 0x%08X\n",
+   reg_d->name, base1, __raw_readl(base1));
+   }
+
+   }
+   return 0;
+}
+#endif
+
 static void omap2_mcspi_set_enable(const struct spi_device *spi,

Re: PATCH[V2 1/3]: Update Platform files for SPI

[Hemanth V]

> * Tony Lindgren  [100209 15:03]:
>> * Grant Likely  [100209 14:38]:
>> > On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren  wrote:
>> > > * Hemanth V  [100203 02:19]:
>> > >> From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001
>> > >> From: Hemanth V 
>> > >> Date: Fri, 27 Nov 2009 14:22:30 +0530
>> > >> Subject: [PATCH] Update platform files
>> > >>
>> > >> This patch updates platform files for
>> > >> fifo, slave support
>> > >>
>> > >> Signed-off-by: Hemanth V 
>> > >
>> > > This should get merged via the spi-devel list with the other patches.
>> > >
>> > > Acked-by: Tony Lindgren 
>> >
>> > Personally, I prefer not to carry arch/* changes in my next-spi
>> > branch, since it means that my pull requests are less obvious for
>> > Linus and there is greater chance of conflict.
>> >
>> > But if you still really want me to merge it through my tree, (or if
>> > getting the patches out of order will break things) then I'll pick it
>> > up.  Just let me know.
>>
>> OK, if you ack it, I'll add the header into omap for-next. That
>> might break git bisect for some configurations depending in which
>> order the patches get pulled by Linus..
>>
>> I guess eventually this header should not live under plat.
>
> Hemanth, the patch is missing line breaks so it won't apply:
>
> http://patchwork.kernel.org/patch/76675/
>
> Please resend, I'm not editing patches manually any longer thanks.
>
> Regards,
>
> Tony
>
Pl find the patches attached, hopefully it doesnot get corrupted this
time

>From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Fri, 27 Nov 2009 14:22:30 +0530
Subject: [PATCH] Update platform files

This patch updates platform files for
fifo, slave support

Signed-off-by: Hemanth V 
---
 arch/arm/mach-omap2/devices.c   |5 +
 arch/arm/plat-omap/include/plat/mcspi.h |   29 -
 2 files changed, 33 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 733d3dc..79b5396 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -282,6 +282,7 @@ static inline void omap_init_sti(void) {}

 static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
.num_cs = 4,
+   .force_cs_mode  = 1,
 };

 static struct resource omap2_mcspi1_resources[] = {
@@ -304,6 +305,10 @@ static struct platform_device omap2_mcspi1 = {

 static struct omap2_mcspi_platform_config omap2_mcspi2_config = {
.num_cs = 2,
+   .mode   = OMAP2_MCSPI_MASTER,
+   .dma_mode   = 0,
+   .force_cs_mode  = 0,
+   .fifo_depth = 0,
 };

 static struct resource omap2_mcspi2_resources[] = {
diff --git a/arch/arm/plat-omap/include/plat/mcspi.h
b/arch/arm/plat-omap/include/plat/mcspi.h
index 1254e49..ffda0a1 100644
--- a/arch/arm/plat-omap/include/plat/mcspi.h
+++ b/arch/arm/plat-omap/include/plat/mcspi.h
@@ -1,8 +1,35 @@
 #ifndef _OMAP2_MCSPI_H
 #define _OMAP2_MCSPI_H

+#define OMAP2_MCSPI_MASTER 0
+#define OMAP2_MCSPI_SLAVE  1
+
+/**
+ * struct omap2_mcspi_platform_config - McSPI controller configuration
+ * @num_cs: Number of chip selects or channels supported
+ * @mode: SPI is master or slave
+ * @dma_mode: Use only DMA for data transfers
+ * @force_cs_mode: Use force chip select mode or auto chip select mode
+ * @fifo_depth: FIFO depth in bytes, max value 64
+ *
+ * @dma_mode when set to 1 uses only dma for data transfers
+ * else the default behaviour is to use PIO mode for transfer
+ * size of 8 bytes or less. This mode is useful when mcspi
+ * is configured as slave
+ *
+ * @force_cs_mode when set to 1 allows continuous transfer of multiple
+ * spi words without toggling the chip select line.
+ *
+ * @fifo_depth when set to non zero values enables FIFO. fifo_depth
+ * should be set as a multiple of buffer size used for read/write.
+ */
+
 struct omap2_mcspi_platform_config {
-   unsigned short  num_cs;
+   u8  num_cs;
+   u8  mode;
+   u8  dma_mode;
+   u8  force_cs_mode;
+   unsigned short fifo_depth;
 };

 struct omap2_mcspi_device_config {
-- 
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[V2 1/3]: Update Platform files for SPI

[Hemanth V]

> On Tue, Feb 9, 2010 at 4:07 PM, Tony Lindgren  wrote:
>> * Grant Likely  [100209 14:38]:
>>> On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren  wrote:
>>> > * Hemanth V  [100203 02:19]:
>>> >> From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001
>>> >> From: Hemanth V 
>>> >> Date: Fri, 27 Nov 2009 14:22:30 +0530
>>> >> Subject: [PATCH] Update platform files
>>> >>
>>> >> This patch updates platform files for
>>> >> fifo, slave support
>>> >>
>>> >> Signed-off-by: Hemanth V 
>>> >
>>> > This should get merged via the spi-devel list with the other patches.
>>> >
>>> > Acked-by: Tony Lindgren 
>>>
>>> Personally, I prefer not to carry arch/* changes in my next-spi
>>> branch, since it means that my pull requests are less obvious for
>>> Linus and there is greater chance of conflict.
>>>
>>> But if you still really want me to merge it through my tree, (or if
>>> getting the patches out of order will break things) then I'll pick it
>>> up.  Just let me know.
>>
>> OK, if you ack it, I'll add the header into omap for-next. That
>> might break git bisect for some configurations depending in which
>> order the patches get pulled by Linus..
>
> git bisect breakage is breakage enough.  :-)  You're right.  I should
> pick this one up.  I can see that now that I've had my tea and I'm no
> longer grumpy.
>
>> I guess eventually this header should not live under plat.
>
> Any reason the header cannot be moved to include/linux/spi/ now?

Quite a few board files use this header file, which would also require changes.
Tony, are you ok with accepting changes to board files.

Thanks
Hemanth
>
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>


--
To unsubscribe from this list: send the line "unsubscribe 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: OMAP3 Slave McSPI driver

[Hemanth V]

- Original Message - 
From: "Talis, Gilles" 

To: 
Sent: Tuesday, February 09, 2010 3:06 PM
Subject: OMAP3 Slave McSPI driver



Hi,

My customer is using Android 2.6.29 kernel from OMAPZOOM and is looking 
for support for slave mode on the SPI driver.
I saw there were patches for this feature sent to this list, but I was 
wondering if those patches were tested on 2.6.29.




These patches have not been specifically tested on 29 kernel, but you could 
give it a shot. Pl also look at the latest patches (V2) posted.


I am also looking for some kind of API usage guidelines. How to setup the 
slave mode and how is OMAP notified that data have been received from 
external master device? My customer plans to use this driver in interrupt 
mode (no DMA needed).




To set any mcspi controller to slave mode, you need to modify 
arch/arm/mach-omap2/devices.c file and set mode to OMAP2_MCSPI_SLAVE.


Typically gpio is used by master to notify the slave that it is ready to 
transfer data. On gpio interrupt slave client could issue spi_read/spi_write 
commands.


Two modes are supported i.e PIO and DMA. Any specific reason not to use DMA 
mode.


Thanks
Hemanth


Thanks
Gilels.



Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve 
Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920




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



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

[PATCH V2 3/3] Add support for Slave mode

[Hemanth V]

>From c13e2181154c793a71e132ab374bba1720ca421c Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Fri, 27 Nov 2009 14:37:20 +0530
Subject: [PATCH] Add McSPI slave support.

This patch adds support for mcspi slave mode.

Signed-off-by: Hemanth V 
---
 drivers/spi/omap2_mcspi.c |   22 --
 1 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c index
d8e8ea0..f6041bf 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -428,6 +428,16 @@ static void omap2_mcspi_set_master_mode(struct spi_master
*master)
omap2_mcspi_ctx[master->bus_num - 1].modulctrl = l;
 }

+static void omap2_mcspi_set_slave_mode(struct spi_master *master) +{
+   u32 l;
+
+   l = mcspi_read_reg(master, OMAP2_MCSPI_MODULCTRL);
+   MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_STEST, 0);
+   MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_MS, 1);
+   mcspi_write_reg(master, OMAP2_MCSPI_MODULCTRL, l);
+}
+
 static int mcspi_wait_for_reg_bit(void __iomem *reg, unsigned long bit) {
unsigned long timeout;
@@ -827,10 +837,11 @@ static int omap2_mcspi_setup_transfer(struct spi_device
*spi,
l &= ~(OMAP2_MCSPI_CHCONF_IS|OMAP2_MCSPI_CHCONF_DPE1);
l |= OMAP2_MCSPI_CHCONF_DPE0;
} else {
-   return -EINVAL;
+   l |= OMAP2_MCSPI_CHCONF_IS;
+   l |= OMAP2_MCSPI_CHCONF_DPE1;
+   l &= ~OMAP2_MCSPI_CHCONF_DPE0;
}

-
/* wordlength */
l &= ~OMAP2_MCSPI_CHCONF_WL_MASK;
l |= (word_len - 1) << 7;
@@ -1216,7 +1227,6 @@ static int __init omap2_mcspi_reset(struct omap2_mcspi
*mcspi)
 {
struct spi_master   *master = mcspi->master;
u32 tmp;
-   u32 error = 0;

if (omap2_mcspi_enable_clocks(mcspi))
return -1;
@@ -1240,10 +1250,10 @@ static int __init omap2_mcspi_reset(struct omap2_mcspi
*mcspi)
if (mcspi->mcspi_mode == OMAP2_MCSPI_MASTER)
omap2_mcspi_set_master_mode(master);
else
-   error = -EINVAL;
+   omap2_mcspi_set_slave_mode(master);

omap2_mcspi_disable_clocks(mcspi);
-   return error;
+   return 0;
 }

 static u8 __initdata spi1_rxdma_id [] = {
@@ -1355,7 +1365,7 @@ static int __init omap2_mcspi_probe(struct
platform_device *pdev)

mcspi = spi_master_get_devdata(master);
mcspi->master = master;
-   mcspi->mcspi_mode = OMAP2_MCSPI_MASTER;
+   mcspi->mcspi_mode = pdata->mode;
mcspi->dma_mode = pdata->dma_mode;
mcspi->force_cs_mode = pdata->force_cs_mode;

-- 
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[V2 2/3]: Adds support for FIFO

[Hemanth V]

>From 5faa83f37c0aaa73e2a03780d2b1dfe9469d1e2e Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Wed, 2 Dec 2009 18:13:13 +0530
Subject: [PATCH] Adds support for FIFO and auto chip select mode

DMA and FIFO could be enabled together for better throughput.
Platform config parameters have been added to enable these
features on any particular McSPI controller.

FIFO can be enabled by defining fifo_depth parameter. fifo_depth needs to be a
multiple of buffer size that is used for read/write.

Auto chip select mode can be enabled by setting force_cs_mode
to zero

Signed-off-by: Hemanth V 
---
 drivers/spi/omap2_mcspi.c |  338 -
1 files changed, 302 insertions(+), 36 deletions(-)

diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c index
121cdd2..ce02f50 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -37,10 +37,11 @@

 #include 
 #include 
+#include 


 #define OMAP2_MCSPI_MAX_FREQ   4800
-
+#define OMAP2_MCSPI_MAX_FIFODEPTH   64
 /* OMAP2 has 3 SPI controllers, while OMAP3 has 4 */
 #define OMAP2_MCSPI_MAX_CTRL   4

@@ -52,6 +53,7 @@
 #define OMAP2_MCSPI_WAKEUPENABLE   0x20
 #define OMAP2_MCSPI_SYST   0x24
 #define OMAP2_MCSPI_MODULCTRL  0x28
+#define OMAP2_MCSPI_XFERLEVEL  0x7c

 /* per-channel banks, 0x14 bytes each, first is: */
 #define OMAP2_MCSPI_CHCONF00x2c
@@ -88,11 +90,15 @@
 #define OMAP2_MCSPI_CHCONF_IS  BIT(18)
 #define OMAP2_MCSPI_CHCONF_TURBO   BIT(19)
 #define OMAP2_MCSPI_CHCONF_FORCE   BIT(20)
+#define OMAP2_MCSPI_CHCONF_FFETBIT(27)
+#define OMAP2_MCSPI_CHCONF_FFERBIT(28)

 #define OMAP2_MCSPI_CHSTAT_RXS BIT(0)
 #define OMAP2_MCSPI_CHSTAT_TXS BIT(1)
 #define OMAP2_MCSPI_CHSTAT_EOT BIT(2)

+#define OMAP2_MCSPI_IRQ_EOWBIT(17)
+
 #define OMAP2_MCSPI_CHCTRL_EN  BIT(0)

 #define OMAP2_MCSPI_WAKEUPENABLE_WKEN  BIT(0)
@@ -128,6 +134,10 @@ struct omap2_mcspi {
unsigned long   phys;
/* SPI1 has 4 channels, while SPI2 has 2 */
struct omap2_mcspi_dma  *dma_channels;
+   u8  mcspi_mode;
+   u8  dma_mode;
+   u8  force_cs_mode;
+   u16 fifo_depth;
 };

 struct omap2_mcspi_cs {
@@ -151,6 +161,37 @@ struct omap2_mcspi_regs {

 static struct omap2_mcspi_regs omap2_mcspi_ctx[OMAP2_MCSPI_MAX_CTRL];

+#ifdef CONFIG_SPI_DEBUG
+struct reg_type {
+   char name[40];
+   int offset;
+};
+
+static struct reg_type reg_map[] = {
+   {"MCSPI_REV", 0x0},
+   {"MCSPI_SYSCONFIG", 0x10},
+   {"MCSPI_SYSSTATUS", 0x14},
+   {"MCSPI_IRQSTATUS", 0x18},
+   {"MCSPI_IRQENABLE", 0x1C},
+   {"MCSPI_WAKEUPENABLE", 0x20},
+   {"MCSPI_SYST", 0x24},
+   {"MCSPI_MODULCTRL", 0x28},
+   {"MCSPI_XFERLEVEL", 0x7c},
+   {"CH0", 0x2C},
+   {"CH1", 0x40},
+   {"CH2", 0x54},
+   {"CH3", 0x68}
+};
+
+static struct reg_type ch_reg_type[] = {
+   {"CONF", 0x00},
+   {"STAT", 0x04},
+   {"CTRL", 0x08},
+   {"TX", 0x0C},
+   {"RX", 0x10},
+};
+#endif
+
 static struct workqueue_struct *omap2_mcspi_wq;

 #define MOD_REG_BIT(val, mask, set) do { \
@@ -221,6 +262,39 @@ static void omap2_mcspi_set_dma_req(const struct
spi_device *spi,
mcspi_write_chconf0(spi, l);
 }

+#ifdef CONFIG_SPI_DEBUG
+static int
+omap2_mcspi_dump_regs(struct spi_master *master)
+{
+   u32 spi_base;
+   u32 reg;
+   u32 channel;
+   struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+
+   spi_base = (u32)mcspi->base;
+
+   for (reg = 0; (reg < ARRAY_SIZE(reg_map)); reg++) {
+   struct reg_type *reg_d = ®_map[reg];
+   u32 base1 = spi_base + reg_d->offset;
+   if (reg_d->name[0] == 'C') {
+   for (channel = 0; (channel < (ARRAY_SIZE(ch_reg_type)));
+   channel++) {
+   struct reg_type *reg_c = &ch_reg_type[channel];
+   u32 base2 = base1 + reg_c->offset;
+   pr_debug("MCSPI_%s%s [0x%08X] = 0x%08X\n",
+  reg_d->name, reg_c->name, base2,
+  __raw_readl(base2));
+   }
+   } else {
+   pr_debug("%s : [0x%08X] = 0x%08X\n",
+   reg_d->name, base1, __raw_readl(base1));
+   }
+
+   }
+   return 0;
+}
+#endif
+
 static void omap2_mcspi_set_enable(const struct spi_device *spi, int enable) {
u32 l;
@@ -238,22 +312,135 @@ static void omap2_mcspi

PATCH[V2 1/3]: Update Platform files for SPI

[Hemanth V]

>From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001
From: Hemanth V 
Date: Fri, 27 Nov 2009 14:22:30 +0530
Subject: [PATCH] Update platform files

This patch updates platform files for
fifo, slave support

Signed-off-by: Hemanth V 
---
 arch/arm/mach-omap2/devices.c   |5 +
 arch/arm/plat-omap/include/plat/mcspi.h |   29 - 2
files changed, 33 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 733d3dc..79b5396 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -282,6 +282,7 @@ static inline void omap_init_sti(void) {}

 static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
.num_cs = 4,
+   .force_cs_mode  = 1,
 };

 static struct resource omap2_mcspi1_resources[] = {
@@ -304,6 +305,10 @@ static struct platform_device omap2_mcspi1 = {

 static struct omap2_mcspi_platform_config omap2_mcspi2_config = {
.num_cs = 2,
+   .mode   = OMAP2_MCSPI_MASTER,
+   .dma_mode   = 0,
+   .force_cs_mode  = 0,
+   .fifo_depth = 0,
 };

 static struct resource omap2_mcspi2_resources[] = {
diff --git a/arch/arm/plat-omap/include/plat/mcspi.h
b/arch/arm/plat-omap/include/plat/mcspi.h
index 1254e49..ffda0a1 100644
--- a/arch/arm/plat-omap/include/plat/mcspi.h
+++ b/arch/arm/plat-omap/include/plat/mcspi.h
@@ -1,8 +1,35 @@
 #ifndef _OMAP2_MCSPI_H
 #define _OMAP2_MCSPI_H

+#define OMAP2_MCSPI_MASTER 0
+#define OMAP2_MCSPI_SLAVE  1
+
+/**
+ * struct omap2_mcspi_platform_config - McSPI controller configuration + *
@num_cs: Number of chip selects or channels supported
+ * @mode: SPI is master or slave
+ * @dma_mode: Use only DMA for data transfers
+ * @force_cs_mode: Use force chip select mode or auto chip select mode + *
@fifo_depth: FIFO depth in bytes, max value 64
+ *
+ * @dma_mode when set to 1 uses only dma for data transfers
+ * else the default behaviour is to use PIO mode for transfer
+ * size of 8 bytes or less. This mode is useful when mcspi
+ * is configured as slave
+ *
+ * @force_cs_mode when set to 1 allows continuous transfer of multiple + * spi
words without toggling the chip select line.
+ *
+ * @fifo_depth when set to non zero values enables FIFO. fifo_depth + * should
be set as a multiple of buffer size used for read/write. + */
+
 struct omap2_mcspi_platform_config {
-   unsigned short  num_cs;
+   u8  num_cs;
+   u8  mode;
+   u8  dma_mode;
+   u8  force_cs_mode;
+   unsigned short fifo_depth;
 };

 struct omap2_mcspi_device_config {
-- 
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 V2 0/3] McSPI Slave, FIFO support on OMAP

[Hemanth V]

This patch series adds support for slave, FIFO for McSPI on OMAP.

DMA and FIFO could be enabled together for better throughput. Platform config
parameters have been added to enable these features on any particular McSPI
controller.

FIFO can be enabled by defining fifo_depth parameter. fifo_depth needs to be a
multiple of buffer size that is used for read/write.

These features are useful when you have high throughput devices on SPI.

This patch incorporates review comments

PATCH[1/3]: Update Platform files for SPI
PATCH[2/3]: Adds support for FIFO
PATCH[3/3]: Adds support for Slave mode

Signed-off-by: Hemanth V 
---
 arch/arm/mach-omap2/devices.c   |5 +
 arch/arm/plat-omap/include/mach/mcspi.h |   16 ++
 drivers/spi/omap2_mcspi.c   |  345 +++---
3 files changed, 331 insertions(+), 35 deletions(-)








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

Re: Enabling spidev in MCSPI1

[Hemanth V]

> I'm trying to enable spidev on mcspi1, but when I do, the kernel while
> booting after the kernel is uncompressed. No useful messages are
> displayed. This is with a current git.
>
> I've attached the diff I use to add the spi driver to the board file.
> (OVero + Summit).
>
> With the #if 0 inplace the kernel boots, enable that code and it fails.
>
> +#if 0
> +   spi_register_board_info(overo_mcspi_board_info,
> +   ARRAY_SIZE(overo_mcspi_board_info));
> +#endif
>
> Does anyone see anything obviously wrong with what I am doing?
>

Is SPI1 also used for touchscreen on your board, if so it might be conflicting

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

Error while using OMAP_DMA_SYNC_FRAME

[Hemanth V]

Hi All,

 I have been trying to use Frame sync for DMA on l-o tree, which is basically
useful when peripherals have built-in fifo and DMA synchronization happens for
the configured number on elements.

I am seeing the error "DMA synchronization event drop occurred with device".
Anyone else seen this error or have any inputs.

Thanks
Hemanth

--
To unsubscribe from this list: send the line "unsubscribe 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: omap3evm: touchscreen delays on pm branch

[Hemanth V]

- Original Message - 
From: "Premi, Sanjeev" 

To: "Dasgupta, Romit" 
Cc: 
Sent: Friday, November 27, 2009 3:20 PM
Subject: RE: omap3evm: touchscreen delays on pm branch



-Original Message-
From: Dasgupta, Romit 
Sent: Friday, November 27, 2009 2:38 PM

To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: RE: omap3evm: touchscreen delays on pm branch

On Fri, 2009-11-27 at 14:11 +0530, Premi, Sanjeev wrote:
> > -Original Message-
> > From: Dasgupta, Romit 
> > Sent: Friday, November 27, 2009 2:10 PM

> > To: Premi, Sanjeev
> > Cc: linux-omap@vger.kernel.org
> > Subject: Re: omap3evm: touchscreen delays on pm branch
> > 
> > Premi, Sanjeev wrote:

> > > Hi,
> > > 
> > > I am finding the response of touchscreen on the 
omap3evm very slow.
> > > 
> > > Here is my test:

> > > On console, I run : watch -n2 "cat /proc/interrupts"
> > > Then, I tap the touchscreen approximately once per 
second. However,
> > > (usually) no interrupts are registered. As I increase 
the frequency

> > > of 'taps' more and more interrupts are registered. But still not
> > > matching exact taps.
> > > 
> > > However, when I keep the cpu busy with "cat /dev/zero > 
/dev/null &"

> > > each tap is recognized.
> > > 
> > Do you see this even if we don't enable OFF?
> > 
> Yes. Sleep_while_idle=0; enable_off_mode=0

> ~sanjeev

Hopefully you have the same TSC driver. Nevertheless, can you 
please try
this (just to see if clock domain idling is causing any 
problem or not):


It is the same driver at SDP3430. I had earlier tried removing
cpuidle altogether and did not see this issue. I too believe that
issue is caused by clocks being going to (auto)idle.

But then, Hemanth should be seeing the same behavior.


Zoom2/Zoom3 use a different touchscreen driver compared to SDP.
Its uses Synaptic Touchscreen over I2C.
--
To unsubscribe from this list: send the line "unsubscribe 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: omap3evm: touchscreen delays on pm branch

[Hemanth V]

- Original Message - 
From: "Premi, Sanjeev" 

To: 
Sent: Thursday, November 26, 2009 10:32 PM
Subject: omap3evm: touchscreen delays on pm branch



Hi,

I am finding the response of touchscreen on the omap3evm very slow.

Here is my test:
On console, I run : watch -n2 "cat /proc/interrupts"
Then, I tap the touchscreen approximately once per second. However,
(usually) no interrupts are registered. As I increase the frequency
of 'taps' more and more interrupts are registered. But still not
matching exact taps.

However, when I keep the cpu busy with "cat /dev/zero > /dev/null &"
each tap is recognized.

EVM uses GPIO175 for touchscreen. I notice that Zoom2 uses GPIO102.
Both are not on BANK0.

Is the behavior same on ZOOM2 as well?


I dont see this problem on Zoom2/Zoom3, I am able to see interrupts being
incremented for every touch.



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


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

Re: [PATCH 0/8] Series short description

[Hemanth V]

- Original Message - 
From: "Tony Lindgren" 

To: 
Cc: 
Sent: Thursday, November 26, 2009 5:48 AM
Subject: [PATCH 0/8] Series short description



Hi all,

Here are some omap mux updates for review. These
are intended for the v2.6.33 merge window.

Initially this series changes the omap34xx mux
code, I'm planning on adding 3630, 2420, and 2430
code later on.

There are several reasons why we need better mux
code:

- We want to make the mux code more generic and this
 will allow us to use the internal signal names and
 gpio numbers instead of mux register offsets. The
 internal signal names stay the same across omap
 generations for some devices.

- We need to map mux registers to GPIO registers for
 dynamic muxing of the GPIO pins during off-idle.

- We want to be able to override the bootloader mux
 values for the modded boards, such as the Beagle.

- We want to have the mux signals and balls available
 under debugfs for debugging new drivers.


Does it also detect conflicts when two drivers try
to step on each other and overwrite the mux settings of
other. SPI and EHCI was one of the problems I faced.




Some of these might eventually work for other archs
too, so let me know if you have any comments on that.

Regards,

Tony

Here are some instructions on how to use:

To see what got muxed during init, edit the kernel
CMDLINE to have debug in it:

# dmesg | grep mux
mux: Setting signal i2c2_scl.i2c2_scl 0x0100 -> 0x0100
mux: Setting signal i2c2_sda.i2c2_sda 0x0100 -> 0x0100
mux: Setting signal i2c3_scl.i2c3_scl 0x0100 -> 0x0100
mux: Setting signal i2c3_sda.i2c3_sda 0x0100 -> 0x0100
mux: Setting signal gpmc_ncs3.gpio54 0x410c -> 0x010c
...

Looks like the gpmc_ncs3.gpio54 muxing in the kernel
has a bug where we should have OMAP_WAKEUP_EN set for
board_smc91x_init for board-rx51? :)

To override bootloader mux settings, edit the kernel CMDLINE:

omap_mux=i2c2_scl.i2c2_scl=0x100,i2c2_sda.i2c2_sda=0x100

Note that this only changes the bootloader settings, not
what might be muxed from the board-*.c files.

With CONFIG_DEBUG_FS set:

# mount -t sysfs sys /sys
# mount -t debugfs debug /sys/kernel/debug

# ls /sys/kernel/debug/omap_mux/i2c
i2c2_scl  i2c2_sda  i2c3_scl  i2c3_sda  i2c4_scl  i2c4_sda

# cat /sys/kernel/debug/omap_mux/i2c2_scl
name: i2c2_scl.i2c2_scl (0x480021be/0x18e = 0x0100), b af15, t NA
mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0
signals: i2c2_scl | NA | NA | NA | gpio_168 | NA | NA | safe_mode

---

Mike Rapoport (1):
 omap2: mux: intoduce omap_mux_{read,write}

Tony Lindgren (7):
 omap: mux: Add new style pin multiplexing code for omap3
 omap: mux: Add new style pin multiplexing data for 34xx
 omap: mux: Add new style init functions to omap3 board-*.c files
 omap: mux: Add debugfs support for new mux code
 omap: Split i2c platform init for mach-omap1 and mach-omap2
 omap: mux: Replace omap_cfg_reg() with new style signal or gpio 
functions

 omap: mux: Remove old mux code for 34xx


arch/arm/mach-omap2/Makefile |4
arch/arm/mach-omap2/board-3430sdp.c  |   13
arch/arm/mach-omap2/board-3630sdp.c  |3
arch/arm/mach-omap2/board-am3517evm.c|   11
arch/arm/mach-omap2/board-cm-t35.c   |   13
arch/arm/mach-omap2/board-igep0020.c |   11
arch/arm/mach-omap2/board-ldp.c  |   10
arch/arm/mach-omap2/board-omap3beagle.c  |   21
arch/arm/mach-omap2/board-omap3evm.c |   21
arch/arm/mach-omap2/board-omap3pandora.c |   15
arch/arm/mach-omap2/board-overo.c|   14
arch/arm/mach-omap2/board-rx51-peripherals.c |7
arch/arm/mach-omap2/board-rx51.c |   16
arch/arm/mach-omap2/board-zoom2.c|   11
arch/arm/mach-omap2/devices.c|   62 +
arch/arm/mach-omap2/mux.c|  961 ++--
arch/arm/mach-omap2/mux.h|  150 +++
arch/arm/mach-omap2/mux34xx.c| 1558 
++

arch/arm/mach-omap2/mux34xx.h|  351 ++
arch/arm/mach-omap2/usb-ehci.c   |  122 +-
arch/arm/plat-omap/i2c.c |   24
arch/arm/plat-omap/include/plat/common.h |1
arch/arm/plat-omap/include/plat/mux.h|  222 
arch/arm/plat-omap/mux.c |8
24 files changed, 2932 insertions(+), 697 deletions(-)
create mode 100644 arch/arm/mach-omap2/mux.h
create mode 100644 arch/arm/mach-omap2/mux34xx.c
create mode 100644 arch/arm/mach-omap2/mux34xx.h

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



--
To unsubscribe from this list: send the line "unsubscribe 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] OMAP3: introduce OMAP3630

[Hemanth V]

> Muxes for OMAP 3630.

What is the plan to add omap_cfg_reg calls for these new pins, which actually
configures these pin muxes.

Thanks
Hemanth

>
> Signed-off-by: Allen Pais 
> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
> index b5fac32..93abb74 100644
> --- a/arch/arm/mach-omap2/mux.c
> +++ b/arch/arm/mach-omap2/mux.c
> @@ -551,6 +551,42 @@ MUX_CFG_34XX("AF13_3430_MMC3_DAT3", 0x5e2,
>  MUX_CFG_34XX("AF26_34XX_SYS_NIRQ", 0x1E0,
>   OMAP3_WAKEUP_EN | OMAP34XX_PIN_INPUT_PULLUP |
>   OMAP34XX_MUX_MODE0)
> +
> +/*Muxes for 3630 */
> +MUX_CFG_34XX("H26_3630_DSS_DATA18", 0x100,
> + OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("H25_3630_DSS_DATA19", 0x102,
> + OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("E28_3630_DSS_DATA20", 0x104,
> + OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("J26_3630_DSS_DATA21", 0x106,
> + OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AC27_3630_DSS_DATA22", 0x108,
> + OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AC28_3630_DSS_DATA23", 0x10A,
> + OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +
> +MUX_CFG_34XX("AF9_3630_ETKD8", 0x5EC,
> + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AG9_3630_ETKD9", 0x5EE,
> + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AG7_3630_ETKD12", 0x5F0,
> + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +
> +MUX_CFG_34XX("AA25_3630_UART2_TX", 0x178,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AD25_3630_UART2_RX", 0x17A,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AB25_3630_UART2_RTS", 0x176,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AB26_3630_UART2_CTS", 0x174,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +
> +MUX_CFG_34XX("H20_UART3_RX_IRRX", 0x19E,
> + OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("H21_UART3_TX_IRTX", 0x1A0,
> + OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +
>  };
>
>  #define OMAP34XX_PINS_SZ ARRAY_SIZE(omap34xx_pins)
> diff --git a/arch/arm/plat-omap/include/mach/mux.h
> b/arch/arm/plat-omap/include/mach/mux.h
> index 0f49d2d..8d8cbe1 100644
> --- a/arch/arm/plat-omap/include/mach/mux.h
> +++ b/arch/arm/plat-omap/include/mach/mux.h
> @@ -890,6 +890,32 @@ enum omap34xx_index {
>
>   /* SYS_NIRQ T2 INT1 */
>   AF26_34XX_SYS_NIRQ,
> +
> + /*Muxes for 3630*/
> + K28_3630_CAM_D6,
> + L28_3630_CAM_D7,
> + K27_3630_CAM_D8,
> + L27_3630_CAM_D9,
> +
> + H26_3630_DSS_DATA18,
> + H25_3630_DSS_DATA19,
> + E28_3630_DSS_DATA20,
> + J26_3630_DSS_DATA21,
> + AC27_3630_DSS_DATA22,
> + AC28_3630_DSS_DATA23,
> +
> + AF9_3630_ETKD8,
> + AG9_3630_ETKD9,
> + AG7_3630_ETK12,
> +
> + AA25_3630_UART2_TX,
> + AD25_3630_UART2_RX,
> + AB25_3630_UART2_RTS,
> + AB26_3630_UART2_CTS,
> +
> + H20_UART3_RX_IRRX,
> + H21_UART3_TX_IRTX,
> +
>  };
>
>  struct omap_mux_cfg {--
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>


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

Re: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor autoloading feature

[Hemanth V]

- Original Message - 
From: "S, Venkatraman" 

To: 
Cc: ; "Shilimkar, Santosh" 


Sent: Thursday, August 27, 2009 4:41 PM
Subject: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor autoloading feature


(Updated version of previous patch: 
http://marc.info/?l=linux-omap&m=125012097403050&w=2)

Add sDMA driver support for descriptor autoloading feature.
Descriptor autoloading is OMAP4 sDMA hardware capability that can be 
exploited for scatter gather scenarios.


The feature works as described below
1) A sDMA channel is programmed to be in 'linked list' mode
2) The client (sDMA user) provides a list of descriptors in a linked list 
format
3) Each of the 'descriptor' (element in the linked list) contains an 
updated set of DMA configuration register values

4) Client starts DMA transfer
5) sDMA controller loads the first element to its register configuration 
memory and executes the transfer
6) After completion, loads the next element (in linked list) to 
configuration memory and executes the transfer, without MCU intervention.
7) Interrupt is generated after all transfers are completed; this can be 
configured to be done differently.


Configurations and additional features
1) Fast mode & non-fast mode
  Fast mode/non-fast decides on how the first transfer begins. In 
non-fast mode, the first element in the linked list is loaded only after 
completing the transfer according to the configurations already in the 
sDMA channel registers. In fast mode, the loading of the first element 
precedes the transfer.


2) Pause / resume of transfers
  A transfer can be paused after a descriptor set has been loaded, 
provided the 'pause bit' is set in the linked list element.
An ongoing transfer cannot be paused. If the 'pause bit' is set, transfer 
is not started after loading the register set from memory.

Such a transfer can be resumed later.

3) Descriptor types
  3 possible configurations of descriptors (initialized as linked list 
elements) are possible. Type 1 provides the maximum flexibility, which 
contains most register definitions of a DMA logical channel. Fewer options 
are present in type 2. Type 3 can just modify source/destinations address 
of transfers. In all transfers, unmodified registers settings are 
maintained for the next transfer.


Patch provides options / API for
1) Setting up a descriptor loading for DMA channel for sg type transfers
2) configuration with linked list elements
3) Starting / pause and resume of the said transfers, query state
4) Closing/Releasing the DMA channel

The patches are generated against kernel 2.6.31-rc1, tested on OMAP4 
simulator platform.


It might be easier to understand the APIs if you could provide an example. 
Could you take example of a contiguous/non-contiguous buffer and explain how 
the desciptor based DMA could be used on this. 


--
To unsubscribe from this list: send the line "unsubscribe 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: [spi-devel-general] [RESEND][PATCH 0/2] McSPI Slave and DMA , FIFO support

[Hemanth V]

 Original Message - 
From: "David Brownell" 




On Sunday 05 July 2009, Hemanth V wrote:

Do you see any major changes required to support
slave mode in the SPI core driver.


There *is* no such thing as a "SPI core driver"...


I was referring to

spi.c - SPI init/core code



We are able to 
use the existing interface for slave mode also, but

some APIs/ Structures could be made generic.


Three things are obvious:

- A spi_master is not a slave side driver!


Yes a more generic or new structure would be good,
but the current one does work for slave mode also.



- Control model would need to be inverted
   * Chip select would be one input,
 not N outputs
   * No clock rate controls at all


Conditional checks for slave/master mode have been added in
the driver where required.


   * latency issues ... driver can't necessarily
 respond quickly enough to guarantee no data
 loss (FIFOs help)


We currently support both FIFO and DMA for
slave mode


   * Can't re-use /dev/spidev*
   * Request queue would have a very different role

- Some primitives are likely missing, for flow
  control (when hardware has a READY handshake)

I think a few proposals for how to handle slave
side have been circulated.


So would it be possible to merge the slave support also for
now, and could be modified to support the new slave interface
as and when available.

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

Re: [PATCH 1/5] ARM: OMAP2/3/4: Split OMAP2_IO_ADDRESS to L3 and L4

[Hemanth V]

- Original Message - 
From: "Shilimkar, Santosh" 

---
#define L3_IO_OFFSET 0x9000
#define __L3_IO_ADDRESS(pa) ((pa) + L3_IO_OFFSET)/* Works for L3 */
#define __OMAP2_L3_IO_ADDRESS(pa) ((pa) + L3_IO_OFFSET)/* Works for L3
*/
#define l3_io_v2p(va) ((va) - L3_IO_OFFSET)/* Works for L3 */

#define IO_OFFSET 0xb200
#define __IO_ADDRESS(pa) ((pa) + IO_OFFSET)/* Works for L4  */
#define __OMAP2_IO_ADDRESS(pa) ((pa) + IO_OFFSET)/* Works for L4 */
#define io_v2p(va) ((va) - IO_OFFSET)/* Works for L4*/
---

This way you don't have to introduce new L4 macro at all => much lesser
code impact.
Initially I thought about this but later preferred to split it. The only 
change what you are suggesting is instead of calling 
"OMAP2_L4_IO_ADDRESS", we keep >that as "OMAP2_IO_ADDRESS". But the idea 
was to differentiate between various IO accesses because at some point of 
time all these has to be removed in
favor of ioremap() + read*()/write*() one by one and that time this would 
be beneficial.


Does that mean all drivers, including the ones in other trees like camera, 
dss etc need to be modified if they are using IO_ADDRESS macros. The idea of 
having a macro as below was to reduce this impact.


#define __IO_ADDRESS(pa) ((pa) >= L3_34XX_PHYS ?   ((pa) + L3_IO_OFFSET) : 
((pa) + IO_OFFSET))


--
To unsubscribe from this list: send the line "unsubscribe 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: Zoom2 Support on LO Master broken ?

[Hemanth V]

- Original Message - 
From: "Hemanth V" 

To: 
Sent: Monday, August 17, 2009 5:48 PM
Subject: Zoom2 Support on LO Master broken ?



I am unable to boot from quad uart and if I try uart3 I get the below error


For quad uart it stops after downloading kernel (ZOOM2 defconfig), probably 
related to LL_DEBUG setting.




<3>IP-Config: No network devices available.
IP-Config: No network devices available.
--
To unsubscribe from this list: send the line "unsubscribe 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: PM branch update: rebase to .31-rc, added omap_hwmod/omap_device

[Hemanth V]

- Original Message - 
From: "Kevin Hilman" 

Known problems:



- network drivers and off-mode
 - various hangs when using off-while-idle and NFS-mounted rootfs
 - network drivers likely need some context save/restore support


Kevin, was this known to work earlier. Could this be related to
GPMC context save/restore.

Thanks
Hemanth
--
To unsubscribe from this list: send the line "unsubscribe 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: Warnings: pm branch

[Hemanth V]

- Original Message - 
From: "Kevin Hilman" 

 /* enter the state and update stats */
@@ -91,6 +93,12 @@ static void cpuidle_idle_call(void)
 /* give the governor an opportunity to reflect on the outcome */
 if (cpuidle_curr_governor->reflect)
 cpuidle_curr_governor->reflect(dev);
+
+ return;
+


... I think you want to drop this return.  If it returns here, it
will still not enable IRQs.  I think it should just fall through
to the enable and return.


Since omap3_enter_idle returns with interrupts enabled, I had
added this return. We could remove it also for safety purposes.

Thanks
Hemanth
--
To unsubscribe from this list: send the line "unsubscribe 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: Warnings: pm branch

[Hemanth V]

> - Original Message -
> From: "Kevin Hilman" 
> To: "Pandita, Vikram" 
> Cc: 
> Sent: Tuesday, August 11, 2009 8:57 PM
> Subject: Re: Warnings: pm branch
>
>
>> "Pandita, Vikram"  writes:
>>
>>> Has anyone send these warning logs on the pm branch on kevin's tree [1]
>>> This seems to be some issue in CpuIdle path with interrupts?
>>>
>>> <4>WARNING: at arch/arm/kernel/process.c:171 cpu_idle+0x60/0x88()
>>> WARNING: at arch/arm/kernel/process.c:171 cpu_idle+0x60/0x88()
>>> Modules linked in:Modules linked in:
>>> [] [] (unwind_backtrace+0x0/0xdc)
>>> (unwind_backtrace+0x0/0xdc
>>> ) from [] from [] (warn_slowpath_common+0x48/0x60)
>>> (warn_slowpath_common+0x48/0x60)
>>> [] [] (warn_slowpath_common+0x48/0x60)
>>> (warn_slowpath_common
>>> +0x48/0x60) from [] from [] (cpu_idle+0x60/0x88)
>>> (cpu_idle+0x60/0x88)
>>> [] [] (cpu_idle+0x60/0x88) (cpu_idle+0x60/0x88) from
>>> [>> a70>] from [] (start_kernel+0x234/0x28c)
>>> (start_kernel+0x234/0x28c)
>>> [] [] (start_kernel+0x234/0x28c)
>>> (start_kernel+0x234/0x28c)
>>> from [<80008034>] from [<80008034>] (0x80008034)
>>> (0x80008034)
>>>
>>
>> Yes, I've seen it, but have yet to debug it.
>>
>> This warning is from the generic ARM idle loop reporting that the OMAP
>> idle path is returning with IRQs disabled.
>>
>> Kevin
>
> I did some more debugging on this. I added the below instrumentation to
> local_irq_disable to capture
> the PC of the last call to local_irq_disable.
>
> extern unsigned long hem_pc;
> register unsigned long current_pc asm ("pc");
>
> #define local_irq_disable() \
> do { hem_pc = current_pc;raw_local_irq_disable();
> trace_hardirqs_off(); } while (0)
>
>
> When I set a breakpoint  at the instruction pointing to
> WARN_ON(irqs_disabled()) using
> lauterbach and dump hem_pc, I see that the last call to irq_disable is
> actuall from cpu_idle itself.
> Looks like some recursion is happening. Does anyone have any inputs on this.
>
> void cpu_idle(void)
> {
>
> local_fiq_enable();
>
> /* endless idle loop with no priority at all */
> while (1) {
> tick_nohz_stop_sched_tick(1);
> leds_event(led_idle_start);
> while (!need_resched()) {
> #ifdef CONFIG_HOTPLUG_CPU
> if (cpu_is_offline(smp_processor_id()))
> cpu_die();
> #endif
>
>>>local_irq_disable();
>
>
> Thanks
> Hemanth
>

Below patch seems to fix the issue.

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 8504a21..3014104 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -75,8 +75,10 @@ static void cpuidle_idle_call(void)
 #endif
/* ask the governor for the next state */
next_state = cpuidle_curr_governor->select(dev);
+
if (need_resched())
-   return;
+   goto out;
+
target_state = &dev->states[next_state];

/* enter the state and update stats */
@@ -91,6 +93,12 @@ static void cpuidle_idle_call(void)
/* give the governor an opportunity to reflect on the outcome */
if (cpuidle_curr_governor->reflect)
cpuidle_curr_governor->reflect(dev);
+
+   return;
+
+out:
+   local_irq_enable();
+   return;
 }

 /**


--
To unsubscribe from this list: send the line "unsubscribe 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: Warnings: pm branch

[Hemanth V]

- Original Message - 
From: "Kevin Hilman" 

To: "Pandita, Vikram" 
Cc: 
Sent: Tuesday, August 11, 2009 8:57 PM
Subject: Re: Warnings: pm branch



"Pandita, Vikram"  writes:


Has anyone send these warning logs on the pm branch on kevin's tree [1]
This seems to be some issue in CpuIdle path with interrupts?

<4>WARNING: at arch/arm/kernel/process.c:171 cpu_idle+0x60/0x88()
WARNING: at arch/arm/kernel/process.c:171 cpu_idle+0x60/0x88()
Modules linked in:Modules linked in:
[] [] (unwind_backtrace+0x0/0xdc) 
(unwind_backtrace+0x0/0xdc

) from [] from [] (warn_slowpath_common+0x48/0x60)
(warn_slowpath_common+0x48/0x60)
[] [] (warn_slowpath_common+0x48/0x60) 
(warn_slowpath_common

+0x48/0x60) from [] from [] (cpu_idle+0x60/0x88)
(cpu_idle+0x60/0x88)
[] [] (cpu_idle+0x60/0x88) (cpu_idle+0x60/0x88) from 
[
a70>] from [] (start_kernel+0x234/0x28c)
(start_kernel+0x234/0x28c)
[] [] (start_kernel+0x234/0x28c) 
(start_kernel+0x234/0x28c)

from [<80008034>] from [<80008034>] (0x80008034)
(0x80008034)



Yes, I've seen it, but have yet to debug it.

This warning is from the generic ARM idle loop reporting that the OMAP
idle path is returning with IRQs disabled.

Kevin


I did some more debugging on this. I added the below instrumentation to 
local_irq_disable to capture

the PC of the last call to local_irq_disable.

extern unsigned long hem_pc;
register unsigned long current_pc asm ("pc");

#define local_irq_disable() \
   do { hem_pc = current_pc;raw_local_irq_disable(); 
trace_hardirqs_off(); } while (0)



When I set a breakpoint  at the instruction pointing to 
WARN_ON(irqs_disabled()) using
lauterbach and dump hem_pc, I see that the last call to irq_disable is 
actuall from cpu_idle itself.

Looks like some recursion is happening. Does anyone have any inputs on this.

void cpu_idle(void)
{

   local_fiq_enable();

   /* endless idle loop with no priority at all */
   while (1) {
   tick_nohz_stop_sched_tick(1);
   leds_event(led_idle_start);
   while (!need_resched()) {
#ifdef CONFIG_HOTPLUG_CPU
   if (cpu_is_offline(smp_processor_id()))
   cpu_die();
#endif


   local_irq_disable();



Thanks
Hemanth 


--
To unsubscribe from this list: send the line "unsubscribe 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: User/kernel memory split

[Hemanth V]

- Original Message - 
From: "Dasgupta, Romit" 



Hemanth,
  Why do you want the split? Do you have physical mem > 1G 
in your system?


We want to fit 512MB RAM on 2.6.27 Kernel which doesnot have highmem option.
We also donot want to disturb the current I/O memory map


-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of V, Hemanth
Sent: Monday, July 06, 2009 3:23 PM
To: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org
Subject: User/kernel memory split

Hi All

Has anyone tried 3.5G/1.5G user/kernel memory split.
Are there any know issues in this.

Thanks
Hemanth


arch/arm/Kconfig
choice
   prompt "Memory split"
   default VMSPLIT_3G
   help
 Select the desired split between kernel and user memory.

 If you are not absolutely sure what you are doing, leave this
 option alone!

   config VMSPLIT_3G
   bool "3G/1G user/kernel split"
   config VMSPLIT_2G
   bool "2G/2G user/kernel split"
   config VMSPLIT_1G
   bool "1G/3G user/kernel split"

--
To unsubscribe from this list: send the line "unsubscribe 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

User/kernel memory split

[Hemanth V]

Hi All

Has anyone tried 3.5G/1.5G user/kernel memory split. 
Are there any know issues in this.


Thanks
Hemanth


arch/arm/Kconfig
choice
   prompt "Memory split"
   default VMSPLIT_3G
   help
 Select the desired split between kernel and user memory.

 If you are not absolutely sure what you are doing, leave this
 option alone!

   config VMSPLIT_3G
   bool "3G/1G user/kernel split"
   config VMSPLIT_2G
   bool "2G/2G user/kernel split"
   config VMSPLIT_1G
   bool "1G/3G user/kernel split"

--
To unsubscribe from this list: send the line "unsubscribe 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: [RESEND][PATCH 0/2] McSPI Slave and DMA ,FIFO support

[Hemanth V]

- Original Message - 
From: "David Brownell" 




On Tuesday 23 June 2009, Hemanth V wrote:

This series of 2 patches adds support for McSPI slave
and DMA,FIFO. It incorporates review comments from
Kevin Hilman and Tony Lindgren


PATCH[1/2]: Changes to arch specific files
PATCH[2/2]: omap2_mcspi.c file changes


Needs some changes yet:

 - Split out slave support as a separate patch.
   That's not really supported by the interface yet.


Do you see any major changes required to support
slave mode in the SPI core driver. We are able to
use the existing interface for slave mode also, but
some APIs/ Structures could be made generic.


--
To unsubscribe from this list: send the line "unsubscribe 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 1/2] McSPI Slave and DMA,FIFO support

[Hemanth V]

This patch adds support for McSPI slave and FIFO. DMA and FIFO
could be enabled together for better throughput. Platform config
parameters have been added to enable these features on any particular
McSPI controller.

FIFO can be enabled by defining fifo_depth parameter. fifo_depth needs
to be a multiple of buffer size that is used for read/write.

These features are useful when you have high throughput devices
like WLAN or Modem connected over SPI.

Signed-off-by: Hemanth V 
 arch/arm/mach-omap2/devices.c   |5 +
 arch/arm/plat-omap/include/mach/mcspi.h |   16 
 2 files changed, 21 insertions(+)

---
Index: linux-omap-2.6/arch/arm/mach-omap2/devices.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/devices.c   2009-06-18
15:22:39.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/devices.c2009-06-23 
16:45:51.0
+0530
@@ -259,6 +259,7 @@

 static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
.num_cs = 4,
+   .force_cs_mode  = 1,
 };

 static struct resource omap2_mcspi1_resources[] = {
@@ -281,6 +282,10 @@

 static struct omap2_mcspi_platform_config omap2_mcspi2_config = {
.num_cs = 2,
+   .mode   = OMAP2_MCSPI_MASTER,
+   .dma_mode   = 1,
+   .force_cs_mode  = 0,
+   .fifo_depth = 0,
 };

 static struct resource omap2_mcspi2_resources[] = {
Index: linux-omap-2.6/arch/arm/plat-omap/include/mach/mcspi.h
===
--- linux-omap-2.6.orig/arch/arm/plat-omap/include/mach/mcspi.h 2009-06-18
15:22:39.0 +0530
+++ linux-omap-2.6/arch/arm/plat-omap/include/mach/mcspi.h  2009-06-23
16:45:51.0 +0530
@@ -1,8 +1,24 @@
 #ifndef _OMAP2_MCSPI_H
 #define _OMAP2_MCSPI_H

+#define OMAP2_MCSPI_MASTER 0
+#define OMAP2_MCSPI_SLAVE  1
+
 struct omap2_mcspi_platform_config {
unsigned short  num_cs;
+
+   /* SPI is master or slave */
+   unsigned short  mode;
+
+   /* Use only DMA for data transfers */
+   unsigned short  dma_mode;
+
+   /* Force chip select mode */
+   unsigned short  force_cs_mode;
+
+   /* FIFO depth in bytes, max value 64 */
+   unsigned short fifo_depth;
+
 };

 struct omap2_mcspi_device_config {


--
To unsubscribe from this list: send the line "unsubscribe 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 2/2] McSPI Slave and DMA,FIFO support

[Hemanth V]

This patch adds support for McSPI slave and FIFO. DMA and FIFO
could be enabled together for better throughput.

This has a dependency on patch
[RESEND][PATCH 1/2] McSPI Slave and DMA,FIFO support

Signed-off-by: Hemanth V 
 drivers/spi/omap2_mcspi.c |  353 --
 1 files changed, 314 insertions(+), 39 deletions(-)

Index: linux-omap-2.6/drivers/spi/omap2_mcspi.c
===
--- linux-omap-2.6.orig/drivers/spi/omap2_mcspi.c   2009-06-23 
16:46:19.0
+0530
+++ linux-omap-2.6/drivers/spi/omap2_mcspi.c2009-06-23 18:38:40.0 
+0530
@@ -37,9 +37,11 @@

 #include 
 #include 
+#include 


 #define OMAP2_MCSPI_MAX_FREQ   4800
+#define OMAP2_MCSPI_MAX_FIFODEPTH  64

 #define OMAP2_MCSPI_REVISION   0x00
 #define OMAP2_MCSPI_SYSCONFIG  0x10
@@ -49,6 +51,7 @@
 #define OMAP2_MCSPI_WAKEUPENABLE   0x20
 #define OMAP2_MCSPI_SYST   0x24
 #define OMAP2_MCSPI_MODULCTRL  0x28
+#define OMAP2_MCSPI_XFERLEVEL  0x7c

 /* per-channel banks, 0x14 bytes each, first is: */
 #define OMAP2_MCSPI_CHCONF00x2c
@@ -83,10 +86,13 @@
 #define OMAP2_MCSPI_CHCONF_IS  (1 << 18)
 #define OMAP2_MCSPI_CHCONF_TURBO   (1 << 19)
 #define OMAP2_MCSPI_CHCONF_FORCE   (1 << 20)
+#define OMAP2_MCSPI_CHCONF_FFET(1 << 27)
+#define OMAP2_MCSPI_CHCONF_FFER(1 << 28)

 #define OMAP2_MCSPI_CHSTAT_RXS (1 << 0)
 #define OMAP2_MCSPI_CHSTAT_TXS (1 << 1)
 #define OMAP2_MCSPI_CHSTAT_EOT (1 << 2)
+#define OMAP2_MCSPI_IRQ_EOW(1 << 17)

 #define OMAP2_MCSPI_CHCTRL_EN  (1 << 0)

@@ -122,6 +128,10 @@
unsigned long   phys;
/* SPI1 has 4 channels, while SPI2 has 2 */
struct omap2_mcspi_dma  *dma_channels;
+   unsigned short  mcspi_mode;
+   unsigned short  dma_mode;
+   unsigned short  force_cs_mode;
+   unsigned short  fifo_depth;
 };

 struct omap2_mcspi_cs {
@@ -130,6 +140,37 @@
int word_len;
 };

+#ifdef CONFIG_SPI_DEBUG
+struct reg_type {
+   char name[40];
+   int offset;
+};
+
+static struct reg_type reg_map[] = {
+   {"MCSPI_REV", 0x0},
+   {"MCSPI_SYSCONFIG", 0x10},
+   {"MCSPI_SYSSTATUS", 0x14},
+   {"MCSPI_IRQSTATUS", 0x18},
+   {"MCSPI_IRQENABLE", 0x1C},
+   {"MCSPI_WAKEUPENABLE", 0x20},
+   {"MCSPI_SYST", 0x24},
+   {"MCSPI_MODULCTRL", 0x28},
+   {"MCSPI_XFERLEVEL", 0x7c},
+   {"CH0", 0x2C},
+   {"CH1", 0x40},
+   {"CH2", 0x54},
+   {"CH3", 0x68}
+};
+
+static struct reg_type ch_reg_type[] = {
+   {"CONF", 0x00},
+   {"STAT", 0x04},
+   {"CTRL", 0x08},
+   {"TX", 0x0C},
+   {"RX", 0x10},
+};
+#endif
+
 static struct workqueue_struct *omap2_mcspi_wq;

 #define MOD_REG_BIT(val, mask, set) do { \
@@ -185,6 +226,39 @@
mcspi_write_cs_reg(spi, OMAP2_MCSPI_CHCONF0, l);
 }

+#ifdef CONFIG_SPI_DEBUG
+static int
+omap2_mcspi_dump_regs(struct spi_master *master)
+{
+   u32 spi_base;
+   u32 reg;
+   u32 channel;
+   struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+
+   spi_base = (u32)mcspi->base;
+
+   for (reg = 0; (reg < ARRAY_SIZE(reg_map)); reg++) {
+   struct reg_type *reg_d = ®_map[reg];
+   u32 base1 = spi_base + reg_d->offset;
+   if (reg_d->name[0] == 'C') {
+   for (channel = 0; (channel < (ARRAY_SIZE(ch_reg_type)));
+   channel++) {
+   struct reg_type *reg_c = &ch_reg_type[channel];
+   u32 base2 = base1 + reg_c->offset;
+   pr_debug("MCSPI_%s%s [0x%08X] = 0x%08X\n",
+  reg_d->name, reg_c->name, base2,
+  __raw_readl(base2));
+   }
+   } else {
+   pr_debug("%s : [0x%08X] = 0x%08X\n",
+   reg_d->name, base1, __raw_readl(base1));
+   }
+
+   }
+   return 0;
+}
+#endif
+
 static void omap2_mcspi_set_enable(const struct spi_device *spi, int enable)
 {
u32 l;
@@ -202,34 +276,160 @@
mcspi_write_cs_reg(spi, OMAP2_MCSPI_CHCONF0, l);
 }

+static int omap2_mcspi_set_txfifo(const struct spi_device *spi, int buf_size,
+   int enable)
+{
+   u32 l, rw, s;
+   unsigned short revert = 0;
+   struct spi_master *master = spi->master;
+   struct omap2_mcspi *mcspi = spi_master_

[RESEND][PATCH 0/2] McSPI Slave and DMA ,FIFO support

[Hemanth V]

This series of 2 patches adds support for McSPI slave
and DMA,FIFO. It incorporates review comments from
Kevin Hilman and Tony Lindgren


PATCH[1/2]: Changes to arch specific files
PATCH[2/2]: omap2_mcspi.c file changes

 arch/arm/mach-omap2/devices.c   |5
 arch/arm/plat-omap/include/mach/mcspi.h |   16 +
 drivers/spi/omap2_mcspi.c   |  353
--


--
To unsubscribe from this list: send the line "unsubscribe 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: L-O master branch broken ?

[Hemanth V]

- Original Message - 
From: "Tony Lindgren" 

To: "Hemanth V" 
Cc: "Kevin Hilman" ; 


Sent: Thursday, June 18, 2009 3:52 PM
Subject: Re: L-O master branch broken ?



* Hemanth V  [090618 13:39]:

- Original Message - From: "Tony Lindgren" 


I get the below error while compiling 3430SDP. I see below commit  as 
the

latest one.




Thanks, pushing a fix right now with the missing brace missing from
Kevin's
sram.c patch. Also moved around the defines so sram.c build for omap1.



Booting still seems to have problems. Its hung after start kernel


Bytes transferred = 2480664 (25da18 hex)
## Booting image at 8000 ...
  Image Name:   Linux-2.6.30-omap1-06022-g6f4712
  Image Type:   ARM Linux Kernel Image (uncompressed)
  Data Size:2480600 Bytes =  2.4 MB
  Load Address: 80008000
  Entry Point:  80008000
  Verifying Checksum ... OK
OK

Starting kernel ...



Can you see what happens with DEBUG_LL enabled?


Doesn't seem to show any additional messages even with
DEBUG_LL enabled 


--
To unsubscribe from this list: send the line "unsubscribe 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: L-O master branch broken ?

[Hemanth V]

- Original Message - 
From: "Tony Lindgren" 




I get the below error while compiling 3430SDP. I see below commit  as the
latest one.




Thanks, pushing a fix right now with the missing brace missing from 
Kevin's

sram.c patch. Also moved around the defines so sram.c build for omap1.



Booting still seems to have problems. Its hung after start kernel


Bytes transferred = 2480664 (25da18 hex)
## Booting image at 8000 ...
  Image Name:   Linux-2.6.30-omap1-06022-g6f4712
  Image Type:   ARM Linux Kernel Image (uncompressed)
  Data Size:2480600 Bytes =  2.4 MB
  Load Address: 80008000
  Entry Point:  80008000
  Verifying Checksum ... OK
OK

Starting kernel ... 


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

L-O master branch broken ?

[Hemanth V]

I get the below error while compiling 3430SDP. I see below commit  as the 
latest one.


Hemanth

commit 3dc15d62d3f8e85d74dcbabc234585cb8dbc2194
Author: Tony Lindgren 
Date:   Thu Jun 18 08:59:09 2009 +0300

   Fix iommu.c file permissions

   Commit c8c8bfc4c3664317441b0037040c9bdea210fba1 changed the
   permissions, so undo that. Also checked the other files with:

   $ find arch/arm/*omap* -type f -perm 755

   Signed-off-by: Tony Lindgren 


arch/arm/plat-omap/sram.c: In function 'omap_detect_sram':
arch/arm/plat-omap/sram.c:139: error: expected expression before 'else'
arch/arm/plat-omap/sram.c:190: warning: ISO C90 forbids mixed declarations 
and code
arch/arm/plat-omap/sram.c:347: error: invalid storage class for function 
'omap242x_sram_init'
arch/arm/plat-omap/sram.c:368: error: invalid storage class for function 
'omap243x_sram_init'
arch/arm/plat-omap/sram.c:433: error: expected declaration or statement at 
end of input

make[1]: *** [arch/arm/plat-omap/sram.o] Error 1
make: *** [arch/arm/plat-omap] Error 2

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

Re: [PATCH] OMAP: McSPI: Fix RX DMA transfer path

[Hemanth V]

- Original Message - 
From: "Aaro Koskinen" 

Subject: [PATCH] OMAP: McSPI: Fix RX DMA transfer path



From: Eero Nurkkala 

When data is read through DMA, the last element must be read separately
through the RX register. It cannot be transferred by the DMA. For further
details see e.g. OMAP3430 TRM.


Could you provide the section number and the version of TRM you are
referring to.



Without the fix the driver causes extra clocks to be clocked to the
bus after DMA RX operations. This can cause interesting behaviour with
some devices.


Could you provide more details on the errors seen i.e is the transfer 
aborted


Thanks
Hemanth

--
To unsubscribe from this list: send the line "unsubscribe 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] McSPI Slave and DMA,FIFO support

[Hemanth V]

- Original Message - 
From: "Kevin Hilman" 

To: "Hemanth V" 
Cc: ; "Tony Lindgren" ; "David 
Brownell" 

Sent: Thursday, June 11, 2009 8:17 PM
Subject: Re: [PATCH 1/2] McSPI Slave and DMA,FIFO support



"Hemanth V"  writes:

- Original Message - 
From: "Hemanth V" 

To: "Tony Lindgren" 
Cc: 
Sent: Friday, June 05, 2009 3:28 PM
Subject: Re: [PATCH 1/2] McSPI Slave and DMA,FIFO support


- Original Message - 
From: "Tony Lindgren" 

To: "Hemanth V" 
Cc: 
Sent: Tuesday, June 02, 2009 11:36 PM
Subject: Re: [PATCH 1/2] McSPI Slave and DMA,FIFO support



Hi,

Sorry for the delay in replying, few comments below.

* Hemanth V  [090519 22:57]:

This patch adds support for McSPI slave and FIFO. DMA and FIFO
could be enabled together for better throughput. Platform config
parameters have been added to enable these features on any particular
McSPI controller.

FIFO can be enabled by defining fifo_depth parameter. fifo_depth needs
to be a multiple of buffer size that is used for read/write.

These features are useful when you have high throughput devices
like WLAN or Modem connected over SPI.

Signed-off-by: Hemanth V 
 arch/arm/mach-omap2/devices.c   |5
 arch/arm/plat-omap/include/mach/mcspi.h |   16 +
 drivers/spi/omap2_mcspi.c   |  343

 3 files changed, 325 insertions(+), 39 deletions(-)


As this is mostly drivers/spi/omap2_mcspi.c, this patch should get
merged via:

$ grep -A7 "SPI SUBSYSTEM" MAINTAINERS
SPI SUBSYSTEM
P:  David Brownell
M:  dbrown...@users.sourceforge.net
L:  spi-devel-gene...@lists.sourceforge.net
S:  Maintained
F:  Documentation/spi/
F:  drivers/spi/
F:  include/linux/spi/

Please keep linux-omap list Cc'd too so everybody can follow
the progress.


Tony, is this list active. The archives seem to be flooded with spam
mails

http://sourceforge.net/mailarchive/forum.php?forum_name=spi-devel-general





Kevin, Can u suggest what is to be done in this situation. spi-devel
list doesnot seem
to be active and Tony is not willing to merge this patch. Should I
send this to LKML


First, you haven't addressed any of the comments made on the list
about your series.

Tony isn't merging this patch because most of it should go via the SPI
subsystem.

A Santosh suggested, you need to break this up into parts that are
OMAP specific (arch/arm/*) and parts that go via the SPI subsystem
(drivers/spi/*.)  If doing this breaks your series, then fix it


But then that would cause a problem, we will not be able to
use arch/arm/plat-omap/include/mach/mcspi.h and will need to redefine those
variables in omap2_mcspi.c which obviously is not the preferred way.



because if it breaks compile this way, then upstream maintainers will
surely hit the same errors and complain.

David Brownell is the SPI maintainer.  I suggest you send to him,
CC'ing linux-omap.

Kevin




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

Re: [PATCH 1/2] McSPI Slave and DMA,FIFO support

[Hemanth V]

- Original Message - 
From: "Hemanth V" 

To: "Tony Lindgren" 
Cc: 
Sent: Friday, June 05, 2009 3:28 PM
Subject: Re: [PATCH 1/2] McSPI Slave and DMA,FIFO support


- Original Message - 
From: "Tony Lindgren" 

To: "Hemanth V" 
Cc: 
Sent: Tuesday, June 02, 2009 11:36 PM
Subject: Re: [PATCH 1/2] McSPI Slave and DMA,FIFO support



Hi,

Sorry for the delay in replying, few comments below.

* Hemanth V  [090519 22:57]:

This patch adds support for McSPI slave and FIFO. DMA and FIFO
could be enabled together for better throughput. Platform config
parameters have been added to enable these features on any particular
McSPI controller.

FIFO can be enabled by defining fifo_depth parameter. fifo_depth needs
to be a multiple of buffer size that is used for read/write.

These features are useful when you have high throughput devices
like WLAN or Modem connected over SPI.

Signed-off-by: Hemanth V 
 arch/arm/mach-omap2/devices.c   |5
 arch/arm/plat-omap/include/mach/mcspi.h |   16 +
 drivers/spi/omap2_mcspi.c   |  343 


 3 files changed, 325 insertions(+), 39 deletions(-)


As this is mostly drivers/spi/omap2_mcspi.c, this patch should get
merged via:

$ grep -A7 "SPI SUBSYSTEM" MAINTAINERS
SPI SUBSYSTEM
P:  David Brownell
M:  dbrown...@users.sourceforge.net
L:  spi-devel-gene...@lists.sourceforge.net
S:  Maintained
F:  Documentation/spi/
F:  drivers/spi/
F:  include/linux/spi/

Please keep linux-omap list Cc'd too so everybody can follow
the progress.


Tony, is this list active. The archives seem to be flooded with spam
mails

http://sourceforge.net/mailarchive/forum.php?forum_name=spi-devel-general





Kevin, Can u suggest what is to be done in this situation. spi-devel list 
doesnot seem
to be active and Tony is not willing to merge this patch. Should I send this 
to LKML


Thanks
Hemanth




---
Index: linux-omap-2.6/arch/arm/mach-omap2/devices.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/devices.c 2009-05-19
17:00:21.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/devices.c 2009-05-20 
11:02:41.0

+0530
@@ -259,6 +259,7 @@

 static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
 .num_cs = 4,
+ .force_cs_mode = 1,
 };

 static struct resource omap2_mcspi1_resources[] = {
@@ -281,6 +282,10 @@

 static struct omap2_mcspi_platform_config omap2_mcspi2_config = {
 .num_cs = 2,
+ .mode = OMAP2_MCSPI_MASTER,
+ .dma_mode = 1,
+ .force_cs_mode = 0,
+ .fifo_depth = 0,
 };

 static struct resource omap2_mcspi2_resources[] = {
Index: linux-omap-2.6/arch/arm/plat-omap/include/mach/mcspi.h
===
--- linux-omap-2.6.orig/arch/arm/plat-omap/include/mach/mcspi.h 
2009-05-19

17:00:21.0 +0530
+++ linux-omap-2.6/arch/arm/plat-omap/include/mach/mcspi.h 2009-05-20
11:02:41.0 +0530
@@ -1,8 +1,24 @@
 #ifndef _OMAP2_MCSPI_H
 #define _OMAP2_MCSPI_H

+#define OMAP2_MCSPI_MASTER 0
+#define OMAP2_MCSPI_SLAVE 1
+
 struct omap2_mcspi_platform_config {
 unsigned short num_cs;
+
+ /* SPI is master or slave */
+ unsigned short mode;
+
+ /* Use only DMA for data transfers */
+ unsigned short dma_mode;
+
+ /* Force chip select mode */
+ unsigned short force_cs_mode;
+
+ /* FIFO depth in bytes, max value 64 */
+ unsigned short fifo_depth;
+
 };

 struct omap2_mcspi_device_config {
Index: linux-omap-2.6/drivers/spi/omap2_mcspi.c
===
--- linux-omap-2.6.orig/drivers/spi/omap2_mcspi.c 2009-05-19 
17:00:21.0

+0530
+++ linux-omap-2.6/drivers/spi/omap2_mcspi.c 2009-05-20 
11:02:41.0 +0530

@@ -37,9 +37,11 @@

 #include 
 #include 
+#include 


 #define OMAP2_MCSPI_MAX_FREQ 4800
+#define OMAP2_MCSPI_MAX_FIFODEPTH 64

 #define OMAP2_MCSPI_REVISION 0x00
 #define OMAP2_MCSPI_SYSCONFIG 0x10
@@ -49,6 +51,7 @@
 #define OMAP2_MCSPI_WAKEUPENABLE 0x20
 #define OMAP2_MCSPI_SYST 0x24
 #define OMAP2_MCSPI_MODULCTRL 0x28
+#define OMAP2_MCSPI_XFERLEVEL 0x7c

 /* per-channel banks, 0x14 bytes each, first is: */
 #define OMAP2_MCSPI_CHCONF0 0x2c
@@ -85,6 +88,9 @@
 #define OMAP2_MCSPI_CHCONF_IS BIT(18)
 #define OMAP2_MCSPI_CHCONF_TURBO BIT(19)
 #define OMAP2_MCSPI_CHCONF_FORCE BIT(20)
+#define OMAP2_MCSPI_CHCONF_FFER BIT(28)
+#define OMAP2_MCSPI_CHCONF_FFET BIT(27)
+

 #define OMAP2_MCSPI_CHSTAT_RXS BIT(0)
 #define OMAP2_MCSPI_CHSTAT_TXS BIT(1)
@@ -93,6 +99,7 @@


Please swap BIT(27) to be before BIT(28) to keep them sorted above.




 #define OMAP2_MCSPI_CHCTRL_EN BIT(0)

 #define OMAP2_MCSPI_WAKEUPENABLE_WKEN BIT(0)
+#define OMAP2_MCSPI_IRQ_EOW BIT(17)

 /* We have 2 DMA channels per CS, one for RX and one for TX */
 struct omap2_mcspi_dma {
@@ -125,6 +132,10 @@
 unsigned long phys;
 /* SPI1 has 4 channels, while SPI2 has 2 */
 struct omap2_mcspi_dma *dma_

Re: [PATCH 1/2] McSPI Slave and DMA,FIFO support

[Hemanth V]

- Original Message - 
From: "Tony Lindgren" 

To: "Hemanth V" 
Cc: 
Sent: Tuesday, June 02, 2009 11:36 PM
Subject: Re: [PATCH 1/2] McSPI Slave and DMA,FIFO support



Hi,

Sorry for the delay in replying, few comments below.

* Hemanth V  [090519 22:57]:

This patch adds support for McSPI slave and FIFO. DMA and FIFO
could be enabled together for better throughput. Platform config
parameters have been added to enable these features on any particular
McSPI controller.

FIFO can be enabled by defining fifo_depth parameter. fifo_depth needs
to be a multiple of buffer size that is used for read/write.

These features are useful when you have high throughput devices
like WLAN or Modem connected over SPI.

Signed-off-by: Hemanth V 
 arch/arm/mach-omap2/devices.c   |5
 arch/arm/plat-omap/include/mach/mcspi.h |   16 +
 drivers/spi/omap2_mcspi.c   |  343 


 3 files changed, 325 insertions(+), 39 deletions(-)


As this is mostly drivers/spi/omap2_mcspi.c, this patch should get
merged via:

$ grep -A7 "SPI SUBSYSTEM" MAINTAINERS
SPI SUBSYSTEM
P:  David Brownell
M:  dbrown...@users.sourceforge.net
L:  spi-devel-gene...@lists.sourceforge.net
S:  Maintained
F:  Documentation/spi/
F:  drivers/spi/
F:  include/linux/spi/

Please keep linux-omap list Cc'd too so everybody can follow
the progress.


Tony, is this list active. The archives seem to be flooded with spam
mails

http://sourceforge.net/mailarchive/forum.php?forum_name=spi-devel-general





---
Index: linux-omap-2.6/arch/arm/mach-omap2/devices.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/devices.c 2009-05-19
17:00:21.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/devices.c 2009-05-20 
11:02:41.0

+0530
@@ -259,6 +259,7 @@

 static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
 .num_cs = 4,
+ .force_cs_mode = 1,
 };

 static struct resource omap2_mcspi1_resources[] = {
@@ -281,6 +282,10 @@

 static struct omap2_mcspi_platform_config omap2_mcspi2_config = {
 .num_cs = 2,
+ .mode = OMAP2_MCSPI_MASTER,
+ .dma_mode = 1,
+ .force_cs_mode = 0,
+ .fifo_depth = 0,
 };

 static struct resource omap2_mcspi2_resources[] = {
Index: linux-omap-2.6/arch/arm/plat-omap/include/mach/mcspi.h
===
--- linux-omap-2.6.orig/arch/arm/plat-omap/include/mach/mcspi.h 
2009-05-19

17:00:21.0 +0530
+++ linux-omap-2.6/arch/arm/plat-omap/include/mach/mcspi.h 2009-05-20
11:02:41.0 +0530
@@ -1,8 +1,24 @@
 #ifndef _OMAP2_MCSPI_H
 #define _OMAP2_MCSPI_H

+#define OMAP2_MCSPI_MASTER 0
+#define OMAP2_MCSPI_SLAVE 1
+
 struct omap2_mcspi_platform_config {
 unsigned short num_cs;
+
+ /* SPI is master or slave */
+ unsigned short mode;
+
+ /* Use only DMA for data transfers */
+ unsigned short dma_mode;
+
+ /* Force chip select mode */
+ unsigned short force_cs_mode;
+
+ /* FIFO depth in bytes, max value 64 */
+ unsigned short fifo_depth;
+
 };

 struct omap2_mcspi_device_config {
Index: linux-omap-2.6/drivers/spi/omap2_mcspi.c
===
--- linux-omap-2.6.orig/drivers/spi/omap2_mcspi.c 2009-05-19 
17:00:21.0

+0530
+++ linux-omap-2.6/drivers/spi/omap2_mcspi.c 2009-05-20 
11:02:41.0 +0530

@@ -37,9 +37,11 @@

 #include 
 #include 
+#include 


 #define OMAP2_MCSPI_MAX_FREQ 4800
+#define OMAP2_MCSPI_MAX_FIFODEPTH 64

 #define OMAP2_MCSPI_REVISION 0x00
 #define OMAP2_MCSPI_SYSCONFIG 0x10
@@ -49,6 +51,7 @@
 #define OMAP2_MCSPI_WAKEUPENABLE 0x20
 #define OMAP2_MCSPI_SYST 0x24
 #define OMAP2_MCSPI_MODULCTRL 0x28
+#define OMAP2_MCSPI_XFERLEVEL 0x7c

 /* per-channel banks, 0x14 bytes each, first is: */
 #define OMAP2_MCSPI_CHCONF0 0x2c
@@ -85,6 +88,9 @@
 #define OMAP2_MCSPI_CHCONF_IS BIT(18)
 #define OMAP2_MCSPI_CHCONF_TURBO BIT(19)
 #define OMAP2_MCSPI_CHCONF_FORCE BIT(20)
+#define OMAP2_MCSPI_CHCONF_FFER BIT(28)
+#define OMAP2_MCSPI_CHCONF_FFET BIT(27)
+

 #define OMAP2_MCSPI_CHSTAT_RXS BIT(0)
 #define OMAP2_MCSPI_CHSTAT_TXS BIT(1)
@@ -93,6 +99,7 @@


Please swap BIT(27) to be before BIT(28) to keep them sorted above.




 #define OMAP2_MCSPI_CHCTRL_EN BIT(0)

 #define OMAP2_MCSPI_WAKEUPENABLE_WKEN BIT(0)
+#define OMAP2_MCSPI_IRQ_EOW BIT(17)

 /* We have 2 DMA channels per CS, one for RX and one for TX */
 struct omap2_mcspi_dma {
@@ -125,6 +132,10 @@
 unsigned long phys;
 /* SPI1 has 4 channels, while SPI2 has 2 */
 struct omap2_mcspi_dma *dma_channels;
+ unsigned short mcspi_mode;
+ unsigned short dma_mode;
+ unsigned short force_cs_mode;
+ unsigned short fifo_depth;
 };

 struct omap2_mcspi_cs {
@@ -133,6 +144,37 @@
 int word_len;
 };

+#ifdef CONFIG_SPI_DEBUG
+struct reg_type {
+ char name[40];
+ int offset;
+};
+
+static struct reg_type reg_map[] = {
+ {"MCSPI_REV", 0x0},
+ {"MCSPI_SYSCONFIG", 0x10},

Re: Performance testing and identifying performance bottlenecks

[Hemanth V]

Would oprofile help

http://oprofile.sourceforge.net/news/

Hemanth
- Original Message - 
From: "Elvis Dowson" 
To: "Linux OMAP Users" ; "Tomi Valkeinen" 


Sent: Thursday, May 28, 2009 7:30 PM
Subject: Performance testing and identifying performance bottlenecks



Hi,
How can I profile and do some performance tests on the linux-omap  kernel 
sources, and identify the 10 slowest methods for a specific  subsystem, 
say DSS2?


I used to use IBM Rational Test-Real-Time before, to do these kinds of 
tests for embedded software, but don't have access to these expensive 
tools now, so I was wondering if some good open-source alternatives 
exists for doing this.


Best regards,

Elvis


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




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

Re: [PATCH 1/2] McSPI Slave and DMA,FIFO support

[Hemanth V]

Tony, Any update on this patch.

Thanks
Hemanth

> This patch adds support for McSPI slave and FIFO. DMA and FIFO
> could be enabled together for better throughput. Platform config
> parameters have been added to enable these features on any particular
> McSPI controller.
>
> FIFO can be enabled by defining fifo_depth parameter. fifo_depth needs
> to be a multiple of buffer size that is used for read/write.
>
> These features are useful when you have high throughput devices
> like WLAN or Modem connected over SPI.
>
> Signed-off-by: Hemanth V 
>  arch/arm/mach-omap2/devices.c   |5
>  arch/arm/plat-omap/include/mach/mcspi.h |   16 +
>  drivers/spi/omap2_mcspi.c   |  343
> 
>  3 files changed, 325 insertions(+), 39 deletions(-)
>
> ---
> Index: linux-omap-2.6/arch/arm/mach-omap2/devices.c
> ===
> --- linux-omap-2.6.orig/arch/arm/mach-omap2/devices.c 2009-05-19
> 17:00:21.0 +0530
> +++ linux-omap-2.6/arch/arm/mach-omap2/devices.c  2009-05-20 
> 11:02:41.0
> +0530
> @@ -259,6 +259,7 @@
>
>  static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
>   .num_cs = 4,
> + .force_cs_mode  = 1,
>  };
>
>  static struct resource omap2_mcspi1_resources[] = {
> @@ -281,6 +282,10 @@
>
>  static struct omap2_mcspi_platform_config omap2_mcspi2_config = {
>   .num_cs = 2,
> + .mode   = OMAP2_MCSPI_MASTER,
> + .dma_mode   = 1,
> + .force_cs_mode  = 0,
> + .fifo_depth = 0,
>  };
>
>  static struct resource omap2_mcspi2_resources[] = {
> Index: linux-omap-2.6/arch/arm/plat-omap/include/mach/mcspi.h
> ===
> --- linux-omap-2.6.orig/arch/arm/plat-omap/include/mach/mcspi.h   
> 2009-05-19
> 17:00:21.0 +0530
> +++ linux-omap-2.6/arch/arm/plat-omap/include/mach/mcspi.h2009-05-20
> 11:02:41.0 +0530
> @@ -1,8 +1,24 @@
>  #ifndef _OMAP2_MCSPI_H
>  #define _OMAP2_MCSPI_H
>
> +#define OMAP2_MCSPI_MASTER   0
> +#define OMAP2_MCSPI_SLAVE1
> +
>  struct omap2_mcspi_platform_config {
>   unsigned short  num_cs;
> +
> + /* SPI is master or slave */
> + unsigned short  mode;
> +
> + /* Use only DMA for data transfers */
> + unsigned short  dma_mode;
> +
> + /* Force chip select mode */
> + unsigned short  force_cs_mode;
> +
> + /* FIFO depth in bytes, max value 64 */
> + unsigned short fifo_depth;
> +
>  };
>
>  struct omap2_mcspi_device_config {
> Index: linux-omap-2.6/drivers/spi/omap2_mcspi.c
> ===
> --- linux-omap-2.6.orig/drivers/spi/omap2_mcspi.c 2009-05-19 
> 17:00:21.0
> +0530
> +++ linux-omap-2.6/drivers/spi/omap2_mcspi.c  2009-05-20 11:02:41.0
> +0530
> @@ -37,9 +37,11 @@
>
>  #include 
>  #include 
> +#include 
>
>
>  #define OMAP2_MCSPI_MAX_FREQ 4800
> +#define OMAP2_MCSPI_MAX_FIFODEPTH64
>
>  #define OMAP2_MCSPI_REVISION 0x00
>  #define OMAP2_MCSPI_SYSCONFIG0x10
> @@ -49,6 +51,7 @@
>  #define OMAP2_MCSPI_WAKEUPENABLE 0x20
>  #define OMAP2_MCSPI_SYST 0x24
>  #define OMAP2_MCSPI_MODULCTRL0x28
> +#define OMAP2_MCSPI_XFERLEVEL0x7c
>
>  /* per-channel banks, 0x14 bytes each, first is: */
>  #define OMAP2_MCSPI_CHCONF0  0x2c
> @@ -85,6 +88,9 @@
>  #define OMAP2_MCSPI_CHCONF_ISBIT(18)
>  #define OMAP2_MCSPI_CHCONF_TURBO BIT(19)
>  #define OMAP2_MCSPI_CHCONF_FORCE BIT(20)
> +#define OMAP2_MCSPI_CHCONF_FFER  BIT(28)
> +#define OMAP2_MCSPI_CHCONF_FFET  BIT(27)
> +
>
>  #define OMAP2_MCSPI_CHSTAT_RXS   BIT(0)
>  #define OMAP2_MCSPI_CHSTAT_TXS   BIT(1)
> @@ -93,6 +99,7 @@
>  #define OMAP2_MCSPI_CHCTRL_ENBIT(0)
>
>  #define OMAP2_MCSPI_WAKEUPENABLE_WKENBIT(0)
> +#define OMAP2_MCSPI_IRQ_EOW  BIT(17)
>
>  /* We have 2 DMA channels per CS, one for RX and one for TX */
>  struct omap2_mcspi_dma {
> @@ -125,6 +132,10 @@
>   unsigned long   phys;
>   /* SPI1 has 4 channels, while SPI2 has 2 */
>   struct omap2_mcspi_dma  *dma_channels;
> + unsigned short  mcspi_mode;
> + unsigned short  dma_mode;
> + unsigned short  force_cs_mode;
> + unsigned short  fifo_depth;
>  };
>
>  struct omap2_mcspi_cs {
> @@ -133,6 +144,37 @@
>   int word_len;
>  };
>

Re: [PATCH][RFC] OMAP4: GPIO Support for OMAP_4430SDP

[Hemanth V]

- Original Message - 
From: "Syed Rafiuddin" 

To: 
Sent: Saturday, May 23, 2009 5:41 PM
Subject: [PATCH][RFC] OMAP4: GPIO Support for OMAP_4430SDP



This patch updates register and offset address with respect to OMAP4.

Signed-off-by: 
---
arch/arm/plat-omap/gpio.c |  133 
+++---

1 files changed, 102 insertions(+), 31 deletions(-)

Index: linux-2.6/arch/arm/plat-omap/gpio.c
===
--- linux-2.6.orig/arch/arm/plat-omap/gpio.c 2009-05-18 14:24:54.0 
+0530
+++ linux-2.6/arch/arm/plat-omap/gpio.c 2009-05-18 15:36:35.0 
+0530

@@ -113,30 +113,70 @@
#define OMAP243X_GPIO4_BASE IO_ADDRESS(0x49012000)
#define OMAP243X_GPIO5_BASE IO_ADDRESS(0x480B6000)

+
#define OMAP24XX_GPIO_REVISION 0x
#define OMAP24XX_GPIO_SYSCONFIG 0x0010
-#define OMAP24XX_GPIO_SYSSTATUS 0x0014
-#define OMAP24XX_GPIO_IRQSTATUS1 0x0018
-#define OMAP24XX_GPIO_IRQSTATUS2 0x0028
-#define OMAP24XX_GPIO_IRQENABLE2 0x002c
-#define OMAP24XX_GPIO_IRQENABLE1 0x001c
-#define OMAP24XX_GPIO_WAKE_EN 0x0020
-#define OMAP24XX_GPIO_CTRL 0x0030
-#define OMAP24XX_GPIO_OE 0x0034
-#define OMAP24XX_GPIO_DATAIN 0x0038
-#define OMAP24XX_GPIO_DATAOUT 0x003c
-#define OMAP24XX_GPIO_LEVELDETECT0 0x0040
-#define OMAP24XX_GPIO_LEVELDETECT1 0x0044
-#define OMAP24XX_GPIO_RISINGDETECT 0x0048
-#define OMAP24XX_GPIO_FALLINGDETECT 0x004c
-#define OMAP24XX_GPIO_DEBOUNCE_EN 0x0050
-#define OMAP24XX_GPIO_DEBOUNCE_VAL 0x0054
-#define OMAP24XX_GPIO_CLEARIRQENABLE1 0x0060
-#define OMAP24XX_GPIO_SETIRQENABLE1 0x0064
-#define OMAP24XX_GPIO_CLEARWKUENA 0x0080
-#define OMAP24XX_GPIO_SETWKUENA 0x0084
-#define OMAP24XX_GPIO_CLEARDATAOUT 0x0090
-#define OMAP24XX_GPIO_SETDATAOUT 0x0094
+
+
+#ifdef CONFIG_ARCH_OMAP4
+#define OMAP24XX_GPIO_SYSSTATUS 0x0114
+#define OMAP24XX_GPIO_IRQSTATUS1 0x0118
+#define OMAP24XX_GPIO_IRQSTATUS2 0x0128


Could you explain difference between OMAP24XX_GPIO_IRQSTATUS1
and OMAP24XX_GPIO_IRQ_STATUS_1 i.e why are two
sets of registers required and similarly for other registers too.



+#define OMAP24XX_GPIO_IRQENABLE2 0x012c
+#define OMAP24XX_GPIO_IRQENABLE1 0x011c
+#define OMAP24XX_GPIO_WAKE_EN 0x0120
+#define OMAP24XX_GPIO_CTRL 0x0130
+#define OMAP24XX_GPIO_OE 0x0134
+#define OMAP24XX_GPIO_DATAIN 0x0138
+#define OMAP24XX_GPIO_DATAOUT 0x013c
+#define OMAP24XX_GPIO_LEVELDETECT0 0x0140
+#define OMAP24XX_GPIO_LEVELDETECT1 0x0144
+#define OMAP24XX_GPIO_RISINGDETECT 0x0148
+#define OMAP24XX_GPIO_FALLINGDETECT 0x014c
+#define OMAP24XX_GPIO_DEBOUNCE_EN 0x0150
+#define OMAP24XX_GPIO_DEBOUNCE_VAL 0x0154
+#define OMAP24XX_GPIO_CLEARIRQENABLE1 0x0160
+#define OMAP24XX_GPIO_SETIRQENABLE1 0x0164
+#define OMAP24XX_GPIO_CLEARWKUENA 0x0180
+#define OMAP24XX_GPIO_SETWKUENA 0x0184
+#define OMAP24XX_GPIO_CLEARDATAOUT 0x0190
+#define OMAP24XX_GPIO_SETDATAOUT 0x0194
+#define OMAP24XX_GPIO_STATUS_RAW_0 0x0024
+#define OMAP24XX_GPIO_STATUS_RAW_1 0x0028
+#define OMAP24XX_GPIO_IRQ_STATUS_0 0x002C
+#define OMAP24XX_GPIO_IRQ_STATUS_1 0x0030
+#define OMAP24XX_GPIO_IRQ_STATUS_SET_0 0x0034
+#define OMAP24XX_GPIO_IRQ_STATUS_SET_1 0x0038
+#define OMAP24XX_GPIO_IRQ_STATUS_CLR_0 0x003C
+#define OMAP24XX_GPIO_IRQ_STATUS_CLR_1 0x0040
+#define OMAP24XX_GPIO_IRQ_WAKE_ENABLE_0 0x0044
+#define OMAP24XX_GPIO_IRQ_WAKE_ENABLE_1 0x0048
+
+#else
+#define OMAP24XX_GPIO_SYSSTATUS 0x0014
+#define OMAP24XX_GPIO_IRQSTATUS10x0018
+#define OMAP24XX_GPIO_IRQSTATUS20x0028
+#define OMAP24XX_GPIO_IRQENABLE20x002c
+#define OMAP24XX_GPIO_IRQENABLE10x001c
+#define OMAP24XX_GPIO_WAKE_EN   0x0020
+#define OMAP24XX_GPIO_CTRL  0x0030
+#define OMAP24XX_GPIO_OE0x0034
+#define OMAP24XX_GPIO_DATAIN0x0038
+#define OMAP24XX_GPIO_DATAOUT   0x003c
+#define OMAP24XX_GPIO_LEVELDETECT0  0x0040
+#define OMAP24XX_GPIO_LEVELDETECT1  0x0044
+#define OMAP24XX_GPIO_RISINGDETECT  0x0048
+#define OMAP24XX_GPIO_FALLINGDETECT 0x004c
+#define OMAP24XX_GPIO_DEBOUNCE_EN   0x0050
+#define OMAP24XX_GPIO_DEBOUNCE_VAL  0x0054
+#define OMAP24XX_GPIO_CLEARIRQENABLE1   0x0060
+#define OMAP24XX_GPIO_SETIRQENABLE1 0x0064
+#define OMAP24XX_GPIO_CLEARWKUENA   0x0080
+#define OMAP24XX_GPIO_SETWKUENA 0x0084
+#define OMAP24XX_GPIO_CLEARDATAOUT  0x0090
+#define OMAP24XX_GPIO_SETDATAOUT0x0094
+
+#endif

/*
 * omap34xx specific GPIO registers
@@ -783,12 +823,16 @@
 reg += OMAP850_GPIO_INT_STATUS;
 break;
#endif
-#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX) || \
- defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
 case METHOD_GPIO_24XX:
 reg += OMAP24XX_GPIO_IRQSTATUS1;
 break;
#endif
+#if defined(CONFIG_ARCH_OMAP4)
+ case METHOD_GPIO_24XX:
+ reg += OMAP24XX_GPIO_IRQ_STATUS_0;
+ break;
+#endif
 default:
 WARN_ON(1);
 return;
@@ -804,6 +848,15 @@
 /* Flush posted write for the irq status to avoid spurious interrupts */
 __raw_re

Re: [PATCH 2/2] McSPI Slave and DMA,FIFO support

[Hemanth V]

Tony, would you be able merge the two patches if I removed omap_cfg_reg 
calls


Thanks
Hemnath
- Original Message - 
From: "Hemanth V" 
To: "Gadiyar, Anand" ; "Kevin Hilman" 
; "Tony Lindgren" 

Cc: 
Sent: Thursday, May 21, 2009 3:09 PM
Subject: Re: [PATCH 2/2] McSPI Slave and DMA,FIFO support


- Original Message - 
From: "Kevin Hilman" 

To: "Gadiyar, Anand" 
Cc: "V, Hemanth" ; 
Sent: Wednesday, May 20, 2009 10:33 PM
Subject: Re: [PATCH 2/2] McSPI Slave and DMA,FIFO support



"Gadiyar, Anand"  writes:


-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hemanth V
Sent: Wednesday, May 20, 2009 11:27 AM
To: linux-omap@vger.kernel.org
Subject: [PATCH 2/2] McSPI Slave and DMA,FIFO support

This patch adds MUX changes for SPI2 and also adds an
option for test driver

Signed-off-by: Hemanth V 
---
 arch/arm/mach-omap2/board-3430sdp.c   |   26 
++

 arch/arm/mach-omap2/mux.c |   11 +++
 arch/arm/plat-omap/include/mach/mux.h |7 +++
 3 files changed, 44 insertions(+)

Index: linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/board-3430sdp.c 2009-05-20 
11:02:34.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c 2009-05-20 
11:05:22.0 +0530

@@ -228,6 +228,13 @@
 .single_channel = 1, /* 0: slave, 1: master */
 };

+#ifdef CONFIG_SPI_DEBUG
+static struct omap2_mcspi_device_config dummy_mcspi_config = {
+ .turbo_mode = 0,
+ .single_channel = 1,  /* 0: slave, 1: master */
+};
+#endif
+
 static struct spi_board_info sdp3430_spi_board_info[] __initdata = {
 [0] = {
 /*
@@ -242,6 +249,18 @@
 .irq = 0,
 .platform_data = &tsc2046_config,
 },
+#ifdef CONFIG_SPI_DEBUG
+ [1] = {
+ /* SPI test driver attached to SPI2 controller by
+ * default
+ */
+ .modalias = "spitst",
+ .bus_num = 2,
+ .chip_select = 0,
+ .max_speed_hz = 150,
+ .controller_data = &dummy_mcspi_config,
+ },
+#endif
 };

 static struct platform_device sdp3430_lcd_device = {
@@ -666,6 +685,13 @@

 static void __init omap_3430sdp_init(void)
 {
+
+ /* SPI2 Pin MUX */
+ omap_cfg_reg(AA3_3430_McSPI2_CLK);
+ omap_cfg_reg(Y2_3430_McSPI2_SIMO);
+ omap_cfg_reg(Y3_3430_McSPI2_SOMI);
+ omap_cfg_reg(Y4_3430_McSPI2_CS0);
+


This will still change the padconf for this port unconditionally.

How do we handle the case where the same platform (SDP in this case)
could have different configurations McSPI2 vs USBHOST2, etc? Is there
a clean way, or do we have no option but to use a CONFIG option?


What about building both as modules and doing the muxing on module
load with a warning if it's taking the pins away from antother
feature.

Longer term, we need a more dynamic way to request pins when there are
conflicts like this.

Kevin


Might be the easiest option right now is to remove omap_cfg_reg calls and 
allow

users to add it when required.

Hemanth






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




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

Re: [PATCH 2/2] McSPI Slave and DMA,FIFO support

[Hemanth V]

- Original Message - 
From: "Kevin Hilman" 

To: "Gadiyar, Anand" 
Cc: "V, Hemanth" ; 
Sent: Wednesday, May 20, 2009 10:33 PM
Subject: Re: [PATCH 2/2] McSPI Slave and DMA,FIFO support



"Gadiyar, Anand"  writes:


-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hemanth V
Sent: Wednesday, May 20, 2009 11:27 AM
To: linux-omap@vger.kernel.org
Subject: [PATCH 2/2] McSPI Slave and DMA,FIFO support

This patch adds MUX changes for SPI2 and also adds an
option for test driver

Signed-off-by: Hemanth V 
---
 arch/arm/mach-omap2/board-3430sdp.c   |   26 ++
 arch/arm/mach-omap2/mux.c |   11 +++
 arch/arm/plat-omap/include/mach/mux.h |7 +++
 3 files changed, 44 insertions(+)

Index: linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/board-3430sdp.c 2009-05-20 
11:02:34.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c 2009-05-20 
11:05:22.0 +0530

@@ -228,6 +228,13 @@
 .single_channel = 1, /* 0: slave, 1: master */
 };

+#ifdef CONFIG_SPI_DEBUG
+static struct omap2_mcspi_device_config dummy_mcspi_config = {
+ .turbo_mode = 0,
+ .single_channel = 1,  /* 0: slave, 1: master */
+};
+#endif
+
 static struct spi_board_info sdp3430_spi_board_info[] __initdata = {
 [0] = {
 /*
@@ -242,6 +249,18 @@
 .irq = 0,
 .platform_data = &tsc2046_config,
 },
+#ifdef CONFIG_SPI_DEBUG
+ [1] = {
+ /* SPI test driver attached to SPI2 controller by
+ * default
+ */
+ .modalias = "spitst",
+ .bus_num = 2,
+ .chip_select = 0,
+ .max_speed_hz = 150,
+ .controller_data = &dummy_mcspi_config,
+ },
+#endif
 };

 static struct platform_device sdp3430_lcd_device = {
@@ -666,6 +685,13 @@

 static void __init omap_3430sdp_init(void)
 {
+
+ /* SPI2 Pin MUX */
+ omap_cfg_reg(AA3_3430_McSPI2_CLK);
+ omap_cfg_reg(Y2_3430_McSPI2_SIMO);
+ omap_cfg_reg(Y3_3430_McSPI2_SOMI);
+ omap_cfg_reg(Y4_3430_McSPI2_CS0);
+


This will still change the padconf for this port unconditionally.

How do we handle the case where the same platform (SDP in this case)
could have different configurations McSPI2 vs USBHOST2, etc? Is there
a clean way, or do we have no option but to use a CONFIG option?


What about building both as modules and doing the muxing on module
load with a warning if it's taking the pins away from antother
feature.

Longer term, we need a more dynamic way to request pins when there are
conflicts like this.

Kevin


Might be the easiest option right now is to remove omap_cfg_reg calls and 
allow

users to add it when required.

Hemanth






--
To unsubscribe from this list: send the line "unsubscribe 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] McSPI Slave and DMA,FIFO support

[Hemanth V]

Santosh,

- Original Message - 
From: "Shilimkar, Santosh" 

To: "V, Hemanth" ; 
Sent: Wednesday, May 20, 2009 11:34 AM
Subject: RE: [PATCH 1/2] McSPI Slave and DMA,FIFO support



Hemanth,


Signed-off-by: Hemanth V 
 arch/arm/mach-omap2/devices.c   |5
 arch/arm/plat-omap/include/mach/mcspi.h |   16 +
 drivers/spi/omap2_mcspi.c   |  343



drivers/spi/omap2_mcspi.c This should be separate patch since 
this has touching drivers directory.


It would break compililation of the patch




--
To unsubscribe from this list: send the line "unsubscribe 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] McSPI Slave and DMA,FIFO support

[Hemanth V]

This patch adds MUX changes for SPI2 and also adds an
option for test driver

Signed-off-by: Hemanth V 
---
 arch/arm/mach-omap2/board-3430sdp.c   |   26 ++
 arch/arm/mach-omap2/mux.c |   11 +++
 arch/arm/plat-omap/include/mach/mux.h |7 +++
 3 files changed, 44 insertions(+)

Index: linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/board-3430sdp.c 2009-05-20
11:02:34.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c  2009-05-20
11:05:22.0 +0530
@@ -228,6 +228,13 @@
.single_channel = 1,/* 0: slave, 1: master */
 };

+#ifdef CONFIG_SPI_DEBUG
+static struct omap2_mcspi_device_config dummy_mcspi_config = {
+   .turbo_mode = 0,
+   .single_channel = 1,  /* 0: slave, 1: master */
+};
+#endif
+
 static struct spi_board_info sdp3430_spi_board_info[] __initdata = {
[0] = {
/*
@@ -242,6 +249,18 @@
.irq= 0,
.platform_data  = &tsc2046_config,
},
+#ifdef CONFIG_SPI_DEBUG
+   [1] = {
+   /* SPI test driver attached to SPI2 controller by
+* default
+*/
+   .modalias   = "spitst",
+   .bus_num= 2,
+   .chip_select= 0,
+   .max_speed_hz   = 150,
+   .controller_data= &dummy_mcspi_config,
+   },
+#endif
 };

 static struct platform_device sdp3430_lcd_device = {
@@ -666,6 +685,13 @@

 static void __init omap_3430sdp_init(void)
 {
+
+   /* SPI2 Pin MUX */
+   omap_cfg_reg(AA3_3430_McSPI2_CLK);
+   omap_cfg_reg(Y2_3430_McSPI2_SIMO);
+   omap_cfg_reg(Y3_3430_McSPI2_SOMI);
+   omap_cfg_reg(Y4_3430_McSPI2_CS0);
+
omap3430_i2c_init();
platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
omap_board_config = sdp3430_config;
Index: linux-omap-2.6/arch/arm/mach-omap2/mux.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/mux.c   2009-05-20 
11:02:34.0
+0530
+++ linux-omap-2.6/arch/arm/mach-omap2/mux.c2009-05-20 11:05:22.0 
+0530
@@ -486,6 +486,17 @@
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
 MUX_CFG_34XX("J25_34XX_GPIO170", 0x1c6,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
+
+/* McSPI */
+MUX_CFG_34XX("AA3_3430_McSPI2_CLK", 0x1d6,
+   OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT)
+MUX_CFG_34XX("Y2_3430_McSPI2_SIMO", 0x1d8,
+   OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT)
+MUX_CFG_34XX("Y3_3430_McSPI2_SOMI", 0x1da,
+   OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT)
+MUX_CFG_34XX("Y4_3430_McSPI2_CS0", 0x1dc,
+   OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
+
 };

 #define OMAP34XX_PINS_SZ   ARRAY_SIZE(omap34xx_pins)
Index: linux-omap-2.6/arch/arm/plat-omap/include/mach/mux.h
===
--- linux-omap-2.6.orig/arch/arm/plat-omap/include/mach/mux.h   2009-05-20
11:02:34.0 +0530
+++ linux-omap-2.6/arch/arm/plat-omap/include/mach/mux.h2009-05-20
11:05:22.0 +0530
@@ -853,6 +853,13 @@
AE5_34XX_GPIO143,
H19_34XX_GPIO164_OUT,
J25_34XX_GPIO170,
+
+   /* McSPI */
+   AA3_3430_McSPI2_CLK,
+   Y2_3430_McSPI2_SIMO,
+   Y3_3430_McSPI2_SOMI,
+   Y4_3430_McSPI2_CS0,
+
 };

 struct omap_mux_cfg {


--
To unsubscribe from this list: send the line "unsubscribe 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] McSPI Slave and DMA,FIFO support

[Hemanth V]

This patch adds support for McSPI slave and FIFO. DMA and FIFO
could be enabled together for better throughput. Platform config
parameters have been added to enable these features on any particular
McSPI controller.

FIFO can be enabled by defining fifo_depth parameter. fifo_depth needs
to be a multiple of buffer size that is used for read/write.

These features are useful when you have high throughput devices
like WLAN or Modem connected over SPI.

Signed-off-by: Hemanth V 
 arch/arm/mach-omap2/devices.c   |5
 arch/arm/plat-omap/include/mach/mcspi.h |   16 +
 drivers/spi/omap2_mcspi.c   |  343 
 3 files changed, 325 insertions(+), 39 deletions(-)

---
Index: linux-omap-2.6/arch/arm/mach-omap2/devices.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/devices.c   2009-05-19
17:00:21.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/devices.c2009-05-20 
11:02:41.0
+0530
@@ -259,6 +259,7 @@

 static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
.num_cs = 4,
+   .force_cs_mode  = 1,
 };

 static struct resource omap2_mcspi1_resources[] = {
@@ -281,6 +282,10 @@

 static struct omap2_mcspi_platform_config omap2_mcspi2_config = {
.num_cs = 2,
+   .mode   = OMAP2_MCSPI_MASTER,
+   .dma_mode   = 1,
+   .force_cs_mode  = 0,
+   .fifo_depth = 0,
 };

 static struct resource omap2_mcspi2_resources[] = {
Index: linux-omap-2.6/arch/arm/plat-omap/include/mach/mcspi.h
===
--- linux-omap-2.6.orig/arch/arm/plat-omap/include/mach/mcspi.h 2009-05-19
17:00:21.0 +0530
+++ linux-omap-2.6/arch/arm/plat-omap/include/mach/mcspi.h  2009-05-20
11:02:41.0 +0530
@@ -1,8 +1,24 @@
 #ifndef _OMAP2_MCSPI_H
 #define _OMAP2_MCSPI_H

+#define OMAP2_MCSPI_MASTER 0
+#define OMAP2_MCSPI_SLAVE  1
+
 struct omap2_mcspi_platform_config {
unsigned short  num_cs;
+
+   /* SPI is master or slave */
+   unsigned short  mode;
+
+   /* Use only DMA for data transfers */
+   unsigned short  dma_mode;
+
+   /* Force chip select mode */
+   unsigned short  force_cs_mode;
+
+   /* FIFO depth in bytes, max value 64 */
+   unsigned short fifo_depth;
+
 };

 struct omap2_mcspi_device_config {
Index: linux-omap-2.6/drivers/spi/omap2_mcspi.c
===
--- linux-omap-2.6.orig/drivers/spi/omap2_mcspi.c   2009-05-19 
17:00:21.0
+0530
+++ linux-omap-2.6/drivers/spi/omap2_mcspi.c2009-05-20 11:02:41.0 
+0530
@@ -37,9 +37,11 @@

 #include 
 #include 
+#include 


 #define OMAP2_MCSPI_MAX_FREQ   4800
+#define OMAP2_MCSPI_MAX_FIFODEPTH  64

 #define OMAP2_MCSPI_REVISION   0x00
 #define OMAP2_MCSPI_SYSCONFIG  0x10
@@ -49,6 +51,7 @@
 #define OMAP2_MCSPI_WAKEUPENABLE   0x20
 #define OMAP2_MCSPI_SYST   0x24
 #define OMAP2_MCSPI_MODULCTRL  0x28
+#define OMAP2_MCSPI_XFERLEVEL  0x7c

 /* per-channel banks, 0x14 bytes each, first is: */
 #define OMAP2_MCSPI_CHCONF00x2c
@@ -85,6 +88,9 @@
 #define OMAP2_MCSPI_CHCONF_IS  BIT(18)
 #define OMAP2_MCSPI_CHCONF_TURBO   BIT(19)
 #define OMAP2_MCSPI_CHCONF_FORCE   BIT(20)
+#define OMAP2_MCSPI_CHCONF_FFERBIT(28)
+#define OMAP2_MCSPI_CHCONF_FFETBIT(27)
+

 #define OMAP2_MCSPI_CHSTAT_RXS BIT(0)
 #define OMAP2_MCSPI_CHSTAT_TXS BIT(1)
@@ -93,6 +99,7 @@
 #define OMAP2_MCSPI_CHCTRL_EN  BIT(0)

 #define OMAP2_MCSPI_WAKEUPENABLE_WKEN  BIT(0)
+#define OMAP2_MCSPI_IRQ_EOWBIT(17)

 /* We have 2 DMA channels per CS, one for RX and one for TX */
 struct omap2_mcspi_dma {
@@ -125,6 +132,10 @@
unsigned long   phys;
/* SPI1 has 4 channels, while SPI2 has 2 */
struct omap2_mcspi_dma  *dma_channels;
+   unsigned short  mcspi_mode;
+   unsigned short  dma_mode;
+   unsigned short  force_cs_mode;
+   unsigned short  fifo_depth;
 };

 struct omap2_mcspi_cs {
@@ -133,6 +144,37 @@
int word_len;
 };

+#ifdef CONFIG_SPI_DEBUG
+struct reg_type {
+   char name[40];
+   int offset;
+};
+
+static struct reg_type reg_map[] = {
+   {"MCSPI_REV", 0x0},
+   {"MCSPI_SYSCONFIG", 0x10},
+   {"MCSPI_SYSSTATUS", 0x14},
+   {"MCSPI_IRQSTATUS", 0x18},
+   {"MCSPI_IRQENABLE", 0x1C},
+   {"MCSPI_WAKEUPENABLE", 0x20},
+   {"MCSPI_SYST", 0x24},
+   {"MCSPI_MODULCTRL", 0x28},
+   {"MCSPI_XFERLEVEL", 0x7c},
+   {"CH0", 0x2C},
+   {"CH1", 0x40},
+   {"CH2", 0x54},
+   {"CH3", 0x68}
+};
+
+static struct reg