Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1625354

Re: [PATCH] ACPICA: Export mutex functions

From "Rafael J. Wysocki" <rjw@rjwysocki.net>
Newsgroups linux.kernel
Subject Re: [PATCH] ACPICA: Export mutex functions
Date 2017-04-18 16:30 +0200
Message-ID <txCiJ-7dQ-7@gated-at.bofh.it> (permalink)
References <tvsxb-6br-3@gated-at.bofh.it> <txvAC-3i3-9@gated-at.bofh.it> <txBPH-6OW-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-12 17:20 +0200
  RE: [PATCH] ACPICA: Export mutex functions "Moore, Robert" <robert.moore@intel.com> - 2017-04-12 17:40 +0200
    Re: [PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-12 23:30 +0200
      RE: [PATCH] ACPICA: Export mutex functions "Moore, Robert" <robert.moore@intel.com> - 2017-04-13 00:00 +0200
        Re: [PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-13 03:00 +0200
        Re: [PATCH] ACPICA: Export mutex functions "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-04-15 00:40 +0200
          RE: [PATCH] ACPICA: Export mutex functions "Moore, Robert" <robert.moore@intel.com> - 2017-04-15 01:40 +0200
      RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-17 11:40 +0200
        RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-17 11:50 +0200
          Re: [PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-17 16:10 +0200
            RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-18 01:40 +0200
        Re: [PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-17 18:00 +0200
          RE: [PATCH] ACPICA: Export mutex functions "Moore, Robert" <robert.moore@intel.com> - 2017-04-17 19:20 +0200
            RE: [PATCH] ACPICA: Export mutex functions "Moore, Robert" <robert.moore@intel.com> - 2017-04-17 21:30 +0200
              Re: [PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-17 21:50 +0200
                RE: [PATCH] ACPICA: Export mutex functions "Moore, Robert" <robert.moore@intel.com> - 2017-04-17 22:50 +0200
                Re: [PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-17 23:10 +0200
                Re: [PATCH] ACPICA: Export mutex functions "Rafael J. Wysocki" <rafael@kernel.org> - 2017-04-17 23:30 +0200
                Re: [PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-18 00:40 +0200
                Re: [PATCH] ACPICA: Export mutex functions "Rafael J. Wysocki" <rafael@kernel.org> - 2017-04-18 01:00 +0200
                RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-18 02:00 +0200
                Re: [PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-18 06:40 +0200
                RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-18 09:10 +0200
                RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-18 09:20 +0200
                Re: [PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-18 16:00 +0200
                Re: [PATCH] ACPICA: Export mutex functions "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-04-18 16:30 +0200
                RE: [PATCH] ACPICA: Export mutex functions "Moore, Robert" <robert.moore@intel.com> - 2017-04-18 18:10 +0200
                RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-19 03:30 +0200
                RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-19 03:40 +0200
                RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-18 02:00 +0200
              RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-18 01:50 +0200
            RE: [PATCH] ACPICA: Export mutex functions "Moore, Robert" <robert.moore@intel.com> - 2017-04-17 21:40 +0200
          RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-18 01:40 +0200

csiph-web