> -----Original Message----- > From: Rafael J. Wysocki [mailto:rjw@xxxxxxxxxxxxx] > Sent: Tuesday, April 18, 2017 7:15 AM > To: Guenter Roeck <linux@xxxxxxxxxxxx> > Cc: Zheng, Lv <lv.zheng@xxxxxxxxx>; Rafael J. Wysocki > <rafael@xxxxxxxxxx>; Moore, Robert <robert.moore@xxxxxxxxx>; Wysocki, > Rafael J <rafael.j.wysocki@xxxxxxxxx>; Len Brown <lenb@xxxxxxxxxx>; > linux-acpi@xxxxxxxxxxxxxxx; devel@xxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; Box, David E <david.e.box@xxxxxxxxx> > Subject: Re: [PATCH] ACPICA: Export mutex functions > > 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 Yes, agreed. Bob -- 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
