HP accelerometer: split chip handling from HP ACPI interface

This patch splits handling between chip-specific lis3lv02d and HP/ACPI specific hp_accel.c.

Quoted 2 lines · On Fri, 21 Nov 2008 22:21:21 +0100 Pavel Machek <[email protected]> wrote:

This patch splits handling between chip-specific lis3lv02d and HP/ACPI specific hp_accel.c.

umm, so? What reason does anyone have for applying it?

Andrew Morton schreef:

Quoted 6 lines

Quoted 2 lines · On Fri, 21 Nov 2008 22:21:21 +0100 Pavel Machek <[email protected]> wrote:

This patch splits handling between chip-specific lis3lv02d and HP/ACPI specific hp_accel.c.

umm, so? What reason does anyone have for applying it?

Here is the log I have for the (old version) of pavel's patch:

The sensor can be accessed via various buses. In particular, SPI, I²C and, on HP laptops, via a specific ACPI API (the only one currently supported). Separate this latest platform from the core of the sensor driver to allow support for the other bus type. The second, and more direct goal is actually to be able to merge this part with the hp-disk-leds driver, which has the same ACPI PNP number.

I'll try to follow with a patch doing the merge of the hp-disk-leds driver, so that everything makes sense...

The sensor can be accessed via various buses. In particular, SPI, I?C and, on HP laptops, via a specific ACPI API (the only one currently supported). Separate this latest platform from the core of the sensor driver to allow support for the other bus type. The second, and more direct goal is actually to be able to merge this part with the hp-disk-leds driver, which has the same ACPI PNP number.

Signed-off-by Pavel Machek <[email protected]>

Signed-off-by Eric Piel <[email protected]>

Quoted 7 lines

The sensor can be accessed via various buses. In particular, SPI, I?C and, on HP laptops, via a specific ACPI API (the only one currently supported). Separate this latest platform from the core of the sensor driver to allow support for the other bus type. The second, and more direct goal is actually to be able to merge this part with the hp-disk-leds driver, which has the same ACPI PNP number.

Quoted 2 lines

Signed-off-by Pavel Machek <[email protected]>

Signed-off-by Eric Piel <[email protected]>

Oops, I sent wrong patch. This should fix the 'compile as module' problems...

Éric Piel schreef:

Quoted 17 lines

Andrew Morton schreef:

Quoted 6 lines

Quoted 2 lines · On Fri, 21 Nov 2008 22:21:21 +0100 Pavel Machek <[email protected]> wrote:

This patch splits handling between chip-specific lis3lv02d and HP/ACPI specific hp_accel.c.

umm, so? What reason does anyone have for applying it?

Here is the log I have for the (old version) of pavel's patch:

The sensor can be accessed via various buses. In particular, SPI, I?C and, on HP laptops, via a specific ACPI API (the only one currently supported). Separate this latest platform from the core of the sensor driver to allow support for the other bus type. The second, and more direct goal is actually to be able to merge this part with the hp-disk-leds driver, which has the same ACPI PNP number.

Quoted 2 lines

I'll try to follow with a patch doing the merge of the hp-disk-leds driver, so that everything makes sense...

Actually, I mistook, Pavel also included some led stuff in this patch. That doesn't look right, especially as the led driver is not removed!

This patch splits handling between chip-specific lis3lv02d and HP/ACPI specific hp_accel.c.

Hi!

I got free fall detection to work -- apparently BIOS does all the important stuff itself.

Now... I'd like some testers. (Don't comment on code... yet. Yes, it has some issues).

hp3dg script should do all the important things.

Quoted 6 lines

I got free fall detection to work -- apparently BIOS does all the important stuff itself.

Now... I'd like some testers. (Don't comment on code... yet. Yes, it has some issues).

Hi Pavel,
I'll try to test this weekend.

Out of curiosity, what did you change compared to the original version of the driver? Did you just disable the set up code?

Also, how do you try free fall? Did you try also with the lid opened?

Quoted 1 line

hp3dg script should do all the important things.

:

Documentation/hwmon/hp3dg

Quoted 2 lines

Documentation/hwmon/hp3dg new file +0 -0

:

Documentation/hwmon/hp3dg line 26

Quoted 7 lines

Documentation/hwmon/hp3dg new file +7 -0

+while true; do
+	./readaccel foo
+	unload 2
+	if cat /proc/acpi/button/lid/LID/state | grep open && cat /proc/acpi/ac_adapter/AC0/state | grep off-line; then
+		unload 20
+	fi
+done

Why a special case if the lid is opened and the laptop unplugged? Is it a special behaviour of the hardware, or simply some kind of basic user behaviour guess?

Hi!

Quoted 5 lines

Quoted 5 lines

I got free fall detection to work -- apparently BIOS does all the important stuff itself.

Now... I'd like some testers. (Don't comment on code... yet. Yes, it has some issues).

Quoted 2 lines

Also, how do you try free fall? Did you try also with the lid opened?

With the lid opened, too, yes. I just took the machine, then tried to let go and catch it meter below that. (Of course I did not really let go, but released the grip and followed...)

Quoted 5 lines

Quoted 1 line

hp3dg script should do all the important things.

:

Documentation/hwmon/hp3dg

Quoted 2 lines

Documentation/hwmon/hp3dg new file +0 -0

:

Quoted 10 lines

Documentation/hwmon/hp3dg line 26

Quoted 7 lines

Documentation/hwmon/hp3dg new file +7 -0

+while true; do
+	./readaccel foo
+	unload 2
+	if cat /proc/acpi/button/lid/LID/state | grep open && cat /proc/acpi/ac_adapter/AC0/state | grep off-line; then
+		unload 20
+	fi
+done

Why a special case if the lid is opened and the laptop unplugged? Is it a special behaviour of the hardware, or simply some kind of basic user behaviour guess?

Behaviour guess, HP asked for those values. Idea is that if the user is walking with machine, park as much as possible because machine is in danger :-).

Pavel Machek schreef:

Quoted 8 lines

Hi!

Quoted 6 lines

Quoted 5 lines

I got free fall detection to work -- apparently BIOS does all the important stuff itself.

Now... I'd like some testers. (Don't comment on code... yet. Yes, it has some issues).

Quoted 6 lines

Quoted 2 lines

Also, how do you try free fall? Did you try also with the lid opened?

With the lid opened, too, yes. I just took the machine, then tried to let go and catch it meter below that. (Of course I did not really let go, but released the grip and followed...)

Hi,
I've tested it. Mostly, it works. If I let it fall, it detects it. If I repeat, it detects it again. If shake it, it doesn't detect any freefall (good). However, for this to work on my laptop (2510p), after the device is turned on, the AC must be unplugged and lid closed before it starts working. It seems that that's only this specific state that triggers the configuration of the sensor by the bios. Once setup, I can plug back and open again the lid, the sensor keeps detecting the freefalls (until it's turned off again).

So I think it's still necessary to explicitly set up the sensor. It's just a matter of setting up the registers as the bios does. We should be able to manage (just by dumping them once).

BTW, there were a couple of problems with the scripts. You have change "/dev/misc" to "/dev/freefall" (which I also like more) but forgot to update the driver itself.

For hp3dg, it couldn't find the led (not the same truncation of the name of the led). Probably you could replace the name of the led by:
/sys/class/leds/*hddprotect*/

The led never turns off, because the sleep is slightly shorter than the unload command.

Moreover, on my system I have neither /proc/acpi/button/lid/LID/state nor /proc/acpi/ac_adapter/AC0/state ! I guess they could be replaced by a clever use of /dev/input/eventX (contening Lid) and /sys/class/power_supply/*/online

Quoted 35 lines

Pavel Machek schreef:

Quoted 5 lines

Hi!

Quoted 3 lines

Quoted 3 lines

I got free fall detection to work -- apparently BIOS does all the important stuff itself.

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

Now... I'd like some testers. (Don't comment on code... yet. Yes, it has some issues).

Also, how do you try free fall? Did you try also with the lid opened?

With the lid opened, too, yes. I just took the machine, then tried to let go and catch it meter below that. (Of course I did not really let go, but released the grip and followed...)

Hi,
I've tested it. Mostly, it works. If I let it fall, it detects it. If I repeat, it detects it again. If shake it, it doesn't detect any freefall (good). However, for this to work on my laptop (2510p), after the device is turned on, the AC must be unplugged and lid closed before it starts working. It seems that that's only this specific state that triggers the configuration of the sensor by the bios. Once setup, I can plug back and open again the lid, the sensor keeps detecting the freefalls (until it's turned off again).

So I think it's still necessary to explicitly set up the sensor. It's just a matter of setting up the registers as the bios does. We should be able to manage (just by dumping them once).

BTW, there were a couple of problems with the scripts. You have change "/dev/misc" to "/dev/freefall" (which I also like more) but forgot to update the driver itself.

For hp3dg, it couldn't find the led (not the same truncation of the name of the led). Probably you could replace the name of the led by:
/sys/class/leds/*hddprotect*/

Quoted 7 lines

The led never turns off, because the sleep is slightly shorter than the unload command.

Moreover, on my system I have neither /proc/acpi/button/lid/LID/state nor /proc/acpi/ac_adapter/AC0/state ! I guess they could be replaced by a clever use of /dev/input/eventX (contening Lid) and /sys/class/power_supply/*/online

These should still exist (bug?), as long as you do compile with ACPI_PROCFS (and load the ac, button modules).
But there should also exist a sysfs replacement:
http://userweb.kernel.org/~lenb/doc/LPC2008-API-web/
gives an overview of what is converted and where it should pop up now.

Pavel Machek schreef:

Quoted 8 lines

Hi!

Quoted 5 lines

Quoted 5 lines

I got free fall detection to work -- apparently BIOS does all the important stuff itself.

Now... I'd like some testers. (Don't comment on code... yet. Yes, it has some issues).

Quoted 6 lines

Quoted 2 lines

Also, how do you try free fall? Did you try also with the lid opened?

With the lid opened, too, yes. I just took the machine, then tried to let go and catch it meter below that. (Of course I did not really let go, but released the grip and followed...)

Hi,
I've tested it. Mostly, it works. If I let it fall, it detects it. If I repeat, it detects it again. If shake it, it doesn't detect any freefall (good). However, for this to work on my laptop (2510p), after the device is turned on, the AC must be unplugged and lid closed before it starts working. It seems that that's only this specific state that triggers the configuration of the sensor by the bios. Once setup, I can plug back and open again the lid, the sensor keeps detecting the freefalls (until it's turned off again).

So I think it's still necessary to explicitly set up the sensor. It's just a matter of setting up the registers as the bios does. We should be able to manage (just by dumping them once).

BTW, there were a couple of problems with the scripts. You have change "/dev/misc" to "/dev/freefall" (which I also like more) but forgot to update the driver itself.

For hp3dg, it couldn't find the led (not the same truncation of the name of the led). Probably you could replace the name of the led by:
/sys/class/leds/*hddprotect*/