1. 28 5月, 2016 1 次提交
    • R
      platform/x86: Add PMC Driver for Intel Core SoC · b740d2e9
      Rajneesh Bhardwaj 提交于
      This patch adds the Power Management Controller driver as a PCI driver
      for Intel Core SoC architecture.
      
      This driver can utilize debugging capabilities and supported features
      as exposed by the Power Management Controller.
      
      Please refer to the below specification for more details on PMC features.
      http://www.intel.in/content/www/in/en/chipsets/100-series-chipset-datasheet-vol-2.html
      
      The current version of this driver exposes SLP_S0_RESIDENCY counter.
      This counter can be used for detecting fragile SLP_S0 signal related
      failures and take corrective actions when PCH SLP_S0 signal is not
      asserted after kernel freeze as part of suspend to idle flow
      (echo freeze > /sys/power/state).
      
      Intel Platform Controller Hub (PCH) asserts SLP_S0 signal when it
      detects favorable conditions to enter its low power mode. As a
      pre-requisite the SoC should be in deepest possible Package C-State
      and devices should be in low power mode. For example, on Skylake SoC
      the deepest Package C-State is Package C10 or PC10. Suspend to idle
      flow generally leads to PC10 state but PC10 state may not be sufficient
      for realizing the platform wide power potential which SLP_S0 signal
      assertion can provide.
      
      SLP_S0 signal is often connected to the Embedded Controller (EC) and the
      Power Management IC (PMIC) for other platform power management related
      optimizations.
      
      In general, SLP_S0 assertion == PC10 + PCH low power mode + ModPhy Lanes
      power gated + PLL Idle.
      
      As part of this driver, a mechanism to read the SLP_S0_RESIDENCY is exposed
      as an API and also debugfs features are added to indicate SLP_S0 signal
      assertion residency in microseconds.
      
      echo freeze > /sys/power/state
      wake the system
      cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec
      Signed-off-by: NRajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
      Signed-off-by: NVishwanath Somayaji <vishwanath.somayaji@intel.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      b740d2e9
  2. 24 3月, 2016 3 次提交
  3. 20 1月, 2016 6 次提交
  4. 10 11月, 2015 1 次提交
    • A
      ideapad-laptop: add support for Yoga 3 ESC key · 74caab99
      Arnd Bergmann 提交于
      The ideapad-laptop handles most special keys on various Lenovo Laptops
      including the Yoga line. Unfortunately, the Yoga 3 11/13/14 models have
      one important exception, which is the Fn-ESC combination.
      
      On other Lenovo Laptops, this is FnLock, which switches the function keys
      between the primary (Mute, Vol down, Vol up, ...) and the secondary (F1,
      F2, F3, ...) behavior. On the new machines, FnLock is only available
      through BIOS setup (possibly through a yet-to-be-implemented feature
      in this driver) but not through Fn-ESC, but instead the ESC key itself
      switched between ESC and a "Paper Display" app for Windows.
      
      Unfortunately, that means that you can never have both ESC *and* the
      function keys working at the same time without needing to press Fn on
      one of them.
      As pointed out in the official Lenovo Forum by dozens of users, this
      makes the machine rather useless for any serious work [1].
      
      I have now studied the ACPI DSDT one more time and found the event
      that is generated for the ESC key. Unlike all other key events on this
      machine, it is actually a WMI, while the other ones are read from the
      embedded controller.
      
      I am now installing a WMI notifier that uses the event number from the
      WMI subsystem as the scancode. The only event number generated here is
      '128', and that fits in nicely with the two existing ranges of scancodes
      used by the EC: 0-15 for the 16-bit VPCCMD_R_VPC register, 16-17 for
      the VPCCMD_R_NOVO register and 64-67 for VPCCMD_R_SPECIAL_BUTTONS.
      
      The only sane way to handle this button (in absence of the Windows Paper
      Display driver) seems to be to have it emit KEY_ESC, so that is what
      I use as the default. Should any user ever want to overwrite the default,
      they can install their own keymap.
      
      To ensure that we can still build the driver without adding a CONFIG_WMI
      dependency, all new code is enclosed in #ifdef.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      
      [1] https://forums.lenovo.com/t5/Lenovo-Yoga-Series-Notebooks/YOGA-3-14-How-to-reclaim-my-Esc-key-and-permanently-disable/td-p/2070816Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      74caab99
  5. 31 10月, 2015 1 次提交
  6. 04 10月, 2015 1 次提交
    • A
      platform/x86: Toshiba WMI Hotkey Driver · 14991fc7
      Azael Avalos 提交于
      Toshiba laptops that feature WMI events for hotkeys were left unsupported
      by the toshiba_acpi driver, however, commit a88bc06e ("toshiba_acpi:
      Avoid registering input device on WMI event laptops") added hardware
      support for such laptops, but the hotkeys are not handled there.
      
      This driver adds support for hotkey monitoring on certain Toshiba laptops
      that manage the hotkeys via WMI events instead of the Toshiba
      Configuration Interface (TCI).
      
      The toshiba_acpi driver and this one can co-exist, as this only takes
      care of hotkeys, while the proper takes care of hardware related stuff.
      
      Currently the driver is under the EXPERIMENTAL flag, as the keymap
      and the notify function are incomplete (due to lack of hardware to test).
      Signed-off-by: NAzael Avalos <coproscefalo@gmail.com>
      Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      14991fc7
  7. 03 10月, 2015 1 次提交
  8. 26 8月, 2015 1 次提交
  9. 30 6月, 2015 1 次提交
  10. 19 6月, 2015 1 次提交
    • H
      acpi-video-detect: video: Make video_detect code part of the video module · 14ca7a47
      Hans de Goede 提交于
      This is a preparation patch for the backlight interface selection logic
      cleanup, there are 2 reasons to not always build the video_detect code
      into the kernel:
      
      1) In order for the video_detect.c to also deal with / select native
      backlight interfaces on win8 systems, instead of doing this in video.c
      where it does not belong, video_detect.c needs to call into the backlight
      class code. Which cannot be done if it is builtin and the blacklight class
      is not.
      
      2) Currently all the platform/x86 drivers which have quirks to prefer
      the vendor driver over acpi-video call acpi_video_unregister_backlight()
      to remove the acpi-video backlight interface, this logic really belongs
      in video_detect.c, which will cause video_detect.c to depend on symbols of
      video.c and video.c already depends on video_detect.c symbols, so they
      really need to be a single module.
      
      Note that this commits make 2 changes so as to maintain 100% kernel
      commandline compatibility:
      
      1) The __setup call for the acpi_backlight= handling is moved to
         acpi/util.c as __setup may only be used by code which is alwasy builtin
      2) video.c is renamed to acpi_video.c so that it can be combined with
         video_detect.c into video.ko
      
      This commit also makes changes to drivers/platform/x86/Kconfig to ensure
      that drivers which use acpi_video_backlight_support() from video_detect.c,
      will not be built-in when acpi_video is not built in. This also changes
      some "select" uses to "depends on" to avoid dependency loops.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Acked-by: NDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      14ca7a47
  11. 11 6月, 2015 1 次提交
  12. 26 5月, 2015 1 次提交
  13. 07 5月, 2015 2 次提交
  14. 25 4月, 2015 1 次提交
  15. 19 2月, 2015 1 次提交
    • B
      x86/intel/quark: Add Isolated Memory Regions for Quark X1000 · 28a375df
      Bryan O'Donoghue 提交于
      Intel's Quark X1000 SoC contains a set of registers called
      Isolated Memory Regions. IMRs are accessed over the IOSF mailbox
      interface. IMRs are areas carved out of memory that define
      read/write access rights to the various system agents within the
      Quark system. For a given agent in the system it is possible to
      specify if that agent may read or write an area of memory
      defined by an IMR with a granularity of 1 KiB.
      
      Quark_SecureBootPRM_330234_001.pdf section 4.5 details the
      concept of IMRs quark-x1000-datasheet.pdf section 12.7.4 details
      the implementation of IMRs in silicon.
      
      eSRAM flush, CPU Snoop write-only, CPU SMM Mode, CPU non-SMM
      mode, RMU and PCIe Virtual Channels (VC0 and VC1) can have
      individual read/write access masks applied to them for a given
      memory region in Quark X1000. This enables IMRs to treat each
      memory transaction type listed above on an individual basis and
      to filter appropriately based on the IMR access mask for the
      memory region. Quark supports eight IMRs.
      
      Since all of the DMA capable SoC components in the X1000 are
      mapped to VC0 it is possible to define sections of memory as
      invalid for DMA write operations originating from Ethernet, USB,
      SD and any other DMA capable south-cluster component on VC0.
      Similarly it is possible to mark kernel memory as non-SMM mode
      read/write only or to mark BIOS runtime memory as SMM mode
      accessible only depending on the particular memory footprint on
      a given system.
      
      On an IMR violation Quark SoC X1000 systems are configured to
      reset the system, so ensuring that the IMR memory map is
      consistent with the EFI provided memory map is critical to
      ensure no IMR violations reset the system.
      
      The API for accessing IMRs is based on MTRR code but doesn't
      provide a /proc or /sys interface to manipulate IMRs. Defining
      the size and extent of IMRs is exclusively the domain of
      in-kernel code.
      
      Quark firmware sets up a series of locked IMRs around pieces of
      memory that firmware owns such as ACPI runtime data. During boot
      a series of unlocked IMRs are placed around items in memory to
      guarantee no DMA modification of those items can take place.
      Grub also places an unlocked IMR around the kernel boot params
      data structure and compressed kernel image. It is necessary for
      the kernel to tear down all unlocked IMRs in order to ensure
      that the kernel's view of memory passed via the EFI memory map
      is consistent with the IMR memory map. Without tearing down all
      unlocked IMRs on boot transitory IMRs such as those used to
      protect the compressed kernel image will cause IMR violations and system reboots.
      
      The IMR init code tears down all unlocked IMRs and sets a
      protective IMR around the kernel .text and .rodata as one
      contiguous block. This sanitizes the IMR memory map with respect
      to the EFI memory map and protects the read-only portions of the
      kernel from unwarranted DMA access.
      Tested-by: NOng, Boon Leong <boon.leong.ong@intel.com>
      Signed-off-by: NBryan O'Donoghue <pure.logic@nexus-software.ie>
      Reviewed-by: NAndy Shevchenko <andy.schevchenko@gmail.com>
      Reviewed-by: NDarren Hart <dvhart@linux.intel.com>
      Reviewed-by: NOng, Boon Leong <boon.leong.ong@intel.com>
      Cc: andy.shevchenko@gmail.com
      Cc: dvhart@infradead.org
      Link: http://lkml.kernel.org/r/1422635379-12476-2-git-send-email-pure.logic@nexus-software.ieSigned-off-by: NIngo Molnar <mingo@kernel.org>
      28a375df
  16. 16 12月, 2014 1 次提交
    • R
      platform/x86/acerhdf: Still depends on THERMAL · 200db647
      Randy Dunlap 提交于
      acerhdf uses thermal interfaces so it should depend on THERMAL.
      It also should not select a thermal driver without checking that
      THERMAL is enabled.
      
      This fixes the following build errors when THERMAL=m and
      ACERHDF=y.
      
      drivers/built-in.o: In function `acerhdf_set_mode':
      acerhdf.c:(.text+0x3e02e1): undefined reference to `thermal_zone_device_update'
      drivers/built-in.o: In function `acerhdf_unbind':
      acerhdf.c:(.text+0x3e052d): undefined reference to `thermal_zone_unbind_cooling_device'
      drivers/built-in.o: In function `acerhdf_bind':
      acerhdf.c:(.text+0x3e0593): undefined reference to `thermal_zone_bind_cooling_device'
      drivers/built-in.o: In function `acerhdf_init':
      acerhdf.c:(.init.text+0x1c2f5): undefined reference to `thermal_cooling_device_register'
      acerhdf.c:(.init.text+0x1c360): undefined reference to `thermal_zone_device_register'
      drivers/built-in.o: In function `acerhdf_unregister_thermal':
      acerhdf.c:(.text.unlikely+0x3c67): undefined reference to `thermal_cooling_device_unregister'
      acerhdf.c:(.text.unlikely+0x3c91): undefined reference to `thermal_zone_device_unregister'
      Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Acked-by: NPeter Feuerer <peter@piie.net>
      Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      200db647
  17. 04 12月, 2014 2 次提交
  18. 11 11月, 2014 1 次提交
  19. 26 9月, 2014 1 次提交
  20. 16 8月, 2014 1 次提交
  21. 11 6月, 2014 3 次提交
  22. 07 4月, 2014 3 次提交
  23. 20 3月, 2014 1 次提交
  24. 21 1月, 2014 2 次提交
    • A
    • D
      X86 platform: New BayTrail IOSF-SB MBI driver · 997ab407
      David E. Box 提交于
      Current Intel SOC cores use a MailBox Interface (MBI) to provide access to unit
      devices connected to the system fabric. This driver implements access to this
      interface on BayTrail platforms. This is a requirement for drivers that need
      access to unit registers on the platform (e.g. accessing the PUNIT for power
      management features such as RAPL). Serialized access is handled by all exported
      routines with spinlocks.
      
      The API includes 3 functions for access to unit registers:
      
      int bt_mbi_read(u8 port, u8 opcode, u32 offset, u32 *mdr)
      int bt_mbi_write(u8 port, u8 opcode, u32 offset, u32 mdr)
      int bt_mbi_modify(u8 port, u8 opcode, u32 offset, u32 mdr, u32 mask)
      
      port:	indicating the unit being accessed
      opcode:	the read or write port specific opcode
      offset:	the register offset within the port
      mdr:	the register data to be read, written, or modified
      mask:	bit locations in mdr to change
      
      Returns nonzero on error
      
      Note: GPU code handles access to the GFX unit. Therefore access to that unit
      with this driver is disallowed to avoid conflicts.
      Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
      Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
      997ab407
  25. 21 11月, 2013 1 次提交
  26. 23 10月, 2013 1 次提交