summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2022-02-25drm/i915: Fix MSO vs. bigjoiner timings confusionVille Syrjälä
When calculating pipe_mode and when doing readout we need to order our steps correctly. 1. We start with adjusted_mode crtc timings being populated with the transcoder timings (either via readout or compute_config(). These will be per-segment for MSO. 2. For all other uses we want the full crtc timings so we ask intel_splitter_adjust_timings() to expand the per-segment numbers to their full glory 3. If bigjoiner is used we the divide the full numbers down to per-pipe numbers using intel_bigjoiner_adjust_timings() During readout we also have to reconstruct the adjusted_mode normal timings (ie. not the crtc_ stuff). These are supposed to reflect the full timings of the display. So we grab these between steps 2 and 3. The "user" mode readout (mainly done for fastboot purposes) should be whatever mode the user would have used had they asked us to do a modeset. We want the full timings for this as the per-segment timings are not suppoesed to be user visible. Also the user mode normal timings hdisplay/vdisplay need to match PIPESRC (that is where we get our PIPESRC size we doing a modeset with a user supplied mode). And we end up with - adjusted_mode normal timigns == full timings - adjusted_mode crtc timings == transcoder timings (per-segment timings for MSO, full timings otherwise) - pipe_mode normal/crtc timings == pipe timings (full timings divided by the number of bigjoiner pipes, if any) - user mode normal timings == full timings with hdisplay/vdisplay replaced with PIPESRC size - user mode crtc timings == full timings Yes, that is a lot of timings. One day we'll try to remove some of the ones we don't actually need to keep around... Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-10-ville.syrjala@linux.intel.com
2022-02-25drm/i915: Extract intel_crtc_compute_pipe_mode()Ville Syrjälä
Pull intel_crtc_compute_pipe_mode() out from intel_crtc_compute_config(). Since it's semi related we'll suck in the max dotclock/double wide checks in as well. And we'll pimp the debugs while at it. Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-9-ville.syrjala@linux.intel.com
2022-02-25drm/i915: Extract intel_crtc_compute_pipe_src()Ville Syrjälä
intel_crtc_compute_config() doesn't really tell a unified story. Let's chunk it up into pieces. We'll start with intel_crtc_compute_pipe_src(). Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-8-ville.syrjala@linux.intel.com
2022-02-25drm/i915: Extract intel_bigjoiner_adjust_timings()Ville Syrjälä
Deduplicate the code to convert the full timings to per-pipe timings for bigjoiner usage. Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-7-ville.syrjala@linux.intel.com
2022-02-25drm/i915: Extract intel_splitter_adjust_timings()Ville Syrjälä
Let's not replicate the same piece of code to expand the MSO segment timings to full width in many places. Pull it into a helper 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/20220223131315.18016-6-ville.syrjala@linux.intel.com
2022-02-25drm/i915: Rename variables in intel_crtc_compute_config()Ville Syrjälä
Do the s/dev_priv/i915/ and s/pipe_config/crtc_state/ renames to intel_crtc_compute_config(). I want to start splitting this up a bit and doing the renames now avoids spreading these old nameing conventions elsewhere. No functional changes. Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-5-ville.syrjala@linux.intel.com
2022-02-25drm/i915: Remove nop bigjoiner state copyVille Syrjälä
We just copied over the whole master crtc state, including cpu_transcoder+has_audio. No need to copy those again. Also get rid of the unhelpful comment. Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-4-ville.syrjala@linux.intel.com
2022-02-25drm/i915: Fix cursor coordinates on bigjoiner slaveVille Syrjälä
Adjust the cursor dst coordinates appripriately when it's on the bigjoiner slave pipe. intel_atomic_plane_check_clipping() already did this but with the cursor we discard those results (apart from uapi.visible and error checks) since the hardware will be doing the clipping for us. v2: Rebase due to bigjoiner bitmask usage Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-3-ville.syrjala@linux.intel.com
2022-02-25drm/i915: Avoid negative shift due to bigjoiner_pipes==0Ville Syrjälä
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>
2022-02-25drm/i915: s/JSP2/ICP2/ PCHVille Syrjälä
This JSP2 PCH actually seems to be some special Apple specific ICP variant rather than a JSP. Make it so. Or at least all the references to it seem to be some Apple ICL machines. Didn't manage to find these PCI IDs in any public chipset docs unfortunately. The only thing we're losing here with this JSP->ICP change is Wa_14011294188, but based on the HSD that isn't actually needed on any ICP based design (including JSP), only TGP based stuff (including MCC) really need it. The documented w/a just never made that distinction because Windows didn't want to differentiate between JSP and MCC (not sure how they handle hpd/ddc/etc. then though...). Cc: stable@vger.kernel.org Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4226 Fixes: 943682e3bd19 ("drm/i915: Introduce Jasper Lake PCH") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220224132142.12927-1-ville.syrjala@linux.intel.com Acked-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Tested-by: Tomas Bzatek <bugs@bzatek.net>
2022-02-25drm/i915/dmc: Do not try loading wrong DMC versionLucas De Marchi
Checking by >= DISPLAY_VER(12) made sense when the support for Tiger Lake was added. However now it only leads to wrong behavior when adding more platforms since it's expected they either don't have DMC to load or they have their own blob. Logs from DG2 loading on a CFL host, without having a DMC firmware defined: <6>[ 0.000000] DMI: Intel Corporation CoffeeLake Client Platform/CoffeeLake S UDIMM RVP, BIOS CNLSFWR1.R00.X220.B00.2103302221 03/30/2021 ... <6>[ 2.706607] pci 0000:03:00.0: [8086:56a0] type 00 class 0x030000 ... <7>[ 6.340397] i915 0000:03:00.0: [drm:intel_dmc_ucode_init [i915]] Loading i915/tgl_dmc_ver2_12.bin <7>[ 6.341841] i915 0000:03:00.0: [drm:intel_fbc_init [i915]] Sanitized enable_fbc value: 1 <3>[ 6.342432] genirq: Flags mismatch irq 0. 00000080 (i915) vs. 00015a00 (timer) <6>[ 6.346283] i915 0000:03:00.0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_12.bin (v2.12) <3>[ 6.385756] i915 0000:03:00.0: Device initialization failed (-16) <5>[ 6.385778] i915 0000:03:00.0: Please file a bug on drm/i915; see https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for details. <4>[ 6.385782] i915: probe of 0000:03:00.0 failed with error -16 TGL is the only platform left with DISPLAY_VER() == 12 that is not handled already in the if/else ladder, so handle it specifically. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223210933.3049143-1-lucas.demarchi@intel.com
2022-02-24drm/i915/dg2: Skip output init on PHY calibration failureMatt Roper
If one of our PHYs fails to complete calibration, we should skip the general initialization of the corresponding output. Most likely this is going to happen on outputs that don't actually exist on the board; in theory we should have already decided to skip this output based on the VBT, but we can't always rely on the VBT being accurate. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223165421.3949883-1-matthew.d.roper@intel.com
2022-02-24drm/i915: Make pre-skl sprite plane registers unlockedVille Syrjälä
Drop the locks around sprite plane register writes. The lock isn't needed since each plane's register are neatly contained on their own cachelines. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220210062403.18690-6-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-02-24drm/i915: Make most pre-skl primary plane registers unlockedVille Syrjälä
Drop the locks around most primary plane register writes. The lock isn't needed since each plane's register are neatly contained on their own cachelines. The one exception we have to make is DSPADDR/DSPSURF which is (ab)used to also trigger FBC nukes on pre-snb (since the hardware doesn't seem to have any dedicated mechanism to trigger nukes). So we need to keep the lock around it to protect against the rmw performed by the fbc code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220210062403.18690-5-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-02-24drm/i915: Make cursor plane registers unlockedVille Syrjälä
Drop the locks around cursor plane register writes. The lock isn't needed since each plane's register are neatly contained on their own cachelines. The locking did have a secondary effect of disabling interrupts around the cursor registers writes though. If we drop that then we open outselves up for sceduling delays and whatnot while on the middle of the register writes. That increases the chance of not all the register writes land during the same frame. For normal atomic commits this is not a concern as the vblank evade mechanism anyway disables interrupts around the update, but the legacy cursor codepath does not. Technically we should do a vblank evade there as well, but so far no one has bothered to hook that up. So in the meantime let's put an explicit local irq disable/enable around the legacy cursor update to keep the race window minimal. v2: local_irq_{disable,enable}() for legacy cursor ioctl Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220211092604.393-1-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-02-24drm/i915: Make skl+ universal plane registers unlockedVille Syrjälä
Drop the locks around most universal plane register writes. The lock isn't needed since each plane's register are neatly contained on their own cachelines. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220210062403.18690-3-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-02-24drm/i915: Optimize icl+ universal plane programmingVille Syrjälä
On icl+ all plane registers are armed by PLANE_SURF, so we can move almost everything over into the update_noarm() hook. The PLANE_CTL write has to stay in the icl_update_arm() hook though as it still exhibits the somewhat annoying self-arming behaviour when the plane transitioning from disabled to enabled. We could either do a full split for skl+ vs. icl+, or we could try some other kind of split where we'd eg. keep most things in the skl+ functions and call them from the icl+ functions. I think a full split is probably the cleaner approach since we've anyway accumulated quite a bit of icl+ specific things, so that is what I opted to do. Some i915_update_info stats for tgl: before: after: Updates: 5043 Updates: 5043 | | 1us | 1us | |** |*** 4us |****** 4us |******** |********** |*********** 16us |*********** 16us |********** |**** |* 66us | 66us | | | 262us | 262us | | | 1ms | 1ms | | | 4ms | 4ms | | | 17ms | 17ms | | | Min update: 3494ns Min update: 2983ns Max update: 49491ns Max update: 39986ns Average update: 18031ns Average update: 13423ns Overruns > 100us: 0 Overruns > 100us: 0 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220210062403.18690-2-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-02-24drm/i915/dg2: Tile 4 plane format supportStanislav Lisovskiy
Tile4 in bspec format is 4K tile organized into 64B subtiles with same basic shape as for legacy TileY which will be supported by Display13. v2: - Moved Tile4 associating struct for modifier/display to the beginning(Imre Deak) - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier checks(Imre Deak) - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12 (Imre Deak) v3: - Rebased patch on top of new changes related to plane_caps. - Added static assert to check that PLANE_CTL_TILING_YF matches PLANE_CTL_TILING_4(Nanley Chery) - Fixed naming and layout description for Tile 4 in drm uapi header(Nanley Chery) v4: - Extracted drm_fourcc changes to separate patch(Nanley Chery) Reviewed-by: Imre Deak <imre.deak@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220118115544.15116-3-stanislav.lisovskiy@intel.com
2022-02-23Merge tag 'drm-intel-gt-next-2022-02-17' of ↵Rodrigo Vivi
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: Extract intel_bw_check_data_rate()Ville Syrjälä
Extract the data rate calculation loop out from intel_bw_atomic_check() to make it a bit less confusing. v2: Deal with 'bool changed' Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> #v1 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-7-ville.syrjala@linux.intel.com
2022-02-23drm/i915: Extract icl_qgv_points_mask()Ville Syrjälä
Declutter intel_bw_atomic_check() a bit by pulling the max QGV mask calculation out. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-6-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-02-23drm/i915: Properly clear crtc state when disabling it fully, againVille Syrjälä
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ä
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-23drm/i915: Dump hw.enable and pipe_modeVille Syrjälä
Include hw.enable and pipe_mode in the crtc debugfs state dump. These are fairly fundemental to the operation of the driver so not seeing them leaves us in the dark. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220217103221.10405-3-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2022-02-23drm/i915: Dump the crtc hw state alwaysVille Syrjälä
Let's just dump the "full" hw crtc state in debugs so that we can see if some stale junk was left behind when the crtc is supposed to be entirely off. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220217103221.10405-2-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2022-02-23Revert "drm/i915/display/vrr: Reset VRR capable property on a long hpd"Ville Syrjälä
This reverts commit 9bc34b4d0f3cb368241684cc5e0445d435dded44. Just oopses on most machines. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223081810.19917-1-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2022-02-22drm/i915/adl-n: Add PCH Support for Alder Lake NTejas Upadhyay
Add the PCH ID for ADL-N. Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220127103520.348015-1-tejaskumarx.surendrakumar.upadhyay@intel.com
2022-02-22drm/i915/display/vrr: Reset VRR capable property on a long hpdManasi Navare
With some VRR panels, user can turn VRR ON/OFF on the fly from the panel settings. When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore MSA bit in the DPCD. Currently the driver parses that onevery HPD but fails to reset the corresponding VRR Capable Connector property. Hence the userspace still sees this as VRR Capable panel which is incorrect. Fix this by explicitly resetting the connector property. v2: Reset vrr capable if status == connector_disconnected v3: Use i915 and use bool vrr_capable (Jani Nikula) v4: Move vrr_capable to after update modes call (Jani N) Remove the redundant comment (Jan N) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220215202601.22943-1-manasi.d.navare@intel.com
2022-02-21drm/i915/adlp: Add TypeC PHY TBT->DP-alt/legacy mode switch workaroundImre Deak
Add display workaround # 1309179469 , which fixes a PHY hang when switching from TBT mode to DP-alt/legacy mode. The workaround also requires an IFWI/PHY firmware change, before that this change has no effect (the DKL_PCS_DW5/SOFTRESET flag is always cleared). HSDES: 18018237866 HSDES: 16014473319 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218122611.767974-1-imre.deak@intel.com
2022-02-21drm/i915/pxp: prefer forward declaration over includesJani Nikula
Always use forward declarations instead of includes in headers if possible. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220214173644.2097124-1-jani.nikula@intel.com
2022-02-21drm/i915/reg: split out icl_dsi_regs.hJani Nikula
The ICL DSI registers have fairly isolated usage. Split the register macros to a separate file. 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-4-jani.nikula@intel.com
2022-02-21drm/i915/reg: split out vlv_dsi_regs.h and vlv_dsi_pll_regs.hJani Nikula
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-21drm/i915/dsi: add separate init timer mask definition for ICL DSIJani Nikula
Having a separate definition will be useful for splitting VLV and ICL register 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-2-jani.nikula@intel.com
2022-02-21drm/i915/dsi: disassociate VBT video transfer mode from register valuesJani Nikula
The VBT DSI video transfer mode field values have been defined in terms of the VLV MIPI_VIDEO_MODE_FORMAT register. The ICL DSI code maps that to ICL DSI_TRANS_FUNC_CONF() register. The values are the same, though the shift is different. Make a clean break and disassociate the values from each other. Assume the values can be different, and translate the VBT value to VLV and ICL register values as needed. Use the existing macros from intel_bios.h. This will be useful in splitting the DSI register macros to files by DSI implementation. 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-1-jani.nikula@intel.com
2022-02-19iosys-map: Add offset to iosys_map_memcpy_to()Lucas De Marchi
In certain situations it's useful to be able to write to an offset of the mapping. Add a dst_offset to iosys_map_memcpy_to(). Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220216174147.3073235-2-lucas.demarchi@intel.com
2022-02-18drm/i915/dg2: Enable 5th portMatt Roper
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/dg2: Drop 38.4 MHz MPLLB tablesMatt Roper
Our early understanding of DG2 was incorrect; since the 5th display isn't actually a Type-C output, 38.4 MHz input clocks are never used on this platform and we can drop the corresponding MPLLB tables. Cc: Anusha Srivatsa <anusha.srivatsa@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> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218010328.183423-2-lucas.demarchi@intel.com
2022-02-18drm/i915: Fix for PHY_MISC_TC1 offsetJouni Högander
Currently ICL_PHY_MISC macro is returning offset 0x64C10 for PHY_E. The PORT_TC1 port is not yet enabled properly in the driver, but intel_phy_snps.c is relying on intel_phy_is_snps() to filter out unavailable phys. That function was already considering the last phy as available. Just correct the offset of the last phy to 0x64C14 as the rest of the support for it is coming on next commits. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218010328.183423-1-lucas.demarchi@intel.com
2022-02-18drm/i915: Pimp icl+ sagv pre/post updateVille Syrjälä
Add some debugs on what exactly we're doing to the QGV point mask in the icl+ sagv pre/post plane update hooks. Currently we're just guessing. v2: s/u32/u16/ for consistency with the mask sizes (Stan) 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/20220218064039.12834-5-ville.syrjala@linux.intel.com
2022-02-18drm/i915: Split pre-icl vs. icl+ SAGV hooks apartVille Syrjälä
To further reduce the confusion between the pre-icl vs. icl+ SAGV codepaths let's do a full split. 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/20220218064039.12834-4-ville.syrjala@linux.intel.com
2022-02-18drm/i915: Fix bw atomic check when switching between SAGV vs. no SAGVVille Syrjälä
If the only thing that is changing is SAGV vs. no SAGV but the number of active planes and the total data rates end up unchanged we currently bail out of intel_bw_atomic_check() early and forget to actually compute the new WGV point mask and thus won't actually enable/disable SAGV as requested. This ends up poorly if we end up running with SAGV enabled when we shouldn't. Usually ends up in underruns. To fix this let's go through the QGV point mask computation if either the data rates/number of planes, or the state of SAGV is changing. v2: Check more carefully if things are changing to avoid the extra calculations/debugs from introducing unwanted overhead Cc: stable@vger.kernel.org Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> #v1 Fixes: 20f505f22531 ("drm/i915: Restrict qgv points which don't have enough bandwidth.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-3-ville.syrjala@linux.intel.com
2022-02-18drm/i915: Correctly populate use_sagv_wm for all pipesVille Syrjälä
When changing between SAGV vs. no SAGV on tgl+ we have to update the use_sagv_wm flag for all the crtcs or else an active pipe not already in the state will end up using the wrong watermarks. That is especially bad when we end up with the tighter non-SAGV watermarks with SAGV enabled. Usually ends up in underruns. Cc: stable@vger.kernel.org Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: 7241c57d3140 ("drm/i915: Add TGL+ SAGV support") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-2-ville.syrjala@linux.intel.com
2022-02-18drm/i915: Drop pointless i830 PIPECONF readVille Syrjälä
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: Make the CHV CGM CSC register writes locklessVille Syrjälä
The CHV CGM CSC registers are single buffered and so we may have to write them from the vblank worker, which imposes very tight dealines. Drop the pointless locking for the register accessess to reduce the overhead. All the other registers we bash from the vblank worker (LUTs) were already made lockless earlier. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220202111616.1579-3-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2022-02-18drm/i915: Make the pipe/output CSC register writes locklessVille Syrjälä
The pipe/output CSC register writes don't need to be locked since all the registers are suitably isolated to their own cachelines. So eliminate the locks to reduce the overhead during the vblank evade critical section. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220202111616.1579-2-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ä
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: Implement Wa_16013835468José Roberto de Souza
PSR2 workaround required when mode has delayed vblank. BSpec: 52890 BSpec: 49421 Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220210185223.95399-2-jose.souza@intel.com
2022-02-18drm/i915/display: Group PSR2 prog sequences and workaroundsJosé Roberto de Souza
Grouping inside of the same if all the programing sequences and workarounds of PSR2. The order of programing changed in intel_psr_enable_source() but it will not affect PSR2 as at this point PSR2_ENABLE is still disabled. Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220210185223.95399-1-jose.souza@intel.com
2022-02-18drm/i915/display/tgl+: Implement new PLL programming stepJosé Roberto de Souza
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: Disconnect PHYs left connected by BIOS on disabled portsImre Deak
BIOS may leave a TypeC PHY in a connected state even though the corresponding port is disabled. This will prevent any hotplug events from being signalled (after the monitor deasserts and then reasserts its HPD) until the PHY is disconnected and so the driver will not detect a connected sink. Rebooting with the PHY in the connected state also results in a system hang. Fix the above by disconnecting TypeC PHYs on disabled ports. Before commit 64851a32c463e5 the PHY connected state was read out even for disabled ports and later the PHY got disconnected as a side effect of a tc_port_lock/unlock() sequence (during connector probing), hence recovering the port's hotplug functionality. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5014 Fixes: 64851a32c463 ("drm/i915/tc: Add a mode for the TypeC PHY's disconnected state") Cc: <stable@vger.kernel.org> # v5.16+ Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220217152237.670220-1-imre.deak@intel.com
generated by cgit (git 2.34.1) at 2025-06-04 00:51:09 +0000