On Tue, Apr 20, 2010 at 1:21 PM, Florian Echtler <[email protected]> wrote:
> Hello Corentin,
>
>> > Looking at your dsdt:
>> >
>> > BUF1 and BUF2 contains some easy to find data:
> [...]
> You're correct, but most of the data fields within BUF1 and BUF2 are
> never referenced anywhere else. Doesn't that mean that these fields are
> probably dead?
Hum .. maybe, the best way to know would be to dump it in various
hardware states.
>> > Looking at _INI :
>> > Store (\_SB.BRNS, BRMX) probably means "set the brightness to
>> > the maximum brightness"
>> >
>> > WQIO returns both BUF1 and BUF2, you can get it with wmi_query_block()
>> >
>> > WSIO calls CPSR and CPSR store the argument in INBF.
>> > BY00, BY01, ... BY31, BGTX, BGTY, BGTZ etc ... are used to access
>> > specific bytes in INBF :
>> > CreateByteField (INBF, 0x00, BY00)
>> > CreateByteField (INBF, 0x01, BY01)
>> > CreateByteField (INBF, 0x02, BY02)
>> > CreateByteField (INBF, 0x03, BY03)
>> > CreateByteField (INBF, 0x04, BY04)
>> > CreateByteField (INBF, 0x05, BY05)
>> >
>> >
>> > CSPR wants BY00 to be 0x01 and BY01 to be 0x10 to do something.
>> > It calls CMD0 (BY08, BY09, BY10, BY11, BY16)
>> >
>> > ERQ0 (present in BUF1) is compared to Arg2 (BY09) == 0x1
>> > if true, it will store some values and call notify
> So this would then trigger the WMI event in the driver, right?
> I'd assume that EVID is the EVent ID - would make sense, since somewhere
> in the embedded controller code, there's this snippet:
>
> Method (_QEF, 0, NotSerialized)
> {
> Store (0xEF, P80H)
> \_SB.WMI2.CMD2 (0x2D, 0x01, 0x01)
> }
>
> Method (_QF1, 0, NotSerialized)
> {
> Store (0xF1, P80H)
> \_SB.WMI2.CMD2 (0x2C, 0x01, 0x01)
> }
>
> AFAICT the problem might be that ERQ0 is never initialized.. so it's
> probably zero from the start and the first code branch in CMD0 will
> never be called.
ERQ0 is initialized here (with 0x00):
Name (BUF1, Buffer (0x40)
{
/* 0000 */ 0x01, 0x00, 0x00,
0xFF, 0x00, 0xFF, 0xFF, 0xFF,
/* 0008 */ 0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
/* 0010 */ 0xFF, 0xFF, 0x00,
0x00, 0x00, 0xFF, 0xFF, 0xFF,
/* 0018 */ 0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
/* 0020 */ 0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
/* 0028 */ 0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
/* 0030 */ 0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
/* 0038 */ 0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF
})
>> Method (GECN, 1, NotSerialized)
>> Method (SECN, 2, Serialized)
>>
>> are very interesting:
>>
>> GECN is used to get status, and SECN to set status.
>>
>> For example, use \_SB.GECN(0x03) to get bluetooth status
>> And \_SB.SECN(0x03, 0x01) to enable bluetooth.
>> I don't really understand what DECN is used for, maybe to know if a
>> device is present (or maybe just switch GECN and DECN).
> I've gone through the binary module from Splashtop (lenovo_ec.ko) with
> objdump, and it appears that it's calling exactly those methods
> (GECN,SECN,DECN). The EC registers themselves also do look very
> interesting, especially with fields like XALM/YALM/ZALM or
> GSVX/GSVY/GSVZ which are probably related to the accelerometer.
>
> Do you perhaps have some example as to how to access the EC register
> space?
Take a look at eeepc-laptop, you can do most of the work with
acpi_evaluate_object (see write_acpi_int/read_acpi_init in
eeepc-laptop).
If you really need to access the EC directly, check ec_write()/ec_read() calls.
--
Corentin Chary
http://xf.iksaif.net
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
