LIS331DLH accelerometer driver, IIO or not?

I'm working to enable the LIS331DLH accelerometer on the Fish River Island II embedded atom development kit.

http://www.st.com/internet/analog/product/218132.jsp

http://us.kontron.com/products/systems+and+platforms/m2m/m2m+smart+services+developer+kit.html

This device is attached to an i2c bus implemented in a CPLD (complex programmable logic device) integrated on the compute module. I found an IIO driver for the device written for 2.6.34. I've rewritten most of the driver to work with the 3.2 kernel's IIO subsystem (and had planned to next port it all the way to git HEAD and push it upstream).

However, I've since stumbled across a couple of things which cloud the issue for me.

First, Carmine Iascone submitted a driver (driver/misc, not iio) for the LIS331DLH back in Nov 2010.

http://lkml.org/lkml/2010/11/9/369

It was suggested that this driver be merged with the existing lis3lv02d driver which listed support for a similar chip in the header, LIS331DL, but it also lists LIS331DLF as not supported. The current git HEAD still does not list LIS331DLH, and there is not a compatible register map in the header.

Second, I came across the following TI document for porting the LIS331DLH driver for Android:

http://processors.wiki.ti.com/index.php/TI-Android-GingerBread-2.3.4-DevKit-2.1_PortingGuides

This references a lis331dlh.c driver which I do not find in Linus' git repository nor in linux-next.

So there are 3 ways I can go about this, and I'd appreciate any direction on which would be the most acceptable for merging upstream.

1) Continue with my IIO version. This subsystem seems well suited to the accelerometer. The iio_chan_spec simplifies the task of exposing the event capabilities of the device, which the drivers/misc/lis3lv02d driver mostly glosses over. It only supports events on free-fall for example, while with IIO it is straight forward to enable interrupts for rising and/or falling thresholds for each axis independently.

2) Attempt to merge Carmine's drivers/misc/lis331dlh driver with the existing lis3lv02d driver as suggested in the thread mentioned above. This driver isn't as fully functional.

3) Try and dig up the lis331dlh driver referenced in the TI document and work to get that upstream. Like option 2, this driver is not likely to be as configurable as the IIO driver.

I am more interested in enabling people to do bizarre and interesting things with the device, so I'm leaning toward continuing with my IIO implementation.

Quoted 53 lines

I'm working to enable the LIS331DLH accelerometer on the Fish River Island II embedded atom development kit.

http://www.st.com/internet/analog/product/218132.jsp

http://us.kontron.com/products/systems+and+platforms/m2m/m2m+smart+services+developer+kit.html

This device is attached to an i2c bus implemented in a CPLD (complex programmable logic device) integrated on the compute module. I found an IIO driver for the device written for 2.6.34. I've rewritten most of the driver to work with the 3.2 kernel's IIO subsystem (and had planned to next port it all the way to git HEAD and push it upstream).

However, I've since stumbled across a couple of things which cloud the issue for me.

First, Carmine Iascone submitted a driver (driver/misc, not iio) for the LIS331DLH back in Nov 2010.

http://lkml.org/lkml/2010/11/9/369

It was suggested that this driver be merged with the existing lis3lv02d driver which listed support for a similar chip in the header, LIS331DL, but it also lists LIS331DLF as not supported. The current git HEAD still does not list LIS331DLH, and there is not a compatible register map in the header.

Second, I came across the following TI document for porting the LIS331DLH driver for Android:

http://processors.wiki.ti.com/index.php/TI-Android-GingerBread-2.3.4-DevKit-2.1_PortingGuides

This references a lis331dlh.c driver which I do not find in Linus' git repository nor in linux-next.

So there are 3 ways I can go about this, and I'd appreciate any direction on which would be the most acceptable for merging upstream.

1) Continue with my IIO version. This subsystem seems well suited to the accelerometer. The iio_chan_spec simplifies the task of exposing the event capabilities of the device, which the drivers/misc/lis3lv02d driver mostly glosses over. It only supports events on free-fall for example, while with IIO it is straight forward to enable interrupts for rising and/or falling thresholds for each axis independently.

2) Attempt to merge Carmine's drivers/misc/lis331dlh driver with the existing lis3lv02d driver as suggested in the thread mentioned above. This driver isn't as fully functional.

3) Try and dig up the lis331dlh driver referenced in the TI document and work to get that upstream. Like option 2, this driver is not likely to be as configurable as the IIO driver.

Quoted 3 lines

I am more interested in enabling people to do bizarre and interesting things with the device, so I'm leaning toward continuing with my IIO implementation.

Make it an IIO driver and then we can delete the misc driver, which shouldn't have snuck in there in the first place :)

greg k-h

Added Dmitry to the cc to get input on input side of things.

Quoted 54 lines · Darren Hart

Quoted 53 lines

I'm working to enable the LIS331DLH accelerometer on the Fish River Island II embedded atom development kit.

http://www.st.com/internet/analog/product/218132.jsp

http://us.kontron.com/products/systems+and+platforms/m2m/m2m+smart+services+developer+kit.html

This device is attached to an i2c bus implemented in a CPLD (complex programmable logic device) integrated on the compute module. I found an IIO driver for the device written for 2.6.34. I've rewritten most of the driver to work with the 3.2 kernel's IIO subsystem (and had planned to next port it all the way to git HEAD and push it upstream).

However, I've since stumbled across a couple of things which cloud the issue for me.

First, Carmine Iascone submitted a driver (driver/misc, not iio) for the LIS331DLH back in Nov 2010.

http://lkml.org/lkml/2010/11/9/369

It was suggested that this driver be merged with the existing lis3lv02d driver which listed support for a similar chip in the header, LIS331DL, but it also lists LIS331DLF as not supported. The current git HEAD still does not list LIS331DLH, and there is not a compatible register map in the header.

Second, I came across the following TI document for porting the LIS331DLH driver for Android:

http://processors.wiki.ti.com/index.php/TI-Android-GingerBread-2.3.4-DevKit-2.1_PortingGuides

This references a lis331dlh.c driver which I do not find in Linus' git repository nor in linux-next.

So there are 3 ways I can go about this, and I'd appreciate any direction on which would be the most acceptable for merging upstream.

1) Continue with my IIO version. This subsystem seems well suited to the accelerometer. The iio_chan_spec simplifies the task of exposing the event capabilities of the device, which the drivers/misc/lis3lv02d driver mostly glosses over. It only supports events on free-fall for example, while with IIO it is straight forward to enable interrupts for rising and/or falling thresholds for each axis independently.

2) Attempt to merge Carmine's drivers/misc/lis331dlh driver with the existing lis3lv02d driver as suggested in the thread mentioned above. This driver isn't as fully functional.

3) Try and dig up the lis331dlh driver referenced in the TI document and work to get that upstream. Like option 2, this driver is not likely to be as configurable as the IIO driver.

Quoted 6 lines

Quoted 3 lines

I am more interested in enabling people to do bizarre and interesting things with the device, so I'm leaning toward continuing with my IIO implementation.

Make it an IIO driver and then we can delete the misc driver, which shouldn't have snuck in there in the first place :)

Agreed. That would be what I'd suggest long term,

refer to 'bizarre and interesting'. There are however some missing elements. Note that none of these should stop you writing an iio driver particularly as the current one doesn't support your part. If you fancy pulling my lis3l02dq driver in as well (not sure how close it is though ;) then feel free!

lis3lv02d driver provides (I'm sure people are more familiar with this than me, but it's helpful to lay it out).

/dev/freefall
joystick emulation through input. (looks like polled only? - guessing the rates for interrupt driven were too high for general use) Some x, y and z button inputs?
A couple of sysfs attributes we'd probably have to support in parallel to new ones for compatability reasons (for a few kernel cycles anyway).

The one bit that doesn't map well at the moment is the click stuff. I've been trying to avoid special purpose events like that by mapping everything to the underlying real motion (these might be rate of change of acceleration thresholds, but I doubt we'll find that in the data sheets!)

Also right now we have no in kernel interface for getting events - will require an extra layer and a demuxer similar (but simpler) to the buffer one. Note as well that the buffer based in kernel stuff is still under review (I'll try and get a rebased version out tomorrow).

So what are your bizarre and interesting then? (feel free not to answer, but comments like that make me curious ;)

Also any links to info on the fish river island II? Google is failing me and I'm curious ;)

Also, I'd almost have been inclinded to say this device should go in input, with a few 'additional' interfaces, but sounds like you want stuff input can't provide?

Quoted 8 lines · Jonathan Cameron

Added Dmitry to the cc to get input on input side of things.

Quoted 7 lines · Darren Hart

Quoted 6 lines

I'm working to enable the LIS331DLH accelerometer on the Fish River Island II embedded atom development kit.

http://www.st.com/internet/analog/product/218132.jsp

http://us.kontron.com/products/systems+and+platforms/m2m/m2m+smart+services+developer+kit.html

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

This device is attached to an i2c bus implemented in a CPLD

(complex

Quoted 1 line

Quoted 1 line

Quoted 1 line

programmable logic device) integrated on the compute module. I

found an

Quoted 1 line

Quoted 1 line

Quoted 1 line

IIO driver for the device written for 2.6.34. I've rewritten most

of the

Quoted 1 line

Quoted 1 line

Quoted 1 line

driver to work with the 3.2 kernel's IIO subsystem (and had planned

to

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

next port it all the way to git HEAD and push it upstream).

However, I've since stumbled across a couple of things which cloud

the

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

issue for me.

First, Carmine Iascone submitted a driver (driver/misc, not iio)

for the

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

LIS331DLH back in Nov 2010.

http://lkml.org/lkml/2010/11/9/369

It was suggested that this driver be merged with the existing

lis3lv02d

Quoted 1 line

Quoted 1 line

Quoted 1 line

driver which listed support for a similar chip in the header,

LIS331DL,

Quoted 1 line

Quoted 1 line

Quoted 1 line

but it also lists LIS331DLF as not supported. The current git HEAD

still

Quoted 1 line

Quoted 1 line

Quoted 1 line

does not list LIS331DLH, and there is not a compatible register map

in

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

the header.

Second, I came across the following TI document for porting the LIS331DLH driver for Android:

http://processors.wiki.ti.com/index.php/TI-Android-GingerBread-2.3.4-DevKit-2.1_PortingGuides

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

This references a lis331dlh.c driver which I do not find in Linus'

git

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

repository nor in linux-next.

So there are 3 ways I can go about this, and I'd appreciate any direction on which would be the most acceptable for merging

upstream.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

1) Continue with my IIO version. This subsystem seems well suited

to the

Quoted 1 line

Quoted 1 line

Quoted 1 line

accelerometer. The iio_chan_spec simplifies the task of exposing

the

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

event capabilities of the device, which the drivers/misc/lis3lv02d driver mostly glosses over. It only supports events on free-fall

for

Quoted 1 line

Quoted 1 line

Quoted 1 line

example, while with IIO it is straight forward to enable interrupts

for

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

rising and/or falling thresholds for each axis independently.

2) Attempt to merge Carmine's drivers/misc/lis331dlh driver with

the

Quoted 1 line

Quoted 1 line

Quoted 1 line

existing lis3lv02d driver as suggested in the thread mentioned

above.

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

This driver isn't as fully functional.

3) Try and dig up the lis331dlh driver referenced in the TI

document and

Quoted 1 line

Quoted 1 line

Quoted 1 line

work to get that upstream. Like option 2, this driver is not likely

to

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

be as configurable as the IIO driver.

I am more interested in enabling people to do bizarre and

interesting

Quoted 1 line

Quoted 1 line

Quoted 1 line

things with the device, so I'm leaning toward continuing with my

IIO

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

implementation.

Make it an IIO driver and then we can delete the misc driver, which shouldn't have snuck in there in the first place :)

Agreed. That would be what I'd suggest long term,

Sure, but you're biased ;-)

Joking aside, you and Greg made my day. I was afraid I had wasted several days grokking the 2.6.34 to 3.2 IIO subsystem changes!

particularly when you

Quoted 5 lines

refer to 'bizarre and interesting'. There are however some missing elements. Note that none of these should stop you writing an iio driver particularly as the current one doesn't support your part. If you fancy pulling my lis3l02dq driver in as well (not sure how close it is though ;) then feel free!

I think I am going to start with a very simple lis331dlh only driver which supports sysfs polling. I'm working on the interrupt and smbalert interface currently, but I need something very soon. It would be good to
get the simple stuff right and in tree so it doesn't bitrot as I work on
the rest. Although, with the IIO core now in-tree and out of staging, hopefully things have settled down some?

Quoted 3 lines

lis3lv02d driver provides (I'm sure people are more familiar with

this

Quoted 8 lines

than me, but it's helpful to lay it out).

/dev/freefall
joystick emulation through input. (looks like polled only? - guessing

the rates for interrupt driven were too high for general use) Some x, y and z button inputs?
A couple of sysfs attributes we'd probably have to support in

parallel

Quoted 1 line

to new ones for compatability reasons (for a few kernel cycles

anyway).

Quoted 6 lines

The one bit that doesn't map well at the moment is the click stuff. I've been trying to avoid special purpose events like that by mapping everything to the underlying real motion (these might be rate of change of acceleration thresholds, but I doubt we'll find that in the data sheets!)

The data sheets are rather sparse. I'm not sure what you mean by "rate of change of acceleration thresholds", but as the thresholds for this device are per-interrupt

(not axis nor direction) and only 6 bits
(while
the axis values are s16... I'm not sure what they are, and the datasheet
makes no attempt to clarify the issue.

Quoted 9 lines

Also right now we have no in kernel interface for getting events - will require an extra layer and a demuxer similar (but simpler) to the buffer one. Note as well that the buffer based in kernel stuff is still under review (I'll try and get a rebased version out tomorrow).

So what are your bizarre and interesting then? (feel free not to answer, but comments like that make me curious ;)

Intel gave away vouchers for FRI2 devices to several attendees to the 2012 ELC conference this year. We asked participants to do something cool and interesting with the device. I'm hoping some of them are more creative than I am! So the answer to your question is "I don't know", which is why I want to make it as configurable as possible to enable others to be bizarre and interesting :-)

Quoted 2 lines

Also any links to info on the fish river island II? Google is failing me and I'm curious ;)

Of course:
http://us.kontron.com/products/systems+and+platforms/m2m/m2m+smart+services+developer+kit.html

I'm developing the board support package for the Yocto Project for this device.

http://www.yoctoproject.org/

Quoted 4 lines

Also, I'd almost have been inclinded to say this device should go in input, with a few 'additional' interfaces, but sounds like you want stuff input can't provide?

I think bizarre and interesting things could certainly be done with the input system, but I'd prefer to expose the lower level features of the chip and not dictate how the chip is used. As you say, an input wrapper could be provided.

One of the things I'm struggling with right now are having two interrupt
lines. This device wires one to SMBALERT# and the other to a GPIO chip. I suppose this should be addressed using a custom platform_data struct

which I haven't implemented yet. My experimental i2c bus platform init code doesn't seem to work as expected... still working on that.

While I have you Jon, I've run into an issue with the iio_chan_spec sysfs interface. I mark the modified bit and set IIO_MOD_X in channel2 per the iio_chan_spec comments. But, iio_device_add_event_sysfs() ignores channel2 if chan->modified, so my event_code demuxer can't find the modifer and can't determine which axis I'm reading or writing event config for. I'm currently setting channel to IIO_MOD_X (or Y or Z) as a workaround, but I think I'm missing something.

The code is a bit of a mess right now as it is the result of my slowly rewriting it from a 2.6.34 version for 3.2 and fixing and enhancing as I
go. I will try to clean it up and get it out for an RFC soon as this is my first real driver, I'm sure your input would be helpful.

Signature · 4 lines

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Quoted 6 lines · Darren Hart

I'm working to enable the LIS331DLH accelerometer on the Fish River Island II embedded atom development kit.

I am more interested in enabling people to do bizarre and interesting things with the device, so I'm leaning toward continuing with my IIO implementation.

Make it an IIO driver and then we can delete the misc driver, which shouldn't have snuck in there in the first place :)

Quoted 3 lines

Make it an IIO driver and then we can delete the misc driver, which shouldn't have snuck in there in the first place :)

To be more fair to the misc driver, I wouldn't say it snucked in there, but more "it ended up there as the least worse place" ;-)

Quoted 6 lines

Quoted 3 lines

Make it an IIO driver and then we can delete the misc driver, which shouldn't have snuck in there in the first place :)

To be more fair to the misc driver, I wouldn't say it snucked in there, but more "it ended up there as the least worse place" ;-)

Because IIO spent forever in staging, as well as blocking lots of other driver work and meaning tons of drivers are now not to be found anywhere but obscure git trees. Thankfully they didn't manage to block the LIS driver during this mess.

Until all the needed support for the LIS IIO driver exists outside of staging the driver needs to stay where it is and without IIO dependancies. It is not acceptable to cripple existing working code with staging tree dependencies.

Hopefully commit a980e046098b0a40eaff5e4e7fcde6cf035b7c06 has finally set the basis for this happening when it hits mainline.

Quoted 11 lines · Greg Kroah-Hartman

Quoted 6 lines · Darren Hart

I'm working to enable the LIS331DLH accelerometer on the Fish River Island II embedded atom development kit.

I am more interested in enabling people to do bizarre and interesting things with the device, so I'm leaning toward continuing with my IIO implementation.

Make it an IIO driver and then we can delete the misc driver, which shouldn't have snuck in there in the first place :)

To be more fair to the misc driver, I wouldn't say it snucked in there, but more "it ended up there as the least worse place" ;-) Actually, the main problem is that there seemed to be no maintainer interested in taking care of accelerometer devices. Now that the IIO subsystem is out of staging, it might be a right place. That said, I don't know much about the user interface to IIO. I know that I liked the idea of having an joystick device created for an accelerometer because that allows to get many programs to access the device almost without any modifications.

I'd happy to help merge the lis3lv02d driver into IIO. IMHO, the main steps are:
* make sure all the various buses are supported (e.g., I²C, SPI, and
also "ACPI-HP")
* ensure the various versions of the accelerometer are supported (there
are 3 supported currently)
* check that the driver is automatically loaded on HP laptops (via ACPI
entry)
* for each of the current interfaces decide if they should be ported or
dropped (/dev/js*, /dev/freefall, sysfs...)

What do you think Jonathan?

Cheers,
Éric

Quoted 13 lines · Éric Piel

Quoted 11 lines · Greg Kroah-Hartman

Quoted 6 lines · Darren Hart

I'm working to enable the LIS331DLH accelerometer on the Fish River Island II embedded atom development kit.

I am more interested in enabling people to do bizarre and interesting things with the device, so I'm leaning toward continuing with my IIO implementation.

Make it an IIO driver and then we can delete the misc driver, which shouldn't have snuck in there in the first place :)

Quoted 8 lines

To be more fair to the misc driver, I wouldn't say it snucked in there, but more "it ended up there as the least worse place" ;-) Actually, the main problem is that there seemed to be no maintainer interested in taking care of accelerometer devices. Now that the IIO subsystem is out of staging, it might be a right place. That said, I don't know much about the user interface to IIO. I know that I liked the idea of having an joystick device created for an accelerometer because that allows to get many programs to access the device almost without any modifications.

I agree that this sort of device should have an input interface. Not sure if a joystick is the right option, but that's more one for Dmitry to comment on.

Quoted 12 lines

I'd happy to help merge the lis3lv02d driver into IIO. IMHO, the main steps are:
* make sure all the various buses are supported (e.g., I²C, SPI, and
also "ACPI-HP")
* ensure the various versions of the accelerometer are supported (there
are 3 supported currently)
* check that the driver is automatically loaded on HP laptops (via ACPI
entry)
* for each of the current interfaces decide if they should be ported or
dropped (/dev/js*, /dev/freefall, sysfs...)

Quoted 1 line

What do you think Jonathan?

You've laid it out extremely clearly. Thanks, I agree with these steps, though they may occur from a slightly different angle given Darren is interested in a part that is not (I believe) currently supported by
your existing driver. Hence he may initially want to do a separate
driver with that (keeping in mind the aim of mergining in the existing driver). I have an ancient driver for the lis3l02dq alone (in iio from the start) that will also get eaten up by Daren's new driver (and the ability to test on that part on spi). staging/iio/accel/lis3l02dq*.c

Quoted 38 lines · Jonathan Cameron

Quoted 13 lines · Éric Piel

Quoted 11 lines · Greg Kroah-Hartman

Quoted 6 lines · Darren Hart

I'm working to enable the LIS331DLH accelerometer on the Fish River Island II embedded atom development kit.

I am more interested in enabling people to do bizarre and interesting things with the device, so I'm leaning toward continuing with my IIO implementation.

Make it an IIO driver and then we can delete the misc driver, which shouldn't have snuck in there in the first place :)

Quoted 8 lines

To be more fair to the misc driver, I wouldn't say it snucked in there, but more "it ended up there as the least worse place" ;-) Actually, the main problem is that there seemed to be no maintainer interested in taking care of accelerometer devices. Now that the IIO subsystem is out of staging, it might be a right place. That said, I don't know much about the user interface to IIO. I know that I liked the idea of having an joystick device created for an accelerometer because that allows to get many programs to access the device almost without any modifications.

I agree that this sort of device should have an input interface. Not sure if a joystick is the right option, but that's more one for Dmitry to comment on.

Quoted 12 lines

I'd happy to help merge the lis3lv02d driver into IIO. IMHO, the main steps are:
* make sure all the various buses are supported (e.g., I²C, SPI, and
also "ACPI-HP")
* ensure the various versions of the accelerometer are supported (there
are 3 supported currently)
* check that the driver is automatically loaded on HP laptops (via ACPI
entry)
* for each of the current interfaces decide if they should be ported or
dropped (/dev/js*, /dev/freefall, sysfs...)

Quoted 1 line

What do you think Jonathan?

Quoted 9 lines

You've laid it out extremely clearly. Thanks, I agree with these steps, though they may occur from a slightly different angle given Darren is interested in a part that is not (I believe) currently supported by
your existing driver. Hence he may initially want to do a separate
driver with that (keeping in mind the aim of mergining in the existing driver). I have an ancient driver for the lis3l02dq alone (in iio from the start) that will also get eaten up by Daren's new driver (and the ability to test on that part on spi). staging/iio/accel/lis3l02dq*.c

I think I should start with getting the lis331dlh support completed, if for no other reason than to keep the scope manageable as I write my first real driver. From that I would like to merge in Jonathan's IIO lis3l02dq driver to get the multi-chip support part right. Then we should look at expanding the scope of the interface and finally merging with misc/lis3102dq. I believe that should meet with everyone's suggestions.

One thing I would like to understand better is what sort of interface does userspace current expect. Phone Gap, for example, provides a very high level interface to applications in m/s^2 for each axis. Is there some interface we should ensure all accelerometer driver's implement?

I suspect a /dev/accel interface that reads out xyz values in ms/s^2 would make sense. We would need to ensure that allows for polled as well as event driven. Thoughts?

Quoted 63 lines · Darren Hart

Quoted 38 lines · Jonathan Cameron

Quoted 13 lines · Éric Piel

Quoted 11 lines · Greg Kroah-Hartman

Quoted 6 lines · Darren Hart

I'm working to enable the LIS331DLH accelerometer on the Fish River Island II embedded atom development kit.

I am more interested in enabling people to do bizarre and interesting things with the device, so I'm leaning toward continuing with my IIO implementation.

Make it an IIO driver and then we can delete the misc driver, which shouldn't have snuck in there in the first place :)

Quoted 8 lines

To be more fair to the misc driver, I wouldn't say it snucked in there, but more "it ended up there as the least worse place" ;-) Actually, the main problem is that there seemed to be no maintainer interested in taking care of accelerometer devices. Now that the IIO subsystem is out of staging, it might be a right place. That said, I don't know much about the user interface to IIO. I know that I liked the idea of having an joystick device created for an accelerometer because that allows to get many programs to access the device almost without any modifications.

I agree that this sort of device should have an input interface. Not sure if a joystick is the right option, but that's more one for Dmitry to comment on.

Quoted 12 lines

I'd happy to help merge the lis3lv02d driver into IIO. IMHO, the main steps are:
* make sure all the various buses are supported (e.g., I²C, SPI, and
also "ACPI-HP")
* ensure the various versions of the accelerometer are supported (there
are 3 supported currently)
* check that the driver is automatically loaded on HP laptops (via ACPI
entry)
* for each of the current interfaces decide if they should be ported or
dropped (/dev/js*, /dev/freefall, sysfs...)

Quoted 1 line

What do you think Jonathan?

Quoted 9 lines

You've laid it out extremely clearly. Thanks, I agree with these steps, though they may occur from a slightly different angle given Darren is interested in a part that is not (I believe) currently supported by
your existing driver. Hence he may initially want to do a separate
driver with that (keeping in mind the aim of mergining in the existing driver). I have an ancient driver for the lis3l02dq alone (in iio from the start) that will also get eaten up by Daren's new driver (and the ability to test on that part on spi). staging/iio/accel/lis3l02dq*.c

I think I should start with getting the lis331dlh support completed, if for no other reason than to keep the scope manageable as I write my first real driver. From that I would like to merge in Jonathan's IIO lis3l02dq driver to get the multi-chip support part right. Then we should look at expanding the scope of the interface and finally merging with misc/lis3102dq. I believe that should meet with everyone's suggestions.

One thing I would like to understand better is what sort of interface does userspace current expect. Phone Gap, for example, provides a very high level interface to applications in m/s^2 for each axis. Is there some interface we should ensure all accelerometer driver's implement?

Quoted 3 lines

I suspect a /dev/accel interface that reads out xyz values in ms/s^2 would make sense. We would need to ensure that allows for polled as well as event driven. Thoughts?

Immediate comment is don't call it /dev/accel. That's just taken out using it for all the combined gyro/ accel units out there.

Also doing scaling in kernel is expensive, fiddly and inefficient (no floating point - and lots of users don't actually care about absolute scale).

Then we get the question of what this gains us over existing options (input or /dev/iio/iio:device0) beyond a memorable location? Maybe we leave this question for now...