[haiku-development] Re: acpi_thinkpad: request for assistance
- From: Michael Weirauch <dev@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 25 Nov 2009 12:41:26 +0100
2009/11/23 Michael Weirauch <dev@xxxxxxxxxxx>:
>> You can try to read the registers directly (but maybe this interfere with
>> the ec driver). See the ec driver how I got the ec address and read / write
>> the registers there.
>> You can also try to find out how acpi use the ec driver and if there is a
>> interface to read the register.
>
> Thanks for the info. I will try to give it a go and get back about any
> results.
A little update. I was able to fetch the acpi_handle to the EC by it's acpi/path
via the apci_modules get_handle(). I just have to evaluate_method() via
the acpi_module (instead of the acpi_device_module) as that operates on
acpi_handles instead of acpi_devices. Will have to see how well this works out
on more usage.
Reading out the ThinkLight status via the EC acpi_handle as a little test
example works now.
The more pressing issue - and that is why I started work on this little driver -
is enabling of the usb-attached bluetooth dongle which doesn't get re-enabled
when it was disabled once or was already disabled during boot.
Of what I was told by Michael (mmlr) is that the usb subsystem checks
the status bits in the usb device registers (the usb-hub?). What the ACPI
subsystem (the hardware part) does in order to activate the device is
out of my knowledge and understanding. Is it that the ACPI subsystem
sets these status registers in the usb device registers directly?
Michael, you once informed me that the usb subsystem is polling for
these status bits, right? Could you point me to the place in code where
it is doing so? Might the polling interval be too low? I am just
trying to evaluate
every possibility. I am not implying something is wrong with that part.
Thanks in advance!
Michael
Other related posts:
