Re: ACPI bytecode hardware registers access

[Rudolf Marek <r.marek@assembler.cz>]

Hello,

To all:
Please continue CCing me and the lm-sensors list thanks.

Luming Yu wrote:
> Yes, that is bad to simultaneously access same hardware by ACPI and
> native drivers without coordination. But the problem is if nativer
> driver is really needed with the existence of the ACPI support for
> that device? 

Yes for example, BIOS will export though ACPI just one temperature _TMP but the
chip monitors voltages and more temps etc etc. So from the lm-sensors point of
view the answer is yes we need a full driver for hardware monitoring.

> Do you know the features that are NOT supported by ACPI?

Yes as I wrote above - the voltages, fan speeds, various types of alarms...

Instead of one temperature reading, I got 9 voltage readings, 3 temps, 5 fans
etc etc

> Probably, just writing a acpi driver for SMBus controler could solve
> this problem completely. Just my intuition. Please correct me if I'm
> wrong.

Problem is that the device manufacturers may do what they want in ACPI bytecode.
  We cannot expect them to implement smbus bus control as specified in the
specs. They just drive the registers on their own.

What I'm trying to implement is the ACPI isolation from selected hardware
somehow, because the ACPI bytecode can contain code that modifies virtually any
hardware in the system without the clue what others drivers do.

Even the windows don't like it:
http://www.microsoft.com/whdc/system/pnppwr/powermgmt/BIOSAML.mspx
(I/O Ports Blocked from BIOS AML)

Please help me find the solution.

Thanks,
Rudolf