- 08 Oct, 2018 5 commits
-
-
Ville Syrjälä authored
Plane scaling is not supported with specific pixel formats. Disallow plane scaling when such a format is used. Currently the only such pixel format we expose is C8, but in case we add more in the future let's make it easy to deal with them. v2: Redo due to plane_check() refactoring Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20181005125817.22576-6-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
All CNL universal planes support horizontal mirroring. Currently we expose the capability only for the primary plane. Expose it for the overlay planes as well. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181005125817.22576-5-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
enum i9xx_plane_id namespace is not valid for any sprite plane, so let's not even populate plane->i9xx_plane. Signed-off-by:
-
Ville Syrjälä authored
We're currently not providing the possible_crtcs mask to drm_universal_plane_init() for primary/cursor planes. While that does work on account of drm_crtc_init_with_planes() filling those up for us, it's inconsisten with what we're doing for sprite planes. Let's just always pass the possible_crtcs bitmask to drm_universal_plane_init(). This does assume that crtc->index == pipe. But we're already making that assumption elsewhere so it doesn't seem like a very big sin here. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Ville Syrjälä authored
plane_funcs can be cosnt. Make them so. v2: Rebase due to per-platforms plane_funcs Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
- 05 Oct, 2018 26 commits
-
-
José Roberto de Souza authored
ALPM is a requirement and we don't need to keep it's cached, what were done in commit 97c9de66 ("drm/i915/psr: Fix ALPM cap check for PSR2") but the alpm was not removed from i915_psr. Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
José Roberto de Souza authored
This WA also works fine for PSR2, triggering a selective update when possible. Acked-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
José Roberto de Souza authored
We are already handling all PSR2 errors, so we can drop this TODO. Reviewed-by:
-
José Roberto de Souza authored
ICL spec states that this bit is now reserved. Bspec: 7722 v2(Dhinakaran and Jani): - instead of remove bit in gen11 now only setting if if gen < 11 - changed commit title Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
-
José Roberto de Souza authored
Now both PSR and PSR2 have the same exit mask, so let's share then instead of have the same code 2 times. Reviewed-by:
-
Anusha Srivatsa authored
Add missing MODULE_FIRMWARE while loading DMC ICL. v2: Add Fixes tag. (Rodrigo) v3: Rebase by Rodrigo after commit 7fe78985 ("drm/i915/csr: restructure CSR firmware definition macros") v4: Rodrigo fixing his own mess on commit mentioning on v3 comment above. Fixes: 4445930f ("firmware/dmc/icl: load v1.07 on icelake.") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v2) Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181004223613.19938-1-rodrigo.vivi@intel.com
-
Rodrigo Vivi authored
No functional change. But just a minor change to keep up with Spec, since it has changed since commit c3cc39c5 ("drm/i915/icl: program mbus during pipe enable") The instructions previously said to program pipe's B credit = 24 / number of pipes, which is 8 for ICL. Now the spec gives us direct values independent of number of pipes. Let's keep in sync. Also just a reorder on fields to make easier to compare against spec's sequence: A -> BW -> B. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Mahesh Kumar <mahesh1.kumar@intel.com> Cc: Arthur J Runyan <arthur.j.runyan@intel.com> Signed-off-by:
Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181004151814.6054-1-rodrigo.vivi@intel.com
-
Lee, Shawn C authored
Amber Lake used the same gen graphics as Kaby Lake. Kernel driver should configure KBL's DDI buffer setting for AML ULX as well. So far, driver would load DDI translation table that used for KBL H/S platform and apply it on AML devices. But AML is belong to ULX series. This change will lead driver to apply KBL-Y's DDI table for AML devices to avoid unexpected eDP/DP signal quality issue. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jose Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Lee, Shawn C <shawn.c.lee@intel.com> Reviewed-by:
-
Lee, Shawn C authored
According to patch "drm/i915/aml: Introducing Amber Lake platform" (e3646724). Add a new marco for AML ULX GT2 devices. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jose Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
commit 'b9be7853 ("drm/i915/whl: Introducing Whiskey Lake platform")' introduced WHL by moving some of CFL IDs here and using the Spec information of "U43" for most of IDs what appeared to be GT3. However when propagating the change to Mesa, Lionel noticed that based on number of execution unities the classification here seems at least strange. So, let's move for now with the information we trust more: the number of EUs. So we are able to propagate this change across the stack without getting stuck forever. Reference: https://patchwork.freedesktop.org/patch/246695/ Fixes: b9be7853 ("drm/i915/whl: Introducing Whiskey Lake platform") Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: David Airlie <airlied@linux.ie> Signed-off-by:
-
Ville Syrjälä authored
Sprite enable on ILK-IVB may take two frames to complete when the hardware is in big FIFO mode (LP1+). That is not entirely great as it means the sprite enable may actually happen one frame after we've already signalled flip completion. At the very least crc checks may fail due to the sprite not yet being visible when we expect it. We already have code to deal with big FIFO mode when it comes to the sprite scaling on IVB (WaCxSRDisabledForSpriteScaling:ivb). Let's extend that workaround to kick in whenever the sprite is in the process of being enabled. Also ILK/SNB bspec has some notes to indicate that we should most likely also do the sprite scaling w/a on all three platforms, so let's do that as well. Pretty easy to reproduce on SNB/IVB. ILK has proved more elusive, but let's trust the spec and include it as well. v2: Make sure the pipe is active before the vblank wait Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Testcase: igt/kms_plane/pixel-format-pipe-*-planes Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107749Signed-off-by:
-
Maarten Lankhorst authored
These functions already have a pointer to the correct state, so use it instead of crtc->config. Changes since v1: - Move pll changes to the pll patch. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
Maarten Lankhorst authored
Fixing chv_set_phy_signal_level() still requires too many levels of indirection to pass crtc_state along, but chv_data_lane_soft_reset() already has a crtc_state we can use. Signed-off-by:
-
Maarten Lankhorst authored
We're already using crtc_state here and made sure no modeset is occurring by looking at conn_state->commit->hw_done, so there's no need to dereference crtc->config. Signed-off-by:
-
Maarten Lankhorst authored
fbdev init shouldn't race with userspace since it's called from intel_modeset_init, so it's safe to dereference crtc->state and assume nothing changed yet. At least not more harmful than crtc->config. Signed-off-by:
-
Maarten Lankhorst authored
Pass the full state to intel_ddi_clk_select, so we can pass it to icl_pll_to_ddi_pll_sel instead of passign the crtc and having to dereference crtc->config Signed-off-by:
-
Maarten Lankhorst authored
Instead of passing crtc and dereferencing crtc->config, pass the correct crtc_state and obtain the crtc pointer from there. Signed-off-by:
-
Maarten Lankhorst authored
Do not rely on crtc->config any more. Remove the assertion from ibx_pch_dpll_disable, because we the dpll state tracking should already handle this case correctly. Changes since v1: - Fixup accidental early return in intel_prepare_shared_dpll, oops! Changes since v2: - Don't use the freed crtc_state in intel_crtc_disable_noatomic() Signed-off-by:
-
Maarten Lankhorst authored
Instead of passing crtc and dereferencing crtc->config, passs the correct crtc_state and obtain the crtc pointer from there. Changes since v1: - Move vlv/chv changes and i9xx_set_pll_dividers changes from crtc_enable/disable patches to here. - Add commit message. Signed-off-by:
-
Maarten Lankhorst authored
Rename intel_crtc to crtc, and pass crtc_state instead of looking at crtc->config. Signed-off-by:
-
Maarten Lankhorst authored
Rename intel_crtc to crtc, and pass crtc_state so we don't have to dereference crtc->config. Signed-off-by:
-
Maarten Lankhorst authored
Pass the state instead of looking at crtc->config and rename intel_crtc to crtc. Signed-off-by:
-
Maarten Lankhorst authored
If we look at the correct state instead of crtc->config, we can nuke the force parameter, and we cleanup a few more users of crtc->config at the same time. Signed-off-by:
-
Maarten Lankhorst authored
One more user of crtc->config down. :) Changes since v1: - Constify crtc_state - int pipe -> enum pipe pipe - Move i9xx_set_pipeconf declaration to the other pipeconf declarations. Signed-off-by:
-
Chris Wilson authored
Earlier, we reasoned that having idled the gpu under mempressure, that would be a good time to trim our request slabs in order to perform the next request allocation. We have stopped performing the global operation on the device (no idling) and wish to make the allocation failure handling more local, so out with the global barrier that may take a long time. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181005080300.9908-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Before we can reset the seqno, we have to be sure the engines are idle. In debugfs/i915_drop_caches_set, we do wait_for_idle but allow ourselves to be interrupted. We should only proceed to reset the seqno then if we were not interrupted, and so also avoid overwriting the error status. References: https://bugs.freedesktop.org/show_bug.cgi?id=108133 Fixes: 6b048706 ("drm/i915: Forcibly flush unwanted requests in drop-caches") Signed-off-by:
-
- 04 Oct, 2018 6 commits
-
-
Ville Syrjälä authored
Print the plane hw state readout results in the common format we already use for pipes and encoders. Also print some clearer debug messages when we disable planes during the early phases of state readout/sanitization. v2: Rebase Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
When we decide that a plane is attached to the wrong pipe we try to turn off said plane. However we are passing around the crtc we think that the plane is supposed to be using rather than the crtc it is currently using. That doesn't work all that well because we may have to do vblank waits etc. and the other pipe might not even be enabled here. So let's pass the plane's current crtc to intel_plane_disable_noatomic() so that it can its job correctly. To do that semi-cleanly we also have to change the plane readout to record the plane's visibility into the bitmasks of the crtc where the plane is currently enabled rather than to the crtc we want to use for the plane. One caveat here is that our active_planes bitmask will get confused if both planes are enabled on the same pipe. Fortunately we can use plane_mask to reconstruct active_planes sufficiently since plane_mask still has the same meaning (is the plane visible?) during readout. We also have to do the same during the initial plane readout as the second plane could clear the active_planes bit the first plane had already set. v2: Rely on fixup_active_planes() to populate active_planes fully (Daniel) Add Daniel's proposed comment to better document why we do this Drop the redundant intel_set_plane_visible() call Cc: stable@vger.kernel.org # fcba862e8428 drm/i915: Have plane->get_hw_state() return the current pipe Cc: stable@vger.kernel.org Cc: Dennis <dennis.nezic@utoronto.ca> Cc: Daniel Vetter <daniel@ffwll.ch> Tested-by:Dennis <dennis.nezic@utoronto.ca> Tested-by:
Peter Nowee <peter.nowee@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105637 Fixes: b1e01595 ("drm/i915: Redo plane sanitation during readout") Signed-off-by:
-
Ville Syrjälä authored
Plane sanitation needs vblank interrupts (on account of CxSR disable). So let's restore vblank interrupts earlier. v2: Make it actually build v3: Add comment to explain why we need this (Daniel) Cc: stable@vger.kernel.org Cc: Dennis <dennis.nezic@utoronto.ca> Tested-by:
-
Ville Syrjälä authored
Always print out the information whether the port and sink can each do MST. And let's include the modparam in the debug output as well. Makes life a little less confusing when you don't have to wonder why MST isn't kicking in. This does cause a slight change in our behaviour towards the sink. Previously we only read the MSTM_CAP register after passing all the other checks. Now we will read that register regardless. Hopefully some crazy sink doesn't get confused by a simple register read. Signed-off-by:
-
Daniele Ceraolo Spurio authored
If the HW has not processed the db invalidation request yet, clearing the cookie can generate a db ring. We clear the cookie when we (re-)allocate the doorbell so no need to do it on destroy as well as no one is going to look at it while the doorbell is inactive v2: fix typo in patch title (Michal) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
GuC stores some data in there, which might be stale after a reset. We already reset the WQ head and tail, but more things are being moved to the descriptor with the interface updates. Instead of trying to track them one by one, always memset and init the descriptors from scratch after GuC is loaded. The code is also reorganized so that the above operations and the doorbell creation are grouped as "client enabling" v2: add proc_desc_fini for symmetry (Daniele), remove unneeded var init, add guc_is_alive() (Michal) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
- 03 Oct, 2018 3 commits
-
-
Chris Wilson authored
Inside the execlists submission tasklet, we often make the mistake of assuming that everything beneath the request is available for use. However, the submission and the request live on two separate timelines, and the request contents may be freed from an early retirement before we have had a chance to run the submission tasklet (think ksoftirqd). To safeguard ourselves against any mistakes, flush the tasklet before we unpin the context if execlists still has a reference to this context. v2: Pull hw_context->active tracking into schedule_in and schedule_out. References: 60367132 ("drm/i915: Avoid use-after-free of ctx in request tracepoints") Signed-off-by:
-
Chris Wilson authored
We do not need to continually clear our dedicated PTE for error capture as it will be updated and invalidated to the next object. Only at the end do we wish to be sure that the PTE doesn't point back to any buffer. Signed-off-by:
-
Chris Wilson authored
The final call to zlib_deflate(Z_FINISH) may require more output space to be allocated and so needs to re-invoked. Failure to do so in the current code leads to incomplete zlib streams (albeit intact due to the use of Z_SYNC_FLUSH) resulting in the occasional short object capture. v2: Check against overrunning our pre-allocated page array v3: Drop Z_SYNC_FLUSH entirely Testcase: igt/i915-error-capture.js Fixes: 0a97015d ("drm/i915: Compress GPU objects in error state") Signed-off-by:
-
