1. 23 1月, 2020 1 次提交
  2. 14 1月, 2020 1 次提交
    • S
      platform/x86: Add support for Uncore frequency control · 49a474c7
      Srinivas Pandruvada 提交于
      Some server users set limits on the uncore frequency using MSR 620H, while
      running latency sensitive workloads. Here uncore frequency controls
      RING/LLC(last-level cache) clocks.
      
      But MSR control is not always possible from the user space, so this driver
      provides a sysfs interface to set max and min frequency limits. This MSR
      620H is a die scoped in multi-die system or package scoped in non multi-die
      systems.
      
      When this driver is loaded, a new directory is created under
       /sys/devices/system/cpu.
      
      For example on a two package Skylake server:
      $cd /sys/devices/system/cpu/intel_uncore_frequency
      
      $ls
      package_00_die_00 package_01_die_00
      
      $ls package_00_die_00
      max_freq_khz  min_freq_khz  initial_max_freq_khz
      initial_min_freq_khz
      
      $grep . *
          max_freq_khz:2400000
          min_freq_khz:1200000
          initial_max_freq_khz:2400000
          initial_min_freq_khz:1200000
      
      Here, initial_max_freq_khz and initial_min_freq_khz are read only
      attributes to show power up or initial values of max and min frequencies
      respectively. Other attributes are read-write, so that users can modify.
      Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      49a474c7
  3. 10 1月, 2020 1 次提交
  4. 16 10月, 2019 1 次提交
  5. 15 10月, 2019 8 次提交
  6. 15 9月, 2019 1 次提交
  7. 15 7月, 2019 3 次提交
  8. 12 7月, 2019 1 次提交
    • Y
      platform/x86: Fix PCENGINES_APU2 Kconfig warning · 7d67c8ac
      YueHaibing 提交于
      Fix Kconfig warning for PCENGINES_APU2 symbol:
      
      WARNING: unmet direct dependencies detected for GPIO_AMD_FCH
        Depends on [n]: GPIOLIB [=n] && HAS_IOMEM [=y]
        Selected by [y]:
        - PCENGINES_APU2 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && INPUT [=y] && INPUT_KEYBOARD [=y] && LEDS_CLASS [=y]
      
      WARNING: unmet direct dependencies detected for KEYBOARD_GPIO_POLLED
        Depends on [n]: !UML && INPUT [=y] && INPUT_KEYBOARD [=y] && GPIOLIB [=n]
        Selected by [y]:
        - PCENGINES_APU2 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && INPUT [=y] && INPUT_KEYBOARD [=y] && LEDS_CLASS [=y]
      
      Add GPIOLIB dependency to fix it.
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Fixes: f8eb0235 ("x86: pcengines apuv2 gpio/leds/keys platform driver")
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      7d67c8ac
  9. 04 7月, 2019 1 次提交
  10. 02 7月, 2019 1 次提交
    • S
      platform/x86: ISST: Add common API to register and handle ioctls · 35f2c14d
      Srinivas Pandruvada 提交于
      Encapsulate common functions which all Intel Speed Select Technology
      interface drivers can use. This creates API to register misc device for
      user kernel communication and handle all common IOCTLs. As part of the
      registry it allows a callback which is to handle domain specific ioctl
      processing.
      
      There can be multiple drivers register for services, which can be built
      as modules. So this driver handle contention during registry and as well
      as during removal. Once user space opened the misc device, the registered
      driver will be prevented from removal. Also once misc device is opened by
      the user space new client driver can't register, till the misc device is
      closed.
      
      There are two types of client drivers, one to handle mail box interface
      and the other is to allow direct read/write to some specific MMIO space.
      
      This common driver implements IOCTL ISST_IF_GET_PLATFORM_INFO.
      Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      35f2c14d
  11. 29 6月, 2019 1 次提交
  12. 28 6月, 2019 1 次提交
  13. 12 6月, 2019 1 次提交
  14. 21 5月, 2019 1 次提交
  15. 09 5月, 2019 1 次提交
  16. 08 3月, 2019 1 次提交
  17. 23 2月, 2019 1 次提交
  18. 29 1月, 2019 2 次提交
  19. 16 1月, 2019 3 次提交
  20. 13 12月, 2018 1 次提交
    • A
      platform/x86: add support for Huawei WMI hotkeys · bf4fb28c
      Ayman Bagabas 提交于
      This driver adds support for missing hotkeys on some Huawei laptops.
      Laptops such as the Matebook X have non functioning hotkeys. Whereas
      newer laptops such as the Matebook X Pro come with working hotkeys out
      of the box.
      
      Old laptops, such as the Matebook X, report hotkey events through ACPI
      device "\WMI0". However, new laptops, such as the Matebook X Pro, does
      not have this WMI device.
      
      All the hotkeys on the Matebook X Pro work fine without this patch
      except (micmute, wlan, and huawei key). These keys and the brightness
      keys report events to "\AMW0" ACPI device. One problem is that
      brightness keys on the Matebook X Pro work without this patch. This
      results in reporting two brightness key press events one is captured
      by ACPI and another by this driver.
      
      A solution would be to check if such event came from the "\AMW0" WMI
      driver then skip reporting event. Another solution would be to leave
      this to user-space to handle. Which can be achieved by using "hwdb"
      tables and remap those keys to "unknown". This solution seems more
      natural to me because it leaves the decision to user-space.
      Acked-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
      Reviewed-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NAyman Bagabas <ayman.bagabas@gmail.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      bf4fb28c
  21. 29 11月, 2018 2 次提交
  22. 07 11月, 2018 1 次提交
  23. 29 10月, 2018 1 次提交
    • H
      platform/x86: Add Intel AtomISP2 dummy / power-management driver · 49ad712a
      Hans de Goede 提交于
      The Image Signal Processor found on Cherry Trail devices is brought up in
      D0 state on devices which have camera sensors attached to it. The ISP will
      not enter D3 state again without some massaging of its registers beforehand
      and the ISP not being in D3 state blocks the SoC from entering S0ix modes.
      
      There was a driver for the ISP in drivers/staging but that got removed
      again because it never worked. It does not seem likely that a real
      driver for the ISP will be added to the mainline kernel anytime soon.
      
      This commit adds a dummy driver which contains the necessary magic from
      the staging driver to powerdown the ISP, so that Cherry Trail devices where
      the ISP is used will properly use S0ix modes when suspended.
      
      Together with other recent S0ix related fixes this allows S0ix modes to
      be entered on e.g. a Chuwi Hi8 Pro and a HP x2 210.
      
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=196915Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Reviewed-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      49ad712a
  24. 20 10月, 2018 1 次提交
  25. 27 9月, 2018 3 次提交