1. 26 9月, 2009 3 次提交
  2. 22 9月, 2009 1 次提交
  3. 27 8月, 2009 1 次提交
    • B
      ACPICA: Major update for acpi_get_object_info external interface · 15b8dd53
      Bob Moore 提交于
      Completed a major update for the acpi_get_object_info external interface.
      Changes include:
       - Support for variable, unlimited length HID, UID, and CID strings
       - Support Processor objects the same as Devices (HID,UID,CID,ADR,STA, etc.)
       - Call the _SxW power methods on behalf of a device object
       - Determine if a device is a PCI root bridge
       - Change the ACPI_BUFFER parameter to ACPI_DEVICE_INFO.
      These changes will require an update to all callers of this interface.
      See the ACPICA Programmer Reference for details.
      
      Also, update all invocations of acpi_get_object_info interface
      Signed-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>
      15b8dd53
  4. 10 8月, 2009 1 次提交
  5. 08 8月, 2009 1 次提交
  6. 20 7月, 2009 1 次提交
  7. 05 6月, 2009 1 次提交
  8. 28 5月, 2009 1 次提交
    • B
      PNPACPI: parse Extended Address Space Descriptors · 8cb24c8f
      Bjorn Helgaas 提交于
      Extended Address Space Descriptors are new in ACPI 3.0 and allow the
      BIOS to communicate device resource cacheability attributes (write-back,
      write-through, uncacheable, etc) to the OS.
      
      Previously, PNPACPI ignored these descriptors, so if a BIOS used them,
      a device could be responding at addresses the OS doesn't know about.
      This patch adds support for these descriptors in _CRS and _PRS.  We
      don't attempt to encode them for _SRS (just like we don't attempt to
      encode the existing 16-, 32-, and 64-bit Address Space Descriptors).
      
      Unfortunately, I don't have a way to test this.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      8cb24c8f
  9. 08 5月, 2009 1 次提交
  10. 28 4月, 2009 1 次提交
    • Y
      irq: change ACPI GSI APIs to also take a device argument · a2f809b0
      Yinghai Lu 提交于
      We want to use dev_to_node() later on, to be aware of the 'home node'
      of the GSI in question.
      
      [ Impact: cleanup, prepare the IRQ code to be more NUMA aware ]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NLen Brown <lenb@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: linux-acpi@vger.kernel.org
      Cc: linux-ia64@vger.kernel.org
      LKML-Reference: <49F65560.20904@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a2f809b0
  11. 07 4月, 2009 1 次提交
  12. 04 4月, 2009 1 次提交
    • W
      Enable PNPACPI _PSx Support, v3 · 6328a574
      Witold Szczeponik 提交于
      (This is an update to the patch presented earlier in
      http://lkml.org/lkml/2008/12/8/284, with new error handling.)
      
      This patch sets the power of PnP ACPI devices to D0 when they
      are activated and to D3 when they are disabled.  The latter is
      in correspondence with the ACPI 3.0 specification, whereas the
      former is added in order to be able to power up a device after
      it has been previously disabled (or when booting up a system).
      (As a consequence, the patch makes the PnP ACPI code more ACPI
      compliant.)
      
      Section 6.2.2 of the ACPI Specification (at least versions 1.0b
      and 3.0a) states: "Prior to running this control method [_DIS],
      the OS[PM] will have already put the device in the D3 state."
      Unfortunately, there is no clear statement as to when to put
      a device in the D0 state. :-( Therefore, the patch executes the
      method calls as _PS3/_DIS and _SRS/_PS0. What is clear: "If the
      device is disabled, _SRS enables the device at the specified
      resources." (From the ACPI 3.0a Specification.)
      
      The patch fixes a problem with some IBM ThinkPads (at least the
      600E and the 600X) where the serial ports have a dedicated
      power source that needs to be brought up before the serial port
      can be used.  Without this patch, the serial port is enabled
      but has no power. (In the past, the tpctl utility had to be
      utilized to turn on the power, but support for this feature
      stopped with version 5.9 as it did not support the more recent
      kernel versions.)
      
      The error handlers that handle any errors that can occur during
      the power up/power down phases return the error codes to the
      caller directly.  Comments welcome! :-)
      
      No regressions were observed on hardware that does not require
      this patch.
      
      The patch is applied against 2.6.27.x.
      Signed-off-by: NWitold Szczeponik <Witold.Szczeponik@gmx.net>
      Acked-by: NZhao Yakui <yakui.zhao@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      6328a574
  13. 03 4月, 2009 2 次提交
  14. 07 1月, 2009 1 次提交
  15. 01 1月, 2009 1 次提交
  16. 31 12月, 2008 1 次提交
  17. 05 11月, 2008 1 次提交
  18. 23 10月, 2008 1 次提交
  19. 17 10月, 2008 4 次提交
  20. 11 10月, 2008 8 次提交
  21. 10 10月, 2008 1 次提交
    • L
      PnP: move pnpacpi/pnpbios_init to after PCI init · ed458df4
      Linus Torvalds 提交于
      We already did that a long time ago for pnp_system_init, but
      pnpacpi_init and pnpbios_init remained as subsys_initcalls, and get
      linked into the kernel before the arch-specific routines that finalize
      the PCI resources (pci_subsys_init).
      
      This means that the PnP routines would either register their resources
      before the PCI layer could, or would be unable to check whether a PCI
      resource had already been registered.  Both are problematic.
      
      I wanted to do this before 2.6.27, but every time we change something
      like this, something breaks.  That said, _every_ single time we trust
      some firmware (like PnP tables) more than we trust the hardware itself
      (like PCI probing), the problems have been worse.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ed458df4
  22. 23 9月, 2008 1 次提交
  23. 25 8月, 2008 1 次提交
    • B
      PNPACPI: ignore the producer/consumer bit for extended IRQ descriptors · de82ff78
      Bjorn Helgaas 提交于
      The Extended Interrupt descriptor has a producer/consumer bit, but
      it's not clear what that would mean, and existing BIOSes use the bit
      inconsistently.  This patch makes Linux PNPACPI ignore the bit.
      
      The ACPI spec contains examples of PCI Interrupt Link devices marked
      as ResourceProducers, but many BIOSes mark them as ResourceConsumers.
      
      I also checked with a Windows contact, who said:
      
          Windows uses only "resource consumer" when dealing with
          interrupts.  There's no useful way of looking at a resource
          producer of interrupts.
      
          ... NT-based Windows largely infers the producer/consumer stuff
          from the device type and ignores the bits in the namespace.  This
          was necessary because Windows 98 ignored them and early namespaces
          contained random junk.
      
      The reason I want to change this is because if PNPACPI devices exclude
      ResourceProducer IRQ resources, we can't write PNP drivers for those
      devices.
      
      For example, on machines such as the the HP rx7620, rx7640, rx8620,
      rx8640, and Superdome, HPET interrupts are ResourceProducers.  The
      HPET driver currently has to use acpi_bus_register_driver() and do its
      own _CRS parsing, even though it requires absolutely no ACPI-specific
      functionality.
      
      It would be better if the HPET driver were a PNP driver and took
      advantage of the _CRS parsing built into PNPACPI.
      
      This producer/consumer check was originally added here:
          http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2b8de5f50e4a302b83ebcd5b0120621336d50bd6
      
      to fix this bug:
          http://bugzilla.kernel.org/show_bug.cgi?id=6292
      
      However, the bug was related only to memory and I/O port resources,
      where the distinction is sensible and important to Linux.  Given that
      the distinction is muddled for IRQ resources, I think it was a mistake
      to add the check there.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      de82ff78
  24. 02 8月, 2008 1 次提交
  25. 27 7月, 2008 3 次提交
反馈
建议
客服 返回
顶部