linux-toradex.git/drivers, branch v3.17.6

clk: qcom: Fix duplicate rbcpr clock name

2014-12-06T23:57:34+00:00

commit 9a6cb70f40b0268297024949eb0a2689e3b7769b upstream.

There is a duplication in a clock name for apq8084 platform that causes
the following warning: "RBCPR_CLK_SRC" redefined

Resolve this by adding a MMSS_ prefix to this clock and making its name
coherent with msm8974 platform.

Fixes: 2b46cd23a5a2 ("clk: qcom: Add APQ8084 Multimedia Clock Controller (MMCC) support")
Signed-off-by: Georgi Djakov 
Reviewed-by: Stephen Boyd 
Signed-off-by: Michael Turquette 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Ignore long hpds on eDP ports

2014-12-06T23:57:34+00:00

original upstream id: 7a7f84ccb82e542c845c43f604665ccea1247866

Turning vdd on/off can generate a long hpd pulse on eDP ports. In order
to handle hpd we would need to turn on vdd to perform aux transfers.
This would lead to an endless cycle of
"vdd off -> long hpd -> vdd on -> detect -> vdd off -> ..."

So ignore long hpd pulses on eDP ports. eDP panels should be physically
tied to the machine anyway so they should not actually disappear and
thus don't need long hpd handling. Short hpds are still needed for link
re-train and whatnot so we can't just turn off the hpd interrupt
entirely for eDP ports. Perhaps we could turn it off whenever the panel
is disabled, but just ignoring the long hpd seems sufficient.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Dave Airlie 
Reviewed-by: Todd Previte 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: check TLV flag before trying to use hotspot firmware commands

2014-12-06T23:57:33+00:00

commit 5ac6c72e594471acfa5b00210c51d533a73413ad upstream.

Older firmwares do not provide support for the HOT_SPOT_CMD command.
Check for the appropriate TLV flag that declares hotspot support in
the firmware to prevent a firmware assertion failure that can be
triggered from the userspace,

Signed-off-by: Luciano Coelho 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: ROC - bug fixes around time events and locking

2014-12-06T23:57:33+00:00

commit a6cc5163149532734b84c86cbffa4994e527074b upstream.

Don't add the time event to the list. We added it several
times the same time event, which leads to an infinite loop
when walking the list.

Since we (currently) don't support more than one ROC for STA
vif at a time, enforce this and don't add the time event
to any list.

We were also missing the locking of the mutex which led to
a lockdep splat - fix that.

Signed-off-by: Matti Gottlieb 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: initialize sadb to NULL in the audio code

2014-12-06T23:57:33+00:00

commit 83d04c39f9048807a8500e575ae3f1718a3f45bb upstream.

Fixes kfree of the sadb buffer when it's NULL.

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

gpu/radeon: Set flag to indicate broken 64-bit MSI

2014-12-06T23:57:33+00:00

commit 91ed6fd2c383bb8f02d66e98b4a4d2f7207249dc upstream.

Some radeon ASICs don't support all 64 address bits of MSIs despite
advertising support for 64-bit MSIs in their configuration space.

This breaks on systems such as IBM POWER7/8, where 64-bit MSIs can
be assigned with some of the high address bits set.

This makes use of the newly introduced "no_64bit_msi" flag in structure
pci_dev to allow the MSI allocation code to fallback to 32-bit MSIs
on those adapters.

Adding Alex's review tag. Patch to the driver is identical to the
reviewed one, I dropped the arch/powerpc hunk rewrote the subject
and cset comment.

Signed-off-by: Benjamin Herrenschmidt 
Reviewed-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: report disconnected for LVDS/eDP with PX if ddc fails

2014-12-06T23:57:33+00:00

commit 1348579433566355e570008929daa09a0db64fd8 upstream.

If ddc fails, presumably the i2c mux (and hopefully the signal
mux) are switched to the other GPU so don't fetch the edid from
the vbios so that the connector reports disconnected.

bug:
https://bugzilla.opensuse.org/show_bug.cgi?id=904417

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Ignore SURFLIVE and flip counter when the GPU gets reset

2014-12-06T23:57:33+00:00

commit bdfa7542d40e6251c232a802231b37116bd31b11 upstream.

During a GPU reset we need to get pending page flip cleared out
since the ring contents are gone and flip will never complete
on its own. This used to work until the mmio vs. CS flip race
detection came about. That piece of code is looking for a
specific surface address in the SURFLIVE register, but as
a flip to that address may never happen the check may never
pass. So we should just skip the SURFLIVE and flip counter
checks when the GPU gets reset.

intel_display_handle_reset() tries to effectively complete
the flip anyway by calling .update_primary_plane(). But that
may not satisfy the conditions of the mmio vs. CS race
detection since there's no guarantee that a modeset didn't
sneak in between the GPU reset and intel_display_handle_reset().
Such a modeset will not wait for pending flips due to the ongoing GPU
reset, and then the primary plane updates performed by
intel_display_handle_reset() will already use the new surface
address, and thus the surface address the flip is waiting for
might never appear in SURFLIVE. The result is that the flip
will never complete and attempts to perform further page flips
will fail with -EBUSY.

During the GPU reset intel_crtc_has_pending_flip() will return
false regardless, so the deadlock with a modeset vs. the error
work acquiring crtc->mutex was avoided. And the reset_counter
check in intel_crtc_has_pending_flip() actually made this bug
even less severe since it allowed normal modesets to go through
even though there's a pending flip.

This is a regression introduced by me here:
 commit 75f7f3ec600524c9544cc31695155f1a9ddbe1d9
 Author: Ville Syrjälä 
 Date:   Tue Apr 15 21:41:34 2014 +0300

    drm/i915: Fix mmio vs. CS flip race on ILK+

Testcase: igt/kms_flip/flip-vs-panning-vs-hang
Signed-off-by: Ville Syrjälä 
Reviewed-by: Chris Wilson 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Kick fbdev before vgacon

2014-12-06T23:57:33+00:00

commit 0485c9dc24ec0939b42ca5104c0373297506b555 upstream.

It's magic, but it seems to work.

This fixes a regression introduced in

commit 1bb9e632a0aeee1121e652ee4dc80e5e6f14bcd2
Author: Daniel Vetter 
Date:   Tue Jul 8 10:02:43 2014 +0200

    drm/i915: Only unbind vgacon, not other console drivers

My best guess is that the vga fbdev driver falls over if we rip out
parts of vgacon. Hooray.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82439
Reported-and-tested-by: Lv Zheng 
Signed-off-by: Daniel Vetter 
Acked-by: Chris Wilson 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: drop WaSetupGtModeTdRowDispatch:snb

2014-12-06T23:57:33+00:00

commit 2208d655a91f9879bd9a39ff9df05dd668b3512c upstream.

This reverts the regressing

commit 6547fbdbfff62c99e4f7b4f985ff8b3454f33b0f
Author: Daniel Vetter 
Date:   Fri Dec 14 23:38:29 2012 +0100

    drm/i915: Implement WaSetupGtModeTdRowDispatch

that causes GPU hangs immediately on boot.

Reported-by: Leo Wolf 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79996
Signed-off-by: Daniel Vetter 
[Jani: amended the commit message slightly.]
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman