Date:	Tue, 3 Apr 2007 09:21:02 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	"Moore, Robert" <robert.moore@...el.com>
Cc:	"Pavel Machek" <pavel@....cz>, "Brown, Len" <len.brown@...el.com>,
	"Matthew Garrett" <mjg59@...f.ucam.org>,
	"Chuck Ebbert" <cebbert@...hat.com>,
	"Rudolf Marek" <r.marek@...embler.cz>,
	<linux-acpi@...r.kernel.org>,
	"linux-kernel" <linux-kernel@...r.kernel.org>,
	<lm-sensors@...sensors.org>
Subject: Re: Could the k8temp driver be interfering with ACPI?

Hi Bob,

On Mon, 2 Apr 2007 13:55:49 -0700, Moore, Robert wrote:
> The ACPI specification allows concurrent execution of control methods
> although methods cannot be preempted. The ACPICA interpreter mutex is
> used to implement this model. 
> 
> From section 5.5.2, "Control Method Execution": Interpretation of a
> Control Method is not preemptive, but it can block. When a control
> method does block, the operating software can initiate or continue the
> execution of a different control method. A control method can only
> assume that access to global objects is exclusive for any period the
> control method does not block.

Do I/O regions count as "global objects"?

> Therefore, the interpreter lock is acquired and a control method is
> allowed to execute to completion unless it blocks on one of the events
> described below. If the method blocks, the interpreter is unlocked and
> other control methods may execute.
> 
> I'm not sure what you mean by "in the middle of an SMBus transaction", I
> don't know how long such a transaction is valid. I might guess that a
> single transaction can only span a single operation region access, but
> I'm not sure of this.

Basically an SMBus transaction looks like this:
1* Prepare the transaction.
2* Start the transaction.
3* Wait for the transaction to complete, typically a few ms.
4* Read the result of the transaction.

Steps 1 and 2 require writing to the SMBus I/O region. Step 4 requires
reading from it, and so does step 3 if the wait loop is poll-based. The
transaction is only safe if we have an exclusive access to the I/O
region during all the 4 steps. My fear is that step 3 could be
implemented by ACPI using either a Sleep() or Acquire() or Wait()
opcode. If it is, we're doomed. OTOH, if it does, it is probably not
even safe for itself, unless there's an additional,
implementation-specific mutex to protect SMBus transactions. I yet have
to get my hands on the DSDT of ACPI implementations which actually
access the SMBus to see exactly how they do it.

> A user-installed operation region handler is an operation region handler
> that is installed by a device driver. This feature would probably only
> be used for custom (OEM-defined) operation region address spaces. (I
> have not seen one yet.) For the standard address spaces (memory, I/O,
> etc.), usually only the default handlers are used.

Could regular Linux device drivers install such handlers for a specific
I/O region? I'm asking because Rudolf Marek's proposal [1] to solve the
concurrent access problem involved extending struct resource with
callbacks to driver-specific routines to handle external access to an
I/O region. This sounds somewhat similar to these "user-installed
operation region handler" defined by ACPI, doesn't it? If ACPI already
has an infrastructure to handle this problem, we probably want to use
it rather than implementing our own.

[1] http://marc.info/?l=linux-kernel&m=117302946017204&w=2

-- 
Jean Delvare
-
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