summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-06-14accel/ivpu: Disable clock relinquish for MMIO resetWachowski, Karol
It is required to disable NPU clock relinquish for the time of MMIO reset. Clock relinquish gets into default (enabled) state after MMIO reset is performed. Signed-off-by: Wachowski, Karol <karol.wachowski@intel.com> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240611120433.1012423-6-jacek.lawrynowicz@linux.intel.com
2024-06-14accel/ivpu: Disable disable_clock_relinquish WA for LNL B0+Wachowski, Karol
This WA is only needed for LNL revision A. Signed-off-by: Wachowski, Karol <karol.wachowski@intel.com> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240611120433.1012423-5-jacek.lawrynowicz@linux.intel.com
2024-06-14accel/ivpu: Remove suspend_reschedule_counterJacek Lawrynowicz
Don't retry runtime suspend. It is now expected to succeed on the first try. After autosuspend_delay passed, FW should already be idle and ready for warm suspend. Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Reviewed-by: Wachowski, Karol <karol.wachowski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240611120433.1012423-4-jacek.lawrynowicz@linux.intel.com
2024-06-14accel/ivpu: Abort jobs of faulty contextMaciej Falkowski
Abort all jobs that belong to contexts generating MMU faults in order to avoid flooding host with MMU IRQs. Jobs are cancelled with: - SSID_RELEASE command when OS scheduling is enabled - DESTROY_CMDQ command when HW scheduling is enabled Signed-off-by: Maciej Falkowski <maciej.falkowski@intel.com> Co-developed-by: Wachowski, Karol <karol.wachowski@intel.com> Signed-off-by: Wachowski, Karol <karol.wachowski@intel.com> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240611120433.1012423-3-jacek.lawrynowicz@linux.intel.com
2024-06-14accel/ivpu: Add wp0_during_power_up WAWachowski, Karol
Send workpoint 0 request during power up on 37xx. This is needed in rare case where WP0 was not sent during power down due to device hang. Signed-off-by: Wachowski, Karol <karol.wachowski@intel.com> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240611120433.1012423-2-jacek.lawrynowicz@linux.intel.com
2024-06-13drm/bridge: sii902x: Add pixel clock check in atomic_checkJayesh Choudhary
Check the pixel clock for the mode in atomic_check and ensure that it is within the range supported by the bridge. Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240613083805.439337-4-j-choudhary@ti.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-06-13drm/bridge: sii902x: Support atomic bridge APIsJayesh Choudhary
Change exisitig enable() and disable() bridge hooks to their atomic counterparts as the former hooks are deprecated. Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240613083805.439337-3-j-choudhary@ti.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-06-13drm/bridge: sii902x: Fix mode_valid hookJayesh Choudhary
Currently, mode_valid is defined only in drm_connector_helper_funcs. When the bridge is attached with the 'DRM_BRIDGE_ATTACH_NO_CONNECTOR' flag, the connector is not initialized, and so is the mode_valid hook under connector helper funcs. It also returns MODE_OK for all modes without actually checking the modes. So move the mode_valid hook to drm_bridge_funcs with proper clock checks for maximum and minimum pixel clock supported by the bridge. Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240613083805.439337-2-j-choudhary@ti.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-06-13drm/connector: hdmi: Fix kerneldoc warningsMaxime Ripard
It looks like the documentation for the HDMI-related fields recently added to both the drm_connector and drm_connector_state structures trigger some warnings because of their use of anonymous structures: $ scripts/kernel-doc -none include/drm/drm_connector.h include/drm/drm_connector.h:1138: warning: Excess struct member 'broadcast_rgb' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'infoframes' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'avi' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'hdr_drm' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'spd' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'vendor' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'is_limited_range' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'output_bpc' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'output_format' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'tmds_char_rate' description in 'drm_connector_state' include/drm/drm_connector.h:2112: warning: Excess struct member 'vendor' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'product' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'supported_formats' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'infoframes' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'lock' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'audio' description in 'drm_connector' Create some intermediate structures instead of anonymous ones to silence the warnings. Reported-by: Jani Nikula <jani.nikula@linux.intel.com> Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Fixes: 54cb39e2293b ("drm/connector: hdmi: Create an HDMI sub-state") Fixes: 948f01d5e559 ("drm/connector: hdmi: Add support for output format") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240610111200.428224-1-mripard@kernel.org
2024-06-13drm/mgag200: Set .detect_ctx() and enable connector pollingThomas Zimmermann
Set .detect_ctx() in struct drm_connector_helper_funcs to the common helper drm_connector_helper_detect_from_ddc() and enable polling for the connector. Mgag200 will now test for the monitor's presence by probing the DDC in regular intervals. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240610141141.29527-4-tzimmermann@suse.de
2024-06-13drm/mgag200: Add BMC outputThomas Zimmermann
The BMC output can be viewed via the BMC's web interface or a similar client. Represent it as virtual encoder and connector. It's attached to the same CRTC as the VGA connector. The connector's status depends on the physical connector's status. The BMC is only connected if the physical connector is not. This is necessary to support userspace clients that can only handle a single output per CRTC. The BMC is a server feature. Add a BMC output for all server chips, but not the desktop models. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240610141141.29527-3-tzimmermann@suse.de
2024-06-13drm/mgag200: Consolidate VGA outputThomas Zimmermann
The various models have common code for the VGA output's encoder and connector. Move everything into a single shared source file. Remove some obsolete initializer macros. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240610141141.29527-2-tzimmermann@suse.de
2024-06-12drm/panel: himax-hx83102: fix incorrect argument to mipi_dsi_msleepTejas Vipin
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 <tejasvipin76@gmail.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20240612133550.473279-2-tejasvipin76@gmail.com [narmstrong: fixed subject and fixes tag] Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240612133550.473279-2-tejasvipin76@gmail.com
2024-06-12drm/mipi-dsi: fix handling of ctx in mipi_dsi_msleepTejas Vipin
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 <tejasvipin76@gmail.com> Suggested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20240612133550.473279-3-tejasvipin76@gmail.com [narmstrong: fixed fixes tag] Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240612133550.473279-3-tejasvipin76@gmail.com
2024-06-12drm/bridge-connector: implement glue code for HDMI connectorDmitry Baryshkov
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 <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240607-bridge-hdmi-connector-v5-3-ab384e6021af@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-06-12drm/bridge-connector: switch to using drmm allocationsDmitry Baryshkov
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 <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240607-bridge-hdmi-connector-v5-2-ab384e6021af@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-06-12drm/connector: hdmi: allow disabling Audio InfoframeDmitry Baryshkov
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 <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240607-bridge-hdmi-connector-v5-1-ab384e6021af@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-06-11drm/panel: Update TODO list item for cleaning up prepared/enabled trackingDouglas Anderson
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 <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.23.I104cdece7324b0c365e552a17f9883414ffaea01@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> 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 Anderson
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/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.org Cc: Robert Chiras <robert.chiras@nxp.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.22.Id14188f1a8af7d524751c27c343a5b583ff5361f@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.22.Id14188f1a8af7d524751c27c343a5b583ff5361f@changeid
2024-06-11drm/panel: raydium-rm67191: Stop tracking enabledDouglas Anderson
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 <robert.chiras@nxp.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.21.I20f82e9dd1597a14ae37a64c6b8275add60fbdb1@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> 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 Anderson
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/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.org Cc: Werner Johansson <werner.johansson@sonymobile.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.20.I89ee53f7fc2f0806cab318128e5fa927990d830f@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.20.I89ee53f7fc2f0806cab318128e5fa927990d830f@changeid
2024-06-11drm/panel: sharp-ls043t1le01: Stop tracking preparedDouglas Anderson
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 <werner.johansson@sonymobile.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.19.I56849dbe7c906f0cff076dc5286fd05c7e3e9c18@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> 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 Anderson
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/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.org Cc: Thierry Reding <treding@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.18.I6a87fce1ee027c96f71c7adf74248b865f50b336@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.18.I6a87fce1ee027c96f71c7adf74248b865f50b336@changeid
2024-06-11drm/panel: sharp-lq101r1sx01: Stop tracking prepared/enabledDouglas Anderson
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 <treding@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.17.Ifd6b12b8a4bca7d492e892ea7455e83f5c0ab5a8@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> 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 Anderson
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/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.org Cc: Marco Franchi <marco.franchi@nxp.com> Cc: Fabio Estevam <festevam@denx.de> Cc: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: imx@lists.linux.dev Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.16.Ief712fb6720cb98bdf9ec8644362d028b6554f9b@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.16.Ief712fb6720cb98bdf9ec8644362d028b6554f9b@changeid
2024-06-11drm/panel: seiko-43wvf1g: Stop tracking prepared/enabledDouglas Anderson
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 <marco.franchi@nxp.com> Cc: Fabio Estevam <festevam@denx.de> Cc: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: imx@lists.linux.dev Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.15.Idda91d310ca2e4f5a4ab4ca6eaf1afdaf14eeb51@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> 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 Anderson
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/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.org Cc: Werner Johansson <werner.johansson@sonymobile.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.14.I1562c864ee35a9c166765488c95104b7e4e562da@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.14.I1562c864ee35a9c166765488c95104b7e4e562da@changeid
2024-06-11drm/panel: panasonic-vvx10f034n00: Stop tracking prepared/enabledDouglas Anderson
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 <werner.johansson@sonymobile.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.13.I7278e956ffd1cf686e737834578d4bb3ea527c7f@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> 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 Anderson
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/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.org Cc: Vinay Simha BN <simhavcs@gmail.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.12.I5f3426e511e77b93c247e0aac114bd12b2b2a933@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.12.I5f3426e511e77b93c247e0aac114bd12b2b2a933@changeid
2024-06-11drm/panel: jdi-lt070me05000: Stop tracking prepared/enabledDouglas Anderson
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 <simhavcs@gmail.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.11.I2e991044def6644c18ad8d7d686f4f3006f278de@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> 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 Anderson
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/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.org Cc: Neil Armstrong <neil.armstrong@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.10.I46ff4e28c260bcd8e81205debd0994e76fd8aeac@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.10.I46ff4e28c260bcd8e81205debd0994e76fd8aeac@changeid
2024-06-11drm/panel: tdo-tl070wsh30: Stop tracking preparedDouglas Anderson
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 <neil.armstrong@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.9.I5025ab14adc2efeef1be1843648547fb725106be@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> 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 Anderson
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/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.org Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.8.Ic533ce1323b94230d4155f9364c2b7c1bc47e798@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.8.Ic533ce1323b94230d4155f9364c2b7c1bc47e798@changeid
2024-06-11drm/panel: osd-osd101t2587-53ts: Stop tracking prepared/enabledDouglas Anderson
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 <peter.ujfalusi@ti.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.7.Ic7f6b4ae48027668940a756090cfc454645d3da4@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> 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 Anderson
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/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.org Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.6.I4c79deffb7551ecfb0378302f8dee1275fd1c060@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.6.I4c79deffb7551ecfb0378302f8dee1275fd1c060@changeid
2024-06-11drm/panel: olimex-lcd-olinuxino: Stop tracking prepared/enabledDouglas Anderson
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 <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.5.I6a96d762be98321e02f56b5864359258d65d9da8@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> 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 Anderson
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/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.org Cc: Jacobe Zang <jacobe.zang@wesion.com> Cc: Nicolas Belin <nbelin@baylibre.com> Cc: Neil Armstrong <neil.armstrong@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.4.I1ee65e7905bf5bf46a0e6c5126ac3c7aa25cb80b@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.4.I1ee65e7905bf5bf46a0e6c5126ac3c7aa25cb80b@changeid
2024-06-11drm/panel: khadas-ts050: Stop tracking prepared/enabledDouglas Anderson
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 <jacobe.zang@wesion.com> Cc: Nicolas Belin <nbelin@baylibre.com> Cc: Neil Armstrong <neil.armstrong@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.3.Ibed1026f20cab08c90fa376e68c2f23a343e826b@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> 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 Anderson
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/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.org Cc: Jerry Han <jerry.han.hq@gmail.com> Cc: Jitao Shi <jitao.shi@mediatek.com> Cc: Rock Wang <rock_wang@himax.com.cn> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.2.I19086c524d38f28f746befe85cb39ffda9d2f666@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.2.I19086c524d38f28f746befe85cb39ffda9d2f666@changeid
2024-06-11drm/panel: boe-himax8279d: Stop tracking prepared/enabledDouglas Anderson
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 <jerry.han.hq@gmail.com> Cc: Jitao Shi <jitao.shi@mediatek.com> Cc: Rock Wang <rock_wang@himax.com.cn> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240604172305.v3.1.Ia3f254ab6e04e4f7afba6c066454498c8fb01324@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.1.Ia3f254ab6e04e4f7afba6c066454498c8fb01324@changeid
2024-06-10drm/bridge: it6505: update usleep_range for RC circuit charge timeKuro Chung
The spec of timing between IVDD/OVDD and SYSRTEN is 10ms, but SYSRSTN RC circuit need at least 25ms for rising time, update for match spec Signed-off-by: Kuro Chung <kuro.chung@ite.com.tw> Signed-off-by: Hermes Wu <hermes.wu@ite.com.tw> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240604024405.1122488-1-kuro.chung@ite.com.tw
2024-06-10drm/bridge: samsung-dsim: Fix porch calcalcuation roundingAdam Ford
The VFP, HBP, and HSA are divided between the available lanes if there is more than one lane. For certain timings and lane configurations, the HFP may not be evenly divisible. If the HFP is rounded down, it ends up being too small which can cause some monitors to not sync properly. In these instances, adjust htotal and hsync to round the HFP up, and recalculate the htotal. This allows 720P-60 to operation on an i.MX8MP with a four-lane configuration. Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> # Kontron BL i.MX8MM with HDMI monitor Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240601144103.198299-2-aford173@gmail.com
2024-06-10drm/bridge: samsung-dsim: Set P divider based on min/max of fin pllAdam Ford
The P divider should be set based on the min and max values of the fin pll which may vary between different platforms. These ranges are defined per platform, but hard-coded values were used instead which resulted in a smaller range available on the i.MX8M[MNP] than what was possible. As noted by Frieder, there are descripencies between the reference manuals of the Mini, Nano and Plus, so I reached out to my NXP rep and got the following response regarding the varing notes in the documentation. "Yes it is definitely wrong, the one that is part of the NOTE in MIPI_DPHY_M_PLLPMS register table against PMS_P, PMS_M and PMS_S is not correct. I will report this to Doc team, the one customer should be take into account is the Table 13-40 DPHY PLL Parameters and the Note above." With this patch, the clock rates now match the values used in NXP's downstream kernel. Fixes: 846307185f0f ("drm/bridge: samsung-dsim: update PLL reference clock") Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> Reviewed-by: Marek Vasut <marex@denx.de> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240601144103.198299-1-aford173@gmail.com
2024-06-10drm/bridge: tc358767: Check if fully initialized before signalling HPD event ↵Marek Vasut
via IRQ Make sure the connector is fully initialized before signalling any HPD events via drm_kms_helper_hotplug_event(), otherwise this may lead to NULL pointer dereference. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240531203333.277476-1-marex@denx.de
2024-06-10drm/bridge: tc358767: Fix comment in tc_edp_mode_validMarek Vasut
Fix comment copy-paste error in tc_edp_mode_valid(), this function is validating DP/eDP clock, not DPI clock frequency. Update the comment to match. No functional change. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240531203213.277421-1-marex@denx.de
2024-06-10drm/bridge: Drop drm_bridge_chain_mode_fixupSam Ravnborg
There are no users left of drm_bridge_chain_mode_fixup() and we do not want to have this function available, so drop it. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240531-bridge_chain_mode-v1-2-8b49e36c5dd3@ravnborg.org
2024-06-10drm/mediatek: Drop chain_mode_fixup call in mode_valid()Sam Ravnborg
The mode_valid implementation had a call to drm_bridge_chain_mode_fixup() which would be wrong as the mode_valid is not allowed to change anything - only to validate the mode. As the next bridge is often/always a connector the call had no effect anyway. So drop it. From the git history I could see this call was included in the original version of the driver so there was no help there to find out why it was added in the first place. But a lot has changed since the initial driver were added and is seems safe to remove the call now. v4: - Link to v3: https://lore.kernel.org/dri-devel/20220717174454.46616-4-sam@ravnborg.org/ - Rebase, and added acks/rb v3: - Link to v2: https://lore.kernel.org/dri-devel/20211020181901.2114645-6-sam@ravnborg.org/ v2: - Link to v1: https://lore.kernel.org/dri-devel/20210722062246.2512666-6-sam@ravnborg.org/ Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Cc: linux-mediatek@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240531-bridge_chain_mode-v1-1-8b49e36c5dd3@ravnborg.org
2024-06-10drm/panic: Add a kmsg panic screenJocelyn Falempe
Add a kmsg option, which will display the last lines of kmsg, and should be similar to fbcon. Add a drm.panic_screen module parameter, so you can choose between the different panic screens available. two options currently, but more will be added later: * "user": a short message telling the user to reboot the machine. * "kmsg": fill the screen with the last lines of kmsg. You can even change it at runtime by writing to /sys/module/drm/parameters/panic_screen v2: * Use module parameter instead of Kconfig choice (Javier Martinez Canillas) v3: * Add help for module parameter usage in Kconfig (Javier Martivez Canillas) * Fix use of font->height before checking it isn't null. (kernel test robot, Dan Carpenter) Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240603095343.39588-4-jfalempe@redhat.com
2024-06-10drm/panic: Add a set_pixel() callback to drm_scanout_bufferJocelyn Falempe
This allows drivers to draw the pixel, and handle tiling, or specific color formats. v2: * Use fg_color for blit() functions (Javier Martinez Canillas) Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240603095343.39588-3-jfalempe@redhat.com
2024-06-10drm/panic: only draw the foreground color in drm_panic_blit()Jocelyn Falempe
The whole framebuffer is cleared, so it's useless to rewrite the background colored pixels. It allows to simplify the drawing functions, and prepare the work for the set_pixel() callback. v2: * keep fg16/fg24/fg32 as variable name for the blit function. * add drm_panic_is_pixel_fg() to avoid code duplication. both suggested by Javier Martinez Canillas Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240603095343.39588-2-jfalempe@redhat.com
generated by cgit (git 2.34.1) at 2025-07-15 09:46:41 +0000