- 21 Mar, 2023 10 commits
-
-
Ville Syrjälä authored
Keeping DC states enabled is incompatible with the _noarm()/_arm() split we use for writing pipe/plane registers. When DC5 and PSR are enabled, all pipe/plane registers effectively become self-arming on account of DC5 exit arming the update, and PSR exit latching it. What probably saves us most of the time is that (with PIPE_MISC[21]=0) all pipe register writes themselves trigger PSR exit, and then we don't re-enter PSR until the idle frame count has elapsed. So it may be that the PSR exit happens already before we've updated the state too much. Also the PSR1 panel (at least on this KBL) seems to discard the first frame we trasmit, presumably still scanning out from its internal framebuffer at that point. So only the second frame we transmit is actually visible. But I suppose that could also be panel specific behaviour. I haven't checked out how other PSR panels behave, nor did I bother to check what the eDP spec has to say about this. And since this really is all about DC states, let's switch from the MODESET domain to the DC_OFF domain. Functionally they are 100% identical. We should probably remove the MODESET domain... And for good measure let's toss in an assert to the place where we do the _noarm() register writes to make sure DC states are in fact off. v2: Just use intel_display_power_is_enabled() (Imre) Cc: <stable@vger.kernel.org> #v5.17+ Cc: Manasi Navare <navaremanasi@google.com> Cc: Drew Davenport <ddavenport@chromium.org> Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Fixes: d13dde44 ("drm/i915: Split pipe+output CSC programming to noarm+arm pair") Fixes: f8a005eb ("drm/i915: Optimize icl+ universal plane programming") Fixes: 890b6ec4 ("drm/i915: Split skl+ plane update into noarm+arm pair") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230320183532.17727-1-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
Unlike SKL/GLK the ICL CSC unit suffers from a new issue where CSC_MODE arming is sticky. That is, once armed it remains armed causing the CSC coeff/offset registers to become effectively self-arming. CSC coeff/offset registers writes no longer disarm the CSC, but fortunately register read still do. So we can use that to disarm the CSC unit once the registers for the current frame have been latched. This avoid s the self-arming behaviour from persisting into the next frame's .color_commit_noarm() call. Cc: <stable@vger.kernel.org> #v5.19+ Cc: Manasi Navare <navaremanasi@google.com> Cc: Drew Davenport <ddavenport@chromium.org> Cc: Imre Deak <imre.deak@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Fixes: d13dde44 ("drm/i915: Split pipe+output CSC programming to noarm+arm pair") Signed-off-by:
-
Ville Syrjälä authored
We're going to need stuff after the color management register latching has happened. Add a corresponding hook. Cc: <stable@vger.kernel.org> #v5.19+ Cc: Manasi Navare <navaremanasi@google.com> Cc: Drew Davenport <ddavenport@chromium.org> Cc: Imre Deak <imre.deak@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
-
Ville Syrjälä authored
SKL/GLK CSC unit suffers from a nasty issue where a CSC coeff/offset register read or write between DC5 exit and PSR exit will undo the CSC arming performed by DMC, and then during PSR exit the hardware will latch zeroes into the active CSC registers. This causes any plane going through the CSC to output all black. We can sidestep the issue by making sure the PSR exit has already actually happened before we touch the CSC coeff/offset registers. Easiest way to guarantee that is to just move the CSC programming back into the .color_commir_arm() as we force a PSR exit (and crucially wait for it to actually happen) prior to touching the arming registers. When PSR (and thus also DC states) are disabled we don't have anything to worry about, so we can keep using the more optional _noarm() hook for writing the CSC registers. Cc: <stable@vger.kernel.org> #v5.19+ Cc: Manasi Navare <navaremanasi@google.com> Cc: Drew Davenport <ddavenport@chromium.org> Cc: Imre Deak <imre.deak@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8283 Fixes: d13dde44 ("drm/i915: Split pipe+output CSC programming to noarm+arm pair") Signed-off-by:
-
Ville Syrjälä authored
We're going to want different behavior for skl/glk vs. icl in .color_commit_noarm(), so split the hook into two. Arguably we already had slightly different behaviour since csc_enable/gamma_enable are never set on icl+, so the old code was perhaps a bit confusing as well. Cc: <stable@vger.kernel.org> #v5.19+ Cc: Manasi Navare <navaremanasi@google.com> Cc: Drew Davenport <ddavenport@chromium.org> Cc: Imre Deak <imre.deak@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
-
Arun R Murthy authored
Enable SDP error detection configuration, this will set CRC16 in 128b/132b link layer. For Display version 13 a hardware bit31 in register VIDEO_DIP_CTL is added to enable/disable SDP CRC applicable for DP2.0 only, but the default value of this bit will enable CRC16 in 128b/132b hence skipping this write. Corrective actions on SDP corruption is yet to be defined. v2: Moved the CRC enable to link training init(Jani N) v3: Moved crc enable to ddi pre enable <Jani N> v4: Separate function for SDP CRC16 (Jani N) Signed-off-by:
Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Arun R Murthy authored
DP2.0 E11 defines a new register to facilitate SDP error detection by a 128B/132B capable DPRX device. v2: Update the macro name to reflect the DP spec(Harry) Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230302081532.765821-2-arun.r.murthy@intel.com
-
Maarten Lankhorst authored
This prevents a namespace collision on other archs. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
The pipe may differ from crtc index if pipes are fused off. For testing purposes, IGT needs to know the pipe. There's already a I915_GET_PIPE_FROM_CRTC_ID IOCTL for this. However, the upcoming Xe driver won't have that IOCTL, and going forward, we'll want a unified interface for testing i915 and Xe, as they share the display code. Thus add the debugfs for i915 display. v2: User letters for pipe names (Ville) Cc: Bhanuprakash Modem <bhanuprakash.modem@intel.com> Reviewed-by:
Bhanuprakash Modem <bhanuprakash.modem@intel.com> Signed-off-by:
-
Jani Nikula authored
Convert the crtc debugfs code to use struct intel_crtc instead of struct drm_crtc. v2: Fix build for CONFIG_DRM_I915_DEBUG_VBLANK_EVADE=y (kernel test robot) Reviewed-by:
-
- 20 Mar, 2023 4 commits
-
-
Clint Taylor authored
BSPEC has updated the cdclk audio keepalives AUD_TS_CDCLK_M value to 60 for all supported platforms and refclks. BSPEC: 54034 BSPEC: 55409 BSPEC: 65243 Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Clint Taylor <clinton.a.taylor@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Jani Nikula authored
Handle errors first and return early, and reduce indentation on the happy day code path. Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230317134144.223936-3-jani.nikula@intel.com
-
Jani Nikula authored
Prefer struct intel_connector over struct drm_connector. Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
-
Jani Nikula authored
Move the debugfs next to the implementation. Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
-
- 18 Mar, 2023 4 commits
-
-
Ville Syrjälä authored
Pull the scanline_offset calculation into its own function. Might have further use for this later with DSB scanline waits. Reviewed-by:
Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Move intel_crtc_update_active_timings() into intel_vblank.c where it more properly belongs. Also do the s/dev_priv/i915/ modernization rename while at it. Reviewed-by:
-
Ville Syrjälä authored
Add some (probably overkill) locking to protect the vblank timestamping constants updates during seamless M/N fastsets. As everything should be naturally aligned I think the individual pieces should probably end up updating atomically enough. So this is only really meant to guarantee everyone sees a consistent whole. All the drm_vblank.c usage is covered by vblank_time_lock, and uncore.lock will take care of __intel_get_crtc_scanline() that can also be called from outside the core vblank functionality. Currently only crtc_clock and framedur_ns can change, but in the future might fastset also across eg. vtotal/vblank_end changes, so let's just grab the locks across the whole thing. Reviewed-by:
-
Ville Syrjälä authored
When we change the M/N values seamlessly during a fastset we should also update the vblank timestamping stuff to make sure the vblank timestamp corrections/guesstimations come out exact. Note that only crtc_clock and framedur_ns can actually end up changing here during fastsets. Everything else we touch can only change during full modesets. Technically we should try to do this exactly at the start of vblank, but that would require some kind of double buffering scheme. Let's skip that for now and just update things right after the commit has been submitted to the hardware. This means the information will be properly up to date when the vblank irq handler goes to work. Only if someone ends up querying some vblanky stuff in between the commit and start of vblank may we see a slight discrepancy. Also this same problem really exists for the DRRS downclocking stuff. But as that is supposed to be more or less transparent to the user, and it only drops to low gear after a long delay (1 sec currently) we probably don't have to worry about it. Any time something is actively submitting updates DRRS will remain in high gear and so the timestamping constants will match the hardware state. Reviewed-by:
-
- 17 Mar, 2023 9 commits
-
-
Ville Syrjälä authored
Move the sprite colorkey ioctl handler to its own file so that intel_sprite.c becomes all about the low level details of pre-skl sprite planes. And drop a bunch of unnecessary includes while at it. Signed-off-by:
-
Ville Syrjälä authored
Move intel_plane_check_src_coordinates() from the pre-skl sprite plane specific code to a more suitable place for common plane code. Signed-off-by:
-
Ville Syrjälä authored
Convert a few more skl+ plane registers to REG_BIT() & co. Somehow thse were missed during the earlier cleanup. Signed-off-by:
-
Ville Syrjälä authored
Might as well complete the SURFLIVE register definitions for all platforms/plane types. We are only missing the VLV/CHV sprite planes. Signed-off-by:
-
Ville Syrjälä authored
Add the definitions for the skl+ univerals plane SURFLIVE registers. Despite not being used for anything real these came in suprisingly handy during some DSB debugging recently, so having the defines around can be useful. Signed-off-by:
-
Ville Syrjälä authored
VLV/CHV have an extra register to configure some stereo3d signalling details via DP MSA. Make sure we reset that register to zero (since we don't do any stereo3d stuff). Signed-off-by:
-
Ville Syrjälä authored
Add definitions for various pipe timestamp registers: - frame timestamp (last start of vblank) (g4x+), already had this defined - flip timestamp (when SURF was last written) (g4x+) - flipdone timestamp (when last flipdone was signalled) (tgl+) Note that on pre-tgl the flip related timestamps are only updated for primary plane flips, but on tgl+ we can select which plane updates them (via PIPE_MISC2). Let's define those related bits as well. Curiously VLV/CHV do not have the frame/flip timestamp registers, despite all the other related registers being inherited from g4x. This means we can get rid of the pipe_offsets[] usage for these, and thus the implicit dev_priv is gone as well. Signed-off-by:
-
Ville Syrjälä authored
This PIPEMISC vs. PIPE_MISC inconsitency is ugly. Unify the naming (PIPE_MISC is also what bspec has always called it). Signed-off-by:
-
Ville Syrjälä authored
The PIPE_MISC registers don't exist on pre-bdw hardware, so there is no point in using pipe_offsets[] for them. Signed-off-by:
-
- 16 Mar, 2023 3 commits
-
-
Vinod Govindapillai authored
If the ignore long HPD flag is set, ignore the link training failures as well. Because of spurious HPDs, some unexpected link training failures are happening while executing IGT test cases. Ignore the link training failures for the time being if the long HPDs are also ignored in the environments like CI. Signed-off-by:
Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by:
-
Vinod Govindapillai authored
Some panels generate long HPD events even while connected to the port. This cause some unexpected CI execution issues. A new flag is added to track if such spurious long HPDs can be ignored and are not processed further if the flag is set. Debugfs entry is added to control the ignore long hpd flag. v2: Address patch styling comments (Jani Nikula) v3: Ignoring the HPD moved to hotplug handler and now applies to all types of outputs (Imre Deak) v4: use debugfs_create_bool and squash patches (Jani Nikula) Signed-off-by: -
Imre Deak authored
Add the missing intel_opregion_cleanup() prototype fixing CONFIG_ACPI=n builds. Fixes: 3e226e4a ("drm/i915/opregion: Cleanup opregion after errors during driver loading") Cc: Jani Nikula <jani.nikula@intel.com> Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202303141610.6L1VO7Gw-lkp@intel.com/Signed-off-by:
-
- 15 Mar, 2023 2 commits
-
-
Ville Syrjälä authored
Bspec calls us to select pattern 2 after link training for DP 2.0. Let's do that... by doing nothing because we will be transmitting pattern 2 at the end of the link training already. Reviewed-by:
-
Ville Syrjälä authored
AFAICS Bspec has never asked us to switch to TPS1 when *disabling* DP_TP_CTL. Let's stop doing that in case it confuses something. We do have to switch before we *enable* DP_TP_CTL, but that is already being handled correctly. v2: Do the same for FDI v3: Rebase Reviewed-by: Imre Deak <imre.deak@intel.com> #v1 Signed-off-by:
-
- 14 Mar, 2023 2 commits
-
-
Ankit Nautiyal authored
While computing compressed bpp, maximum value of bits_per_pixel is calculated that can be supported with the given link configuration for a given mode. Avoid rounding up of this max bits_per_pixel. Also improve documentation for computing max bits_per_pixel. Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Jani Nikula authored
Follow the style of placing debugfs next to the implementation. Signed-off-by:
-
- 10 Mar, 2023 6 commits
-
-
Ville Syrjälä authored
The pipe needs a certain amount of time during vblank to prefill sufficiently. If the vblank is too short the relevant watermark level must be disabled. Start implementing the necessary calculations to check this. Scaler and DSC prefill are left out for now as handling those is not entirely trivial. Also the PSR latency reporting override chicken bits would need to be correctly configured based on the results of these calculations. Just add some FIXMEs for now. TODO: bspec isn't exactly crystal clear in its explanations so quite a few open questions remain... v2: Skip inacive pipes Handle SAGV latency v3: Rebase v4: Fix handling of disabled wm levels (latency == 0) Reviewed-by: -
Ville Syrjälä authored
Extract the skl+ wm latency determination into a small helper so that everyone has the same idea what the latency should be. This introduces a slight functional change in that skl_cursor_allocation() will now start to account for the extra 4 usec that the kbk/cfl/cml IPC w/a adds. v2: Rebase Reviewed-by:
-
Imre Deak authored
Move the display debugfs registration later, after initializing steps for opregion/acpi/audio. These latter ones don't depend on the debugfs entries, OTOH some debugfs entries may depend on the initialized state. Reviewed-by:
-
Imre Deak authored
Clean up the opregion state if something fails after intel_opregion_setup() is called. Reviewed-by:
-
Imre Deak authored
Atm, during system resume, the driver updates the display connector information required by the opregion video extensions during system resume, on platforms both with and without display being present. On !HAS_DISPLAY platforms this will result in the crash with the stack trace below, since the driver's connector state is not initialized on those. Bspec doesn't specify when each of the opregion functionality is supported (depending on the presence of display), however we can presume that none of the video extensions, nor the ACPI _DSM functions are supported on !HAS_DISPLAY platforms; accordingly skip the corresponding opregion/ACPI setup on those (also matching the Windows driver in this). Keep sending the opregion notification about suspending/resuming the whole adapter (vs. the display only which is a separate power state notification) on all platforms, similarly to runtime suspend/resume. This fixes the following: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 1443 Comm: kworker/u40:55 Tainted: G U 6.2.0-rc8+ #58 Hardware name: LENOVO 82VB/LNVNB161216, BIOS KMCN09WW 04/26/2022 Workqueue: events_unbound async_run_entry_fn RIP: 0010:drm_connector_list_iter_next+0x4f/0xb0 Call Trace: <TASK> intel_acpi_device_id_update+0x80/0x160 [i915] intel_opregion_resume+0x2f/0x1e0 [i915] ? dg2_init_clock_gating+0x49/0xf0 [i915] i915_drm_resume+0x137/0x190 [i915] ? __pfx_pci_pm_resume+0x10/0x10 dpm_run_callback+0x47/0x150 Cc: iczero <iczero@hellomouse.net> Reported-and-tested-by:
iczero <iczero@hellomouse.net> References: https://gitlab.freedesktop.org/drm/intel/-/issues/8015Reviewed-by:
-
Ville Syrjälä authored
intel_crtc_prepare_cleared_state() is unintentionally losing the "inherited" flag. This will happen if intel_initial_commit() is forced to go through the full modeset calculations for whatever reason. Afterwards the first real commit from userspace will not get forced to the full modeset path, and thus eg. audio state may not get recomputed properly. So if the monitor was already enabled during boot audio will not work until userspace itself does an explicit full modeset. Cc: stable@vger.kernel.org Tested-by:
Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com>
-
