[lm-sensors] ACPI bytecode hardware registers access
r.marek at assembler.cz
Mon Feb 5 17:41:04 CET 2007
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 could keep
> system from overheating, it could say so, and system could skip loading of
> ACPI thermal driver. Problem is, lm-sensors doesn't know, what to do to
> control system. You still need to figure out, that for example turning fan #3
> on helps to decrease temp #2... It's not possible to associate termal devices
> of ACPI with those from lm-sensors, so lm-sensors cannot steal info about
> trip-points from ACPI, or use ACPI as a governor.
Well this is quite a different level of abstraction. I believe that thermal
control for laptops should be left alone, or driven by ACPI.
My current focus is to stop changing the registers from ACPI AML same time as
other drivers are using same device. (on desktop/server systems) This causes
problems to APCI and also to other drivers. Once such collision is detected we
may warn the user to use for example just the thermal module and not lm-sensors
In ideal case user should use the ACPI thermal policy OR the lm-sensors, but
without the actual inspection of ACPI bytecode there is no chance to know if
ACPI and lm-sensors driver are talking to same chip? (maybe through the I/O
space regions it may work, however not for smbus bused stuff, because it will
advertise the controller and not the actual smbus device)
> Returning to your example, there are two registers in ACPI space, access to
> which should be locked by single mutex. So you could provide mapping from I/O
> address to mutex. So if ACPI wants to access IO register, it asks, which
> mutex it should acquire. Question on how to extend mutex lock until access to
> second register remains open...
So if I understand correctly you propose something like I did in 3) in my
original post. However this will not help much because we need to hold the mutex
longer time. If I look from the "other" side, typical driver just sets the bank,
do the reads/writes and then does not care about it. This could be generalized -
the driver guards its "transactions" - once done it does not care what happens
with the device (suppose the driver preserves the chip state after transaction
is done - this is easy for monitoring chips but hard for smbus cotrollers)
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 code execution is still
in device methods. I dont know if it would work for the "globaly" declared
Second possibility is to have some kind of that port forwarder, which will
direct the actual access from ACPI to the Linux driver. The driver then knows if
is safe to read or write from/to that location.
This principle would be also handy for the super I/O because this chips needs
some magic sequence to open them, read the config and close them. There are many
drivers (watchdog, parport, irda, mmc, lm-sensors) in the kernel trying to write
to same super I/O port (0x2e/0x2f) this generic port forwarder would solve it too.
Question for ACPI people: If I would come with some kind of this port-forwarder
class - will you accept it as solution if all technical stuff is solved? I mean
- will be solution acceptable in principle for you?
Keep me CCed thanks.
More information about the lm-sensors