An error occurred fetching the project authors.
- 31 Jan, 2020 12 commits
-
-
Ville Syrjälä authored
Extract a small helper to compute the active pipes bitmask based on the old bitmask + the crtcs in the atomic state. I want to decouple the cdclk state entirely from the current global state so I want to track the active pipes also inside the (to be introduced) full cdclk state. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-17-ville.syrjala@linux.intel.comReviewed-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
Now that we have the more formal global state thing let's use if for memory bandwidth tracking. No real difference to the current private object usage since we already tried to avoid taking the single serializing lock needlessly. But since we're going to roll the global state out to more things probably a good idea to unify the approaches a bit. Signed-off-by:
-
Ville Syrjälä authored
Our current global state handling is pretty ad-hoc. Let's try to make it better by imitating the standard drm core private object approach. The reason why we don't want to directly use the private objects is locking; Each private object has its own lock so if we introduce any global private objects we get serialized by that single lock across all pipes. The global state apporoach instead uses a read/write lock type of approach where each individual crtc lock counts as a read lock, and grabbing all the crtc locks allows one write access. Signed-off-by:
-
Ville Syrjälä authored
Move intel_atomic_state_free() next to its counterpart. Signed-off-by:
-
Ville Syrjälä authored
Use the same structure to store the cdclk state in both intel_atomic_state and dev_priv. First step towards proper old vs. new cdclk states. Signed-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
Ville Syrjälä authored
Move all the old vs. new state shenanigans into intel_set_cdclk_{pre,post}_plane_update() so that the caller doesn't need to know any of it. Signed-off-by: -
Ville Syrjälä authored
I want to have a higher level cdclk state object so let's rename the current lower level thing to cdclk_config (because I lack imagination). Signed-off-by:
-
Ville Syrjälä authored
Move the min_cdclk[] and min_voltage_level[] arrays under the rest of the cdclk state. And while at it provide a simple helper (intel_cdclk_clear_state()) to clear the state during the ww_mutex backoff dance. Signed-off-by:
-
Ville Syrjälä authored
Move the initial setup of state->{cdclk,min_cdclk[],min_voltage_level[]} into intel_modeset_calc_cdclk(), and we'll move the counterparts into intel_cdclk_swap_state(). This encapsulates the cdclk state much better. Signed-off-by: -
Ville Syrjälä authored
The linetime watermarks really have very little in common with the plane watermarks. It looks to be cleaner to simply track them in the crtc_state and program them from the normal modeset/fastset paths. The only dark cloud comes from the fact that the register is still supposedly single buffered. So in theory it might still need some form of two stage programming. Note that even though HSW/BDWhave two stage programming we never computed any special intermediate values for the linetime watermarks, and on SKL+ we don't even have the two stage stuff plugged in since everything else is double buffered. So let's assume it's all fine and continue doing what we've been doing. Actually on HSW/BDW the value should not even change without a full modeset since it doesn't account for pfit downscaling. Thus only fastboot might be affected. But on SKL+ the pfit scaling factor is take into consideration so the value may change during any fastset. As a bonus we'll plug this thing into the state checker/dump now. v2: Rebase due to bigjoiner prep v2: Only compute ips linetime for IPS capable pipes. Bspec says the register values is ignored for other pipes, but in fact it can't even be written so the state checker becomes unhappy if we don't compute it as zero. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Jani Nikula authored
intel_dp_set_m_n() has a clear place in the DDI DP specific pre-enable hook. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128162850.8660-3-jani.nikula@intel.com
-
Jani Nikula authored
To allow better flexibility for encoder specific code, push intel_enable_pipe(), lpt_pch_enable() and intel_crtc_vblank_on() down to the encoders from hsw_crtc_enable(). There's slight duplication, but also more clarity with the reduced conditional statements. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by:
-
- 29 Jan, 2020 1 commit
-
-
Jani Nikula authored
The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(), intel_de_posting_read(), intel_de_read_fw(), and intel_de_write_fw(). No functional changes. Generated using the following semantic patch: @@ expression REG, OFFSET; @@ - I915_READ(REG) + intel_de_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - POSTING_READ(REG) + intel_de_posting_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE(REG, OFFSET) + intel_de_write(dev_priv, REG, OFFSET) @@ expression REG; @@ - I915_READ_FW(REG) + intel_de_read_fw(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE_FW(REG, OFFSET) + intel_de_write_fw(dev_priv, REG, OFFSET) Acked-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
- 27 Jan, 2020 3 commits
-
-
Ville Syrjälä authored
We've added more internal things that use modeset locks and thus we need to be prepared for intel_atomic_check() grabbing more locks than what our initial drm_modeset_lock_all_ctx() took. So we're missing the backoff handling here. Also drm_atomic_helper_duplicate_state() works against us by clearing state->acquire_ctx in anticipation of drm_atomic_helper_commit_duplicated_state() being used to commit the state. We could probably just reset acquire_ctx back, but instead let's just rewrite the whole thing without using either of those "helpers". There's also no need to add any connectors to the state here since we just want the new watermarks which don't depend on connectors. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Stanislav Lisovskiy authored
Despite that during hw readout we seem to have scalers assigned to pipes, then call atomic_setup_scalers, at the commit stage in skl_update_scaler there is a check, that if we have fb src and dest of same size, we stage freeing of that scaler. However we don't update pfit.enabled flag then, which makes the state inconsistent, which in turn triggers a WARN_ON in skl_pfit_enable, because we have pfit enabled, but no assigned scaler. To me this looks weird that we kind of do the decision to use or not use the scaler at skl_update_scaler stage but not in intel_atomic_setup_scalers, moreover not updating the whole state consistently. This fix is to not free the scaler if we have pfit.enabled flag set, so that the state is now consistent and the warnings are gone. v2: - Put pfit.enable check into crtc specific place (Ville Syrjälä) Bugzilla: https://gitlab.freedesktop.org/drm/intel/issues/577Signed-off-by:Tomi Sarvela <tomi.p.sarvela@intel.com> Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/display/intel_atomic.c:185: warning: Function parameter or member 'state' not described in 'intel_connector_needs_modeset' drivers/gpu/drm/i915/display/intel_atomic.c:185: warning: Function parameter or member 'connector' not described in 'intel_connector_needs_modeset' drivers/gpu/drm/i915/display/intel_fbc.c:1124: warning: Function parameter or member 'state' not described in 'intel_fbc_enable' drivers/gpu/drm/i915/display/intel_fbc.c:1124: warning: Excess function parameter 'crtc_state' description in 'intel_fbc_enable' drivers/gpu/drm/i915/display/intel_fbc.c:1124: warning: Excess function parameter 'plane_state' description in 'intel_fbc_enable' Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
- 25 Jan, 2020 1 commit
-
-
Wambui Karuga authored
This patch converts various instances of the printk based logging macros in drm/i915/display/intel_display.c to the new struct drm_device based logging macros. In some instances, this involves extracting the struct drm_i915_private device from various intel types and using it in the macros. v2: use correct variable name in assignment over variable type. Signed-off-by:
Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by:
-
- 24 Jan, 2020 2 commits
-
-
José Roberto de Souza authored
A recent change in BSpec allow us to change EXTLINE while transcoder is enabled so this allow us to change it even when doing the first fastset after taking over previous hardware state set by BIOS. BIOS don't enable PSR, so if sink supports PSR it will be enabled on the first fastset, so moving the EXTLINE compute and set to PSR flows allow us to simplfy a bunch of code. This will save a lot of time in all the IGT tests that uses CRC, as when PSR2 is enabled CRCs are not generated, so we switch to PSR1, so the previous code would compute dc3co_exitline=0 causing a full modeset that would shutdown pipe, enable and train link. v2: only programming EXTLINE when DC3CO is enabled BSpec: 49196 Cc: Imre Deak <imre.deak@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by:
Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
-
Manasi Navare authored
In the port sync mode, for the master crtc, the master_transcoder is INVALID. In that case since its value is -1, do not set the bit in the bitmask. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: d0eed154 ("drm/i915: Fix post-fastset modeset check for port sync") Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
-
- 22 Jan, 2020 6 commits
-
-
Ville Syrjälä authored
We've already pinned the vma and fence by the time we try to deal with implicit fencing. Properly unpin the vma and fence if the fence setup fails instead of just bailing straight out from .prepare_fb(). As can be expected drm_atomic_helper_prepare_planes() will not call .cleanup_fb() for the plane whose .prepare_fb() failed so we must do the cleanup ourself. v2: Rebase Signed-off-by:
-
Ville Syrjälä authored
intel_prepare_plane_fb() bails early if there is no fb (or rather no obj, which is the same thing). intel_cleanup_plane_fb() does not. This means the steps performed by intel_cleanup_plane_fb() aren't balanced with with what was done intel_prepare_plane_fb() if there is no fb for the plane. These hooks get called for every plane in the state regardless of whether they have an fb or not. Add a matching null obj check to intel_cleanup_plane_fb() to restore the balance. Note that intel_cleanup_plane_fb() has sufficient protections already in place that the imbalance doesn't cause any real problems. But having things be in balance seems nicer anyway, and might help avoid some surprises in the future. Signed-off-by:
-
Ville Syrjälä authored
Drop the redundant intel_ prefix from our atomic state variable. Signed-off-by:
-
Ville Syrjälä authored
Switch over to using explicit old/new planes states instead of digging the old state out via plane->state. The main issue is that plane->state will point to the uapi state which we generally don't even want to look at. Also it sets a bad example as using plane->state during commit_tail() would be a bug. Here we're still holding the modeset locks so it's actually safe, but best not give people bad ideas. Signed-off-by:
-
Ville Syrjälä authored
Let's do the intel_plane_copy_uapi_to_hw_state() before we bail out due to both old and new uapi.crtc being NULL. This will drop the reference to the old hw.fb for planes that are transitioning from being a slave plane to simply being disabled. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Pankaj Bharadiya authored
Drm specific drm_WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where intel_encoder struct pointer is available. The conversion was done automatically with below coccinelle semantic patch. @@ identifier func, T; @@ func(...) { ... struct intel_encoder *T = ...; <... ( -WARN( +drm_WARN(T->base.dev, ...) | -WARN_ON( +drm_WARN_ON(T->base.dev, ...) | -WARN_ONCE( +drm_WARN_ONCE(T->base.dev, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T->base.dev, ...) ) ...> } @@ identifier func, T; @@ func(struct intel_encoder *T,...) { <... ( -WARN( +drm_WARN(T->base.dev, ...) | -WARN_ON( +drm_WARN_ON(T->base.dev, ...) | -WARN_ONCE( +drm_WARN_ONCE(T->base.dev, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T->base.dev, ...) ) ...> } command: spatch --sp-file <script> --dir drivers/gpu/drm/i915/display \ --linux-spacing --in-place Signed-off-by:Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by:
-
- 21 Jan, 2020 2 commits
-
-
Ville Syrjälä authored
Replace the hand rolled intel_attached_dp() with the real thing. @@ identifier F !~ "^intel_attached_dp$"; expression C; @@ F(...) { <... - enc_to_intel_dp(intel_attached_encoder(C)) + intel_attached_dp(C) ...> } v2: Regenerated Signed-off-by:Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
-
Ville Syrjälä authored
It's easy to confuse the drm_connector->encoder (legacy state adjusted during modeset) and intel_connector->encoder (the statically (sans. MST) attached encoder of the connector). For the latter let's use intel_attached_encoder() consistently. @@ identifier F !~ "^intel_attached_encoder$"; struct intel_connector *C; expression E; @@ F(...) { <... ( C->encoder = E | - C->encoder + intel_attached_encoder(C) ) ...> } @@ identifier F !~ "^intel_attached_encoder$"; struct drm_connector *C; expression E; @@ F(...) { <... ( to_intel_connector(C)->encoder = E | - to_intel_connector(C)->encoder + intel_attached_encoder(to_intel_connector(C)) ) ...> } v2: Regenerated Signed-off-by:
-
- 20 Jan, 2020 5 commits
-
-
Ville Syrjälä authored
Let's not pollute the function scope with variables when they're only needed inside some loops. Signed-off-by:
-
Ville Syrjälä authored
sync_mode_slaves_mask is a bitmask so use PIPE_CONF_CHECK_X() for it so we get the mismatch printed in hex instead of decimal. Signed-off-by:
-
Ville Syrjälä authored
Let's use the pipe rather than the silly 'i' iterator from for_each_oldnew_intel_crtc_in_state() for indexing the ddb entries array. Maybe one day we can assume c99 and hide the 'i' entirely from sight. Signed-off-by:
-
Ville Syrjälä authored
Currently we don't call intel_crtc_prepare_cleared_state() for crtcs that are going to be entirely disabled (uapi.enable==false). That means such crtcs will leave stale junk lying around in their states and we have to sprinkle hw.enable checks all over before we can look at the states. Let's change that a bit so that we aways do the state clearing, even for fully disabled crtcs. Note that we still keep some parts of the old state (see intel_crtc_prepare_cleared_state() for the details) so probably can't trust things 100% when hw.enable==false. But at least there's less chance now that we end up looking at stale junk. Signed-off-by:
-
Ville Syrjälä authored
The post-fastset "does anyone still need a full modeset?" for port sync looks busted. The outer loop bails out of a full modeset is still needed by the current crtc, and then we skip forcing a full modeset on the related crtcs. That's totally the opposite of what we want. The MST path has the logic mostly the other way around so it looks correct. To fix the port sync case let's follow the MST logic for both. So, if the current crtc already needs a modeset we do nothing. otherwise we check if any of the related crtcs needs a modeset, and if so we force a full modeset for the current crtc. And while at let's change the else if to a plain if to so we don't have needless coupling between the MST and port sync checks. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Fixes: 05a8e451 ("drm/i915/display: Use external dependency loop for port sync") Signed-off-by:
-
- 15 Jan, 2020 1 commit
-
-
Ville Syrjälä authored
Instead of dealing with the presence/absence of the primary plane in the higher level pre/post plane update code let's move all that into the fbc code itself. Now the higher level code doesn't have to think about FBC details anymore. Signed-off-by:
-
- 14 Jan, 2020 1 commit
-
-
Ville Syrjälä authored
intel_prepare_plane_fb() will always pin plane_state->hw.fb whenever it is present. We copy that from the master plane to the slave plane, but we fail to copy the corresponding ggtt view. Thus when it comes time to pin the slave plane's fb we use some stale ggtt view left over from the last time the plane was used as a non-slave plane. If that previous use involved 90/270 degree rotation or remapping we'll try to shuffle the pages of the new fb around accordingingly. However the new fb may be backed by a bo with less pages than what the ggtt view rotation/remapped info requires, and so we we trip a GEM_BUG(). Steps to reproduce on icl: 1. plane 1: whatever plane 6: largish !NV12 fb + 90 degree rotation 2. plane 1: smallish NV12 fb plane 6: make invisible so it gets slaved to plane 1 3. GEM_BUG() Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/issues/951 Fixes: 1f594b20 ("drm/i915: Remove special case slave handling during hw programming, v3.") Signed-off-by:
-
- 13 Jan, 2020 2 commits
-
-
Ville Syrjälä authored
Lots of enc_to_foo(&encoder->base) around. Simplify by passing in the intel_encoder instead. @find@ identifier F =~ "^enc_to_.*"; identifier E; @@ F(struct drm_encoder *E) { ... } @@ identifier find.F; identifier find.E; @@ F( - struct drm_encoder *E + struct intel_encoder *encoder ) { <... - E + &encoder->base ...> } @@ identifier find.F; expression E; @@ - F(E) + F(to_intel_encoder(E)) @@ expression E; @@ - to_intel_encoder(&E->base) + E Signed-off-by: -
Ville Syrjälä authored
Life is usually easier when we pass around intel_ types instead of drm_ types. In this case it might not be, but I think being consistent is a good thing anyway. Also some of this might get cleaned up a bit more later as we keep propagating the intel_ types further. @find@ identifier F =~ "^intel_attached_.*"; identifier C; @@ F(struct drm_connector *C) { ... } @@ identifier find.F; identifier find.C; @@ F( - struct drm_connector *C + struct intel_connector *connector ) { <... - C + &connector->base ...> } @@ identifier find.F; expression C; @@ - F(C) + F(to_intel_connector(C)) @@ expression C; @@ - to_intel_connector(&C->base) + C Signed-off-by:Mika Kahola <mika.kahola@intel.com>
-
- 07 Jan, 2020 4 commits
-
-
José Roberto de Souza authored
This loop was added directly to intel_atomic_check() to be used by all other features that have external pipe dependencies, so using it and removing intel_atomic_check_synced_crtcs(). After this changes is_trans_port_sync_master() it not used anywhere, so removing it. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Dan Carpenter authored
There is a cut and paste bug so we return the wrong error code. Fixes: a603f5bd ("drm/i915/dp: Make sure all tiled connectors get added to the state with full modeset") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Dhinakaran Pandiyan authored
Detect the modifier corresponding to media compression to enable display decompression for YUV and xRGB packed formats. A new modifier is added so that the driver can distinguish between media and render compressed buffers. Unlike render decompression, plane 6 and plane 7 do not support media decompression. v2: Fix checkpatch warnings on code style (Lucas) From DK: Separate modifier array for planes that cannot decompress media (Ville) v3: Support planar formats v4: Switch plane order v5: - Use format block descriptors to get CCS subsampling calculation right everywhere. - Extend the plane state normal view array to accommodate 4 color planes. - Use helpers to convert between main and CCS planes. v6: Add missing packed YUV formats to the MC format list. (Yang) v7: Align UV planes to tile-row size. Cc: Nanley G Chery <nanley.g.chery@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Yang A Shi <yang.a.shi@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191231233756.18753-8-imre.deak@intel.com
-
Imre Deak authored
As intel_fb_plane_get_subsampling() returns the subsampling factor wrt. its main plane, for a CCS plane we need to apply both the main and the CCS plane's subsampling factor on the FB's dimensions to get the CCS plane's dimensions. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
