Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 07 3月, 2017 1 次提交
  3. 14 2月, 2017 2 次提交
  5. 04 2月, 2017 1 次提交
    • S
      platform/x86: Support Turbo Boost Max 3.0 for non HWP systems · 4ec567b8
      由 Srinivas Pandruvada 提交于 
      On platforms supporting Intel Turbo Boost Max Technology 3.0, the
maximum turbo frequencies (turbo ratio) of some cores in a CPU package
may be higher than the other cores in the same package.  In that case,
better performance can be achieved by making the scheduler prefer to run
tasks on the CPUs with higher max turbo frequencies.

On Intel® Broadwell Xeon systems, it is optional to turn on HWP
(Hardware P-States). When HWP is not turned on, the BIOS doesn't
present required CPPC (Collaborative Processor Performance Control)
tables. This table is used to get the per CPU core maximum performance
ratio and inform scheduler (in cpufreq/intel_pstate driver).

On such systems the maximum performance ratio can be read via over
clocking (OC) mailbox interface for each CPU. This interface is not
architectural and can change for every model of processors.

This driver reads maximum performance ratio of each CPU and set up
the scheduler priority metrics. In this way scheduler can prefer CPU
with higher performance to schedule tasks.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      4ec567b8
  7. 03 2月, 2017 1 次提交
    • J
      platform/x86: dell-smbios: Auto-select as needed · 9893ae86
      由 Jean Delvare 提交于 
      Dell-smbios is a helper module, it serves no purpose on its own, so
do not present it as an option to the user. Instead, select it
automatically whenever a driver which needs it is selected.

Also select DCDBAS as needed, instead of depending on it, so that
the Dell driver options are always visible.

As a clean-up, I removed the "default n" statements as they are not
needed (n is the default default.)
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Cc: Michał Kępień <kernel@kempniu.pl>
Cc: Pali Rohár <pali.rohar@gmail.com>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      9893ae86
  9. 27 1月, 2017 2 次提交
  11. 14 1月, 2017 1 次提交
  13. 28 12月, 2016 1 次提交
  15. 19 12月, 2016 1 次提交
  17. 17 12月, 2016 3 次提交
  19. 23 10月, 2016 1 次提交
    • V
      platform/x86: Introduce support for Mellanox hotplug driver · 30488704
      由 Vadim Pasternak 提交于 
      Enable system support for the Mellanox Technologies hotplug platform
driver, which provides support for the next Mellanox basic systems:
"msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410",
"msb7800", "msn2740", "msn2100" and also various number of derivative
systems from the above basic types.
This driver handles hot-plug events for the power suppliers, power
cables and fans for the above systems.

The Kconfig currently controlling compilation of this code is:
driver/platform/x86:config MLX_CPLD_PLATFORM
                       tristate "Mellanox platform hotplug driver support"
Signed-off-by: NVadim Pasternak <vadimp@mellanox.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      30488704
  21. 13 10月, 2016 1 次提交
    • A
      platform/x86: asus-wmi: add SERIO_I8042 dependency · ea893695
      由 Arnd Bergmann 提交于 
      A recent bugfix added a call to i8042_install_filter but did
not add the dependency, leading to possible link errors:

drivers/platform/built-in.o: In function `asus_nb_wmi_quirks':
asus-nb-wmi.c:(.text+0x23af): undefined reference to `i8042_install_filter'

This adds a dependency on SERIO_I8042||SERIO_I8042=n to indicate
that we can build the driver when the i8042 driver is disabled,
but it cannot be built-in when that is a loadable module.

Fixes: b5643539 ("platform/x86: asus-wmi: Filter buggy scan codes on ASUS Q500A")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      ea893695
  23. 23 7月, 2016 1 次提交
  25. 02 7月, 2016 1 次提交
    • J
      asus-wireless: Toggle airplane mode LED · 2c1a49c9
      由 João Paulo Rechi Vita 提交于 
      In the ASHS device we have the HSWC method, which calls either OWGD or
OWGS, depending on its parameter:

	Device (ASHS)
	{
		Name (_HID, "ATK4002")  // _HID: Hardware ID
		Method (HSWC, 1, Serialized)
		{
			If ((Arg0 < 0x02))
			{
				OWGD (Arg0)
				Return (One)
			}
			If ((Arg0 == 0x02))
			{
				Local0 = OWGS ()
				If (Local0)
				{
					Return (0x05)
				}
				Else
				{
					Return (0x04)
				}
			}
			If ((Arg0 == 0x03))
			{
				Return (0xFF)
			}
			If ((Arg0 == 0x04))
			{
				OWGD (Zero)
				Return (One)
			}
			If ((Arg0 == 0x05))
			{
				OWGD (One)
				Return (One)
			}
			If ((Arg0 == 0x80))
			{
				Return (One)
			}
		}
		Method (_STA, 0, NotSerialized)  // _STA: Status
		{
			If ((MSOS () >= OSW8))
			{
				Return (0x0F)
			}
			Else
			{
				Return (Zero)
			}
		}
	}

On the Asus laptops that do not have an airplane mode LED, OWGD has an
empty implementation and OWGS simply returns 0. On the ones that have an
airplane mode LED these methods have the following implementation:

	Method (OWGD, 1, Serialized)
	{
		SGPL (0x0203000F, Arg0)
		SGPL (0x0203000F, Arg0)
	}

	Method (OWGS, 0, Serialized)
	{
		Store (RGPL (0x0203000F), Local0)
		Return (Local0)
	}

Where OWGD(1) sets the airplane mode LED ON, OWGD(0) set it off, and
OWGS() returns its state.

This commit exposes the airplane mode indicator LED to userspace under
the name asus-wireless::airplane, so it can be driven according to
userspace's policy.
Signed-off-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com>
Reviewed-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      2c1a49c9
  27. 29 6月, 2016 1 次提交
  29. 09 6月, 2016 1 次提交
  31. 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
  33. 24 3月, 2016 3 次提交
  35. 20 1月, 2016 6 次提交
  37. 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
  39. 31 10月, 2015 1 次提交
  41. 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
  43. 03 10月, 2015 1 次提交
  45. 26 8月, 2015 1 次提交
  47. 30 6月, 2015 1 次提交
  49. 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
  51. 11 6月, 2015 1 次提交
  53. 26 5月, 2015 1 次提交
  55. 07 5月, 2015 2 次提交