David Hubbard <david.c.hubbard@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxx lG@xxxxxxxxxxxxxxxxxxxxxxxxx hffltUu@xxxxxxxxxxxxxxxxxxxxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
