- 26 Jun, 2015 2 commits
-
-
Michel Thierry authored
If for some reason [1], the page directory/table does not exist, clear_range would end up in an infinite while loop. Introduced by commit 06fda602 ("drm/i915: Create page table allocators"). [1] This is already being addressed in one of Mika's patches: http://mid.gmane.org/1432314314-23530-17-git-send-email-mika.kuoppala@intel.com Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: stable@vger.kernel.org Reported-by: John Harrison <john.c.harrison@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
-
Rodrigo Vivi authored
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ä <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
-
- 22 Jun, 2015 1 commit
-
-
Ander Conselvan de Oliveira authored
Silence the following -Wmaybe-uninitialized warnings and make the code more clear. drivers/gpu/drm/i915/intel_display.c: In function ‘__intel_set_mode’: drivers/gpu/drm/i915/intel_display.c:11844:14: warning: ‘crtc_state’ may be used uninitialized in this function [-Wmaybe-uninitialized] return state->mode_changed || state->active_changed; ^ drivers/gpu/drm/i915/intel_display.c:11854:25: note: ‘crtc_state’ was declared here struct drm_crtc_state *crtc_state; ^ drivers/gpu/drm/i915/intel_display.c:11868:6: warning: ‘crtc’ may be used uninitialized in this function [-Wmaybe-uninitialized] if (crtc != intel_encoder->base.crtc) ^ drivers/gpu/drm/i915/intel_display.c:11853:19: note: ‘crtc’ was declared here struct drm_crtc *crtc; Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
-
- 17 Jun, 2015 3 commits
-
-
Ander Conselvan de Oliveira authored
The code in intel_crtc_restore_mode() sets the enabled value of all the CRTCs when restoring the mode after a suspend/resume cycle. When more than one CRTC is enabled, that causes drm_atomic_helper_check_modeset() to fail if there is more than one pipe enabled, since all but one CRTC has valid connector data. Instead, set only the enabled value for the CRTC passed as an argument. v2: Don't leak atomic state. (Matt) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90468 References: https://bugs.freedesktop.org/show_bug.cgi?id=90396Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
-
Ander Conselvan de Oliveira authored
The force restore path relies on the staged config to preserve the configuration used before a suspend/resume cycle. The update done to it in intel_modeset_fixup_state() would cause that information to be lost after the first modeset, making it impossible to restore the modes for pipes B and C. References: https://bugs.freedesktop.org/show_bug.cgi?id=90468Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
-
Ander Conselvan de Oliveira authored
Since the force restore logic will restore the CRTCs state one at a time, it is possible that the state will be inconsistent until the whole operation finishes. A call to intel_modeset_check_state() is done once it's over, so don't check the state multiple times in between. This regression was introduced in: commit 7f27126e Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed Nov 5 14:26:06 2014 -0800 drm/i915: factor out compute_config from __intel_set_mode v3 v2: Rename check parameter to force_restore. (Matt) Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94431 Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
-
- 15 Jun, 2015 4 commits
-
-
Francisco Jerez authored
Only bit 27 of SCRATCH1 and bit 6 of ROW_CHICKEN3 are allowed to be set because of security-sensitive bits we don't want userspace to mess with. On HSW hardware the whitelisted bits control whether atomic read-modify-write operations are performed on L3 or on GTI, and when set to L3 (which can be 10x-30x better performing than on GTI, depending on the application) require great care to avoid a system hang, so we currently program them to be handled on GTI by default. Beignet can immediately start taking advantage of this change to enable L3 atomics. Mesa should eventually switch to L3 atomics too, but a number of non-trivial changes are still required so it will continue using GTI atomics for now. Signed-off-by: Francisco Jerez <currojerez@riseup.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
-
Francisco Jerez authored
In some cases it might be unnecessary or dangerous to give userspace the right to write arbitrary values to some register, even though it might be desirable to give it control of some of its bits. This patch extends the register whitelist entries to contain a mask/value pair in addition to the register offset. For registers with non-zero mask, any LRM writes and LRI writes where the bits of the immediate given by the mask don't match the specified value will be rejected. This will be used in my next patch to grant userspace partial write access to some sensitive registers. Signed-off-by: Francisco Jerez <currojerez@riseup.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
-
Francisco Jerez authored
Until now the software command checker assumed that commands could read or write at most a single register per packet. This is not necessarily the case, MI_LOAD_REGISTER_IMM expects a variable-length list of offset/value pairs and writes them in sequence. The previous code would only check whether the first entry was valid, effectively allowing userspace to write unrestricted registers of the MMIO space by sending a multi-register write with a legal first register, with potential security implications on Gen6 and 7 hardware. Fix it by extending the drm_i915_cmd_descriptor table to represent multi-register access and making validate_cmd() iterate for all register offsets present in the command packet. Signed-off-by: Francisco Jerez <currojerez@riseup.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Apparently we can have requests even if though the active list is empty, so do the request retirement regardless of whether there's anything on the active list. The way it happened here is that during suspend intel_ring_idle() notices the olr hanging around and then proceeds to get rid of it by adding a request. However since there was nothing on the active lists i915_gem_retire_requests() didn't clean those up, and so the idle work never runs, and we leave the GPU "busy" during suspend resulting in a WARN later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
-
- 05 Jun, 2015 1 commit
-
-
Rodrigo Vivi authored
04 is the minor version. API version is ver1. So let's follow same scheme used on published version at 01.org. If really needed the minor version a follow-up updated will be done. But for now we need to move fwd and unblock end users. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
-
- 29 May, 2015 3 commits
-
-
Michel Thierry authored
We already set this limit for the GGTT. This is a temporary patch until a full replacement of size_t variables (inadequate in 32-bit kernel) is in place. Regression from: commit a4e0bedc Author: Michel Thierry <michel.thierry@intel.com> Date: Wed Apr 8 12:13:35 2015 +0100 drm/i915: Use complete address space in true PPGTT v2: Prettify code and explain why this is needed. (Chris) v3: Don't hide the compilation warning in 32-bit. (Chris) Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
With unified modeset and flip paths introduced recently when switching to fbcon PSR was being disabled on fb_set_par path but re-enabled on fb_pan_display one, causing missed screen updates and un unusable console. Regression introduced with: commit bb546623 Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Tue Apr 21 17:13:13 2015 +0300 drm/i915: Unify modeset and flip paths of intel_crtc_set_config() Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
Without this frontbuffer flip when enabling planes PSR got compromised and wasn't being enabled waiting forever on the flush that never arrived. Another solution would to create a enable_cursor function and split this frontbuffer flip among the different plane enable and disable functions. But if necessary this can be done in a follow up work. For now let's just fix the regression. It was removed by: commit 87d4300a Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Tue Apr 21 17:12:54 2015 +0300 drm/i915: Move intel_(pre_disable/post_enable)_primary to intel_display.c, and use it there. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 28 May, 2015 7 commits
-
-
Paulo Zanoni authored
This commit is the "sink CRC" version of: commit 8c740dce Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Oct 17 18:42:03 2014 -0300 drm/i915: disable IPS while getting the pipe CRCs. For some unknown reason, when IPS gets enabled, the sink CRC changes. Since hsw_enable_ips() doesn't really guarantee to enable IPS (it depends on package C-states), we can't really predict if IPS is enabled or disabled while running our CRC tests, so let's just completely disable IPS while sink CRCs are being used. If we find a way to make IPS not change the pipe CRC result, we may want to fix IPS and then revert this patch (and 8c740dce too). While this doesn't happen, let's merge this patch, so the IGT tests relying on sink CRCs can work properly. This was discovered while developing a new IGT test, which will probably be called kms_frontbuffer_tracking. Testcase: igt/kms_frontbuffer_tracking (not on upstream IGT yet) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
It's totally broken, and since commit d328c9d7 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Apr 10 16:22:37 2015 +0200 drm/i915: Select starting pipe bpp irrespective or the primary plane the kernel will try to use it even for the common rgb888 framebuffers. Ville has patches to fix it all up properly, but unfortunately they're stuck in review limbo. And since the 4.2 feature cutoff has passed we need to somehow handle this regression. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <przanoni@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
Ville Syrjälä authored
chv_enable_pll() doesn't need to hold sb_lock for the entire duration of the function. Drop the lock as soon as possible. valleyview_set_cdclk() does a potential lock+unlock+lock+unlock cycle with sb_lock. Grab the lock a few lines earlier so we can make do with a single lock+unlock cycle always. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Rename dpio_lock to sb_lock to inform the reader that its primary purpose is to protect the sideband mailbox rather than some DPIO state. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
The primary plane frobbing was removed from the sprite code in commit ecce87ea Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Tue Apr 21 17:12:50 2015 +0300 drm/i915: Remove implicitly disabling primary plane for now but the intel_flush_primary_plane() calls were left behind. Replace them with straight forward POSTING_READ() of the sprite surface address register. The other user of intel_flush_primary_plane() is g4x_disable_trickle_feed() where we can just inline the steps directly. This allows intel_flush_primary_plane() to be killed off. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Expecting CHV power wells to be just an extended versions of the VLV power wells, a bunch of commented out power wells were added in anticipation when Punit folks would implement it all. Turns out they never did, and instead CHV has fewer power wells than VLV. Rip out all the #if 0'ed junk that's not needed. v2: Rename the "pipe-a" well to "display" to match VLV Clarify the pipe A power well relationship to pipes B and C (Deepak) Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Not sure which LDO programming sequence delay should be used for the CHV PHY, but the spec says that 600ns is "Used by default for initial bringup", and the BIOS seems to use that, so let's do the same. Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 27 May, 2015 1 commit
-
-
Michel Thierry authored
commit 53292cdb ("drm/i915: Workaround to avoid lite restore with HEAD==TAIL") added a check for req0 != null which is unnecessary. The only way req0 could be null is if the list was empty, and this is already addressed at the beginning of execlists_context_unqueue(). Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 26 May, 2015 3 commits
-
-
Chris Wilson authored
In commit 1854d5ca Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 7 16:20:32 2015 +0100 drm/i915: Deminish contribution of wait-boosting from clients we removed an atomic timer based check for allowing waitboosting and moved it below the mutex taken during RPS. However, that mutex can be held for long periods of time on Vallyview/Cherryview as communication with the PCU is slow. As clients may frequently wait for results (e.g. such as tranform feedback) we introduced contention between the client and the RPS worker. We can take advantage of the RPS worker, by switching the wait boost decision to use spin locks and defer the actual reclocking to the worker. Fixes a regression of up to 45% on Baytrail and Baswell! v2 (Daniel): - Use max_freq_softlimit instead of the not-yet-merged boost frequency. - Don't inject a fake irq into the boost work, instead treat client_boost as just another legit waker. v3: Drop the now unused mask (Chris). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90112 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
It was reported that this comment was confusing, and indeed it is. v2: (one year later!) Add the range for the DRM_I915_* iotcl defines (Daniel) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
This reverts commit 118182e9. It's causing too much trouble when compile-testing for non-i915 folks. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
- 22 May, 2015 7 commits
-
-
Daniel Vetter authored
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
As Daniel commented on commit b7ffe1362c5f468b853223acc9268804aa92afc8 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Apr 27 13:41:24 2015 +0100 drm/i915: Free RPS boosts for all laggards it is better to be explicit when sharing hardcoded values such as throttle/boost timeouts. Make it so! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
After allocating from the slab cache, we then need to free the request back into the slab cache upon error (and not call kfree as that leads to eventual memory corruption). Fixes regression from commit efab6d8d Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 7 16:20:57 2015 +0100 drm/i915: Use a separate slab for requests Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chandra Konduru authored
There is a mplayer video failure reported with xv. This is because there is a request to do both plane scaling and colorkey. Because skl hw doesn't support plane scaling and colorkey at the same time, request is failed which is expected behavior. To make xv operate, this patch allows colorkey continue to work without using scaler. Then behavior would be similar to platforms without plane scaler support. Signed-off-by: Chandra Konduru <chandra.konduru@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90449 [danvet: change can_scale to bool as requested by Ville.] Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
GTT caching was disabled by default on gen8 due to not working with big pages. Some information suggests that it got fixed, but still GTT caching has been left disabled by default. Or could be it just meant that the default was changed to off, and hence the problem got solved. Enable GTT caching in the hopes of some performance increase. Whether or not the big pages issue has been fixed is irrelevant at this stage since we don't use big pages. This gives me a 1-2% improvement in xonotic on my BSW. Haven't tried BDW, but supposedly it has larger TLBs so might not benefit as much. On HSW GTT caching is enabled by default. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
GEN8_L3SQCREG1 isn't saved in the context (verified by going through a context dump), and so we shouldn't be using the ring w/a code to initialize it. Also Bspec explicitly talks about MMIO and writing it with the CPU. Additionally there's another w/a WaTempDisableDOPClkGating:bdw which tells us to disable DOP clock gating around the GEN8_L3SQCREG1 write to make sure everyone notices the change. So let's do that as well. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
We're not using ilk_init_lp_watermarks() on BDW for some reason. Probably due to the BDW patches and the relevant WM patches landing roughlly at the same time. Fix it up. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 21 May, 2015 8 commits
-
-
Ville Syrjälä authored
Bspec says we should disable the FDI RX/TX before disabling the PCH ports. Do so. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Follow the BSpec sequence for the CRT port as well on PCH platforms, ie. disable the pipe before the port. Didn't bother looking at DDI in detail yet, so leave that one be even though the CRT is a PCH port there. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
While at it also remove the redundant/unneeded w/a like done for hdmi already. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Mention that this also removes the unneeded w/a, as suggested by Jesse.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
BSpec says we should disable all ports after the pipe on PCH platforms. Do so. Fixes a pipe off timeout on ILK now caused by the transcoder B workaround. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Currently the IBX transcoder B workarounds are not working correctly. Well, the HDMI one seems to be working somewhat, but the DP one is definitely busted. After a bit of experimentation it looks like the best way to make this work is first disable the port on transcoder B, and then re-enable it transcoder A, and immediately disable it again. We can also clean up the code by noting that we can't be called without a valid crtc. And also note that port A on ILK does not need the workaround, so let's check for that one too. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
On IBX the SDVO/HDMI register write may be masked when enabling the port, so it may need to written twice. The HDMI code does this, but the SDVO code does not. Add the workaround to the SDVO code as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Currently we're always enabling enhanced framing on CPT even if the sink doesn't support it. Fix this up by actaully looking at what the sink tells us. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Define a TRANS_DP_PIPE_TO_PORT() to make the CPT DP .get_hw_state() pipe readout neater. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-