aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-06-12drm/panel: himax-hx83102: fix incorrect argument to mipi_dsi_msleepTejas Vipin1-3/+3
mipi_dsi_msleep should be modified to accept ctx as a pointer and the function call should be adjusted accordingly. Fixes: a2ab7cb169da ("drm/panel: himax-hx83102: use wrapped MIPI DCS functions") Signed-off-by: Tejas Vipin <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Link: https://lore.kernel.org/r/[email protected] [narmstrong: fixed subject and fixes tag] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-12drm/mipi-dsi: fix handling of ctx in mipi_dsi_msleepTejas Vipin1-1/+1
ctx would be better off treated as a pointer to account for most of its usage so far, and brackets should be added to account for operator precedence for correct evaluation. Fixes: f79d6d28d8fe ("drm/mipi-dsi: wrap more functions for streamline handling") Signed-off-by: Tejas Vipin <[email protected]> Suggested-by: Douglas Anderson <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Link: https://lore.kernel.org/r/[email protected] [narmstrong: fixed fixes tag] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-12drm/bridge-connector: implement glue code for HDMI connectorDmitry Baryshkov3-3/+174
In order to let bridge chains implement HDMI connector infrastructure, add necessary glue code to the drm_bridge_connector. In case there is a bridge that sets DRM_BRIDGE_OP_HDMI, drm_bridge_connector will register itself as a HDMI connector and provide proxy drm_connector_hdmi_funcs implementation. Note, to simplify implementation, there can be only one bridge in a chain that sets DRM_BRIDGE_OP_HDMI. Setting more than one is considered an error. This limitation can be lifted later, if the need arises. Acked-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-06-12drm/bridge-connector: switch to using drmm allocationsDmitry Baryshkov1-18/+5
Turn drm_bridge_connector to using drmm_kzalloc() and drmm_connector_init() and drop the custom destroy function. The drm_connector_unregister() and fwnode_handle_put() are already handled by the drm_connector_cleanup() and so are safe to be dropped. Acked-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-06-12drm/connector: hdmi: allow disabling Audio InfoframeDmitry Baryshkov2-0/+37
Add drm_atomic_helper_connector_hdmi_disable_audio_infoframe(), an API to allow the driver disable sending the Audio Infoframe. This is to be used by the drivers if setup of the infoframes is not tightly coupled with the audio functionality and just disabling the audio playback doesn't stop the HDMI hardware from sending the Infoframe. Acked-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-06-11drm/i915/mtl: Update workaround 14018575942Angus Chen1-0/+8
The WA should be extended to cover VDBOX engine. We found that 28-channels 1080p VP9 encoding may hit this issue. v3: update the WA number and explain the reason why this workaround is needed v2: add WA number v1: initial version Signed-off-by: Angus Chen <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/psr: Wake time is aux less wake time for Panel ReplayJouni Högander1-2/+6
When checking vblank length used wake time is aux less wake time for eDP Panel Replay (vblank length is not checked for DP2.0 Panel Replay). Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/psr: Check vblank against IO buffer wake time on LunarlakeJouni Högander1-1/+5
As Lunarlake doesn't have block count configuration vblank should be checked against IO buffer wake time. Bspec: 68920 Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/psr: Take into account SU SDP scanline indication in vblank checkJouni Högander1-0/+3
SU SDP scanline indication should be taken into account when checking vblank length. In Bspec we have: PSR2_CTL[ SU SDP scanline indication ] = 0: (TRANS_VBLANK Vertical Blank End- TRANS_VBLANK Vertical Blank Start) > PSR2_CTL Block Count Number value in lines PSR2_CTL[ SU SDP scanline indication ] = 1: (TRANS_VBLANK Vertical Blank End- TRANS_VBLANK Vertical Blank Start- 1) > PSR2_CTL Block Count Number value in lines Bspec: 49274 Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/psr: Move vblank length check to separate functionJouni Högander1-3/+15
We are about to add more complexity to vblank length check. It makes sense to move it to separate function for sake of clarity. v2: change name to wake_lines_fit_into_vblank Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/psr: Print Panel Replay status instead of frame lock statusJouni Högander1-17/+5
Currently Panel Replay status printout is printing frame lock status. It should print Panel Replay status instead. Panel Replay status register field follows PSR status register field. Use existing PSR code for that. Fixes: ef75c25e8fed ("drm/i915/panelreplay: Debugfs support for panel replay") Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/psr: Add Panel Replay support to intel_psr2_config_et_validJouni Högander1-7/+8
Early Transport is possible and in our HW mandatory on eDP Panel Replay. Add parameter to intel_psr2_config_et_valid to differentiate validity check for Panel Replay. v2: fix intel_dp->psr_dpcd[0] check Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/alpm: Share alpm support checks with PSR codeJouni Högander3-14/+6
Convert intel_alpm_aux_wake_supported and intel_alpm_aux_less_wake_supported as non-static. Use them in intel_psr.c instead of local variables. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/psr: Split enabling sink for PSR and Panel ReplayJouni Högander1-37/+44
Current intel_psr_enable_sink is a mess due to partly reusing PSR bit definitions for Panel Replay. Even thought PSR and Panel Replay enable registers do have common bits they still have also different bits and same bits with different meaning. For sake of clarity split enabling sink to PSR and Panel Replay specific parts. Also fix issue caused by using psr->panel_replay_enabled to early. Fixes: 88ae6c65ecdb ("drm/i915/psr: Unify panel replay enable/disable sink") Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/display: Add missing Panel Replay Enable SU Region ET bitJouni Högander1-0/+1
Add missing Panel Replay Enable SU Region ET bit defined in DP2.1 specification. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Acked-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/display: Skip Panel Replay on pipe comparison if no active planesJouni Högander1-1/+3
Panel Replay is not enabled if there are no active planes. Do not compare it on pipe comparison. Otherwise we get pipe mismatch. Fixes: ac9ef327327b ("drm/i915/psr: Panel replay has to be enabled before link training") Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/display: Take panel replay into account in vsc sdp unpackingJouni Högander1-1/+4
Currently intel_dp_vsc_sdp_unpack is not taking into account Panel Replay vsc sdp. Fix this by adding vsc sdp revision 0x6 and length 0x10 into intel_dp_vsc_sdp_unpack Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/alpm: Write also AUX Less Wake lines into ALPM_CTLJouni Högander1-1/+2
Currently AUX Less Wake lines are not written into ALPM_CTL. Fix this. Fixes: 1ccbf135862b ("drm/i915/psr: Enable ALPM on source side for eDP Panel replay") Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/alpm: Do not use fast_wake_lines for aux less wake timeJouni Högander2-2/+3
We want to have own variables for fast wake lines and aux less wake time. It might be needed to choose if we can enable Panel Replay Selective Update or PSR2. Also currently aux less wake time is overwritten by calculated fast wake time. v2:use aux less wake time in intel_alpm_lobf_compute_config Fixes: da6a9836ac09 ("drm/i915/psr: Calculate aux less wake time") Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/panel: Update TODO list item for cleaning up prepared/enabled trackingDouglas Anderson1-21/+26
Now that most panels have been updated not to track/double-check their prepared/enabled state update the TODO with next steps. Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.23.I104cdece7324b0c365e552a17f9883414ffaea01@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.23.I104cdece7324b0c365e552a17f9883414ffaea01@changeid
2024-06-11drm/panel: raydium-rm67191: Don't call unprepare+disable at shutdownDouglas Anderson1-9/+0
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. A grep through mainline for compatible strings used by this driver indicates that it is used by IMX boards. The IMX driver appears to be correctly calling drm_atomic_helper_shutdown() so we can remove the calls. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Robert Chiras <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.22.Id14188f1a8af7d524751c27c343a5b583ff5361f@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.22.Id14188f1a8af7d524751c27c343a5b583ff5361f@changeid
2024-06-11drm/panel: raydium-rm67191: Stop tracking enabledDouglas Anderson1-19/+2
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. The conversion of the rm67191 panel driver follows many of the other panel drivers but has a few differences that need to be called out. Like in commit 1e0465eb16a4 ("drm/panel: otm8009a: Don't double check prepared/enabled"), this panel also uses the "prepared" flag to prevent the backlight functions from running when the panel is powered off. This is probably not the safest thing to do but the old behavior was preserved. See the discussion in the otm8009a patch. Because of this, I've left the driver tracking "prepared" but removed its tracking of "enabled". NOTE: as part of this, transition the panel's direct calls to its disable/unprepare functions in shutdown to call through DRM panel. Cc: Robert Chiras <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.21.I20f82e9dd1597a14ae37a64c6b8275add60fbdb1@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.21.I20f82e9dd1597a14ae37a64c6b8275add60fbdb1@changeid
2024-06-11drm/panel: sharp-ls043t1le01: Don't call disable at shutdown/removeDouglas Anderson1-12/+0
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. A grep through mainline for compatible strings used by this driver indicates that it is used by Qualcomm boards. The Qualcomm driver appears to be correctly calling drm_atomic_helper_shutdown() so we can remove the calls. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Werner Johansson <[email protected]> Cc: Dmitry Baryshkov <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.20.I89ee53f7fc2f0806cab318128e5fa927990d830f@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.20.I89ee53f7fc2f0806cab318128e5fa927990d830f@changeid
2024-06-11drm/panel: sharp-ls043t1le01: Stop tracking preparedDouglas Anderson1-12/+0
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Cc: Werner Johansson <[email protected]> Cc: Dmitry Baryshkov <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.19.I56849dbe7c906f0cff076dc5286fd05c7e3e9c18@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.19.I56849dbe7c906f0cff076dc5286fd05c7e3e9c18@changeid
2024-06-11drm/panel: sharp-lq101r1sx01: Don't call disable at shutdown/removeDouglas Anderson1-22/+2
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. A grep through mainline for compatible strings used by this driver indicates that it is used by Tegra boards. The Tegra driver appears to be correctly calling drm_atomic_helper_shutdown() so we can remove the calls. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Thierry Reding <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.18.I6a87fce1ee027c96f71c7adf74248b865f50b336@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.18.I6a87fce1ee027c96f71c7adf74248b865f50b336@changeid
2024-06-11drm/panel: sharp-lq101r1sx01: Stop tracking prepared/enabledDouglas Anderson1-39/+0
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Cc: Thierry Reding <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.17.Ifd6b12b8a4bca7d492e892ea7455e83f5c0ab5a8@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.17.Ifd6b12b8a4bca7d492e892ea7455e83f5c0ab5a8@changeid
2024-06-11drm/panel: seiko-43wvf1g: Don't call disable at shutdown/removeDouglas Anderson1-9/+0
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. A grep through mainline for compatible strings used by this driver indicates that it is used by IMX boards. As far as I can tell, all IMX boards are now correctly calling drm_atomic_helper_shutdown() so we can remove the calls. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Marco Franchi <[email protected]> Cc: Fabio Estevam <[email protected]> Cc: Laurentiu Palcu <[email protected]> Cc: Pengutronix Kernel Team <[email protected]> Cc: [email protected] Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.16.Ief712fb6720cb98bdf9ec8644362d028b6554f9b@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.16.Ief712fb6720cb98bdf9ec8644362d028b6554f9b@changeid
2024-06-11drm/panel: seiko-43wvf1g: Stop tracking prepared/enabledDouglas Anderson1-40/+0
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Cc: Marco Franchi <[email protected]> Cc: Fabio Estevam <[email protected]> Cc: Laurentiu Palcu <[email protected]> Cc: Pengutronix Kernel Team <[email protected]> Cc: [email protected] Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.15.Idda91d310ca2e4f5a4ab4ca6eaf1afdaf14eeb51@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.15.Idda91d310ca2e4f5a4ab4ca6eaf1afdaf14eeb51@changeid
2024-06-11drm/panel: panasonic-vvx10f034n00: Don't call disable at shutdown/removeDouglas Anderson1-12/+0
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. Unfortunately, grepping mainline for this panel's compatible string shows no hits, so we can't be 100% sure if the DRM modeset driver used with this panel has been fixed. If it is found that the DRM modeset driver hasn't been fixed then this patch could be temporarily reverted until it is. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Werner Johansson <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.14.I1562c864ee35a9c166765488c95104b7e4e562da@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.14.I1562c864ee35a9c166765488c95104b7e4e562da@changeid
2024-06-11drm/panel: panasonic-vvx10f034n00: Stop tracking prepared/enabledDouglas Anderson1-34/+1
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Cc: Werner Johansson <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.13.I7278e956ffd1cf686e737834578d4bb3ea527c7f@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.13.I7278e956ffd1cf686e737834578d4bb3ea527c7f@changeid
2024-06-11drm/panel: jdi-lt070me05000: Don't call disable at shutdown/removeDouglas Anderson1-12/+0
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. A grep through mainline for compatible strings used by this driver indicates that it is used by Qualcomm boards. The Qualcomm driver appears to be correctly calling drm_atomic_helper_shutdown() so we can remove the calls. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Vinay Simha BN <[email protected]> Cc: Sumit Semwal <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.12.I5f3426e511e77b93c247e0aac114bd12b2b2a933@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.12.I5f3426e511e77b93c247e0aac114bd12b2b2a933@changeid
2024-06-11drm/panel: jdi-lt070me05000: Stop tracking prepared/enabledDouglas Anderson1-25/+2
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. NOTE: as part of this, transition the panel's direct calls to its disable function in shutdown/remove to call through DRM panel. Cc: Vinay Simha BN <[email protected]> Cc: Sumit Semwal <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.11.I2e991044def6644c18ad8d7d686f4f3006f278de@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.11.I2e991044def6644c18ad8d7d686f4f3006f278de@changeid
2024-06-11drm/panel: tdo-tl070wsh30: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-11/+0
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. Unfortunately, grepping mainline for this panel's compatible string shows no hits, so we can't be 100% sure if the DRM modeset driver used with this panel has been fixed. If it is found that the DRM modeset driver hasn't been fixed then this patch could be temporarily reverted until it is. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Neil Armstrong <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.10.I46ff4e28c260bcd8e81205debd0994e76fd8aeac@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.10.I46ff4e28c260bcd8e81205debd0994e76fd8aeac@changeid
2024-06-11drm/panel: tdo-tl070wsh30: Stop tracking preparedDouglas Anderson1-12/+0
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Cc: Neil Armstrong <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.9.I5025ab14adc2efeef1be1843648547fb725106be@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.9.I5025ab14adc2efeef1be1843648547fb725106be@changeid
2024-06-11drm/panel: osd-osd101t2587-53ts: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-14/+0
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. A grep through mainline for compatible strings used by this driver indicates that it is used by TI OMAP boards. The OMAP driver appears to be correctly calling drm_atomic_helper_shutdown() so we can remove the calls. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Peter Ujfalusi <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.8.Ic533ce1323b94230d4155f9364c2b7c1bc47e798@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.8.Ic533ce1323b94230d4155f9364c2b7c1bc47e798@changeid
2024-06-11drm/panel: osd-osd101t2587-53ts: Stop tracking prepared/enabledDouglas Anderson1-26/+1
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Cc: Peter Ujfalusi <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.7.Ic7f6b4ae48027668940a756090cfc454645d3da4@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.7.Ic7f6b4ae48027668940a756090cfc454645d3da4@changeid
2024-06-11drm/panel: olimex-lcd-olinuxino: Don't call unprepare+disable at removeDouglas Anderson1-3/+0
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. Unfortunately, grepping mainline for this panel's compatible string shows no hits, so we can't be 100% sure if the DRM modeset driver used with this panel has been fixed. If it is found that the DRM modeset driver hasn't been fixed then this patch could be temporarily reverted until it is. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.6.I4c79deffb7551ecfb0378302f8dee1275fd1c060@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.6.I4c79deffb7551ecfb0378302f8dee1275fd1c060@changeid
2024-06-11drm/panel: olimex-lcd-olinuxino: Stop tracking prepared/enabledDouglas Anderson1-41/+0
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.5.I6a96d762be98321e02f56b5864359258d65d9da8@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.5.I6a96d762be98321e02f56b5864359258d65d9da8@changeid
2024-06-11drm/panel: khadas-ts050: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-11/+0
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. Unfortunately, grepping mainline for this panel's compatible string shows no hits, so we can't be 100% sure if the DRM modeset driver used with this panel has been fixed. If it is found that the DRM modeset driver hasn't been fixed then this patch could be temporarily reverted until it is. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Jacobe Zang <[email protected]> Cc: Nicolas Belin <[email protected]> Cc: Neil Armstrong <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.4.I1ee65e7905bf5bf46a0e6c5126ac3c7aa25cb80b@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.4.I1ee65e7905bf5bf46a0e6c5126ac3c7aa25cb80b@changeid
2024-06-11drm/panel: khadas-ts050: Stop tracking prepared/enabledDouglas Anderson1-28/+0
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Cc: Jacobe Zang <[email protected]> Cc: Nicolas Belin <[email protected]> Cc: Neil Armstrong <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.3.Ibed1026f20cab08c90fa376e68c2f23a343e826b@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.3.Ibed1026f20cab08c90fa376e68c2f23a343e826b@changeid
2024-06-11drm/panel: boe-himax8279d: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-17/+0
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. Unfortunately, grepping mainline for this panel's compatible string shows no hits, so we can't be 100% sure if the DRM modeset driver used with this panel has been fixed. If it is found that the DRM modeset driver hasn't been fixed then this patch could be temporarily reverted until it is. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Jerry Han <[email protected]> Cc: Jitao Shi <[email protected]> Cc: Rock Wang <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.2.I19086c524d38f28f746befe85cb39ffda9d2f666@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.2.I19086c524d38f28f746befe85cb39ffda9d2f666@changeid
2024-06-11drm/panel: boe-himax8279d: Stop tracking prepared/enabledDouglas Anderson1-27/+4
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. NOTE: as part of this, transition the panel's direct calls to its disable/unprepare functions in shutdown/remove to call through DRM panel. Cc: Jerry Han <[email protected]> Cc: Jitao Shi <[email protected]> Cc: Rock Wang <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.1.Ia3f254ab6e04e4f7afba6c066454498c8fb01324@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.1.Ia3f254ab6e04e4f7afba6c066454498c8fb01324@changeid
2024-06-11drm/i915: Compute CMRR and calculate vtotalMitul Golani3-11/+83
Compute Fixed Average Vtotal/CMRR with resepect to userspace VRR enablement. Also calculate required parameters in case of CMRR is enabled. During intel_vrr_compute_config, CMRR is getting enabled based on userspace has enabled Variable refresh mode with VRR timing generator or not. Make CMRR as small subset of FAVT mode, when Panel is running on Fixed refresh rate and on VRR framework then only enable CMRR to match with actual refresh rate. --v2: - Update is_cmrr_frac_required function return as bool, not int. [Jani] - Use signed int math instead of unsigned in cmrr_get_vtotal2. [Jani] - Fix typo and usage of camel case in cmrr_get_vtotal. [Jani] - Use do_div in cmrr_get_vtotalwhile calculating cmrr_m. [ Jani] - Simplify cmrr and vrr compute config in intel_vrr_compute_config. [Jani] - Correct valiable name usage in is_cmrr_frac_required. [Ville] --v3: - Removing RFC tag. --v4: - Added edp check to address edp usecase for now. (ville) - Updated is_cmrr_fraction_required to more simplified calculation. - on longterm goal to be worked upon uapi as suggestion from ville. --v5: - Correct vtotal paramas accuracy and add 2 digit precision. - Avoid using DIV_ROUND_UP and improve scanline precision. --v6: - Make CMRR a small subset of FAVT mode. --v7: - Update commit message to avoid confusion with Legacy VRR (Ankit). - Add cmrr.enable in last, so remove from this patch. --v8: - Set cmrr.enable in current patch instead of separate patch (Ankit). - Since vrr.enable and cmrr.enable are not mutually exclusive, handle accordingly (Ankit). - is_edp is not required inside is_cmrr_frac_required function (Ankit). - Add video_mode_required flag for future enhancement. - Correct cmrr_m/cmrr_n calculation. --v9: - Move patch to last and set other bits before computing cmrr.enable.(Ankit) - Add TODO: for to address target refresh rate precision as future enhancement. Signed-off-by: Mitul Golani <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/display: Compute vrr vsync paramsMitul Golani1-8/+9
Compute vrr vsync params in case of FAVT as well instead of only to AVT mode of operation. --v2: - Remove redundant computation for vrr_vsync_start and vrr_vsync_end(Ankit). --v3: - vrr.enable and cmrr.enable check together is not required as both will be true at the same point in time. (Ankit) - Replace vrr.enable flag to cmrr.enable, mistakenly added. (Ankit) Signed-off-by: Mitul Golani <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/display: Compute Adaptive sync SDP paramsMitul Golani1-3/+11
Compute params for Adaptive Sync SDP when Fixed Average Vtotal mode is enabled. --v2: Since vrr.enable is set in case of cmrr also, handle accordingly(Ankit). --v3: - Since vrr.enable is set in case of cmrr also, handle accordingly(Ankit). - check cmrr.enable when CMRR flags are set during intel_dp_compute_as_sdp. --v4: - Use drm_mode_vrefresh instead of manual calculation (Ankit). Signed-off-by: Mitul Golani <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/display: Add support for pack and unpackMitul Golani1-0/+4
Add support of pack and unpack for target_rr_divider. --v2: - Set Target Refresh Rate Divider bit when related AS SDP bit is set (Ankit). --v3: - target_rr_divider is bools so set accordingly (Ankit). Signed-off-by: Mitul Golani <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/dp: Add refresh rate divider to struct representing AS SDPMitul Golani1-0/+1
Add target_rr_divider to structure representing AS SDP. It is valid only in FAVT mode, sink device ignores the bit in AVT mode. --v2: - Update commit header and send patch to dri-devel. Signed-off-by: Mitul Golani <[email protected]> Reviewed-by: Arun R Murthy <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915: Update trans_vrr_ctl flag when cmrr is computedMitul Golani2-2/+10
Add/update trans_vrr_ctl flag when crtc_state->cmrr.enable is set, With this commit setting the stage for subsequent CMRR enablement. --v2: - Check pipe active state in cmrr enabling. [Jani] - Remove usage of bitwise OR on booleans. [Jani] - Revert unrelated changes. [Jani] - Update intel_vrr_enable, vrr and cmrr enable conditions. [Jani] - Simplify whole if-ladder in intel_vrr_enable. [Jani] - Revert patch restructuring mistakes in intel_vrr_get_config. [Jani] --v3: - Check pipe active state in cmrr disabling.[Jani] - Correct messed up condition in intel_vrr_enable. [Jani] --v4: - Removing RFC tag. --v5: - CMRR handling in co-existatnce of LRR and DRRS. --v7: - Rebase on top of AS SDP merge. --v8: - Remove cmrr_enabling/disabling and update commit message. (Ankit) --v9: - Revert removed line(Ankit). Signed-off-by: Mitul Golani <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915: Define and compute Transcoder CMRR registersMitul Golani4-1/+62
Add register definitions for Transcoder Fixed Average Vtotal mode/CMRR function, with the necessary bitfields. Compute these registers when CMRR is enabled, extending Adaptive refresh rate capabilities. --v2: - Use intel_de_read64_2x32 in intel_vrr_get_config. [Jani] - Fix indent and order based on register offset. [Jani] --v3: - Removing RFC tag. --v4: - Update place holder for CMRR register definition. (Jani) --v5: - Add CMRR register definitions to a separate file intel_vrr_reg.h. --v6: - Fixed indentation. (Jani) - Add dependency header intel_display_reg_defs.h. (Jani) - Rename file name to intel_vrr_regs.h instead of reg.h (Jani) --v7: - Remove adding CMRR flag to vrr_ctl register during set_transcoder_timing, as it is already being done during intel_vrr_enable. (Ankit) Signed-off-by: Mitul Golani <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915: Separate VRR related register definitionsMitul Golani3-100/+112
Move VRR related register definitions to a separate file called intel_vrr_regs.h. Signed-off-by: Mitul Golani <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.