Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?

Bodo Eggert
2007-03-05T13:59:07Z

David Hubbard <david.c.hubbard@gmail.com> wrote:

> For I/O and memory that ACPI accesses and has not reserved, the AML
> interpreter could allocate at run-time.
>
> I'm not sure how to implement exactly. For example, it would be bad to
> have a /proc/ioports that had a lot of single ports allocated, for
> example:
> 1000-107f : 0000:00:1f.0
> 1000-1000 : ACPI PM1a_EVT_BLK
> 1001-1001 : ACPI PM1a_EVT_BLK
> 1002-1002 : ACPI PM1a_EVT_BLK
> 1003-1003 : ACPI PM1a_EVT_BLK
>
> Thus the AML interpreter would need to have some reasonable
> intelligence when allocating regions. Conflict resolution would also
> be more difficult, e.g. if a hwmon driver was loaded first and then
> acpi as a module, ACPI could not allocate the region. Maybe run-time
> allocating won't work.
>
> And then, how would ACPI release a region after it has used it? The
> easiest method would be to never release anything used even once.
>
> Thoughts?

1) Make a general resource allocation lock, if there is none.
2) make ACPI take this lock whenever it touches ports not allocated by itself
and release it on function return.
3) Make ACPI callback the allocating device if it touches allocated ranges,
and on function return.

1 + 2 will replace allocating single ports and freeing them again (so ACPI won't
prevent e.g. the display driver from loading just because it turned on the
backlight) while preventing races with newly allocated ranges, and 3 allows
coexistence with other drivers.
--
The problem with the easy way out is that it has already been mined.

Friß, Spammer: TKF8@jQXoImLG.7eggert.dyndns.org
lG@aOkf0g.7eggert.dyndns.org hffltUu@6au8pBwc.7eggert.dyndns.org
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html