diff mbox

iio: st-sensors: add support for lis3lv02d accelerometer

Message ID 1408815064-5763-1-git-send-email-linus.walleij@linaro.org
State New
Headers show

Commit Message

Linus Walleij Aug. 23, 2014, 5:31 p.m. UTC
This adds support for the LIS3LV02 accelerometer found in the
ST Microelectronics Nomadik board series.

Cc: devicetree@vger.kernel.org
Cc: Denis CIOCCA <denis.ciocca@st.com>
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 .../devicetree/bindings/iio/st-sensors.txt         |  1 +
 drivers/iio/accel/st_accel.h                       |  1 +
 drivers/iio/accel/st_accel_core.c                  | 81 ++++++++++++++++++++++
 drivers/iio/accel/st_accel_i2c.c                   |  4 ++
 4 files changed, 87 insertions(+)

Comments

Jonathan Cameron Aug. 25, 2014, 4:19 p.m. UTC | #1
On 23/08/14 18:31, Linus Walleij wrote:
> This adds support for the LIS3LV02 accelerometer found in the
> ST Microelectronics Nomadik board series.
> 
> Cc: devicetree@vger.kernel.org
> Cc: Denis CIOCCA <denis.ciocca@st.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This is a little 'interesting', given the part is already supported by
drivers/misc/lis3lv02d*.c and already has bindings under there.
Documentation/devicetree/bindings/misc/lis302.txt
(some of these are interesting).

Do we think this is the right way to handle the alternative support
here?

Denis, if you have time, could you take a look at this addition to your
driver.

If anyone wants to look at what the misc driver supports that we still
don't have in the IIO driver then that would be great!

Jonathan

> ---
>  .../devicetree/bindings/iio/st-sensors.txt         |  1 +
>  drivers/iio/accel/st_accel.h                       |  1 +
>  drivers/iio/accel/st_accel_core.c                  | 81 ++++++++++++++++++++++
>  drivers/iio/accel/st_accel_i2c.c                   |  4 ++
>  4 files changed, 87 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/iio/st-sensors.txt b/Documentation/devicetree/bindings/iio/st-sensors.txt
> index a7a0a15913ad..d2aaca974531 100644
> --- a/Documentation/devicetree/bindings/iio/st-sensors.txt
> +++ b/Documentation/devicetree/bindings/iio/st-sensors.txt
> @@ -23,6 +23,7 @@ standard bindings from pinctrl/pinctrl-bindings.txt.
>  Valid compatible strings:
>  
>  Accelerometers:
> +- st,lis3lv02dl-accel
>  - st,lsm303dlh-accel
>  - st,lsm303dlhc-accel
>  - st,lis3dh-accel
> diff --git a/drivers/iio/accel/st_accel.h b/drivers/iio/accel/st_accel.h
> index c3877630b2e4..38a0e9932549 100644
> --- a/drivers/iio/accel/st_accel.h
> +++ b/drivers/iio/accel/st_accel.h
> @@ -14,6 +14,7 @@
>  #include <linux/types.h>
>  #include <linux/iio/common/st_sensors.h>
>  
> +#define LIS3LV02DL_ACCEL_DEV_NAME	"lis3lv02dl_accel"
>  #define LSM303DLHC_ACCEL_DEV_NAME	"lsm303dlhc_accel"
>  #define LIS3DH_ACCEL_DEV_NAME		"lis3dh"
>  #define LSM330D_ACCEL_DEV_NAME		"lsm330d_accel"
> diff --git a/drivers/iio/accel/st_accel_core.c b/drivers/iio/accel/st_accel_core.c
> index 087864854c61..d4dd05d0b24d 100644
> --- a/drivers/iio/accel/st_accel_core.c
> +++ b/drivers/iio/accel/st_accel_core.c
> @@ -129,6 +129,30 @@
>  #define ST_ACCEL_3_IG1_EN_MASK			0x08
>  #define ST_ACCEL_3_MULTIREAD_BIT		false
>  
> +/* CUSTOM VALUES FOR SENSOR 4 */
I wish now we'd nipped this naming convention in the bud and insisted
on naming after a relevant part. Oh well.

> +#define ST_ACCEL_4_WAI_EXP			0x3a
> +#define ST_ACCEL_4_ODR_ADDR			0x20
> +#define ST_ACCEL_4_ODR_MASK			0x30 /* DF1 and DF0 */
> +#define ST_ACCEL_4_ODR_AVL_40HZ_VAL		0x00
> +#define ST_ACCEL_4_ODR_AVL_160HZ_VAL		0x01
> +#define ST_ACCEL_4_ODR_AVL_640HZ_VAL		0x02
> +#define ST_ACCEL_4_ODR_AVL_2560HZ_VAL		0x03
> +#define ST_ACCEL_4_PW_ADDR			0x20
> +#define ST_ACCEL_4_PW_MASK			0xc0
> +#define ST_ACCEL_4_FS_ADDR			0x21
> +#define ST_ACCEL_4_FS_MASK			0x80
> +#define ST_ACCEL_4_FS_AVL_2_VAL			0X00
> +#define ST_ACCEL_4_FS_AVL_6_VAL			0X01
> +#define ST_ACCEL_4_FS_AVL_2_GAIN		IIO_G_TO_M_S_2(1024)
> +#define ST_ACCEL_4_FS_AVL_6_GAIN		IIO_G_TO_M_S_2(340)
> +#define ST_ACCEL_4_BDU_ADDR			0x21
> +#define ST_ACCEL_4_BDU_MASK			0x40
> +#define ST_ACCEL_4_DRDY_IRQ_ADDR		0x21
> +#define ST_ACCEL_4_DRDY_IRQ_INT1_MASK		0x04
> +#define ST_ACCEL_4_IG1_EN_ADDR			0x21
> +#define ST_ACCEL_4_IG1_EN_MASK			0x08
> +#define ST_ACCEL_4_MULTIREAD_BIT		true
> +
>  static const struct iio_chan_spec st_accel_12bit_channels[] = {
>  	ST_SENSORS_LSM_CHANNELS(IIO_ACCEL,
>  			BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
> @@ -373,6 +397,63 @@ static const struct st_sensors st_accel_sensors[] = {
>  		.multi_read_bit = ST_ACCEL_3_MULTIREAD_BIT,
>  		.bootime = 2,
>  	},
> +	{
> +		.wai = ST_ACCEL_4_WAI_EXP,
> +		.sensors_supported = {
> +			[0] = LIS3LV02DL_ACCEL_DEV_NAME,
> +		},
> +		.ch = (struct iio_chan_spec *)st_accel_12bit_channels,
> +		.odr = {
> +			.addr = ST_ACCEL_4_ODR_ADDR,
> +			.mask = ST_ACCEL_4_ODR_MASK,
> +			.odr_avl = {
> +				{ 40, ST_ACCEL_4_ODR_AVL_40HZ_VAL },
> +				{ 160, ST_ACCEL_4_ODR_AVL_160HZ_VAL, },
> +				{ 640, ST_ACCEL_4_ODR_AVL_640HZ_VAL, },
> +				{ 2560, ST_ACCEL_4_ODR_AVL_2560HZ_VAL, },
> +			},
> +		},
> +		.pw = {
> +			.addr = ST_ACCEL_4_PW_ADDR,
> +			.mask = ST_ACCEL_4_PW_MASK,
> +			.value_on = ST_SENSORS_DEFAULT_POWER_ON_VALUE,
> +			.value_off = ST_SENSORS_DEFAULT_POWER_OFF_VALUE,
> +		},
> +		.enable_axis = {
> +			.addr = ST_SENSORS_DEFAULT_AXIS_ADDR,
> +			.mask = ST_SENSORS_DEFAULT_AXIS_MASK,
> +		},
> +		.fs = {
> +			.addr = ST_ACCEL_4_FS_ADDR,
> +			.mask = ST_ACCEL_4_FS_MASK,
> +			.fs_avl = {
> +				[0] = {
> +					.num = ST_ACCEL_FS_AVL_2G,
> +					.value = ST_ACCEL_4_FS_AVL_2_VAL,
> +					.gain = ST_ACCEL_4_FS_AVL_2_GAIN,
> +				},
> +				[1] = {
> +					.num = ST_ACCEL_FS_AVL_6G,
> +					.value = ST_ACCEL_4_FS_AVL_6_VAL,
> +					.gain = ST_ACCEL_4_FS_AVL_6_GAIN,
> +				},
> +			},
> +		},
> +		.bdu = {
> +			.addr = ST_ACCEL_4_BDU_ADDR,
> +			.mask = ST_ACCEL_4_BDU_MASK,
> +		},
> +		.drdy_irq = {
> +			.addr = ST_ACCEL_4_DRDY_IRQ_ADDR,
> +			.mask_int1 = ST_ACCEL_4_DRDY_IRQ_INT1_MASK,
> +			.ig1 = {
> +				.en_addr = ST_ACCEL_4_IG1_EN_ADDR,
> +				.en_mask = ST_ACCEL_4_IG1_EN_MASK,
> +			},
> +		},
> +		.multi_read_bit = ST_ACCEL_4_MULTIREAD_BIT,
> +		.bootime = 2, /* guess */
> +	},
>  };
>  
>  static int st_accel_read_raw(struct iio_dev *indio_dev,
> diff --git a/drivers/iio/accel/st_accel_i2c.c b/drivers/iio/accel/st_accel_i2c.c
> index 7164aeff3ab1..146ebce50509 100644
> --- a/drivers/iio/accel/st_accel_i2c.c
> +++ b/drivers/iio/accel/st_accel_i2c.c
> @@ -21,6 +21,10 @@
>  #ifdef CONFIG_OF
>  static const struct of_device_id st_accel_of_match[] = {
>  	{
> +		.compatible = "st,lis3lv02dl-accel",
This one is going to be interesting... There are existing
bindings fo rhte same part in drivers/misc/lis3lv02d_i2c.c


> +		.data = LIS3LV02DL_ACCEL_DEV_NAME,
> +	},
> +	{
>  		.compatible = "st,lsm303dlh-accel",
>  		.data = LSM303DLH_ACCEL_DEV_NAME,
>  	},
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Linus Walleij Aug. 27, 2014, 1:38 p.m. UTC | #2
On Mon, Aug 25, 2014 at 6:19 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> On 23/08/14 18:31, Linus Walleij wrote:
>> This adds support for the LIS3LV02 accelerometer found in the
>> ST Microelectronics Nomadik board series.
>>
>> Cc: devicetree@vger.kernel.org
>> Cc: Denis CIOCCA <denis.ciocca@st.com>
>> Cc: Lee Jones <lee.jones@linaro.org>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>
> This is a little 'interesting', given the part is already supported by
> drivers/misc/lis3lv02d*.c and already has bindings under there.
> Documentation/devicetree/bindings/misc/lis302.txt
> (some of these are interesting).

Grrr how come I missed this... It was originally merged as a
hwmon driver.


>> +/* CUSTOM VALUES FOR SENSOR 4 */
>>
> I wish now we'd nipped this naming convention in the bud and insisted
> on naming after a relevant part. Oh well.

Well we can always make an invasive patch fixing that. I can
probably do it using sed or something.

> Do we think this is the right way to handle the alternative support
> here?

Well this patch is a driver using the IIO framework and was written
by ST, but the other driver support a few other interesting features
and seems to be for the laptop usecase.

Adding the other authors to the TO: line...

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Denis CIOCCA Sept. 10, 2014, 12:59 p.m. UTC | #3
Ciao guys,

I'm sorry but I was in business trip. I think that current lis3lv02d 
supports more things, I want to support everything in the current IIO 
drivers but always I have no time.

BR,
Denis


On 08/27/14 15:38, Linus Walleij wrote:
> On Mon, Aug 25, 2014 at 6:19 PM, Jonathan Cameron <jic23@kernel.org> wrote:

>> On 23/08/14 18:31, Linus Walleij wrote:

>>> This adds support for the LIS3LV02 accelerometer found in the

>>> ST Microelectronics Nomadik board series.

>>>

>>> Cc: devicetree@vger.kernel.org

>>> Cc: Denis CIOCCA <denis.ciocca@st.com>

>>> Cc: Lee Jones <lee.jones@linaro.org>

>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

>> This is a little 'interesting', given the part is already supported by

>> drivers/misc/lis3lv02d*.c and already has bindings under there.

>> Documentation/devicetree/bindings/misc/lis302.txt

>> (some of these are interesting).

> Grrr how come I missed this... It was originally merged as a

> hwmon driver.

>

>

>>> +/* CUSTOM VALUES FOR SENSOR 4 */

>>>

>> I wish now we'd nipped this naming convention in the bud and insisted

>> on naming after a relevant part. Oh well.

> Well we can always make an invasive patch fixing that. I can

> probably do it using sed or something.

>

>> Do we think this is the right way to handle the alternative support

>> here?

> Well this patch is a driver using the IIO framework and was written

> by ST, but the other driver support a few other interesting features

> and seems to be for the laptop usecase.

>

> Adding the other authors to the TO: line...

>

> Yours,

> Linus Walleij
Pavel Machek Sept. 10, 2014, 1:36 p.m. UTC | #4
Hi!

> I'm sorry but I was in business trip. I think that current lis3lv02d 
> supports more things, I want to support everything in the current IIO 
> drivers but always I have no time.

Ok then, can you add hwmon interfaces from the other driver to your one? That way,
we can deprecate one of them...

									Pavel

> 
> BR,
> Denis
> 
> 
> On 08/27/14 15:38, Linus Walleij wrote:
> > On Mon, Aug 25, 2014 at 6:19 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> >> On 23/08/14 18:31, Linus Walleij wrote:
> >>> This adds support for the LIS3LV02 accelerometer found in the
> >>> ST Microelectronics Nomadik board series.
> >>>
> >>> Cc: devicetree@vger.kernel.org
> >>> Cc: Denis CIOCCA <denis.ciocca@st.com>
> >>> Cc: Lee Jones <lee.jones@linaro.org>
> >>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> >> This is a little 'interesting', given the part is already supported by
> >> drivers/misc/lis3lv02d*.c and already has bindings under there.
> >> Documentation/devicetree/bindings/misc/lis302.txt
> >> (some of these are interesting).
> > Grrr how come I missed this... It was originally merged as a
> > hwmon driver.
> >
> >
> >>> +/* CUSTOM VALUES FOR SENSOR 4 */
> >>>
> >> I wish now we'd nipped this naming convention in the bud and insisted
> >> on naming after a relevant part. Oh well.
> > Well we can always make an invasive patch fixing that. I can
> > probably do it using sed or something.
> >
> >> Do we think this is the right way to handle the alternative support
> >> here?
> > Well this patch is a driver using the IIO framework and was written
> > by ST, but the other driver support a few other interesting features
> > and seems to be for the laptop usecase.
> >
> > Adding the other authors to the TO: line...
> >
> > Yours,
> > Linus Walleij
Denis CIOCCA Sept. 11, 2014, 8:38 a.m. UTC | #5
When I have time yes for sure...:D

Denis

On 09/10/14 15:36, Pavel Machek wrote:
> Hi!
>
>> I'm sorry but I was in business trip. I think that current lis3lv02d
>> supports more things, I want to support everything in the current IIO
>> drivers but always I have no time.
> Ok then, can you add hwmon interfaces from the other driver to your one? That way,
> we can deprecate one of them...
>
> 									Pavel
>
>> BR,
>> Denis
>>
>>
>> On 08/27/14 15:38, Linus Walleij wrote:
>>> On Mon, Aug 25, 2014 at 6:19 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>>>> On 23/08/14 18:31, Linus Walleij wrote:
>>>>> This adds support for the LIS3LV02 accelerometer found in the
>>>>> ST Microelectronics Nomadik board series.
>>>>>
>>>>> Cc: devicetree@vger.kernel.org
>>>>> Cc: Denis CIOCCA <denis.ciocca@st.com>
>>>>> Cc: Lee Jones <lee.jones@linaro.org>
>>>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>>>> This is a little 'interesting', given the part is already supported by
>>>> drivers/misc/lis3lv02d*.c and already has bindings under there.
>>>> Documentation/devicetree/bindings/misc/lis302.txt
>>>> (some of these are interesting).
>>> Grrr how come I missed this... It was originally merged as a
>>> hwmon driver.
>>>
>>>
>>>>> +/* CUSTOM VALUES FOR SENSOR 4 */
>>>>>
>>>> I wish now we'd nipped this naming convention in the bud and insisted
>>>> on naming after a relevant part. Oh well.
>>> Well we can always make an invasive patch fixing that. I can
>>> probably do it using sed or something.
>>>
>>>> Do we think this is the right way to handle the alternative support
>>>> here?
>>> Well this patch is a driver using the IIO framework and was written
>>> by ST, but the other driver support a few other interesting features
>>> and seems to be for the laptop usecase.
>>>
>>> Adding the other authors to the TO: line...
>>>
>>> Yours,
>>> Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Linus Walleij Sept. 11, 2014, 9:13 a.m. UTC | #6
On Mon, Aug 25, 2014 at 6:19 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> On 23/08/14 18:31, Linus Walleij wrote:
>> This adds support for the LIS3LV02 accelerometer found in the
>> ST Microelectronics Nomadik board series.
>>
>> Cc: devicetree@vger.kernel.org
>> Cc: Denis CIOCCA <denis.ciocca@st.com>
>> Cc: Lee Jones <lee.jones@linaro.org>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>
> If anyone wants to look at what the misc driver supports that we still
> don't have in the IIO driver then that would be great!

I had a quick look at it:

- The misc driver has a bridge that optionally registers the
  accelerometer as a joystick in the input subsystem, so it
  can be used as a polled joystick. That looks like something
  we would want to be able to do for any accelerometer in a
  generic glue file in IIO I think?

- Ability to generate a "free-fall event" on a misc device
  if the device containing the sensor is dropped. A special
  interrupt can be enabled on the device for this. I can't quite
  see how userspace is supposed to react to it, because this
  miscdevice userspace ABI is sort of complex.

- Some driver-specific sysfs power management stuff

- Context save/restore registers for power-off handling.

- Trigger selftest from sysfs : I suspect this could be ported
  over to all the ST Micro devices, as they are similar in that
  way, same kind of test registers.

- Possible to enable high-pass filter from the DT config.
  (Should that not be dynamic?)

Apart from that it has a custom sysfs interface to read the
accelerometer, similar to the IIO interface. It seems to *only* support
raw values AFAICT  though, not sensitivity adjustment, so my patch
gives the ability to have better sensor handling in the kernel from an
IIO point of view.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jonathan Cameron Sept. 11, 2014, 4:39 p.m. UTC | #7
On September 11, 2014 10:13:24 AM GMT+01:00, Linus Walleij <linus.walleij@linaro.org> wrote:
>On Mon, Aug 25, 2014 at 6:19 PM, Jonathan Cameron <jic23@kernel.org>
>wrote:
>> On 23/08/14 18:31, Linus Walleij wrote:
>>> This adds support for the LIS3LV02 accelerometer found in the
>>> ST Microelectronics Nomadik board series.
>>>
>>> Cc: devicetree@vger.kernel.org
>>> Cc: Denis CIOCCA <denis.ciocca@st.com>
>>> Cc: Lee Jones <lee.jones@linaro.org>
>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>>
>> If anyone wants to look at what the misc driver supports that we
>still
>> don't have in the IIO driver then that would be great!
>
>I had a quick look at it:
>
>- The misc driver has a bridge that optionally registers the
>  accelerometer as a joystick in the input subsystem, so it
>  can be used as a polled joystick. That looks like something
>  we would want to be able to do for any accelerometer in a
>  generic glue file in IIO I think?

That is what we had iio-input for but it has languished unloved for quite a while.  Always too many other things to do!

Nasty bit in there is how to do bindings for it.  No one really likes the existing ones for iio client drivers.

Note it is more general than just accelerometers as all sorts of other devices
 are useful for human input.  At some point we need to figure out how to represent
 analog sensors connected to a generic ADC.
>
>- Ability to generate a "free-fall event" on a misc device
>  if the device containing the sensor is dropped. A special
>  interrupt can be enabled on the device for this. I can't quite
>  see how userspace is supposed to react to it, because this
>  miscdevice userspace ABI is sort of complex.
Long ago we had a discussion about how to handle this. I think the conclusion was we just needed a standard abi that any driver
 could use to notify user space if any sensor told the machine it was in free fall.  /Dev/freefall perhaps with simple poll /select support?

Can do this with iio events but perhaps a separate system would be lighter weight?  
Interesting trick would be to do a software filter for this for devices without hardware support.
>
>- Some driver-specific sysfs power management stuff
>
>- Context save/restore registers for power-off handling.
>
>- Trigger selftest from sysfs : I suspect this could be ported
>  over to all the ST Micro devices, as they are similar in that
>  way, same kind of test registers.
>
>- Possible to enable high-pass filter from the DT config.
>  (Should that not be dynamic?)
Probably. 
>
>Apart from that it has a custom sysfs interface to read the
>accelerometer, similar to the IIO interface. It seems to *only* support
>raw values AFAICT  though, not sensitivity adjustment, so my patch
>gives the ability to have better sensor handling in the kernel from an
>IIO point of view.
>
I likewise looked at this long ago (came out roughly concurrently with the similar lis3l02dq driver) came to roughly the same conclusion.
>Yours,
>Linus Walleij
Linus Walleij Oct. 31, 2014, 8:53 p.m. UTC | #8
On Thu, Sep 11, 2014 at 6:39 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> On September 11, 2014 10:13:24 AM GMT+01:00, Linus Walleij <linus.walleij@linaro.org> wrote:

>>Apart from that it has a custom sysfs interface to read the
>>accelerometer, similar to the IIO interface. It seems to *only* support
>>raw values AFAICT  though, not sensitivity adjustment, so my patch
>>gives the ability to have better sensor handling in the kernel from an
>>IIO point of view.
>>
> I likewise looked at this long ago (came out roughly concurrently
> with the similar lis3l02dq driver) came to roughly the same conclusion.

So Jonathan what do you say, should we simply merge this patch?

It will be two drivers in the kernel for the same hardware but one
of them is modern and uses IIO.

The misc driver maintainers doesn't seem to be moving anywhere
near IIO on its own whereas this patch establishes a base for
moving features over to generic IIO whenever someone finds the
time.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/iio/st-sensors.txt b/Documentation/devicetree/bindings/iio/st-sensors.txt
index a7a0a15913ad..d2aaca974531 100644
--- a/Documentation/devicetree/bindings/iio/st-sensors.txt
+++ b/Documentation/devicetree/bindings/iio/st-sensors.txt
@@ -23,6 +23,7 @@  standard bindings from pinctrl/pinctrl-bindings.txt.
 Valid compatible strings:
 
 Accelerometers:
+- st,lis3lv02dl-accel
 - st,lsm303dlh-accel
 - st,lsm303dlhc-accel
 - st,lis3dh-accel
diff --git a/drivers/iio/accel/st_accel.h b/drivers/iio/accel/st_accel.h
index c3877630b2e4..38a0e9932549 100644
--- a/drivers/iio/accel/st_accel.h
+++ b/drivers/iio/accel/st_accel.h
@@ -14,6 +14,7 @@ 
 #include <linux/types.h>
 #include <linux/iio/common/st_sensors.h>
 
+#define LIS3LV02DL_ACCEL_DEV_NAME	"lis3lv02dl_accel"
 #define LSM303DLHC_ACCEL_DEV_NAME	"lsm303dlhc_accel"
 #define LIS3DH_ACCEL_DEV_NAME		"lis3dh"
 #define LSM330D_ACCEL_DEV_NAME		"lsm330d_accel"
diff --git a/drivers/iio/accel/st_accel_core.c b/drivers/iio/accel/st_accel_core.c
index 087864854c61..d4dd05d0b24d 100644
--- a/drivers/iio/accel/st_accel_core.c
+++ b/drivers/iio/accel/st_accel_core.c
@@ -129,6 +129,30 @@ 
 #define ST_ACCEL_3_IG1_EN_MASK			0x08
 #define ST_ACCEL_3_MULTIREAD_BIT		false
 
+/* CUSTOM VALUES FOR SENSOR 4 */
+#define ST_ACCEL_4_WAI_EXP			0x3a
+#define ST_ACCEL_4_ODR_ADDR			0x20
+#define ST_ACCEL_4_ODR_MASK			0x30 /* DF1 and DF0 */
+#define ST_ACCEL_4_ODR_AVL_40HZ_VAL		0x00
+#define ST_ACCEL_4_ODR_AVL_160HZ_VAL		0x01
+#define ST_ACCEL_4_ODR_AVL_640HZ_VAL		0x02
+#define ST_ACCEL_4_ODR_AVL_2560HZ_VAL		0x03
+#define ST_ACCEL_4_PW_ADDR			0x20
+#define ST_ACCEL_4_PW_MASK			0xc0
+#define ST_ACCEL_4_FS_ADDR			0x21
+#define ST_ACCEL_4_FS_MASK			0x80
+#define ST_ACCEL_4_FS_AVL_2_VAL			0X00
+#define ST_ACCEL_4_FS_AVL_6_VAL			0X01
+#define ST_ACCEL_4_FS_AVL_2_GAIN		IIO_G_TO_M_S_2(1024)
+#define ST_ACCEL_4_FS_AVL_6_GAIN		IIO_G_TO_M_S_2(340)
+#define ST_ACCEL_4_BDU_ADDR			0x21
+#define ST_ACCEL_4_BDU_MASK			0x40
+#define ST_ACCEL_4_DRDY_IRQ_ADDR		0x21
+#define ST_ACCEL_4_DRDY_IRQ_INT1_MASK		0x04
+#define ST_ACCEL_4_IG1_EN_ADDR			0x21
+#define ST_ACCEL_4_IG1_EN_MASK			0x08
+#define ST_ACCEL_4_MULTIREAD_BIT		true
+
 static const struct iio_chan_spec st_accel_12bit_channels[] = {
 	ST_SENSORS_LSM_CHANNELS(IIO_ACCEL,
 			BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
@@ -373,6 +397,63 @@  static const struct st_sensors st_accel_sensors[] = {
 		.multi_read_bit = ST_ACCEL_3_MULTIREAD_BIT,
 		.bootime = 2,
 	},
+	{
+		.wai = ST_ACCEL_4_WAI_EXP,
+		.sensors_supported = {
+			[0] = LIS3LV02DL_ACCEL_DEV_NAME,
+		},
+		.ch = (struct iio_chan_spec *)st_accel_12bit_channels,
+		.odr = {
+			.addr = ST_ACCEL_4_ODR_ADDR,
+			.mask = ST_ACCEL_4_ODR_MASK,
+			.odr_avl = {
+				{ 40, ST_ACCEL_4_ODR_AVL_40HZ_VAL },
+				{ 160, ST_ACCEL_4_ODR_AVL_160HZ_VAL, },
+				{ 640, ST_ACCEL_4_ODR_AVL_640HZ_VAL, },
+				{ 2560, ST_ACCEL_4_ODR_AVL_2560HZ_VAL, },
+			},
+		},
+		.pw = {
+			.addr = ST_ACCEL_4_PW_ADDR,
+			.mask = ST_ACCEL_4_PW_MASK,
+			.value_on = ST_SENSORS_DEFAULT_POWER_ON_VALUE,
+			.value_off = ST_SENSORS_DEFAULT_POWER_OFF_VALUE,
+		},
+		.enable_axis = {
+			.addr = ST_SENSORS_DEFAULT_AXIS_ADDR,
+			.mask = ST_SENSORS_DEFAULT_AXIS_MASK,
+		},
+		.fs = {
+			.addr = ST_ACCEL_4_FS_ADDR,
+			.mask = ST_ACCEL_4_FS_MASK,
+			.fs_avl = {
+				[0] = {
+					.num = ST_ACCEL_FS_AVL_2G,
+					.value = ST_ACCEL_4_FS_AVL_2_VAL,
+					.gain = ST_ACCEL_4_FS_AVL_2_GAIN,
+				},
+				[1] = {
+					.num = ST_ACCEL_FS_AVL_6G,
+					.value = ST_ACCEL_4_FS_AVL_6_VAL,
+					.gain = ST_ACCEL_4_FS_AVL_6_GAIN,
+				},
+			},
+		},
+		.bdu = {
+			.addr = ST_ACCEL_4_BDU_ADDR,
+			.mask = ST_ACCEL_4_BDU_MASK,
+		},
+		.drdy_irq = {
+			.addr = ST_ACCEL_4_DRDY_IRQ_ADDR,
+			.mask_int1 = ST_ACCEL_4_DRDY_IRQ_INT1_MASK,
+			.ig1 = {
+				.en_addr = ST_ACCEL_4_IG1_EN_ADDR,
+				.en_mask = ST_ACCEL_4_IG1_EN_MASK,
+			},
+		},
+		.multi_read_bit = ST_ACCEL_4_MULTIREAD_BIT,
+		.bootime = 2, /* guess */
+	},
 };
 
 static int st_accel_read_raw(struct iio_dev *indio_dev,
diff --git a/drivers/iio/accel/st_accel_i2c.c b/drivers/iio/accel/st_accel_i2c.c
index 7164aeff3ab1..146ebce50509 100644
--- a/drivers/iio/accel/st_accel_i2c.c
+++ b/drivers/iio/accel/st_accel_i2c.c
@@ -21,6 +21,10 @@ 
 #ifdef CONFIG_OF
 static const struct of_device_id st_accel_of_match[] = {
 	{
+		.compatible = "st,lis3lv02dl-accel",
+		.data = LIS3LV02DL_ACCEL_DEV_NAME,
+	},
+	{
 		.compatible = "st,lsm303dlh-accel",
 		.data = LSM303DLH_ACCEL_DEV_NAME,
 	},