| Message ID | 1408815064-5763-1-git-send-email-linus.walleij@linaro.org |
|---|---|
| State | New |
| Headers | show |
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
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
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
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
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
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
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
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 --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, },
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(+)