1. 16 12月, 2014 1 次提交
  2. 10 10月, 2014 1 次提交
  3. 22 9月, 2014 1 次提交
  4. 23 7月, 2014 1 次提交
  5. 27 6月, 2014 1 次提交
    • L
      I2C/ACPI: Add i2c ACPI operation region support · 5d98e61d
      Lan Tianyu 提交于
      ACPI 5.0 spec(5.5.2.4.5) defines GenericSerialBus(i2c, spi, uart) operation region.
      It allows ACPI aml code able to access such kind of devices to implement
      some ACPI standard method.
      
      ACPI Spec defines some access attribute to associate with i2c protocol.
      AttribQuick 	       	       		Read/Write Quick Protocol
      AttribSendReceive			Send/Receive Byte Protocol
      AttribByte 			 	Read/Write Byte Protocol
      AttribWord				Read/Write Word Protocol
      AttribBlock				Read/Write Block Protocol
      AttribBytes				Read/Write N-Bytes Protocol
      AttribProcessCall			Process Call Protocol
      AttribBlockProcessCall			Write Block-Read Block Process Call Protocol
      AttribRawBytes 				Raw Read/Write N-BytesProtocol
      AttribRawProcessBytes			Raw Process Call Protocol
      
      On the Asus T100TA, Bios use GenericSerialBus operation region to access
      i2c device to get battery info.
      
      Sample code From Asus T100TA
      
          Scope (_SB.I2C1)
          {
              Name (UMPC, ResourceTemplate ()
              {
                  I2cSerialBus (0x0066, ControllerInitiated, 0x00061A80,
                      AddressingMode7Bit, "\\_SB.I2C1",
                      0x00, ResourceConsumer, ,
                      )
              })
      
      	...
      
              OperationRegion (DVUM, GenericSerialBus, Zero, 0x0100)
              Field (DVUM, BufferAcc, NoLock, Preserve)
              {
                  Connection (UMPC),
                  Offset (0x81),
                  AccessAs (BufferAcc, AttribBytes (0x3E)),
                  FGC0,   8
              }
      	...
           }
      
           Device (BATC)
           {
               Name (_HID, EisaId ("PNP0C0A"))  // _HID: Hardware ID
               Name (_UID, One)  // _UID: Unique ID
      	 ...
      
                  Method (_BST, 0, NotSerialized)  // _BST: Battery Status
                  {
                      If (LEqual (AVBL, One))
                      {
                          Store (FGC0, BFFG)
                          If (LNotEqual (STAT, One))
                          {
                              ShiftRight (CHST, 0x04, Local0)
                              And (Local0, 0x03, Local0)
                              If (LOr (LEqual (Local0, One), LEqual (Local0, 0x02)))
                              {
                                  Store (0x02, Local1)
                              }
      	...
      
          }
      
      The i2c operation region is defined under I2C1 scope. _BST method under
      battery device BATC read battery status from the field "FCG0". The request
      would be sent to i2c operation region handler.
      
      This patch is to add i2c ACPI operation region support. Due to there are
      only "Byte" and "Bytes" protocol access on the Asus T100TA, other protocols
      have not been tested.
      
      About RawBytes and RawProcessBytes protocol, they needs specific drivers to interpret
      reference data from AML code according ACPI 5.0 SPEC(5.5.2.4.5.3.9 and 5.5.2.4.5.3.10).
      So far, not found such case and will add when find real case.
      Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      5d98e61d
  6. 30 5月, 2014 1 次提交
    • Z
      ACPI / PNP: use device ID list for PNPACPI device enumeration · eec15edb
      Zhang Rui 提交于
      ACPI can be used to enumerate PNP devices, but the code does not
      handle this in the right way currently.  Namely, if an ACPI device
      object
       1. Has a _CRS method,
       2. Has an identification of
          "three capital characters followed by four hex digits",
       3. Is not in the excluded IDs list,
      it will be enumerated to PNP bus (that is, a PNP device object will
      be create for it).  This means that, actually, the PNP bus type is
      used as the default bus type for enumerating _HID devices in ACPI.
      
      However, more and more _HID devices need to be enumerated to the
      platform bus instead (that is, platform device objects need to be
      created for them).  As a result, the device ID list in acpi_platform.c
      is used to enforce creating platform device objects rather than PNP
      device objects for matching devices.  That list has been continuously
      growing recently, unfortunately, and it is pretty much guaranteed to
      grow even more in the future.
      
      To address that problem it is better to enumerate _HID devices
      as platform devices by default.  To this end, change the way of
      enumerating PNP devices by adding a PNP ACPI scan handler that
      will use a device ID list to create PNP devices for the ACPI
      device objects whose device IDs are present in that list.
      
      The initial device ID list in the PNP ACPI scan handler contains
      all of the pnp_device_id strings from all the existing PNP drivers,
      so this change should be transparent to the PNP core and all of the
      PNP drivers.  Still, in the future it should be possible to reduce
      its size by converting PNP drivers that need not be PNP for any
      technical reasons into platform drivers.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      [rjw: Rewrote the changelog, modified the PNP ACPI scan handler code]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      eec15edb
  7. 26 5月, 2014 1 次提交
    • B
      ACPI: add dynamic_debug support · 45fef5b8
      Bjørn Mork 提交于
      Commit 1a699476 ("ACPI / hotplug / PCI: Hotplug notifications
      from acpi_bus_notify()") added debug messages for a few common
      events. These debug messages are unconditionally enabled if
      CONFIG_DYNAMIC_DEBUG is defined, contrary to the documented
      meaning, making the ACPI system spew lots of unwanted noise on
      any kernel with dynamic debugging.
      
      The bug was introduced by commit fbfddae6 ("ACPI: Add
      acpi_handle_<level>() interfaces"), which added the
      CONFIG_DYNAMIC_DEBUG dependency without respecting its meaning.
      
      Fix by adding real support for dynamic_debug.
      
      Fixes: fbfddae6 ("ACPI: Add acpi_handle_<level>() interfaces")
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      45fef5b8
  8. 20 5月, 2014 1 次提交
  9. 19 2月, 2014 1 次提交
  10. 04 2月, 2014 2 次提交
  11. 17 1月, 2014 1 次提交
    • Z
      ACPI: add module autoloading support for ACPI enumerated devices · 6eb2451f
      Zhang Rui 提交于
      An ACPI enumerated device may have its compatible id strings.
      
      To support the compatible ACPI ids (acpi_device->pnp.ids),
      we introduced acpi_driver_match_device() to match
      the driver->acpi_match_table and acpi_device->pnp.ids.
      
      For those drivers, MODULE_DEVICE_TABLE(acpi, xxx) is used to
      exports the driver module alias in the format of
      "acpi:device_compatible_ids".
      But in the mean time, the current code does not export the
      ACPI compatible strings as part of the module_alias for the
      ACPI enumerated devices, which will break the module autoloading.
      
      Take the following piece of code for example,
      static const struct acpi_device_id xxx_acpi_match[] = {
              { "INTABCD", 0 },
              { }
      };
      MODULE_DEVICE_TABLE(acpi, xxx_acpi_match);
      
      If this piece of code is used in a platform driver for
      an ACPI enumerated platform device, the platform driver module_alias
      is "acpi:INTABCD", but the uevent attribute of its platform device node
      is "platform:INTABCD:00" (PREFIX:platform_device->name).
      If this piece of code is used in an i2c driver for an ACPI enumerated
      i2c device, the i2c driver module_alias is "acpi:INTABCD", but
      the uevent of its i2c device node is "i2c:INTABCD:00" (PREFIX:i2c_client->name).
      If this piece of code is used in an spi driver for an ACPI enumerated
      spi device, the spi driver module_alias is "acpi:INTABCD", but
      the uevent of its spi device node is "spi:INTABCD" (PREFIX:spi_device->modalias).
      
      The reason why the module autoloading is not broken for now is that
      the uevent file of the ACPI device node is "acpi:INTABCD".
      Thus it is the ACPI device node creation that loads the platform/i2c/spi driver.
      
      So this is a problem that will affect us the day when the ACPI bus
      is removed from device model.
      
      This patch introduces two new APIs,
      one for exporting ACPI ids in uevent MODALIAS field,
      and another for exporting ACPI ids in device' modalias sysfs attribute.
      
      For any bus that supports ACPI enumerated devices, it needs to invoke
      these two functions for their uevent and modalias attribute.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6eb2451f
  12. 06 1月, 2014 1 次提交
  13. 07 12月, 2013 2 次提交
  14. 15 11月, 2013 3 次提交
    • J
      ACPI: Provide acpi_dev_name accessor for struct acpi_device device name · 45c42a7f
      Jarkko Nikula 提交于
      struct acpi_device fields are only available when CONFIG_ACPI is set. We may
      find use for dev_name(&adev->dev) in generic code that is build also without
      CONFIG_ACPI is set but currently this requires #ifdef CONFIG_ACPI churn.
      
      Provide here an accessor that returns dev_name of embedded struct device dev
      in struct acpi_device or NULL depending on CONFIG_ACPI setting.
      Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      45c42a7f
    • R
      ACPI: Eliminate the DEVICE_ACPI_HANDLE() macro · 3a83f992
      Rafael J. Wysocki 提交于
      Since DEVICE_ACPI_HANDLE() is now literally identical to
      ACPI_HANDLE(), replace it with the latter everywhere and drop its
      definition from include/acpi.h.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3a83f992
    • R
      ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node · 7b199811
      Rafael J. Wysocki 提交于
      Modify struct acpi_dev_node to contain a pointer to struct acpi_device
      associated with the given device object (that is, its ACPI companion
      device) instead of an ACPI handle corresponding to it.  Introduce two
      new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
      ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
      ACPI_HANDLE() macro to take the above changes into account.
      Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
      use ACPI_COMPANION_SET() instead.  For some of them who used to
      pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
      introduce a helper routine acpi_preset_companion() doing an
      equivalent thing.
      
      The main motivation for doing this is that there are things
      represented by struct acpi_device objects that don't have valid
      ACPI handles (so called fixed ACPI hardware features, such as
      power and sleep buttons) and we would like to create platform
      device objects for them and "glue" them to their ACPI companions
      in the usual way (which currently is impossible due to the
      lack of valid ACPI handles).  However, there are more reasons
      why it may be useful.
      
      First, struct acpi_device pointers allow of much better type checking
      than void pointers which are ACPI handles, so it should be more
      difficult to write buggy code using modified struct acpi_dev_node
      and the new macros.  Second, the change should help to reduce (over
      time) the number of places in which the result of ACPI_HANDLE() is
      passed to acpi_bus_get_device() in order to obtain a pointer to the
      struct acpi_device associated with the given "physical" device,
      because now that pointer is returned by ACPI_COMPANION() directly.
      Finally, the change should make it easier to write generic code that
      will build both for CONFIG_ACPI set and unset without adding explicit
      compiler directives to it.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part
      7b199811
  15. 24 10月, 2013 1 次提交
  16. 24 9月, 2013 7 次提交
  17. 31 7月, 2013 1 次提交
  18. 26 7月, 2013 1 次提交
  19. 18 7月, 2013 1 次提交
    • R
      ACPI / video / i915: No ACPI backlight if firmware expects Windows 8 · 8c5bd7ad
      Rafael J. Wysocki 提交于
      According to Matthew Garrett, "Windows 8 leaves backlight control up
      to individual graphics drivers rather than making ACPI calls itself.
      There's plenty of evidence to suggest that the Intel driver for
      Windows [8] doesn't use the ACPI interface, including the fact that
      it's broken on a bunch of machines when the OS claims to support
      Windows 8.  The simplest thing to do appears to be to disable the
      ACPI backlight interface on these systems".
      
      There's a problem with that approach, however, because simply
      avoiding to register the ACPI backlight interface if the firmware
      calls _OSI for Windows 8 may not work in the following situations:
       (1) The ACPI backlight interface actually works on the given system
           and the i915 driver is not loaded (e.g. another graphics driver
           is used).
       (2) The ACPI backlight interface doesn't work on the given system,
           but there is a vendor platform driver that will register its
           own, equally broken, backlight interface if not prevented from
           doing so by the ACPI subsystem.
      Therefore we need to allow the ACPI backlight interface to be
      registered until the i915 driver is loaded which then will unregister
      it if the firmware has called _OSI for Windows 8 (or will register
      the ACPI video driver without backlight support if not already
      present).
      
      For this reason, introduce an alternative function for registering
      ACPI video, acpi_video_register_with_quirks(), that will check
      whether or not the ACPI video driver has already been registered
      and whether or not the backlight Windows 8 quirk has to be applied.
      If the quirk has to be applied, it will block the ACPI backlight
      support and either unregister the backlight interface if the ACPI
      video driver has already been registered, or register the ACPI
      video driver without the backlight interface otherwise.  Make
      the i915 driver use acpi_video_register_with_quirks() instead of
      acpi_video_register() in i915_driver_load().
      
      This change is based on earlier patches from Matthew Garrett,
      Chun-Yi Lee and Seth Forshee and includes a fix from Aaron Lu's.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=51231Tested-by: NAaron Lu <aaron.lu@intel.com>
      Tested-by: NIgor Gnatenko <i.gnatenko.brain@gmail.com>
      Tested-by: NYves-Alexis Perez <corsac@debian.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NAaron Lu <aaron.lu@intel.com>
      Acked-by: NMatthew Garrett <matthew.garrett@nebula.com>
      8c5bd7ad
  20. 19 6月, 2013 1 次提交
  21. 17 4月, 2013 1 次提交
  22. 25 3月, 2013 1 次提交
  23. 03 3月, 2013 1 次提交
    • Y
      x86, ACPI, mm: Revert movablemem_map support · 20e6926d
      Yinghai Lu 提交于
      Tim found:
      
        WARNING: at arch/x86/kernel/smpboot.c:324 topology_sane.isra.2+0x6f/0x80()
        Hardware name: S2600CP
        sched: CPU #1's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
        smpboot: Booting Node   1, Processors  #1
        Modules linked in:
        Pid: 0, comm: swapper/1 Not tainted 3.9.0-0-generic #1
        Call Trace:
          set_cpu_sibling_map+0x279/0x449
          start_secondary+0x11d/0x1e5
      
      Don Morris reproduced on a HP z620 workstation, and bisected it to
      commit e8d19552 ("acpi, memory-hotplug: parse SRAT before memblock
      is ready")
      
      It turns out movable_map has some problems, and it breaks several things
      
      1. numa_init is called several times, NOT just for srat. so those
      	nodes_clear(numa_nodes_parsed)
      	memset(&numa_meminfo, 0, sizeof(numa_meminfo))
         can not be just removed.  Need to consider sequence is: numaq, srat, amd, dummy.
         and make fall back path working.
      
      2. simply split acpi_numa_init to early_parse_srat.
         a. that early_parse_srat is NOT called for ia64, so you break ia64.
         b.  for (i = 0; i < MAX_LOCAL_APIC; i++)
      	     set_apicid_to_node(i, NUMA_NO_NODE)
           still left in numa_init. So it will just clear result from early_parse_srat.
           it should be moved before that....
         c.  it breaks ACPI_TABLE_OVERIDE...as the acpi table scan is moved
             early before override from INITRD is settled.
      
      3. that patch TITLE is total misleading, there is NO x86 in the title,
         but it changes critical x86 code. It caused x86 guys did not
         pay attention to find the problem early. Those patches really should
         be routed via tip/x86/mm.
      
      4. after that commit, following range can not use movable ram:
        a. real_mode code.... well..funny, legacy Node0 [0,1M) could be hot-removed?
        b. initrd... it will be freed after booting, so it could be on movable...
        c. crashkernel for kdump...: looks like we can not put kdump kernel above 4G
      	anymore.
        d. init_mem_mapping: can not put page table high anymore.
        e. initmem_init: vmemmap can not be high local node anymore. That is
           not good.
      
      If node is hotplugable, the mem related range like page table and
      vmemmap could be on the that node without problem and should be on that
      node.
      
      We have workaround patch that could fix some problems, but some can not
      be fixed.
      
      So just remove that offending commit and related ones including:
      
       f7210e6c ("mm/memblock.c: use CONFIG_HAVE_MEMBLOCK_NODE_MAP to
          protect movablecore_map in memblock_overlaps_region().")
      
       01a178a9 ("acpi, memory-hotplug: support getting hotplug info from
          SRAT")
      
       27168d38 ("acpi, memory-hotplug: extend movablemem_map ranges to
          the end of node")
      
       e8d19552 ("acpi, memory-hotplug: parse SRAT before memblock is
          ready")
      
       fb06bc8e ("page_alloc: bootmem limit with movablecore_map")
      
       42f47e27 ("page_alloc: make movablemem_map have higher priority")
      
       6981ec31 ("page_alloc: introduce zone_movable_limit[] to keep
          movable limit for nodes")
      
       34b71f1e ("page_alloc: add movable_memmap kernel parameter")
      
       4d59a751 ("x86: get pg_data_t's memory from other node")
      
      Later we should have patches that will make sure kernel put page table
      and vmemmap on local node ram instead of push them down to node0.  Also
      need to find way to put other kernel used ram to local node ram.
      Reported-by: NTim Gardner <tim.gardner@canonical.com>
      Reported-by: NDon Morris <don.morris@hp.com>
      Bisected-by: NDon Morris <don.morris@hp.com>
      Tested-by: NDon Morris <don.morris@hp.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Renninger <trenn@suse.de>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Tang Chen <tangchen@cn.fujitsu.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      20e6926d
  24. 24 2月, 2013 1 次提交
    • T
      acpi, memory-hotplug: parse SRAT before memblock is ready · e8d19552
      Tang Chen 提交于
      On linux, the pages used by kernel could not be migrated.  As a result,
      if a memory range is used by kernel, it cannot be hot-removed.  So if we
      want to hot-remove memory, we should prevent kernel from using it.
      
      The way now used to prevent this is specify a memory range by
      movablemem_map boot option and set it as ZONE_MOVABLE.
      
      But when the system is booting, memblock will allocate memory, and
      reserve the memory for kernel.  And before we parse SRAT, and know the
      node memory ranges, memblock is working.  And it may allocate memory in
      ranges to be set as ZONE_MOVABLE.  This memory can be used by kernel,
      and never be freed.
      
      So, let's parse SRAT before memblock is called first.  And it is early
      enough.
      
      The first call of memblock_find_in_range_node() is in:
      
        setup_arch()
          |-->setup_real_mode()
      
      so, this patch add a function early_parse_srat() to parse SRAT, and call
      it before setup_real_mode() is called.
      
      NOTE:
      
      1) early_parse_srat() is called before numa_init(), and has initialized
         numa_meminfo.  So DO NOT clear numa_nodes_parsed in numa_init() and DO
         NOT zero numa_meminfo in numa_init(), otherwise we will lose memory
         numa info.
      
      2) I don't know why using count of memory affinities parsed from SRAT
         as a return value in original acpi_numa_init().  So I add a static
         variable srat_mem_cnt to remember this count and use it as the return
         value of the new acpi_numa_init()
      
      [mhocko@suse.cz: parse SRAT before memblock is ready fix]
      Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>
      Reviewed-by: NWen Congyang <wency@cn.fujitsu.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Jiang Liu <jiang.liu@huawei.com>
      Cc: Jianguo Wu <wujianguo@huawei.com>
      Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Wu Jianguo <wujianguo@huawei.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: "Brown, Len" <len.brown@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e8d19552
  25. 13 2月, 2013 1 次提交
  26. 20 1月, 2013 1 次提交
  27. 11 1月, 2013 1 次提交
  28. 03 1月, 2013 1 次提交
  29. 05 12月, 2012 1 次提交
  30. 26 11月, 2012 1 次提交