[ltp] getting hdaps up and running on the w530
Саша Питосин
sasha.pitosin at mail.ru
Wed Sep 26 02:36:12 CEST 2018
On 4/14/14 3:19 PM, Raider Sail wrote:
> 1. How do we interface with the APS hardware via the new embedded controller on the W530?
Hello,
I think I have made some progress with latest ThinkPad accelerometer,
observing I/O port communications between the Windows Driver and hardware.
Only ports 0x1610 and 0x1611 are used, using an "indirect" addressing mode:
- writing to 0x1610 selects the register to be accessed
- reading (or writing) 0x1611 reads (or writes) the chosen register.
It appears that some operations can take a while, and you have to poll
register 0x00 until it return zero.
Readings are delivered through a FIFO (registers 0x10-0x2f), each entry
containing:
- X axis (2 bytes, little-endian)
- Y axis (2 bytes, little-endian)
- One extra byte (maybe related to temperature?)
Before accessing the FIFO, 0xff is always written to register 0x01
(latch?), and 0x00 is written to the same register, maybe to release it.
Getting new readings involves waiting for the accelerometer to be ready,
locking the FIFO, writing 0x11 to register 0x00 and waiting again.
Register 0x10 will then contain the number of available FIFO entries
(between 0 and 5), followed by the 5-byte records described above in
registers 0x11 to (0x11 + 5 * num. of records)-1. Then register 0x2f
returns zero and the FIFO can be released.
An example of a reading sequence:
0x1610 <-- 0x00
0x1611 --> 0x00 # register 0x00 returns 0x00
0x1610 <-- 0x01
0x1611 <-- 0xff # register 0x01 is written 0xff
0x1610 <-- 0x00
0x1611 <-- 0x11 # register 0x00 is written 0x11
0x1610 <-- 0x00
0x1611 --> 0x11 # register 0x00 returns 0x11 (not ready yet - polling!)
0x1611 --> 0x00 # register 0x00 returns 0x00
0x1610 <-- 0x10
0x1611 --> 0x01 # register 0x10 returns 0x01
0x1610 <-- 0x11
0x1611 --> 0x11 # first data byte
0x1610 <-- 0x12
0x1611 --> 0x02 # second data byte
0x1610 <-- 0x13
0x1611 --> 0x9a # ...
0x1610 <-- 0x14
0x1611 --> 0x02
0x1610 <-- 0x2a
0x1611 --> 0x00
0x1610 <-- 0x2b
0x1611 --> 0x80
0x1610 <-- 0x2f
0x1611 --> 0x00 # register 0x2f returns 0x00
0x1610 <-- 0x01
0x1611 <-- 0x00 # register 0x01 is written 0x00
At boot, the following registers are configured:
0x1610 <-- 0x00
0x1611 --> 0x00 # register 0x00 returns 0x00
0x1610 <-- 0x01
0x1611 <-- 0xff # register 0x01 is written 0xff
0x1610 <-- 0x10
0x1611 <-- 0x81 # register 0x10 is written 0x81
0x1610 <-- 0x00
0x1611 <-- 0x17
0x1610 <-- 0x00
0x1611 --> 0x00
0x1610 <-- 0x10
0x1611 --> 0x01
0x1610 <-- 0x11
0x1611 --> 0x00
0x1610 <-- 0x12
0x1611 --> 0x00
0x1610 <-- 0x13
0x1611 --> 0x00
0x1610 <-- 0x2f
0x1611 --> 0x00
0x1610 <-- 0x01
0x1611 <-- 0x00 # register 0x01 is written 0x00
0x1610 <-- 0x00
0x1611 --> 0x00 # register 0x00 returns 0x00
0x1610 <-- 0x01
0x1611 <-- 0xff # register 0x01 is written 0xff
0x1610 <-- 0x10
0x1611 <-- 0x01 # register 0x10 is written 0x01
0x1610 <-- 0x00
0x1611 <-- 0x14
0x1610 <-- 0x00
0x1611 --> 0x00
0x1610 <-- 0x10
0x1611 --> 0x01
0x1610 <-- 0x2f
0x1611 --> 0x00
0x1610 <-- 0x01
0x1611 <-- 0x00 # register 0x01 is written 0x00
0x1610 <-- 0x00
0x1611 --> 0x00 # register 0x00 returns 0x00
0x1610 <-- 0x01
0x1611 <-- 0xff # register 0x01 is written 0xff
0x1610 <-- 0x10
0x1611 <-- 0xc8 # register 0x10 is written 0xc8
0x1610 <-- 0x11
0x1611 <-- 0x00
0x1610 <-- 0x12
0x1611 <-- 0x02
0x1610 <-- 0x00
0x1611 <-- 0x10 # register 0x00 is written 0x10
0x1610 <-- 0x00
0x1611 --> 0x10 # register 0x00 returns 0x10 (not ready yet - polling!)
0x1611 --> 0x00 # register 0x00 returns 0x00
0x1610 <-- 0x10
0x1611 --> 0xc8
0x1610 <-- 0x2f
0x1611 --> 0x00
0x1610 <-- 0x01
0x1611 <-- 0x00 # register 0x01 is written 0x00
Regards,
Sasha
More information about the Linux-Thinkpad
mailing list