summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display/intel_dp.c
AgeCommit message (Collapse)Author
2021-02-22drm/i915/display: Remove some redundancy around CAN_PSR()José Roberto de Souza
If source_support is set the platform supports PSR so no need to check it again at every CAN_PSR(). Also removing the intel_dp_is_edp() calls, if sink_support is set the sink connected is for sure a eDP panel. 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-3-jose.souza@intel.com
2021-02-08drm/i915: migrate pll enable/disable code to intel_dpll.[ch]Dave Airlie
This moves the older i9xx/vlv/chv enable/disable to dpll file. Signed-off-by: Dave Airlie <airlied@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/7fa8c76b0f07f3ede9efd7c1f989f33fbc8c53a3.1612536383.git.jani.nikula@intel.com
2021-02-05drm/i915/display: Support PSR Multiple InstancesGwan-gyeong Mun
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
2021-02-04drm/i915/display: fix spelling mistake "Couldnt" -> "Couldn't"Colin Ian King
There is a spelling mistake in a drm_dbg message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210203110803.17894-1-colin.king@canonical.com
2021-01-25drm/i915/display: VRR + DRRS cannot be enabled togetherVille Syrjälä
If VRR is enabled, DRRS cannot be enabled, so make this check in atomic check. Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-8-manasi.d.navare@intel.com
2021-01-25drm/i915/display/dp: Compute VRR state in atomic_checkManasi Navare
This forces a complete modeset if vrr drm crtc state goes from enabled to disabled and vice versa. This patch also computes vrr state variables from the mode timings and based on the vrr property set by userspace as well as hardware's vrr capability. v2: *Rebase v3: * Vmin = max (vtotal, vmin) (Manasi) v4: * set crtc_state->vrr.enable = 0 for disable request v5: * drm_dbg_kms, squash crtc states def patch (Jani N) v6: * Move vrr modeset check to separate function (Jani N) v7: * Ville's fixes - vmin, vmax rename, fix rounding dir * Add pipeline full, flipline to crtc state * Pass conn state to vrr_compute_config (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-6-manasi.d.navare@intel.com
2021-01-25drm/i915/display/dp: Attach and set drm connector VRR propertyAditya Swarup
This function sets the VRR property for connector based on the platform support, EDID monitor range and DP sink DPCD capability of outputing video without msa timing information. v8: * Use HAS_VRR, remove drm_conn declaration (Jani N) * Fix typos in Comment (Jani N) v7: * Move the helper to separate file (Manasi) v6: * Remove unset of prop v5: * Fix the vrr prop not being set in kernel (Manasi) * Unset the prop on connector disconnect (Manasi) v4: * Rebase (Mansi) v3: * intel_dp_is_vrr_capable can be used for debugfs, make it non static (Manasi) v2: * Just set this in intel_dp_get_modes instead of new hook (Jani) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-2-manasi.d.navare@intel.com
2021-01-21drm/i915/dp: split out aux functionality to intel_dp_aux.cJani Nikula
Split out the DP aux functionality to a new intel_dp_aux.[ch]. This is a surprisingly clean cut. v2: - Remove intel_dp_pack_aux declaration from intel_dp.h (Anshuman) - Fixed some whitespace/comment checkpatch warnings Cc: Anshuman Gupta <anshuman.gupta@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/20210120101834.19813-4-jani.nikula@intel.com
2021-01-21drm/i915/dp: abstract struct intel_dp pps members to a sub-structJani Nikula
Add some namespacing to highlight what belongs where. No functional changes. Cc: Anshuman Gupta <anshuman.gupta@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/20210120101834.19813-3-jani.nikula@intel.com
2021-01-19drm/dp: Revert "drm/dp: Introduce EDID-based quirks"Lyude Paul
This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally these quirks were added because of the issues with using the eDP backlight interfaces on certain laptop panels, which made it impossible to properly probe for DPCD backlight support without having a whitelist for panels that we know have working VESA backlight control interfaces over DPCD. As well, it should be noted it was impossible to use the normal sink OUI for recognizing these panels as none of them actually filled out their OUIs, hence needing to resort to checking EDIDs. At the time we weren't really sure why certain panels had issues with DPCD backlight controls, but we eventually figured out that there was a second interface that these problematic laptop panels actually did work with and advertise properly: Intel's proprietary backlight interface for HDR panels. So far the testing we've done hasn't brought any panels to light that advertise this interface and don't support it properly, which means we finally have a real solution to this problem. As a result, we now have no need for the force DPCD backlight quirk, and furthermore this also removes the need for any kind of EDID quirk checking in DRM. So, let's just revert it for now since we were the only driver using this. v3: * Rebase v2: * Fix indenting error picked up by checkpatch in intel_edp_init_connector() Signed-off-by: Lyude Paul <lyude@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Cc: thaytan@noraisin.net Cc: Vasily Khoruzhick <anarsoul@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-6-lyude@redhat.com
2021-01-19drm/i915: Fix the PHY compliance test vs. hotplug mishapVille Syrjälä
I accidentally added the compliance test hacks only to intel_dp_hotplug() which doesn't even get used on any DDI platform. Put the same crap into intel_ddi_hotplug(). Cc: Imre Deak <imre.deak@intel.com> Fixes: 193af12cd681 ("drm/i915: Shove the PHY test into the hotplug work") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210114205046.8247-7-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2021-01-19drm/i915: Fix the training pattern debug printVille Syrjälä
Currently we claim to use TPS7 when using TPS4. That is just confusing, so let's fix the debug print. And while we're touching this let's add the customary encoder id/name as well. v2: Add MISSING_CASE() (Manasi) Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210114205046.8247-2-ville.syrjala@linux.intel.com
2021-01-15drm/i915: Only enable DFP 4:4:4->4:2:0 conversion when outputting YCbCr 4:4:4Ville Syrjälä
Let's not enable the 4:4:4->4:2:0 conversion bit in the DFP unless we're actually outputting YCbCr 4:4:4. It would appear some protocol converters blindy consult this bit even when the source is outputting RGB, resulting in a visual mess. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2914 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111164111.13302-1-ville.syrjala@linux.intel.com Fixes: 181567aa9f0d ("drm/i915: Do YCbCr 444->420 conversion via DP protocol converters") Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-01-15drm/i915/display: Bitwise or the conversion colour specifier togetherChris Wilson
drivers/gpu/drm/i915/display/intel_dp.c:6922 intel_dp_update_420() warn: should this be a bitwise op? drivers/gpu/drm/i915/display/intel_dp.c:6922 intel_dp_update_420() warn: should this be a bitwise op? drivers/gpu/drm/i915/display/intel_dp.c:6923 intel_dp_update_420() warn: should this be a bitwise op? Inside drm_dp_downstream_rgb_to_ycbcr_conversion(), that parameter 'color_spc' is used as return port_cap[3] & color_spc, implying that it is indeed a mask and not a boolean value. Fixes: 522508b665df ("drm/i915/display: Let PCON convert from RGB to YCbCr if it can") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201223103917.14687-1-chris@chris-wilson.co.uk
2021-01-14drm/i915/pps: rename vlv_init_panel_power_sequencer to vlv_pps_initJani Nikula
This function is a bit of an outlier, but try to change to a name that is more in line with the rest of the intel_pps functions. No functional changes. Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/644b89c1d88d4d2cd7a9426ec7d7ea14eb65a8bc.1610127741.git.jani.nikula@intel.com
2021-01-14drm/i915/pps: add locked intel_pps_wait_power_cycleJani Nikula
Prefer keeping the unlocked variants hidden if possible. No functional changes. Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4b712770deab9de8c3aeea8df35269433977038a.1610127741.git.jani.nikula@intel.com
2021-01-14drm/i915/pps: rename intel_dp_check_edp to intel_pps_check_power_unlockedJani Nikula
Follow the usual naming pattern for functions. No functional changes. Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f03f7195fb62b250847909e0972f69a151095529.1610127741.git.jani.nikula@intel.com
2021-01-14drm/i915/pps: abstract intel_pps_encoder_reset()Jani Nikula
Add an "encoder reset" call to hide some more pps functions, and clean up the callers. A minor functional change is not holding the pps lock across the whole operation in intel_dp_encoder_reset, but instead doing it in two steps. v2: rename intel_pps_reinit to intel_pps_encoder_reset for clarity Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/84a50f2700b19c6719cd3e1e931c64f1e2027551.1610127741.git.jani.nikula@intel.com
2021-01-14drm/i915/pps: add higher level intel_pps_init() callJani Nikula
Add a new init call to be called only once, unlike some of the other various init calls. This lets us hide more functions within intel_pps.c. No functional changes. Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/290865ed9b0ea79120222a24c233a2d596239076.1610127741.git.jani.nikula@intel.com
2021-01-14drm/i915/pps: abstract intel_pps_vdd_off_syncJani Nikula
Add a locked version of intel_pps_vdd_off_sync_unlocked() that does everything the callers expect it to. No functional changes. v2: Fix typo (Anshuman) Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1e722290208d827c5cae107fe41dbfe41a494793.1610127741.git.jani.nikula@intel.com
2021-01-14drm/i915/pps: rename edp_panel_* to intel_pps_*_unlockedJani Nikula
Follow the usual naming pattern for functions, both for the prefix and the _unlocked suffix for functions that expect the lock to be held when calling. No functional changes. Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/d119605ba3d9c86647a524375de2d7e3d57a5676.1610127741.git.jani.nikula@intel.com
2021-01-14drm/i915/pps: rename intel_edp_panel_* to intel_pps_*Jani Nikula
Follow the usual naming pattern for functions. We don't need to repeat "panel" here. No functional changes. v2: Fix comment (Anshuman) Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b858271bd4d9c4a2ce15a13301d7bd9f7d121eb5.1610127741.git.jani.nikula@intel.com
2021-01-14drm/i915/pps: rename intel_edp_backlight_* to intel_pps_backlight_*Jani Nikula
Follow the usual naming pattern for functions. No functional changes. Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/9887e4e278ed9a20da064bbf1d0845e52b7c3b3d.1610127741.git.jani.nikula@intel.com
2021-01-14drm/i915/pps: rename pps_{,un}lock -> intel_pps_{,un}lockJani Nikula
Start following the usual naming pattern for functions. No functional changes. Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e37623750c592c08720f3b340cf85862d0f0ca12.1610127741.git.jani.nikula@intel.com
2021-01-14drm/i915/pps: abstract panel power sequencer from intel_dp.cJani Nikula
In a long overdue refactoring, split out all panel sequencer code from intel_dp.c to new intel_pps.[ch]. The first part is mostly just code movement as-is, without cleanups or functional changes. We need to add a vlv_get_dpll() helper to get at the vlv/chv dpll from pps code. v2: Rebase. Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/14cc59d5734432ad976cd49ff8efce8fa413e5b2.1610127741.git.jani.nikula@intel.com
2021-01-13drm/i915/dp: Fix LTTPR vswing/pre-emp setting in non-transparent modeImre Deak
The DP PHY vswing/pre-emphasis level programming the driver does is related to the DPTX -> first LTTPR link segment only. Accordingly it should be only programmed when link training the first LTTPR and kept as-is when training subsequent LTTPRs and the DPRX. For these latter PHYs the vs/pe levels will be set in response to writing the DP_TRAINING_LANEx_SET_PHY_REPEATERy DPCD registers (by an upstream LTTPR TX PHY snooping this write access of its downstream LTTPR/DPRX RX PHY). The above is also described in DP Standard v2.0 under 3.6.6.1. While at it simplify and add the LTTPR that is link trained to the debug message in intel_dp_set_signal_levels(). Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201229172201.4155327-2-imre.deak@intel.com
2021-01-13drm/i915/dp: Move intel_dp_set_signal_levels() to intel_dp_link_training.cImre Deak
intel_dp_set_signal_levels() is needed for link training, so move it to intel_dp_link_training.c. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201229172201.4155327-1-imre.deak@intel.com
2021-01-13drm/i915/hotplug: Handle CP_IRQ for DP-MSTAnshuman Gupta
Handle CP_IRQ in DEVICE_SERVICE_IRQ_VECTOR_ESI0 It requires to call intel_hdcp_handle_cp_irq() in case of CP_IRQ is triggered by a sink in DP-MST topology. Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Karthik B S <karthik.b.s@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-4-anshuman.gupta@intel.com
2021-01-11drm/i915: Try to use fast+narrow link on eDP again and fall back to the old ↵Ville Syrjälä
max strategy on failure Some new eDP panels don't like to operate at the max parameters, and instead we need to go for an optimal confiugration. That unfortunately doesn't work with older eDP panels which are generally only guaranteed to work at the max parameters. To solve these two conflicting requirements let's start with the optimal setup, and if that fails we start again with the max parameters. The downside is probably an extra modeset when we switch strategies but I don't see a good way to avoid that. For a bit of history we first tried to go for the fast+narrow in commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast and narrow"). but that had to be reverted due to regression on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back to max link rate and lane count on eDP"). So now we try to get the best of both worlds by using both strategies. v2: Deal with output_bpp and uapi vs. hw state split Reword some comments v3: Rebase Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Albert Astals Cid <aacid@kde.org> # v5.0 backport Cc: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport Cc: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=105267 References: https://bugs.freedesktop.org/show_bug.cgi?id=109959 References: https://gitlab.freedesktop.org/drm/intel/issues/272 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210107182026.24848-1-ville.syrjala@linux.intel.com
2021-01-08drm/i915/pps: Reuse POWER_DOMAIN_DISPLAY_CORE in pps_{lock, unlock}Anshuman Gupta
We need a power_domain wakeref in pps_{lock,unlock} to prevent a race while resetting pps state in intel_power_sequencer_reset(). intel_power_sequencer_reset() need a pps_mutex to access pps_pipe but it can't grab pps_mutex due to deadlock with power_well functions are called while holding pps_mutex. intel_power_sequencer_reset() is called by power_well function associated with legacy platforms like vlv and chv therefore re-use the POWER_DOMAIN_DISPLAY_CORE power domain, which only used by vlv and chv display power domain. This will avoids the unnecessary noise of unrelated power wells in pps_{lock,unlock}. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210107112500.16216-1-anshuman.gupta@intel.com
2021-01-07Merge tag 'drm-intel-next-2021-01-04' of ↵Daniel Vetter
git://anongit.freedesktop.org/drm/drm-intel into drm-next - Display hotplug fix for gen2/gen3 (Chris) - Remove trailing semicolon (Tom) - Suppress display warnings for old ifwi presend on our CI (Chris) - OA/Perf related workaround (Lionel) - Replace I915_READ/WRITE per new uncore and display read/write functions (Jani) - PSR improvements (Jose) - HDR and other color changes on LSPCON (Uma, Ville) - FBC fixes for TGL (Uma) - Record plane update times for debugging (Chris) - Refactor panel backlight control functions (Dave) - Display power improvements (Imre) - Add VRR register definition (Manasi) - Atomic modeset improvements for bigjoiner pipes (Ville) - Switch off the scanout during driver unregister (Chris) - Clean-up DP's FEW enable (Manasi) - Fix VDSCP slice count (Manasi) - Fix and clean up around rc_model_size for DSC (Jani) - Remove Type-C noisy debug warn message (Sean) - Display HPD code clean-up (Ville) - Refactor Intel Display (Dave) - Start adding support for Intel's eDP backlight controls (Lyude) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210104211018.GA1094707@intel.com
2021-01-07Merge tag 'topic/dp-hdmi-2.1-pcon-2020-12-23' of ↵Daniel Vetter
git://anongit.freedesktop.org/drm/drm-intel into drm-next Add support for DP-HDMI2.1 PCON From the series cover letter: This patch series attempts to add support for a DP-HDMI2.1 Protocol Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata E5 to DisplayPort_v2.0: https://vesa.org/join-vesamemberships/member-downloads/?action=stamp&fileid=42299 The details are mentioned in: VESA DP-to-HDMI PCON Specification Standalone Document https://groups.vesa.org/wg/DP/document/15651 This series starts with adding support for FRL (Fixed Rate Link) Training between the PCON and HDMI2.1 sink. As per HDMI2.1 specification, a new data-channel or lane is added in FRL mode, by repurposing the TMDS clock Channel. Through FRL, higher bit-rate can be supported, ie. up to 12 Gbps/lane (48 Gbps over 4 lanes). With these patches, the HDMI2.1 PCON can be configured to achieve FRL training based on the maximum FRL rate supported by the panel, source and the PCON. The approach is to add the support for FRL training between PCON and HDMI2.1 sink and gradually add other blocks for supporting higher resolutions and other HDMI2.1 features, that can be supported by pcon for the sources that do not natively support HDMI2.1. This is done before the DP Link training between the source and PCON is started. In case of FRL training is not achieved, the PCON will work in the regular TMDS mode, without HDMI2.1 feature support. Any interruption in FRL training between the PCON and HDMI2.1 sink is notified through IRQ_HPD. On receiving the IRQ_HPD the concerned DPCD registers are read and FRL training is re-attempted. Currently, we have tested the FRL training and are able to enable 4K display with TGL Platform + Realtek PCON RTD2173 with HDMI2.1 supporting panel. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87lfdpndkt.fsf@intel.com
2020-12-30drm/i915/dp: Track pm_qos per connectorChris Wilson
Since multiple connectors may run intel_dp_aux_xfer conncurrently, a single global pm_qos does not suffice. (One connector may disable the dma-latency boost prematurely while the second is still depending on it.) Instead of a single global pm_qos, track the pm_qos request for each intel_dp. v2: Move the pm_qos setup/teardown to intel_dp_aux_init/fini Fixes: 9ee32fea5fe8 ("drm/i915: irq-drive the dp aux communication") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201230202309.23982-1-chris@chris-wilson.co.uk
2020-12-23drm/i915/dp: Program source OUI on eDP panelsLyude Paul
Since we're about to start adding support for Intel's magic HDR backlight interface over DPCD, we need to ensure we're properly programming this field so that Intel specific sink services are exposed. Otherwise, 0x300-0x3ff will just read zeroes. We also take care not to reprogram the source OUI if it already matches what we expect. This is just to be careful so that we don't accidentally take the panel out of any backlight control modes we found it in. v2: * Add careful parameter to intel_edp_init_source_oui() to avoid re-writing the source OUI if it's already been set during driver initialization Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: thaytan@noraisin.net Cc: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201204223603.249878-2-lyude@redhat.com
2020-12-22drm/i915/display: Let PCON convert from RGB to YCbCr if it canAnkit Nautiyal
If PCON has capability to convert RGB->YCbCr colorspace and also to 444->420 downsampling then for any YUV420 only mode, we can let the PCON do all the conversion. If the PCON supports RGB->YCbCr conversion for all BT2020, BT709, BT601, choose the one that is selected by userspace via connector colorspace property, otherwise default to BT601. v2: As suggested by Uma Shankar, considered case for colorspace BT709 and BT2020, and default to BT601. Also appended dir 'display' in commit message. v3: Fixed typo in condition for printing one of the error msg. v4: As suggested by Uma Shankar: -Fixed bug in determining the colorspace for RGB->YCbCr conversion. -Fixed minor formatting issues Also updated the commit message as per latest changes. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> [Jani: Fixed checkpatch PARENTHESIS_ALIGNMENT.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-16-ankit.k.nautiyal@intel.com
2020-12-22drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encodingAnkit Nautiyal
When a source supporting DSC1.1 is connected to DSC1.2 HDMI2.1 sink via DP HDMI2.1 PCON, the PCON can be configured to decode the DSC1.1 compressed stream and encode to DSC1.2. It then sends the DSC1.2 compressed stream to the HDMI2.1 sink. This patch configures the PCON for DSC1.1 to DSC1.2 encoding, based on the PCON's DSC encoder capablities and HDMI2.1 sink's DSC decoder capabilities. v2: Addressed review comments from Uma Shankar: -fixed the error in packing pps parameter values -added check for pcon in the pcon related function -appended display in commit message v3: Only consider non-zero DSC FRL b/w for determining max FRL b/w supported by sink. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> [Jani: Fixed checkpatch BRACES, LINE_SPACING, PARENTHESIS_ALIGNMENT.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-15-ankit.k.nautiyal@intel.com
2020-12-22drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoderAnkit Nautiyal
This patch adds support to read and store the DSC capabilities of the HDMI2.1 PCon encoder. It also adds a new field to store these caps, The caps are read during dfp update and can later be used to get the PPS parameters for PCON-HDMI2.1 sink pair. Which inturn will be used to take a call to override the existing PPS-metadata, by either writing the entire new PPS metadata, or by writing only the PPS override parameters. v2: Restructured the code to read all capability DPCDs at once and store in an array in intel_dp structure. v3: rebase Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> [Jani: Fixed checkpatch PARENTHESIS_ALIGNMENT.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-13-ankit.k.nautiyal@intel.com
2020-12-22drm/i915: Add support for enabling link status and recoverySwati Sharma
In this patch enables support for detecting link failures between PCON and HDMI sink in i915 driver. HDMI link loss indication to upstream DP source is indicated via IRQ_HPD. This is followed by reading of HDMI link configuration status (HDMI_TX_LINK_ACTIVE_STATUS). If the PCON → HDMI 2.1 link status is off; reinitiate frl link training to recover. Also, report HDMI FRL link error count range for each individual FRL active lane is indicated by DOWNSTREAM_HDMI_ERROR_STATUS_LN registers. v2: Checked for dpcd read and write failures and added debug message. (Uma Shankar) v3: Rearranged code to re-start FRL link training or fall back to TMDS mode. v4: Resused function to check frl which inturn restarts FRL and fallback to TMDS mode. Signed-off-by: Swati Sharma <swati2.sharma@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> (v2) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-12-ankit.k.nautiyal@intel.com
2020-12-22drm/i915: Check for FRL training before DP Link trainingAnkit Nautiyal
This patch calls functions to check FRL training requirements for an HDMI2.1 sink, when connected through PCON. The call is made before the DP link training. In case FRL is not required or failure during FRL training, the TMDS mode is selected for the pcon. v2: moved check_frl_training() just after FEC READY, before starting DP link training. v3: rebase Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-11-ankit.k.nautiyal@intel.com
2020-12-22drm/i915: Add support for starting FRL training for HDMI2.1 via PCONAnkit Nautiyal
This patch adds functions to start FRL training for an HDMI2.1 sink, connected via a PCON as a DP branch device. This patch also adds a new structure for storing frl training related data, when FRL training is completed. v2: As suggested by Uma Shankar: -renamed couple of variables for better clarity -tweaked the macros used for correct semantics for true/false -fixed other styling issues. v3: Completed the TODO for condition for going to FRL mode. Modified the condition to determine the required FRL b/w based only on the Pcon and Sink's max FRL values. Moved the frl structure initialization to intel_dp_init_connector(). v4: Fixed typo in initialization of frl structure. v5: Always use FRL if its possible, instead of enabling only for higher modes as done in v3. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> (v2) [Jani: Fixed checkpatch BRACES, CONSTANT_COMPARISON.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-10-ankit.k.nautiyal@intel.com
2020-12-22drm/i915: Capture max frl rate for PCON in dfp cap structureAnkit Nautiyal
HDMI2.1 PCON advertises Max FRL bandwidth supported by the PCON. This patch captures this in dfp cap structure in intel_dp and uses this to prune connector modes that cannot be supported by the PCON and FRL bandwidth. v2: Addressed review comments from Uma Shankar: -tweaked the comparison of target bw and pcon frl bw to avoid roundup errors. -minor modification of field names and comments. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-9-ankit.k.nautiyal@intel.com
2020-12-14Merge tag 'drm-next-2020-12-11' of git://anongit.freedesktop.org/drm/drmLinus Torvalds
Pull drm updates from Dave Airlie: "Not a huge amount of big things here, AMD has support for a few new HW variants (vangogh, green sardine, dimgrey cavefish), Intel has some more DG1 enablement. We have a few big reworks of the TTM layers and interfaces, GEM and atomic internal API reworks cross tree. fbdev is marked orphaned in here as well to reflect the current reality. core: - documentation updates - deprecate DRM_FORMAT_MOD_NONE - atomic crtc enable/disable rework - GEM convert drivers to gem object functions - remove SCATTER_LIST_MAX_SEGMENT sched: - avoid infinite waits ttm: - remove AGP support - don't modify caching for swapout - ttm pinning rework - major TTM reworks - new backend allocator - multihop support vram-helper: - top down BO placement fix - TTM changes - GEM object support displayport: - DP 2.0 DPCD prep work - DP MST extended DPCD caps fbdev: - mark as orphaned amdgpu: - Initial Vangogh support - Green Sardine support - Dimgrey Cavefish support - SG display support for renoir - SMU7 improvements - gfx9+ modiifier support - CI BACO fixes radeon: - expose voltage via hwmon on SUMO amdkfd: - fix unique id handling i915: - more DG1 enablement - bigjoiner support - integer scaling filter support - async flip support - ICL+ DSI command mode - Improve display shutdown - Display refactoring - eLLC machine fbdev loading fix - dma scatterlist fixes - TGL hang fixes - eLLC display buffer caching on SKL+ - MOCS PTE seeting for gen9+ msm: - Shutdown hook - GPU cooling device support - DSI 7nm and 10nm phy/pll updates - sm8150/sm2850 DPU support - GEM locking re-work - LLCC system cache support aspeed: - sysfs output config support ast: - LUT fix - new display mode gma500: - remove 2d framebuffer accel panfrost: - move gpu reset to a worker exynos: - new HDMI mode support mediatek: - MT8167 support - yaml bindings - MIPI DSI phy code moved etnaviv: - new perf counter - more lockdep annotation hibmc: - i2c DDC support ingenic: - pixel clock reset fix - reserved memory support - allow both DMA channels at once - different pixel format support - 30/24/8-bit palette modes tilcdc: - don't keep vblank irq enabled vc4: - new maintainer added - DSI registration fix virtio: - blob resource support - host visible and cross-device support - uuid api support" * tag 'drm-next-2020-12-11' of git://anongit.freedesktop.org/drm/drm: (1754 commits) drm/amdgpu: Initialise drm_gem_object_funcs for imported BOs drm/amdgpu: fix size calculation with stolen vga memory drm/amdgpu: remove amdgpu_ttm_late_init and amdgpu_bo_late_init drm/amdgpu: free the pre-OS console framebuffer after the first modeset drm/amdgpu: enable runtime pm using BACO on CI dGPUs drm/amdgpu/cik: enable BACO reset on Bonaire drm/amd/pm: update smu10.h WORKLOAD_PPLIB setting for raven drm/amd/pm: remove one unsupported smu function for vangogh drm/amd/display: setup system context for APUs drm/amd/display: add S/G support for Vangogh drm/amdkfd: Fix leak in dmabuf import drm/amdgpu: use AMDGPU_NUM_VMID when possible drm/amdgpu: fix sdma instance fw version and feature version init drm/amd/pm: update driver if version for dimgrey_cavefish drm/amd/display: 3.2.115 drm/amd/display: [FW Promotion] Release 0.0.45 drm/amd/display: Revert DCN2.1 dram_clock_change_latency update drm/amd/display: Enable gpu_vm_support for dcn3.01 drm/amd/display: Fixed the audio noise during mode switching with HDCP mode on drm/amd/display: Add wm table for Renoir ...
2020-12-10drm/i915/dsc: make rc_model_size an encoder defined valueJani Nikula
Move the initialization of the rc_model_size from the common code into encoder code, allowing different encoders to specify the size according to their needs. Keep using the hard coded value in the encoders for now to make this a non-functional change. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6843c4f6958619f7389180aa92fded7b9fdbb4ba.1607429866.git.jani.nikula@intel.com
2020-12-08drm/i915/display/dp: Compute the correct slice count for VDSC on DPManasi Navare
This patch fixes the slice count computation algorithm for calculating the slice count based on Peak pixel rate and the max slice width allowed on the DSC engines. We need to ensure slice count > min slice count req as per DP spec based on peak pixel rate and that it is greater than min slice count based on the max slice width advertised by DPCD. So use max of these two. In the prev patch we were using min of these 2 causing it to violate the max slice width limitation causing a blank screen on 8K@60. Fixes: d9218c8f6cf4 ("drm/i915/dp: Add helpers for Compressed BPP and Slice Count for DSC") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: <stable@vger.kernel.org> # v5.0+ Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201204205804.25225-1-manasi.d.navare@intel.com (cherry picked from commit d371d6ea92ad2a47f42bbcaa786ee5f6069c9c14) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-12-07drm/i915/display/dp: Compute the correct slice count for VDSC on DPManasi Navare
This patch fixes the slice count computation algorithm for calculating the slice count based on Peak pixel rate and the max slice width allowed on the DSC engines. We need to ensure slice count > min slice count req as per DP spec based on peak pixel rate and that it is greater than min slice count based on the max slice width advertised by DPCD. So use max of these two. In the prev patch we were using min of these 2 causing it to violate the max slice width limitation causing a blank screen on 8K@60. Fixes: d9218c8f6cf4 ("drm/i915/dp: Add helpers for Compressed BPP and Slice Count for DSC") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: <stable@vger.kernel.org> # v5.0+ Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201204205804.25225-1-manasi.d.navare@intel.com
2020-12-03drm/i915: Track power reference taken for eDP VDDImre Deak
Add wakeref tracking for the eDP encoders' AUX display power domain references taken while the panel's VDD is enabled. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20201130212200.2811939-7-imre.deak@intel.com
2020-12-02drm/i915/display: Enable colorspace programming for LSPCON devicesUma Shankar
Enable HDMI Colorspace for LSPCON based devices. Sending Colorimetry data for HDR using AVI infoframe. LSPCON firmware expects this and though SOC drives DP, for HDMI panel AVI infoframe is sent to the LSPCON device which transfers the same to HDMI sink. v2: Dropped state managed in drm core as per Jani Nikula's suggestion. v3: Aligned colorimetry handling for lspcon as per compute_avi_infoframes, as suggested by Ville. v4: Finally fixed this with Ville's help, re-phrased the commit header and description. v5: Register HDMI colorspace for lspcon and move this to intel_dp_add_properties as we can't create property at late_register. Credits-to: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-9-uma.shankar@intel.com
2020-12-02drm/i915: Split intel_attach_colorspace_property() into HDMI vs. DP variantsVille Syrjälä
With LSPCON we use the AVI infoframe to convey the colorimetry information (as opposed to DP MSA/SDP), so the property we expose should match the values we can stuff into the infoframe. Ie. we must use the HDMI variant of the property, even though we drive LSPCON in PCON mode. To that end just split intel_attach_colorspace_property() into HDMI and DP variants and let the caller worry about which one it wants to use. Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-8-uma.shankar@intel.com
2020-12-02drm/i915/display: Attach content type property for LSPCONUma Shankar
Content type is supported on HDMI sink devices. Attached the property for the same for LSPCON based devices. v2: Added the content type programming when we are attaching the property to connector, as suggested by Ville. v3: Need to attach content type on intel_dp_add_properties as creating of new properties is not possible at late_register. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-7-uma.shankar@intel.com
2020-12-02drm/i915/display: Attach HDR property for capable Gen9 devicesUma Shankar
Attach HDR property for Gen9 devices with MCA LSPCON chips. v2: Cleaned HDR property attachment logic based on capability as per Jani Nikula's suggestion. v3: Fixed the HDR property attachment logic as per the new changes by Kai-Feng to align with lspcon detection failure on some devices. v4: Add HDR proprty in late_register to handle lspcon detection, as suggested by Ville. v5: Init Lspcon only if advertized from BIOS. v6: Added a Todo to plan a cleanup later, added Ville's RB. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-4-uma.shankar@intel.com
generated by cgit v1.2.3-70-g09d2 (git 2.48.1) at 2025-07-18 13:03:37 +0000