There is no support for two pipes one transcoder for PSR and if we had
that the current code should not use cpu_transcoder.
Also I can't see a scenario where crtc_state->enable_psr2_sel_fetch is
set and PSR is not enabled and if by a bug it happens PSR HW will just
ignore any value in set in PSR2_MAN_TRK_CTL.
So dropping all the rest and keeping the same behavior that we have
with intel_psr2_program_plane_sel_fetch().
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209181439.215104-2-jose.souza@intel.com
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: 0aa5c3835c ("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>
Instead of every new platform having yet another masive
copy of the whole PLL sanitation code, let's just reuse the
.disable_clock() hook for this purpose. We do need to plug
this into the ICL+ DSI code for that, but fortunately it
already has a suitable function we can use.
We do lose the debug message though on account of not bothering
to check if the clock is actually enabled or not before turning
it off. We could introduce yet another vfunc to query the current
state, but not sure it's worth the hassle?
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-14-ville.syrjala@linux.intel.com
For ICL+ we have several styles of clock routing for DDIs:
1) TC DDI + TC PHY
-> needs DDI_CLK_SEL==MG/TBT part form intel_ddi_clk_{select,disable}()
and ICL_DPCLKA_CFGCR0_TC_CLK_OFF part form icl_{map,unmap}_plls_to_ports()
2) ICL/TGL combo DDI + combo PHY
-> just need the stuff from icl_{map,unmap}_plls_to_ports()
3) JSL/EHL TC DDI + combo PHY
-> needs DDI_CLK_SEL==MG part from intel_ddi_clk_{select,disable}() and
the full combo style clock selection from icl_{map,unmap}_plls_to_ports()
4) ADLS/RKL
-> these use both TC and combo DDIs with combo PHYs, however they
always use the full combo style clock selection as per
icl_{map,unmap}_plls_to_ports() and do not use DDI_CLK_SEL at all,
thus get treated the same as 2)
We extract all that from the current mess in the following way:
1) icl_ddi_tc_{enable,disable}_clock()
2) icl_ddi_combo_{enable,disable}_clock()
3) jsl_ddi_tc_{enable,disable}_clock()
4) for now we reuse icl_ddi_combo_{enable,disable}_clock() here
v2: s/dev_priv/i915/ (Lucas)
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-8-ville.syrjala@linux.intel.com
Next, let's start introducing the HPD pin mappings for Intel's new gen9_bc
platform in order to make hotplugging display connectors work. Since
gen9_bc is just a TGP PCH along with a CML CPU, except with the same HPD
mappings as ICL, we simply add a skl_hpd_pin function that is shared
between gen9 and gen9_bc which handles both the traditional gen9 HPD pin
mappings and the Icelake HPD pin mappings that gen9_bc uses.
Changes since v4:
* Split this into its own commit
* Introduce skl_hpd_pin() like vsyrjala suggested and use that instead of
sticking our HPD pin mappings in TGP code
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
[originally from Tejas's work]
Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209212832.1401815-4-lyude@redhat.com
ilk+ planes get notably unhappy when the plane x+w exceeds
the stride. This wasn't a problem previously because we
always aligned SURF to the closest tile boundary so the
x offset never got particularly large. But now with async
flips we have to align to 256KiB instead and thus this
becomes a real issue.
On ilk/snb/ivb it looks like the accesses just wrap
early to the next tile row when scanout goes past the
SURF+n*stride boundary, hsw/bdw suffer more heavily and
start to underrun constantly. i965/g4x appear to be immune.
vlv/chv I've not yet checked.
Let's borrow another trick from the skl+ code and search
backwards for a better SURF offset in the hopes of getting the
x offset below the limit. IIRC when I ran into a similar issue
on skl years ago it was causing the hardware to fall over
pretty hard as well.
And let's be consistent and include i965/g4x in the check
as well, just in case I just got super lucky somehow when
I wasn't able to reproduce the issue. Not that it really
matters since we still use 4k SURF alignment for i965/g4x
anyway.
Fixes: 6ede6b0616 ("drm/i915: Implement async flips for vlv/chv")
Fixes: 4bb18054ad ("drm/i915: Implement async flip for ilk/snb")
Fixes: 2a636e240c ("drm/i915: Implement async flip for ivb/hsw")
Fixes: cda195f13a ("drm/i915: Implement async flips for bdw")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209021918.16234-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
It is a preliminary work for supporting multiple EDP PSR and
DP PanelReplay. And it refactors singleton PSR to Multi Transcoder
supportable PSR.
And this moves and renames the i915_psr structure of drm_i915_private's to
intel_dp's intel_psr structure.
It also causes changes in PSR interrupt handling routine for supporting
multiple transcoders. But it does not change the scenario and timing of
enabling and disabling PSR. And it not support multiple pipes with
a single transcoder PSR case yet.
v2: Fix indentation and add comments
v3: Remove Blank line
v4: Rebased
v5: Rebased and Addressed Anshuman's review comment.
- Move calling of intel_psr_init() to intel_dp_init_connector()
v6: Address Anshuman's review comments
- Remove wrong comments and add comments for a limit of supporting of
a single pipe PSR
v7: Update intel_psr_compute_config() for supporting multiple transcoder
PSR on BDW+
v8: Address Anshuman's review comments
- Replace DRM_DEBUG_KMS with drm_dbg_kms() / DRM_WARN with drm_warn()
v9: Fix commit message
v10: Rebased
v11: Address Jose's review comment.
- Reorder calling order of intel_psr2_program_trans_man_trk_ctl().
- In order to reduce changes keep the old name for drm_i915_private.
- Change restrictions of multiple instances of PSR.
v12: Address Jose's review comment.
- Change the calling of intel_psr2_program_trans_man_trk_ctl() into
commit_pipe_config().
- Change a checking order of CAN_PSR() and connector_status to original
on i915_psr_sink_status_show().
- Drop unneeded intel_dp_update_pipe() function.
- In order to wait a specific encoder which belong to crtc_state on
intel_psr_wait_for_idle(), add checking of encoder.
- Add an whitespace to comments.
v13: Rebased and Address Jose's review comment.
- Add and use for_each_intel_psr_enabled_encoder() macro.
- In order to use correct frontbuffer_bit for each pipe,
fix intel_psr_invalidate() and intel_psr_flush().
- Remove redundant or unneeded codes.
- Update comments.
v14: Address Jose's review comment
- Add and use for_each_intel_encoder_can_psr() macro and
for_each_intel_encoder_mask_can_psr() macro.
- Add source_support member variable into intel_psr structure.
- Update CAN_PSR() macro that checks source_support.
- Move encoder's PSR availity check to psr_init() from
psr_compute_config().
- Remove redundant or unneeded codes.
v15: Remove wrong mutex lock/unlock of PSR from
intel_psr2_program_trans_man_trk_ctl()
Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210204134015.419036-1-gwan-gyeong.mun@intel.com
