- 29 Aug, 2016 40 commits
-
-
Adrian Hunter authored
BugLink: http://bugs.launchpad.net/bugs/1591655 Add support for Intel's AVX-512 instructions to the instruction decoder. AVX-512 instructions are documented in Intel Architecture Instruction Set Extensions Programming Reference (February 2016). AVX-512 instructions are identified by a EVEX prefix which, for the purpose of instruction decoding, can be treated as though it were a 4-byte VEX prefix. Existing instructions which can now accept an EVEX prefix need not be further annotated in the op code map (x86-opcode-map.txt). In the case of new instructions, the op code map is updated accordingly. Also add associated Mask Instructions that are used to manipulate mask registers used in AVX-512 instructions. The 'perf tools' instruction decoder is updated in a subsequent patch. And a representative set of instructions is added to the perf tools new instructions test in a subsequent patch. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Acked-by:
Ingo Molnar <mingo@kernel.org> Acked-by:
Masami Hiramatsu <mhiramat@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dan Williams <dan.j.williams@intel.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: X86 ML <x86@kernel.org> Link: http://lkml.kernel.org/r/1469003437-32706-3-git-send-email-adrian.hunter@intel.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> (cherry picked from commit 25af37f4) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com>
-
Adrian Hunter authored
BugLink: http://bugs.launchpad.net/bugs/1591655 vcvtph2ps does not have an immediate operand, so remove the erroneous 'Ib' from its opcode map entry. Add vcvtph2ps to the perf tools new instructions test to verify it. Signed-off-by:
-
James Smart authored
BugLink: http://bugs.launchpad.net/bugs/1608652 Correct issue with ioremap() call on 32bit kernel Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <james.smart@broadcom.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> (cherry picked from commit 115a4124) Signed-off-by:
Brad Figg <brad.figg@canonical.com>
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 SKX has a lot in common with HSX Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit ec53e594) Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 Hard-code BXT ART to 19200MHz, so turbostat --debug can fully enumerate TSC: CPUID(0x15): eax_crystal: 3 ebx_tsc: 186 ecx_crystal_hz: 0 TSC: 1190 MHz (19200000 Hz * 186 / 3 / 1000000) Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 Broxton has a lot in common with SKL Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 Some processors use the Interrupt Response Time Limit (IRTL) MSR value to describe the maximum IRQ response time latency for deep package C-states. (Though others have the register, but do not use it) Lets print it out to give insight into the cases where it is used. IRTL begain in SNB, with PC3/PC6/PC7, and HSW added PC8/PC9/PC10. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 The CPUID.SGX bit was printed, even if --debug was used Signed-off-by:
-
Chen Yu authored
BugLink: http://bugs.launchpad.net/bugs/1591802 MSR_CONFIG_TDP_NOMINAL: should print all 8 bits of base_ratio (bit 0:7) 0xFF MSR_CONFIG_TDP_LEVEL_1: should print all 15 bits of PKG_MIN_PWR_LVL1 (bit 48:62) 0x7FFF should print all 15 bits of PKG_MAX_PWR_LVL1 (bit 32:46) 0x7FFF should print all 8 bits of LVL1_RATIO (bit 16:23) 0xFF should print all 15 bits of PKG_TDP_LVL1 (bit 0:14) 0x7FFF And the same modification to MSR_CONFIG_TDP_LEVEL_2. MSR_TURBO_ACTIVATION_RATIO: should print all 8 bits of MAX_NON_TURBO_RATIO (bit 0:7) 0xFF Signed-off-by:
Chen Yu <yu.c.chen@intel.com> Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 MSR_NHM_SNB_PKG_CST_CFG_CTL: 0x1e008008 (...pkg-cstate-limit=0: unlimited) should print as MSR_NHM_SNB_PKG_CST_CFG_CTL: 0x1e008008 (...pkg-cstate-limit=8: unlimited) Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 turbostat already checks whether calling each cpuid leavf is legal, and it doesn't look at the function return value, so call the simpler gcc intrinsic __cpuid() instead of __get_cpuid(). syntax only, no functional change Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 SGX presence is related to a SKL power workaround, so lets show when that is enabled. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 The accuracy of Bzy_Mhz and Busy% depend on reading the TSC, APERF, and MPERF close together in time. When there is a very short measurement interval, or a large system is profoundly idle, the changes in APERF and MPERF may be very small. They can be small enough that an expensive interrupt between reading APERF and MPERF can cause the APERF/MPERF ratio to become inaccurate, resulting in invalid calculation and display of Bzy_MHz. A dummy APERF read of APERF makes this problem much more rare. Apparently this 1st systemn call after exiting a long stretch of idle is when we typically see expensive timer interrupts that cause large jitter. For the cases that dummy APERF read fails to prevent, we compare the latency of the APERF and MPERF reads. If they differ by more than 2x, we re-issue them. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 The column "GFX%c6" show the percentage of time the GPU is in the "render C6" state, rc6. Deep package C-states on several systems depend on the GPU being in RC6. This information comes from the counter /sys/class/drm/card0/power/rc6_residency_ms, as read before and after the measurement interval. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 Under the column "GFXMHz", show a snapshot of this attribute: /sys/class/graphics/fb0/device/drm/card0/gt_cur_freq_mhz This is an instantaneous snapshot of what sysfs presents at the end of the measurement interval. turbostat does not average or otherwise perform any math on this value. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 The new IRQ column shows how many interrupts have occurred on each CPU during the measurement inteval. This information comes from the difference between /proc/interrupts shapshots made before and after the measurement interval. The first row, the system summary, shows the sum of the IRQS for all CPUs during that interval. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 skip the open(2)/close(2) on each msr read by keeping the /dev/cpu/*/msr files open. The remaining read(2) is generally far fewer cycles than the removed open(2) system call. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 By default... Turbostat --debug gconfiguration info goes to stderr. In FORK mode, turbostat statistics go to stderr. In PERIODIC mode, turbostat statistics go to stdout. These defaults do not change, but an option "--out file" will send all output above only to the specified file. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 some tools processing turbostat output have difficulty with items that begin with %... Reported-by:
Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by:
-
Hubert Chrzaniuk authored
BugLink: http://bugs.launchpad.net/bugs/1591802 Following changes have been made: - changed MSR_NHM_TURBO_RATIO_LIMIT to MSR_TURBO_RATIO_LIMIT in debug print for consistency with Developer Manual - updated definition of bitfields in MSR_TURBO_RATIO_LIMIT and appropriate parsing code - added x200 to list of architectures that do not support Nahlem compatible definition of MSR_TURBO_RATIO_LIMIT register (x200 has the register but bits definition is custom) - fixed typo in code that parses MSR_TURBO_RATIO_LIMIT (logical instead of bitwise operator) - changed MSR_TURBO_RATIO_LIMIT parsing algorithm so the print out had the same order as implementations for other platforms Signed-off-by:
Hubert Chrzaniuk <hubert.chrzaniuk@intel.com> Signed-off-by:
-
Chrzaniuk, Hubert authored
BugLink: http://bugs.launchpad.net/bugs/1591802 x200 does not enable any way to programmatically obtain bus clock speed. Bclk for the architecture has a fixed value of 100 MHz. At the same time x200 cannot be included in has_snb_msrs since it does not support C7 idle state. prior to this patch, MHz values reported on this chip were erroneously calculated using bclk of 133MHz, causing MHz values to be reported 33% higher than actual. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 turbostat -i interval_sec will sample and display statistics every interval_sec. interval_sec used to be a whole number of seconds, but now we accept a decimal, as small as 0.001 sec (1 ms). Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 This MSR is helpful to show if P-state HW coordination is enabled or disabled. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 # turbostat --debug ... CPUID(6): ... HWP, HWPnotify, HWPwindow, HWPepp, HWPpkg ... ... cpu0: MSR_PM_ENABLE: 0x00000001 (HWP) cpu0: MSR_HWP_CAPABILITIES: 0x01050916 (high 0x16 guar 0x9 eff 0x5 low 0x1) cpu0: MSR_HWP_REQUEST: 0x80001604 (min 0x4 max 0x16 des 0x0 epp 0x80 window 0x0 pkg 0x0) cpu0: MSR_HWP_INTERRUPT: 0x00000001 (EN_Guaranteed_Perf_Change, Dis_Excursion_Min) cpu0: MSR_HWP_STATUS: 0x00000000 (No-Guaranteed_Perf_Change, No-Excursion_Min) Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 This CPUID leaf is available on Skylake: CPUID(0x16): base_mhz: 1500 max_mhz: 2200 bus_mhz: 100 Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 for debugging, dump a few more fields: CPUID(1): SSE3 MONITOR EIST TM2 TSC MSR ACPI-TM TM cpu0: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST MONITOR) Signed-off-by:
-
Lyude authored
BugLink: http://bugs.launchpad.net/bugs/1616894 Unfortunately, there's two situations where we lose hpd right now: - Runtime suspend - When we've shut off all of the power wells on Valleyview/Cherryview While it would be nice if this didn't cause issues, this has the ability to get us in some awkward states where a user won't be able to get their display to turn on. For instance; if we boot a Valleyview system without any monitors connected, it won't need any of it's power wells and thus shut them off. Since this causes us to lose HPD, this means that unless the user knows how to ssh into their machine and do a manual reprobe for monitors, none of the monitors they connect after booting will actually work. Eventually we should come up with a better fix then having to enable polling for this, since this makes rpm a lot less useful, but for now the infrastructure in i915 just isn't there yet to get hpd in these situations. Changes since v1: - Add comment explaining the addition of the if (!mode_config->poll_running) in intel_hpd_init() - Remove unneeded if (!dev->mode_config.poll_enabled) in i915_hpd_poll_init_work() - Call to drm_helper_hpd_irq_event() after we disable polling - Add cancel_work_sync() call to intel_hpd_cancel_work() Changes since v2: - Apparently dev->mode_config.poll_running doesn't actually reflect whether or not a poll is currently in progress, and is actually used for dynamic module paramter enabling/disabling. So now we instead keep track of our own poll_running variable in dev_priv->hotplug - Clean i915_hpd_poll_init_work() a little bit Changes since v3: - Remove the now-redundant connector loop in intel_hpd_init(), just rely on intel_hpd_poll_enable() for setting connector->polled correctly on each connector - Get rid of poll_running - Don't assign enabled in i915_hpd_poll_init_work before we actually lock dev->mode_config.mutex - Wrap enabled assignment in i915_hpd_poll_init_work() in READ_ONCE() for doc purposes - Do the same for dev_priv->hotplug.poll_enabled with WRITE_ONCE in intel_hpd_poll_enable() - Add some comments about racing not mattering in intel_hpd_poll_enable Changes since v4: - Rename intel_hpd_poll_enable() to intel_hpd_poll_init() - Drop the bool argument from intel_hpd_poll_init() - Remove redundant calls to intel_hpd_poll_init() - Rename poll_enable_work to poll_init_work - Add some kerneldoc for intel_hpd_poll_init() - Cross-reference intel_hpd_poll_init() in intel_hpd_init() - Just copy the loop from intel_hpd_init() in intel_hpd_poll_init() Changes since v5: - Minor kerneldoc nitpicks Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Lyude <cpaul@redhat.com> Signed-off-by:
Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by:
-
Lyude authored
BugLink: http://bugs.launchpad.net/bugs/1616894 One of the things preventing us from using polling is the fact that calling valleyview_crt_detect_hotplug() when there's a VGA cable connected results in sending another hotplug. With polling enabled when HPD is disabled, this results in a scenario like this: - We enable power wells and reset the ADPA - output_poll_exec does force probe on VGA, triggering a hpd - HPD handler waits for poll to unlock dev->mode_config.mutex - output_poll_exec shuts off the ADPA, unlocks dev->mode_config.mutex - HPD handler runs, resets ADPA and brings us back to the start This results in an endless irq storm getting sent from the ADPA whenever a VGA connector gets detected in the middle of polling. Somewhat based off of the "drm/i915: Disable CRT HPD around force trigger" patch Ville Syrjälä sent a while back Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Lyude authored
BugLink: http://bugs.launchpad.net/bugs/1616894 While VGA hotplugging worked(ish) before, it looks like that was mainly because we'd unintentionally enable it in valleyview_crt_detect_hotplug() when we did a force trigger. This doesn't work reliably enough because whenever the display powerwell on vlv gets disabled, the values set in VLV_ADPA get cleared and consequently VGA hotplugging gets disabled. This causes bugs such as one we found on an Intel NUC, where doing the following sequence of hotplugs: - Disconnect all monitors - Connect VGA - Disconnect VGA - Connect HDMI Would result in VGA hotplugging becoming disabled, due to the powerwells getting toggled in the process of connecting HDMI. Changes since v3: - Expose intel_crt_reset() through intel_drv.h and call that in vlv_display_power_well_init() instead of encoder->base.funcs->reset(&encoder->base); Changes since v2: - Use intel_encoder structs instead of drm_encoder structs Changes since v1: - Instead of handling the register writes ourself, we just reuse intel_crt_detect() - Instead of resetting the ADPA during display IRQ installation, we now reset them in vlv_display_power_well_init() Cc: stable@vger.kernel.org Acked-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Rebase over dev_priv/drm_device embedding.] Signed-off-by:
-
Lyude authored
BugLink: http://bugs.launchpad.net/bugs/1616894 This lets call intel_crt_reset() in contexts where IRQs are disabled and as such, can't hold the locks required to work with the connectors. Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1520446 Broxton has all the HSW C-states, except C3. BXT C-state timing is slightly different. Here we trust the IRTL MSRs as authority on maximum C-state latency, and override the driver's tables with the values found in the associated IRTL MSRs. Further we set the target_residency to 1x maximum latency, trusting the hardware demotion logic. Signed-off-by:
-
Tony Luck authored
BugLink: http://bugs.launchpad.net/bugs/1591815 This is an entirely new driver instead of yet another set of patches to sb_edac.c because: 1) Mapping from PCI devices to socket/memory controller is significantly different. Skylake scatters devices on a socket across a number of PCI buses. 2) There is an extra level of interleaving via the "mcroute" register that would be a little messy to squeeze into the old driver. 3) Validation is getting too expensive. Changes to sb_edac need to be checked against Sandy Bridge, Ivy Bridge, Haswell, Broadwell and Knights Landing. Acked-by:
Aristeu Rozanski <aris@redhat.com> Acked-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 4ec656bd) Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1591815Signed-off-by:
-
Tedd Ho-Jeong An authored
BugLink: http://bugs.launchpad.net/bugs/1591648 This patch adds support for Intel Bluetooth device 3168 also known as Sandy Peak (SdP). T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=8087 ProdID=0aa7 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by:
Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> (cherry picked from commit 439e65d3) Signed-off-by:
-
Chen Yu authored
BugLink: http://bugs.launchpad.net/bugs/1587714 People reported that they can not do a poweroff nor a suspend to ram on their Mac Pro 11. After some investigations it was found that, once the PCI bridge 0000:00:1c.0 reassigns its mm windows to ([mem 0x7fa00000-0x7fbfffff] and [mem 0x7fc00000-0x7fdfffff 64bit pref]), the region of ACPI io resource 0x1804 becomes unaccessible immediately, where the ACPI Sleep register is located, as a result neither poweroff(S5) nor suspend to ram(S3) works. As suggested by Bjorn, further testing shows that, there is an unreported device may be (using) conflict with above aperture, which brings unpredictable result such as the failure of accessing the io port, which blocks the poweroff(S5). Besides if we reassign the memory aperture to the other place, the poweroff works again. As we do not find any resource declared in _CRS which contain above memory aperture, and Mac OS does not use this pci bridge neither, we choose a simple workaround to clear the hotplug flag(suggested by Yinghai Lu), thus do not allocate any resource for this pci bridge, and thereby no conflict anymore. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211 Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Rafael J. Wysocki <rafael@kernel.org> Cc: Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Wen-chien Jesse Sung authored
BugLink: https://launchpad.net/bugs/1512999 Since DMI IDs may be different between models while subsystem IDs of host bridge will stay the same, use pci_get_subsys() instead of dmi_match() to identify Edge Gateways. Signed-off-by:
Wen-chien Jesse Sung <jesse.sung@canonical.com> Acked-by:
-
Masaki Ota authored
Remove an unnecessary codes. Change input_ivent() function to appropriate function. Add the device ID of "HID_DEVICE_ID_ALPS_U1_DUAL". [jkosina@suse.cz: removed unnecessary bitshifts of values passed input_report_key() as spotted by Dmitry] Signed-off-by:
Masaki Ota <masaki.ota@jp.alps.com> Reviewed-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> BugLink: https://bugs.launchpad.net/bugs/1616813 (cherry picked from commit 819d64e5) Signed-off-by:
Ying-Chun Liu (PaulLiu) <paul.liu@canonical.com> Acked-by:
-
Jiri Kosina authored
All devices with ALPS_JP VID are handled by hid-alps driver, hence they require an entry in hid_have_special_driver[]. BugLink: https://bugs.launchpad.net/bugs/1616813Signed-off-by:
-
Jiri Kosina authored
Calculating size of the report as sizeof(pointer) always passess the length corresponding to the pointer type, not the underlying data report. BugLink: https://bugs.launchpad.net/bugs/1616813Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
