- 20 7月, 2017 4 次提交
-
-
由 Daniel 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: 73974893 ("drm/i915: Fix modeset handling during gpu reset, v5.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170719125502.25696-3-daniel.vetter@ffwll.ch
-
由 Daniel 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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170719125502.25696-2-daniel.vetter@ffwll.ch
-
由 Matthias Kaehlcke 提交于
Commit a2196033 ("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: a2196033 ("drm/i915: Consistently use enum pipe for PCH transcoders") Signed-off-by: NMatthias Kaehlcke <mka@chromium.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170719173928.186638-1-mka@chromium.org
-
由 Chris 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: NMatthew Auld <matthew.auld@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101627 Fixes: 5f09a9c8 ("drm/i915: Allow contexts to be unreferenced locklessly") Signed-off-by: NChris 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.ukTested-by: NMatthew Auld <matthew.auld@intel.com> Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
-
- 19 7月, 2017 8 次提交
-
-
由 Daniel 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: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170714224656.6431-3-daniel.vetter@ffwll.ch
-
由 Daniel 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 88be58be 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: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170714224656.6431-2-daniel.vetter@ffwll.ch
-
由 Daniel 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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170715093106.19873-1-daniel.vetter@ffwll.ch
-
由 Chris 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: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170718173028.31207-1-chris@chris-wilson.co.ukTested-by: NMatthew Auld <matthew.auld@intel.com> Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
-
由 Chris 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=101627Signed-off-by: NChris 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.ukReviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
-
由 Daniel 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: NMartin Peres <martin.peres@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170719100043.30851-1-daniel.vetter@ffwll.ch
-
由 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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: d555cb58 ("drm/i915/skl+: use linetime latency if ddb size is not available") Cc: "Mahesh Kumar" <mahesh1.kumar@intel.com> Reported-by: NDavid 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.comReviewed-by: NMahesh Kumar <mahesh1.kumar@intel.com>
-
由 Paul 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: NPaul Kocialkowski <paul.kocialkowski@linux.intel.com> Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: NManasi Navare <manasi.d.navare@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170718142536.2306-1-paul.kocialkowski@linux.intel.com
-
- 18 7月, 2017 2 次提交
-
-
由 Ville 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: 75343a44 ("drm/i915: Drop useless posting reads from cursor commit") Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Tested-by: NPaul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170714155227.6089-1-ville.syrjala@linux.intel.com
-
由 Matthias 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: NMatthias Kaehlcke <mka@chromium.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170717181403.57324-1-mka@chromium.org
-
- 17 7月, 2017 3 次提交
-
-
由 Imre Deak 提交于
Fix the sizeof(ptr) vs. sizeof(*ptr) typo. Fixes: 2889caa9 ("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: NImre Deak <imre.deak@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170714151242.517-2-imre.deak@intel.com
-
由 Imre Deak 提交于
1acfc104 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: 1acfc104 ("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: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170714151242.517-1-imre.deak@intel.com
-
由 Daniel Vetter 提交于
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 14 7月, 2017 2 次提交
-
-
由 Daniel 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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170706130023.28417-2-daniel.vetter@ffwll.ch
-
由 Daniel 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 c45eb4fe (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 50c3dc97 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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170706130023.28417-1-daniel.vetter@ffwll.ch
-
- 13 7月, 2017 6 次提交
-
-
由 Kumar, Mahesh 提交于
use same cpp value in different phase of plane WM caluclation. Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170705143154.32132-7-mahesh1.kumar@intel.com
-
由 Kumar, 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: NMahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170705143154.32132-6-mahesh1.kumar@intel.com
-
由 Kumar, 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: NMahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170705143154.32132-5-mahesh1.kumar@intel.com
-
由 Kumar, 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: NMahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170705143154.32132-4-mahesh1.kumar@intel.com
-
由 Kumar, 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: NMahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NMaarten 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.]
-
由 Kumar, 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: NMahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170705143154.32132-2-mahesh1.kumar@intel.com
-
- 11 7月, 2017 3 次提交
-
-
由 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: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170710205852.28352-1-rodrigo.vivi@intel.com
-
由 Daniel 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: NDaniel Vetter <daniel.vetter@intel.com>
-
由 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: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499373908-26761-1-git-send-email-rodrigo.vivi@intel.com
-
- 10 7月, 2017 1 次提交
-
-
由 Maarten Lankhorst 提交于
Commit 9a148a96 ("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: 9a148a96 ("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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170626083349.24389-1-maarten.lankhorst@linux.intel.comReviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
-
- 08 7月, 2017 4 次提交
-
-
由 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: NMika Kahola <mika.kahola@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499374321-31152-1-git-send-email-rodrigo.vivi@intel.com
-
由 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: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499373673-25066-1-git-send-email-rodrigo.vivi@intel.com
-
由 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: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Link: http://patchwork.freedesktop.org/patch/msgid/1499375184-5725-1-git-send-email-rodrigo.vivi@intel.com
-
由 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: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NClinton Taylor <clinton.a.taylor@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499375295-6454-1-git-send-email-rodrigo.vivi@intel.com
-
- 07 7月, 2017 4 次提交
-
-
由 Chuanxiao 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: 4a234c5f ("drm/i915: pass the vma to insert_entries") Bugzilla:https://bugs.freedesktop.org/show_bug.cgi?id=101713Signed-off-by: NChuanxiao 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.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 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: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NClinton Taylor <clinton.a.taylor@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499374873-2454-1-git-send-email-rodrigo.vivi@intel.com
-
由 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: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499302831-17773-1-git-send-email-rodrigo.vivi@intel.com
-
由 Paulo Zanoni 提交于
So don't forget to reserve its stolen memory bits. v2: Add ack and remove "TODO" from commit message. Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: NThomas Gleixner <tglx@linutronix.de> Link: http://patchwork.freedesktop.org/patch/msgid/1499302845-17856-1-git-send-email-rodrigo.vivi@intel.com
-
- 06 7月, 2017 3 次提交
-
-
由 Imre Deak 提交于
The comments match an earlier version of the patch, fix them to match the current state. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-6-git-send-email-imre.deak@intel.com
-
由 Imre 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=98564Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-5-git-send-email-imre.deak@intel.com
-
由 Imre 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: NImre Deak <imre.deak@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-4-git-send-email-imre.deak@intel.com
-