Skip to content
  1. Feb 17, 2022
  3. Feb 16, 2022
  5. Feb 15, 2022
  7. Feb 14, 2022
  9. Feb 12, 2022
    • Ville Syrjälä's avatar
      drm/i915: Nuke some dead code · 02cae05e
      Ville Syrjälä authored 
      

Remove all the dead code from icl_ddi_bigjoiner_pre_enable().

Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220203183823.22890-6-ville.syrjala@linux.intel.com
Reviewed-by: default avatarManasi Navare <manasi.d.navare@intel.com>
      02cae05e
    • Ville Syrjälä's avatar
      drm/i915: Clean up the bigjoiner state copy logic · aeb47df3
      Ville Syrjälä authored 
      

Currently the bigjoiner state copy logic is kind of
a byzantine mess.

Clean it up to operate in the following manner during a full
modeset:
1) master uapi -> hw state copy
2) master hw -> slave hw state copy

And during a non-modeset update we do:
1) master uapi -> hw state light copy
2) master hw -> slave hw state light copy

I think that is now easier to reason about since we never do
any kind of master uapi -> slave hw state copy short circuit
that could happen previously.

Obviously this does now depend on the master uapi->hw copy
always happening before the master hw -> slave hw copy, but
that is guaranteed by the fact that we always add both crtcs
to the state early, the crtcs are registered in pipe
order (so the compute_config loop happens in pipe order),
and the hardware requires the master pipe has to be lower
than the slave pipe as well. And for good measure we shall
add a check+WARN for this before doing the bigjoiner crtc
assignment.

v2: Fix uapi.ctm vs. hw.ctm copy-paste fail

Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220204072049.1610-1-ville.syrjala@linux.intel.com
Reviewed-by: default avatarManasi Navare <manasi.d.navare@intel.com>
      aeb47df3
    • Ville Syrjälä's avatar
      drm/i915: Remove weird code from intel_atomic_check_bigjoiner() · 2b1466ea
      Ville Syrjälä authored 
      

There's some weird junk in intel_atomic_check_bigjoiner()
that's trying to look at the old crtc state's bigjoiner
usage for some reason. That code is totally unnecessary,
and maybe even actively harmful. Not entirely sure which
since it's such a mess that I can't actually wrap my brain
around what it ends up doing.

Either way, thanks to intel_bigjoiner_add_affected_crtcs()
all of the old bigjoiner crtcs are guaranteed to be in the
state already if any one of them is in the state. Also if
any one of those crtcs got flagged for a modeset, then all
of them will have been flagged, and the bigjoiner links
will have been detached via kill_bigjoiner_slave().

So there is no need to look examing any old bigjoiner
usage in intel_atomic_check_bigjoiner(). All we have to care
about is whether bigjoiner is needed for the new state,
and whether we can get the slave crtc we need.

Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220203183823.22890-4-ville.syrjala@linux.intel.com
Reviewed-by: default avatarManasi Navare <manasi.d.navare@intel.com>
      2b1466ea
    • Ville Syrjälä's avatar
      drm/i915: Fix bigjoiner state copy fails · 6148f365
      Ville Syrjälä authored 
      

We seem to be missing a few things from the bigjoiner state copy.
Namely hw.mode isn't getting copied (which probably causes PIPESRC
to be misconfigured), CTM/LUTs aren't getting copied (which could
cause the pipe to produced incorrect output), and we also forgot
to copy over the color_mgmt_changed flag so potentially we fail
to do the actual CTM/LUT programming (assuming we aren't doing
a full modeset or fastset). Fix it all.

v2: Fix uapi.ctm vs. hw.ctm copy-paste fail

Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220204072009.1546-1-ville.syrjala@linux.intel.com
Reviewed-by: default avatarManasi Navare <manasi.d.navare@intel.com>
      6148f365
    • Ville Syrjälä's avatar
      drm/i915: Flag crtc scaling_filter changes as modeset · 1a7a8d93
      Ville Syrjälä authored 
      

The core doesn't flag scaling_filter prop changes as needing
a modeset. That doesn't work for us since we only reprogram the
pipe scaler during full modesets and fastsets. So we need to
flag the prop change as a modeset ourselves. Assuming nothing else
has changed the operation will get promoted (demoted?) to a fastset
later.

Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220203183823.22890-2-ville.syrjala@linux.intel.com
Reviewed-by: default avatarManasi Navare <manasi.d.navare@intel.com>
      1a7a8d93
    • Ville Syrjälä's avatar
      drm/i915/dp: Reuse intel_hdmi_tmds_clock() · 0c63fd3d
      Ville Syrjälä authored 
      

Reuse intel_hdmi_tmds_clock() for DP->HDMI TMDS clock calculations.

Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211015133921.4609-9-ville.syrjala@linux.intel.com
Reviewed-by: default avatarAnkit Nautiyal <ankit.k.nautiyal@intel.com>
      0c63fd3d
    • Ville Syrjälä's avatar
      drm/i915/hdmi: Simplify intel_hdmi_mode_clock_valid() · 5d488786
      Ville Syrjälä authored 
      

Just loop over the possible bpc values instead of
using an ugly if construct.

A slight change in behaviour is that we now call
intel_hdmi_{source,sink}_bpc_possible() even for 8bpc,
but that is fine since 8bpc is always supported.

Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211015133921.4609-8-ville.syrjala@linux.intel.com
Reviewed-by: default avatarAnkit Nautiyal <ankit.k.nautiyal@intel.com>
      5d488786
  11. Feb 11, 2022