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
