Fix intel_dp_dsc_compute_config, previously timeslots parameter
was used in fact not as a timeslots, but more like a ratio
timeslots/64, which of course didn't have any effect for SST DSC,
but causes now issues for MST DSC.
Secondly we need to calculate pipe_bpp using intel_dp_dsc_compute_bpp
only for SST DSC case, while for MST case it has been calculated
earlier already with intel_dp_dsc_mst_compute_link_config.
Third we also were wrongly determining sink min bpp/max bpp, those
limites should be intersected with our limits to find common
acceptable bpp's, plus on top of that we should align those with
VESA bpps and only then calculate required timeslots amount.
Some MST hubs started to work only after third change was made.

v2: Make kernel test robot happy(claimed there was unitialzed use,
    while there is none)
v3: Rename intel_dp_dsc_nearest_vesa_bpp to intel_dp_dsc_nearest_valid_bpp
    (Manasi Navare)
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123100718.29130-1-stanislav.lisovskiy@intel.com

We might to use that function separately from intel_dp_dsc_compute_config
for DP DSC over MST case, because allocating bandwidth in that
case can be a bit more tricky. So in order to avoid code copy-pasta
lets extract this to separate function and reuse it for both SST
and MST cases.

v2: Removed multiple blank lines
v3: Rename intel_dp_dsc_nearest_vesa_bpp to intel_dp_dsc_nearest_valid_bpp
    to reflect its meaning more properly.
    (Manasi Navare)
Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123100551.29080-1-stanislav.lisovskiy@intel.com

Whenever we are not able to get enough timeslots
for required PBN, let's try to allocate those
using DSC, just same way as we do for SST.

v2: Removed intel_dp_mst_dsc_compute_config and refactored
    intel_dp_dsc_compute_config to support timeslots as a
    parameter(Ville Syrjälä)

v3: - Rebased
    - Added a debug to see that we at least try reserving
      VCPI slots using DSC, because currently its not visible
      from the logs, thus making debugging more tricky.
    - Moved timeslots to numerator, where it should be.

v4: - Call drm_dp_mst_atomic_check already during link
      config computation, because we need to know already
      by this moment if uncompressed amount of VCPI slots
      needed can fit, otherwise we need to use DSC.
      (thanks to Vinod Govindapillai for pointing this out)

v5: - Put pipe_config->bigjoiner_pipes back to original
      condition in intel_dp_dsc_compute_config
      (don't remember when I lost it)

v6: - Removed unnecessary drm_dp_mst_atomic_check as it is
      now always called in a newly introduced
      intel_dp_mst_find_vcpi_slots_for_bpp function
      (Vinod Govindapillai)
Reviewed-by: NVinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221101094222.22091-5-stanislav.lisovskiy@intel.com

We would be using almost same code to loop through bpps while calling
drm_dp_atomic_find_vcpi_slots - lets remove this duplication by
introducing a new function intel_dp_mst_find_vcpi_slots_for_bpp

v2: Fix pbn_div calculation - shouldn't matter if its DSC or not.
v3: FIx rebase conflict, constant_n no longer needed.
Reviewed-by: NVinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221101094222.22091-4-stanislav.lisovskiy@intel.com

We currently always exit that bpp loop because
drm_dp_atomic_find_vcpi_slots doesn't care if we actually
can fit those or not.
I think that wasn't the initial intention here, especially when
we keep trying with lower bpps, we are supposed to keep trying
until we actually find some _working_ configuration, which isn't the
case here.
So added that drm_dp_mst_check here, so that we can make sure
that try all the bpps before we fail.
Reviewed-by: NVinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221101094222.22091-3-stanislav.lisovskiy@intel.com

Turns out many of the files that need i915_reg.h get it implicitly via
{display/intel_de.h, gt/intel_context.h} -> i915_trace.h -> i915_irq.h
-> i915_reg.h. Since i915_trace.h doesn't actually need i915_irq.h,
makes sense to drop it, but that requires adding quite a few new
includes all over the place.

Prefer including i915_reg.h where needed instead of adding another
implicit include, because eventually we'll want to split up i915_reg.h
and only include the specific registers at each place.

Also some places actually needed i915_irq.h too.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6e78a2e0ac1bffaf5af3b5ccc21dff05e6518cef.1668008071.git.jani.nikula@intel.com

Move the DP MST connector property setup into its own function
so it's not spread all over intel_dp_add_mst_connector().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220912111814.17466-9-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

In Display version 14, Transcoder Chicken Registers have updated address.
This patch performs checks to use the right register when required.

v2: Omit display version check in i915_reg.h(Jani)
v3:
 - Remove extra whitespace introduced
 - Fix reg definitions for MTL_CHICKEN_TRANS(MattR)

Bspec: 34387, 50054
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NMadhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com>
Signed-off-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220913183341.908028-6-radhakrishna.sripada@intel.com

Windows/BIOS always uses fixed N values. Let's match that
behaviour.

Allows us to also get rid of that constant_n quirk stuff.
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220907091057.11572-17-ville.syrjala@linux.intel.com

This reverts commit c6266862.

Part of a series where patches were modified while applying to resolve
conflicts, leading to further conflicts between drm-misc-next and
drm-intel-next, resulting in build failures in drm-tip. To be applied
again on a baseline with drm-misc-next and drm-intel-next in sync.
Acked-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This reverts commit 7ae5ab44.

Part of a series where patches were modified while applying to resolve
conflicts, leading to further conflicts between drm-misc-next and
drm-intel-next, resulting in build failures in drm-tip. To be applied
again on a baseline with drm-misc-next and drm-intel-next in sync.
Acked-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This reverts commit e1a84ba8.

Part of a series where patches were modified while applying to resolve
conflicts, leading to further conflicts between drm-misc-next and
drm-intel-next, resulting in build failures in drm-tip. To be applied
again on a baseline with drm-misc-next and drm-intel-next in sync.
Acked-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Whenever we are not able to get enough timeslots
for required PBN, let's try to allocate those
using DSC, just same way as we do for SST.

v2: Removed intel_dp_mst_dsc_compute_config and refactored
    intel_dp_dsc_compute_config to support timeslots as a
    parameter(Ville Syrjälä)

v3: - Rebased
    - Added a debug to see that we at least try reserving
      VCPI slots using DSC, because currently its not visible
      from the logs, thus making debugging more tricky.
    - Moved timeslots to numerator, where it should be.

v4: - Call drm_dp_mst_atomic_check already during link
      config computation, because we need to know already
      by this moment if uncompressed amount of VCPI slots
      needed can fit, otherwise we need to use DSC.
      (thanks to Vinod Govindapillai for pointing this out)

v5: - Put pipe_config->bigjoiner_pipes back to original
      condition in intel_dp_dsc_compute_config
      (don't remember when I lost it)

v6: - Removed unnecessary drm_dp_mst_atomic_check as it is
      now always called in a newly introduced
      intel_dp_mst_find_vcpi_slots_for_bpp function
      (Vinod Govindapillai)
Reviewed-by: NVinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220905085744.29637-5-stanislav.lisovskiy@intel.com

We would be using almost same code to loop through bpps while calling
drm_dp_atomic_find_vcpi_slots - lets remove this duplication by
introducing a new function intel_dp_mst_find_vcpi_slots_for_bpp

v2: Fix pbn_div calculation - shouldn't matter if its DSC or not.
Reviewed-by: NVinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220905085744.29637-4-stanislav.lisovskiy@intel.com

We currently always exit that bpp loop because
drm_dp_atomic_find_vcpi_slots doesn't care if we actually
can fit those or not.
I think that wasn't the initial intention here, especially when
we keep trying with lower bpps, we are supposed to keep trying
until we actually find some _working_ configuration, which isn't the
case here.
So added that drm_dp_mst_check here, so that we can make sure
that try all the bpps before we fail.
Reviewed-by: NVinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220905085744.29637-3-stanislav.lisovskiy@intel.com

If an MST connector was disabled in the old state during a commit, the
connector's best_encoder will be NULL, so we can't look up mst_mgr via
it. Do the lookup instead via intel_connector->mst_port which always
points to the primary encoder.

This fixes the following:
[   58.922866] BUG: kernel NULL pointer dereference, address: 0000000000000170
[   58.922867] #PF: supervisor read access in kernel mode
[   58.922868] #PF: error_code(0x0000) - not-present page
[   58.922869] PGD 0 P4D 0
[   58.922870] Oops: 0000 [#1] PREEMPT SMP NOPTI
[   58.922872] CPU: 0 PID: 133 Comm: kworker/0:2 Tainted: G     U             6.0.0-rc3-imre+ #560
[   58.922874] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR5 RVP, BIOS ADLPFWI1.R00.3135.A00.2203251419 03/25/2022
[   58.922874] Workqueue: events output_poll_execute [drm_kms_helper]
[   58.922879] RIP: 0010:intel_dp_mst_atomic_check+0xbb/0x1c0 [i915]
[   58.922955] Code: 5b 7b f6 ff 84 c0 75 41 48 8b 44 24 18 65 48 2b 04 25 28 00 00 00 0f 85 ff 00 00 00 48 8b 45 10 48 8b 93 10 07 00 00 4c 89 e7 <48> 8b b0 70 01 00 00 48 83 c4 20 5b 5d 48 81 c6 f0 0c 00 00 41 5c
[   58.922956] RSP: 0018:ffffc90000633a88 EFLAGS: 00010246
[   58.922957] RAX: 0000000000000000 RBX: ffff888117d19000 RCX: ffff888101893308
[   58.922958] RDX: ffff888122981000 RSI: ffffffff82309ecc RDI: ffff888114da6800
[   58.922959] RBP: ffff8881094bab48 R08: 0000000081917436 R09: 0000000068191743
[   58.922960] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888114da6800
[   58.922960] R13: ffff8881143f8000 R14: 0000000000000000 R15: ffff888119bf2000
[   58.922961] FS:  0000000000000000(0000) GS:ffff888496200000(0000) knlGS:0000000000000000
[   58.922962] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   58.922962] CR2: 0000000000000170 CR3: 0000000005612004 CR4: 0000000000770ef0
[   58.922963] PKRU: 55555554
[   58.922963] Call Trace:
[   58.922964]  <TASK>
[   58.922966]  drm_atomic_helper_check_modeset+0x3f8/0xc70 [drm_kms_helper]
[   58.922972]  intel_atomic_check+0xb1/0x3180 [i915]
[   58.923059]  ? find_held_lock+0x2b/0x80
[   58.923064]  drm_atomic_check_only+0x5d3/0xa60 [drm]
[   58.923082]  drm_atomic_commit+0x56/0xc0 [drm]
[   58.923097]  ? drm_plane_get_damage_clips.cold+0x1c/0x1c [drm]
[   58.923114]  drm_client_modeset_commit_atomic+0x235/0x280 [drm]
[   58.923132]  drm_client_modeset_commit_locked+0x5b/0x190 [drm]
[   58.923148]  drm_client_modeset_commit+0x24/0x50 [drm]
[   58.923164]  drm_fb_helper_set_par+0xae/0xe0 [drm_kms_helper]
[   58.923171]  drm_fb_helper_hotplug_event+0xd5/0xf0 [drm_kms_helper]
[   58.923178]  output_poll_execute+0xac/0x200 [drm_kms_helper]
[   58.923187]  process_one_work+0x268/0x580
[   58.923190]  ? process_one_work+0x580/0x580
[   58.923191]  worker_thread+0x52/0x3b0
[   58.923193]  ? process_one_work+0x580/0x580
[   58.923195]  kthread+0xf0/0x120
[   58.923196]  ? kthread_complete_and_exit+0x20/0x20
[   58.923198]  ret_from_fork+0x1f/0x30
[   58.923202]  </TASK>

Fixes: ffac9721 ("drm/display/dp_mst: Don't open code modeset checks for releasing time slots")
Cc: Lyude Paul <lyude@redhat.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NLyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220901161933.1004778-1-imre.deak@intel.com

Now that we've finally gotten rid of the non-atomic MST users leftover in
the kernel, we can finally get rid of all of the legacy payload code we
have and move as much as possible into the MST atomic state structs. The
main purpose of this is to make the MST code a lot less confusing to work
on, as there's a lot of duplicated logic that doesn't really need to be
here. As well, this should make introducing features like fallback link
retraining and DSC support far easier.

Since the old payload code was pretty gnarly and there's a Lot of changes
here, I expect this might be a bit difficult to review. So to make things
as easy as possible for reviewers, I'll sum up how both the old and new
code worked here (it took me a while to figure this out too!).

The old MST code basically worked by maintaining two different payload
tables - proposed_vcpis, and payloads. proposed_vcpis would hold the
modified payload we wanted to push to the topology, while payloads held the
payload table that was currently programmed in hardware. Modifications to
proposed_vcpis would be handled through drm_dp_allocate_vcpi(),
drm_dp_mst_deallocate_vcpi(), and drm_dp_mst_reset_vcpi_slots(). Then, they
would be pushed via drm_dp_mst_update_payload_step1() and
drm_dp_mst_update_payload_step2().

Furthermore, it's important to note how adding and removing VC payloads
actually worked with drm_dp_mst_update_payload_step1(). When a VC payload
is removed from the VC table, all VC payloads which come after the removed
VC payload's slots must have their time slots shifted towards the start of
the table. The old code handles this by looping through the entire payload
table and recomputing the start slot for every payload in the topology from
scratch. While very much overkill, this ends up doing the right thing
because we always order the VCPIs for payloads from first to last starting
timeslot.

It's important to also note that drm_dp_mst_update_payload_step2() isn't
actually limited to updating a single payload - the driver can use it to
queue up multiple payload changes so that as many of them can be sent as
possible before waiting for the ACT. This is -technically- not against
spec, but as Wayne Lin has pointed out it's not consistently implemented
correctly in hubs - so it might as well be.

drm_dp_mst_update_payload_step2() is pretty self explanatory and basically
the same between the old and new code, save for the fact we don't have a
second step for deleting payloads anymore -and thus rename it to
drm_dp_mst_add_payload_step2().

The new payload code stores all of the current payload info within the MST
atomic state and computes as much of the state as possible ahead of time.
This has the one exception of the starting timeslots for payloads, which
can't be determined at atomic check time since the starting time slots will
vary depending on what order CRTCs are enabled in the atomic state - which
varies from driver to driver. These are still stored in the atomic MST
state, but are only copied from the old MST state during atomic commit
time. Likewise, this is when new start slots are determined.

Adding/removing payloads now works much more closely to how things are
described in the spec. When we delete a payload, we loop through the
current list of payloads and update the start slots for any payloads whose
time slots came after the payload we just deleted. Determining the starting
time slots for new payloads being added is done by simply keeping track of
where the end of the VC table is in
drm_dp_mst_topology_mgr->next_start_slot. Additionally, it's worth noting
that we no longer have a single update_payload() function. Instead, we now
have drm_dp_mst_add_payload_step1|2() and drm_dp_mst_remove_payload(). As
such, it's now left it up to the driver to figure out when to add or remove
payloads. The driver already knows when it's disabling/enabling CRTCs, so
it also already knows when payloads should be added or removed.

Changes since v1:
* Refactor around all of the completely dead code changes that are
  happening in amdgpu for some reason when they really shouldn't even be
  there in the first place… :\
* Remove mention of sending one ACT per series of payload updates. As Wayne
  Lin pointed out, there are apparently hubs on the market that don't work
  correctly with this scheme and require a separate ACT per payload update.
* Fix accidental drop of mst_mgr.lock - Wayne Lin
* Remove mentions of allowing multiple ACT updates per payload change,
  mention that this is a result of vendors not consistently supporting this
  part of the spec and requiring a unique ACT for each payload change.
* Get rid of reference to drm_dp_mst_port in DC - turns out I just got
  myself confused by DC and we don't actually need this.
Changes since v2:
* Get rid of fix for not sending payload deallocations if ddps=0 and just
  go back to wayne's fix
Signed-off-by: NLyude Paul <lyude@redhat.com>
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fangzhi Zuo <Jerry.Zuo@amd.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <sean@poorly.run>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-18-lyude@redhat.com

I'm not sure why, but at the time I originally wrote the find/release time
slot helpers I thought we should avoid keeping modeset tracking out of the
MST helpers. In retrospect though there's no actual good reason to do
this, and the logic has ended up being identical across all the drivers
using the helpers. Also, it needs to be fixed anyway so we don't break
things when going atomic-only with MST.

So, let's just move this code into drm_dp_atomic_release_time_slots() and
stop open coding it.
Signed-off-by: NLyude Paul <lyude@redhat.com>
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fangzhi Zuo <Jerry.Zuo@amd.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <sean@poorly.run>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-10-lyude@redhat.com

VCPI is only sort of the correct term here, originally the majority of this
code simply referred to timeslots vaguely as "slots" - and since I started
working on it and adding atomic functionality, the name "VCPI slots" has
been used to represent time slots.

Now that we actually have consistent access to the DisplayPort spec thanks
to VESA, I now know this isn't actually the proper term - as the
specification refers to these as time slots.

Since we're trying to make this code as easy to figure out as possible,
let's take this opportunity to correct this nomenclature and call them by
their proper name - timeslots. Likewise, we rename various functions
appropriately, along with replacing references in the kernel documentation
and various debugging messages.

It's important to note that this patch series leaves the legacy MST code
untouched for the most part, which is fine since we'll be removing it soon
anyhow. There should be no functional changes in this series.

v2:
* Add note that Wayne Lin from AMD suggested regarding slots being between
  the source DP Tx and the immediate downstream DP Rx
Signed-off-by: NLyude Paul <lyude@redhat.com>
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fangzhi Zuo <Jerry.Zuo@amd.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <sean@poorly.run>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-5-lyude@redhat.com

If drm_connector_init fails, intel_connector_free will be called to take
care of proper free. So it is necessary to drop the refcount of port
before intel_connector_free.

Fixes: 091a4f91 ("drm/i915: Handle drm-layer errors in intel_dp_add_mst_connector")
Signed-off-by: NHangyu Hua <hbh25y@gmail.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220624130406.17996-1-jose.souza@intel.comSigned-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
(cherry picked from commit cea9ed61)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

If drm_connector_init fails, intel_connector_free will be called to take
care of proper free. So it is necessary to drop the refcount of port
before intel_connector_free.

Fixes: 091a4f91 ("drm/i915: Handle drm-layer errors in intel_dp_add_mst_connector")
Signed-off-by: NHangyu Hua <hbh25y@gmail.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220624130406.17996-1-jose.souza@intel.comSigned-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
(cherry picked from commit cea9ed61)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

If drm_connector_init fails, intel_connector_free will be called to take
care of proper free. So it is necessary to drop the refcount of port
before intel_connector_free.

Fixes: 091a4f91 ("drm/i915: Handle drm-layer errors in intel_dp_add_mst_connector")
Signed-off-by: NHangyu Hua <hbh25y@gmail.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220624130406.17996-1-jose.souza@intel.comSigned-off-by: NJosé Roberto de Souza <jose.souza@intel.com>

Reduce duplication.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220330094109.4164326-2-jani.nikula@intel.com

128b/132b supports using 64 slots starting from 0, while 8b/10b reserves
slot 0 for metadata.

Commit d6c6a76f ("drm: Update MST First Link Slot Information Based
on Encoding Format") added support for updating the topology state
accordingly, and commit 41724ea2 ("drm/amd/display: Add DP 2.0 MST
DM Support") started using it in the amd driver.

This feels more than a little cumbersome, especially updating the
information in atomic check. For i915, add the update to MST connector
.compute_config hook rather than iterating over all MST managers and
connectors in global mode config .atomic_check. Fingers crossed.

v3:
- Propagate errors from intel_dp_mst_update_slots() (Ville)

v2:
- Update in .compute_config() not .atomic_check (Ville)

Cc: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NLyude Paul <lyude@redhat.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220208152317.3019070-1-jani.nikula@intel.com

Let's do the cpu transcoder M/N setup next to where we program
most other cpu transcoder timings/etc.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-9-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Instead of passing in the whole crtc state let's pass in just
the bits of state we need. This will help with the DRRS code
which shouldn't really be accessing the atomic state stuff directly
as it gets called outside the normal atomic flows.

v2: Fix set_m1_n1 vs. set_m2_n2 fumble for i9xx (Jani)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-7-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Make things a bit more explicit by splitting
intel_cpu_transcoder_set_m_n() into separate variants for M1/N1 vs.
M2/N2. Makes the DRRS M/N programming at least more obvious.

Note that for the MST and DRRS cases we don't need to call the
M2/N2 variant at all since the transcoders that support those
do not have the M2/N2 registers.

Same could be said for i9xx_crtc_enable() but I want to do a
higher level code sharing between that valleyview_crtc_enable()
later in which case we do need the M2/N2 variant. This is also
why I keep the transcoder_has_m2_n2() in intel_cpu_transcoder_set_m2_n2()
so the caller doesn't have necessarily care what the chosen
transcoder supports.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-5-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

I want to make a clean split betwen the CPU vs. PCH transcoder
programming. To that end eliminate intel_dp_set_m_n() and just
call the individual CPU/PCH transcoder functions directly.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-2-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Disabling planes in the middle of the modeset seuqnece does not make
sense since userspace can anyway disable planes before the modeset
even starts. So when the modeset seuqence starts the set of enabled
planes is entirely arbitrary. Trying to sprinkle the plane disabling
into the modeset sequence just means more randomness and potential
for hard to reproduce bugs.

So it makes most sense to just disable all planes first so that the
rest of the modeset sequence remains identical regardless of which
planes happen to be enabled by userspace at the time.

This reverts commit 84030adb.

Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-3-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.

In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP. Real data transmission starts from
the first slot, with a total of 64 slots available.

v2:
* Move total/start slots to mst_state, and copy it to mst_mgr in
atomic_check

v3:
* Only keep the slot info on the mst_state
* add a start_slot parameter to the payload function, to facilitate non
  atomic drivers (this is a temporary workaround and should be removed when
  we are moving out the non atomic driver helpers)

v4:
*fixed typo and formatting

v5: (no functional changes)
* Fixed formatting in drm_dp_mst_update_slots()
* Reference mst_state instead of mst_state->mgr for debugging info
Signed-off-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NFangzhi Zuo <Jerry.Zuo@amd.com>
[v5 nitpicks]
Reviewed-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NLyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211025223825.301703-3-lyude@redhat.com

If we want to return from for_each_intel_connector_iter(), one
way is calling drm_connector_list_iter_end() before returning
to avoid memleak. The other way is just breaking from the bracket
and then returning after the outside drm_connector_list_iter_end().
Obviously, the second way makes code smaller and more clear.
Apply it to the function intel_dp_mst_atomic_master_trans_check().
Signed-off-by: NHe Ying <heying24@huawei.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022022243.138860-1-heying24@huawei.com

Add a function for checking source MST support. Drop intel_dp->can_mst
and use intel_dp->mst_mgr.cbs to indicate the same. It's the single
point of truth without additional state variables. In code, "source
support" is also self-documenting as opposed to the vague "can mst".
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211006101618.22066-1-jani.nikula@intel.com

There's a new register pair for 128b/132b mode where you need to set the
pixel clock in Hz.

v2: Fix UHBR rate check, use intel_dp_is_uhbr() helper

Bspec: 54128
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a2902cc188973f022f282f2a77e693afdecefb5a.1631191763.git.jani.nikula@intel.com

PIPECONF becamse TRANSCONF when HSW introduced the EDP transcoder.
Bigjoiner is making life even more confusing by introducing
a N:1 relationship between pipes and transcoders. In that case
we only enable/configure the transcoder corresponding to the
master pipe. Let's do some renames to make it clear we're dealing
with the transcoder rather than pipe when it comes to
PIPECONF/TRANSCONF.

I decided to leave the _cpu_ part out from the function/macro
names since the PCH transcoder related stuff already has a
_pch_ in their name. So shouldn't be possible to confuse them.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210913144440.23008-6-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

The MST code uses actual link rates in the limits struct, while the DP
code in general uses indexes to the ->common_rates[] array. Fix the
confusion by using actual link rate values everywhere. This is a better
abstraction than some obscure index.

Rename the struct members while at it to ensure all the places are
covered.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d70ab7261abacd367d3a6a47102575eb88a55cd4.1629735412.git.jani.nikula@intel.com

Less is more, fewer lines to wonder about.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210813115610.20010-1-jani.nikula@intel.com

HDMI and DisplayPort sequences states that audio and PSR should be
disabled before planes are disabled.
Not following it did not caused any problems up to Alderlake-P but
for this platform it causes underruns during the PSR2 disable
sequence.

Specification don't mention that DRRS should be disabled before planes
but it looks safer to switch back to the default refresh rate before
following with the rest of the pipe disable sequence.

BSpec: 49191
BSpec: 49190
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210726181559.80855-1-jose.souza@intel.com

A new step has been added to the DP modeset sequences for all platforms
with display version 12 and beyond:  if enabling DP MST with FEC, we
need to set a chicken bit before enabling the transcoder.  The chicken
bit should be disabled again before disabling the transcoder (which we
can do unconditionally since it shouldn't be set anyway in non-MST
cases).

Bspec: 49190, 54128, 55424
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210723170618.1477415-1-matthew.d.roper@intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Earlier HDCP over MST support was added for TGL Platform.
Extending it to all future platfroms.

v2:
- Remove the platform check and commit log changes. [Jani]
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210705122208.25618-1-anshuman.gupta@intel.com

Clear out the straggler 'intel_crtc' variables.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210609085632.22026-7-ville.syrjala@linux.intel.comReviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>