- 22 6月, 2015 1 次提交
-
-
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: NChris Wilson <chris@chris-wilson.co.uk> Suggested-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 19 6月, 2015 1 次提交
-
-
由 Hans de Goede 提交于
This results in a nice cleanup, as we can replace the complicated logic from should_ignore_backlight_request() with a simple check for the type being native. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NDarren Hart <dvhart@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 17 6月, 2015 3 次提交
-
-
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: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
-
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: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
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: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 15 6月, 2015 6 次提交
-
-
由 Francisco Jerez 提交于
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: NFrancisco Jerez <currojerez@riseup.net> Reviewed-by: NZhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Francisco Jerez 提交于
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: NFrancisco Jerez <currojerez@riseup.net> Reviewed-by: NZhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Francisco Jerez 提交于
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: NFrancisco Jerez <currojerez@riseup.net> Reviewed-by: NZhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Jani Nikula 提交于
This reverts commit 0aedb162. I messed things up while applying [1] to drm-intel-fixes. Rectify. [1] http://mid.gmane.org/1432827156-9605-1-git-send-email-ville.syrjala@linux.intel.com Fixes: 0aedb162 ("drm/i915: Don't skip request retirement if the active list is empty") Cc: stable@vger.kernel.org Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
With the introduction of multiple views of an obj in the same vm, each vma was taught to cache its copy of the pages (so that different views could have different page arrangements). However, this missed decoupling those vma->ggtt_view.pages when the vma released its reference on the obj->pages. As we don't always free the vma, this leads to a possible scenario (e.g. execbuffer interrupted by the shrinker) where the vma points to a stale obj->pages, and explodes. Fixes regression from commit fe14d5f4 Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Date: Wed Dec 10 17:27:58 2014 +0000 drm/i915: Infrastructure for supporting different GGTT views per object Tvrtko says, if someone else will be confused how this can happen, key is the reservation execbuffer path. That puts the VMA on the exec_list which prevents i915_vma_unbind and i915_gem_vma_destroy from fully destroying the VMA. So the VMA is left existing as an empty object in the list - unbound and disassociated with the backing store. Kind of a cached memory object. And then re-using it needs to clear the cached pages pointer which is fixed above. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1227892Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Michel Thierry <michel.thierry@intel.com> Cc: stable@vger.kernel.org Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> [Jani: Added Tvrtko's explanation to commit message.] Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 09 6月, 2015 1 次提交
-
-
由 Jani Nikula 提交于
Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI devices, as they do not have a sink device in them to respond to any AUX traffic. When probing these dongles over the DDC, sometimes they will NAK the first attempt even though the transaction is valid and they support the DDC protocol. The retry loop inside of drm_do_probe_ddc_edid() would normally catch this case and try the transaction again, resulting in success. That, however, was thwarted by the fix for [1]: commit 9292f37e Author: Eugeni Dodonov <eugeni.dodonov@intel.com> Date: Thu Jan 5 09:34:28 2012 -0200 drm: give up on edid retries when i2c bus is not responding This added code to exit immediately if the return code from the i2c_transfer function was -ENXIO in order to reduce the amount of time spent in waiting for unresponsive or disconnected devices. That was possible because the underlying i2c bit banging algorithm had retries of its own (which, of course, were part of the reason for the bug the commit fixes). Since its introduction in commit f899fc64 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jul 20 15:44:45 2010 -0700 drm/i915: use GMBUS to manage i2c links we've been flipping back and forth enabling the GMBUS transfers, but we've settled since then. The GMBUS implementation does not do any retries, however, bailing out of the drm_do_probe_ddc_edid() retry loop on first encounter of -ENXIO. This, combined with Eugeni's commit, broke the retry on -ENXIO. Retry GMBUS once on -ENXIO on first message to mitigate the issues with passive adapters. This patch is based on the work, and commit message, by Todd Previte <tprevite@gmail.com>. [1] https://bugs.freedesktop.org/show_bug.cgi?id=41059 v2: Don't retry if using bit banging. v3: Move retry within gmbux_xfer, retry only on first message. v4: Initialize GMBUS0 on retry (Ville). v5: Take index reads into account (Ville). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85924 Cc: Todd Previte <tprevite@gmail.com> Cc: stable@vger.kernel.org Tested-by: Oliver Grafe <oliver.grafe@ge.com> (v2) Tested-by: NJim Bride <jim.bride@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 08 6月, 2015 1 次提交
-
-
In the commit below, I missed the connector allocation in the function intel_sdvo_analog_init(), leading to those connectors to have a NULL state pointer. commit 08d9bc92 Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Fri Apr 10 10:59:10 2015 +0300 drm/i915: Allocate connector state together with the connectors Reported-by: NStefan Lippers-Hollmann <s.l-h@gmx.de> Tested-by: NStefan Lippers-Hollmann <s.l-h@gmx.de> Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 05 6月, 2015 1 次提交
-
-
由 Rodrigo Vivi 提交于
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: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 04 6月, 2015 3 次提交
-
-
由 Ville Syrjälä 提交于
commit 65ca7514 Author: Damien Lespiau <damien.lespiau@intel.com> Date: Mon Feb 9 19:33:22 2015 +0000 drm/i915/skl: Implement WaBarrierPerformanceFixDisable got misapplied and the code landed in chv_init_workarounds() instead of the intended skl_init_workarounds(). Move it over to the right place. Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
Add all missing platforms handled by intel_set_memory_cxsr() to the i915_sr_status debugfs entry. v2: Add G4X too. (Ville) Clarify the change also affects CHV. (Ander) References: https://bugs.freedesktop.org/show_bug.cgi?id=89792Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Arun Siluvery 提交于
After GPU reset, HW is losing the address of HWS page in the register. The page itself is valid except that HW is not aware of its location. [ 64.368623] [drm:gen8_init_common_ring [i915]] *ERROR* HWS Page address = 0x00000000 [ 64.368655] [drm:gen8_init_common_ring [i915]] *ERROR* HWS Page address = 0x00000000 [ 64.368681] [drm:gen8_init_common_ring [i915]] *ERROR* HWS Page address = 0x00000000 [ 64.368704] [drm:gen8_init_common_ring [i915]] *ERROR* HWS Page address = 0x00000000 This patch reloads this value into the register during ring init. Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 01 6月, 2015 2 次提交
-
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Jim Bride 提交于
According to the HSW b-spec we need to try clock divisors of 63 and 72, each 3 or more times, when attempting DP AUX channel communication on a server chipset. This actually wasn't happening due to a short-circuit that only checked the DP_AUX_CH_CTL_DONE bit in status rather than checking that the operation was done and that DP_AUX_CH_CTL_TIME_OUT_ERROR was not set. [v2] Implemented alternate solution suggested by Jani Nikula. Cc: stable@vger.kernel.org Signed-off-by: NJim Bride <jim.bride@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 30 5月, 2015 1 次提交
-
-
由 Michel Thierry 提交于
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: NDaniel Vetter <daniel.vetter@ffwll.ch> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NMichel Thierry <michel.thierry@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 29 5月, 2015 2 次提交
-
-
由 Rodrigo Vivi 提交于
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: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rodrigo Vivi 提交于
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: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 28 5月, 2015 7 次提交
-
-
由 Paulo Zanoni 提交于
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: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
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: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NDeepak S <deepak.s@linux.intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NDeepak S <deepak.s@linux.intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 27 5月, 2015 2 次提交
-
-
由 Michel Thierry 提交于
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: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NMichel Thierry <michel.thierry@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
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: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 26 5月, 2015 1 次提交
-
-
由 Daniel Vetter 提交于
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: NDaniel Vetter <daniel.vetter@intel.com>
-
- 23 5月, 2015 1 次提交
-
-
由 Daniel Vetter 提交于
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 22 5月, 2015 7 次提交
-
-
由 Chris Wilson 提交于
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: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
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: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chandra Konduru 提交于
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: NChandra 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: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Bspec says we should disable the FDI RX/TX before disabling the PCH ports. Do so. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-