1. 09 2月, 2017 3 次提交
  2. 07 2月, 2017 1 次提交
  3. 05 1月, 2017 1 次提交
  4. 03 1月, 2017 5 次提交
  5. 21 12月, 2016 2 次提交
    • L
      ACPI / osl: Remove deprecated acpi_get_table_with_size()/early_acpi_os_unmap_memory() · 8d3523fb
      Lv Zheng 提交于
      Since all users are cleaned up, remove the 2 deprecated APIs due to no
      users.
      As a Linux variable rather than an ACPICA variable, acpi_gbl_permanent_mmap
      is renamed to acpi_permanent_mmap to have a consistent coding style across
      entire Linux ACPI subsystem.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8d3523fb
    • L
      ACPICA: Tables: Back port acpi_get_table_with_size() and... · 174cc718
      Lv Zheng 提交于
      ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel
      
      ACPICA commit cac6790954d4d752a083e6122220b8a22febcd07
      
      This patch back ports Linux acpi_get_table_with_size() and
      early_acpi_os_unmap_memory() into ACPICA upstream to reduce divergences.
      
      The 2 APIs are used by Linux as table management APIs for long time, it
      contains a hidden logic that during the early stage, the mapped tables
      should be unmapped before the early stage ends.
      
      During the early stage, tables are handled by the following sequence:
       acpi_get_table_with_size();
       parse the table
       early_acpi_os_unmap_memory();
      During the late stage, tables are handled by the following sequence:
       acpi_get_table();
       parse the table
      Linux uses acpi_gbl_permanent_mmap to distinguish the early stage and the
      late stage.
      
      The reasoning of introducing acpi_get_table_with_size() is: ACPICA will
      remember the early mapped pointer in acpi_get_table() and Linux isn't able to
      prevent ACPICA from using the wrong early mapped pointer during the late
      stage as there is no API provided from ACPICA to be an inverse of
      acpi_get_table() to forget the early mapped pointer.
      
      But how ACPICA can work with the early/late stage requirement? Inside of
      ACPICA, tables are ensured to be remained in "INSTALLED" state during the
      early stage, and they are carefully not transitioned to "VALIDATED" state
      until the late stage. So the same logic is in fact implemented inside of
      ACPICA in a different way. The gap is only that the feature is not provided
      to the OSPMs in an accessible external API style.
      
      It then is possible to fix the gap by providing an inverse of
      acpi_get_table() from ACPICA, so that the two Linux sequences can be
      combined:
       acpi_get_table();
       parse the table
       acpi_put_table();
      In order to work easier with the current Linux code, acpi_get_table() and
      acpi_put_table() is implemented in a usage counting based style:
       1. When the usage count of the table is increased from 0 to 1, table is
          mapped and .Pointer is set with the mapping address (VALIDATED);
       2. When the usage count of the table is decreased from 1 to 0, .Pointer
          is unset and the mapping address is unmapped (INVALIDATED).
      So that we can deploy the new APIs to Linux with minimal effort by just
      invoking acpi_get_table() in acpi_get_table_with_size() and invoking
      acpi_put_table() in early_acpi_os_unmap_memory(). Lv Zheng.
      
      Link: https://github.com/acpica/acpica/commit/cac67909Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      174cc718
  6. 29 11月, 2016 1 次提交
    • 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
  7. 21 11月, 2016 1 次提交
  8. 18 11月, 2016 1 次提交
    • R
      cpufreq: intel_pstate: Request P-states control from SMM if needed · d0ea59e1
      Rafael J. Wysocki 提交于
      Currently, intel_pstate is unable to control P-states on my
      IvyBridge-based Acer Aspire S5, because they are controlled by SMM
      on that machine by default and it is necessary to request OS control
      of P-states from it via the SMI Command register exposed in the ACPI
      FADT.  intel_pstate doesn't do that now, but acpi-cpufreq and other
      cpufreq drivers for x86 platforms do.
      
      Address this problem by making intel_pstate use the ACPI-defined
      mechanism as well.  However, intel_pstate is not modular and it
      doesn't need the module refcount tricks played by
      acpi_processor_notify_smm(), so export the core of this function
      to it as acpi_processor_pstate_control() and make it call that.
      [The changes in processor_perflib.c related to this should not
      make any functional difference for the acpi_processor_notify_smm()
      users].
      
      To be safe, only call acpi_processor_notify_smm() from intel_pstate
      if ACPI _PPC support is enabled in it.
      Suggested-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      d0ea59e1
  9. 17 11月, 2016 2 次提交
  10. 15 11月, 2016 1 次提交
  11. 21 10月, 2016 3 次提交
  12. 17 10月, 2016 1 次提交
  13. 20 9月, 2016 1 次提交
  14. 10 9月, 2016 4 次提交
  15. 09 9月, 2016 1 次提交
  16. 31 8月, 2016 5 次提交
  17. 13 8月, 2016 7 次提交