- 08 Oct, 2018 10 commits
-
-
Ville Syrjälä authored
Use a more familiar naming pattern for our variables in the sprite plane init function. v2: Drop the redundant 'plane' from plane_formats and num_planes_formats too v3: Rebase due to ->max_stride() and ->check_plane() changes Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20181005125817.22576-11-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
There's not much point in following the primary vs. sprite split for the SKL+ universal plane init code. The only difference is of our own doing in the form of the .check_plane(). Let's make a small exception for that little detail and otherwise share the same code to initialize all the universal planes. Eventually we should eliminate the mess around .check_plane() as well, but for now let's be happy with some code reduction. v2: Remember to set up plane->has_fbc Make skl_plane_has_ccs() static v3: Rebase due to NV12, rename some variables v4: Don't leave the color_encoding/range props behind v5: Rebase dur to blend properties, skl_plane_max_stride() and skl_plane_check() v6: Make skl_update_plane() static Signed-off-by: -
Ville Syrjälä authored
Pull the common plane+plane_state allocation into a small helper. Reduces the amount of boilerplate in the plane initialization functions. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181005125817.22576-9-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
No point in having each caller of intel_create_plane_state() initialize the scaler_id to -1. Instead just do it in intel_create_plane_state(). Previously we left scaler_id at 0 for pre-SKL platforms, but I can't see how initializing it to -1 always would cause any harm. Signed-off-by:
-
Ville Syrjälä authored
All SKL+ universal planes support the same set of formats (with the exception of NV12 which we don't expose yet). Make the format lists for primary and sprites the same. And make the format list const while at it. v2: Deal with the "planar" format list as well Signed-off-by:
-
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ä 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:
-
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:
-
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 4 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:
-
