from:"AnilKumar, Chimata"

On Sat, Oct 20, 2012 at 04:30:59, Dmitry Torokhov wrote:
> On Fri, Oct 19, 2012 at 12:36:12PM +0530, AnilKumar Ch wrote:
> > Remove const from pointer to array of gpios in matrix_keypad_platform_data
> > struct. This is required if we update row_gpios and col_gpios based on
> > device tree data.
> 
> Then don't. Set them up via non-const aliases instead.
> 

Changed.

Thanks
AnilKumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 2/2] Input: matrix-keypad - Add device tree support

Hi Rob,

Thanks for the comments.

On Fri, Oct 19, 2012 at 18:27:21, Rob Herring wrote:
> On 10/19/2012 02:06 AM, AnilKumar Ch wrote:
> > Add device tree support to matrix keypad driver and usage details
> > are added to device tree documentation. Driver was tested on AM335x
> > EVM.
> > 
> > Signed-off-by: AnilKumar Ch 
> > ---
> >  .../devicetree/bindings/input/matrix-keypad.txt|   52 ++
> >  drivers/input/keyboard/matrix_keypad.c |  104 
> > +++-
> >  2 files changed, 155 insertions(+), 1 deletion(-)
> >  create mode 100644 
> > Documentation/devicetree/bindings/input/matrix-keypad.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/input/matrix-keypad.txt 
> > b/Documentation/devicetree/bindings/input/matrix-keypad.txt
> > new file mode 100644
> > index 000..50aaa6e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/matrix-keypad.txt
> > @@ -0,0 +1,52 @@
> > +* GPIO driven matrix keypad device tree bindings
> > +
> > +GPIO driven matrix keypad is used to interface a SoC with a matrix keypad.
> > +The matrix keypad supports multiple row and column lines, a key can be
> > +placed at each intersection of a unique row and a unique column. The matrix
> > +keypad can sense a key-press and key-release by means of GPIO lines and
> > +report the event using GPIO interrupts to the cpu.
> > +
> > +Required Properties:
> > +- compatible:  Should be "matix-keypad"
> 
> How about gpio-matrix-keypad?

More meaningful, changed

> 
> > +- keypad,num-row-gpios:Number of row lines connected to the keypad
> > +   controller.
> > +- keypad,num-col-gpios:Number of column lines connected to the keypad
> > +   controller.
> 
> Isn't the number of gpios just the count of gpios listed below? So you
> don't need these props.

Removed

> 
> > +- row-gpios:   List of gpios used as row lines. The gpio 
> > specifier
> > +   for this property depends on the gpio controller to
> > +   which these row lines are connected.
> > +- col-gpios:   List of gpios used as column lines. The gpio 
> > specifier
> > +   for this property depends on the gpio controller to
> > +   which these column lines are connected.
> > +
> > +Optional Properties:
> > +- linux,no-autorepeat: do no enable autorepeat feature.
> > +- linux,wakeup:use any event on keypad as wakeup event.
> > +- debounce-delay-ms:   debounce interval in milliseconds
> > +- col-scan-delay-us:   delay, measured in microseconds, that is needed
> > +   before we can scan keypad after activating column gpio
> > +- clustered-irq:   have clustered irq number
> > +- clustered-irq-flags: have clustered irq flags
> 
> It's not clear what clustered means here. If I have to go read Linux
> code to understand, you are doing it wrong. Describe the h/w, not Linux
> data structs.

I have added based on pdata of the driver, I am not using these
parameters because AM335x-EVM have different interrupts for all
gpio pins.

clustered-irq: combined irq source for the whole matrix keypad,
like all gpio keys are connected to a gpio expander

> 
> > +
> > +Example:
> > +   matrix-keypad {
> > +   compatible = "matrix-keypad";
> > +   keypad,num-row-gpios = <3>;
> > +   keypad,num-col-gpios = <2>;
> > +   debounce-delay-ms = <5>;
> > +   col-scan-delay-us = <2>;
> > +
> > +   row-gpios = < 25 0
> > + 26 0
> > + 27 0>;
> > +
> > +   col-gpios = < 21 0
> > + 22 0>;
> > +
> > +   linux,keymap = <0x008B
> > +   0x019E
> > +   0x0269
> > +   0x0001006A
> > +   0x0101001C
> > +   0x0201006C>;
> > +   };
> > diff --git a/drivers/input/keyboard/matrix_keypad.c 
> > b/drivers/input/keyboard/matrix_keypad.c
> > index 18b7237..39e480d 100644
> > --- a/drivers/input/keyboard/matrix_keypad.c
> > +++ b/drivers/input/keyboard/matrix_keypad.c
> > @@ -23,6 +23,9 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> >  
> >  struct matrix_keypad {
> > const struct matrix_keypad_platform_data *pdata;
> > @@ -394,6 +397,91 @@ static void matrix_keypad_free_gpio(struct 
> > matrix_keypad *keypad)
> > gpio_free(pdata->col_gpios[i]);
> >  }
> >  
> > +#ifdef CONFIG_OF
> > +static
> > +struct matrix_keypad_platform_data *matrix_keypad_parse_dt(struct device 
> > *dev)
> > +{
> > +   struct matrix_keypad_platform_data *pdata;
> > +   struct matrix_keymap_data *keymap_data;
> > +   struct device_node *np = dev->of_node;
> > +   struct property *prop;
> > +   int key_count = 0, length, row, col;
> > +   uint32_t *keymap;
> > +
> > +   pdata = devm_kzalloc(dev,

RE: [PATCH 2/2] Input: matrix-keypad - Add device tree support

Hi Rob,

Thanks for the comments.

On Fri, Oct 19, 2012 at 18:27:21, Rob Herring wrote:
 On 10/19/2012 02:06 AM, AnilKumar Ch wrote:
  Add device tree support to matrix keypad driver and usage details
  are added to device tree documentation. Driver was tested on AM335x
  EVM.
  
  Signed-off-by: AnilKumar Ch anilku...@ti.com
  ---
   .../devicetree/bindings/input/matrix-keypad.txt|   52 ++
   drivers/input/keyboard/matrix_keypad.c |  104 
  +++-
   2 files changed, 155 insertions(+), 1 deletion(-)
   create mode 100644 
  Documentation/devicetree/bindings/input/matrix-keypad.txt
  
  diff --git a/Documentation/devicetree/bindings/input/matrix-keypad.txt 
  b/Documentation/devicetree/bindings/input/matrix-keypad.txt
  new file mode 100644
  index 000..50aaa6e
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/input/matrix-keypad.txt
  @@ -0,0 +1,52 @@
  +* GPIO driven matrix keypad device tree bindings
  +
  +GPIO driven matrix keypad is used to interface a SoC with a matrix keypad.
  +The matrix keypad supports multiple row and column lines, a key can be
  +placed at each intersection of a unique row and a unique column. The matrix
  +keypad can sense a key-press and key-release by means of GPIO lines and
  +report the event using GPIO interrupts to the cpu.
  +
  +Required Properties:
  +- compatible:  Should be matix-keypad
 
 How about gpio-matrix-keypad?

More meaningful, changed

 
  +- keypad,num-row-gpios:Number of row lines connected to the keypad
  +   controller.
  +- keypad,num-col-gpios:Number of column lines connected to the keypad
  +   controller.
 
 Isn't the number of gpios just the count of gpios listed below? So you
 don't need these props.

Removed

 
  +- row-gpios:   List of gpios used as row lines. The gpio 
  specifier
  +   for this property depends on the gpio controller to
  +   which these row lines are connected.
  +- col-gpios:   List of gpios used as column lines. The gpio 
  specifier
  +   for this property depends on the gpio controller to
  +   which these column lines are connected.
  +
  +Optional Properties:
  +- linux,no-autorepeat: do no enable autorepeat feature.
  +- linux,wakeup:use any event on keypad as wakeup event.
  +- debounce-delay-ms:   debounce interval in milliseconds
  +- col-scan-delay-us:   delay, measured in microseconds, that is needed
  +   before we can scan keypad after activating column gpio
  +- clustered-irq:   have clustered irq number
  +- clustered-irq-flags: have clustered irq flags
 
 It's not clear what clustered means here. If I have to go read Linux
 code to understand, you are doing it wrong. Describe the h/w, not Linux
 data structs.

I have added based on pdata of the driver, I am not using these
parameters because AM335x-EVM have different interrupts for all
gpio pins.

clustered-irq: combined irq source for the whole matrix keypad,
like all gpio keys are connected to a gpio expander

 
  +
  +Example:
  +   matrix-keypad {
  +   compatible = matrix-keypad;
  +   keypad,num-row-gpios = 3;
  +   keypad,num-col-gpios = 2;
  +   debounce-delay-ms = 5;
  +   col-scan-delay-us = 2;
  +
  +   row-gpios = gpio2 25 0
  +gpio2 26 0
  +gpio2 27 0;
  +
  +   col-gpios = gpio2 21 0
  +gpio2 22 0;
  +
  +   linux,keymap = 0x008B
  +   0x019E
  +   0x0269
  +   0x0001006A
  +   0x0101001C
  +   0x0201006C;
  +   };
  diff --git a/drivers/input/keyboard/matrix_keypad.c 
  b/drivers/input/keyboard/matrix_keypad.c
  index 18b7237..39e480d 100644
  --- a/drivers/input/keyboard/matrix_keypad.c
  +++ b/drivers/input/keyboard/matrix_keypad.c
  @@ -23,6 +23,9 @@
   #include linux/gpio.h
   #include linux/input/matrix_keypad.h
   #include linux/slab.h
  +#include linux/of.h
  +#include linux/of_gpio.h
  +#include linux/of_platform.h
   
   struct matrix_keypad {
  const struct matrix_keypad_platform_data *pdata;
  @@ -394,6 +397,91 @@ static void matrix_keypad_free_gpio(struct 
  matrix_keypad *keypad)
  gpio_free(pdata-col_gpios[i]);
   }
   
  +#ifdef CONFIG_OF
  +static
  +struct matrix_keypad_platform_data *matrix_keypad_parse_dt(struct device 
  *dev)
  +{
  +   struct matrix_keypad_platform_data *pdata;
  +   struct matrix_keymap_data *keymap_data;
  +   struct device_node *np = dev-of_node;
  +   struct property *prop;
  +   int key_count = 0, length, row, col;
  +   uint32_t *keymap;
  +
  +   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
  +   if (!pdata) {
  +   dev_err(dev, could not allocate memory for platform

RE: [PATCH 1/2] Input: matrix-keypad - remove const from pointer to array of gpios

On Sat, Oct 20, 2012 at 04:30:59, Dmitry Torokhov wrote:
 On Fri, Oct 19, 2012 at 12:36:12PM +0530, AnilKumar Ch wrote:
  Remove const from pointer to array of gpios in matrix_keypad_platform_data
  struct. This is required if we update row_gpios and col_gpios based on
  device tree data.
 
 Then don't. Set them up via non-const aliases instead.
 

Changed.

Thanks
AnilKumar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [RFC PATCH v3 13/16] ARM: dts: add AM33XX MMC support

2012-10-29 Thread AnilKumar, Chimata

On Thu, Oct 18, 2012 at 18:56:52, Porter, Matt wrote:
> Adds AM33XX MMC support for am335x-bone and am335x-evm.
> 
> Signed-off-by: Matt Porter 
> ---
>  arch/arm/boot/dts/am335x-bone.dts |6 ++
>  arch/arm/boot/dts/am335x-evm.dts  |6 ++
>  arch/arm/boot/dts/am33xx.dtsi |   27 +++
>  3 files changed, 39 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am335x-bone.dts 
> b/arch/arm/boot/dts/am335x-bone.dts
> index c634f87..5510979 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -70,6 +70,8 @@
>   };
>  
>   ldo3_reg: regulator@5 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;

I think these min & max limits are regulator limits. Are these fields
required? Add details of these additions. AFAIK fine-tuned (board
specific) min/max limits should be add here(like mpu and core
regulator nodes)

>   regulator-always-on;
>   };
>  
> @@ -78,3 +80,7 @@
>   };
>   };
>  };
> +
> + {
> + vmmc-supply = <_reg>;
> +};
> diff --git a/arch/arm/boot/dts/am335x-evm.dts 
> b/arch/arm/boot/dts/am335x-evm.dts
> index 185d632..d63fce8 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -114,7 +114,13 @@
>   };
>  
>   vmmc_reg: regulator@12 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;

=same=

>   regulator-always-on;
>   };
>   };
>  };
> +
> + {
> + vmmc-supply = <_reg>;
> +};
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index ab9c78f..26a6af7 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -234,6 +234,33 @@
>   status = "disabled";
>   };
>  
> + mmc1: mmc@4806 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc1";
> + ti,dual-volt;
> + ti,needs-special-reset;
> + dmas = < 24
> +  25>;
> + dma-names = "tx", "rx";

Add status = "disabled" here and "okay" in corresponding
.dts file

> + };
> +
> + mmc2: mmc@481d8000 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc2";
> + ti,needs-special-reset;
> + dmas = < 2
> +  3>;
> + dma-names = "tx", "rx";
> + status = "disabled";
> + };
> +
> + mmc3: mmc@4781 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc3";
> + ti,needs-special-reset;

What about DMA resources for mmc3?

AnilKumar

> + status = "disabled";
> + };
> +
>   wdt2: wdt@44e35000 {
>   compatible = "ti,omap3-wdt";
>   ti,hwmods = "wd_timer2";
> -- 
> 1.7.9.5
> 
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 

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

RE: [RFC PATCH v3 13/16] ARM: dts: add AM33XX MMC support

2012-10-29 Thread AnilKumar, Chimata

On Thu, Oct 18, 2012 at 18:56:52, Porter, Matt wrote:
 Adds AM33XX MMC support for am335x-bone and am335x-evm.
 
 Signed-off-by: Matt Porter mpor...@ti.com
 ---
  arch/arm/boot/dts/am335x-bone.dts |6 ++
  arch/arm/boot/dts/am335x-evm.dts  |6 ++
  arch/arm/boot/dts/am33xx.dtsi |   27 +++
  3 files changed, 39 insertions(+)
 
 diff --git a/arch/arm/boot/dts/am335x-bone.dts 
 b/arch/arm/boot/dts/am335x-bone.dts
 index c634f87..5510979 100644
 --- a/arch/arm/boot/dts/am335x-bone.dts
 +++ b/arch/arm/boot/dts/am335x-bone.dts
 @@ -70,6 +70,8 @@
   };
  
   ldo3_reg: regulator@5 {
 + regulator-min-microvolt = 180;
 + regulator-max-microvolt = 330;

I think these min  max limits are regulator limits. Are these fields
required? Add details of these additions. AFAIK fine-tuned (board
specific) min/max limits should be add here(like mpu and core
regulator nodes)

   regulator-always-on;
   };
  
 @@ -78,3 +80,7 @@
   };
   };
  };
 +
 +mmc1 {
 + vmmc-supply = ldo3_reg;
 +};
 diff --git a/arch/arm/boot/dts/am335x-evm.dts 
 b/arch/arm/boot/dts/am335x-evm.dts
 index 185d632..d63fce8 100644
 --- a/arch/arm/boot/dts/am335x-evm.dts
 +++ b/arch/arm/boot/dts/am335x-evm.dts
 @@ -114,7 +114,13 @@
   };
  
   vmmc_reg: regulator@12 {
 + regulator-min-microvolt = 180;
 + regulator-max-microvolt = 330;

=same=

   regulator-always-on;
   };
   };
  };
 +
 +mmc1 {
 + vmmc-supply = vmmc_reg;
 +};
 diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
 index ab9c78f..26a6af7 100644
 --- a/arch/arm/boot/dts/am33xx.dtsi
 +++ b/arch/arm/boot/dts/am33xx.dtsi
 @@ -234,6 +234,33 @@
   status = disabled;
   };
  
 + mmc1: mmc@4806 {
 + compatible = ti,omap3-hsmmc;
 + ti,hwmods = mmc1;
 + ti,dual-volt;
 + ti,needs-special-reset;
 + dmas = edma 24
 + edma 25;
 + dma-names = tx, rx;

Add status = disabled here and okay in corresponding
.dts file

 + };
 +
 + mmc2: mmc@481d8000 {
 + compatible = ti,omap3-hsmmc;
 + ti,hwmods = mmc2;
 + ti,needs-special-reset;
 + dmas = edma 2
 + edma 3;
 + dma-names = tx, rx;
 + status = disabled;
 + };
 +
 + mmc3: mmc@4781 {
 + compatible = ti,omap3-hsmmc;
 + ti,hwmods = mmc3;
 + ti,needs-special-reset;

What about DMA resources for mmc3?

AnilKumar

 + status = disabled;
 + };
 +
   wdt2: wdt@44e35000 {
   compatible = ti,omap3-wdt;
   ti,hwmods = wd_timer2;
 -- 
 1.7.9.5
 
 ___
 devicetree-discuss mailing list
 devicetree-disc...@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/devicetree-discuss
 

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

RE: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer

2012-09-23 Thread AnilKumar, Chimata

Hi Eric,

Thanks for the comments,

On Mon, Sep 24, 2012 at 03:08:19, Éric Piel wrote:
> On 22-08-12 08:30, AnilKumar Ch wrote:
> > This patch adds support for lis331dlh digital accelerometer to the
> > lis3lv02d driver family. Adds ID field for detecting the lis331dlh
> > module, based on this ID field lis3lv02d driver will export the
> > lis331dlh module functionality.
> 
> Hello AnilKumar,
> 
> Sorry for taking so long to review your patch. Overall, it looks great :-)
> 
> There are just a few points that almost code-style/comment that needs to 
> be fixed. See below. Could you fix these small issues, and submit a new 
> patch for Andrew to pick it in his queue?

As I can see this patch is already in linux-next, I will submit
a new patch by addressing all your comments.

> 
> Here is my:
> Reviewed-by: Éric Piel 
> 
> 
> >
> > Signed-off-by: AnilKumar Ch 
> > ---
> > Changes from v1:
> > - Removed G range sysfs entry from v1
> > - Modified documentation to specify lis331dlh is supported
> >
> >   Documentation/misc-devices/lis3lv02d   |3 ++-
> >   drivers/misc/lis3lv02d/lis3lv02d.c |   42 
> > +-
> >   drivers/misc/lis3lv02d/lis3lv02d.h |   44 
> > +++-
> >   drivers/misc/lis3lv02d/lis3lv02d_i2c.c |7 -
> >   4 files changed, 87 insertions(+), 9 deletions(-)
> >
> > diff --git a/Documentation/misc-devices/lis3lv02d 
> > b/Documentation/misc-devices/lis3lv02d
> > index f1a4ec8..af815b9 100644
> > --- a/Documentation/misc-devices/lis3lv02d
> > +++ b/Documentation/misc-devices/lis3lv02d
> > @@ -4,7 +4,8 @@ Kernel driver lis3lv02d
> >   Supported chips:
> >
> > * STMicroelectronics LIS3LV02DL, LIS3LV02DQ (12 bits precision)
> > -  * STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits)
> > +  * STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits) and
> > +LIS331DLH (16 bits)
> >
> >   Authors:
> >   Yan Burman 
> > diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c 
> > b/drivers/misc/lis3lv02d/lis3lv02d.c
> > index 29d12a7..c0a9199 100644
> > --- a/drivers/misc/lis3lv02d/lis3lv02d.c
> > +++ b/drivers/misc/lis3lv02d/lis3lv02d.c
> > @@ -80,6 +80,14 @@
> >   #define LIS3_SENSITIVITY_12B  ((LIS3_ACCURACY * 1000) / 1024)
> >   #define LIS3_SENSITIVITY_8B   (18 * LIS3_ACCURACY)
> >
> > +/*
> > + * LIS3331DLH spec says 1LSBs corresponds 4G/1024 -> 1LSB is 1000/1024 mG.
> > + * Sensitivity values for +/-2G, outdata in 12 bits for +/-2G scale. so 4
> > + * bits adjustment is required
> > + */
> > +#define LIS3DLH_SENSITIVITY_2G ((LIS3_ACCURACY * 1000) / 1024)
> > +#define SHIFT_ADJ_2G   4
> > +
> You said later:
> >
> > Typo mistake this should be 4G/4096
> Could you fix the comment. Even better, change LIS3331DLH to LIS331DLH
> 
> Also, if I understand correctly, there is currently no support for 
> changing the sensitivity. It stays at 2G all the time, right? In such 
> case, please add a sentence in this comment that the driver does only 
> support the 2G sensitivity for now.

I will do this

> 
> 
> >   #define LIS3_DEFAULT_FUZZ_12B 3
> >   #define LIS3_DEFAULT_FLAT_12B 3
> >   #define LIS3_DEFAULT_FUZZ_8B  1
> > @@ -133,6 +141,19 @@ static s16 lis3lv02d_read_12(struct lis3lv02d *lis3, 
> > int reg)
> > return (s16)((hi << 8) | lo);
> >   }
> >
> > +/* 12bits for 2G range, 13 bits for 4G range and 14 bits for 8G range */
> > +static s16 lis3lv02d_read_16(struct lis3lv02d *lis3, int reg)
> > +{
> > +   u8 lo, hi;
> > +   int v;
> > +
> > +   lis3->read(lis3, reg - 1, );
> > +   lis3->read(lis3, reg, );
> > +   v = (int) ((hi << 8) | lo);
> > +
> > +   return (s16) v >> lis3->shift_adj;
> > +}
> As the method reads 12, 13, or 14 bits, it's a bit tricky to call it 
> "*_read_16". I'd suggest maybe "lis3lv02d_read_12_14", 
> "lis3lv02d_read_adj_16", or even "lis331dlh_read_data". Pick the one you 
> prefer :-)

Comment is available to convey the number of bits so I am changing it to
"lis331dlh_read_data".

> 
> 
> >   /**
> >* lis3lv02d_get_axis - For the given axis, give the value converted
> >* @axis:  1,2,3 - can also be negative
> > @@ -193,6 +214,7 @@ static void lis3lv02d_get_xyz(struct lis3lv02d *lis3, 
> > int *x, int *y, int *z)
> >   static int lis3_12_rates[4] = {40, 160, 640, 2560};
> >   static int lis3_8_rates[2] = {100, 400};
> >   static int lis3_3dc_rates[16] = {0, 1, 10, 25, 50, 100, 200, 400, 1600, 
> > 5000};
> > +static int lis3_3dlh_rates[4] = {50, 100, 400, 1000};
> >
> >   /* ODR is Output Data Rate */
> >   static int lis3lv02d_get_odr(struct lis3lv02d *lis3)
> > @@ -265,7 +287,7 @@ static int lis3lv02d_selftest(struct lis3lv02d *lis3, 
> > s16 results[3])
> > (LIS3_IRQ1_DATA_READY | LIS3_IRQ2_DATA_READY));
> > }
> >
> > -   if (lis3->whoami == WAI_3DC) {
> > +   if ((lis3->whoami == WAI_3DC) || (lis3->whoami == WAI_3DLH)) {
> > ctlreg =

RE: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer

2012-09-23 Thread AnilKumar, Chimata

Hi Eric,

Thanks for the comments,

On Mon, Sep 24, 2012 at 03:08:19, Éric Piel wrote:
 On 22-08-12 08:30, AnilKumar Ch wrote:
  This patch adds support for lis331dlh digital accelerometer to the
  lis3lv02d driver family. Adds ID field for detecting the lis331dlh
  module, based on this ID field lis3lv02d driver will export the
  lis331dlh module functionality.
 
 Hello AnilKumar,
 
 Sorry for taking so long to review your patch. Overall, it looks great :-)
 
 There are just a few points that almost code-style/comment that needs to 
 be fixed. See below. Could you fix these small issues, and submit a new 
 patch for Andrew to pick it in his queue?

As I can see this patch is already in linux-next, I will submit
a new patch by addressing all your comments.

 
 Here is my:
 Reviewed-by: Éric Piel eric.p...@tremplin-utc.net
 
 
 
  Signed-off-by: AnilKumar Ch anilku...@ti.com
  ---
  Changes from v1:
  - Removed G range sysfs entry from v1
  - Modified documentation to specify lis331dlh is supported
 
Documentation/misc-devices/lis3lv02d   |3 ++-
drivers/misc/lis3lv02d/lis3lv02d.c |   42 
  +-
drivers/misc/lis3lv02d/lis3lv02d.h |   44 
  +++-
drivers/misc/lis3lv02d/lis3lv02d_i2c.c |7 -
4 files changed, 87 insertions(+), 9 deletions(-)
 
  diff --git a/Documentation/misc-devices/lis3lv02d 
  b/Documentation/misc-devices/lis3lv02d
  index f1a4ec8..af815b9 100644
  --- a/Documentation/misc-devices/lis3lv02d
  +++ b/Documentation/misc-devices/lis3lv02d
  @@ -4,7 +4,8 @@ Kernel driver lis3lv02d
Supported chips:
 
  * STMicroelectronics LIS3LV02DL, LIS3LV02DQ (12 bits precision)
  -  * STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits)
  +  * STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits) and
  +LIS331DLH (16 bits)
 
Authors:
Yan Burman burman@gmail.com
  diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c 
  b/drivers/misc/lis3lv02d/lis3lv02d.c
  index 29d12a7..c0a9199 100644
  --- a/drivers/misc/lis3lv02d/lis3lv02d.c
  +++ b/drivers/misc/lis3lv02d/lis3lv02d.c
  @@ -80,6 +80,14 @@
#define LIS3_SENSITIVITY_12B  ((LIS3_ACCURACY * 1000) / 1024)
#define LIS3_SENSITIVITY_8B   (18 * LIS3_ACCURACY)
 
  +/*
  + * LIS3331DLH spec says 1LSBs corresponds 4G/1024 - 1LSB is 1000/1024 mG.
  + * Sensitivity values for +/-2G, outdata in 12 bits for +/-2G scale. so 4
  + * bits adjustment is required
  + */
  +#define LIS3DLH_SENSITIVITY_2G ((LIS3_ACCURACY * 1000) / 1024)
  +#define SHIFT_ADJ_2G   4
  +
 You said later:
 
  Typo mistake this should be 4G/4096
 Could you fix the comment. Even better, change LIS3331DLH to LIS331DLH
 
 Also, if I understand correctly, there is currently no support for 
 changing the sensitivity. It stays at 2G all the time, right? In such 
 case, please add a sentence in this comment that the driver does only 
 support the 2G sensitivity for now.

I will do this

 
 
#define LIS3_DEFAULT_FUZZ_12B 3
#define LIS3_DEFAULT_FLAT_12B 3
#define LIS3_DEFAULT_FUZZ_8B  1
  @@ -133,6 +141,19 @@ static s16 lis3lv02d_read_12(struct lis3lv02d *lis3, 
  int reg)
  return (s16)((hi  8) | lo);
}
 
  +/* 12bits for 2G range, 13 bits for 4G range and 14 bits for 8G range */
  +static s16 lis3lv02d_read_16(struct lis3lv02d *lis3, int reg)
  +{
  +   u8 lo, hi;
  +   int v;
  +
  +   lis3-read(lis3, reg - 1, lo);
  +   lis3-read(lis3, reg, hi);
  +   v = (int) ((hi  8) | lo);
  +
  +   return (s16) v  lis3-shift_adj;
  +}
 As the method reads 12, 13, or 14 bits, it's a bit tricky to call it 
 *_read_16. I'd suggest maybe lis3lv02d_read_12_14, 
 lis3lv02d_read_adj_16, or even lis331dlh_read_data. Pick the one you 
 prefer :-)

Comment is available to convey the number of bits so I am changing it to
lis331dlh_read_data.

 
 
/**
 * lis3lv02d_get_axis - For the given axis, give the value converted
 * @axis:  1,2,3 - can also be negative
  @@ -193,6 +214,7 @@ static void lis3lv02d_get_xyz(struct lis3lv02d *lis3, 
  int *x, int *y, int *z)
static int lis3_12_rates[4] = {40, 160, 640, 2560};
static int lis3_8_rates[2] = {100, 400};
static int lis3_3dc_rates[16] = {0, 1, 10, 25, 50, 100, 200, 400, 1600, 
  5000};
  +static int lis3_3dlh_rates[4] = {50, 100, 400, 1000};
 
/* ODR is Output Data Rate */
static int lis3lv02d_get_odr(struct lis3lv02d *lis3)
  @@ -265,7 +287,7 @@ static int lis3lv02d_selftest(struct lis3lv02d *lis3, 
  s16 results[3])
  (LIS3_IRQ1_DATA_READY | LIS3_IRQ2_DATA_READY));
  }
 
  -   if (lis3-whoami == WAI_3DC) {
  +   if ((lis3-whoami == WAI_3DC) || (lis3-whoami == WAI_3DLH)) {
  ctlreg = CTRL_REG4;
  selftest = CTRL4_ST0;
  } else {
  @@ -396,9 +418,17 @@ int lis3lv02d_poweron(struct lis3lv02d *lis3)
  lis3-read(lis3, CTRL_REG2,

RE: [PATCH RFT] regulator: tps65217: Convert to regulator_[is_enabled|get_voltage_sel]_regmap

On Fri, Sep 07, 2012 at 20:00:59, Mark Brown wrote:
> On Fri, Sep 07, 2012 at 02:26:53PM +0000, AnilKumar, Chimata wrote:
> > On Fri, Sep 07, 2012 at 19:51:51, Mark Brown wrote:
> 
> > > You didn't send a patch.
> 
> > Its there, above to my comment
> > https://lkml.org/lkml/2012/6/18/308
> 
> Right, but my reply was saying we should do something different so I was
> expecting an update which implemented one of the suggestions.

I will send the formal patch.

Thanks
AnilKumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH RFT] regulator: tps65217: Convert to regulator_[is_enabled|get_voltage_sel]_regmap

On Fri, Sep 07, 2012 at 19:51:51, Mark Brown wrote:
> On Fri, Sep 07, 2012 at 02:19:59PM +0000, AnilKumar, Chimata wrote:
> 
> > Currently this is not properly taken care, is there are any specific
> > reasons for this?
> 
> You didn't send a patch.
> 

Its there, above to my comment
https://lkml.org/lkml/2012/6/18/308

Thanks
AnilKumar

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

RE: [PATCH RFT] regulator: tps65217: Convert to regulator_[is_enabled|get_voltage_sel]_regmap

On Mon, Jun 18, 2012 at 18:15:14, Mark Brown wrote:
> On Mon, Jun 18, 2012 at 12:39:38PM +0000, AnilKumar, Chimata wrote:
> 
> > +   if (config->regmap)
> > +   rdev->regmap = config->regmap;
> > +   else
> > +   rdev->regmap = dev_get_regmap(dev->parent, NULL);
> 
> No, this would be broken.  We're specifically using the device we got
> passed in.  In this case the fact that the regmap is on the MFD means
> that the driver does need to explicitly set the regmap.  Or we should
> have this be a multi-stage series of checks:
> 
>   if (config->regmap)
>   rdev->regmap = config->regmap;
>   else if (dev_get_regmap(dev, NULL))
>   rdev->regmap = dev_get_regmap(dev, NULL);
>   else if (dev->parent)
>   rdev->regmap = dev_get_regmap(dev->parent, NULL);
> 
> which should cover the MFD case if there's no regmap on the child
> without having to go through all the drivers doing it by hand.
> 

Mark,

Currently this is not properly taken care, is there are any specific
reasons for this?

Thanks
AnilKumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH RFT] regulator: tps65217: Convert to regulator_[is_enabled|get_voltage_sel]_regmap

On Mon, Jun 18, 2012 at 18:15:14, Mark Brown wrote:
 On Mon, Jun 18, 2012 at 12:39:38PM +, AnilKumar, Chimata wrote:
 
  +   if (config-regmap)
  +   rdev-regmap = config-regmap;
  +   else
  +   rdev-regmap = dev_get_regmap(dev-parent, NULL);
 
 No, this would be broken.  We're specifically using the device we got
 passed in.  In this case the fact that the regmap is on the MFD means
 that the driver does need to explicitly set the regmap.  Or we should
 have this be a multi-stage series of checks:
 
   if (config-regmap)
   rdev-regmap = config-regmap;
   else if (dev_get_regmap(dev, NULL))
   rdev-regmap = dev_get_regmap(dev, NULL);
   else if (dev-parent)
   rdev-regmap = dev_get_regmap(dev-parent, NULL);
 
 which should cover the MFD case if there's no regmap on the child
 without having to go through all the drivers doing it by hand.
 

Mark,

Currently this is not properly taken care, is there are any specific
reasons for this?

Thanks
AnilKumar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH RFT] regulator: tps65217: Convert to regulator_[is_enabled|get_voltage_sel]_regmap

On Fri, Sep 07, 2012 at 19:51:51, Mark Brown wrote:
 On Fri, Sep 07, 2012 at 02:19:59PM +, AnilKumar, Chimata wrote:
 
  Currently this is not properly taken care, is there are any specific
  reasons for this?
 
 You didn't send a patch.
 

Its there, above to my comment
https://lkml.org/lkml/2012/6/18/308

Thanks
AnilKumar

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

RE: [PATCH RFT] regulator: tps65217: Convert to regulator_[is_enabled|get_voltage_sel]_regmap

On Fri, Sep 07, 2012 at 20:00:59, Mark Brown wrote:
 On Fri, Sep 07, 2012 at 02:26:53PM +, AnilKumar, Chimata wrote:
  On Fri, Sep 07, 2012 at 19:51:51, Mark Brown wrote:
 
   You didn't send a patch.
 
  Its there, above to my comment
  https://lkml.org/lkml/2012/6/18/308
 
 Right, but my reply was saying we should do something different so I was
 expecting an update which implemented one of the suggestions.

I will send the formal patch.

Thanks
AnilKumar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer

2012-08-27 Thread AnilKumar, Chimata

Hi Eric,

On Wed, Aug 22, 2012 at 13:18:38, Arnd Bergmann wrote:
> On Wednesday 22 August 2012, AnilKumar Ch wrote:
> > This patch adds support for lis331dlh digital accelerometer to the
> > lis3lv02d driver family. Adds ID field for detecting the lis331dlh
> > module, based on this ID field lis3lv02d driver will export the
> > lis331dlh module functionality.
> > 
> > Signed-off-by: AnilKumar Ch 
> 
> Acked-by: Arnd Bergmann 
> 

If there are no further comments could you please push
this patch?

Thanks
AnilKumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer

2012-08-27 Thread AnilKumar, Chimata

Hi Eric,

On Wed, Aug 22, 2012 at 13:18:38, Arnd Bergmann wrote:
 On Wednesday 22 August 2012, AnilKumar Ch wrote:
  This patch adds support for lis331dlh digital accelerometer to the
  lis3lv02d driver family. Adds ID field for detecting the lis331dlh
  module, based on this ID field lis3lv02d driver will export the
  lis331dlh module functionality.
  
  Signed-off-by: AnilKumar Ch anilku...@ti.com
 
 Acked-by: Arnd Bergmann a...@arndb.de
 

If there are no further comments could you please push
this patch?

Thanks
AnilKumar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer

Chinmay,

On Thu, Aug 23, 2012 at 15:53:10, Chinmay V S wrote:
> > Note from datasheet, "1LSb=4g/4096 at 12bit representation,
> > ±2g Full-scale"
> 
> Precisely my point. All the datasheet says is :
> 1. It is +/-2G mode --> so Numerator is 4G.
> 2. We are using 12bits --> so Denominator is 2^12 = 4096.
> 
> There is no clear reason/justification as to why 12bits was chosen in
> the first place. At this point unless someone from the
> design/original-driver team actually confirms why the 12bit
> representation was chosen, it is all conjecture on our part.
> 
> If you have the actual LIS331DLH hardware, can you verify if the lower
> 4bits do actually contain any data (or are they always zero). This
> will help us decide whether to use them(16bit mode) or discard
> them(12bit mode)?...
> 

This is the outdata of accelerometer

root@am335xevm:~# cat /sys/devices/platform/lis3lv02d/position
[   16.323852] lis3lv02d: hi 0x1low 0x50   val 0x15
[   16.329742] lis3lv02d: hi 0x0low 0x0val 0x0
[   16.335052] lis3lv02d: hi 0x3e   low 0x50   val 0x3e5
(20,0,973)
root@am335xevm:~# cat /sys/devices/platform/lis3lv02d/position
[   25.777343] lis3lv02d: hi 0x2low 0xa0   val 0x2a
[   25.783203] lis3lv02d: hi 0xc1   low 0xf0   val 0xfc1f
[   25.790130] lis3lv02d: hi 0xfd   low 0x50   val 0xffd5
(41,-969,-41)
root@am335xevm:~# cat /sys/devices/platform/lis3lv02d/position
[   47.607330] lis3lv02d: hi 0xc0   low 0x60   val 0xfc06
[   47.613464] lis3lv02d: hi 0xfd   low 0x90   val 0xffd9
[   47.619934] lis3lv02d: hi 0x2low 0x40   val 0x24
(-994,-38,35)

Lower nibble always "0"

Regards
AnilKumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer

On Wed, Aug 22, 2012 at 22:24:10, Chinmay V S wrote:
> > Look at this application note which talks about the outdata values
> > for 2G range (page 12/31) 
> > http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00215823.pdf
> 
> Had been through the application note earlier. The table5 (on page 12)
> that you refer to, does NOT contradict either 12/16bit, as in all the
> examples the lower 4 bits are zero. So i don't see how one can assume
> from these examples that for +/-2G they one should consider 12/16bits.
> A nice side-effect of using 12|13|14bits for +/-2|4|8G is that the
> values returned by the driver are in mG in all the 3 modes.
> 
> > Corresponding to the 4G and 8G I got the details form older
> > patches (SHIFT_ADJ_4G and SHIFT_ADJ_8G).
> > http://driverdev.linuxdriverproject.org/pipermail/devel/2010-November/009685.html
> >
> > We can easily interpret number of bits for 4G and 8G from 2G
> > information.
> 
> Going through the code of this driver i can see what you are talking
> about. Depending on the full-scale-range the device is being
> configured for, the number of bits used to represent acceleration in
> the driver is changed.
> 
> Again judging from the code, the driver is always returning
> acceleration at a constant accuracy i.e. 1mG in all the 3 modes
> (+/-2|4|8G)i.e.
> +/-2G is mode means value can be anywhere from +/-2048mG,
> (requiring 12bits.)
> +/-4G in the range of +/-4096mG, requiring 13bits.
> +/-8G i.e. +/-8192mG, requiring 14bits.
> 
> Was this done...
> 
> a. ...because LIS331DLH's theoretical MAX accuracy is ~1mG
> If yes, then using 12bits is fine.
> 

Note from datasheet, "1LSb=4g/4096 at 12bit representation,
±2g Full-scale"

>From this I understood that ±2G full scale value is 12 bits.
That is one more reason to take 12bit value.

Regards
AnilKumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer

On Wed, Aug 22, 2012 at 22:24:10, Chinmay V S wrote:
Look at this application note which talks about the outdata values
for 2G range (page 12/31)
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00215823.pdf

Had been through the application note earlier. The table5 (on page 12)
that you refer to, does NOT contradict either 12/16bit, as in all the
examples the lower 4 bits are zero. So i don't see how one can assume
from these examples that for +/-2G they one should consider 12/16bits.
A nice side-effect of using 12|13|14bits for +/-2|4|8G is that the
values returned by the driver are in mG in all the 3 modes.

Corresponding to the 4G and 8G I got the details form older
patches (SHIFT_ADJ_4G and SHIFT_ADJ_8G).
http://driverdev.linuxdriverproject.org/pipermail/devel/2010-November/009685.html

We can easily interpret number of bits for 4G and 8G from 2G
information.

Going through the code of this driver i can see what you are talking
about. Depending on the full-scale-range the device is being
configured for, the number of bits used to represent acceleration in
the driver is changed.

Again judging from the code, the driver is always returning
acceleration at a constant accuracy i.e. 1mG in all the 3 modes
(+/-2|4|8G)i.e.
+/-2G is mode means value can be anywhere from +/-2048mG,
(requiring 12bits.)
+/-4G in the range of +/-4096mG, requiring 13bits.
+/-8G i.e. +/-8192mG, requiring 14bits.

Was this done...

a. ...because LIS331DLH's theoretical MAX accuracy is ~1mG
If yes, then using 12bits is fine.

Note from datasheet, 1LSb=4g/4096 at 12bit representation,
±2g Full-scale

From this I understood that ±2G full scale value is 12 bits.
That is one more reason to take 12bit value.

Regards
AnilKumar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

RE: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer

Chinmay,

On Thu, Aug 23, 2012 at 15:53:10, Chinmay V S wrote:
  Note from datasheet, 1LSb=4g/4096 at 12bit representation,
  ±2g Full-scale
 
 Precisely my point. All the datasheet says is :
 1. It is +/-2G mode -- so Numerator is 4G.
 2. We are using 12bits -- so Denominator is 2^12 = 4096.
 
 There is no clear reason/justification as to why 12bits was chosen in
 the first place. At this point unless someone from the
 design/original-driver team actually confirms why the 12bit
 representation was chosen, it is all conjecture on our part.
 
 If you have the actual LIS331DLH hardware, can you verify if the lower
 4bits do actually contain any data (or are they always zero). This
 will help us decide whether to use them(16bit mode) or discard
 them(12bit mode)?...
 

This is the outdata of accelerometer

root@am335xevm:~# cat /sys/devices/platform/lis3lv02d/position
[   16.323852] lis3lv02d: hi 0x1low 0x50   val 0x15
[   16.329742] lis3lv02d: hi 0x0low 0x0val 0x0
[   16.335052] lis3lv02d: hi 0x3e   low 0x50   val 0x3e5
(20,0,973)
root@am335xevm:~# cat /sys/devices/platform/lis3lv02d/position
[   25.777343] lis3lv02d: hi 0x2low 0xa0   val 0x2a
[   25.783203] lis3lv02d: hi 0xc1   low 0xf0   val 0xfc1f
[   25.790130] lis3lv02d: hi 0xfd   low 0x50   val 0xffd5
(41,-969,-41)
root@am335xevm:~# cat /sys/devices/platform/lis3lv02d/position
[   47.607330] lis3lv02d: hi 0xc0   low 0x60   val 0xfc06
[   47.613464] lis3lv02d: hi 0xfd   low 0x90   val 0xffd9
[   47.619934] lis3lv02d: hi 0x2low 0x40   val 0x24
(-994,-38,35)

Lower nibble always 0

Regards
AnilKumar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer

On Wed, Aug 22, 2012 at 16:09:22, Chinmay V S wrote:
> Hmmm. Interesting. As i understand LIS331DLH provides 16bit data
> irrespective of the full-scale/sensitivity configuration. Hence we
> could effectively map +/-2G to +/-32768(signed 16bit 2's complement).
> According to the current-patch right-shifting the register values by
> 4(i.e. reducing 16bit --> 12bit) will mean that we lose accuracy by
> ~1mG.
> 
> Clearly this will NOT affect use-case like display-orientation in
> smart-phones, but surely medical and industrial applications WILL
> benefit from the additional accuracy by utilising the entire 16-bit
> resolution provided by LIS331DLH hardware.
> 
> I went through the LIS331DLH datasheet/application-note from
> http://www.st.com/internet/analog/product/218132.jsp and i'm a bit
> confused from your statement about +/-2G being 12bit data. Nowhere is
> it mentioned that LIS331DLH provides +/-2G|+/-4G|+/-8G as 12|13|14 bit
> data respectively. Then again i might be wrong...
> 

Look at this application note which talks about the outdata values
for 2G range (page 12/31) 
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00215823.pdf

Corresponding to the 4G and 8G I got the details form older
patches (SHIFT_ADJ_4G and SHIFT_ADJ_8G).
http://driverdev.linuxdriverproject.org/pipermail/devel/2010-November/009685.html

We can easily interpret number of bits for 4G and 8G from 2G
information.

Thanks
AnilKumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer

Hi Chinmay,

Thanks for the comments

On Wed, Aug 22, 2012 at 14:14:55, Chinmay V S wrote:
> Hi All,
> 
> A few nitpicks.
> 
> > + * LIS3331DLH spec says 1LSBs corresponds 4G/1024 -> 1LSB is 1000/1024 mG.
> > + * Sensitivity values for +/-2G, outdata in 12 bits for +/-2G scale. so 4
> > + * bits adjustment is required
> Shouldn't it be "1LSB is 4000/1024 mG" ?

Typo mistake this should be 4G/4096

> Also "outdata in 12bits" (typo. in->is?)
> 

If we look at the lis331dlh datasheet 12 bits outdata for +/- 2G resolution
range and 13 bits for +/- 4G range and 14 bits for +/- 8G range. So output
data is only 12 bits.

> On a more technical note, now that LIS3331DLH has 16bit resolution,
> why don't we simply return the entire 16-bit value in
> lis3lv02d_read_16(). The fact that lis3lv02d_read_16() has 16-bit
> resolution can be indicated by

Depending on the range 2 or 4 or 8 we have to pass the outdata that is
handled by using the shift_adj member to shift the outdata to corresponding
bits 12/13/14.

> 
> @@ -954,6 +984,16 @@ int lis3lv02d_init_device(struct lis3lv02d *lis3)
> lis3->odr_mask = CTRL1_ODR0|CTRL1_ODR1|CTRL1_ODR2|CTRL1_ODR3;
> lis3->scale = LIS3_SENSITIVITY_8B;
> break;
> +   case WAI_3DLH:
> +   pr_info("16 bits 3DLH sensor found\n");
> +   lis3->read_data = lis3lv02d_read_16;
> +   lis3->mdps_max_val = 32768; /* 16 bits for +/-2G */

This driver supports only +/-2G range of values so it is limited to 2048.
With this we do not have the runtime change of G range so by default 2G
is added.

Regards
AnilKumar

RE: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer

Hi Chinmay,

Thanks for the comments

On Wed, Aug 22, 2012 at 14:14:55, Chinmay V S wrote:
 Hi All,
 
 A few nitpicks.
 
  + * LIS3331DLH spec says 1LSBs corresponds 4G/1024 - 1LSB is 1000/1024 mG.
  + * Sensitivity values for +/-2G, outdata in 12 bits for +/-2G scale. so 4
  + * bits adjustment is required
 Shouldn't it be 1LSB is 4000/1024 mG ?

Typo mistake this should be 4G/4096

 Also outdata in 12bits (typo. in-is?)
 

If we look at the lis331dlh datasheet 12 bits outdata for +/- 2G resolution
range and 13 bits for +/- 4G range and 14 bits for +/- 8G range. So output
data is only 12 bits.

 On a more technical note, now that LIS3331DLH has 16bit resolution,
 why don't we simply return the entire 16-bit value in
 lis3lv02d_read_16(). The fact that lis3lv02d_read_16() has 16-bit
 resolution can be indicated by

Depending on the range 2 or 4 or 8 we have to pass the outdata that is
handled by using the shift_adj member to shift the outdata to corresponding
bits 12/13/14.

 
 @@ -954,6 +984,16 @@ int lis3lv02d_init_device(struct lis3lv02d *lis3)
 lis3-odr_mask = CTRL1_ODR0|CTRL1_ODR1|CTRL1_ODR2|CTRL1_ODR3;
 lis3-scale = LIS3_SENSITIVITY_8B;
 break;
 +   case WAI_3DLH:
 +   pr_info(16 bits 3DLH sensor found\n);
 +   lis3-read_data = lis3lv02d_read_16;
 +   lis3-mdps_max_val = 32768; /* 16 bits for +/-2G */

This driver supports only +/-2G range of values so it is limited to 2048.
With this we do not have the runtime change of G range so by default 2G
is added.

Regards
AnilKumar

RE: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer

On Wed, Aug 22, 2012 at 16:09:22, Chinmay V S wrote:
Hmmm. Interesting. As i understand LIS331DLH provides 16bit data
irrespective of the full-scale/sensitivity configuration. Hence we
could effectively map +/-2G to +/-32768(signed 16bit 2's complement).
According to the current-patch right-shifting the register values by
4(i.e. reducing 16bit -- 12bit) will mean that we lose accuracy by
~1mG.

Clearly this will NOT affect use-case like display-orientation in
smart-phones, but surely medical and industrial applications WILL
benefit from the additional accuracy by utilising the entire 16-bit
resolution provided by LIS331DLH hardware.

I went through the LIS331DLH datasheet/application-note from
http://www.st.com/internet/analog/product/218132.jsp and i'm a bit
confused from your statement about +/-2G being 12bit data. Nowhere is
it mentioned that LIS331DLH provides +/-2G|+/-4G|+/-8G as 12|13|14 bit
data respectively. Then again i might be wrong...

Look at this application note which talks about the outdata values
for 2G range (page 12/31)
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00215823.pdf

Corresponding to the 4G and 8G I got the details form older
patches (SHIFT_ADJ_4G and SHIFT_ADJ_8G).
http://driverdev.linuxdriverproject.org/pipermail/devel/2010-November/009685.html

We can easily interpret number of bits for 4G and 8G from 2G
information.

Thanks
AnilKumar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

RE: linux-next: Tree for July 17 (mfd/tps65217.c)

2012-08-21 Thread AnilKumar, Chimata

Hi Samuel,

On Tue, Aug 21, 2012 at 23:21:37, Randy Dunlap wrote:
> On 08/05/2012 11:38 PM, AnilKumar, Chimata wrote:
> 
> > On Fri, Aug 03, 2012 at 22:58:01, Randy Dunlap wrote:
> >> On 07/17/2012 02:48 PM, Randy Dunlap wrote:
> >>
> >>> On 07/16/2012 10:41 PM, Stephen Rothwell wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> Changes since 20120716:
> >>>>
> >>>
> >>>
> >>> on i386:
> >>>
> >>> drivers/built-in.o: In function `tps65217_probe':
> >>> tps65217.c:(.devinit.text+0x13e37): undefined reference to 
> >>> `of_regulator_match'
> >>>
> >>>
> >>> Full randconfig file is attached.
> >>> CONFIG_REGULATOR is not enabled.
> >>>
> >>
> >>
> >> This build error is still present in linux-next of 20120803.
> >>
> > 
> > This will be fixed with this patch
> > https://patchwork.kernel.org/patch/1220151/
> > 
> > Today, I will submit v2 for this
> 
> 
> This build still fails in linux-next 20120821.

Could you please push this patch ASAP?
http://www.spinics.net/lists/linux-omap/msg75336.html

Thanks
AnilKumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: linux-next: Tree for July 17 (mfd/tps65217.c)

2012-08-21 Thread AnilKumar, Chimata

Hi Samuel,

On Tue, Aug 21, 2012 at 23:21:37, Randy Dunlap wrote:
 On 08/05/2012 11:38 PM, AnilKumar, Chimata wrote:
 
  On Fri, Aug 03, 2012 at 22:58:01, Randy Dunlap wrote:
  On 07/17/2012 02:48 PM, Randy Dunlap wrote:
 
  On 07/16/2012 10:41 PM, Stephen Rothwell wrote:
 
  Hi all,
 
  Changes since 20120716:
 
 
 
  on i386:
 
  drivers/built-in.o: In function `tps65217_probe':
  tps65217.c:(.devinit.text+0x13e37): undefined reference to 
  `of_regulator_match'
 
 
  Full randconfig file is attached.
  CONFIG_REGULATOR is not enabled.
 
 
 
  This build error is still present in linux-next of 20120803.
 
  
  This will be fixed with this patch
  https://patchwork.kernel.org/patch/1220151/
  
  Today, I will submit v2 for this
 
 
 This build still fails in linux-next 20120821.

Could you please push this patch ASAP?
http://www.spinics.net/lists/linux-omap/msg75336.html

Thanks
AnilKumar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v3 1/2] lis3: add generic DT matching code

2012-08-07 Thread AnilKumar, Chimata

Hi Mack,

No attachments please.

On Wed, Aug 08, 2012 at 00:19:01, Daniel Mack wrote:
> Hi,
> 
> thanks for your review.
> 
> On 06.08.2012 12:45, AnilKumar, Chimata wrote:
> > On Sun, Aug 05, 2012 at 21:48:42, Daniel Mack wrote:
> >> On 30.07.2012 09:36, Daniel Mack wrote:
> >>> This patch adds logic to parse lis3 properties from a device tree node
> >>> and store them in a freshly allocated lis3lv02d_platform_data.
> >>>
> >>> Note that the actual match tables are left out here. This part should
> >>> happen in the drivers that bind to the individual busses (SPI/I2C/PCI).
> >>>
> >>> Also adds some DT bindinds documentation.
> >>>
> >>> Signed-off-by: Daniel Mack 
> >>> ---
> >>> Changes from v2:
> >>>  - kzalloc braino
> >>>
> >>> Changes from v1:
> >>>  - some typos in properties fixed
> >>>
> >>>
> >>>  Documentation/devicetree/bindings/misc/lis302.txt |  74 
> >>>  drivers/misc/lis3lv02d/lis3lv02d.c| 137 
> >>> ++
> >>>  drivers/misc/lis3lv02d/lis3lv02d.h|   4 +
> >>>  3 files changed, 215 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/misc/lis302.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/misc/lis302.txt 
> >>> b/Documentation/devicetree/bindings/misc/lis302.txt
> >>> new file mode 100644
> >>> index 000..66230fd
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/misc/lis302.txt
> >>> @@ -0,0 +1,74 @@
> >>> +LIS302 accelerometer devicetree bindings
> >>> +
> >>> +This device is matched via its bus drivers, and has a number of 
> >>> properties
> >>> +that apply in on the generic device (independent from the bus).
> >>> +
> >>> +
> >>> +Required properties for the SPI bindings:
> >>> + - compatible:   should be set to "st,lis3lv02d_spi"
> >>> + - reg:  the chipselect index
> >>> + - spi-max-frequency:maximal bus speed, should be set to 100 
> >>> unless
> >>> + constrained by external circuitry
> >>> + - interrupts:   the interrupt generated by the device
> >>> +
> >>> +
> >>> +Optional properties for all bus drivers:
> >>> +
> >>> + - st,click-single-{x,y,z}:  if present, tells the device to issue an
> >>> + interrupt on single click events on the
> >>> + x/y/z axis.
> >>> + - st,click-double-{x,y,z}:  if present, tells the device to issue an
> >>> + interrupt on double click events on the
> >>> + x/y/z axis.
> >>> + - st,click-thresh-{x,y,z}:  set the x/y/z axis threshold
> >>> + - st,click-click-time-limit:click time limit, from 0 to 127.5msec
> >>> + with step of 0.5 msec
> >>> + - st,click-latency: click latency, from 0 to 255 msec with
> >>> + step of 1 msec.
> >>> + - st,click-window:  click window, from 0 to 255 msec with
> >>> + step of 1 msec.
> >>> + - st,irq{1,2}-disable:  disable IRQ 1/2
> >>> + - st,irq{1,2}-ff-wu-1:  raise IRQ 1/2 on FF_WU_1 condition
> >>> + - st,irq{1,2}-ff-wu-2:  raise IRQ 1/2 on FF_WU_2 condition
> >>> + - st,irq{1,2}-data-ready:   raise IRQ 1/2 on data ready contition
> >>> + - st,irq{1,2}-click:raise IRQ 1/2 on click condition
> >>> + - st,irq-open-drain:consider IRQ lines open-drain
> >>> + - st,irq-active-low:make IRQ lines active low
> >>> + - st,wu-duration-1: duration register for Free-Fall/Wake-Up
> >>> + interrupt 1
> >>> + - st,wu-duration-2: duration register for Free-Fall/Wake-Up
> >>> + interrupt 2
> >>> + - st,wakeup-{x,y,z}-{lo,hi}:set wakeup condition on x/y/z axis for
> >>> + upper/lower limit
> >>> + - st,highpass-cutoff-hz=:   1, 2, 4 or 8 for 1Hz, 2Hz, 4Hz or 8Hz of
> >>> + highpass cut-off frequency
> >>> + -

RE: [PATCH v3 1/2] lis3: add generic DT matching code

2012-08-07 Thread AnilKumar, Chimata

Hi Mack,

No attachments please.

On Wed, Aug 08, 2012 at 00:19:01, Daniel Mack wrote:
 Hi,
 
 thanks for your review.
 
 On 06.08.2012 12:45, AnilKumar, Chimata wrote:
  On Sun, Aug 05, 2012 at 21:48:42, Daniel Mack wrote:
  On 30.07.2012 09:36, Daniel Mack wrote:
  This patch adds logic to parse lis3 properties from a device tree node
  and store them in a freshly allocated lis3lv02d_platform_data.
 
  Note that the actual match tables are left out here. This part should
  happen in the drivers that bind to the individual busses (SPI/I2C/PCI).
 
  Also adds some DT bindinds documentation.
 
  Signed-off-by: Daniel Mack zon...@gmail.com
  ---
  Changes from v2:
   - kzalloc braino
 
  Changes from v1:
   - some typos in properties fixed
 
 
   Documentation/devicetree/bindings/misc/lis302.txt |  74 
   drivers/misc/lis3lv02d/lis3lv02d.c| 137 
  ++
   drivers/misc/lis3lv02d/lis3lv02d.h|   4 +
   3 files changed, 215 insertions(+)
   create mode 100644 Documentation/devicetree/bindings/misc/lis302.txt
 
  diff --git a/Documentation/devicetree/bindings/misc/lis302.txt 
  b/Documentation/devicetree/bindings/misc/lis302.txt
  new file mode 100644
  index 000..66230fd
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/misc/lis302.txt
  @@ -0,0 +1,74 @@
  +LIS302 accelerometer devicetree bindings
  +
  +This device is matched via its bus drivers, and has a number of 
  properties
  +that apply in on the generic device (independent from the bus).
  +
  +
  +Required properties for the SPI bindings:
  + - compatible:   should be set to st,lis3lv02d_spi
  + - reg:  the chipselect index
  + - spi-max-frequency:maximal bus speed, should be set to 100 
  unless
  + constrained by external circuitry
  + - interrupts:   the interrupt generated by the device
  +
  +
  +Optional properties for all bus drivers:
  +
  + - st,click-single-{x,y,z}:  if present, tells the device to issue an
  + interrupt on single click events on the
  + x/y/z axis.
  + - st,click-double-{x,y,z}:  if present, tells the device to issue an
  + interrupt on double click events on the
  + x/y/z axis.
  + - st,click-thresh-{x,y,z}:  set the x/y/z axis threshold
  + - st,click-click-time-limit:click time limit, from 0 to 127.5msec
  + with step of 0.5 msec
  + - st,click-latency: click latency, from 0 to 255 msec with
  + step of 1 msec.
  + - st,click-window:  click window, from 0 to 255 msec with
  + step of 1 msec.
  + - st,irq{1,2}-disable:  disable IRQ 1/2
  + - st,irq{1,2}-ff-wu-1:  raise IRQ 1/2 on FF_WU_1 condition
  + - st,irq{1,2}-ff-wu-2:  raise IRQ 1/2 on FF_WU_2 condition
  + - st,irq{1,2}-data-ready:   raise IRQ 1/2 on data ready contition
  + - st,irq{1,2}-click:raise IRQ 1/2 on click condition
  + - st,irq-open-drain:consider IRQ lines open-drain
  + - st,irq-active-low:make IRQ lines active low
  + - st,wu-duration-1: duration register for Free-Fall/Wake-Up
  + interrupt 1
  + - st,wu-duration-2: duration register for Free-Fall/Wake-Up
  + interrupt 2
  + - st,wakeup-{x,y,z}-{lo,hi}:set wakeup condition on x/y/z axis for
  + upper/lower limit
  + - st,highpass-cutoff-hz=:   1, 2, 4 or 8 for 1Hz, 2Hz, 4Hz or 8Hz of
  + highpass cut-off frequency
  + - st,hipass{1,2}-disable:   disable highpass 1/2.
  + - st,default-rate=: set the default rate
  + - st,axis-{x,y,z}=: set the axis to map to the three 
  coordinates
  
  Some more parameters missing, what about st_min_limits and st_max_limits
  required for selftest.
 
 Right. Added them now.
 
  +
  +
  +Example for a SPI device node:
  +
  + lis302@0 {
  + compatible = st,lis302dl-spi;
  + reg = 0;
  + spi-max-frequency = 100;
  + interrupt-parent = gpio;
  + interrupts = 104 0;
  +
  + st,click-single-x;
  + st,click-single-y;
  + st,click-single-z;
  + st,click-thresh-x = 10;
  + st,click-thresh-y = 10;
  + st,click-thresh-z = 10;
  + st,irq1-click;
  + st,irq2-click;
  + st,wakeup-x-lo;
  + st,wakeup-x-hi;
  + st,wakeup-y-lo;
  + st,wakeup-y-hi;
  + st,wakeup-z-lo;
  + st,wakeup-z-hi;
  + };
  
  Why can't we add these flags in driver itself like below?
  Is these parameters varies from SoC to SoC or accelerometer
  - to - accelerometer?
 
 I don't understand, sorry. The point here is that the driver that is
 probed for device initialization are the PCI/I2C/SPI drivers. The

Look

RE: [PATCH v3 1/2] lis3: add generic DT matching code

On Sun, Aug 05, 2012 at 21:48:42, Daniel Mack wrote:
> Ping, anyone?
> 
> On 30.07.2012 09:36, Daniel Mack wrote:
> > This patch adds logic to parse lis3 properties from a device tree node
> > and store them in a freshly allocated lis3lv02d_platform_data.
> > 
> > Note that the actual match tables are left out here. This part should
> > happen in the drivers that bind to the individual busses (SPI/I2C/PCI).
> > 
> > Also adds some DT bindinds documentation.
> > 
> > Signed-off-by: Daniel Mack 
> > ---
> > Changes from v2:
> >  - kzalloc braino
> > 
> > Changes from v1:
> >  - some typos in properties fixed
> > 
> > 
> >  Documentation/devicetree/bindings/misc/lis302.txt |  74 
> >  drivers/misc/lis3lv02d/lis3lv02d.c| 137 
> > ++
> >  drivers/misc/lis3lv02d/lis3lv02d.h|   4 +
> >  3 files changed, 215 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/misc/lis302.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/misc/lis302.txt 
> > b/Documentation/devicetree/bindings/misc/lis302.txt
> > new file mode 100644
> > index 000..66230fd
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/misc/lis302.txt
> > @@ -0,0 +1,74 @@
> > +LIS302 accelerometer devicetree bindings
> > +
> > +This device is matched via its bus drivers, and has a number of properties
> > +that apply in on the generic device (independent from the bus).
> > +
> > +
> > +Required properties for the SPI bindings:
> > + - compatible: should be set to "st,lis3lv02d_spi"
> > + - reg:the chipselect index
> > + - spi-max-frequency:  maximal bus speed, should be set to 100 
> > unless
> > +   constrained by external circuitry
> > + - interrupts: the interrupt generated by the device
> > +
> > +
> > +Optional properties for all bus drivers:
> > +
> > + - st,click-single-{x,y,z}:if present, tells the device to issue an
> > +   interrupt on single click events on the
> > +   x/y/z axis.
> > + - st,click-double-{x,y,z}:if present, tells the device to issue an
> > +   interrupt on double click events on the
> > +   x/y/z axis.
> > + - st,click-thresh-{x,y,z}:set the x/y/z axis threshold
> > + - st,click-click-time-limit:  click time limit, from 0 to 127.5msec
> > +   with step of 0.5 msec
> > + - st,click-latency:   click latency, from 0 to 255 msec with
> > +   step of 1 msec.
> > + - st,click-window:click window, from 0 to 255 msec with
> > +   step of 1 msec.
> > + - st,irq{1,2}-disable:disable IRQ 1/2
> > + - st,irq{1,2}-ff-wu-1:raise IRQ 1/2 on FF_WU_1 condition
> > + - st,irq{1,2}-ff-wu-2:raise IRQ 1/2 on FF_WU_2 condition
> > + - st,irq{1,2}-data-ready: raise IRQ 1/2 on data ready contition
> > + - st,irq{1,2}-click:  raise IRQ 1/2 on click condition
> > + - st,irq-open-drain:  consider IRQ lines open-drain
> > + - st,irq-active-low:  make IRQ lines active low
> > + - st,wu-duration-1:   duration register for Free-Fall/Wake-Up
> > +   interrupt 1
> > + - st,wu-duration-2:   duration register for Free-Fall/Wake-Up
> > +   interrupt 2
> > + - st,wakeup-{x,y,z}-{lo,hi}:  set wakeup condition on x/y/z axis for
> > +   upper/lower limit
> > + - st,highpass-cutoff-hz=: 1, 2, 4 or 8 for 1Hz, 2Hz, 4Hz or 8Hz of
> > +   highpass cut-off frequency
> > + - st,hipass{1,2}-disable: disable highpass 1/2.
> > + - st,default-rate=:   set the default rate
> > + - st,axis-{x,y,z}=:   set the axis to map to the three 
> > coordinates

Some more parameters missing, what about st_min_limits and st_max_limits
required for selftest.

> > +
> > +
> > +Example for a SPI device node:
> > +
> > +   lis302@0 {
> > +   compatible = "st,lis302dl-spi";
> > +   reg = <0>;
> > +   spi-max-frequency = <100>;
> > +   interrupt-parent = <>;
> > +   interrupts = <104 0>;
> > +
> > +   st,click-single-x;
> > +   st,click-single-y;
> > +   st,click-single-z;
> > +   st,click-thresh-x = <10>;
> > +   st,click-thresh-y = <10>;
> > +   st,click-thresh-z = <10>;
> > +   st,irq1-click;
> > +   st,irq2-click;
> > +   st,wakeup-x-lo;
> > +   st,wakeup-x-hi;
> > +   st,wakeup-y-lo;
> > +   st,wakeup-y-hi;
> > +   st,wakeup-z-lo;
> > +   st,wakeup-z-hi;
> > +   };

Why can't we add these flags in driver itself like below?
Is these parameters varies from SoC to SoC or accelerometer
- to - accelerometer?

#ifdef CONFIG_OF
static struct

RE: linux-next: Tree for July 17 (mfd/tps65217.c)

On Fri, Aug 03, 2012 at 22:58:01, Randy Dunlap wrote:
> On 07/17/2012 02:48 PM, Randy Dunlap wrote:
> 
> > On 07/16/2012 10:41 PM, Stephen Rothwell wrote:
> > 
> >> Hi all,
> >>
> >> Changes since 20120716:
> >>
> > 
> > 
> > on i386:
> > 
> > drivers/built-in.o: In function `tps65217_probe':
> > tps65217.c:(.devinit.text+0x13e37): undefined reference to 
> > `of_regulator_match'
> > 
> > 
> > Full randconfig file is attached.
> > CONFIG_REGULATOR is not enabled.
> > 
> 
> 
> This build error is still present in linux-next of 20120803.
> 

This will be fixed with this patch
https://patchwork.kernel.org/patch/1220151/

Today, I will submit v2 for this

Regards
AnilKumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: linux-next: Tree for July 17 (mfd/tps65217.c)

On Fri, Aug 03, 2012 at 22:58:01, Randy Dunlap wrote:
 On 07/17/2012 02:48 PM, Randy Dunlap wrote:
 
  On 07/16/2012 10:41 PM, Stephen Rothwell wrote:
  
  Hi all,
 
  Changes since 20120716:
 
  
  
  on i386:
  
  drivers/built-in.o: In function `tps65217_probe':
  tps65217.c:(.devinit.text+0x13e37): undefined reference to 
  `of_regulator_match'
  
  
  Full randconfig file is attached.
  CONFIG_REGULATOR is not enabled.
  
 
 
 This build error is still present in linux-next of 20120803.
 

This will be fixed with this patch
https://patchwork.kernel.org/patch/1220151/

Today, I will submit v2 for this

Regards
AnilKumar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v3 1/2] lis3: add generic DT matching code