summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2017-07-21Revert "drm/i915: Add option to support dynamic backlight via DPCD"Jani Nikula
This reverts commit ae25eceab616d16a07bcaa434b84463d58a3bdc3. The DPCD backlight commits regress a Thinkpad X1 Carbon 4th Gen and a BXT-P (in CI). Enabling dynamic backlight boots to a black screen, and enabling DPCD backlight leads to a black screen after suspend/resume. References: http://mid.mail-archive.com/20170706135349.6tu3lz7uehazlnnn@boom References: http://mid.mail-archive.com/20170627132326.f2q3yn4bh5flji4q@boom Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101619 Reported-by: David Weinehall <david.weinehall@linux.intel.com> Fixes: ae25eceab616 ("drm/i915: Add option to support dynamic backlight via DPCD") Cc: Jenny TC <jenny.tc@intel.com> Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Puthikorn Voravootivat <puthik@chromium.org> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: intel-gfx@lists.freedesktop.org Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/051eeb592361985d2d06333c61c220dd92253b09.1500542254.git.jani.nikula@intel.com
2017-07-20drm/i915: Drop unpin stall in atomic_prepare_commitDaniel Vetter
The core already does this in setup_commit(). With this we can also remove the unpin_work_count since it's the last user, and also remove the loop since that was only used for stalling against legacy flips. v2: Amend commit message a bit (Chris). Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170720175754.30751-8-daniel.vetter@ffwll.ch
2017-07-20drm/i915: Remove intel_flip_work infrastructureDaniel Vetter
This gets rid of all the interactions between the legacy flip code and the modeset code. Yay! This highlights an ommission in the atomic paths, where we fail to apply a boost to the pending rendering when we miss the target vblank. But the existing code is still dead and can be removed. v2: Note that the boosting doesn't work in atomic (Chris). Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170720175754.30751-7-daniel.vetter@ffwll.ch
2017-07-20drm/i915: adjust has_pending_fb_unpin to atomicDaniel Vetter
A bit an oversight - the current code did nothing, since only legacy flips used the unpin_work_count and assorted logic. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170720175754.30751-6-daniel.vetter@ffwll.ch
2017-07-20drm/i915: Rip out legacy page_flip completion/irq handlingDaniel Vetter
All these races and things are now solved through the vblank evasion trick, plus event handling is done using normal vblank even processing and drm_crtc_arm_vblank_event. We can get rid of all this complexity. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170720175754.30751-5-daniel.vetter@ffwll.ch
2017-07-20drm/i915/selftests: Fix an error handling path in 'mock_gem_device()'Christophe JAILLET
Goto the right label in case of error, otherwise there is a leak. This has been introduced by c5cf9a9147ff. In this patch a goto has not been updated. Fixes: c5cf9a9147ff ("drm/i915: Create a kmem_cache to allocate struct i915_priolist from") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://patchwork.freedesktop.org/patch/msgid/20170719223503.30580-1-christophe.jaillet@wanadoo.fr Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-07-20drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irqPandiyan, Dhinakaran
INTEL_GEN() appears to be the new way of doing these platform checks, so convert this i915_irq.c too. Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1500402480-30741-1-git-send-email-dhinakaran.pandiyan@intel.com
2017-07-20drm/i915: Unbreak gpu reset vs. modeset lockingDaniel Vetter
Taking the modeset locks unconditionally isn't the greatest idea, because atm that part is still broken and times out (and then atomic keels over). And there's really no reason to do so, the old code didn't do that either. To make the patch a bit simpler let's also nuke 2 cases that are only around for the old mmioflip paths. Atomic nonblocking workers will not die (minus bugs) when a gpu reset happens. And of course this doesn't fix any of the gpu reset vs. modeset deadlock fun, but it at least stop modern CI machines from keeling over all over the place for no reason at all. And we still have the explicit testcases to run the fake gpu reset, so coverage isn't that much worse. v2: Split out additional changes on top, restrict this to purely reducing the critical section of modeset locks. v2: Review from Maarten - update comments - don't oops when state is NULL in intel_finish_reset, but try to at least still drop locks properly. The hw is going to be toast anyway. Fixes: 739748939974 ("drm/i915: Fix modeset handling during gpu reset, v5.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170719125502.25696-3-daniel.vetter@ffwll.ch
2017-07-20drm/i915: Nuke legacy flip queueing codeDaniel Vetter
Just a very minimal patch to nuke that code. Lots of the flip interrupt handling stuff is still around. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170719125502.25696-2-daniel.vetter@ffwll.ch
2017-07-20drm/i915: Pass enum pipe to intel_set_pch_fifo_underrun_reporting()Matthias Kaehlcke
Commit a21960339c8c ("drm/i915: Consistently use enum pipe for PCH transcoders") misses some pieces, due to a problem with the patch format, this patch adds the remaining bits. Fixes: a21960339c8c ("drm/i915: Consistently use enum pipe for PCH transcoders") Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170719173928.186638-1-mka@chromium.org
2017-07-19drm/i915/selftests: Mark contexts as lost during freeing of mock deviceChris Wilson
We need to unpin the last retired context early in the shutdown sequence so that its RCU free is done before we try to free the context ida. I included this in a later patch ("drm/i915: Keep a recent cache of freed contexts objects for reuse") and so missed that the selftests were broken in the meantime. Reported-by: Matthew Auld <matthew.auld@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101627 Fixes: 5f09a9c8ab6b ("drm/i915: Allow contexts to be unreferenced locklessly") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170719135957.14603-1-chris@chris-wilson.co.uk Tested-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com>
2017-07-19drm/i915: unregister interfaces first in unloadDaniel Vetter
We first need to make sure no one else can get at us anymore, before we can proceed to tear down all the datastructures. Just a small step towards eventually the perfect unload code ... Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170714224656.6431-3-daniel.vetter@ffwll.ch
2017-07-19drm/i915: Fix fbdev unload sequenceDaniel Vetter
First thing we need to do is unregister the fbdev instance, but we can't just go ahead and kfree it. That must wait until the hotplug and polling work are stopped, since they can race with the with the teardown. That means we need to split up the fbdev teardown into the unregister part and the cleanup part. I originally suspected that this was broken in one of the unload shuffles, but on closer inspection the oldest sequence I've dug out also gets this wrong. Just not quite so badly. I've run drv_module_reload a few hundred times and it's rock solid compared to insta-death beforehand. This bug seems to have been uncovered by commit 88be58be886f1215cc73dc8c273c985eecd7385c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jul 6 15:00:19 2017 +0200 drm/i915/fbdev: Always forward hotplug events But the effect of that seems to only be to increase the race window enough to make it blow up easier. I'm not exactly clear on what's going on there ... v2: Fix whitespace and use fetch_and_zero (Chris). Testcase: igt/drv_module_reload Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101791 Cc: martin.peres@free.fr Cc: chris@chris-wilson.co.uk Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170714224656.6431-2-daniel.vetter@ffwll.ch
2017-07-19drm/atomic-helper: Fix leak in disable_allDaniel Vetter
The legacy plane->fb pointer is refcounted by calling drm_atomic_clean_old_fb(). In practice this isn't a real problem because: - The caller in the i915 gpu reset code restores the original state again, which means the plane->fb pointer won't change, hence can't leak. - Drivers using drm_atomic_helper_shutdown call the fbdev cleanup first, and that usually cleans up the fb through drm_remove_framebuffer, which does this correctly. - Without fbdev the only framebuffers are from userspace, and those get cleaned up (again using drm_remove_framebuffer) befor the driver can even be unloaded. But in i915 I've switched the cleanup sequence around so that the _shutdown() calls happens after the drm_remove_framebuffer(), which is how I discovered this issue. v2: My analysis why the current code was ok for gpu reset and suspend/resume was correct, but then I totally failed to realize that we better keep this symmetric. Thanksfully CI noticed that for balance, a refcounting bug must exist at 2 places if previously there was no issue ... v3: Don't be lazy and compute the plane_mask in commit_duplicated_state properly too, instead of just using ~0U. Cc: martin.peres@free.fr Cc: chris@chris-wilson.co.uk Acked-by: Dave Airlie <airlied@gmail.com> (v1) Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170715093106.19873-1-daniel.vetter@ffwll.ch
2017-07-19drm/i915/selftests: Attach a stub pm_domainChris Wilson
Supply a pm_domain and its ops for our mock GEM device so that device runtime pm doesn't complain even though we only want to mark it permanently active! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170718173028.31207-1-chris@chris-wilson.co.uk Tested-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com>
2017-07-19drm/i915: Drain the device workqueue on unloadChris Wilson
Workers on the i915->wq may rearm themselves so for completeness we need to replace our flush_workqueue() with a call to drain_workqueue() before unloading the device. v2: Reinforce the drain_workqueue with an preceding rcu_barrier() as a few of the tasks that need to be drained may first be armed by RCU. References: https://bugs.freedesktop.org/show_bug.cgi?id=101627 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170718134124.14832-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
2017-07-19drm/i915: More stolen quirkingDaniel Vetter
I've found a bios with an off-by-one at the other end. There's a pnp reservation for 0xc5400000-0xc7fffffe and we want stolen in 0xc6000000 through 0xc8000000. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99872 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98683 Cc: Martin Peres <martin.peres@linux.intel.com> Reviewed-by: Martin Peres <martin.peres@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170719100043.30851-1-daniel.vetter@ffwll.ch
2017-07-19drm/i915: Fix bad comparison in skl_compute_plane_wm, v2.Maarten Lankhorst
ddb_allocation && ddb_allocation / blocks_per_line >= 1 is the same as ddb_allocation >= blocks_per_line, so use the latter to simplify this. This fixes the following compiler warning: drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a boolean expression with an integer other than 0 or 1. Changes since v1: - Rebase, was missing the changes to the macro names. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: d555cb5827d6 ("drm/i915/skl+: use linetime latency if ddb size is not available") Cc: "Mahesh Kumar" <mahesh1.kumar@intel.com> Reported-by: David Binderman <dcb314@hotmail.com> Cc: David Binderman <dcb314@hotmail.com> Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.13-rc1+ Link: http://patchwork.freedesktop.org/patch/msgid/20170717120230.2023-1-maarten.lankhorst@linux.intel.com Reviewed-by: Mahesh Kumar <mahesh1.kumar@intel.com>
2017-07-19drm/i915: Explicit the connector name for DP link training resultPaul Kocialkowski
This adds the connector name when printing a debug message about the DP link training result. It is useful to figure out what connector is failing when multiple DP connectors are used. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170718142536.2306-1-paul.kocialkowski@linux.intel.com
2017-07-18drm/i915: Fix cursor updates on some platformsVille Syrjälä
Turns out that just writing CURPOS isn't sufficient to move the cursor on some platforms. My 830 works just fine, but eg. 945 and PNV don't. On those platforms we need to arm even the CURPOS update with a CURBASE write. Even worse, a write to any of the cursor register apart from CURBASE will cancel an already pending cursor update. So if we have armed a CURCNTR/CURBASE update, a subsequent CURPOS write prior to vblank would cancel that armed update. Thus we're left with a cursor that doesn't appear to move, or even change shape. Fix the problem by always performing the CURBASE write after a CURPOS write. Bspec is somewhat unclear which platforms actually require this CURBASE write and which don't. So to keep it simple and to make sure we really fix the problem across all supported devices, let's just perform the CURBASE write unconditionally. Cc: Paul Menzel <pmenzel@molgen.mpg.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101790 Fixes: 75343a44c901 ("drm/i915: Drop useless posting reads from cursor commit") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170714155227.6089-1-ville.syrjala@linux.intel.com
2017-07-18drm/i915: Consistently use enum pipe for PCH transcodersMatthias Kaehlcke
The current code uses in some instances enum transcoder for PCH transcoders and enum pipe in others. This is error prone and clang raises warnings like this: drivers/gpu/drm/i915/intel_dp.c:3546:51: warning: implicit conversion from enumeration type 'enum pipe' to different enumeration type 'enum transcoder' [-Wenum-conversion] intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false); Consistently use the type enum pipe for PCH transcoders. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170717181403.57324-1-mka@chromium.org
2017-07-17drm/i915: Fix user ptr check size in eb_relocate_vma()Imre Deak
Fix the sizeof(ptr) vs. sizeof(*ptr) typo. Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170714151242.517-2-imre.deak@intel.com
2017-07-17drm/i915: Fix error checking/locking in perf/lookup_context()Imre Deak
1acfc104cdf8 missed to convert this one caller to be lockless. The side effect of that was that the error check in lookup_context() became incorrect. Convert now this caller too. Fixes: 1acfc104cdf ("drm/i915: Enable rcu-only context lookups") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170714151242.517-1-imre.deak@intel.com
2017-07-17drm/i915: Update DRIVER_DATE to 20170717Daniel Vetter
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-14drm/i915: Protect against deferred fbdev setupDaniel Vetter
We could probably hit this already with our current async fbdev init, but it's much easier to hit this with the new deferred fbdev setup that I'm working on polishing. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170706130023.28417-2-daniel.vetter@ffwll.ch
2017-07-14drm/i915/fbdev: Always forward hotplug eventsDaniel Vetter
With deferred fbdev setup we always need to forward hotplug events, even if fbdev isn't fully set up yet. Otherwise the deferred setup will neer happen. Originally this check was added in commit c45eb4fed12d278d3619f1904885bd0d7bcbf036 (tag: drm-intel-next-fixes-2016-08-05) Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jul 13 18:34:45 2016 +0100 drm/i915/fbdev: Check for the framebuffer before use But the specific case of the hotplug function blowing up was fixed in commit 50c3dc970a09b3b60422a58934cc27a413288bab Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jun 27 17:19:22 2014 +0200 drm/fb-helper: Fix hpd vs. initial config races Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170706130023.28417-1-daniel.vetter@ffwll.ch
2017-07-13drm/i915/skl+: unify cpp value in WM calculationKumar, Mahesh
use same cpp value in different phase of plane WM caluclation. Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170705143154.32132-7-mahesh1.kumar@intel.com
2017-07-13drm/i915/skl+: WM calculation don't require heightKumar, Mahesh
height of plane was require to swap width/height in case of 90/270 rotation. Now src structure contains already swapped values, So we don't have to calculate height of the plane. Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170705143154.32132-6-mahesh1.kumar@intel.com
2017-07-13drm/i915: Addition wrapper for fixed16.16 operationKumar, Mahesh
This patch introduce addition wrapper for fixed point 16.16 operations. Which will be used by later patches to avoid direct member variables access of fixed_16_16_t structure. add_fixed16 : takes 2 fixed_16_16_t variable & returns fixed_16_16_t add_fixed16_u32 : takes fixed_16_16_t & u32 variable & returns fixed_16_16_t Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170705143154.32132-5-mahesh1.kumar@intel.com
2017-07-13drm/i915: cleanup fixed-point wrappers namingKumar, Mahesh
This patch make naming of fixed-point wrappers consistent operation_<any_post_operation>_<1st operand>_<2nd operand> also shorten the name for fixed_16_16 to fixed16 s/u32_to_fixed_16_16/u32_to_fixed16 s/fixed_16_16_to_u32/fixed16_to_u32 s/fixed_16_16_to_u32_round_up/fixed16_to_u32_round_up s/min_fixed_16_16/min_fixed16 s/max_fixed_16_16/max_fixed16 s/mul_u32_fixed_16_16/mul_u32_fixed16 s/fixed_16_16_div/div_fixed16 Changes Since V1: - Split the patch in more logical patches (Maarten) Changes Since V2: - Rebase Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170705143154.32132-4-mahesh1.kumar@intel.com
2017-07-13drm/i915: Always perform internal fixed16 division in 64 bitsKumar, Mahesh
This patch combines fixed_16_16_div & fixed_16_16_div_u64 wrappers. And new fixed_16_16_div wrapper always performs division operation in u64 internally, to avoid any data loss which was happening in earlier version of wrapper. earlier wrapper was converting u32 to fixed16 in 32 bit so we were losing 16-MSB data. Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170705143154.32132-3-mahesh1.kumar@intel.com [mlankhorst: Fix typo in commit message.]
2017-07-13drm/i915: take-out common clamping code of fixed16 wrappersKumar, Mahesh
This patch creates a new function for clamping u64 to fixed16. And make use of this function in other fixed16 wrappers. Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170705143154.32132-2-mahesh1.kumar@intel.com
2017-07-11drm/i915/cnl: Add missing type case.Rodrigo Vivi
Paulo had noticed that inside cnl_ddi_vswing_program the case was handling voltage but with no indication of type where a missing type could also take us to that path. So my first attempt was to add a message to let clear who trigger that path. However DK had a better idea that is to handle the missed type sooner before it might take to that path. So this v2 here uses his approach. v2: Handle missed type sooner. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170710205852.28352-1-rodrigo.vivi@intel.com
2017-07-10Merge tag 'drm-for-v4.13' into drm-intel-next-queuedDaniel Vetter
Resync with the main drm-next pull request for 4.13. What we really need is to fully resync with pending drm-misc, but that's not yet possible due to the still ongoing merge window. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2017-07-10drm/i915/cnl: Add max allowed Cannonlake DC.Rodrigo Vivi
This is a follow-up after enabling DC states with commit: "drm/i915/DMC/CNL: Load DMC on CNL". Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499373908-26761-1-git-send-email-rodrigo.vivi@intel.com
2017-07-10drm/i915: Make DP-MST connector info workMaarten Lankhorst
Commit 9a148a96fc3a ("drm/i915/debugfs: add dp mst info") adds support for DP-MST to intel_connector_info, but forgot to remove the early return for DP-MST. Remove it, and print out MST connectors directly. Fixes: 9a148a96fc3a ("drm/i915/debugfs: add dp mst info") Cc: <stable@vger.kernel.org> # v4.11+ Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Libin Yang <libin.yang@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170626083349.24389-1-maarten.lankhorst@linux.intel.com Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
2017-07-07drm/i915/cnl: Get DDI clock based on PLLs.Rodrigo Vivi
PLLs are the source clocks for the DDIs so in order to determine the ddi clock we need to check the PLL configuration. v2: Mika pointed out that 24 was hardcoded while it should consider ref clock that can be either 24KHz or 19.2KHz on CNL. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499374321-31152-1-git-send-email-rodrigo.vivi@intel.com
2017-07-07drm/i915/cnl: Inherit RPS stuff from previous platforms.Rodrigo Vivi
Apparently no change on RPS stuff from previous platforms. v2: Merging to rps related patches in one and also adding missed cases. Cc: David Weinehall <david.weinehall@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499373673-25066-1-git-send-email-rodrigo.vivi@intel.com
2017-07-07drm/i915/cnl: Gen10 render context size.Rodrigo Vivi
No change on render context size is required for Gen10. So this patch doesn't change the default behaviour, but only avoid the missing_case message. Cc: Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Link: http://patchwork.freedesktop.org/patch/msgid/1499375184-5725-1-git-send-email-rodrigo.vivi@intel.com
2017-07-07drm/i915/cnl: Don't trust VBT's alternate pin for port D for now.Rodrigo Vivi
Cannon Lake's VBT that is currently available for B0 stepping states that port D uses alternate pin 3 messing up with the default pin-port mapping table. Using that information we cannot get HDMI working properly. So for now we don't relly on VBT for this information. Cc: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499375295-6454-1-git-send-email-rodrigo.vivi@intel.com
2017-07-07drm/i915: Fix the kernel panic when using aliasing ppgttChuanxiao Dong
The ppgtt should be get directly from i915_address_space *vm instead of vma->vm. v2: - add one more fix for bxt. (Chris) Fixes: 4a234c5fae16 ("drm/i915: pass the vma to insert_entries") Bugzilla:https://bugs.freedesktop.org/show_bug.cgi?id=101713 Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> v1 Cc: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499421059-18262-1-git-send-email-chuanxiao.dong@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-07-06drm/i915/cnl: Cannonlake color init.Rodrigo Vivi
Cannonlake has same color setup as Geminilake. Legacy color load luts doesn't work anymore on Cannonlake+. Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499374873-2454-1-git-send-email-rodrigo.vivi@intel.com
2017-07-06drm/i915/cnl: Add force wake for gen10+.Rodrigo Vivi
By spec there is no change on force wake registers for Cannonlake. Let's reuse gen9 one. v2: Adding missing case for the write part. (Tvrtko) v3: Rebase on recent tree. v4: Make it for gen9+ instead adding gen10 only. (by Joonas). Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499302831-17773-1-git-send-email-rodrigo.vivi@intel.com
2017-07-06drm/i915/cnl: Fix comment about AUX IO power well enable/disableImre Deak
The comments match an earlier version of the patch, fix them to match the current state. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-6-git-send-email-imre.deak@intel.com
2017-07-06drm/i915/gen9+: Don't remove secondary power well requestsImre Deak
So far in an attempt to make sure all power wells get disabled during display uninitialization the driver removed any secondary request bits (BIOS, KVMR, DEBUG) that were set for a given power well. The known source for these requests was DMC's request on power well 1 and the misc IO power well. Since DMC is inactive (DC states are disabled) at the point we disable these power wells, there shouldn't be any reason to leave them on. However there are two problems with the above assumption: Bspec requires that the misc IO power well stays enabled (without providing a reason) and there can be KVMR requests that we can't remove anyway (the KVMR request register is R/O). Atm, a KVMR request can trigger a timeout WARN when trying to disable power wells. To make the code aligned to Bspec and to get rid of the KVMR WARN, don't try to remove the secondary requests, only detect them and stop polling for the power well disabled state when any one is set. Also add a comment about the timeout values required by Bspec when enabling power wells and the fact that waiting for them to get disabled is not required by Bspec. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98564 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-5-git-send-email-imre.deak@intel.com
2017-07-06drm/i915/bxt, glk: Fix assert on conditions for DC9 enablingImre Deak
What we want to assert based on the conditions required by Bspec is that power well 2 is disabled, so no need to check for other power wells. In addition we can only check if the driver's request is removed, the actual state depends on whether the other request bits are set or not (BIOS, KVMR, DEBUG). So check only the driver's request bit. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-4-git-send-email-imre.deak@intel.com
2017-07-06drm/i915/skl: Don't disable misc IO power well during display uninitImre Deak
Bspec requires leaving the misc IO power well enabled during display uninit, so align the code accordingly. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-3-git-send-email-imre.deak@intel.com
2017-07-06drm/i915/gen9+: Add 10 us delay after power well 1/AUX IO pw disablingImre Deak
Bspec requires a 10 us delay after disabling power well 1 and - if not toggled on-demand - the AUX IO power wells during display uninit. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-2-git-send-email-imre.deak@intel.com
2017-07-06drm/i915: Only free the oldest stale context before allocatingChris Wilson
Currently, we move all unreferenced contexts to an RCU free list and then onto a worker for eventual reaping. To compensate against this growing into a long list with frequent allocations starving the system of available memory, before we allocate a new context we reap all the stale contexts. This puts all the cost of destroying the context into the next allocator, which is presumably more sensitive to syscall latency and unfair. We can limit the number of contexts being freed by the new allocator to both keep the list trimmed and to allow the allocator to be reasonably fast. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170705142634.18554-4-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2017-07-06drm/i915: Drop request retirement before reaping stale contextsChris Wilson
Before we create a new context, we try and reap all the stale contexts (i.e. those that are freed but waiting for a worker to come and return their allocations to the system). Before we do this, we retire all requests so that we clear any inflight no longer used contexts (who are only being kept alived by those inflght requests). However, any context that is finally unreferenced by this retirement is put onto an RCU list and not available for immediately reaping, we stall for no immediate benefit. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170705142634.18554-3-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
generated by cgit (git 2.34.1) at 2025-05-28 21:38:28 +0000