login
Search
Add support for HP Pavlion dv5 models, whose sensor has an inverted x
axis.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
My HP Pavilion dv5 has an inverted x axis of the accelerometer, so this
patch marks the inversion for all the dv5. I can include the full
dmidecode output if this is deemed necessary.
With the laptop standing still on my desk jstest reports X and Y values
fluctuating from -8k to +8k (more or less). I assume this is normal?
drivers/hwmon/hp_accel.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/hwmon/hp_accel.c b/drivers/hwmon/hp_accel.c
index abf4dfc..5a379bd 100644
--- a/drivers/hwmon/hp_accel.c
+++ b/drivers/hwmon/hp_accel.c
@@ -179,6 +179,7 @@ static struct dmi_system_id lis3lv02d_dmi_ids[] = {
AXIS_DMI_MATCH("NC673x", "HP Compaq 673", xy_rotated_left_usd),
AXIS_DMI_MATCH("NC651xx", "HP Compaq 651", xy_rotated_right),
AXIS_DMI_MATCH("NC671xx", "HP Compaq 671", xy_swap_yz_inverted),
+ AXIS_DMI_MATCH("HPDV5", "HP Pavilion dv5", x_inverted),
{ NULL, }
/* Laptop models without axis info (yet):
* "NC6910" "HP Compaq 6910"
--
1.6.1.399.g0d272
--
Acked-by: Eric Piel <Eric.Piel@tremplin-utc.net> Looks good. What does "k" stands for? If that's the unit of the joystick output: yes, that's perfectly normal, just some noise/vibration. If that's 1000, it's far too much to be normal. Eric --
k is for thousands. I thought it could have been normal because someone (Pavel?) mentioned the disk park script trigged even if he was just walking around, so I just assumed the sensor to be extremely sensible. OTOH the maximum range of the sensor, as reported by jstest, seems to be -32k to +32k, and 8k is about one forth of it. Considering sometimes the fluctuations even peak to 12k, there might be something else at play here. Any suggestions on helping debug the issue are welcome. -- Giuseppe "Oblomov" Bilotta --
Ok, at my machine it fluctuates around 1K when sitting on the desk, and maximum range is about 13-15K. So your values seem little too noisy. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
I suspected as much. Do you think this is a hardware problem, or something that can be worked around in software? Or maybe I just leave in a very shaky neighborohood (although there's little or no car traffic around here) ... -- Giuseppe "Oblomov" Bilotta --
I'd say that the driver is way too new to suspect hardware problems. Could you try the new version from -mm? It does very minimum setup, as recommended by HP... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
I can try, but I have never worked with the -mm tree, so I don't even know where to get it. Is there a webpage or archived email I can read to understand how to get and build the -mm tree? Is it git-tracked? Or can I just get your patches for -mm and apply them on top of the current git? I will try this patch http://lkml.indiana.edu/hypermail/linux/kernel/0901.2/00164.html in the mean time, in case that's the patch which is in -mm. -- Giuseppe "Oblomov" Bilotta --
On Mon, Feb 9, 2009 at 12:45 PM, Giuseppe Bilotta With that patch I still get the same range of fluctuations. -- Giuseppe "Oblomov" Bilotta --
Yeah, that patch. Not sure what to do next... you could grab lis3 manual and see if you can setup chip by hand to get better results... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
As Eric pointed out, it looks definitely like an endianness problem, although there are a few strange things which are happening at the same time. Is the lis3 manual available online somewhere, or can I request it to the mfgr? -- Giuseppe "Oblomov" Bilotta --
It's freely available at the original manufacturer website: http://www.st.com/stonline/products/literature/ds/11115.htm Eric --
On Tue, Feb 10, 2009 at 10:39 PM, Giuseppe Bilotta 'k, found it on the STMicroelectronics website. Reading the doc about LIS3LV02DL I see that WHO_AM_I should return 3Ah, but my sensor returns 3Bh. I'll see if I find the correct datasheet for this one instead, it might have info about the differences. One thing that I noticed is that (modulo axis inversion) I'm able to use the sensor correctly if I set the thing to only use the high byte, totally discarding the lower byte: return *((s8*)(&hi)); Maybe this sensor needs a different setup to return 12 instead of 8 bits of information. -- Giuseppe "Oblomov" Bilotta --
Yeah, we accept also 3Bh for the who_am_i (see in hp_accel.c). The reporter who had a laptop with such chip never reported any problem and I didn't pay attention enough to notice those chips have only 8bits So you probably have a lis202dl (which has only two axes of 8bits each) or a LIS302DL (3 axes of 8 bits): http://www.st.com/stonline/products/literature/ds/13624/lis202dl.htm http://www.st.com/stonline/products/literature/ds/12726/lis302dl.htm Unfortunately, the WHO_AM_I register returns 3Bh in both cases. I'd tend to imagine it's a three axes chip, but you can confirm that by just checking if Z has any meaningful value. You can then modify lis3lv02d_read_16() to only return the byte as low byte and the high byte as FFh if the high bit of the value is set (because I guess they are signed integers). You also have to change MDPS_MAX_VAL to 128, to get things completely right. Once we have this sorted, we should add a flag to know if the current device is 8 bits or 12 bits, depending on the value of who_am_i. This would allow the driver to work fine with both type of chip. Eric --
On Tue, 10 Feb 2009 23:48:14 +0100 I've lost the plot here. I still intend to merge lis3lv02d-add-axes-knowledge-of-hp-pavilion-dv5-models.patch into 2.6.29. Someone please stop me if that is wrong. --
Hi Andrew, No, let's wait to get things settle down. You can discard the current patch. I think we should manage to get it working eventually, but the patch will be much bigger... Eric --
Ah, yes, that would explain a lots of things! Your chip is 8bits! The original reporter had not reported anything and I didn't pay attention So you either have the lis302dl or the lis202dl (2 axes only): http://www.st.com/stonline/products/literature/ds/12726/lis302dl.htm http://www.st.com/stonline/products/literature/ds/13624/lis202dl.htm I'd guess you have the one with 3 axes as all the axes had changing values. More optimistically I'll imagine that no HP laptop has the 2D chip, which unfortunately share the same who_am_i value. So to get it working you need to change the lis3lv02d_read_16() function to only read the low byte and put the high byte to FFh if the high bit (80h) is set (I guess it's a signed integer). Then for completeness you need to put MDPS_MAX_VAL to 128. Does it work? Once this is verified, you should add a flag in the driver for the device to know whether it's 8bits or 12bits. This would be set at initialization according to the who_am_i value. Eric --
No problem, the patch from Giuseppe will get the axex fine :-) However, could you let use know if you too, on your laptop, have huge fluctuations even when the laptop is not moving? Could you give an idea of the minimum and maximum values of each axis when the laptop is set normally on the desk without touching it? Thanks, Eric --
(putting back the cc's, please keep them when answering) Giuseppe, Palatis mentions that on his laptop the sensor is actually y_inverted. Could you check your laptop? In particular it would be nice if you could describe the values for the four positions defined in the documentation file. BTW, what is the exact version of your laptop? Is it the same as Palatis? Palatis, could you let us know if you also have a lot of "noise" in the values. That is, if when using jstest /dev/input/js0 you see big changes in the values. Is it like on Giuseppe's laptop of around 8000? Moreover I'm wondering if this could be an error on LSB/MSB ordering. Maybe looking at the raw values (cat /sys/devices/platform/lis3lv02d/position) would give more insight... See you, Eric --
With my patch applied:
Left raised: 0 -> 32k
Right raised: 0 -> -32k
Front raised: 1 -> -32k
back raised: 1 -> 32k
Upside down: 2 -> 32k
So it seems that my model inverts the Z axis too, I'll have to fix
that. However, this last test is tricky because unless the laptop is
completely upside down the Z axis can go from -32k to +32k with just a
couple of degrees (around the 90°)
amd64 architecture here. Laptop flat:
oblomov@oblomov:~$ cat /sys/devices/platform/lis3lv02d/position
(-256,256,14592)
oblomov@oblomov:~$ cat /sys/devices/platform/lis3lv02d/position
(0,256,14848)
oblomov@oblomov:~$ cat /sys/devices/platform/lis3lv02d/position
(-256,256,14848)
oblomov@oblomov:~$ cat /sys/devices/platform/lis3lv02d/position
(-256,0,14336)
oblomov@oblomov:~$ cat /sys/devices/platform/lis3lv02d/position
(-256,512,14336)
oblomov@oblomov:~$ cat /sys/devices/platform/lis3lv02d/position
(256,256,14592)
Left edge raised:
oblomov@oblomov:~$ cat /sys/devices/platform/lis3lv02d/position
(5120,512,13312)
oblomov@oblomov:~$ cat /sys/devices/platform/lis3lv02d/position
(5632,512,13312)
You might be onto something.
The dmi for my Pavilion is:
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Hewlett-Packard
Product Name: HP Pavilion dv5 Notebook PC
Version: F.09
Serial Number: (x-ed out)
UUID: (x-ed out)
Wake-up Type: Power Switch
SKU Number: (x-ed out)
Family: 103C_5335KV
So it might be that different pavilions have different sensors?
--
Giuseppe "Oblomov" Bilotta
--
Let's have a look at this once the "big noise" problem is fixed, because for now it's rather impossible to deduce anything meaningful. Yes, beautiful! All are multiples of 2⁸, so much a sign of MSB/LSB inversion! And the good news is that the device just happens to have a register to set the endianess: CTRL2/BLE . For now, in the driver, we expect the device to be little endian (which is the default according to the manual). So at initialization we could force the endianess and see if that fix the problem. Can you try something like this in lis3lv02d_poweron(): adev.read(handle, CTRL_REG2, &val); val |= CTRL2_BDU | CTRL2_IEN; + val &= ~CTRL2_BLE; adev.write(handle, CTRL_REG2, val); Eric
I reverted both my patch and the 'minimal init' patch from Pavel, then added this line. However, it seems to change nothing. Even using CTRL2_BLE instead of its negation doesn't seem to change much: same fluctuations, and cat'ing the sysfs file still gives 256, 512 etc. -- Giuseppe "Oblomov" Bilotta --
On Tue, Feb 10, 2009 at 9:29 PM, Giuseppe Bilotta Discard this, I'm an idiot and I'm not doing the testing properly. BRB. -- Giuseppe "Oblomov" Bilotta --
Ok, this is getting crazier and crazier. Apparently, setting the CTRL2_BLE bit this way makes no difference, and so does setting it with val |= (i.e. enabling it): in both cases, if I debug lis3lv02d_read_16 I always get 0 in the lower byte and something in the upper byte. By forcefully swapping lo and hi I actually get very little fluctuations in the Y and Z axes (so small that jstest doesn't detect them), but I still get huge (4k) fluctuations in the X axis: apparently, this axis has very small SIGNED fluctuations around the 0, which translate to fluctuations between 255 and 1 Now, the lo/hi thing might be solved some other way (e.g. by checking the BLE bit and relying on its setting instead of trying to force it, and then swapping hi and lo as needed). But how do we solve the SIGNEDNESS of lo ? -- Giuseppe "Oblomov" Bilotta --
On Tue, Feb 10, 2009 at 10:28 PM, Giuseppe Bilotta To be precise, these are the result I get with some additional debug info, with and without setting BLE. Setting BLE on init: [ 2891.428798] lis3lv02d: BLE: 0 [ 2891.452567] lis3lv02d: BLE: 32 [ 2891.476800] lis3lv02d: lo: 0 hi: 1 [ 2891.500616] lis3lv02d: lo: 0 hi: 3 [ 2891.524799] lis3lv02d: lo: 0 hi: 57 Resetting BLE on init: [ 3006.661279] lis3lv02d: BLE: 0 [ 3006.684574] lis3lv02d: BLE: 0 [ 3006.709107] lis3lv02d: lo: 0 hi: 254 [ 3006.733144] lis3lv02d: lo: 0 hi: 2 [ 3006.757286] lis3lv02d: lo: 0 hi: 56 So it looks like (1) the BLE register is ignored (at least in my sensor) and (2) it actually defaults to LE anyway. -- Giuseppe "Oblomov" Bilotta --
Well, on hp2140 it fluctuates 1000+-500 or so... But Z axis is still significantly different. How much is 7 while in "steady state" for you? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
Assuming 7 here means Z, the Z axis fluctuates in the + range. All three axis seem to hold to 4k most of the time (+ or - for X and Y, only + for Z), with not infrequent peaks of 8k (+ or - for X and Y, only + for Z), and seldom peaks at around 12k. Z seems to peak to 12k more often, I only rarely manage to see X or Y peaking so high. -- Giuseppe "Oblomov" Bilotta --
On Mon, Feb 9, 2009 at 4:02 PM, Jaswinder Singh Rajput lspnp (run by root, most likely) should show a device HPQ0004. If it's present you have the sensor. I also have a big horrible sticker on my palm rest advertising the protectsmart feature. (Please use Reply-All) -- Giuseppe "Oblomov" Bilotta --
