1. 05 2月, 2015 8 次提交
  2. 26 1月, 2015 2 次提交
  3. 22 1月, 2015 1 次提交
  4. 07 1月, 2015 1 次提交
  5. 06 1月, 2015 5 次提交
    • Z
      ACPI/int340x_thermal: enumerate INT3401 for Intel SoC DTS thermal driver · 014d9d5d
      Zhang Rui 提交于
      Intel SoC DTS thermal driver on Baytrail platform uses IRQ 86 for
      critical overheating notification.
      But this IRQ 86 is described in the _CRS control method of INT3401 device,
      thus we should enumerate INT3401 to set the IRQ descriptor when
      Intel SoC DTS thermal driver is built.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Tested-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      014d9d5d
    • Z
      ACPI/int340x_thermal: enumerate INT340X devices even if they're not in _ART/_TRT · 48628e40
      Zhang Rui 提交于
      For some INT340X thermal devices, even if they are not referred in
      _TRT/_ART table, they still can be used by userspace for thermal control.
      Thus change the code to enumerated all the INT340X devices,
      no matter if they're referred in _TRT/_ART or not.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Tested-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      48628e40
    • H
      ACPI / processor: Rename acpi_(un)map_lsapic() to acpi_(un)map_cpu() · d02dc27d
      Hanjun Guo 提交于
      acpi_map_lsapic() will allocate a logical CPU number and map it to
      physical CPU id (such as APIC id) for the hot-added CPU, it will also
      do some mapping for NUMA node id and etc, acpi_unmap_lsapic() will
      do the reverse.
      
      We can see that the name of the function is a little bit confusing and
      arch (IA64) dependent so rename them as acpi_(un)map_cpu() to make arch
      agnostic and explicit.
      Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d02dc27d
    • H
      ACPI / processor: Convert apic_id to phys_id to make it arch agnostic · af8f3f51
      Hanjun Guo 提交于
      apic_id in MADT table is the CPU hardware id which identify
      it self in the system for x86 and ia64, OSPM will use it for
      SMP init to map APIC ID to logical cpu number in the early
      boot, when the DSDT/SSDT (ACPI namespace) is scanned later, the
      ACPI processor driver is probed and the driver will use acpi_id
      in DSDT to get the apic_id, then map to the logical cpu number
      which is needed by the processor driver.
      
      Before ACPI 5.0, only x86 and ia64 were supported in ACPI spec,
      so apic_id is used both in arch code and ACPI core which is
      pretty fine. Since ACPI 5.0, ARM is supported by ACPI and
      APIC is not available on ARM, this will confuse people when
      apic_id is both used by x86 and ARM in one function.
      
      So convert apic_id to phys_id (which is the original meaning)
      in ACPI processor dirver to make it arch agnostic, but leave the
      arch dependent code unchanged, no functional change.
      Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      af8f3f51
    • R
      ACPI / PM: Fix PM initialization for devices that are not present · 1b1f3e16
      Rafael J. Wysocki 提交于
      If an ACPI device object whose _STA returns 0 (not present and not
      functional) has _PR0 or _PS0, its power_manageable flag will be set
      and acpi_bus_init_power() will return 0 for it.  Consequently, if
      such a device object is passed to the ACPI device PM functions, they
      will attempt to carry out the requested operation on the device,
      although they should not do that for devices that are not present.
      
      To fix that problem make acpi_bus_init_power() return an error code
      for devices that are not present which will cause power_manageable to
      be cleared for them as appropriate in acpi_bus_get_power_flags().
      However, the lists of power resources should not be freed for the
      device in that case, so modify acpi_bus_get_power_flags() to keep
      those lists even if acpi_bus_init_power() returns an error.
      Accordingly, when deciding whether or not the lists of power
      resources need to be freed, acpi_free_power_resources_lists()
      should check the power.flags.power_resources flag instead of
      flags.power_manageable, so make that change too.
      
      Furthermore, if acpi_bus_attach() sees that flags.initialized is
      unset for the given device, it should reset the power management
      settings of the device and re-initialize them from scratch instead
      of relying on the previous settings (the device may have appeared
      after being not present previously, for example), so make it use
      the 'valid' flag of the D0 power state as the initial value of
      flags.power_manageable for it and call acpi_bus_init_power() to
      discover its current power state.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
      1b1f3e16
  6. 23 12月, 2014 1 次提交
  7. 17 12月, 2014 1 次提交
    • L
      cpuidle / ACPI: remove unused CPUIDLE_FLAG_TIME_INVALID · 62c4cf97
      Len Brown 提交于
      CPUIDLE_FLAG_TIME_INVALID is no longer checked
      by menu or ladder cpuidle governors, so don't
      bother setting or defining it.
      
      It was originally invented to account for the fact that
      acpi_safe_halt() enables interrupts to invoke HLT.
      That would allow interrupt service routines to be included
      in the last_idle duration measurements made in cpuidle_enter_state(),
      potentially returning a duration much larger than reality.
      
      But menu and ladder can gracefully handle erroneously large duration
      intervals without checking for CPUIDLE_FLAG_TIME_INVALID.
      Further, if they don't check CPUIDLE_FLAG_TIME_INVALID, they
      can also benefit from the instances when the duration interval
      is not erroneously large.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      62c4cf97
  8. 16 12月, 2014 3 次提交
    • J
      x86, irq: Keep balance of IOAPIC pin reference count · cffe0a2b
      Jiang Liu 提交于
      To keep balance of IOAPIC pin reference count, we need to protect
      pirq_enable_irq(), acpi_pci_irq_enable() and intel_mid_pci_irq_enable()
      from reentrance. There are two cases which will cause reentrance.
      
      The first case is caused by suspend/hibernation. If pcibios_disable_irq
      is called during suspending/hibernating, we don't release the assigned
      IRQ number, otherwise it may break the suspend/hibernation. So late when
      pcibios_enable_irq is called during resume, we shouldn't allocate IRQ
      number again.
      
      The second case is that function acpi_pci_irq_enable() may be called
      twice for PCI devices present at boot time as below:
      1) pci_acpi_init()
      	--> acpi_pci_irq_enable() if pci_routeirq is true
      2) pci_enable_device()
      	--> pcibios_enable_device()
      		--> acpi_pci_irq_enable()
      We can't kill kernel parameter pci_routeirq yet because it's still
      needed for debugging purpose.
      
      So flag irq_managed is introduced to track whether IRQ number is
      assigned by OS and to protect pirq_enable_irq(), acpi_pci_irq_enable()
      and intel_mid_pci_irq_enable() from reentrance.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Len Brown <lenb@kernel.org>
      Link: http://lkml.kernel.org/r/1414387308-27148-13-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      cffe0a2b
    • J
      ACPI: Fix minor syntax issues in processor_core.c · 13ca62b2
      Jiang Liu 提交于
      Fix minor syntax issues in processor_core.c to follow coding styles.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Len Brown <lenb@kernel.org>
      Link: http://lkml.kernel.org/r/1414387308-27148-7-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      13ca62b2
    • J
      ACPI: Correct return value of acpi_dev_resource_address_space() · 6658c739
      Jiang Liu 提交于
      Change acpi_dev_resource_address_space() to return failure if the
      acpi_resource structure can't be converted to an ACPI address64
      structure, so caller could correctly detect failure.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Acked-by: NRafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Len Brown <lenb@kernel.org>
      Link: http://lkml.kernel.org/r/1414387308-27148-6-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      6658c739
  9. 15 12月, 2014 2 次提交
  10. 13 12月, 2014 3 次提交
  11. 11 12月, 2014 1 次提交
  12. 04 12月, 2014 2 次提交
  13. 03 12月, 2014 1 次提交
  14. 02 12月, 2014 2 次提交
    • R
      ACPI / sleep: Drain outstanding events after disabling multiple GPEs · c52fa70c
      Rafael J. Wysocki 提交于
      After multiple GPEs have been disabled at the low level in one go,
      like when acpi_disable_all_gpes() is called, we should always drain
      all of the outstanding events from them, or interesting races become
      possible.
      
      For this reason, call acpi_os_wait_events_complete() after
      acpi_enable_all_wakeup_gpes() and acpi_disable_all_gpes() in
      acpi_freeze_prepare() and acpi_power_off_prepare(), respectively.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c52fa70c
    • R
      ACPICA: Save current masks of enabled GPEs after enable register writes · c50f13c6
      Rafael J. Wysocki 提交于
      There is a race condition between acpi_hw_disable_all_gpes() or
      acpi_enable_all_wakeup_gpes() and acpi_ev_asynch_enable_gpe() such
      that if the latter wins the race, it may mistakenly enable a GPE
      disabled by the former.  This may lead to premature system wakeups
      during system suspend and potentially to more serious consequences.
      
      The source of the problem is how acpi_hw_low_set_gpe() works when
      passed ACPI_GPE_CONDITIONAL_ENABLE as the second argument.  In that
      case, the GPE will be enabled if the corresponding bit is set in the
      enable_for_run mask of the GPE enable register containing that bit.
      However, acpi_hw_disable_all_gpes() and acpi_enable_all_wakeup_gpes()
      don't modify the enable_for_run masks of GPE registers when writing
      to them.  In consequence, if acpi_ev_asynch_enable_gpe(), which
      eventually calls acpi_hw_low_set_gpe() with the second argument
      equal to ACPI_GPE_CONDITIONAL_ENABLE, is executed in parallel with
      one of these functions, it may reverse changes made by them.
      
      To fix the problem, introduce a new enable_mask field in struct
      acpi_gpe_register_info in which to store the current mask of
      enabled GPEs and modify acpi_hw_low_set_gpe() to take this
      mask into account instead of enable_for_run when its second
      argument is equal to ACPI_GPE_CONDITIONAL_ENABLE.  Also modify
      the low-level routines called by acpi_hw_disable_all_gpes(),
      acpi_enable_all_wakeup_gpes() and acpi_enable_all_runtime_gpes()
      to update the enable_mask masks of GPE registers after all
      (successful) writes to those registers.
      Acked-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c50f13c6
  15. 01 12月, 2014 1 次提交
  16. 28 11月, 2014 5 次提交
  17. 27 11月, 2014 1 次提交