1. 03 2月, 2017 1 次提交
  2. 02 12月, 2016 1 次提交
  3. 29 11月, 2016 2 次提交
    • L
      ACPI: Implement acpi_dma_configure · d760a1ba
      Lorenzo Pieralisi 提交于
      On DT based systems, the of_dma_configure() API implements DMA
      configuration for a given device. On ACPI systems an API equivalent to
      of_dma_configure() is missing which implies that it is currently not
      possible to set-up DMA operations for devices through the ACPI generic
      kernel layer.
      
      This patch fills the gap by introducing acpi_dma_configure/deconfigure()
      calls that for now are just wrappers around arch_setup_dma_ops() and
      arch_teardown_dma_ops() and also updates ACPI and PCI core code to use
      the newly introduced acpi_dma_configure/acpi_dma_deconfigure functions.
      
      Since acpi_dma_configure() is used to configure DMA operations, the
      function initializes the dma/coherent_dma masks to sane default values
      if the current masks are uninitialized (also to keep the default values
      consistent with DT systems) to make sure the device has a complete
      default DMA set-up.
      
      The DMA range size passed to arch_setup_dma_ops() is sized according
      to the device coherent_dma_mask (starting at address 0x0), mirroring the
      DT probing path behaviour when a dma-ranges property is not provided
      for the device being probed; this changes the current arch_setup_dma_ops()
      call parameters in the ACPI probing case, but since arch_setup_dma_ops()
      is a NOP on all architectures but ARM/ARM64 this patch does not change
      the current kernel behaviour on them.
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: Bjorn Helgaas <bhelgaas@google.com> [pci]
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NTomasz Nowicki <tn@semihalf.com>
      Tested-by: NHanjun Guo <hanjun.guo@linaro.org>
      Tested-by: NTomasz Nowicki <tn@semihalf.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Tomasz Nowicki <tn@semihalf.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      d760a1ba
    • L
      ACPI: Add FWNODE_ACPI_STATIC fwnode type · 027b25b2
      Lorenzo Pieralisi 提交于
      On systems booting with a device tree, every struct device is associated
      with a struct device_node, that provides its DT firmware representation.
      The device node can be used in generic kernel contexts (eg IRQ
      translation, IOMMU streamid mapping), to retrieve the properties
      associated with the device and carry out kernel operations accordingly.
      Owing to the 1:1 relationship between the device and its device_node,
      the device_node can also be used as a look-up token for the device (eg
      looking up a device through its device_node), to retrieve the device in
      kernel paths where the device_node is available.
      
      On systems booting with ACPI, the same abstraction provided by
      the device_node is required to provide look-up functionality.
      
      The struct acpi_device, that represents firmware objects in the
      ACPI namespace already includes a struct fwnode_handle of
      type FWNODE_ACPI as their member; the same abstraction is missing
      though for devices that are instantiated out of static ACPI tables
      entries (eg ARM SMMU devices).
      
      Add a new fwnode_handle type to associate devices created out
      of static ACPI table entries to the respective firmware components
      and create a simple ACPI core layer interface to dynamically allocate
      and free the corresponding firmware nodes so that kernel subsystems
      can use it to instantiate the nodes and associate them with the
      respective devices.
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
      Reviewed-by: NTomasz Nowicki <tn@semihalf.com>
      Tested-by: NHanjun Guo <hanjun.guo@linaro.org>
      Tested-by: NTomasz Nowicki <tn@semihalf.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      027b25b2
  4. 25 11月, 2016 1 次提交
  5. 17 11月, 2016 1 次提交
  6. 10 11月, 2016 1 次提交
  7. 24 10月, 2016 1 次提交
  8. 12 10月, 2016 1 次提交
    • M
      ACPI / property: Allow holes in reference properties · b60e4ea4
      Mika Westerberg 提交于
      DT allows holes or empty phandles for references. This is used for example
      in SPI subsystem where some chip selects are native and others are regular
      GPIOs. In ACPI _DSD we currently do not support this but instead the
      preceding reference consumes all following integer arguments.
      
      For example we would like to support something like the below ASL fragment
      for SPI:
      
        Package () {
            "cs-gpios",
            Package () {
                ^GPIO, 19, 0, 0, // GPIO CS0
                0,               // Native CS
                ^GPIO, 20, 0, 0, // GPIO CS1
            }
        }
      
      The zero in the middle means "no entry" or NULL reference. To support this
      we change acpi_data_get_property_reference() to take firmware node and
      num_args as argument and rename it to __acpi_node_get_property_reference().
      The function returns -ENOENT if the given index resolves to "no entry"
      reference and -ENODATA when there are no more entries in the property.
      
      We then add static inline wrapper acpi_node_get_property_reference() that
      passes MAX_ACPI_REFERENCE_ARGS as num_args to support the existing
      behaviour which some drivers have been relying on.
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b60e4ea4
  9. 28 9月, 2016 1 次提交
  10. 24 9月, 2016 1 次提交
    • M
      ACPI / watchdog: Add support for WDAT hardware watchdog · 058dfc76
      Mika Westerberg 提交于
      Starting from Intel Skylake the iTCO watchdog timer registers were moved to
      reside in the same register space with SMBus host controller.  Not all
      needed registers are available though and we need to unhide P2SB (Primary
      to Sideband) device briefly to be able to read status of required NO_REBOOT
      bit. The i2c-i801.c SMBus driver used to handle this and creation of the
      iTCO watchdog platform device.
      
      Windows, on the other hand, does not use the iTCO watchdog hardware
      directly even if it is available. Instead it relies on ACPI Watchdog Action
      Table (WDAT) table to describe the watchdog hardware to the OS. This table
      contains necessary information about the the hardware and also set of
      actions which are executed by a driver as needed.
      
      This patch implements a new watchdog driver that takes advantage of the
      ACPI WDAT table. We split the functionality into two parts: first part
      enumerates the WDAT table and if found, populates resources and creates
      platform device for the actual driver. The second part is the driver
      itself.
      
      The reason for the split is that this way we can make the driver itself to
      be a module and loaded automatically if the WDAT table is found. Otherwise
      the module is not loaded.
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      058dfc76
  11. 22 9月, 2016 2 次提交
    • D
      acpi: Validate processor id when mapping the processor · fd74da21
      Dou Liyang 提交于
      When we want to identify whether the proc_id is unreasonable or not, we
      can call the "acpi_processor_validate_proc_id" function. It will search
      in the duplicate IDs. If we find the proc_id in the IDs, we return true
      to the call function. Conversely, the false represents available.
      
      When we establish all possible cpuid <-> nodeid mapping to handle the
      cpu hotplugs, we will use the proc_id from ACPI table.
      
      We do validation when we get the proc_id. If the result is true, we
      will stop the mapping.
      
      [ tglx: Mark the new function __init ]
      Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Cc: mika.j.penttila@gmail.com
      Cc: len.brown@intel.com
      Cc: rafael@kernel.org
      Cc: rjw@rjwysocki.net
      Cc: yasu.isimatu@gmail.com
      Cc: linux-mm@kvack.org
      Cc: linux-acpi@vger.kernel.org
      Cc: isimatu.yasuaki@jp.fujitsu.com
      Cc: gongzhaogang@inspur.com
      Cc: tj@kernel.org
      Cc: izumi.taku@jp.fujitsu.com
      Cc: cl@linux.com
      Cc: chen.tang@easystack.cn
      Cc: akpm@linux-foundation.org
      Cc: kamezawa.hiroyu@jp.fujitsu.com
      Cc: lenb@kernel.org
      Link: http://lkml.kernel.org/r/1472114120-3281-8-git-send-email-douly.fnst@cn.fujitsu.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      fd74da21
    • G
      x86/acpi: Set persistent cpuid <-> nodeid mapping when booting · dc6db24d
      Gu Zheng 提交于
      The whole patch-set aims at making cpuid <-> nodeid mapping persistent. So that,
      when node online/offline happens, cache based on cpuid <-> nodeid mapping such as
      wq_numa_possible_cpumask will not cause any problem.
      It contains 4 steps:
      1. Enable apic registeration flow to handle both enabled and disabled cpus.
      2. Introduce a new array storing all possible cpuid <-> apicid mapping.
      3. Enable _MAT and MADT relative apis to return non-present or disabled cpus' apicid.
      4. Establish all possible cpuid <-> nodeid mapping.
      
      This patch finishes step 4.
      
      This patch set the persistent cpuid <-> nodeid mapping for all enabled/disabled
      processors at boot time via an additional acpi namespace walk for processors.
      
      [ tglx: Remove the unneeded exports ]
      Signed-off-by: NGu Zheng <guz.fnst@cn.fujitsu.com>
      Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>
      Signed-off-by: NZhu Guihua <zhugh.fnst@cn.fujitsu.com>
      Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Cc: mika.j.penttila@gmail.com
      Cc: len.brown@intel.com
      Cc: rafael@kernel.org
      Cc: rjw@rjwysocki.net
      Cc: yasu.isimatu@gmail.com
      Cc: linux-mm@kvack.org
      Cc: linux-acpi@vger.kernel.org
      Cc: isimatu.yasuaki@jp.fujitsu.com
      Cc: gongzhaogang@inspur.com
      Cc: tj@kernel.org
      Cc: izumi.taku@jp.fujitsu.com
      Cc: cl@linux.com
      Cc: chen.tang@easystack.cn
      Cc: akpm@linux-foundation.org
      Cc: kamezawa.hiroyu@jp.fujitsu.com
      Cc: lenb@kernel.org
      Link: http://lkml.kernel.org/r/1472114120-3281-6-git-send-email-douly.fnst@cn.fujitsu.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      dc6db24d
  12. 03 9月, 2016 1 次提交
    • L
      ACPI / drivers: fix typo in ACPI_DECLARE_PROBE_ENTRY macro · 3feab13c
      Lorenzo Pieralisi 提交于
      When the ACPI_DECLARE_PROBE_ENTRY macro was added in
      commit e647b532 ("ACPI: Add early device probing infrastructure"),
      a stub macro adding an unused entry was added for the !CONFIG_ACPI
      Kconfig option case to make sure kernel code making use of the
      macro did not require to be guarded within CONFIG_ACPI in order to
      be compiled.
      
      The stub macro was never used since all kernel code that defines
      ACPI_DECLARE_PROBE_ENTRY entries is currently guarded within
      CONFIG_ACPI; it contains a typo that should be nonetheless fixed.
      
      Fix the typo in the stub (ie !CONFIG_ACPI) ACPI_DECLARE_PROBE_ENTRY()
      macro so that it can actually be used if needed.
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Fixes: e647b532 (ACPI: Add early device probing infrastructure)
      Cc: 4.4+ <stable@vger.kernel.org> # 4.4+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3feab13c
  13. 31 8月, 2016 1 次提交
    • L
      ACPI / bus: Make acpi_get_first_physical_node() public · daae45ca
      Lukas Wunner 提交于
      Following the fwnode of a device is currently a one-way road: We provide
      ACPI_COMPANION() to obtain the fwnode but there's no (public) method to
      do the reverse. Granted, there may be multiple physical_nodes, but often
      the first one in the list is sufficient.
      
      A handy function to obtain it was introduced with commit 3b95bd16
      ("ACPI: introduce a function to find the first physical device"), but
      currently it's only available internally.
      
      We're about to add an EFI Device Path parser which needs this function.
      Consider the following device path: ACPI(PNP0A03,0)/PCI(28,2)/PCI(0,0)
      The PCI root is encoded as an ACPI device in the path, so the parser
      has to find the corresponding ACPI device, then find its physical node,
      find the PCI bridge in slot 1c (decimal 28), function 2 below it and
      finally find the PCI device in slot 0, function 0.
      
      To this end, make acpi_get_first_physical_node() public.
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      daae45ca
  14. 18 8月, 2016 1 次提交
  15. 22 7月, 2016 1 次提交
    • S
      ACPI / processor_idle: Add support for Low Power Idle(LPI) states · a36a7fec
      Sudeep Holla 提交于
      ACPI 6.0 introduced an optional object _LPI that provides an alternate
      method to describe Low Power Idle states. It defines the local power
      states for each node in a hierarchical processor topology. The OSPM can
      use _LPI object to select a local power state for each level of processor
      hierarchy in the system. They used to produce a composite power state
      request that is presented to the platform by the OSPM.
      
      Since multiple processors affect the idle state for any non-leaf hierarchy
      node, coordination of idle state requests between the processors is
      required. ACPI supports two different coordination schemes: Platform
      coordinated and  OS initiated.
      
      This patch adds initial support for Platform coordination scheme of LPI.
      Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a36a7fec
  16. 09 7月, 2016 2 次提交
  17. 26 6月, 2016 1 次提交
  18. 22 6月, 2016 2 次提交
  19. 05 6月, 2016 2 次提交
  20. 30 5月, 2016 1 次提交
  21. 05 5月, 2016 5 次提交
  22. 19 4月, 2016 1 次提交
    • L
      ACPI / tables: Move table override mechanisms to tables.c · 5ae74f2c
      Lv Zheng 提交于
      This patch moves acpi_os_table_override() and
      acpi_os_physical_table_override() to tables.c.
      
      Along with the mechanisms, acpi_initrd_initialize_tables() is also moved to
      tables.c to form a static function. The following functions are renamed
      according to this change:
       1. acpi_initrd_override() -> renamed to early_acpi_table_init(), which
          invokes acpi_table_initrd_init()
       2. acpi_os_physical_table_override() -> which invokes
          acpi_table_initrd_override()
       3. acpi_initialize_initrd_tables() -> renamed to acpi_table_initrd_scan()
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5ae74f2c
  23. 09 4月, 2016 1 次提交
  24. 01 1月, 2016 1 次提交
  25. 15 12月, 2015 1 次提交
  26. 02 12月, 2015 1 次提交
  27. 07 11月, 2015 2 次提交
  28. 26 10月, 2015 1 次提交
  29. 25 10月, 2015 1 次提交
  30. 15 10月, 2015 1 次提交