Riku Voipio wrote: > Yan Burman wrote: >> +================== >> + >> +Supported chips: >> + >> + * STMicroelectronics LIS3LV02DL and LIS3LV02DQ >> + > These chips are connected to either I2C or SPI - This is the 4th driver for > (apparently) these same chips: > > http://docwiki.gumstix.org/Lis3lv02dq_spi.c > http://svn.openmoko.org/branches/src/target/kernel/2.6.24.x/patches/lis302dl.patch > > http://article.gmane.org/gmane.linux.kernel.spi.devel/1010 Hi! Thanks a lot for these links (which I was not aware of). They indeed seem to handle the same hardware (all via spi). To be even more complete, here is a link we received off-list for accessing the same hardware via I?C: http://pof.eslack.org/HTC/shift/i2c-gsensor.tar.gz There are for sure some nice things we could borrow ;-) > >> + depends on ACPI && INPUT && X86 >> > > >> +/* The actual chip is STMicroelectronics LIS3LV02DL or LIS3LV02DQ >> + * that seems to be connected via SPI */ >> > Perhaps it would make more sense implement support for SPI > bus on the laptop and use the SPI interface directly instead or > routing via the ACPI hiding layer? Getting rid of ACPI could be nice, as it tends to be rather slow. However, so far we've stick to it because it ensures that for the ~15 different models of HP laptop, we can access the hardware exactly the same way. I have the gut feeling that if HP spent some time to add an interface in ACPI, there was some kind of reason. However, I know nothing about SPI. Maybe you'll tell that if this chip is on the SPI bus, it will always be accessed the same way, located at the same address... or whatever that can ensure us that from the moment we know this device is in the laptop (and that's easy via HPQ0004) we cannot mess up. In that case, going to SPI would be definitely worthy. Eric
