Message-ID: <Pine.LNX.4.58.0703061804360.2988@be1.lrz>
Date:	Tue, 6 Mar 2007 21:40:19 +0100 (CET)
From:	Bodo Eggert <7eggert@....de>
To:	Jean Delvare <khali@...ux-fr.org>
cc:	Bodo Eggert <7eggert@....de>,
	David Hubbard <david.c.hubbard@...il.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Pavel Machek <pavel@....cz>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	lm-sensors@...sensors.org, linux-acpi@...r.kernel.org,
	Chuck Ebbert <cebbert@...hat.com>, Rudolf@...pms.net
Subject: Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?

On Tue, 6 Mar 2007, Jean Delvare wrote:
> On Mon, 05 Mar 2007 14:56:44 +0100, Bodo Eggert wrote:

> > 2) make ACPI take this lock whenever it touches ports not allocated by itself
> >    and release it on function return.
> 
> This is costly.

TANSTAAFL. You'll need to take some lock, and if you want port emulation 
or per-device-mutex, you'll have to pay the price.

> > 3) Make ACPI callback the allocating device if it touches allocated ranges,
> >    and on function return.
> 
> By callback, do you mean port forwarding as Rudolf Marek did, or more
> simple "stop touching the device" and "you can touch the device again"
> sort of signals? If the latter, this is no different from a mutex.

It may be the described port emulation callback (which is very nice and
possibly desired for some devices), but if you add an "I am done tampering
with your hardware" callback, the driver can also implement the mutex.

Some drivers will not understand all possible access patterns, they may 
try to emulate first, and if they fail, fall back to taking the mutex and 
passing the raw port access.

> > 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.
> 
> What benefit do you see compared to a lock taken by both AML and the
> hardware monitoring drivers?

1) I asume port allocations or ACPI foreign port acces to be rare, so
   there would be little impact on (un)registering hardware. Off cause
   there are some long ACPI calls (like reading the battery?), in these
   cases it might be beneficial to release the global allocation lock
   after gaining exclusive access to the driver's port range. (This can
   only be done if the device driver is loaded.)

2) If there is a global lock for accessing ACPI-tampered hardware, each
   driver that *might* conflict with ACPI _must_ take it on each access.  
   This would seialize unrelated sensor busses, IDE, graphics ...  (AFAI
   can imagine.)  A callback allows using a per-(device|bus)-mutex instead.

> Care to submit a sample implementation?

I think somebody experienced with the internals should do this.

Rudolph's implementation is close enough to imagine what would be done,
the changes would be:

- Add a "done" call to resource_ops

in ACPI:
- Check for own region first and do raw access there
- get the lock before __request_region
- s/__request/__check/

in driver:
- If emulation fails, get the local lock and switch to passthrough mode
- if in passthrough mode and done is called, release the lock
-- 
Those who hesitate under fire usually do not end up KIA or WIA. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists