1. 15 1月, 2011 1 次提交
  2. 14 12月, 2010 1 次提交
  3. 11 12月, 2010 7 次提交
  4. 10 12月, 2010 3 次提交
  5. 02 12月, 2010 2 次提交
  6. 14 11月, 2010 1 次提交
  7. 26 10月, 2010 2 次提交
  8. 25 10月, 2010 6 次提交
    • M
      ACPI: Page based coalescing of I/O remappings optimization · 4a3cba5e
      Myron Stowe 提交于
      This patch optimizes ACPI MMIO remappings by keeping track of the
      remappings on a PAGE_SIZE granularity.
      
      When an ioremap() occurs, the underlying infrastructure works on a 'page'
      based granularity.  As such, an ioremap() request for 1 byte for example,
      will end up mapping in an entire (PAGE_SIZE) page.  Huang Ying took
      advantage of this in commit 15651291 by
      checking if subsequent ioremap() requests reside within any of the list's
      existing remappings still in place, and if so, incrementing a reference
      count on the existing mapping as opposed to performing another ioremap().
      Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      4a3cba5e
    • M
      ACPI: Convert simple locking to RCU based locking · 78cdb3ed
      Myron Stowe 提交于
      Convert the simple locking introduced earlier for the ACPI MMIO
      remappings list to an RCU based locking scheme.
      Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      78cdb3ed
    • M
      ACPI: Pre-map 'system event' related register blocks · d362edaf
      Myron Stowe 提交于
      During ACPI initialization, pre-map fixed hardware registers that are
      accessed during ACPI's 'system event' related IRQ handing.
      
      ACPI's 'system event' handing accesses specific fixed hardware
      registers; namely PM1a event, PM1b event, GPE0, and GPE1 register
      blocks which are declared within the FADT.  If these registers are
      backed by MMIO, as opposed to I/O port space, accessing them within
      interrupt context will cause a panic as acpi_os_read_memory()
      depends on ioremap() in such cases - BZ 18012.
      
      By utilizing the functionality provided in the previous two patches -
      ACPI: Maintain a list of ACPI memory mapped I/O remappings, and, ACPI:
      Add interfaces for ioremapping/iounmapping ACPI registers - accesses
      to ACPI MMIO areas will now be safe from within interrupt contexts (IRQ
      and/or NMI) provided the area was pre-mapped.  This solves BZ 18012.
      
      ACPI "System Event" reference(s):
        ACPI Specification, Revision 4.0, Section 3 "ACPI Overview",
        3.8 "System Events", 5.6 "ACPI Event Programming Model".
      
      Reference: https://bugzilla.kernel.org/show_bug.cgi?id=18012
      
      Reported-by: <bjorn.helgaas@hp.com>
      Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      d362edaf
    • M
      ACPI: Add interfaces for ioremapping/iounmapping ACPI registers · 29718521
      Myron Stowe 提交于
      Add remapping and unmapping interfaces for ACPI registers that are
      backed by memory mapped I/O (MMIO).  These interfaces, along with
      the MMIO remapping list, enable accesses of such registers from within
      interrupt context.
      
      ACPI Generic Address Structure (GAS) reference (ACPI's fixed/generic
      hardware registers use the GAS format):
        ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address
        Structure".
      Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      29718521
    • M
      ACPI: Maintain a list of ACPI memory mapped I/O remappings · 620242ae
      Myron Stowe 提交于
      For memory mapped I/O (MMIO) remappings, add a list to maintain the
      remappings and augment the corresponding mapping and unmapping interface
      routines (acpi_os_map_memory() and acpi_os_unmap_memory()) to
      dynamically add to, and delete from, the list.
      
      The current ACPI I/O accessing methods - acpi_read() and acpi_write() -
      end up calling ioremap() when accessing MMIO.  This prevents use of these
      methods within interrupt context (IRQ and/or NMI), since ioremap() may
      block to allocate memory.  Maintaining a list of MMIO remappings enables
      accesses to such areas from within interrupt context provided they have
      been pre-mapped.
      Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      620242ae
    • M
      ACPI: Fix ioremap size for MMIO reads and writes · b3ba1efe
      Myron Stowe 提交于
      The size used for I/O remapping MMIO read and write accesses has not
      accounted for the basis of ACPI's Generic Address Structure (GAS)
      'Register Bit Width' field which is bits, not bytes.  This patch
      adjusts the ioremap() 'size' argument accordingly.
      
      ACPI "Generic Register" reference:
        ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address
        Structure".
      Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      b3ba1efe
  9. 24 10月, 2010 1 次提交
    • R
      ACPI / Battery: Return -ENODEV for unknown values in get_property() · a1b4bd69
      Rafael J. Wysocki 提交于
      The function acpi_battery_get_property() is called by the
      power supply framework's function power_supply_show_property()
      implementing the sysfs interface for power supply devices as the
      ACPI battery driver's ->get_property() callback.  Thus it is supposed
      to return error code if the value of the given property is unknown.
      Unfortunately, however, it returns 0 in those cases and puts a
      wrong (negative) value into the intval field of the
      union power_supply_propval object provided by
      power_supply_show_property().  In consequence, wrong negative
      values are read by user space from the battery's sysfs files.
      
      Fix this by making acpi_battery_get_property() return -ENODEV
      for properties with unknown values (-ENODEV is returned, because
      power_supply_uevent() returns with error for any other error code
      returned by power_supply_show_property()).
      Reported-and-tested-by: NSitsofe Wheeler <sitsofe@yahoo.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      a1b4bd69
  10. 23 10月, 2010 2 次提交
    • R
      ACPI / PM: Fix reference counting of power resources · 3e384ee6
      Rafael J. Wysocki 提交于
      The reference counting of ACPI power resources is currently broken
      for a few reasons.  First, instead of using a simple reference
      counter per power resource it uses a list of objects representing
      refereces to the given power resource from devices.  This leads to
      the second breakage, because it prevents power resources from
      being referenced more than once by one device, which is necessary
      if the device is configured to signal wakeup.  Namely, when putting
      the device into a low power state we first call
      acpi_enable_wakeup_device_power() that should reference count power
      resources needed for signaling wakeup and then we call
      acpi_power_transition() to power off the device.  The latter call
      drops references to the device's power resources, possibly including
      the ones added by acpi_enable_wakeup_device_power(), so the device
      can't signal wakeup as a result.  Apart from this, the locking
      in acpi_power_on() and acpi_power_off_device() doesn't prevent
      all possible races from happening, which may be problematic for
      runtime PM and asynchronous suspend and resume.
      
      Fix the problem by using a counter for power resources reference
      counting and putting the evaluation of ACPI _ON and _OFF methods
      under the power resource mutex.
      Reported-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      3e384ee6
    • B
      Subject: [PATCH] ACPICA: Fix Scope() op in module level code · 8df3fc98
      Bob Moore 提交于
      Some Panasonic Toughbooks create nodes in module level code.
      Module level code is the executable AML code outside of control method,
      for example, below AML code creates a node \_SB.PCI0.GFX0.DD02.CUBL
      
              If (\_OSI ("Windows 2006"))
              {
                  Scope (\_SB.PCI0.GFX0.DD02)
                  {
                      Name (CUBL, Ones)
                      ...
                  }
              }
      
      Scope() op does not actually create a new object, it refers to an
      existing object(\_SB.PCI0.GFX0.DD02 in above example). However, for
      Scope(), we want to indeed open a new scope, so the child nodes(CUBL in
      above example) can be created correctly under it.
      
      https://bugzilla.kernel.org/show_bug.cgi?id=19462Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NLin Ming <ming.m.lin@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      8df3fc98
  11. 22 10月, 2010 2 次提交
    • Z
      ACPI battery: support percentage battery remaining capacity · 557d5868
      Zhang Rui 提交于
      According to the ACPI spec, some kinds of primary battery can
      report percentage battery remaining capacity directly to OS.
      
      In this case, it reports the LastFullChargedCapacity == 100,
      BatteryPresentRate = 0xFFFFFFFF, and BatteryRemaingCapacity a
      percentage value, which actually means RemainingBatteryPercentage.
      
      Now we found some battery follows this rule even if it's a rechargeable.
      https://bugzilla.kernel.org/show_bug.cgi?id=15979
      
      Handle these batteries correctly in ACPI battery driver
      so that they won't break userspace.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Tested-by: NSitsofe Wheeler <sitsofe@yahoo.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      557d5868
    • T
      ACPI: Make Embedded Controller command timeout delay configurable · 7a18e96d
      Thomas Renninger 提交于
      Here and then there show up machines which need higher timeout values.
      Finding this on affected machines can be cumbersome, because
      ACPI_EC_DELAY is a compile option -> make it configurable via boot param.
      
      This can even be provided writable at runtime via:
      /sys/modules/acpi/parameters/ec_delay
      
      Known machines where this helps:
      Some HP machines where for whatever reasons specific EC accesses take
      very long at resume from S3 (in _WAK function).
      The AE_TIME error is passed upwards and the ACPI interpreter will
      not execute the rest of the _WAK function which results in not properly
      initialized devices/variables with different side-effects.
      
      Afaik, on some MSI machines this helped as well.
      
      If this param is needed there probably are underlying problems like:
        - EC firmware bug
        - A kernel EC driver bug
        - An ACPI interpreter behavior (e.g. timings when specific
          EC accesses happen and how) which the EC does not like
        - ...
      which should get evaluated further, but often are nasty or
      impossible to fix from OS side.
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      7a18e96d
  12. 20 10月, 2010 5 次提交
  13. 18 10月, 2010 5 次提交
  14. 16 10月, 2010 2 次提交