linux-toradex.git/drivers/gpu/drm/i915/intel_display.c, branch v4.1.26

drm/i915: Update atomic state when removing mst connector, v3.

2016-04-20T05:03:45+00:00

[ Upstream commit 20fae983c6667d038e810c618e3340946b8dc506 ]

Fully remove the MST connector from the atomic state, and remove the
early returns in check_*_state for MST connectors.

With atomic the state can be made consistent all the time.

Thanks to Sivakumar Thulasimani for the idea of using
drm_atomic_helper_set_config.

Changes since v1:
- Remove the MST check in intel_connector_check_state too.
Changes since v2:
- Use drm_atomic_helper_set_config.

Signed-off-by: Maarten Lankhorst 
Cc: Sivakumar Thulasimani 
Reviewed-by: Sivakumar Thulasimani 
Signed-off-by: Daniel Vetter 
Signed-off-by: Sasha Levin

drm/i915/dp: fall back to 18 bpp when sink capability is unknown

2016-02-15T20:45:29+00:00

[ Upstream commit 5efd407674068dede403551bea3b0b134c32513a ]

Per DP spec, the source device should fall back to 18 bpp, VESA range
RGB when the sink capability is unknown. Fix the color depth
clamping. 18 bpp color depth should ensure full color range in automatic
mode.

The clamping has been HDMI specific since its introduction in

commit 996a2239f93b03c5972923f04b097f65565c5bed
Author: Daniel Vetter 
Date:   Fri Apr 19 11:24:34 2013 +0200

    drm/i915: Disable high-bpc on pre-1.4 EDID screens

Cc: stable@vger.kernel.org
Reported-and-tested-by: Dihan Wickremasuriya 
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331
Reviewed-by: Ville Syrjälä 
Signed-off-by: Jani Nikula 
Link: http://patchwork.freedesktop.org/patch/msgid/1452695720-7076-1-git-send-email-jani.nikula@intel.com
(cherry picked from commit 013dd9e038723bbd2aa67be51847384b75be8253)
Signed-off-by: Sasha Levin

drm/i915: Deny wrapping an userptr into a framebuffer

2015-11-09T22:33:35+00:00

commit cc917ab43541db3ff66d0136042686d40a1b4c9a upstream.

Pinning a userptr onto the hardware raises interesting questions about
the lifetime of such a surface as the framebuffer extends that life
beyond the client's address space. That is the hardware will need to
keep scanning out from the backing storage even after the client wants
to remap its address space. As the hardware pins the backing storage,
the userptr becomes invalid and this raises a WARN when the clients
tries to unmap its address space. The situation can be even more
complicated when the buffer is passed between processes, between a
client and display server, where the lifetime and hardware access is
even more confusing. Deny it.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
Cc: Michał Winiarski 
Reviewed-by: Tvrtko Ursulin 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Restore lost DPLL register write on gen2-4

2015-11-09T22:33:35+00:00

commit 8e7a65aa70bcc1235a44e40ae0da5056525fe081 upstream.

We accidentally lost the initial DPLL register write in
1c4e02746147 drm/i915: Fix DVO 2x clock enable on 830M

The "three times for luck" hack probably saved us from a total
disaster. But anyway, bring the initial write back so that the
code actually makes some sense.

Reported-and-tested-by: Nick Bowler 
References: http://mid.gmane.org/CAN_QmVyMaArxYgEcVVsGvsMo7-6ohZr8HmF5VhkkL4i9KOmrhw@mail.gmail.com
Cc: Nick Bowler 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Preserve SSC earlier

2015-09-21T17:05:26+00:00

commit 69f92f67b68ab7028ffe15f0eea76b59f8859383 upstream.

Commit 92122789b2d6 ("drm/i915: preserve SSC if previously set v3")
added code to intel_modeset_gem_init to override the SSC status read
from VBT with the SSC status set by BIOS.

However, intel_modeset_gem_init is invoked *after* intel_modeset_init,
which calls intel_setup_outputs, which *modifies* SSC status by way of
intel_init_pch_refclk. So unlike advertised, intel_modeset_gem_init
doesn't preserve the SSC status set by BIOS but whatever
intel_init_pch_refclk decided on.

This is a problem on dual gpu laptops such as the MacBook Pro which
require either a handler to switch DDC lines, or the discrete gpu
to proxy DDC/AUX communication: Both the handler and the discrete
gpu may initialize after the i915 driver, and consequently, an LVDS
connector may initially seem disconnected and the SSC therefore
is disabled by intel_init_pch_refclk, but on reprobe the connector
may turn out to be connected and the SSC must then be enabled.

Due to 92122789b2d6 however, the SSC is not enabled on reprobe since
it is assumed BIOS disabled it while in fact it was disabled by
intel_init_pch_refclk.

Also, because the SSC status is preserved so late, the preserved value
only ever gets used on resume but not on panel initialization:
intel_modeset_init calls intel_init_display which indirectly calls
intel_panel_use_ssc via multiple subroutines, *before* the BIOS value
overrides the VBT value in intel_modeset_gem_init (intel_panel_use_ssc
is the sole user of dev_priv->vbt.lvds_use_ssc).

Fix this by moving the code introduced by 92122789b2d6 from
intel_modeset_gem_init to intel_modeset_init before the invocation
of intel_setup_outputs and intel_init_display.

Add a DRM_DEBUG_KMS as suggested way back by Jani:
http://lists.freedesktop.org/archives/intel-gfx/2014-June/046666.html

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Paul Hordiienko 
    [MBP  6,2 2010  intel ILK + nvidia GT216  pre-retina]
Tested-by: William Brown 
    [MBP  8,2 2011  intel SNB + amd turks     pre-retina]
Tested-by: Lukas Wunner 
    [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina]
Tested-by: Bruno Bierbaumer 
    [MBP 11,3 2013  intel HSW + nvidia GK107  retina -- work in progress]
Fixes: 92122789b2d6 ("drm/i915: preserve SSC if previously set v3")
Signed-off-by: Lukas Wunner 
Reviewed-by: Jesse Barnes 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix IPS related flicker

2015-08-03T16:29:09+00:00

commit ac88cd738425e04dbed3706621cf613a00708834 upstream.

We cannot let IPS enabled with no plane on the pipe:

BSpec: "IPS cannot be enabled until after at least one plane has
been enabled for at least one vertical blank." and "IPS must be
disabled while there is still at least one plane enabled on the
same pipe as IPS." This restriction apply to HSW and BDW.

However a shortcut path on update primary plane function
to make primary plane invisible by setting DSPCTRL to 0
was leting IPS enabled while there was no
other plane enabled on the pipe causing flickerings that we were
believing that it was caused by that other restriction where
ips cannot be used when pixel rate is greater than 95% of cdclok.

v2: Don't mess with Atomic path as pointed out by Ville.

Reference: https://bugs.freedesktop.org/show_bug.cgi?id=85583
Cc: Ville Syrjälä 
Cc: Paulo Zanoni 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Drop PIPE-A quirk for 945GSE HP Mini

2015-05-07T12:28:34+00:00

Since the introduction of BIOS fb preservation, circa 3.17, we began
encountering a failure during boot when trying to use force-detect
before GEM was initialised. That bug is from

commit 7fad798e16fecddd41c6a91728a09f0b9507e40c
Author: Daniel Vetter 
Date:   Wed Jul 4 17:51:47 2012 +0200

    drm/i915: ensure the force pipe A quirk is actually followed

but investigation of the affected machine revealed that it was using a
PIPE-A quirk even though it was a 945GSE and the quirk is only supposed
to be used to workaround a hardware issue on 830/845. That quirk was
added for this HP Mini in

commit 6b93afc564a5e74b0eaaa46c95f557449951b3b9
Author: Bryce Harrington 
Date:   Wed May 27 03:40:52 2009 -0700

    add pipe a force quirk for Dell mini

in order to workaround an issue with the BIOS behaving strangely during
lid-close. Since then we have a much larger hammer to thwart the BIOS
after opening the lid and the PIPE-A quirk is no longer required.

Reported-and-tested-by: Apostolos B. 
References: https://bugs.freedesktop.org/show_bug.cgi?id=21960
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=87521
Signed-off-by: Chris Wilson 
Signed-off-by: Jani Nikula

drm/i915: Move drm_framebuffer_unreference out of struct_mutex for takeover

2015-04-14T13:09:05+00:00

intel_user_framebuffer_destroy() requires the struct_mutex for its
object bookkeeping, so this means that all calls to
drm_framebuffer_unreference must be held without that lock.

This is a simplified version of the identically named patch by Chris Wilson.

    Regression from commit ab8d66752a9c28cd6c94fa173feacdfc1554aa03
    Author: Tvrtko Ursulin 
    Date:   Mon Feb 2 15:44:15 2015 +0000

        drm/i915: Track old framebuffer instead of object

v2: Bikeshedding.

References: https://bugs.freedesktop.org/show_bug.cgi?id=89166
Cc: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Jani Nikula

drm/i915: Allocate connector state together with the connectors

2015-04-13T12:21:21+00:00

Connector states were being allocated in intel_setup_outputs() in loop
over all connectors. That meant hot-added connectors would have a NULL
state. Since the change to use a struct drm_atomic_state for the legacy
modeset, connector states are necessary for the i915 driver to function
properly, so that would lead to oopses.

Broken by

commit 944b0c76575753da5a332aab0a1d8c6df65a076b
Author: Ander Conselvan de Oliveira 
Date:   Fri Mar 20 16:18:07 2015 +0200

    drm/i915: Copy the staged connector config to the legacy atomic state

v2: Fix test for intel_connector_init() success in lvds and sdvo (PRTS)

Signed-off-by: Ander Conselvan de Oliveira 
Reported-and-tested-by: Nicolas Kalkhof 
Signed-off-by: Daniel Vetter 
Signed-off-by: Jani Nikula

drm/i915: Handle error to get connector state when staging config

2015-03-27T14:06:52+00:00

The return value of one of the calls to drm_atomic_get_connector_state()
in intel_modeset_stage_output_state() wasn't checked for errors.

Reported-by: Dan Carpenter 
Signed-off-by: Ander Conselvan de Oliveira 
Signed-off-by: Daniel Vetter