Re: [PATCH] ACPICA: Export mutex functions

[Rafael J. Wysocki]

On Tuesday, April 18, 2017 06:50:26 AM Guenter Roeck wrote:
> On 04/18/2017 12:14 AM, Zheng, Lv wrote:
> > Hi,

[cut]

> >
> > Maybe I should provide more detailed examples for this solution.
> >
> > For example:
> > OperationRegion (SIOT, SuperIOAddressSpace, Zero, 100)
> > Field (SIOT, ByteAcc, Lock, Preserve)
> > {
> >     FNC1, 8,
> >     FNC2, 8,
> >     ...
> > }
> >
> > Acquire (MUX0)
> > Store (0, FNC1)
> > Release (MUX0)
> >
> > Then you can call (let me use casual pseudo code)
> > acpi_install_operation_region(SuperIOAddressSpace, superio_opregion_handler) from OS side.
> > In its callback superio_opregion_handler(), you can:
> >
> > superio_enter();
> > If (address == 0) {
> >    /* mean FNC1 */
> >    Perform the locked superior accesses
> > } else if (address == 1) {
> >    /* mean FNC2 */
> >    Perform the locked superior accesses
> > }
> > superio_exit();
> >
> > Are there similar approach in your DSDT?
> >
> 
> Some snippets from the DSDT:
> 
> 	Device (SIO1)
>             {
>          	Name (_HID, EisaId ("PNP0C02") /* PNP Motherboard Resources */)  // _HID: Hardware ID
>          	Name (_UID, Zero)  // _UID: Unique ID
> 		...
> 		Mutex (MUT0, 0x00)
> 		Method (ENFG, 1, NotSerialized)
>                      {
>                          Acquire (MUT0, 0x0FFF)
>                          INDX = 0x87
>                          INDX = One
>                          INDX = 0x55
>                          If ((SP1O == 0x2E))
>                          {
>                              INDX = 0x55
>                          }
>                          Else
>                          {
>                              INDX = 0xAA
>                          }
> 
>                          LDN = Arg0
>                      }
> 
>                      Method (EXFG, 0, NotSerialized)
>                      {
>                          INDX = 0x02
>                          DATA = 0x02
>                          Release (MUT0)
>                      }
> 
> 		    OperationRegion (IOID, SystemIO, SP1O, 0x02)	/* SP1O is 0x2e */
>                      Field (IOID, ByteAcc, NoLock, Preserve)
>                      {
>                          INDX,   8,
>                          DATA,   8
>                      }
> 		    ...
> 
> Example for use:
> 		Method (DCNT, 2, NotSerialized)
>                      {
>                          ENFG (CGLD (Arg0))
>                          If (((DMCH < 0x04) && ((Local1 = (DMCH & 0x03)) != Zero)))
>                          {
>                              RDMA (Arg0, Arg1, Local1++)
>                          }
> 
>                          ACTR = Arg1
>                          Local1 = (IOAH << 0x08)
>                          Local1 |= IOAL
>                          RRIO (Arg0, Arg1, Local1, 0x08)
>                          EXFG ()
>                      }
> 
> Can there be more than one address space handler for a given region ?
> Each driver accessing the resource would need that handler.

Rather, every driver accessing the resource would need to be aware of the
existence of the operation region handler and would need to use the mutual
exclusion mechanism used by that handler, if my understanding here is correct.

The existence of an operation region for a specific section of address space is
a declaration that AML is going to access locations in that section.  It allows
the OS to install a handler for that region to intercept AML accesses and do
what it likes with them.

Thanks,
Rafael