summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/display/intel_display.c
AgeCommit message (Collapse)AuthorFilesLines
2022-03-08drm/i915: Fix the async flip wm0/ddb optimizationVille Syrjälä1-16/+22
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-08drm/i915: Check async flip capability early onVille Syrjälä1-7/+72
Since the async flip state check is done very late and thus it can see potentially all the planes in the state (due to the wm/ddb optimization) we need to move the "can the requested plane do async flips at all?" check much earlier. For this purpose we introduce intel_async_flip_check_uapi() that gets called early during the atomic check. And for good measure we'll throw in a couple of basic checks: - is the crtc active? - was a modeset flagged? - is+was the plane enabled? Though atm all of those should be guaranteed by the fact that the async flip can only be requested through the legacy page flip ioctl. 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-3-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (cherry picked from commit b0b2bed2a1305c8f977c6b7d5fa162773693a212) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2022-03-08drm/i915: Avoid negative shift due to bigjoiner_pipes==0Ville Syrjälä1-1/+4
bigjoiner_pipes==0 leads bigjoiner_master_pipe() to do BIT(ffs(0)-1) which is undefined behaviour. The code should actually still work fine since the only place we provoke that is intel_crtc_bigjoiner_slave_pipes() and it'll bitwise AND the result with 0, so doesn't really matter what we get out of bigjoiner_master_pipe(). But best not provoke undefined behaviour anyway. Reported-by: kernel test robot <oliver.sang@intel.com> Fixes: a6e7a006f5d5 ("drm/i915: Change bigjoiner state tracking to use the pipe bitmask") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-2-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> (cherry picked from commit cccc71b552a1040ad3d738d7ec95570801fb0bf6) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2022-02-23Merge tag 'drm-intel-gt-next-2022-02-17' of ↵Rodrigo Vivi1-1/+1
git://anongit.freedesktop.org/drm/drm-intel into drm-intel-next UAPI Changes: - Weak parallel submission support for execlists Minimal implementation of the parallel submission support for execlists backend that was previously only implemented for GuC. Support one sibling non-virtual engine. Core Changes: - Two backmerges of drm/drm-next for header file renames/changes and i915_regs reorganization Driver Changes: - Add new DG2 subplatform: DG2-G12 (Matt R) - Add new DG2 workarounds (Matt R, Ram, Bruce) - Handle pre-programmed WOPCM registers for DG2+ (Daniele) - Update guc shim control programming on XeHP SDV+ (Daniele) - Add RPL-S C0/D0 stepping information (Anusha) - Improve GuC ADS initialization to work on ARM64 on dGFX (Lucas) - Fix KMD and GuC race on accessing PMU busyness (Umesh) - Use PM timestamp instead of RING TIMESTAMP for reference in PMU with GuC (Umesh) - Report error on invalid reset notification from GuC (John) - Avoid WARN splat by holding RPM wakelock during PXP unbind (Juston) - Fixes to parallel submission implementation (Matt B.) - Improve GuC loading status check/error reports (John) - Tweak TTM LRU priority hint selection (Matt A.) - Align the plane_vma to min_page_size of stolen mem (Ram) - Introduce vma resources and implement async unbinding (Thomas) - Use struct vma_resource instead of struct vma_snapshot (Thomas) - Return some TTM accel move errors instead of trying memcpy move (Thomas) - Fix a race between vma / object destruction and unbinding (Thomas) - Remove short-term pins from execbuf (Maarten) - Update to GuC version 69.0.3 (John, Michal Wa.) - Improvements to GT reset paths in GuC backend (Matt B.) - Use shrinker_release_pages instead of writeback in shmem object hooks (Matt A., Tvrtko) - Use trylock instead of blocking lock when freeing GEM objects (Maarten) - Allocate intel_engine_coredump_alloc with ALLOW_FAIL (Matt B.) - Fixes to object unmapping and purging (Matt A) - Check for wedged device in GuC backend (John) - Avoid lockdep splat by locking dpt_obj around set_cache_level (Maarten) - Allow dead vm to unbind vma's without lock (Maarten) - s/engine->i915/i915/ for DG2 engine workarounds (Matt R) - Use to_gt() helper for GGTT accesses (Michal Wi.) - Selftest improvements (Matt B., Thomas, Ram) - Coding style and compiler warning fixes (Matt B., Jasmine, Andi, Colin, Gustavo, Dan) From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/Yg4i2aCZvvee5Eai@jlahtine-mobl.ger.corp.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [Fixed conflicts while applying, using the fixups/drm-intel-gt-next.patch from drm-rerere's 1f2b1742abdd ("2022y-02m-23d-16h-07m-57s UTC: drm-tip rerere cache update")]
2022-02-23drm/i915: Properly clear crtc state when disabling it fully, againVille Syrjälä1-3/+5
Currently we just leave the old gunk lying around in the crtc state when userspace asks us to fully disable the crtc. That doesn't match what the state would be had we never even enabled the crtc in the first place. So let's make this consistent and call intel_crtc_prepare_cleared_state() for disabled crtcs as well (excluding bigjoiner slaves of course which have had their state copied from the master). I actually already did this once in commit fff13e63a141 ("drm/i915: Clear most of crtc state when disabling the crtc") but then commit 19f65a3dbf75 ("drm/i915: Try to make bigjoiner work in atomic check") undid it all :( Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220217103221.10405-5-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2022-02-23drm/i915: Remove odd any_ms=true assignmentVille Syrjälä1-3/+1
For some reason we're flagging that we need to run through the full modeset calculations (any_ms==true -> do cdclk/etc. checks) if any crtc got initially flagged for a modeset and is not enabled via the uapi. No idea why this is here since later on (after all fastset handling) we do full run through the crtcs and flag any_ms if anything still needs a full modeset. So let's just throw out this early weirdo. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220217103221.10405-4-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2022-02-21drm/i915/reg: split out vlv_dsi_regs.h and vlv_dsi_pll_regs.hJani Nikula1-1/+2
The VLV (including CHV, BXT, and GLK) DSI registers have fairly isolated usage. Split the register macros to separated files. Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220217224023.3994777-3-jani.nikula@intel.com
2022-02-18drm/i915/dg2: Enable 5th portMatt Roper1-0/+1
DG2 supports a 5th display output which the hardware refers to as "TC1," even though it isn't a Type-C output. This behaves similarly to the TC1 on past platforms with just a couple minor differences: * DG2's TC1 bit in SDEISR is at bit 25 rather than 24 as it is on ICP/TGP/ADP. * DG2 doesn't need the hpd inversion setting that we had to use on DG1 v2: intel_ddi_init(dev_priv, PORT_TC1); [Matt] Cc: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218010328.183423-3-lucas.demarchi@intel.com
2022-02-18drm/i915: Drop pointless i830 PIPECONF readVille Syrjälä1-4/+2
Reading the PIPECONF enable bit out from the hardware in i9xx_set_pipeconf() on i830 is pointless as the bit should always be set since we keep both pipes constantly running on i830. Drop the pointless read and just always keep the bit set. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220202111616.1579-4-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2022-02-18drm/i915: Move PIPE_CHICKEN RMW out from the vblank evade critical sectionVille Syrjälä1-3/+5
We don't want any RMWs in the part of the commit that happens under vblank evasion. Eventually we want to use the DSB to handle that and it can't read registers at all. Also reads are just slowing us down needlessly. Let's move the whole PIPE_CHICKEN stuff out from the critical section since we don't have anything there that needs to be syncrhonized with other plane/pipe registers. If we ever need to add such things then we have to move it back, but without doing any reads. TODO: should look into eliminating the RMW anyway... Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220202111616.1579-1-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2022-02-18drm/i915/display/tgl+: Implement new PLL programming stepJosé Roberto de Souza1-0/+1
A new programming step was added to combo and TC PLL sequences. If override_AFC_startup is set in VBT, driver should overwrite AFC_startup value to 0x0 or 0x7 in PLL's div0 register. The current understating is that only TGL needs this and all other display 12 and newer platforms will have a older VBT or a newer VBT with override_AFC_startup set to 0 but in any case there is a drm_warn_on_once() to let us know if this is not true. v2: - specification updated, now AFC can be override to 0x0 or 0x7 - not using a union for div0 (Imre) - following previous wrong vbt naming: bits instead of bytes (Imre) BSpec: 49204 BSpec: 20122 BSpec: 49968 BSpec: 71360 Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220216134059.25348-1-jose.souza@intel.com
2022-02-18drm/i915: Introduce intel_crtc_planes_update_arm()Ville Syrjälä1-6/+2
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: Move intel_plane_atomic_calc_changes() & co. outVille Syrjälä1-188/+0
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-86/+203
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: Return both master and slave pipes from enabled_bigjoiner_pipes()Ville Syrjälä1-11/+14
Return both the master and slave pipe bitmasks from enabled_bigjoiner_pipes(). We'll have use for both during readout soon. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220203183823.22890-10-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2022-02-15drm/i915: Use for_each_intel_crtc_in_pipe_mask() moreVille Syrjälä1-8/+4
Convert a few hand roller for_each_intel_crtc_in_pipe_mask() to the real thing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220203183823.22890-9-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-20/+31
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-02-11drm/i915: Nuke some dead codeVille Syrjälä1-17/+1
Remove all the dead code from icl_ddi_bigjoiner_pre_enable(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220203183823.22890-6-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2022-02-11drm/i915: Clean up the bigjoiner state copy logicVille Syrjälä1-62/+108
Currently the bigjoiner state copy logic is kind of a byzantine mess. Clean it up to operate in the following manner during a full modeset: 1) master uapi -> hw state copy 2) master hw -> slave hw state copy And during a non-modeset update we do: 1) master uapi -> hw state light copy 2) master hw -> slave hw state light copy I think that is now easier to reason about since we never do any kind of master uapi -> slave hw state copy short circuit that could happen previously. Obviously this does now depend on the master uapi->hw copy always happening before the master hw -> slave hw copy, but that is guaranteed by the fact that we always add both crtcs to the state early, the crtcs are registered in pipe order (so the compute_config loop happens in pipe order), and the hardware requires the master pipe has to be lower than the slave pipe as well. And for good measure we shall add a check+WARN for this before doing the bigjoiner crtc assignment. v2: Fix uapi.ctm vs. hw.ctm copy-paste fail Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220204072049.1610-1-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2022-02-11drm/i915: Remove weird code from intel_atomic_check_bigjoiner()Ville Syrjälä1-22/+11
There's some weird junk in intel_atomic_check_bigjoiner() that's trying to look at the old crtc state's bigjoiner usage for some reason. That code is totally unnecessary, and maybe even actively harmful. Not entirely sure which since it's such a mess that I can't actually wrap my brain around what it ends up doing. Either way, thanks to intel_bigjoiner_add_affected_crtcs() all of the old bigjoiner crtcs are guaranteed to be in the state already if any one of them is in the state. Also if any one of those crtcs got flagged for a modeset, then all of them will have been flagged, and the bigjoiner links will have been detached via kill_bigjoiner_slave(). So there is no need to look examing any old bigjoiner usage in intel_atomic_check_bigjoiner(). All we have to care about is whether bigjoiner is needed for the new state, and whether we can get the slave crtc we need. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220203183823.22890-4-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2022-02-11drm/i915: Fix bigjoiner state copy failsVille Syrjälä1-1/+13
We seem to be missing a few things from the bigjoiner state copy. Namely hw.mode isn't getting copied (which probably causes PIPESRC to be misconfigured), CTM/LUTs aren't getting copied (which could cause the pipe to produced incorrect output), and we also forgot to copy over the color_mgmt_changed flag so potentially we fail to do the actual CTM/LUT programming (assuming we aren't doing a full modeset or fastset). Fix it all. v2: Fix uapi.ctm vs. hw.ctm copy-paste fail Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220204072009.1546-1-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2022-02-11drm/i915: Flag crtc scaling_filter changes as modesetVille Syrjälä1-0/+4
The core doesn't flag scaling_filter prop changes as needing a modeset. That doesn't work for us since we only reprogram the pipe scaler during full modesets and fastsets. So we need to flag the prop change as a modeset ourselves. Assuming nothing else has changed the operation will get promoted (demoted?) to a fastset later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220203183823.22890-2-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2022-02-09drm/i915: Fix IPS disable in intel_plane_disable_noatomic()Ville Syrjälä1-2/+4
IPS must be disabled prior to disabling the last plane (excluding the cursor). Make the code do that instead of assuming the primary plane would be the last one. This is probably 100% theoretical as the BIOS should never light up the other planes anyway. But no harm in making the code totally consistent. Also let's update the ips_enabled flag in the crtc state afterwards so that the first atomic commit has accurate information about the state of IPS. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220209113526.7595-6-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2022-02-09drm/i915: Extract hsw_ips_get_config()Ville Syrjälä1-13/+1
Pull the IPS state readout into hsw_ips.c. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220209113526.7595-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-09drm/i915: Move the IPS code to its own fileVille Syrjälä1-238/+1
IPS is a pretty well isolated feature. Move the relevant code to a separate file from polluting intel_display.c. I stuck to the hsw_ips name since that's what the function were already using, and also to avoid confusion with the ILK "Intelligen Power Sharing"/intel_ips GPU turbo stuff. And let's also do the s/dev_priv/i915/ rename while touching most of the code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220209113526.7595-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-09drm/i915: Hoover the IPS enable/disable calls into the pre/post update hooksVille Syrjälä1-12/+34
No reason the caller of the IPS pre/post update hooks should be responsible for the actual IPS enab/disable. Just pull those calls into the pre/post update hooks themselves. And while at it let's adjust the function naming a bit to have a consistent namespace. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220209113526.7595-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-09drm/i915: Change IPS calling conventionVille Syrjälä1-16/+22
Follow the modern state+crtc calling convention for the IPS code as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220209113526.7595-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-09drm/i915: Move vblank waits out from IPS codeVille Syrjälä1-7/+12
Hoist the IPS related vblank waits one level up. Later on we'll want to consolidate all the potential pre-plane update vblank waits into one so we can't be hiding any in low level code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220209113526.7595-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-09drm/i915/dpll: add intel_dpll_crtc_compute_clock()Jani Nikula1-1/+1
Avoid referencing the function pointer directly to be able to abstract the call better. 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/12ac40c1ef9915fe680c6657b603b08be022626b.1643896905.git.jani.nikula@intel.com
2022-02-07drm/i915: Workaround broken BIOS DBUF configuration on TGL/RKLVille Syrjälä1-0/+1
On TGL/RKL the BIOS likes to use some kind of bogus DBUF layout that doesn't match what the spec recommends. With a single active pipe that is not going to be a problem, but with multiple pipes active skl_commit_modeset_enables() goes into an infinite loop since it can't figure out any order in which it can commit the pipes without causing DBUF overlaps between the planes. We'd need some kind of extra DBUF defrag stage in between to make the transition possible. But that is clearly way too complex a solution, so in the name of simplicity let's just sanitize the DBUF state by simply turning off all planes when we detect a pipe encroaching on its neighbours' DBUF slices. We only have to disable the primary planes as all other planes should have already been disabled (if they somehow were enabled) by earlier sanitization steps. And for good measure let's also sanitize in case the DBUF allocations of the pipes already seem to overlap each other. Cc: <stable@vger.kernel.org> # v5.14+ Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4762 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220204141818.1900-3-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-02-03drm/i915: Disable unused power wells left enabled by BIOSImre Deak1-0/+2
Make sure all unused power wells left enabled by BIOS get disabled during driver loading and system resume. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5028 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220202104249.2680843-1-imre.deak@intel.com
2022-02-01drm/i915: Document BDW+ DRRS M/N programming requirementsVille Syrjälä1-0/+4
When reprogramming M/N live on BDW+ we must write the LINK_N register last as it's the one that arms the double buffered register update for all the M/N registers. Document this so that we don't accidentally break things. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-18-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01drm/i915: Always check dp_m2_n2 on pre-bdwVille Syrjälä1-6/+5
No point in special casing the check of dp_m2_n2 on pre-bdw platforms. Either the transcoder has M2/N2 in which case the values should be set to something sensible, or it doesn't in which case dp_m2_n2 is always zeroed. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-17-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01drm/i915: Dump dp_m2_n2 alwaysVille Syrjälä1-5/+5
No point in special casing the dp_m2_n2 dumping. Just do it always. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-16-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01drm/i915: Clear DP M2/N2 when not doing DRRSVille Syrjälä1-4/+11
Make life simpler by always programming DP M2/N2 with a consistent value. This will lets use do state readout+chec unconditionally. I was first going to just set M2/N2=M1/N1 but then it occurred to me that it might interfere with fastboot on account of BIOS likely leaving the registers zeroed. So let's zero out the values instead (except TU where a zero register value actually means '1'). Still not sure that's the best approach but lets go with it for now. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-14-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01drm/i915: Fix transcoder_has_m2_n2()Ville Syrjälä1-5/+1
M2/N2 values are present for all ilk-ivb,vlv,chv (and hsw edp). Make the code reflect that. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-13-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01drm/i915: Extract {i9xx,ilk}_configure_cpu_transcoder()Ville Syrjälä1-33/+40
Follow the path laid out by hsw+ and extract helpers to configure the cpu transcoder for earlier platforms as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01drm/i915: Move M/N setup to a more logical place on ddi platformsVille Syrjälä1-4/+10
Let's do the cpu transcoder M/N setup next to where we program most other cpu transcoder timings/etc. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01drm/i915: Move PCH transcoder M/N setup into the PCH codeVille Syrjälä1-46/+16
Do the PCH transcoder M/N setup next to where all the other PCH transcoder stuff is programmed. Matches the spec modeset sequence better. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01drm/i915: Pass crtc+cpu_transcoder to intel_cpu_transcoder_set_m_n()Ville Syrjälä1-19/+18
Instead of passing in the whole crtc state let's pass in just the bits of state we need. This will help with the DRRS code which shouldn't really be accessing the atomic state stuff directly as it gets called outside the normal atomic flows. v2: Fix set_m1_n1 vs. set_m2_n2 fumble for i9xx (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01drm/i915: Split intel_cpu_transcoder_get_m_n() into M1/N1 vs. M2/N2 variantsVille Syrjälä1-13/+19
As with intel_cpu_transcoder_set_m_n() let's split the readout counterpart into explicit M1/N1 vs. M2/N2 variants as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01drm/i915: Split intel_cpu_transcoder_set_m_n() into M1/N1 vs. M2/N2 variantsVille Syrjälä1-33/+42
Make things a bit more explicit by splitting intel_cpu_transcoder_set_m_n() into separate variants for M1/N1 vs. M2/N2. Makes the DRRS M/N programming at least more obvious. Note that for the MST and DRRS cases we don't need to call the M2/N2 variant at all since the transcoders that support those do not have the M2/N2 registers. Same could be said for i9xx_crtc_enable() but I want to do a higher level code sharing between that valleyview_crtc_enable() later in which case we do need the M2/N2 variant. This is also why I keep the transcoder_has_m2_n2() in intel_cpu_transcoder_set_m2_n2() so the caller doesn't have necessarily care what the chosen transcoder supports. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01drm/i915: Nuke ilk_get_fdi_m_n_config()Ville Syrjälä1-7/+0
Get rid of the entirely pointless ilk_get_fdi_m_n_config() wrapper and just call the CPU transcoder function directly. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01drm/i915: Nuke intel_dp_get_m_n()Ville Syrjälä1-17/+6
As with intel_dp_set_m_n() let's get rid of the wrapper and just call the relevant PCH vs. CPU transcoder functions directly. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01drm/i915: Nuke intel_dp_set_m_n()Ville Syrjälä1-36/+20
I want to make a clean split betwen the CPU vs. PCH transcoder programming. To that end eliminate intel_dp_set_m_n() and just call the individual CPU/PCH transcoder functions directly. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01Merge tag 'drm-misc-next-2022-01-27' of ↵Dave Airlie1-1/+1
git://anongit.freedesktop.org/drm/drm-misc into drm-next [airlied: add two missing Kconfig] drm-misc-next for v5.18: UAPI Changes: - Fix invalid IN_FORMATS blob when plane->format_mod_supported is NULL. Cross-subsystem Changes: - Assorted dt bindings updates. - Fix vga16fb vga checking on x86. - Fix extra semicolon in rwsem.h's _down_write_nest_lock. - Assorted small fixes to agp and fbdev drivers. - Fix oops in creating a udmabuf with 0 pages. - Hot-unplug firmware fb devices on forced removal - Reqquest memory region in simplefb and simpledrm, and don't make the ioresource as busy. Core Changes: - Mock a drm_plane in drm-plane-helper selftest. - Assorted bug fixes to device logging, dbi. - Use DP helper for sink count in mst. - Assorted documentation fixes. - Assorted small fixes. - Move DP headers to drm/dp, and add a drm dp helper module. - Move the buddy allocator from i915 to common drm. - Add simple pci and platform module init macros to remove a lot of boilerplate from some drivers. - Support microsoft extension for HMDs and specialized monitors. - Improve edid parser's deep color handling. - Add type 7 timing support to edid parser. - Add a weak backpointer to the ttm_bo from ttm_resource - Add 3 eDP panels. Driver Changes: - Add support for HDMI and JZ4780 to ingenic. - Add support for higher DP/eDP bitrates to nouveau. - Assorted driver fixes to tilcdc, vmwgfx, sn65dsi83, meson, stm, panfrost, v3d, gma500, vc4, virtio, mgag200, ast, radeon, amdgpu, nouveau, various bridge drivers. - Convert and revert exynos dsi support to bridge driver. - Add vcc supply regulator support for sn65dsi83. - More conversion of bridge/chipone-icn6211 to atomic. - Remove conflicting fb's from stm, and add support for new hw version. - Add device link in parade-ps8640 to fix suspend/resume. - Update Boe-tv110c9m init sequence. - Add wide screen support to AST2600. - Fix omapdrm implicit dma_buf fencing. - Add support for multiple overlay planes to vkms. - Convert bridge/anx7625 to atomic, add HDCP support, add eld support for audio, and fix HPD. - Add driver for ChromeOS privacy screen. - Handover display from firmware to vc4 more gracefully, and support nomodeset. - Add flexible and ycbcr pixel formats to stm/ltdc. - Convert exynos mipi dsi to atomic. - Add initial dual core group GPUs support to panfrost. - No longer add exclusive fence in amdgpu as shared fence. - Add CSC and full range supoprt to vc4. - Shutdown the display on system shutdown and unbind. - Add Multi-Inno Technology MI0700S4T-6 simple panel. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/456a23c6-7324-7543-0c45-751f30ef83f7@linux.intel.com
2022-01-31Merge drm/drm-next into drm-intel-nextRodrigo Vivi1-11/+11
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-28drm/i915: s/gmch_{m,n}/data_{m,n}/Ville Syrjälä1-24/+24
Rename the gmch_* M/N members to data_* to match the register definitions and thus make life a little less confusing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220127093303.17309-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-01-28drm/i915: Clean up M/N register definesVille Syrjälä1-5/+5
Use REG_GENMASK() & co. for the M/N register values. There are also a lot of weird unused defines (eg. *_OFFSET) we can just throw out. Also let's mask out the unused bits during readout for good measure. Previously we only masked out the TU_SIZE from one of the registers, which was a bit too inconsistent for my taste. v2: Mention the readout masking in the commit msg (Jani) Deal wth gvt 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/20220127120219.20143-1-ville.syrjala@linux.intel.com
2022-01-28drm/i915: Extract intel_{get,set}_m_n()Ville Syrjälä1-62/+47
Make the M/N setup/readout a bit less repitive by extracting a few small helpers. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220127093303.17309-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-30 05:09:51 +0000