drm/i915/dp: Rework pipe joiner logic in mode_valid

Currently in intel_dp_mode_valid(), we compute the number of joined pipes
required before deciding whether DSC is needed. This ordering prevents us
from accounting for DSC-related overhead when determining pipe
requirements.

It is not possible to first decide whether DSC is needed and then compute
the required number of joined pipes, because the two depend on each other:

 - DSC need is a function of the pipe count (e.g., 4‑pipe always requires
   DSC; 2‑pipe may require it if uncompressed joiner is unavailable).

 - Whether a given pipe‑join configuration is sufficient depends on
   effective bandwidth, which itself changes when DSC is used.

As a result, the only correct approach is to iterate candidate pipe counts.

So, refactor the logic to start with a single pipe and incrementally try
additional pipes only if needed. While DSC overhead is not yet computed
here, this restructuring prepares the code to support that in a follow-up
changes.

If a forced joiner configuration is present, we just check for that
configuration. If it fails, we bailout and return instead of trying with
other joiner configurations.

v2:
 - Iterate over number of pipes to be joined instead of joiner
   candidates. (Jani)
 - Document the rationale of iterating over number of joined pipes.
   (Imre)
v3:
 - In case the force joiner configuration doesn't work, do not fallback
   to the normal routine, bailout instead of trying other joiner
   configurations. (Imre)
v4:
 - Use num_joined_pipes instead of num_pipes. (Imre)
 - Inititialize status before the loops starts. (Imre)
v5:
 - Fix status handling by setting MODE_CLOCK_HIGH on DSC/rate failures.
   (Imre)

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260202103731.357416-5-ankit.k.nautiyal@intel.com

0 files changed, 0 insertions, 0 deletions