#
dea1731d |
|
12-Dec-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Move intel_vblank_evade() & co. into intel_vblank.c intel_vblank.c seems like the appropriate place for the core vblank evasion code. Move it there. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-8-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
|
#
318ec320 |
|
12-Dec-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Move the min/max scanline sanity check into intel_vblank_evade() There isn't really any reason to make the caller suffer through checking the vblank evasion min/max scanlines. If we somehow ended up with bogus values (which really shouldn't happen) then just skip the actual vblank evasion loop but otherwise plow ahead as normal. The only "real" change is that we now get+put a vblank reference even if the min/max values are bogus, previously we skipped directly to the end. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-7-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
|
#
b5ad7ce0 |
|
12-Dec-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Extract intel_vblank_evade() Pull the core vblank evasion loop into its own function, so that we can reuse it elsewhere later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-6-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
|
#
b1f9bc3d |
|
12-Dec-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Include need_vlv_dsi_wa in intel_vblank_evade_ctx Pull the need_vlv_dsi_wa details into intel_vblank_evade_init() so that caller doesn't have to care about it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-5-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
|
#
637bda52 |
|
12-Dec-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce struct intel_vblank_evade_ctx Collect the information needed for vblank evasions into a structure that we can pass around more easily. And let's rename intel_crtc_vblank_evade_scanlines() to just intel_vblank_evade_init() so that better describes the intended usage of initializing the context. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-4-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
|
#
bb83f348 |
|
12-Dec-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Reorder drm_vblank_put() vs. need_vlv_dsi_wa Drop the vblank reference only after we've done the hideous need_vlv_dsi_wa stuff. This will make it easier to reuse the the vblank evasion machinery elsewhere. Keeping the vblank reference for a bit longer is not a problem. In fact we might want to not drop it at all until intel_pipe_update_end(), but we'll leave that idea for later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-3-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
|
#
c045bc42 |
|
12-Dec-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Decouple intel_crtc_vblank_evade_scanlines() from atomic commits We'll be needing to do vblank evasion around legacy cursor updates, which don't have the intel_atomic_state around. So let's remove this dependency on a full commit and pass the crtc state in by hand. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-2-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
|
#
6128beca |
|
28-Sep-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Stop accessing crtc->state from the flip done irq Assuming crtc->state is pointing at the correct thing for the async flip commit is nonsense. If we had already queued up multiple commits this would point at the very lates crtc state even if the older commits hadn't even happened yet. Instead properly stage/arm the event like we do for async flips. Since we don't need to arm multiple of these at the same time we don't need a list like the normal vblank even processing uses. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230928152450.30109-1-ville.syrjala@linux.intel.com Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
|
#
8ca0b875 |
|
21-Sep-2023 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Add helpers for BW management on shared display links At the moment a modeset fails if the config computation of a pipe can't fit its required BW to the available link BW even though the limitation may be resolved by reducing the BW requirement of other pipes. To improve the above this patch adds helper functions checking the overall BW limits after all CRTC states have been computed. If the check fails the maximum link bpp for a selected pipe will be reduced and all the CRTC states will be recomputed until either the overall BW limit check passes, or further bpp reduction is not possible (because all pipes/encoders sharing the link BW reached their minimum link bpp). Atm, the MST encoder allocates twice the required BW for YUV420 format streams. A follow-up patchset will fix that, add a code comment about this. This change prepares for upcoming patches enabling the above BW management on FDI and MST links. v2: - Rename intel_crtc_state::max_link_bpp to max_link_bpp_x16 and intel_link_bw_limits::max_bpp to max_bpp_x16. (Jani) v3: - Add the helper functions in a separate patch. (Ville) - Add the functions to intel_link_bw.c instead of intel_atomic.c (Ville) - Return -ENOSPC instead of -EINVAL to userspace in case of a link BW limit failure. v4: - Make intel_atomic_check_config() static. v5: (Ville) - Rename intel_link_bw_limits::min_bpp_pipes to min_bpp_reached_pipes and intel_link_bw_reset_pipe_limit_to_min() to intel_link_bw_set_min_bpp_for_pipe(). - Rename pipe_bpp to link_bpp in intel_link_bw_reduce_bpp(). - Add FIXME: comment about MST encoder's YUV420 BW allocation and tracking the link bpp limit accordingly. v6: - Move intel_link_bw_compute_pipe_bpp() to intel_fdi.c (Ville) - WARN_ON(BIT(pipe) & min_bpp_reached_pipes) in intel_link_bw_set_bpp_limit_for_pipe(). (Ville) - Rename intel_link_bw_set_min_bpp_for_pipe() to intel_link_bw_set_bpp_limit_for_pipe() and intel_link_bw_limits::min_bpp_reached_pipes to bpp_limit_reached_pipes. (Ville) - Remove unused header includes. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230921195159.2646027-10-imre.deak@intel.com
|
#
7678e089 |
|
06-Jun-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/dsb: Evade transcoder undelayed vblank when using DSB We want to start the DSB execution from the transcoder's undelayed vblank, so in order to guarantee atomicity with the all the other mmio register writes we need to evade both vblanks. Note that currently we don't add any vblank delay, so this is effectively a nop. But in the future when we start to program double buffered registers from the DSB we'll need to delay the pipe's vblank to provide the register programming "window2" for the DSB. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230606191504.18099-15-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
|
#
5ae0da3f |
|
06-Jun-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/dsb: Load LUTs using the DSB during vblank Loading LUTs with the DSB outside of vblank doesn't really work due to the palette anti-collision logic. Apparently the DSB register writes don't get stalled like CPU mmio writes do and instead we end up corrupting the LUT entries. Disabling the anti-collision logic would allow us to successfully load the LUT outside of vblank, but presumably that risks the LUT reads from the scanout (temporarily) getting corrupted data from the LUT instead. The anti-collision logic isn't active during vblank so that is when we can successfully load the LUT with the DSB. That is what we want to do anyway to avoid tearing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230606191504.18099-13-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
|
#
16a93594 |
|
15-Sep-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Implement transcoder LRR for TGL+ Implement low refresh rate (LRR) where we change the vblank length by hand as requested, but otherwise keep the timing generator running in non-VRR mode (ie. fixed refresh rate). The panel itself must support VRR for this to work, and only TGL+ has the double buffred TRANS_VTOTAL.VTOTAL that we need to make the switch properly. The double buffer latching happens at the start of transcoders undelayed vblank. The other thing that we change is TRANS_VBLANK.VBLANK_END but the hardware entirely ignores that in DP mode. But I decided to keep writing it anyway just to avoid more special cases in readout/state check. v2: Document that TRANS_VBLANK.VBLANK_END is ignored by the hardware v3: Reconcile with VRR fastset Adjust update_lrr flag behaviour Make sure timings stay within VRR range v4: Fix up update_m_n vs. update_lrr rebase fail (Manasi) Drop DOUBLE_BUFFER_VACTIVE define as it's not needed (Manasi) TODO: Hook LRR into the automatic DRRS downclocking stuff? Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230915103800.14218-1-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
|
#
26f03ef8 |
|
01-Sep-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Assert that VRR is off during vblank evasion if necessary Whenever we change the actual transcoder timings (clock via seamless M/N, full modeset, (or soon) vtotal via LRR) we want the timing generator to be in non-VRR during the commit. Warn if we forgot to turn VRR off prior to vblank evasion. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-12-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
|
#
825edc8b |
|
01-Sep-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Adjust seamless_m_n flag behaviour Make the seamless_m_n flag more like the update_pipe fastset flag, ie. the flag will only be set if we need to do the seamless M/N update, and in all other cases the flag is cleared. Also rename the flag to update_m_n to make it more clear it's similar to update_pipe. I believe special casing seamless_m_n like this makes sense as it also affects eg. vblank evasion. We can potentially avoid some vblank evasion tricks, simplify some checks, and hopefully will help with the VRR vs. M/N mess. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-6-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
|
#
691dec86 |
|
01-Sep-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Enable VRR later during fastsets In order to reconcile seamless M/N updates with VRR we'll need to defer the fastset VRR enable to happen after the seamless M/N update (which happens during the vblank evade critical section). So just push the VRR enable to be the last thing during the update. This will also affect the vblank evasion as the transcoder will now still be running with the old VRR state during the vblank evasion. So just grab the timings always from the old crtc state during any non-modeset commit, and also grab the current state of VRR from the active timings (as we disable VRR before vblank evasion during fastsets). This also fixes vblank evasion for seamless M/N updates as we now properly account for the fact that the M/N update happens after vblank evasion. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-5-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
|
#
f4b0cece |
|
01-Sep-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Extract intel_crtc_vblank_evade_scanlines() Pull the vblank evasion scanline calculations into their own helper to declutter intel_pipe_update_start() a bit. Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-4-ville.syrjala@linux.intel.com Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
|
#
09f390d4 |
|
01-Sep-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Change intel_pipe_update_{start,end}() calling convention We'll need to also look at the old crtc state in intel_pipe_update_start() so change the calling convention to just plumb in the full atomic state instead. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-3-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
|
#
f895e3db |
|
01-Sep-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Move psr unlock out from the pipe update critical section Do the PSR unlock after the vblank evade critcal section is fully over, not before. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-2-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
|
#
18e0deee |
|
23-May-2023 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/display: Move display runtime info to display structure Move the runtime info specific to display into display-specific structures as has already been done with the constant display info. v2: - Rename __runtime to __runtime_defaults for more clarity on the purpose. (Andrzej) - Move introduction of DISPLAY_INFO() to previous patch. (Andrzej) - Drop NO_DISPLAY macro. (Andrzej) v3: - Use "{}" instead of "{ 0 }" for empty struct init. (Jani) Cc: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230523195609.73627-4-matthew.d.roper@intel.com
|
#
2b874a02 |
|
15-May-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: split out display irq handling Split (non-hotplug) display irq handling out of i915_irq.[ch] into display/intel_display_irq.[ch]. v3: - Preserve [I915_MAX_PIPES] harder (kernel test robot) v2: - Rebase - Preserve [I915_MAX_PIPES] in functions (kernel test robot) Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230515101738.2399816-3-jani.nikula@intel.com
|
#
6b9bd7c3 |
|
12-May-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/display: add i915 parameter to I915_STATE_WARN() Add i915 parameter to I915_STATE_WARN() and use device based logging. Done using cocci + hand edited where there was no i915 local variable ready. v2: avoid null deref in verify_connector_state() Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230512181658.1735594-1-jani.nikula@intel.com
|
#
fe735c34 |
|
12-May-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/crtc: replace I915_STATE_WARN_ON() with I915_STATE_WARN() Describe the assertion better. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230512110444.1448231-2-jani.nikula@intel.com
|
#
435db526 |
|
04-Apr-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Evade transcoder's vblank when doing seamless M/N changes The transcoder M/N values are double buffered on the transcoder's undelayed vblank. So when doing seamless M/N fastsets we need to evade also that. Note that currently the pipe's delayed vblank == transcoder's undelayed vblank, so this is still a nop change. But in the future when we may have to delay the pipe's vblank to create a register programming window ("window2") for the DSB. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230404175431.23064-2-ville.syrjala@linux.intel.com Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com
|
#
ecaeecea |
|
20-Mar-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/vrr: Tell intel_crtc_update_active_timings() about VRR explicitly In order to move VRR enable/disable to a place where it's also applicable to fastsets we need to be prepared to configure the pipe into non-VRR mode initially, and then later switch to VRR mode. To that end allow the active timings to be configured in non-VRR mode temporarily even when the crtc_state says we're going to be using VRR. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230320203352.19515-5-ville.syrjala@linux.intel.com Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
|
#
014f0515 |
|
20-Mar-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/debugfs: switch crtc debugfs to struct intel_crtc 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: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230320124429.786985-1-jani.nikula@intel.com
|
#
8cb1f95c |
|
10-Mar-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Update vblank timestamping stuff on seamless M/N change 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: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Fixes: e6f29923c048 ("drm/i915: Allow M/N change during fastset on bdw+") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230310235828.17439-1-ville.syrjala@linux.intel.com
|
#
66560f33 |
|
25-Jan-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Mark FIFO underrun disabled earlier At least on some platforms (tested on ctg) the way vgacon does screen blanking seems to flag constant FIFO underruns, which means we have to be prepared for them while the driver is loading. Currently there is a time window between drm_crtc_init() and intel_sanitize_fifo_underrun_reporting() during which FIFO underrun reporting is in fact marked as enabled. Thus we may end up mistakenly detecting these bogus underruns during driver init. Close the race by marking FIFO underrun reporting as disabled prior to even registering the crtc. intel_sanitize_fifo_underrun_reporting()/etc. will re-enable it later if needed. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125185234.21599-2-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
|
#
59ad01c7 |
|
10-Mar-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Update vblank timestamping stuff on seamless M/N change 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: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Fixes: e6f29923c048 ("drm/i915: Allow M/N change during fastset on bdw+") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230310235828.17439-1-ville.syrjala@linux.intel.com (cherry picked from commit 8cb1f95cca68421b08333175719fdd3615372ca8) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
62fe4515 |
|
16-Jan-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: split out vblank/scanline code to intel_vblank.[ch] The vblank/scanline code is fairly isolated in i915_irq.c. Split it out to new intel_vblank.[ch]. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3e3e9016f5135dccae5110c291ba048567622e7a.1673873708.git.jani.nikula@intel.com
|
#
f5e674e9 |
|
21-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce intel_crtc_needs_color_update() Add a common helper to answer the question "do we need to update color management stuff?". 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/20221021162442.27283-5-ville.syrjala@linux.intel.com
|
#
52a90349 |
|
21-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce intel_crtc_needs_fastset() Replace the somewhat obscure crtc_state.update_pipe checks with a more descriptive thing. Also nicely matches the intel_crtc_needs_modeset() counterpart for full modesets. v2: Handle one more case in the fbc code Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221021162442.27283-2-ville.syrjala@linux.intel.com
|
#
a2b1d9ec |
|
04-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Clean up some namespacing Rename a few functions from intel_crtc_foo_init() to intel_foo_crtc_init() so that the namespaec clearly indicates what feature/file we're talking about. I left out intel_crtc_crc_init() because the whole crc stuff uses intel_crtc_ as its namespace currently. Suggested-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/20221004150929.23910-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
064751a6 |
|
29-Sep-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Split up intel_color_init() intel_color_init() does both device level and crtc level stuff. Split it up accordingly. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220929071521.26612-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
254e5e88 |
|
20-Jul-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm: Remove unnecessary include statements of drm_plane_helper.h Remove the include statement for drm_plane_helper.h from all the files that don't need it. Althogh the header file is almost empty, many drivers include it somewhere. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220720083058.15371-5-tzimmermann@suse.de
|
#
ce21211b |
|
06-Apr-2022 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915/display: Fix warnings about PSR lock not held Commit 3b6f409547fb ("drm/i915/display/psr: Lock and unlock PSR around pipe updates") did not took into account async flips with PSR1 and PSR2 HW tracking, causing PSR lock not be held and causing warnings when intel_psr2_program_trans_man_trk_ctl() is executed. So here taking the PSR lock before the earlier return in intel_pipe_update_start/end(). Cc: Jouni Högander <jouni.hogander@intel.com> Reported-by: Imre Deak <imre.deak@intel.com> Fixes: 3b6f409547fb ("drm/i915/display/psr: Lock and unlock PSR around pipe updates") 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/20220406210540.493610-1-jose.souza@intel.com
|
#
3b6f4095 |
|
05-Apr-2022 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915/display/psr: Lock and unlock PSR around pipe updates Frontbuffer rendering and page flips can race with each other and this can potentialy cause issues with PSR2 selective fetch. And because pipe/crtc updates are time sentive we can't grab the PSR lock after intel_pipe_update_start() and before intel_pipe_update_end(). So here adding the lock and unlock functions and calls, the proper PSR2 selective fetch handling will come in a separated patch. v2: - fixed new functions documentation Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220405155344.47219-2-jose.souza@intel.com
|
#
851f15fe |
|
11-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Stash DRRS state under intel_crtc Ger rid of one more ugly crtc->config usage by storing the DRRS state under intel_crtc. intel_drrs_enable() copies what it needs from the crtc state, after which DRRS can be blissfully ignorant of anything going on around it. This also lets multiple pipes do DRRS simultanously and entirely independently. v2: Split out some stuff (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220311172428.14685-13-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
2e084371 |
|
13-Feb-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix the async flip wm0/ddb optimization 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>
|
#
5c8107dc |
|
13-Feb-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix the async flip wm0/ddb optimization 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>
|
#
80dfdeb7 |
|
04-Jan-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: stop including i915_irq.h from i915_drv.h Only include i915_irq.h where actually needed. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220105102131.988791-1-jani.nikula@intel.com
|
#
7d41745a |
|
03-Dec-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: s/intel_get_first_crtc/intel_first_crtc/ Since we got rid of the "_get_" from intel_get_crtc_for_pipe() let's do the same for intel_get_first_crtc() for consistency. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211203112029.1057-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
927167f3 |
|
03-Dec-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Relocate intel_crtc_for_plane() Move intel_crtc_for_plane() next to its only user. No one else should ever use this. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211203112029.1057-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
cbb8a795 |
|
03-Dec-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Nuke {pipe,plane}_to_crtc_mapping[] These plane/pipe->crtc mapping arrays are rather pointless. Get rid of them and just iterate the lists instead. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211203112029.1057-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
fd2b94a5 |
|
08-Dec-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/trace: split out display trace to a separate file Add display/intel_display_trace.[ch] for defining display tracepoints. The main goal is to reduce cross-includes between gem and display. It would be possible split up tracing even further, but that would lead to more boilerplate. We end up having to include intel_crtc.h in a few places because it was pulled in implicitly via intel_de.h -> i915_trace.h -> intel_crtc.h, and that's no longer the case. There should be no changes to tracepoints. v3: - Rebase v2: - Define TRACE_INCLUDE_PATH relative to define_trace.h (Chris) - Remove useless comments (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7862ad764fbd0748d903c76bc632d3d277874e5b.1638961423.git.jani.nikula@intel.com
|
#
92e9624a |
|
01-Dec-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/crtc: un-inline some crtc functions and move to intel_crtc.[ch] Move a number of crtc/pipe related functions to intel_crtc.[ch], and un-inline to avoid looking into struct drm_i915_private guts in header files. 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/c0be2adc4a7f7e72a47e12a57f742aaa42b813e6.1638366969.git.jani.nikula@intel.com
|
#
617ed6c2 |
|
22-Nov-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dsi: split out icl_dsi.h Follow the convention of corresponding .h for .c. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211122111504.223248-4-jani.nikula@intel.com
|
#
0088d39b |
|
17-Nov-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Do vblank evasion correctly if vrr push has already been sent Let's adjust the vblank evasion to account for the case where a push has already been sent. In that case the vblank exit will start at vmin vblank start (as opposed to vmax vblank start when no push has been sent). This should minimize the effects of the tiny race between sampling the frame counter vs. intel_vrr_send_push() during the previous frame. This will also be required if we want to do mailbox style updates with vrr since then we'd definitely do multiple commits per frame. Currently mailbox updates are only used by the legacy cursor, but we don't do vrr push for those. Cc: 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/20211117183103.27418-2-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
|
#
4765d061 |
|
17-Nov-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Move vrr push after the frame counter sampling again Moving the vrr push to happen before sampling the frame counter was wrong. If we are already in vblank when the push is sent the vblank exit will start immediately which causes the sampled frame counter to correspond to the next frame instead of the current frame. So put things back into the original order (except we should keep the vrr push within the irq disable section to avoid pointless irq related delays here). We'll just have to accept the tiny race that exists between sampling the frame counter vs. vrr push. And let's at least document said race properly in a comment. I suppose we could try to minimize the race by sampling the frame counter just before sending the push, but that would require changing drm_crtc_arm_vblank_event() to accept a caller provided vblank counter value, so leave it be for now. Another thing we could do is change the vblank evasion to account for the case where a push was already sent. That would anyway be required for mailbox style updates. Currently mailbox updates are only used by the legacy cursor, but we don't do a vrr push for those. Cc: Manasi Navare <manasi.d.navare@intel.com> Fixes: 6f9976bd1310 ("drm/i915: Do vrr push before sampling the frame counter") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211117183103.27418-1-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
|
#
2bbc6fca |
|
20-Oct-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use vblank workers for gamma updates The pipe gamma registers are single buffered so they should only be updated during the vblank to avoid screen tearing. In fact they really should only be updated between start of vblank and frame start because that is the only time the pipe is guaranteed to be empty. Already at frame start the pipe begins to fill up with data for the next frame. Unfortunately frame start happens ~1 scanline after the start of vblank which in practice doesn't always leave us enough time to finish the gamma update in time (gamma LUTs can be several KiB of data we have to bash into the registers). However we must try our best and so we'll add a vblank work for each pipe from where we can do the gamma update. Additionally we could consider pushing frame start forward to the max of ~4 scanlines after start of vblank. But not sure that's exactly a validated configuration. As it stands the ~100 first pixels tend to make it through with the old gamma values. Even though the vblank worker is running on a high prority thread we still have to contend with C-states. If the CPU happens be in a deep C-state when the vblank interrupt arrives even the irq handler gets delayed massively (I've observed dozens of scanlines worth of latency). To avoid that problem we'll use the qos mechanism to keep the CPU awake while the vblank work is scheduled. With all this hooked up we can finally enjoy near atomic gamma updates. It even works across several pipes from the same atomic commit which previously was a total fail because we did the gamma updates for each pipe serially after waiting for all pipes to have latched the double buffered registers. In the future the DSB should take over this responsibility which will hopefully avoid some of these issues. Kudos to Lyude for finishing the actual vblank workers. Works like the proverbial train toilet. v2: Add missing intel_atomic_state fwd declaration v3: Clean up properly when not scheduling the worker v4: Clean up the rest and add tracepoints v5: s/intel_wait_for_vblank_works/intel_wait_for_vblank_workers/ (Jani,Uma) CC: Lyude Paul <lyude@redhat.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020223339.669-4-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
|
#
6f9976bd |
|
20-Oct-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Do vrr push before sampling the frame counter Do the vrr push before we sample the frame counter to know when the commit has been latched. Doing these in the wrong order could lead us to complete the flip before it has actually happened. Cc: 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/20211020223339.669-3-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
|
#
89a34600 |
|
28-Jul-2021 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915/display: remove explicit CNL handling from intel_crtc.c No need for special CNL handling as there is no real platform with that configuration. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-6-lucas.demarchi@intel.com
|
#
f15f01a7 |
|
09-Jun-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: s/intel_crtc/crtc/ Clear out the straggler 'intel_crtc' variables. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210609085632.22026-7-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
93e7e61e |
|
12-Apr-2021 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915/display: rename display version macros While converting the rest of the driver to use GRAPHICS_VER() and MEDIA_VER(), following what was done for display, some discussions went back on what we did for display: 1) Why is the == comparison special that deserves a separate macro instead of just getting the version and comparing directly like is done for >, >=, <=? 2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for brevity. If we remove the current users of IS_DISPLAY_VER(), we could actually repurpose it for a range check With (1) there could be an advantage if we used gen_mask since multiple conditionals be combined by the compiler in a single and instruction and check the result. However a) INTEL_GEN() doesn't use the mask since it would make the code bigger everywhere else and b) in the cases it made sense, it also made sense to convert to the _RANGE() variant. So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER() users to use == and != operators. Aside from the definition changes, this was done by the following semantic patch: @@ expression dev_priv, E1; @@ - !IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) != E1 @@ expression dev_priv, E1; @@ - IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) == E1 @@ expression dev_priv, from, until; @@ - IS_DISPLAY_RANGE(dev_priv, from, until) + IS_DISPLAY_VER(dev_priv, from, until) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> [Jani: Minor conflict resolve while applying.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-4-lucas.demarchi@intel.com
|
#
2b5a4562 |
|
22-Mar-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/display: Simplify GLK display version tests GLK has always been a bit of a special case since it reports INTEL_GEN() as 9, but has version 10 display IP. Now we can properly represent the display version as 10 and simplify the display generation tests throughout the display code. Aside from manually adding the version to the glk_info structure, the rest of this patch is generated with a Coccinelle semantic patch. Note that we also need to switch any code that matches gen10 today but *not* GLK to be CNL-specific: @@ expression dev_priv; @@ - DISPLAY_VER(dev_priv) > 9 + DISPLAY_VER(dev_priv) >= 10 @@ expression dev_priv, E; @@ ( - DISPLAY_VER(dev_priv) >= 10 && E + (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && E | - DISPLAY_VER(dev_priv) >= 10 + DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) | - IS_DISPLAY_RANGE(dev_priv, 10, E) + IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_CANNONLAKE(dev_priv) ) @@ expression dev_priv, E, E2; @@ ( - (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 10) | - E || IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv) + E || IS_DISPLAY_VER(dev_priv, 10) | - (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 10) | - IS_GEMINILAKE(dev_priv) || E || IS_CANNONLAKE(dev_priv) + E || IS_DISPLAY_VER(dev_priv, 10) | - E || IS_GEMINILAKE(dev_priv) || E2 || IS_CANNONLAKE(dev_priv) + E || E2 || IS_DISPLAY_VER(dev_priv, 10) | - (IS_DISPLAY_VER(dev_priv, 10) || IS_GEMINILAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 10) | - (IS_GEMINILAKE(dev_priv) || IS_DISPLAY_VER(dev_priv, 10)) + IS_DISPLAY_VER(dev_priv, 10) ) @@ expression dev_priv; @@ - (IS_DISPLAY_VER(dev_priv, 9) && !IS_GEMINILAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 9) @@ expression dev_priv; @@ ( - !(DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)) + DISPLAY_VER(dev_priv) < 10 | - (DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)) + DISPLAY_VER(dev_priv) >= 10 ) @@ expression dev_priv, E; @@ - E || DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10) + E || DISPLAY_VER(dev_priv) >= 10 @@ expression dev_priv, E; @@ - (IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_DISPLAY_VER(dev_priv, 10)) + IS_DISPLAY_RANGE(dev_priv, 10, E) @@ expression dev_priv; @@ ( - DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) || IS_GEN9_LP(dev_priv) + DISPLAY_VER(dev_priv) >= 10 || IS_GEN9_LP(dev_priv) | - IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) + IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 10 ) @@ expression dev_priv, E; @@ - !(DISPLAY_VER(dev_priv) >= E) + DISPLAY_VER(dev_priv) < E v2: - Convert gen10 conditions that don't include GLK into CNL conditions. (Ville) v3: - Rework coccinelle rules so that "ver>=10" turns into "ver>=11||is_cnl." (Ville) v3.1: - Manually re-add the ".display.version = 10" to glk_info after regenerating patch via Coccinelle. v4: - Also apply cocci rules to intel_pm.c and i915_irq.c! (CI) Cc: Ville Syrjälä <ville.syrjala@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210322233840.4056851-1-matthew.d.roper@intel.com
|
#
005e9537 |
|
19-Mar-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/display: Eliminate most usage of INTEL_GEN() Use Coccinelle to convert most of the usage of INTEL_GEN() and IS_GEN() in the display code to use DISPLAY_VER() comparisons instead. The following semantic patch was used: @@ expression dev_priv, E; @@ - INTEL_GEN(dev_priv) == E + IS_DISPLAY_VER(dev_priv, E) @@ expression dev_priv; @@ - INTEL_GEN(dev_priv) + DISPLAY_VER(dev_priv) @@ expression dev_priv; expression E; @@ - IS_GEN(dev_priv, E) + IS_DISPLAY_VER(dev_priv, E) @@ expression dev_priv; expression from, until; @@ - IS_GEN_RANGE(dev_priv, from, until) + IS_DISPLAY_RANGE(dev_priv, from, until) There are still some display-related uses of INTEL_GEN() in intel_pm.c (watermark code) and i915_irq.c. Those will be updated separately. v2: - Use new IS_DISPLAY_RANGE and IS_DISPLAY_VER helpers. (Jani) 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/20210320044245.3920043-4-matthew.d.roper@intel.com
|
#
603a945e |
|
04-Mar-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix DSI TE max_vblank_count handling commit 33267703df15 ("drm/i915/dsi: Enable software vblank counter") claims to get the mode_flags from the crtc_state, but in fact does not. Fix it to do it right. Cc: Vandita Kulkarni <vandita.kulkarni@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/20210304170421.10901-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
9bb475cd |
|
04-Mar-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Don't try to query the frame counter for disabled pipes For platforms/outputs without hardware frame counters we can't call drm_crtc_accurate_vblank_count() when the vblank support is disabled or we just get a WARN due to the crtc timings (vblank->hwmode) being considered invalid. Note that until the pipe in question has been enabled and drm_crtc_set_max_vblank_count() has been called on it we would also take this path on platforms which have a working frame counter. So getting the WARN is rather likely on any platform unless you always boot with lots of displays plugged in. Also even on hardware with a working frame counter we may not be able to read the actual frame counter register on disabled pipes due the relevant power well being disabled. Ie. would just result in the unclaimed reg spew. So let's just avoid all this an directly report zero in case the pipe is disabled. Reported-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Tested-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210304170421.10901-3-ville.syrjala@linux.intel.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
#
e43539f8 |
|
04-Mar-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Move pipe enable/disable tracepoints to intel_crtc_vblank_{on,off}() On platforms/outputs without a working frame counter we rely on the vblank code to cook up the frame counter from the timestamps. That requires that vblank support is enabled. Thus we need to move the pipe enable/disable tracepoints to the other side of the drm_vblank_{on,off}() calls. There shouldn't really be much happening between these old and new call sites so the tracepoints should still provide reasonable data. The alternative would be to give up on having the frame counter values in the trace which would render the tracepoints more or less pointless. v2: Missed one case in intel_ddi_post_disable() Drop the now useless i915_trace.h includes Reported-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Tested-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210304170421.10901-2-ville.syrjala@linux.intel.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
#
7e07c68f |
|
05-Feb-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Nuke INTEL_OUTPUT_FORMAT_INVALID We tend to use output_format!=RGB as a shorthand for YCbCr, but this fails if we have a disabled crtc where output_format==INVALID. We're now getting some fail from intel_color_check() when we have: hw.enable==false hw.ctm!=NULL output_format==INVALID Let's avoid that by throwing INTEL_OUTPUT_FORMAT_INVALID to the dumpster, and thus everything defaults to RGB when the crtc is disabled. This does beg the deeper question of how much of the state should we in fact be validating when hw/uapi.enable==false. And should we even be doing the uapi->hw copy when uapi.enable==false? So far I've not been able to come up with satisfactory answers for myself, so I'm putting it off for the moment. Cc: Lee Shawn C <shawn.c.lee@intel.com> Fixes: 0aa5c3835c8a ("drm/i915: support two CSC module on gen11 and later") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2964 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205202322.27608-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
#
d471008b |
|
05-Feb-2021 |
Dave Airlie <airlied@redhat.com> |
drm/i915: move pipe update code into crtc. (v2) Daniel suggested this should move here. v2: move vrr code. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/738c7aaeb63c7d2357ddd932f18787ec8a3cefeb.1612536383.git.jani.nikula@intel.com
|
#
46d12f91 |
|
05-Feb-2021 |
Dave Airlie <airlied@redhat.com> |
drm/i915: migrate skl planes code new file (v5) Rework the plane init calls to do the gen test one level higher. Rework some of the plane helpers so they can live in new file, there is still some scope to clean up the plane/fb interactions later. v2: drop atomic code back, rename file to Ville suggestions, add header file. v3: move scaler bits back v4: drop wrong new includes (Ville) v5: integrate the ccs gen12 changes v6: fix unrelated code movement (Ville) Signed-off-by: Dave Airlie <airlied@redhat.com> [Jani: fixed up sparse warnings.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4e88a5c6b9ab3b93cc2b6c7d78c26ae86f6abbd0.1612536383.git.jani.nikula@intel.com
|
#
ed428ffc |
|
05-Feb-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Nuke INTEL_OUTPUT_FORMAT_INVALID We tend to use output_format!=RGB as a shorthand for YCbCr, but this fails if we have a disabled crtc where output_format==INVALID. We're now getting some fail from intel_color_check() when we have: hw.enable==false hw.ctm!=NULL output_format==INVALID Let's avoid that by throwing INTEL_OUTPUT_FORMAT_INVALID to the dumpster, and thus everything defaults to RGB when the crtc is disabled. This does beg the deeper question of how much of the state should we in fact be validating when hw/uapi.enable==false. And should we even be doing the uapi->hw copy when uapi.enable==false? So far I've not been able to come up with satisfactory answers for myself, so I'm putting it off for the moment. Cc: Lee Shawn C <shawn.c.lee@intel.com> Fixes: 0aa5c3835c8a ("drm/i915: support two CSC module on gen11 and later") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2964 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205202322.27608-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (cherry picked from commit 7e07c68f06a248441b485249de4c4115cba262cc) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
fbf756c3 |
|
14-Jan-2021 |
Dave Airlie <airlied@redhat.com> |
drm/i915: refactor some crtc code out of intel display. (v2) There may be more crtc code that can be pulled out, but this is a good start. v2: move plane before this. Signed-off-by: Dave Airlie <airlied@redhat.com> [Jani: cleaned up intel_crtc.h a bit.] 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/eacbe964f90d189c5940c12af5e09091b37a19c3.1610622609.git.jani.nikula@intel.com
|