Is your ioport included in the microsoft's list being blocked by XP?
Please give me an example (acpidump output from a real box)
that demonstrates ACPI is missing something which must be done
through native driver. I'm wondering the designer of the box should
already known AML code will directly
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? Do you know the features that are NOT supported by ACPI?
Probably, just writing a
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
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
Rudolf Marek wrote:
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
Hello Alex,
Thanks for the comments.
Why do you think such a solution exists?
I asked help to find a solution, this does not mean I believe there is one.
One solution would be to create generic thermal interface, under which all
drivers could provide their capabilities... Say if lm-sensors
Hi,
I studied ACPI spec once a while and there is only global lock (this is used for
SMM ) and also there might be some per device mutexes, but I never seen them
implemented. Maybe there might be implemented some per ACPI device mutex, so
regions belonging to this device will be locked if the
Hi Rudolf,
My feeling: I/O-devices that provide different functions via the
same register-set, should have a core that takes care of the
communication with the I/O-device. (like for instance the w83627hf
chipset that has sensor functionailty but also watchdog capabilities).
The core needs to
Hi all,
I am not on the linux-acpi list, so please include me in the To: for
future replies.
What it does? It reads the register 0x50 in bank 1 of W83627EHF chip.
The register for bank switch is 0x4e.
The w83627EHF driver update function is also changing the bank switch
register. We have seen
