1. 22 1月, 2018 1 次提交
    • M
      device property: Introduce fwnode_irq_get() · 7c6c57f2
      Marcin Wojtas 提交于
      Until now there were two very similar functions allowing
      to get Linux IRQ number from ACPI handle (acpi_irq_get())
      and OF node (of_irq_get()). The first one appeared to be used
      only as a subroutine of platform_irq_get(), which (in the generic
      code) limited IRQ obtaining from _CRS method only to nodes
      associated to kernel's struct platform_device.
      
      This patch introduces a new helper routine - fwnode_irq_get(),
      which allows to get the IRQ number directly from the fwnode
      to be used as common for OF/ACPI worlds. It is usable not
      only for the parents fwnodes, but also for the child nodes
      comprising their own _CRS methods with interrupts description.
      
      In order to be able o satisfy compilation with !CONFIG_ACPI
      and also simplify the new code, introduce a helper macro
      (ACPI_HANDLE_FWNODE), with which it is possible to reach
      an ACPI handle directly from its fwnode.
      Signed-off-by: NMarcin Wojtas <mw@semihalf.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c6c57f2
  2. 06 11月, 2017 1 次提交
    • R
      ACPI / PM: Take SMART_SUSPEND driver flag into account · 05087360
      Rafael J. Wysocki 提交于
      Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
      its system suspend callbacks.
      
      [Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
      is an optimization, because if is not passed, all of the subsequent
      checks may be skipped and some of them are much more overhead in
      general.]
      
      Also use the observation that if the device is in runtime suspend
      at the beginning of the "late" phase of a system-wide suspend-like
      transition, its state cannot change going forward (runtime PM is
      disabled for it at that time) until the transition is over and the
      subsequent system-wide PM callbacks should be skipped for it (as
      they generally assume the device to not be suspended), so add
      checks for that in acpi_subsys_suspend_late/noirq() and
      acpi_subsys_freeze_late/noirq().
      
      Moreover, if acpi_subsys_resume_noirq() is called during the
      subsequent system-wide resume transition and if the device was left
      in runtime suspend previously, its runtime PM status needs to be
      changed to "active" as it is going to be put into the full-power
      state going forward, so add a check for that too in there.
      
      In turn, if acpi_subsys_thaw_noirq() runs after the device has been
      left in runtime suspend, the subsequent "thaw" callbacks need
      to be skipped for it (as they may not work correctly with a
      suspended device), so set the power.direct_complete flag for the
      device then to make the PM core skip those callbacks.
      
      On top of the above, make the analogous changes in the acpi_lpss
      driver that uses the ACPI PM domain callbacks.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      05087360
  3. 17 10月, 2017 1 次提交
  4. 11 10月, 2017 2 次提交
    • S
      ACPI / LPIT: Add Low Power Idle Table (LPIT) support · eeb2d80d
      Srinivas Pandruvada 提交于
      Add functionality to read LPIT table, which provides:
      
       - Sysfs interface to read residency counters via
         /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
         /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
      
      Here the count "low_power_idle_cpu_residency_us" shows the time spent
      by CPU package in low power state.  This is read via MSR interface,
      which points to MSR for PKG C10.
      
      Here the count "low_power_idle_system_residency_us" show the count the
      system was in low power state. This is read via MMIO interface. This
      is mapped to SLP_S0 residency on modern Intel systems. This residency
      is achieved only when CPU is in PKG C10 and all functional blocks are
      in low power state.
      
      It is possible that none of the above counters present or anyone of the
      counter present or all counters present.
      
      For example: On my Kabylake system both of the above counters present.
      After suspend to idle these counts updated and prints:
      
       6916179
       6998564
      
      This counter can be read by tools like turbostat to display. Or it can
      be used to debug, if modern systems are reaching desired low power state.
      
       - Provides an interface to read residency counter memory address
      
         This address can be used to get the base address of PMC memory
         mapped IO.  This is utilized by intel_pmc_core driver to print
         more debug information.
      
      In addition, to avoid code duplication to read iomem, removed the read of
      iomem from acpi_os_read_memory() in osl.c and made a common function
      acpi_os_read_iomem(). This new function is used for reading iomem in
      in both osl.c and acpi_lpit.c.
      
      Link: http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdfSigned-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      eeb2d80d
    • R
      ACPI / PM: Combine two identical device resume routines · 63705c40
      Rafael J. Wysocki 提交于
      Notice that acpi_dev_runtime_resume() and acpi_dev_resume_early() are
      actually literally identical after some more-or-less recent changes,
      so rename acpi_dev_runtime_resume() to acpi_dev_resume(), use it
      everywhere instead of acpi_dev_resume_early() and drop the latter.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
      63705c40
  5. 10 10月, 2017 1 次提交
  6. 29 8月, 2017 1 次提交
  7. 07 8月, 2017 1 次提交
    • L
      ACPI: Introduce DMA ranges parsing · c04ac679
      Lorenzo Pieralisi 提交于
      Some devices have limited addressing capabilities and cannot
      reference the whole memory address space while carrying out DMA
      operations (eg some devices with bus address bits range smaller than
      system bus - which prevents them from using bus addresses that are
      otherwise valid for the system).
      
      The ACPI _DMA object allows bus devices to define the DMA window that is
      actually addressable by devices that sit upstream the bus, therefore
      providing a means to parse and initialize the devices DMA masks and
      addressable DMA range size.
      
      By relying on the generic ACPI kernel layer to retrieve and parse
      resources, introduce ACPI core code to parse the _DMA object.
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Tested-by: NNate Watterson <nwatters@codeaurora.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c04ac679
  8. 30 7月, 2017 1 次提交
    • T
      tty: pl011: fix initialization order of QDF2400 E44 · 37ef38f3
      Timur Tabi 提交于
      The work-around for Qualcomm Technologies QDF2400 Erratum 44 hinges on a
      global variable defined in the pl011 driver.  The ACPI SPCR parsing code
      determines whether the work-around is needed, and if so, it changes the
      console name from "pl011" to "qdf2400_e44".  The expectation is that
      the pl011 driver will implement the work-around when it sees the console
      name.  The global variable qdf2400_e44_present is set when that happens.
      
      The problem is that work-around needs to be enabled when the pl011
      driver probes, not when the console name is queried.  However, sbsa_probe()
      is called before pl011_console_match().  The work-around appeared to work
      previously because the default console on QDF2400 platforms was always
      ttyAMA1.  The first time sbsa_probe() is called (for ttyAMA0),
      qdf2400_e44_present is still false.  Then pl011_console_match() is called,
      and it sets qdf2400_e44_present to true.  All subsequent calls to
      sbsa_probe() enable the work-around.
      
      The solution is to move the global variable into spcr.c and let the
      pl011 driver query it during probe time.  This works because all QDF2400
      platforms require SPCR, so parse_spcr() will always be called.
      pl011_console_match still checks for the "qdf2400_e44" console name,
      but it doesn't do anything else special.
      
      Fixes: 5a0722b8 ("tty: pl011: use "qdf2400_e44" as the earlycon name for QDF2400 E44")
      Tested-by: NJeffrey Hugo <jhugo@codeaurora.org>
      Signed-off-by: NTimur Tabi <timur@codeaurora.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37ef38f3
  9. 25 7月, 2017 1 次提交
  10. 22 7月, 2017 3 次提交
  11. 22 6月, 2017 1 次提交
  12. 08 6月, 2017 1 次提交
  13. 07 6月, 2017 1 次提交
  14. 06 6月, 2017 1 次提交
  15. 29 5月, 2017 1 次提交
  16. 20 4月, 2017 2 次提交
    • S
      drivers: acpi: Handle IOMMU lookup failure with deferred probing or error · 5a1bb638
      Sricharan R 提交于
      This is an equivalent to the DT's handling of the iommu master's probe
      with deferred probing when the corrsponding iommu is not probed yet.
      The lack of a registered IOMMU can be caused by the lack of a driver for
      the IOMMU, the IOMMU device probe not having been performed yet, having
      been deferred, or having failed.
      
      The first case occurs when the firmware describes the bus master and
      IOMMU topology correctly but no device driver exists for the IOMMU yet
      or the device driver has not been compiled in. Return NULL, the caller
      will configure the device without an IOMMU.
      
      The second and third cases are handled by deferring the probe of the bus
      master device which will eventually get reprobed after the IOMMU.
      
      The last case is currently handled by deferring the probe of the bus
      master device as well. A mechanism to either configure the bus master
      device without an IOMMU or to fail the bus master device probe depending
      on whether the IOMMU is optional or mandatory would be a good
      enhancement.
      Tested-by: NHanjun Guo <hanjun.guo@linaro.org>
      Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
      [Lorenzo: Added fixes for dma_coherent_mask overflow, acpi_dma_configure
                called multiple times for same device]
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NSricharan R <sricharan@codeaurora.org>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      5a1bb638
    • H
      ACPI / utils: Add new acpi_dev_present helper · 8661423e
      Hans de Goede 提交于
      acpi_dev_found just iterates over all ACPI-ids and sees if one matches.
      This means that it will return true for devices which are in the DSDT
      but disabled (their _STA method returns 0).
      
      For some drivers it is useful to be able to check if a certain HID
      is not only present in the namespace, but also actually present as in
      acpi_device_is_present() will return true for the device. For example
      because if a certain device is present then the driver will want to use
      an extcon or IIO ADC channel provided by that device.
      
      This commit adds a new acpi_dev_present helper which drivers can use
      to this end.
      
      Like acpi_dev_found, acpi_dev_present take a HID as argument, but
      it also has 2 extra optional arguments to only check for an ACPI
      device with a specific UID and/or HRV value. This makes it more
      generic and allows it to replace custom code doing similar checks
      in several places.
      
      Arguably acpi_dev_present is what acpi_dev_found should have been, but
      there are too many users to just change acpi_dev_found without the risk
      of breaking something.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Reviewed-by: NLukas Wunner <lukas@wunner.de>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8661423e
  17. 19 4月, 2017 3 次提交
  18. 29 3月, 2017 3 次提交
  19. 15 3月, 2017 1 次提交
  20. 11 3月, 2017 2 次提交
  21. 07 2月, 2017 1 次提交
  22. 03 2月, 2017 1 次提交
  23. 02 12月, 2016 1 次提交
  24. 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
  25. 25 11月, 2016 1 次提交
  26. 17 11月, 2016 1 次提交
  27. 10 11月, 2016 1 次提交
  28. 24 10月, 2016 1 次提交
  29. 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
  30. 28 9月, 2016 1 次提交