summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/display/intel_atomic_plane.c
AgeCommit message (Collapse)AuthorFilesLines
2022-04-18Merge drm/drm-next into drm-misc-nextPaul Cercueil1-45/+95
drm/drm-next has a build fix for the NewVision NV3052C panel (drivers/gpu/drm/panel/panel-newvision-nv3052c.c), which needs to be merged back to drm-misc-next, as it was failing to build there. Signed-off-by: Paul Cercueil <paul@crapouillou.net>
2022-04-07dma-buf: add enum dma_resv_usage v4Christian König1-1/+2
This change adds the dma_resv_usage enum and allows us to specify why a dma_resv object is queried for its containing fences. Additional to that a dma_resv_usage_rw() helper function is added to aid retrieving the fences for a read or write userspace submission. This is then deployed to the different query functions of the dma_resv object and all of their users. When the write paratermer was previously true we now use DMA_RESV_USAGE_WRITE and DMA_RESV_USAGE_READ otherwise. v2: add KERNEL/OTHER in separate patch v3: some kerneldoc suggestions by Daniel v4: some more kerneldoc suggestions by Daniel, fix missing cases lost in the rebase pointed out by Bas. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220407085946.744568-2-christian.koenig@amd.com
2022-03-21drm/i915: Pre-calculate plane relative data rateVille Syrjälä1-0/+64
Handle the plane relative data rate in exactly the same way as we already handle the real data rate. Ie. pre-calculate it during intel_plane_atomic_check_with_state(), and assign/clear it for the Y plane as needed. This should guarantee that the tracking is 100% consistent, and makes me have to think less when the same apporach is used by both types of data rate. We might even want to consider replacing the relative data rate with the real data rate entirely, but it's not clear if that will produce less optimal plane ddb allocations. So for now lets keep using the current approach. v2: Rebase due to async flip wm optimization Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220303191207.27931-4-ville.syrjala@linux.intel.com
2022-03-21drm/i915: Split plane data_rate into data_rate+data_rate_yVille Syrjälä1-19/+15
Split the currently combined plane data_rate into the proper Y vs. CbCr components. This matches how we now track the plane dbuf allocations, and thus will make the dbuf bandwidth calculations actually produce the correct numbers for each dbuf slice. Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220303191207.27931-3-ville.syrjala@linux.intel.com
2022-03-21drm/i915: Tweak plane ddb allocation trackingVille Syrjälä1-18/+14
Let's store the plane allocation in a manner which more closely matches how the hw operates. That is, we store the packed/CbCr ddb in one struct, and the Y ddb in another. Currently we're storing packed/Y in one struct, CbCr in the other. This also works pretty well for icl+ where the UV plane is the main plane and the Y plane is subservient to it. Although in this case we do not even use ddb_y as we do the ddb allocation in terms of hw planes. v2: Rebase Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220303191207.27931-2-ville.syrjala@linux.intel.com
2022-03-10drm/i915: Make the PIPESRC rect relative to the entire bigjoiner areaVille Syrjälä1-4/+3
When using bigjoiner it's useful to know the offset of each individual pipe in the whole set of joined pipes. Let's include that information in our PIPESRC rectangle. With this we can make the plane clipping code blissfully unaware of bigjoiner usage, as all we have to do is remove the pipe's offset from the final plane destination coordinates. v2: Use intel_bigjoiner_num_pipes() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-14-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2022-03-08drm/i915: Fix the async flip wm0/ddb optimizationVille Syrjälä1-4/+3
The current implementation of the async flip wm0/ddb optimization does not work at all. The biggest problem is that we skip the whole intel_pipe_update_{start,end}() dance and thus never actually complete the commit that is trying to do the wm/ddb change. To fix this we need to move the do_async_flip flag to the crtc state since we handle commits per-pipe, not per-plane. Also since all planes can now be included in the first/last "async flip" (which gets converted to a sync flip to do the wm/ddb mangling) we need to be more careful when checking if the plane state is async flip comptatible. Only planes doing the async flip should be checked and other planes are perfectly fine not adhereing to any async flip related limitations. However for subsequent commits which are actually going do the async flip in hardware we want to make sure no other planes are in the state. That should never happen assuming we did our job correctly, so we'll toss in a WARN to make sure we catch any bugs here. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: c3639f3be480 ("drm/i915: Use wm0 only during async flips for DG2") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220214105532.13049-4-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (cherry picked from commit 2e08437160d1e8f2cd3f0d56d59e74423602116e) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2022-03-04drm/i915: Start tracking PIPESRC as a drm_rectVille Syrjälä1-10/+5
Instead of just having the pipe_src_{w,h} let's use a full drm_rect for it. This will be particularly useful to astract away some bigjoiner details. v2: No hweight() stuff yet Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-11-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2022-03-03drm/i915: Fix the async flip wm0/ddb optimizationVille Syrjälä1-4/+3
The current implementation of the async flip wm0/ddb optimization does not work at all. The biggest problem is that we skip the whole intel_pipe_update_{start,end}() dance and thus never actually complete the commit that is trying to do the wm/ddb change. To fix this we need to move the do_async_flip flag to the crtc state since we handle commits per-pipe, not per-plane. Also since all planes can now be included in the first/last "async flip" (which gets converted to a sync flip to do the wm/ddb mangling) we need to be more careful when checking if the plane state is async flip comptatible. Only planes doing the async flip should be checked and other planes are perfectly fine not adhereing to any async flip related limitations. However for subsequent commits which are actually going do the async flip in hardware we want to make sure no other planes are in the state. That should never happen assuming we did our job correctly, so we'll toss in a WARN to make sure we catch any bugs here. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: c3639f3be480 ("drm/i915: Use wm0 only during async flips for DG2") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220214105532.13049-4-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-02-18drm/i915: Introduce intel_crtc_planes_update_arm()Ville Syrjälä1-6/+17
No reason the high level intel_update_crtc() needs to know that there is something magical about the commit order of planes between different platforms. So let's hide that detail even better. In order to keep to somewhat consistent naming between things we shall call this intel_crtc_planes_update_arm() to match the plane->update_arm() vfunc naming convention. And let's rename the noarm counterpart to intel_crtc_planes_update_noarm() to more clearly associate it with the plane->update_noarm() vfunc. v2: Change the naming convention a bit Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220216232806.6194-2-ville.syrjala@linux.intel.com
2022-02-16drm/i915: Introduce scaled_planes bitmaskVille Syrjälä1-0/+5
Add another plane bitmask, this time tracking which planes are scaled. This is going to be useful in ILK watermark computations, and skl+ pipe scaler assignments. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220211090629.15555-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-16drm/i915: Move intel_plane_atomic_calc_changes() & co. outVille Syrjälä1-0/+180
Exfiltrate intel_plane_atomic_calc_changes() and its friends from intel_display.c to intel_atomic_plane.c since that is a much better fit. While at it also nuke the official looking kernel docs for intel_wm_need_update() and flag it for eventual destruction so that people don't get any wrong ideas about using it in new code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220211090629.15555-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-15drm/i915: Change bigjoiner state tracking to use the pipe bitmaskVille Syrjälä1-2/+3
Get rid of the inflexible bigjoiner_linked_crtc pointer thing and just track things as a bitmask of pipes instead. We can also nuke the bigjoiner_slave boolean as the role of the pipe can be determined from its position in the bitmask. It might be possible to nuke the bigjoiner boolean as well if we make encoder.compute_config() do the bitmask assignment directly for the master pipe. But for now I left that alone so that encoer.compute_config() will just flag the state as needing bigjoiner, and the intel_atomic_check_bigjoiner() is still responsible for determining the bitmask. But that may have to change as the encoder may be in the best position to determine how exactly we should populate the bitmask. Most places that just looked at the single bigjoiner_linked_crtc now iterate over the whole bitmask, eliminating the singular slave pipe assumption. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220203183823.22890-11-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2022-02-15drm/i915: Introduce intel_crtc_is_bigjoiner_{slave,master}()Ville Syrjälä1-2/+2
Introduce helpers to query whether the crtc is the slave/master for bigjoiner. This decouples most places from the exact state layout we use to track this relationship, allowing us to change and extend it more easily. Performed with cocci: @@ expression S, E; @@ ( S->bigjoiner_slave = E; | - S->bigjoiner_slave + intel_crtc_is_bigjoiner_slave(S) ) @@ expression S, E; @@ ( - E && S->bigjoiner && !intel_crtc_is_bigjoiner_slave(S) + E && intel_crtc_is_bigjoiner_master(S) | - S->bigjoiner && !intel_crtc_is_bigjoiner_slave(S) + intel_crtc_is_bigjoiner_master(S) ) @@ expression S; @@ - (intel_crtc_is_bigjoiner_master(S)) + intel_crtc_is_bigjoiner_master(S) @@ expression S, E1, E2, E3; @@ - intel_crtc_is_bigjoiner_slave(S) ? E1 : S->bigjoiner ? E2 : E3 + intel_crtc_is_bigjoiner_slave(S) ? E1 : intel_crtc_is_bigjoiner_master(S) ? E2 : E3 @@ typedef bool; @@ + bool intel_crtc_is_bigjoiner_slave(const struct intel_crtc_state *crtc_state) + { + return crtc_state->bigjoiner_slave; + } + intel_master_crtc(...) {...} @@ typedef bool; @@ + bool intel_crtc_is_bigjoiner_master(const struct intel_crtc_state *crtc_state) + { + return crtc_state->bigjoiner && !crtc_state->bigjoiner_slave; + } + intel_master_crtc(...) {...} @@ typedef bool; identifier S; @@ - bool is_trans_port_sync_mode(const struct intel_crtc_state *S); + bool is_trans_port_sync_mode(const struct intel_crtc_state *state); + bool intel_crtc_is_bigjoiner_slave(const struct intel_crtc_state *crtc_state); + bool intel_crtc_is_bigjoiner_master(const struct intel_crtc_state *crtc_state); Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220203183823.22890-7-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2022-01-31Merge drm/drm-next into drm-intel-nextRodrigo Vivi1-2/+2
Catch-up with 5.17-rc2 and trying to align with drm-intel-gt-next for a possible topic branch for merging the split of i915_regs... Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2022-01-26drm/i915: Introduce do_async_flip flag to intel_plane_stateStanislav Lisovskiy1-1/+2
There might be various logical contructs when we might want to enable async flip, so lets calculate those and set this flag, so that there is no need in long conditions in other places. v2: - Set do_async_flip flag to False, if no async flip needed. Lets not rely that it will be 0-initialized, but set explicitly, so that the logic is clear as well. v3: - Clear do_async_flip in intel_plane_duplicate_state(Ville Syrjälä) - Check with do_async_flip also when calling intel_crtc_{enable,disable}_flip_done(Ville Syrjälä) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220124090653.14547-3-stanislav.lisovskiy@intel.com
2022-01-24drm/i915/plane: convert to drm device based logging and WARNJani Nikula1-2/+3
Prefer drm device based logging and WARN. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/9742b56ee0935a6b833f108ca8f72a29935853df.1642769982.git.jani.nikula@intel.com
2021-12-24Merge tag 'drm-intel-gt-next-2021-12-23' of ↵Dave Airlie1-2/+2
git://anongit.freedesktop.org/drm/drm-intel into drm-next Driver Changes: - Added bits of DG2 support around page table handling (Stuart Summers, Matthew Auld) - Fixed wakeref leak in PMU busyness during reset in GuC mode (Umesh Nerlige Ramappa) - Fixed debugfs access crash if GuC failed to load (John Harrison) - Bring back GuC error log to error capture, undoing accidental earlier breakage (Thomas Hellström) - Fixed memory leak in error capture caused by earlier refactoring (Thomas Hellström) - Exclude reserved stolen from driver use (Chris Wilson) - Add memory region sanity checking and optional full test (Chris Wilson) - Fixed buffer size truncation in TTM shmemfs backend (Robert Beckett) - Use correct lock and don't overwrite internal data structures when stealing GuC context ids (Matthew Brost) - Don't hog IRQs when destroying GuC contexts (John Harrison) - Make GuC to Host communication more robust (Matthew Brost) - Continuation of locking refactoring around VMA and backing store handling (Maarten Lankhorst) - Improve performance of reading GuC log from debugfs (John Harrison) - Log when GuC fails to reset an engine (John Harrison) - Speed up GuC/HuC firmware loading by requesting RP0 (Vinay Belgaumkar) - Further work on asynchronous VMA unbinding (Thomas Hellström, Christian König) - Refactor GuC/HuC firmware handling to prepare for future platforms (John Harrison) - Prepare for future different GuC/HuC firmware signing key sizes (Daniele Ceraolo Spurio, Michal Wajdeczko) - Add noreclaim annotations (Matthew Auld) - Remove racey GEM_BUG_ON between GPU reset and GuC communication handling (Matthew Brost) - Refactor i915->gt with to_gt(i915) to prepare for future platforms (Michał Winiarski, Andi Shyti) - Increase GuC log size for CONFIG_DEBUG_GEM (John Harrison) - Fixed engine busyness in selftests when in GuC mode (Umesh Nerlige Ramappa) - Make engine parking work with PREEMPT_RT (Sebastian Andrzej Siewior) - Replace X86_FEATURE_PAT with pat_enabled() (Lucas De Marchi) - Selftest for stealing of guc ids (Matthew Brost) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YcRvKO5cyPvIxVCi@tursulin-mobl2
2021-12-17drm/i915/display: Use to_gt() helperMichał Winiarski1-2/+2
Use to_gt() helper consistently throughout the codebase. Pure mechanical s/i915->gt/to_gt(i915). No functional changes. Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211214193346.21231-4-andi.shyti@linux.intel.com
2021-12-09Merge drm/drm-next into drm-intel-nextJani Nikula1-3/+4
Get the dependencies for merging drm-privacy-screen support. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-12-09drm/i915/trace: split out display trace to a separate fileJani Nikula1-2/+3
Add display/intel_display_trace.[ch] for defining display tracepoints. The main goal is to reduce cross-includes between gem and display. It would be possible split up tracing even further, but that would lead to more boilerplate. We end up having to include intel_crtc.h in a few places because it was pulled in implicitly via intel_de.h -> i915_trace.h -> intel_crtc.h, and that's no longer the case. There should be no changes to tracepoints. v3: - Rebase v2: - Define TRACE_INCLUDE_PATH relative to define_trace.h (Chris) - Remove useless comments (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7862ad764fbd0748d903c76bc632d3d277874e5b.1638961423.git.jani.nikula@intel.com
2021-12-02drm/i915/crtc: rename intel_get_crtc_for_pipe() to intel_crtc_for_pipe()Jani Nikula1-1/+1
The "get" in the name implies reference counting, remove it. This also makes the function conform to naming style. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6105d0ff44efac3c999af6382e4b0729e251f1e1.1638366969.git.jani.nikula@intel.com
2021-12-02Merge tag 'drm-intel-next-2021-11-30' of ↵Dave Airlie1-20/+69
git://anongit.freedesktop.org/drm/drm-intel into drm-next drm/i915 feature pull for v5.17: Features and functionality: - Implement per-lane DP drive settings for ICL+ (Ville) - Enable runtime pm autosuspend by default (Tilak Tangudu) - ADL-P DSI support (Vandita) - Add support for pipe C and D DMC firmware (Anusha) - Implement (near)atomic gamma LUT updates via vblank workers (Ville) - Split plane updates to noarm+arm phases (Ville) - Remove the CCS FB stride restrictions on ADL-P (Imre) - Add PSR selective fetch support for biplanar formats (Jouni) - Add support for display audio codec keepalive (Kai) - VRR platform support for display 11 (Manasi) Refactoring and cleanups: - FBC refactoring and cleanups preparing for multiple FBC instances (Ville) - PCH modeset refactoring, move to its own file (Ville) - Refactor and simplify handling of modifiers (Imre) - PXP cleanups (Ville) - Display header and include refactoring (Jani) - Some register macro cleanups (Ville) - Refactor DP HDMI DFP limit code (Ville) Fixes: - Disable DSB usage for now due to incorrect gamma LUT updates (Ville) - Check async flip state of every crtc and plane only once (José) - Fix DPT FB suspend/resume (Imre) - Fix black screen on reboot due to disabled DP++ TMDS output buffers (Ville) - Don't request GMBUS to generate irqs when called while irqs are off (Ville) - Fix type1 DVI DP dual mode adapter heuristics for modern platforms (Ville) - Fix fix integer overflow in 128b/132b data rate calculation (Jani) - Fix bigjoiner state readout (Ville) - Build fix for non-x86 (Siva) - PSR fixes (José, Jouni, Ville) - Disable ADL-P underrun recovery (José) - Fix DP link parameter usage before valid DPCD (Imre) - VRR vblank and frame counter fixes (Ville) - Fix fastsets on TypeC ports following a non-blocking modeset (Imre) - Compiler warning fixes (Nathan Chancellor) - Fix DSI HS mode commands (William Tseng) - Error return fixes (Dan Carpenter) - Update memory bandwidth calculations (Radhakrishna) - Implement WM0 cursor WA for DG2 (Stan) - Fix DSI Double pixelclock on read-back for dual-link panels (Hans de Goede) - HDMI 2.1 PCON FRL configuration fixes (Ankit) Merges: - DP link training delay helpers, via topic branch (Jani) - Backmerge drm-next (Jani) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87v909it0t.fsf@intel.com
2021-11-17drm/i915: use new cursor in intel_prepare_plane_fb v2Christian König1-3/+4
Simplifying the code a bit. v2: rebased Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211116102431.198905-5-christian.koenig@amd.com
2021-11-04drm/i915: Split update_plane() into update_noarm() + update_arm()Ville Syrjälä1-20/+68
The amount of plane registers we have to write has been steadily increasing, putting more pressure on the vblank evasion mechanism and forcing us to increase its time budget. Let's try to take some of the pressure off by splitting plane updates into two parts: 1) write all non-self arming plane registers, ie. the registers where the write actually does nothing until a separate arming register is also written which will cause the hardware to latch the new register values at the next start of vblank 2) write all self arming plane registers, ie. registers which always just latch at the next start of vblank, and registers which also arm other registers to do so Here we just provide the mechanism, but don't actually implement the split on any platform yet. so everything stays now in the _arm() hooks. Subsequently we can move a whole bunch of stuff into the _noarm() part, especially in more modern platforms where the number of registers we have to write is also the greatest. On older platforms this is less beneficial probably, but no real reason to deviate from a common behaviour. And let's sprinkle some TODOs around the areas that will need adapting. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018115030.3547-5-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2021-10-21drm/i915: Move intel_format_info_is_yuv_semiplanar() to intel_fb.cImre Deak1-0/+1
Move intel_format_info_is_yuv_semiplanar() to intel_fb.c . The number of planes for YUV semiplanar formats using CCS modifiers will change on future platforms. We can use the modifier descriptors to simplify getting the plane numbers for all modifiers, prepare for that here. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020195138.1841242-7-imre.deak@intel.com
2021-10-12drm/i915/display: move pin/unpin fb/plane code to a new file.Dave Airlie1-0/+1
This just moves this code out of the i915_display.c into a new standalone file. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211012043502.1377715-6-airlied@gmail.com
2021-10-12drm/i915/display: move plane prepare/cleanup to intel_atomic_plane.cDave Airlie1-0/+208
Start to refactor more stuff out of intel_display.c. These fit better in this file. This moves the rps boosting code as well as this is the only user of it. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211012043502.1377715-2-airlied@gmail.com
2021-07-08drm/i915/plane: add intel_plane_helper_add() helperJani Nikula1-1/+6
Add a small helper to keep intel_plane_helper_funcs static. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210518132426.7567-1-jani.nikula@intel.com
2021-05-07drm/i915/xelpd: First stab at DPT supportVille Syrjälä1-2/+5
Add support for DPT (display page table). DPT is a slightly peculiar two level page table scheme used for tiled scanout buffers (linear uses direct ggtt mapping still). The plane surface address will point at a page in the DPT which holds the PTEs for 512 actual pages. Thus we require 1/512 of the ggttt address space compared to a direct ggtt mapping. We create a new DPT address space for each framebuffer and track two vmas (one for the DPT, another for the ggtt). TODO: - Is the i915_address_space approaach sane? - Maybe don't map the whole DPT to write the PTEs? - Deal with remapping/rotation? Need to create a separate DPT for each remapped/rotated plane I guess. Or else we'd need to make the per-fb DPT large enough to support potentially several remapped/rotated vmas. How large should that be? Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Bommu Krishnaiah <krishnaiah.bommu@intel.com> Cc: Wilson Chris P <Chris.P.Wilson@intel.com> Cc: Tang CQ <cq.tang@intel.com> Cc: Auld Matthew <matthew.auld@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Wilson Chris P <Chris.P.Wilson@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-5-imre.deak@intel.com
2021-04-19drm/i915: Reuse intel_adjusted_rate() for pfit pixel rate adjustmentVille Syrjälä1-3/+3
Replace the hand rolled pfit downscale calculations with intel_adjusted_rate(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210330184254.6290-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-04-19drm/i915: Extract intel_adjusted_rate()Ville Syrjälä1-8/+28
Extract a small helper to calculate the downscaling adjusted pixel rate/data rate/etc. v2: Drop the plane visibility check and add a comment explaining why Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210401154043.19466-1-ville.syrjala@linux.intel.com
2021-03-22drm/i915: Fix enabled_planes bitmaskVille Syrjälä1-2/+3
The enabled_planes bitmask was supposed to track logically enabled planes (ie. fb!=NULL and crtc!=NULL), but instead we end up putting even disabled planes into the bitmask since intel_plane_atomic_check_with_state() only takes the early exit if the plane was disabled and stays disabled. I think I misread the early said codepath to exit whenever the plane is logically disabled, which is not true. So let's fix this up properly and set the bit only when the plane actually is logically enabled. Cc: Manasi Navare <manasi.d.navare@intel.com> Fixes: ee42ec19ca2e ("drm/i915: Track logically enabled planes for hw state") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210305153610.12177-2-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2021-01-19drm/i915: Reuse the async_flip() hook for the async flip disable w/aVille Syrjälä1-1/+1
On some platforms we need to trigger an extra async flip with the async flip bit disabled, and then wait for the next vblank until the async flip bit off state will actually latch. Currently the w/a is just open coded for skl+ universal planes. Instead of doing that lets reuse the .async_flip() hook for this purpose since it needs to write the exact same set of registers. In order to do this we'll just have the caller pass in the state of the async flip bit explicitly. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-8-ville.syrjala@linux.intel.com Reviewed-by: Karthik B S <karthik.b.s@intel.com>
2020-12-04drm/i915: Track logically enabled planes for hw stateVille Syrjälä1-0/+3
Currently crtc_state->uapi.plane_mask only tracks logically enabled planes on the uapi level. For bigjoiner purposes we want to do the same for the hw state. Let's follow the pattern established by active_planes & co. here. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201124201156.17095-1-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2020-11-18drm/i915: Add bigjoiner aware plane clipping checksMaarten Lankhorst1-0/+60
We need to look at hw.fb for the framebuffer, and add the translation for the slave_plane_state. With these changes we set the correct rectangle on the bigjoiner slave, and don't set incorrect src/dst/visibility on the slave plane. v2: * Manual rebase (Manasi) v3: * hw.rotation instead of uapi.rotation (Ville) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-11-manasi.d.navare@intel.com
2020-11-18drm/i915: Get the uapi state from the correct plane when bigjoiner is usedVille Syrjälä1-18/+41
When using bigjoiner userspace is only controlling the "master" plane, so use its uapi state for the "slave" plane as well. hw.crtc needs a bit of magic since we don't want to copy that from the uapi state (as it points to the wrong pipe for the "slave " plane). Instead we pass the right crtc in explicitly but only assign it when the uapi state indicates the plane to be logically enabled (ie. uapi.crtc != NULL). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-10-manasi.d.navare@intel.com
2020-11-18drm/i915: Copy the plane hw state directly for Y planesVille Syrjälä1-0/+12
When doing the plane state copy from the UV plane to the Y plane let's just copy the hw state directly instead of using the original uapi state. The UV plane has already had its uapi state copied into its hw state, so this extra detour via the uapi state for the Y plane is pointless. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-2-manasi.d.navare@intel.com
2020-10-21drm/i915: Enable scaling filter for plane and CRTCPankaj Bharadiya1-0/+1
GEN >= 10 hardware supports the programmable scaler filter. Attach scaling filter property for CRTC and plane for GEN >= 10 hardwares and program scaler filter based on the selected filter type. changes since v3: * None changes since v2: * Use updated functions * Add ps_ctrl var to contain the full PS_CTRL register value (Ville) * Duplicate the scaling filter in crtc and plane hw state (Ville) changes since v1: * None Changes since RFC: * Enable properties for GEN >= 10 platforms (Ville) * Do not round off the crtc co-ordinate (Danial Stone, Ville) * Add new functions to handle scaling filter setup (Ville) * Remove coefficient set 0 hardcoding. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201020161427.6941-5-pankaj.laxminarayan.bharadiya@intel.com
2020-09-28drm/i915: Add dedicated plane hook for async flip caseKarthik B S1-1/+5
This hook is added to avoid writing other plane registers in case of async flips, so that we do not write the double buffered registers during async surface address update. v7: -Plane ctl needs bits from skl_plane_ctl_crtc as well. (Ville) -Add a vfunc for skl_program_async_surface_address and call it from intel_update_plane. (Ville) v8: -Rebased. v9: -Use if-else instead of return in intel_update_plane(). (Ville) -Rename 'program_async_surface_address' to 'async_flip'. (Ville) v10: -Check if async_flip hook is present before calling it. Otherwise it will OOPS during legacy cursor updates. (Ville) v11: -Rename skl_program_async_surface_address(). (Ville) Signed-off-by: Karthik B S <karthik.b.s@intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200921110210.21182-6-karthik.b.s@intel.com
2020-04-21drm/i915/display/atomic_plane: Prefer drm_WARN_ON over WARN_ONPankaj Bharadiya1-2/+2
struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN_ON over WARN_ON. Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200406112800.23762-3-pankaj.laxminarayan.bharadiya@intel.com
2020-03-20drm/i915: Fix crtc nv12 etc. plane bitmasks for DPMS offVille Syrjälä1-6/+15
We only consider crtc_state->enable when initially calculating plane visibility. Later on we try to override the plane's state to invisible if the crtc is in DPMS off state (crtc_state->active==false). Unfortunately the code doing that only updates the plane_state.visible flag and the crtc_state.active_planes bimask, but forgets to update some of the other plane bitmasks stored in the crtc_state. Namely crtc_state.nv12_planes is left set up based on the original visibility check which makes icl_check_nv12_planes() pick a slave plane for the flagged plane in the bitmask. Later on we hit the watermark code which sees a plane with a slave assigned and it then makes the logical assumption that the master plane must itself be visible. Since the master's plane_state.visible flag was already cleared we get a WARN. Fix the problem by clearing all the plane bitmasks for DPMS off. This is more or less the wrong approach and instead we should calculate all the plane related state purely based crtc_state->enable (to guarantee that the subsequent DPMS on can't fail). However in the past we definitely had some roadblocks to making that happen. Not sure how many are left these days, but let's stick to the current approach since it's a much simpler fix to the immediate problem (the WARN). v2: Keep the visible=false, it's important (Rodrigo) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200318174515.31637-1-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-03-02drm/i915: Use intel_plane_data_rate for min_cdclk calculationStanislav Lisovskiy1-1/+23
There seems to be a bit of confusing redundancy in a way, how plane data rate/min cdclk are calculated. In fact both min cdclk, pixel rate and plane data rate are all part of the same formula as per BSpec. However currently we have intel_plane_data_rate, which is used to calculate plane data rate and which is also used in bandwidth calculations. However for calculating min_cdclk we have another piece of code, doing almost same calculation, but a bit differently and in a different place. However as both are actually part of same formula, probably would be wise to use plane data rate calculations as a basis anyway, thus avoiding code duplication and possible bugs related to this. Another thing is that I've noticed that during min_cdclk calculations we account for plane scaling, while for plane data rate, we don't. crtc->pixel_rate seems to account only for pipe ratio, however it is clearly stated in BSpec that plane data rate also need to account plane ratio as well. So what this commit does is: - Adds a plane ratio calculation to intel_plane_data_rate - Removes redundant calculations from skl_plane_min_cdclk which is used for gen9+ and now uses intel_plane_data_rate as a basis from there as well. v2: - Don't use 64 division if not needed(Ville Syrjälä) - Now use intel_plane_pixel_rate as a basis for calculations both at intel_plane_data_rate and skl_plane_min_cdclk(Ville Syrjälä) v3: - Again fix the division macro - Fix plane_pixel_rate to pixel_rate at intel_plane_pixel_rate callsites v4: - Renamed skl_plane_ratio function back(Ville Syrjälä) v5: - Don't precalculate plane pixel rate for invisible plane, check for visibility first, as in invisible case it will have dst_w and dst_h equal to zero, causing divide error. v6: - Removed useless warn in intel_plane_pixel_rate(Ville Syrjälä) - Fixed alignment in intel_plane_data_rate(Ville Syrjälä) - Changed pixel_rate type to be unsigned int in skl_plane_min_cdclk(Ville Syrjälä) Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227150935.2107-1-stanislav.lisovskiy@intel.com
2020-02-04drm/i915/display: Fix NULL-crtc deref in calc_min_cdclk()Chris Wilson1-4/+5
[ 23.419442] BUG: KASAN: null-ptr-deref in intel_plane_calc_min_cdclk+0x82/0x440 [i915] [ 23.419527] Read of size 4 at addr 00000000000000f8 by task insmod/735 [ 23.419578] [ 23.419644] CPU: 2 PID: 735 Comm: insmod Not tainted 5.5.0+ #114 [ 23.419716] Hardware name: ��������������������������������� ���������������������������������/���������������������������������, BIOS RYBDWi35.86A.0246.2 [ 23.419793] Call Trace: [ 23.419864] dump_stack+0xef/0x16e [ 23.419927] __kasan_report.cold+0x60/0x90 [ 23.420157] ? intel_plane_calc_min_cdclk+0x82/0x440 [i915] [ 23.420397] intel_plane_calc_min_cdclk+0x82/0x440 [i915] [ 23.420630] intel_atomic_check+0x455f/0x65a0 [i915] [ 23.420708] ? mark_held_locks+0x90/0x90 [ 23.420929] ? intel_crtc_duplicate_state+0x2e/0x1b0 [i915] [ 23.421172] ? intel_plane_duplicate_state+0x2d/0xc0 [i915] [ 23.421239] ? __drm_dbg+0xa4/0x120 [ 23.421303] ? __kasan_kmalloc.constprop.0+0xc2/0xd0 [ 23.421355] ? __kmalloc_track_caller+0x23a/0x320 [ 23.421602] ? intel_calc_active_pipes+0x1c0/0x1c0 [i915] [ 23.421852] sanitize_watermarks+0x220/0x510 [i915] [ 23.422092] ? intel_atomic_check+0x65a0/0x65a0 [i915] [ 23.422164] ? drm_modeset_unlock_all+0x88/0x130 [ 23.422402] intel_modeset_init+0x1b76/0x3c90 [i915] [ 23.422647] ? intel_finish_reset+0x2d0/0x2d0 [i915] [ 23.422851] ? intel_irq_install+0x12c/0x210 [i915] [ 23.423076] i915_driver_probe+0x13e7/0x2930 [i915] v2: No crtc is implied by an invisible plane, so the extra !crtc check is redundant. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200203133824.198872-1-chris@chris-wilson.co.uk
2020-01-31drm/i915: Convert cdclk to global stateVille Syrjälä1-25/+44
Let's convert cdclk_state to be a proper global state. That allows us to use the regular atomic old vs. new state accessor, hopefully making the code less confusing. We do have to deal with a few more error cases in case the cdclk state duplication fails. But so be it. v2: Fix new plane min_cdclk vs. old crtc min_cdclk check Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200121140353.25997-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-01-31drm/i915: Extract intel_cdclk_stateVille Syrjälä1-2/+4
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-10-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-01-23drm/i915/atomic: use struct drm_device logging macrosWambui Karuga1-4/+5
Convert to the new struct drm_based logging macros to replace the printk based macros in i915/display/intel_atomic_plane.c. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200121134559.17355-2-wambui.karugax@gmail.com
2020-01-22drm/i915: Clear old hw.fb & co. from slave plane's stateVille Syrjälä1-4/+2
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200110183228.8199-2-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2019-12-23drm/i915: Make sure CCS YUV semiplanar format checks workImre Deak1-1/+1
For CCS formats, the current DRM core check for YUV semiplanar formats doesn't work; use an i915 specific function for that. v2: Fix checkpatch warnings. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191221120543.22816-11-imre.deak@intel.com
2019-12-18drm/i915: Introduce intel_plane_state_reset()Ville Syrjälä1-2/+13
For the sake of symmetry with the crtc stuff let's add a helper to reset the plane state to sane default values. For the moment this only gets caller from the plane init. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191107142417.11107-5-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-19 09:30:25 +0000