aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/drivers/gpu/drm/i915/display/intel_dp_mst.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2023-06-02drm/i915/display: switch the rest of the connectors to struct drm_edidJani Nikula1-4/+6
Convert the remaining uses of struct edid based drm_get_edid(), drm_connector_update_edid_property() and drm_add_edid_modes() calls to the struct drm_edid based drm_edid_read_ddc(), drm_edid_connector_update() and drm_edid_connector_add_modes(). Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b1b53bb9004adaa402e061f7df2caf0eb4723a43.1685437501.git.jani.nikula@intel.com
2023-06-02drm/display/dp_mst: drop has_audio from struct drm_dp_mst_portJani Nikula1-1/+1
Caching the has_audio in struct drm_dp_mst_port seems odd, and oddly placed. Defer audio handling to drivers, and use the info from the connector display info. i915 was the only one using it anyway. Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7d9eefdf150870479c5797f027d4c2b0a19ff583.1685437500.git.jani.nikula@intel.com
2023-05-16drm/i915/hdcp: add intel_atomic_state argument to hdcp_enable functionSuraj Kandpal1-3/+1
Pass all the parameter in intel_encoder->enable() to intel_hdcp_enable as we need intel_atomic_state later down to get acquire_ctx. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230515103225.688830-2-suraj.kandpal@intel.com
2023-05-05drm/i915/display: Add new member to configure PCON color conversionAnkit Nautiyal1-0/+1
The decision to use DFP output format conversion capabilities should be during compute_config phase. This patch adds new member to crtc_state to represent the final output_format to the sink. In case of a DFP this can be different than the output_format, as per the format conversion done via the PCON. This will help to store only the format conversion capabilities of the DP device in intel_dp->dfp, and use crtc_state to compute and store the configuration for color/format conversion for a given mode. v2: modified the new member to crtc_state to represent the final output_format that eaches the sink, after possible conversion by PCON kind of devices. (Ville) v3: Addressed comments from Ville: -Added comments to clarify difference between sink_format and output_format. -Corrected the order of setting sink_format and output_format. -Added readout for sink_format in get_pipe_config hooks. v4: Set sink_format for intel_sdvo too. (Ville) v5: Rebased. v6: Fixed condition to go for YCbCr420 format for dp and hdmi. (Ville) v7: Fix the condition to set sink_format for HDMI. Set hdmi output_format simply as sink_format. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v3) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230427125605.487769-2-ankit.k.nautiyal@intel.com
2023-04-19drm/i915/dp_mst: Fix active port PLL selection for secondary MST streamsImre Deak1-0/+7
The port PLL selection needs to be up-to-date in the CRTC state of both the primary and all secondary MST streams. The commit removing the encoder update_prepare/complete hooks (see Fixes: below), stopped doing this for secondary streams, fix this up. Fixes: 0f752b2178c9 ("drm/i915: Remove the encoder update_prepare()/complete() hooks") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8336 Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230414173800.590790-1-imre.deak@intel.com
2023-04-05drm/i915: Implement UHBR bandwidth checkStanislav Lisovskiy1-4/+29
According to spec, we should check if output_bpp * pixel_rate is less than DDI clock * 72, if UHBR is used. v2: - s/pipe_config/crtc_state/ (Jani Nikula) - Merged previous patch into that one, to remove empty function(Jani Nikula) v3: - Make that constraint check to be DSC-related only - Limit this to only DISPLAY_VER <= 13 v4: - Move constraint check to the top(Vinod Govindapillai) HSDES: 1406899791 BSPEC: 49259 Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230324135125.6720-1-stanislav.lisovskiy@intel.com
2023-04-03drm/i915: Disable DPLLs before disconnecting the TC PHYImre Deak1-0/+15
Bspec requires disabling the DPLLs on TC ports before disconnecting the port's PHY. Add a post_pll_disable encoder hook and move the call to disconnect the port's PHY from the post_disable hook to the new hook. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230323142035.1432621-28-imre.deak@intel.com
2023-03-29drm/i915: Use compressed bpp when calculating m/n value for DP MST DSCStanislav Lisovskiy1-1/+1
For obvious reasons, we use compressed bpp instead of pipe bpp for DSC DP SST case. Lets be consistent and use compressed bpp instead of pipe bpp, also in DP MST DSC case. Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Fixes: d51f25eb479a ("drm/i915: Add DSC support to MST path") Link: https://patchwork.freedesktop.org/patch/msgid/20230327064217.24033-1-stanislav.lisovskiy@intel.com
2023-03-15Merge tag 'drm-intel-next-2023-03-07' of git://anongit.freedesktop.org/drm/drm-intel into drm-nextDave Airlie1-11/+18
Cross-subsystem Changes: - MEI patches to fix suspend/resume issues with the i915's PXP. (Alexander) Driver Changes: - Registers helpers and clean-ups. (Lucas) - PXP fixes and clean-ups. (Alan, Alexander) - CDCLK related fixes and w/a (Chaitanya, Stanislav) - Move display code to use RMW whenever possible (Andrzej) - PSR fixes (Jouni, Ville) - Implement async_flip mode per plane tracking (Andrzej) - Remove pre-production Workarounds (Matt) - HDMI related fixes (Ankit) - LVDS cleanup (Ville) - Watermark fixes and cleanups (Ville, Jani, Stanilav) - DMC code related fixes, cleanups and improvements (Jani) - Implement fb_dirty for PSR,FBC,DRRS fixes (Jouni) - Initial DSB improvements targeting LUTs loading (Ville) - HWMON related fixes (Ashutosh) - PCI ID updates (Jonathan, Matt Roper) - Fix leak in scatterlist (Matt Atwood) - Fix eDP+DSI dual panel systems (Ville) - Cast iomem to avoid sparese warnings (Jani) - Set default backlight controller index (Jani) - More MTL enabling (RK) - Conversion of display dev_priv towards i915 (Nirmoy) - Improvements in log/debug messages (Ville) - Increase slice_height for DP VDSC (Suraj) - VBT ports improvements (Ville) - Fix platforms without Display (Imre) - Other generic display code clean-ups (Ville, Jani, Rodrigo) - Add RPL-U sub platform (Chaitanya) - Add inverted backlight quirk for HP 14-r206nv (Mavroudis) - Transcoder timing improvements (Ville) - Track audio state per-transcoder (Ville) - Error/underrun interrupt fixes (Ville) - Update combo PHY init sequence (Matt Roper) - Get HDR DPCD refresh timeout (Ville) - Vblank improvements (Ville) - DSS fixes and cleanups (Jani) - PM code cleanup (Jani) - Split display parts related to RPS (Jani) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ZAez4aekcob8fTeh@intel.com
2023-02-23drm/i915: Fix audio ELD handling for DP MSTVille Syrjälä1-9/+16
I forgot to call intel_audio_compute_config() on DP MST, which means ELD doesn't get populated and passed to the audio driver. References: https://gitlab.freedesktop.org/drm/intel/-/issues/8097 Fixes: 5d986635e296 ("drm/i915/audio: Precompute the ELD") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230220151731.6852-1-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2023-02-17drm/i915: Rename intel_ddi_{enable,disable}_pipe_clock()Ville Syrjälä1-2/+2
What intel_ddi_{enable,disable}_pipe_clock() actually do is enable the clock to the transcoder, not the pipe. Rename accordingly. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-13drm/i915/dp_mst: Fix payload removal during output disablingImre Deak1-6/+10
Use the correct old/new topology and payload states in intel_mst_disable_dp(). So far drm_atomic_get_mst_topology_state() it used returned either the old state, in case the state was added already earlier during the atomic check phase or otherwise the new state (but the latter could fail, which can't be handled in the enable/disable hooks). After the first patch in the patchset, the state should always get added already during the check phase, so here we can get the old/new states without a failure. drm_dp_remove_payload() should use time_slots from the old payload state and vc_start_slot in the new one. It should update the new payload states to reflect the sink's current payload table after the payload is removed. Pass the new topology state and the old and new payload states accordingly. This also fixes a problem where the payload allocations for multiple MST streams on the same link got inconsistent after a few commits, as during payload removal the old instead of the new payload state got updated, so the subsequent enabling sequence and commits used a stale payload state. v2: Constify the old payload state pointer. (Ville) Cc: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org # 6.1 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Lyude Paul <lyude@redhat.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Acked-by: Wayne Lin <wayne.lin@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230206114856.2665066-4-imre.deak@intel.com
2023-02-13drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()Imre Deak1-1/+3
Atm, drm_dp_remove_payload() uses the same payload state to both get the vc_start_slot required for the payload removal DPCD message and to deduct time_slots from vc_start_slot of all payloads after the one being removed. The above isn't always correct, as vc_start_slot must be the up-to-date version contained in the new payload state, but time_slots must be the one used when the payload was previously added, contained in the old payload state. The new payload's time_slots can change vs. the old one if the current atomic commit changes the corresponding mode. This patch let's drivers pass the old and new payload states to drm_dp_remove_payload(), but keeps these the same for now in all drivers not to change the behavior. A follow-up i915 patch will pass in that driver the correct old and new states to the function. Cc: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: stable@vger.kernel.org # 6.1 Cc: dri-devel@lists.freedesktop.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Lyude Paul <lyude@redhat.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Acked-by: Wayne Lin <wayne.lin@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230206114856.2665066-2-imre.deak@intel.com
2023-02-13drm/i915/dp_mst: Add the MST topology state for modesetted CRTCsImre Deak1-0/+61
Add the MST topology for a CRTC to the atomic state if the driver needs to force a modeset on the CRTC after the encoder compute config functions are called. Later the MST encoder's disable hook also adds the state, but that isn't guaranteed to work (since in that hook getting the state may fail, which can't be handled there). This should fix that, while a later patch fixes the use of the MST state in the disable hook. v2: Add missing forward struct declartions, caught by hdrtest. v3: Factor out intel_dp_mst_add_topology_state_for_connector() used later in the patchset. Cc: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org # 6.1 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> # v2 Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Lyude Paul <lyude@redhat.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Acked-by: Wayne Lin <wayne.lin@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230206114856.2665066-1-imre.deak@intel.com
2022-12-13drm/i915: Bpp/timeslot calculation fixes for DP MST DSCStanislav Lisovskiy1-12/+57
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: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221123100718.29130-1-stanislav.lisovskiy@intel.com
2022-12-13drm/i915: Extract VESA DSC bpp alignment to separate functionStanislav Lisovskiy1-1/+0
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: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221123100551.29080-1-stanislav.lisovskiy@intel.com
2022-12-13drm/i915: Add DSC support to MST pathStanislav Lisovskiy1-0/+125
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: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221101094222.22091-5-stanislav.lisovskiy@intel.com
2022-12-13drm/i915: Extract drm_dp_atomic_find_vcpi_slots cycle to separate functionStanislav Lisovskiy1-12/+36
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: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221101094222.22091-4-stanislav.lisovskiy@intel.com
2022-12-13drm/i915: Fix intel_dp_mst_compute_link_configStanislav Lisovskiy1-2/+14
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: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221101094222.22091-3-stanislav.lisovskiy@intel.com
2022-11-11drm/i915: stop including i915_irq.h from i915_trace.hJani Nikula1-0/+1
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6e78a2e0ac1bffaf5af3b5ccc21dff05e6518cef.1668008071.git.jani.nikula@intel.com
2022-09-26drm/i915: Extract intel_dp_mst_add_properties()Ville Syrjälä1-16/+30
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220912111814.17466-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-09-14drm/i915/mtl: Update CHICKEN_TRANS* register addressesMadhumitha Tolakanahalli Pradeep1-1/+4
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: Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220913183341.908028-6-radhakrishna.sripada@intel.com
2022-09-12Merge drm/drm-next into drm-intel-nextJani Nikula1-63/+34
Backmerge to sync the DP MST atomic changes to drm-intel-next. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2022-09-08drm/i915: Use a fixed N value alwaysVille Syrjälä1-2/+1
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: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220907091057.11572-17-ville.syrjala@linux.intel.com
2022-09-06Revert "drm/i915: Fix intel_dp_mst_compute_link_config"Jani Nikula1-14/+2
This reverts commit c6266862de1665b8c8006f58612db2dea66a29f6. 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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2022-09-06Revert "drm/i915: Extract drm_dp_atomic_find_vcpi_slots cycle to separate function"Jani Nikula1-41/+13
This reverts commit 7ae5ab441402b8165de4658ba9398d8378f7dd1e. 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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2022-09-06Revert "drm/i915: Add DSC support to MST path"Jani Nikula1-126/+0
This reverts commit e1a84ba850128b3984973786829e610ae4ee0e2e. 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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2022-09-06drm/i915: Add DSC support to MST pathStanislav Lisovskiy1-0/+126
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: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220905085744.29637-5-stanislav.lisovskiy@intel.com
2022-09-06drm/i915: Extract drm_dp_atomic_find_vcpi_slots cycle to separate functionStanislav Lisovskiy1-13/+41
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: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220905085744.29637-4-stanislav.lisovskiy@intel.com
2022-09-06drm/i915: Fix intel_dp_mst_compute_link_configStanislav Lisovskiy1-2/+14
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: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220905085744.29637-3-stanislav.lisovskiy@intel.com
2022-09-02drm/i915/dp_mst: Fix mst_mgr lookup during atomic checkImre Deak1-5/+3
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: ffac9721939d ("drm/display/dp_mst: Don't open code modeset checks for releasing time slots") Cc: Lyude Paul <lyude@redhat.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901161933.1004778-1-imre.deak@intel.com
2022-08-23drm/display/dp_mst: Move all payload info into the atomic stateLyude Paul1-34/+30
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: Lyude 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: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-18-lyude@redhat.com
2022-08-23drm/display/dp_mst: Don't open code modeset checks for releasing time slotsLyude Paul1-23/+1
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: Lyude 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: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-10-lyude@redhat.com
2022-08-23drm/display/dp_mst: Call them time slots, not VCPI slotsLyude Paul1-3/+2
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: Lyude 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: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-5-lyude@redhat.com
2022-06-28drm/i915: fix a possible refcount leak in intel_dp_add_mst_connector()Hangyu Hua1-0/+1
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: 091a4f91942a ("drm/i915: Handle drm-layer errors in intel_dp_add_mst_connector") Signed-off-by: Hangyu Hua <hbh25y@gmail.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220624130406.17996-1-jose.souza@intel.com Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
2022-03-30drm/i915/audio: move has_audio checks to within codec enable/disableJani Nikula1-5/+3
Reduce duplication. 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/20220330094109.4164326-2-jani.nikula@intel.com
2022-02-11drm/i915/mst: update slot information for 128b/132bJani Nikula1-2/+31
128b/132b supports using 64 slots starting from 0, while 8b/10b reserves slot 0 for metadata. Commit d6c6a76f80a1 ("drm: Update MST First Link Slot Information Based on Encoding Format") added support for updating the topology state accordingly, and commit 41724ea273cd ("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: Lyude Paul <lyude@redhat.com> 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/20220208152317.3019070-1-jani.nikula@intel.com
2022-02-01drm/i915: Move M/N setup to a more logical place on ddi platformsVille Syrjälä1-4/+0
Let's do the cpu transcoder M/N setup next to where we program most other cpu transcoder timings/etc. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01drm/i915: Pass crtc+cpu_transcoder to intel_cpu_transcoder_set_m_n()Ville Syrjälä1-1/+2
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01drm/i915: Split intel_cpu_transcoder_set_m_n() into M1/N1 vs. M2/N2 variantsVille Syrjälä1-3/+2
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01drm/i915: Nuke intel_dp_set_m_n()Ville Syrjälä1-1/+3
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-10-29Merge drm/drm-next into drm-intel-nextJani Nikula1-2/+2
Backmerge to get the DP 2.0 MST changes merged to drm-next. This also syncs us up to v5.15-rc7. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-10-27Revert "drm/i915/display: Disable audio, DRRS and PSR before planes"Ville Syrjälä1-11/+3
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 84030adb9e27d202a66022488bf0349a8bd45213. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-3-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-10-25drm: Update MST First Link Slot Information Based on Encoding FormatBhawanpreet Lakha1-2/+2
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: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> [v5 nitpicks] Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211025223825.301703-3-lyude@redhat.com
2021-10-25drm: Small optimization to intel_dp_mst_atomic_master_trans_checkHe Ying1-10/+8
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: He Ying <heying24@huawei.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211022022243.138860-1-heying24@huawei.com
2021-10-08drm/i915/mst: abstract intel_dp_mst_source_support()Jani Nikula1-4/+11
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211006101618.22066-1-jani.nikula@intel.com
2021-09-20drm/i915/dg2: configure TRANS_DP2_VFREQ{HIGH,LOW} for 128b/132bJani Nikula1-0/+11
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/a2902cc188973f022f282f2a77e693afdecefb5a.1631191763.git.jani.nikula@intel.com
2021-09-15drm/i915: s/pipe/transcoder/ when dealing with PIPECONF/TRANSCONFVille Syrjälä1-2/+2
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210913144440.23008-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-08-24drm/i915/dp: use actual link rate values in struct link_config_limitsJani Nikula1-3/+3
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/d70ab7261abacd367d3a6a47102575eb88a55cd4.1629735412.git.jani.nikula@intel.com
2021-08-13drm/i915/mst: use intel_de_rmw() to simplify VC payload alloc set/clearJani Nikula1-7/+2
Less is more, fewer lines to wonder about. Cc: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210813115610.20010-1-jani.nikula@intel.com