linux.git/drivers/gpu, branch v4.6.3

Revert "drm/i915: Exit cherryview_irq_handler() after one pass"

2016-06-24T17:22:05+00:00

This reverts commit 9dbaab56ac09f07a73fe83bf69bec3e31060080a.

Turns out it was a bad idea and was fixed up "properly" in 4.7 but those
patches are too big to put into 4.6, so let's just revert it for now.

Reported-by: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Peter Frühberger 
Cc: Chris Wilson 
Cc: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/core: Do not preserve framebuffer on rmfb, v4.

2016-06-24T17:22:05+00:00

commit f2d580b9a8149735cbc4b59c4a8df60173658140 upstream.

It turns out that preserving framebuffers after the rmfb call breaks
vmwgfx userspace. This was originally introduced because it was thought
nobody relied on the behavior, but unfortunately it seems there are
exceptions.

drm_framebuffer_remove may fail with -EINTR now, so a straight revert
is impossible. There is no way to remove the framebuffer from the lists
and active planes without introducing a race because of the different
locking requirements. Instead call drm_framebuffer_remove from a
workqueue, which is unaffected by signals.

Changes since v1:
- Add comment.
Changes since v2:
- Add fastpath for refcount = 1. (danvet)
Changes since v3:
- Rebased.
- Restore lastclose framebuffer removal too.

Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
Testcase: kms_rmfb_basic
References: https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
Cc: Thomas Hellstrom 
Cc: David Herrmann 
Reviewed-by: Daniel Vetter 
Tested-by: Thomas Hellstrom  #v3
Tested-by: Tvrtko Ursulin 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/6c63ca37-0e7e-ac7f-a6d2-c7822e3d611f@linux.intel.com
Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

drm: msm: remove unused variable

2016-06-08T01:23:43+00:00

commit 6979cd54c0667189bb0805c0fcebfef8afc5a191 upstream.

A recent cleanup removed the only user of the 'kms' variable in
msm_preclose(), causing a harmless compiler warning:

drivers/gpu/drm/msm/msm_drv.c: In function 'msm_preclose':
drivers/gpu/drm/msm/msm_drv.c:468:18: error: unused variable 'kms' [-Werror=unused-variable]

This removes the variable as well.

Signed-off-by: Arnd Bergmann 
Fixes: 4016260ba47a ("drm/msm: fix bug after preclose removal")
Signed-off-by: Rob Clark 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Pass the correct crtc state to .update_plane()

2016-06-08T01:23:41+00:00

commit 9f6151c9039084e18c118831779a99ac8f29e39c upstream.

Pass the current crtc state, not the old crtc state, to the
.update_plane() hook.

Noticed on BSW when PRIMSIZE was getting programmed to a stale value
which produced utter garbage on screen eg. wwhen going from 1920x1080
to 1024x768.

Cc: Maarten Lankhorst 
Fixes: a758e6845825 ("drm/i915: Do not use commit_plane for sprite planes.")
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/1457543247-13987-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Greg Kroah-Hartman

drm/imx: Match imx-ipuv3-crtc components using device node in platform data

2016-06-08T01:23:41+00:00

commit 310944d148e3600dcff8b346bee7fa01d34903b1 upstream.

The component master driver imx-drm-core matches component devices using
their of_node. Since commit 950b410dd1ab ("gpu: ipu-v3: Fix imx-ipuv3-crtc
module autoloading"), the imx-ipuv3-crtc dev->of_node is not set during
probing. Before that, of_node was set and caused an of: modalias to be
used instead of the platform: modalias, which broke module autoloading.

On the other hand, if dev->of_node is not set yet when the imx-ipuv3-crtc
probe function calls component_add, component matching in imx-drm-core
fails. While dev->of_node will be set once the next component tries to
bring up the component master, imx-drm-core component binding will never
succeed if one of the crtc devices is probed last.

Add of_node to the component platform data and match against the
pdata->of_node instead of dev->of_node in imx-drm-core to work around
this problem.

Fixes: 950b410dd1ab ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")
Signed-off-by: Philipp Zabel 
Tested-by: Fabio Estevam 
Tested-by: Lothar Waßmann 
Tested-by: Heiko Schocher 
Tested-by: Chris Ruehl 
Signed-off-by: Greg Kroah-Hartman

drm: Add helper for DP++ adaptors

2016-06-08T01:23:41+00:00

commit b3daa5ef52c26acd7432c787989bd92d48070c76 upstream.

Add a helper which aids in the identification of DP dual mode
(aka. DP++) adaptors. There are several types of adaptors
specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI

Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors
may go as high as 300MHz and they provide a register informing the
source device what the actual limit is. Supposedly also type 1 adaptors
may optionally implement this register. This TMDS clock limit is the
main reason why we need to identify these adaptors.

Type 1 adaptors provide access to their internal registers and the sink
DDC bus through I2C. Type 2 adaptors provide this access both via I2C
and I2C-over-AUX. A type 2 source device may choose to implement either
of these methods. If a source device implements the I2C-over-AUX
method, then the driver will obviously need specific support for such
adaptors since the port is driven like an HDMI port, but DDC
communication happes over the AUX channel.

This helper should be enough to identify the adaptor type (some
type 1 DVI adaptors may be a slight exception) and the maximum TMDS
clock limit. Another feature that may be available is control over
the TMDS output buffers on the adaptor, possibly allowing for some
power saving when the TMDS link is down.

Other user controllable features that may be available in the adaptors
are downstream i2c bus speed control when using i2c-over-aux, and
some control over the CEC pin. I chose not to provide any helper
functions for those since I have no use for them in i915 at this time.
The rest of the registers in the adaptor are mostly just information,
eg. IEEE OUI, hardware and firmware revision, etc.

v2: Pass adaptor type to helper functions to ease driver implementation
    Fix a bunch of typoes (Paulo)
    Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know
    the type (Paulo)
    Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo)
    Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to
    ease future LSPCON enabling
    Remove the unused DP_DUAL_MODE_LAST_RESERVED define
v3: Fix kernel doc function argument descriptions (Jani)
    s/NONE/UNKNOWN/ in drm_dp_dual_mode_detect() docs
    Add kernel doc for enum drm_dp_dual_mode_type
    Actually build the docs
    Fix more typoes
v4: Adjust code indentation of type2 adaptor detection (Shashank)
    Add debug messages for failurs cases (Shashank)
v5: EXPORT_SYMBOL(drm_dp_dual_mode_read) (Paulo)

Cc: Tore Anderson 
Cc: Paulo Zanoni 
Cc: Shashank Sharma 
Cc: Daniel Vetter 
Cc: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma  (v4)
Link: http://patchwork.freedesktop.org/patch/msgid/1462542412-25533-1-git-send-email-ville.syrjala@linux.intel.com
(cherry picked from commit ede53344dbfd1dd43bfd73eb6af743d37c56a7c3)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix watermarks for VLV/CHV

2016-06-08T01:23:41+00:00

commit caed361d83b204b7766924b80463bf7502ee7986 upstream.

commit 92826fcdfc14 ("drm/i915: Calculate watermark related members in the crtc_state, v4.")
broke thigns by removing the pre vs. post wm update distinction. We also
lost the pre plane wm update entirely for VLV/CHV from the crtc enable
path.

This caused underruns on modeset and plane enable/disable on CHV,
and often those can lead to a dead pipe.

So let's bring back the pre vs. post thing, and let's toss in an
explicit wm update to valleyview_crtc_enable() to avoid having to
put it into the common code.

This is more or less a partial revert of the offending commit.

Cc: Maarten Lankhorst 
Cc: drm-intel-fixes@lists.freedesktop.org
Fixes: 92826fcdfc14 ("drm/i915: Calculate watermark related members in the crtc_state, v4.")
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/1457543247-13987-4-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Don't leave old junk in ilk active watermarks on readout

2016-06-08T01:23:41+00:00

commit 7045c3689f148a0c95f42bae8ef3eb2829ac7de9 upstream.

When we read out the watermark state from the hardware we're supposed to
transfer that into the active watermarks, but currently we fail to any
part of the active watermarks that isn't explicitly written. Let's clear
it all upfront.

Looks like this has been like this since the beginning, when I added the
readout. No idea why I didn't clear it up.

Cc: Matt Roper 
Fixes: 243e6a44b9ca ("drm/i915: Init HSW watermark tracking in intel_modeset_setup_hw_state()")
Signed-off-by: Ville Syrjälä 
Reviewed-by: Matt Roper 
Signed-off-by: Matt Roper 
Link: http://patchwork.freedesktop.org/patch/msgid/1463151318-14719-2-git-send-email-ville.syrjala@linux.intel.com
(cherry picked from commit 15606534bf0a65d8a74a90fd57b8712d147dbca6)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

2016-06-08T01:23:41+00:00

commit 0c2fb7c6c8fef2092051192095a7788231ba9a42 upstream.

To save a bit of power, let's try to turn off the TMDS output buffers
in DP++ adaptors when we're not driving the port.

v2: Let's not forget DDI, toss in a debug message while at it
v3: Just do the TMDS output control based on adaptor type. With the
    helper getting passed the type, we wouldn't actually have to
    check at all in the driver, but the check eliminates the debug
    output more honest

Cc: Tore Anderson 
Cc: Paulo Zanoni 
Cc: Shashank Sharma 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/1462216105-20881-4-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Shashank Sharma 
(cherry picked from commit b2ccb822d376d1bbbe5d1f9118d1488b25e6bc6d)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Respect DP++ adaptor TMDS clock limit

2016-06-08T01:23:41+00:00

commit c578d15226c99f0566d5d022f81af6b7d69928db upstream.

Try to detect the max TMDS clock limit for the DP++ adaptor (if any)
and take it into account when checking the port clock.

Note that as with the sink (HDMI vs. DVI) TMDS clock limit we'll ignore
the adaptor TMDS clock limit in the modeset path, in case users are
already "overclocking" their TMDS links. One subtle change here is that
we'll have to respect the adaptor TMDS clock limit when we decide whether
to do 12bpc or 8bpc, otherwise we might end up picking 12bpc and
accidentally driving the TMDS link out of spec even when the user chose
a mode that fits wihting the limits at 8bpc. This means you can't
"overclock" your DP++ dongle at 12bpc anymore, but you can continue to
do so at 8bpc.

Note that for simplicity we'll use the I2C access method for all dual
mode adaptors including type 2. Otherwise we'd have to start mixing
DP AUX and HDMI together. In the future we may need to do that if we
come across any board designs that don't hook up the DDC pins to the
DP++ connectors. Such boards would obviously only work with type 2
dual mode adaptors, and not type 1.

v2: Store adaptor type under indel_hdmi->dp_dual_mode
    Deal with DRM_DP_DUAL_MODE_UNKNOWN
    Pass adaptor type to drm_dp_dual_mode_max_tmds_clock(),
    and use it for type1 adaptors as well

Reported-by: Tore Anderson 
Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
Cc: Paulo Zanoni 
Cc: Shashank Sharma 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/1462216105-20881-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Shashank Sharma 
(cherry picked from commit b1ba124d8e95cca48d33502a4a76b1ed09d213ce)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman