> Could regular Linux device drivers install such handlers for a specific > I/O region? No. ACPICA only supports operation region handlers on a per-address-space basis, not per-region. > 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. As far as the AML interpreter is concerned, access to the SMBus is via an operation region. So, each access to such a region would encompass a single SMBus transaction. Also, the interpreter remains locked during this access (I'm fairly sure) even though the EC driver is involved. > > 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"? I think the spec is referring to any global namespace object. This includes operation regions, so the answer is yes, as long as access to the region does not block and cause the interpreter to be released. As far as ACPICA, none of the default handlers for operation regions will block. Bob > -----Original Message----- > From: Jean Delvare [mailto:khali@xxxxxxxxxxxx] > Sent: Tuesday, April 03, 2007 12:21 AM > To: Moore, Robert > Cc: Pavel Machek; Brown, Len; Matthew Garrett; Chuck Ebbert; Rudolf Marek; > linux-acpi@xxxxxxxxxxxxxxx; linux-kernel; lm-sensors@xxxxxxxxxxxxxx > 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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
