user/sven/linux.git, branch v4.4.10

Linux 4.4.10

2016-05-11T09:23:26Z

drm/i915/skl: Fix DMC load on Skylake J0 and K0

2016-05-11T09:21:27Z

commit a41c8882592fb80458959b10e37632ce030b68ca upstream. The driver does not load firmware for unknown steppings, so these new steppings must be added to the list. Cc: Rodrigo Vivi Signed-off-by: Mat Martineau Reviewed-by: Rodrigo Vivi Signed-off-by: Rodrigo Vivi Link: http://patchwork.freedesktop.org/patch/msgid/1454023163-25469-1-git-send-email-mathew.j.martineau@linux.intel.com Cc: Jani Nikula Signed-off-by: Greg Kroah-Hartman

lib/test-string_helpers.c: fix and improve string_get_size() tests

2016-05-11T09:21:26Z

commit 72676bb53f33fd0ef3a1484fc1ecfd306dc6ff40 upstream. Recently added commit 564b026fbd0d ("string_helpers: fix precision loss for some inputs") fixed precision issues for string_get_size() and broke tests. Fix and improve them: test both STRING_UNITS_2 and STRING_UNITS_10 at a time, better failure reporting, test small an huge values. Fixes: 564b026fbd0d28e9 ("string_helpers: fix precision loss for some inputs") Signed-off-by: Vitaly Kuznetsov Cc: Andy Shevchenko Cc: Rasmus Villemoes Cc: James Bottomley Cc: James Bottomley Cc: "James E.J. Bottomley" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

ACPI / processor: Request native thermal interrupt handling via _OSC

2016-05-11T09:21:26Z

commit a21211672c9a1d730a39aa65d4a5b3414700adfb upstream. There are several reports of freeze on enabling HWP (Hardware PStates) feature on Skylake-based systems by the Intel P-states driver. The root cause is identified as the HWP interrupts causing BIOS code to freeze. HWP interrupts use the thermal LVT which can be handled by Linux natively, but on the affected Skylake-based systems SMM will respond to it by default. This is a problem for several reasons: - On the affected systems the SMM thermal LVT handler is broken (it will crash when invoked) and a BIOS update is necessary to fix it. - With thermal interrupt handled in SMM we lose all of the reporting features of the arch/x86/kernel/cpu/mcheck/therm_throt driver. - Some thermal drivers like x86-package-temp depend on the thermal threshold interrupts signaled via the thermal LVT. - The HWP interrupts are useful for debugging and tuning performance (if the kernel can handle them). The native handling of thermal interrupts needs to be enabled because of that. This requires some way to tell SMM that the OS can handle thermal interrupts. That can be done by using _OSC/_PDC in processor scope very early during ACPI initialization. The meaning of _OSC/_PDC bit 12 in processor scope is whether or not the OS supports native handling of interrupts for Collaborative Processor Performance Control (CPPC) notifications. Since on HWP-capable systems CPPC is a firmware interface to HWP, setting this bit effectively tells the firmware that the OS will handle thermal interrupts natively going forward. For details on _OSC/_PDC refer to: http://www.intel.com/content/www/us/en/standards/processor-vendor-specific-acpi-specification.html To implement the _OSC/_PDC handshake as described, introduce a new function, acpi_early_processor_osc(), that walks the ACPI namespace looking for ACPI processor objects and invokes _OSC for them with bit 12 in the capabilities buffer set and terminates the namespace walk on the first success. Also modify intel_thermal_interrupt() to clear HWP status bits in the HWP_STATUS MSR to acknowledge HWP interrupts (which prevents them from firing continuously). Signed-off-by: Srinivas Pandruvada [ rjw: Subject & changelog, function rename ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

drm/i915: Fake HDMI live status

2016-05-11T09:21:26Z

commit 60b3143c7cac7e8d2ca65c0b347466c5776395d1 upstream. This patch does the following: - Fakes live status of HDMI as connected (even if that's not). While testing certain (monitor + cable) combinations with various intel platforms, it seems that live status register doesn't work reliably on some older devices. So limit the live_status check for HDMI detection, only for platforms from gen7 onwards. V2: restrict faking live_status to certain platforms V3: (Ville) - keep the debug message for !live_status case - fix indentation of comment - remove "warning" from the debug message (Jani) - Change format of fix details in the commit message Fixes: 237ed86c693d ("drm/i915: Check live status before reading edid") Suggested-by: Ville Syrjala Signed-off-by: Shashank Sharma Link: http://patchwork.freedesktop.org/patch/msgid/1461237606-16491-1-git-send-email-shashank.sharma@intel.com Signed-off-by: Ville Syrjälä (cherry picked from commit 4f4a8185011773f7520d9916c6857db946e7f9d1) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

drm/i915: Make RPS EI/thresholds multiple of 25 on SNB-BDW

2016-05-11T09:21:25Z

commit 4ea3959018d09edfa36a9e7b5ccdbd4ec4b99e49 upstream. Somehow my SNB GT1 (Dell XPS 8300) gets very unhappy around GPU hangs if the RPS EI/thresholds aren't suitably aligned. It seems like scheduling/timer interupts stop working somehow and things get stuck eg. in usleep_range(). I bisected the problem down to commit 8a5864377b12 ("drm/i915/skl: Restructured the gen6_set_rps_thresholds function") I observed that before all the values were at least multiples of 25, but afterwards they are not. And rounding things up to the next multiple of 25 does seem to help, so lets' do that. I also tried roundup(..., 5) but that wasn't sufficient. Also I have no idea if we might need this sort of thing on gen9+ as well. These are the original EI/thresholds: LOW_POWER GEN6_RP_UP_EI 12500 GEN6_RP_UP_THRESHOLD 11800 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 21250 BETWEEN GEN6_RP_UP_EI 10250 GEN6_RP_UP_THRESHOLD 9225 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 18750 HIGH_POWER GEN6_RP_UP_EI 8000 GEN6_RP_UP_THRESHOLD 6800 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 15000 These are after 8a5864377b12: LOW_POWER GEN6_RP_UP_EI 12500 GEN6_RP_UP_THRESHOLD 11875 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 21250 BETWEEN GEN6_RP_UP_EI 10156 GEN6_RP_UP_THRESHOLD 9140 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 18750 HIGH_POWER GEN6_RP_UP_EI 7812 GEN6_RP_UP_THRESHOLD 6640 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 15000 And these are what we have after this patch: LOW_POWER GEN6_RP_UP_EI 12500 GEN6_RP_UP_THRESHOLD 11875 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 21250 BETWEEN GEN6_RP_UP_EI 10175 GEN6_RP_UP_THRESHOLD 9150 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 18750 HIGH_POWER GEN6_RP_UP_EI 7825 GEN6_RP_UP_THRESHOLD 6650 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 15000 Cc: Akash Goel Cc: Chris Wilson Testcase: igt/kms_pipe_crc_basic/hang-read-crc-pipe-B Fixes: 8a5864377b12 ("drm/i915/skl: Restructured the gen6_set_rps_thresholds function") Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1461159836-9108-1-git-send-email-ville.syrjala@linux.intel.com Acked-by: Chris Wilson Reviewed-by: Patrik Jakobsson (cherry picked from commit 8a292d016d1cc4938ff14b4df25328230b08a408) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix eDP low vswing for Broadwell

2016-05-11T09:21:24Z

commit 992e7a41f9fcc7bcd10e7d346aee5ed7a2c241cb upstream. It was noticed on bug #94087 that module parameter i915.edp_vswing=2 that should override the VBT setting to use default voltage swing (400 mV) was not applied for Broadwell. This patch provides a fix for this by checking if default i.e. higher voltage swing is requested to be used and applies the DDI translations table for DP instead of eDP (low vswing) table. v2: Combine two if statements into one (Jani) v3: Change dev_priv->edp_low_vswing to use dev_priv->vbt.edp.low_vswing Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94087 Signed-off-by: Mika Kahola Link: http://patchwork.freedesktop.org/patch/msgid/1461155942-7749-1-git-send-email-mika.kahola@intel.com Signed-off-by: Ville Syrjälä (cherry picked from commit 00983519214b61c1b9371ec2ed55a4dde773e384) [Jani: s/dev_priv->vbt.edp.low_vswing/dev_priv->edp_low_vswing/ to backport] Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

drm/i915/ddi: Fix eDP VDD handling during booting and suspend/resume

2016-05-11T09:21:24Z

commit 5eaa60c7109b40f17ac81090bc8b90482da76cd1 upstream. The driver's VDD on/off logic assumes that whenever the VDD is on we also hold an AUX power domain reference. Since BIOS can leave the VDD on during booting and resuming and on DDI platforms we won't take a corresponding power reference, the above assumption won't hold on those platforms and an eventual delayed VDD off work will do an extraneous AUX power domain put resulting in a refcount underflow. Fix this the same way we did this for non-DDI DP encoders: commit 6d93c0c41760c0 ("drm/i915: fix VDD state tracking after system resume") At the same time call the DP encoder suspend handler the same way as the non-DDI DP encoders do to flush any pending VDD off work. Leaving the work running may cause a HW access where we don't expect this (at a point where power domains are suspended already). While at it remove an unnecessary function call indirection. This fixed for me AUX refcount underflow problems on BXT during suspend/resume. CC: Ville Syrjälä Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1460963062-13211-4-git-send-email-imre.deak@intel.com (cherry picked from commit bf93ba67e9c05882f05b7ca2d773cfc8bf462c2a) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

drm/radeon: make sure vertical front porch is at least 1

2016-05-11T09:21:23Z

commit 3104b8128d4d646a574ed9d5b17c7d10752cd70b upstream. hw doesn't like a 0 value. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

iio: ak8975: fix maybe-uninitialized warning

2016-05-11T09:21:23Z

commit 05be8d4101d960bad271d32b4f6096af1ccb1534 upstream. If i2c_device_id *id is NULL and acpi_match_device returns NULL too, then chipset may be unitialized when accessing &ak_def_array[chipset] in ak8975_probe. Therefore initialize chipset to AK_MAX_TYPE, which will return an error when not changed. This patch fixes the following maybe-uninitialized warning: drivers/iio/magnetometer/ak8975.c: In function ‘ak8975_probe’: drivers/iio/magnetometer/ak8975.c:788:14: warning: ‘chipset’ may be used uninitialized in this function [-Wmaybe-uninitialized] data->def = &ak_def_array[chipset]; Signed-off-by: Richard Leitner Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman