Repository navigation
HDMI and display overlays - #191
quic-vishsain wants to merge 50 commits into
Conversation
There was a problem hiding this comment.
Build check / Build is failing, and it's the config check that's stopping it. The two STM options are what trip it.
debian.qcom/config/annotations:228 has CONFIG_ARCH_STM32 as 'n'. DRM_STM is depends on DRM && (ARCH_STM32 || COMPILE_TEST), and COMPILE_TEST is 'n' too, so the symbol can't exist in this flavour. olddefconfig drops it and the check then flags that 'm' doesn't match. debian.master does carry both at 'm', but that's because master has ARCH_STM32=y. The qcom file overrides that to 'n', which is why these sit at '-' here. You left CONFIG_DRM_STM_DSI at '-', which is what the other two should look like:
CONFIG_DRM_STM policy<{'arm64': '-'}>
CONFIG_DRM_STM_LVDS policy<{'arm64': '-'}>
That clears this failure. The build stops at the config check, so I can't tell you what's behind it until it gets past this.
drm_of_find_panel_or_bridge() is widely used, but many callers pass NULL into the @panel or the @bridge arguments, thus making a very partial usage of this rather complex function. Besides, the bridge returned in @bridge is not refcounted, thus making this API unsafe when DRM bridge hotplug will be introduced. Solve both issues for the cases of calls to drm_of_find_panel_or_bridge() with a NULL @panel pointer by adding a new function that only looks for bridges (and is thus much simpler) and increments the refcount of the returned bridge. The new function is identical to drm_of_find_panel_or_bridge() except it: - handles bridge refcounting: uses of_drm_find_and_get_bridge() instead of of_drm_find_bridge() internally to return a refcounted bridge - is simpler to use: just takes no @panel parameter, returns the pointer in the return value instead of a double pointer argument - has a simpler implementation: it is equal to drm_of_find_panel_or_bridge() after removing the code that becomes dead when @panel == NULL Also add this function to drm_bridge.c and not drm_of.c because it returns bridges only. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://patch.msgid.link/20260511-drm-bridge-alloc-getput-panel_or_bridge-v6-2-f61c9e498b3f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…e_state() The drm_atomic_helper_bridge_reset() helper is deprecated in favour of the new atomic_create_state callback. Add drm_atomic_helper_bridge_create_state() as the counterpart helper for this new callback, and make drm_atomic_helper_bridge_reset() call this new helper. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-7-ff399263111b@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
Since we're going to move the drm_private_obj state allocation to a callback, we need to be able to deal with its possible failure. Make drm_private_obj_init return an error code on failure. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-1-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…vate_obj The drm_private_obj initialization was inconsistent with the rest of the KMS objects. Indeed, it required to pass a preallocated state in drm_private_obj_init(), while all the others objects would have a reset callback that would be called later on to create the state. However, reset really is meant to reset the hardware and software state. That it creates an initial state is a side-effect that has been used in all objects but drm_private_obj. This is made more complex since some drm_private_obj, the DisplayPort ones in particular, need to be persistent across and suspend/resume cycle, and such a cycle would call drm_mode_config_reset(). Thus, we need to add a new callback to allocate a pristine state for a given private object. This discussion has also came up during the atomic state readout discussion, so it might be introduced into the other objects later on. Until all drivers are converted to that new allocation pattern, we will only call it if the passed state is NULL. This will be removed eventually. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-2-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…ate_state The bridge implementation relies on a drm_private_obj, that is initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-4-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
to drm_private_obj") introduced a new pattern for allocating drm object
states: atomic_create_state, a dedicated hook that allocates and
initializes a pristine state without any side effect.
The bridge atomic_reset callback is already fallible and in practice
only allocates and initializes state without touching hardware.
However, the reset name does not make this contract clear: callers
and implementers cannot tell from the name alone whether the hardware
will be affected or when the hook is safe to call.
Add an atomic_create_state callback to drm_bridge_funcs to make the
contract explicit: allocate a pristine state, initialize it, no side
effects. The core calls it when available, falling back to
atomic_reset otherwise.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug
Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-6-ff399263111b@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
Now that we have an atomic_create_state callback for drm_private_objs, we can provide a helper for it. It's somewhat different from the other similar helpers though, because we definitely expect drm_private_obj to be subclassed. It wouldn't make sense for a driver to use it as-is. So we can't provide a straight implementation of the atomic_create_state callback, but rather we provide the parts that will deal with the drm_private_obj initialization, and we will leave the allocation and initialization of the subclass to drivers. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-3-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
The KMS framework uses two slightly different definitions for the state
concept. For a given object (plane, CRTC, encoder, etc., so
drm_$OBJECT_state), the state is the entire state of that object.
However, at the device level, drm_atomic_state refers to a state update
for a limited number of objects.
Thus, drm_atomic_state isn't the entire device state, but only the full
state of some objects in that device. This has been an endless source of
confusion and thus bugs.
We can rename the drm_atomic_state structure to drm_atomic_commit to
make it less confusing.
This patch was created using:
rg -l drm_atomic_state | \
xargs sed -i 's/drm_atomic_state/drm_atomic_commit/g; s/drm_atomic_commit_helper/drm_atomic_state_helper/g'
mv drivers/gpu/drm/tests/drm_atomic_state_test.c drivers/gpu/drm/tests/drm_atomic_commit_test.c
Acked-by: Simona Vetter <simona.vetter@ffwll.ch>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260427-drm-drm-atomic-update-v4-1-c0e713bfdf25@kernel.org
Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
This reverts commit c71766e. Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
This reverts commit d0d07d9. Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…o HDMI driver LT9611C(EX/UXD) is an I2C-controlled chip that Receiver signal/dual port mipi dsi and output hdmi, differences in hardware features: - LT9611C: supports 1-port mipi dsi to hdmi 1.4 - LT9611EX: supports 2-port mipi dsi to hdmi 1.4 - LT9611UXD: supports 2-port mipi dsi to hdmi 1.4/2.0 Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Sunyun Yang <syyang@lontium.com> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com> Link: https://patch.msgid.link/20261021-lt9611c-v7-v18-1-4978b94896f1@oss.qualcomm.com Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…iver LT9611C(EX/UXD) is an I2C-controlled chip that receives single or dual port MIPI DSI and outputs HDMI. Differences in hardware features: - LT9611C: supports 1-port MIPI DSI to HDMI 1.4 - LT9611EX: supports 2-port MIPI DSI to HDMI 1.4 - LT9611UXD: supports 2-port MIPI DSI to HDMI 1.4/2.0 The driver supports: - EDID read and mode filtering via custom MCU command protocol - HPD detection and interrupt handling - HDMI audio output via I2S - Firmware upgrade via sysfs - Dual DSI bonded mode for LT9611EX and LT9611UXD variants Signed-off-by: Sunyun Yang <syyang@lontium.com> Co-developed-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com> Link: https://patch.msgid.link/20261021-lt9611c-v7-v18-2-4978b94896f1@oss.qualcomm.com Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
… support Enable the Shikra MDSS display subsystem on the Qualcomm Shikra IQS EVK board and add the Lontium LT9611UXD DSI-to-HDMI bridge node. The LT9611UXD is connected via I2C (bus 4, address 0x41), powered by a GPIO-controlled 3.3V regulator (PM8150 GPIO4) and an always-on 1.8V rail. Reset is on GPIO76 and interrupt on GPIO85. The bridge receives DSI output from MDSS and drives an HDMI-A connector, with the link wired as: DPU -> DSI0 -> LT9611UXD -> HDMI. Regulator and pinctrl labels use generic board-level names (vreg_disp_3p3, bridge_irq_pin, bridge_rst_pin) to decouple them from the bridge chip. Link: https://lore.kernel.org/all/20261015-shikra-work-v5-1-5e075222b60a@oss.qualcomm.com/ Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…overlay Add a DT overlay for CQM and CQS, to enable HDMI output when LT9611UXD DSI-to-HDMI daughter card connected to PDISP1 DSI0 on carrier card. LT9611UXD is connected through I2C4, with reset and interrupt connected to tlmm GPIO76 and GPIO85. Disable the default DSI0 panel dt nodes and enable LT9611UXD bridge for HDMI output. Link: https://lore.kernel.org/all/20261021-shikra_display_overlays-v1-1-adaea735999f@oss.qualcomm.com/ Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…nel overlay Add a DT overlay for IQS, to enable LVDS interface when LVDS daughter card is connected to PDISP1 DSI0 on carrier card. There is SN65DSI84 DSI-to-LVDS bridge on the daughter card which is connected through I2C3 with reset and interrupt connected to tlmm GPIO76 and GPIO85. Backlight is connected to gpio87 with pdm_pwm functionality. Currently this is not supported in linux-next yet, so pull the gpio high. Enable support for AUO G133HAN01 LVDS panel connected to this daughter card and disable the default HDMI bridge and connector in favour of the LVDS panel. Link: https://lore.kernel.org/all/20261021-shikra_display_overlays-v1-3-adaea735999f@oss.qualcomm.com/ Signed-off-by: Anand Tiwari <anand.tiwari@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
Add a DT overlay for IQS, to enable DLC0697 panel when DLC daughter card connected to PDISP1 DSI0 on carrier card. Configure DLC0697 reset GPIO, supplies, pinctrl states and GPIO backlight controlled through PM8150 GPIO 1. Disable the default HDMI bridge and connector in favour of the DSI panel. Link: https://lore.kernel.org/all/20261021-shikra_display_overlays-v1-2-adaea735999f@oss.qualcomm.com/ Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…LI9881C panel Enable the regulator driver for the Raspberry Pi touchscreen V2 power and backlight controller, and the Ilitek ILI9881C DSI panel driver, as modules, for the Raspberry Pi 7 inch DSI panel on the 22-pin JDISP1 DSI0 connector on Qualcomm Shikra EVK, Talos Lyra EVK boards. Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com> Link: https://lore.kernel.org/all/20261021-shikra_display_overlays-v1-4-adaea735999f@oss.qualcomm.com/
…hare panel Describe Waveshare 7" DSI panel which uses ILI9881 as a panel controller. This panel requires two voltags supplies, so add separate iovcc supply. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260418-waveshare-dsi-touch-v4-1-b249f3e702bd@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…overlay Add a DT overlay to enable Raspberry Pi 7-inch DSI panel connected to DSI 22pin on the carrier card. DSI0 from SOC is routed through MUX which can be selected by DIP switch S1016.5 ON for enabling this 22-pin JDISP1 DSI0 connector. Add the regulator and backlight controller at I2C4 address 0x45, Goodix GT911 touch controller, panel power and reset control, and a 2-lane DSI connection. Disable the default HDMI bridge and connector in favour of the RPi DSI panel. Link: https://lore.kernel.org/all/20261021-shikra_display_overlays-v1-5-adaea735999f@oss.qualcomm.com/ Signed-off-by: Shashank Maurya <shashank.maurya@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
… drivers Enable the Waveshare DSI touch GPIO/backlight controller driver and the Jadard JD9365DA-H3 DSI panel driver, as modules, for the Waveshare 8 inch DSI panel on the 22-pin JDISP1 DSI0 connector on the Qualcomm Shikra EVK, Talos Lyra EVK boards. Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com> Link: https://lore.kernel.org/all/20261021-shikra_display_overlays-v1-6-adaea735999f@oss.qualcomm.com/
Remove TOUCHSCREEN_GOODIX from prune.config to enable it. It is used by the touch controllers on the Raspberry Pi 7 inch (GT911) and Waveshare 8 inch (GT9271) DSI panels. Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
The Waveshare DSI TOUCH family of panels has separate on-board GPIO controller, which controls power supplies to the panel and the touch screen and provides reset pins for both the panel and the touchscreen. Also it provides a simple PWM controller for panel backlight. Add bindings for these GPIO controllers. As overall integration might be not very obvious (and it differs significantly from the bindings used by the original drivers), provide complete example with the on-board regulators and the DSI panel. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260507-waveshare-dsi-touch-v5-1-d2ac7ccc22d4@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
The Waveshare DSI TOUCH family of panels has separate on-board GPIO controller, which controls power supplies to the panel and the touch screen and provides reset pins for both the panel and the touchscreen. Also it provides a simple PWM controller for panel backlight. Add support for this GPIO controller. Tested-by: Riccardo Mereu <r.mereu@arduino.cc> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260507-waveshare-dsi-touch-v5-2-d2ac7ccc22d4@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…re panel Describe Waveshare 12.3-DSI-TOUCH-A panel which allegedly uses HX83102 as a panel controller. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260413-waveshare-dsi-touch-v3-1-3aeb53022c32@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…e panel Describe Waveshare 5" and 5" DSI panels which use HX9365-E as a panel controller. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260413-waveshare-dsi-touch-v3-2-3aeb53022c32@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…veshare panel Describe Waveshare DSI panels which use JD9365 as a panel controller. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260413-waveshare-dsi-touch-v3-3-3aeb53022c32@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
… OTA7290B Add schema for the panels using Focaltech OTA7290B controller. For now there is only one such panel, from the Waveshare 8.8 DSI TOUCH-A kit. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260413-waveshare-dsi-touch-v3-5-3aeb53022c32@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
If the DSI panel supports versatile lanes configuration, its driver might require determining the number of DSI data lanes, which is usually specified on the DSI host side of the OF graph. Add new helper as a pair to drm_of_get_data_lanes_count_ep() that lets callers determine number of data-lanes on the remote side of the OF graph. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patch.msgid.link/20260413-waveshare-dsi-touch-v3-6-3aeb53022c32@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
This 720x1600 panel is found in several Motorola/Lenovo smartphones like the Moto G9 Play (guamp). The initialization sequence is based on the datasheet. Add it to the existing HX83102 panel driver. Signed-off-by: Val Packett <val@packett.cool> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260217070121.190108-4-val@packett.cool Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
… control The HTF065H045 panel based on the HX83102 controller does use DCS commands for controlling backlight brightness. Make the driver fall back to DCS when no external backlight has been defined in the device tree, like many other drivers do. Signed-off-by: Val Packett <val@packett.cool> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260217070121.190108-5-val@packett.cool Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
Add support for the Waveshare 12.3" DSI TOUCH-A panel. According to the vendor driver, it uses different mode_flags, so let the panel descriptions override driver-wide defaults. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260413-waveshare-dsi-touch-v3-7-3aeb53022c32@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
Sending DSI commands from the prepare() callback requires DSI link to be up at that point. For DSI hosts is guaranteed only if the panel driver sets the .prepare_prev_first flag. Set it to let these panels work with the DSI hosts which don't power on the link in their .mode_set callback. Reviewed-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patch.msgid.link/20260413-waveshare-dsi-touch-v3-8-3aeb53022c32@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
Simplify hx8394_enable() function by using hx8394_disable() instead of open-coding it and mipi_dsi_msleep() instead of manual checks. Reviewed-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patch.msgid.link/20260413-waveshare-dsi-touch-v3-9-3aeb53022c32@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
Enable support for Waveshare 5.0" and 5.5" DSI TOUCH-A panels. Reviewed-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patch.msgid.link/20260413-waveshare-dsi-touch-v3-10-3aeb53022c32@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…_modes_fixed Use existing helper instead of manually coding it. Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260413-waveshare-dsi-touch-v3-11-3aeb53022c32@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…i05101-01a MIPI-DSI panel The taiguan-xti05101-01a is a 10.1" TFT panel. The MIPI controller on this panel is the same as the other panels here, so add this panel to this driver. Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260214085409.3489057-4-yelangyan@huaqin.corp-partner.google.com Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…ration Several panels support attachment either using 4 DSI lanes or just 2. In some cases, this requires a different panel mode to fulfill clock requirements. Extend the driver to handle such cases by letting the panel description to omit lanes specification and parsing number of lanes from the DT. Reviewed-by: Linus Walleij <linusw@kernel.org> Tested-by: Riccardo Mereu <r.mereu@arduino.cc> Link: https://patch.msgid.link/20260413-waveshare-dsi-touch-v3-12-3aeb53022c32@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
Sending DSI commands from the prepare() callback requires DSI link to be up at that point. For DSI hosts is guaranteed only if the panel driver sets the .prepare_prev_first flag. Set it to let these panels work with the DSI hosts which don't power on the link in their .mode_set callback. Reviewed-by: Linus Walleij <linusw@kernel.org> Tested-by: Riccardo Mereu <r.mereu@arduino.cc> Link: https://patch.msgid.link/20260413-waveshare-dsi-touch-v3-13-3aeb53022c32@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…panels Add configuration for Waveshare 3.4" and 4.0" round DSI panels using JD9365 controller. Tested-by: Riccardo Mereu <r.mereu@arduino.cc> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260413-waveshare-dsi-touch-v3-14-3aeb53022c32@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…anels Add configuration for several Waveshare 8.0" and 10.1" WXGA DSI panels using JD9365 controller Tested-by: Riccardo Mereu <r.mereu@arduino.cc> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260413-waveshare-dsi-touch-v3-15-3aeb53022c32@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…anels Add configuration for Waveshare 9.0" and 10.1" 720p DSI panels using JD9365 controller. Tested-by: Riccardo Mereu <r.mereu@arduino.cc> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260413-waveshare-dsi-touch-v3-16-3aeb53022c32@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
Add devm_drm_panel_add(), devres-managed version of drm_panel_add(). It's not uncommon for the panel drivers to use devres functions for most of the resources. Provide corresponding replacement for drm_panel_add(). Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260413-waveshare-dsi-touch-v3-18-3aeb53022c32@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
Add driver for the panel found on Waveshare 8.8" DSI TOUCH-A kit. It uses ota7290b IC as a controller. Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260413-waveshare-dsi-touch-v3-19-3aeb53022c32@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…setup Several the Waveshare DSI LCD panel kits use DSI2LVDS ICN6202 bridge together with the LVDS panels. Define new compatible for the on-kit bridge setup (it is not itmized and it uses Waveshare prefix since the rest of the integration details are not known). Note: the ICN6202 / ICN6211 bridges are completely handled by the board itself, they should not be programmed by the host (which otherwise might override correct params), etc. As such, it doesn't make sense to use those in the compat strings. I consider those to be an internal detail of the setup. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260412-ws-lcd-v3-1-db22c2631828@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…anels Several Waveshare DSI LCD kits use LVDS panels and the ICN6202 DSI2LVDS bridge. Support that setup by handling waveshare,dsi2lvds compatible. The only difference with the existing waveshare,dsi2dpi is the bridge's output type (LVDS vs DPI). Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260412-ws-lcd-v3-2-db22c2631828@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…panel overlay Add a DT overlay to enable Waveshare 8-inch DSI panel connected to DSI 22pin on the carrier card. DSI0 from SOC is routed through MUX which can be selected by DIP switch S1016.5 ON, for enabling this 22-pin JDISP1 DSI0 connector. Add the JD9365DA-H3 panel, GPIO expander at I2C4 address 0x45 for panel power, reset and backlight, and the Goodix GT9271 touch controller. Disable the default HDMI bridge and connector in favour of the Waveshare DSI panel. Link: https://lore.kernel.org/all/20261021-shikra_display_overlays-v1-7-adaea735999f@oss.qualcomm.com/ Signed-off-by: Shashank Maurya <shashank.maurya@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
Remove sn65dsi83 from prune.config to enable it Signed-off-by: Anand Tiwari <anand.tiwari@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…upport Enable STMicroelectronics STM32 display support as module. This includes: * DRM_STM * DRM_STM_LVDS * BACKLIGHT_GPIO * TOUCHSCREEN_ILI210X This display is used on several SoCs and boards such as STM32MP257F-EV1 and STM32MP257F-DK. Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Tested-by: Yannick Fertre <yannick.fertre@foss.st.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260205-master-v1-1-dcefcabc2934@foss.st.com Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Anand Tiwari <anand.tiwari@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
…DS output The current DSI mode configuration enables VIDEO_BURST and disables horizontal front porch (HFP) and back porch (HBP) transmission using MIPI_DSI_MODE_VIDEO_NO_HFP and MIPI_DSI_MODE_VIDEO_NO_HBP. However, the SN65DSI83/84 bridge relies on receiving full horizontal timing information over DSI in order to correctly reconstruct the LVDS output timings. When HFP and HBP are not transmitted, the bridge cannot recreate the required timing parameters, resulting in unstable or missing display output on some panels. Additionally, while burst mode is supported by the hardware, its use depends on continuous clock behavior from the DSI host. In practice, burst mode may introduce instability depending on the host controller implementation, as the DSI link may transition to low-power state between bursts. In testing, removing burst mode and ensuring full horizontal timing transmission results in stable LVDS output across affected panels. Update the DSI mode flags to: - Drop MIPI_DSI_MODE_VIDEO_BURST - Drop MIPI_DSI_MODE_VIDEO_NO_HFP - Drop MIPI_DSI_MODE_VIDEO_NO_HBP This aligns with common system configurations where non-burst mode is preferred and full timing information is transmitted over DSI. Link: https://lore.kernel.org/all/20260412053811.662461-2-tessolveupstream@gmail.com/ Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com> Signed-off-by: Anand Tiwari <anand.tiwari@oss.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
449e1dc to
6f7a01a
Compare
Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
6f7a01a to
475e8e9
Compare
|
Build check is green and the annotations fix is right, thanks. Both Semgrep findings are in Same on the license check: the five new |
Annotations fix applied and Build check is green.
[Check failure on line 1241 in drivers/gpu/drm/panel/panel-himax-hx83102.c] Check warning on line 474 in drivers/gpu/drm/drm_bridge.c Above 2 Semgrep Findings are in BACKPORT commits, patches are already present in qcom-next and backported cleanly from there. |
shikra-cqm-cqs-evk-hdmi: HDMI output for CQM/CQS with LT9611UXD
daughter card
shikra-iqs-evk-dlc-panel: DLC0697 DSI panel for IQS with DLC daughter
card
shikra-iqs-evk-lvds-auo,g133han01: AUO G133HAN01 LVDS panel for IQS
with LVDS daughter card
shikra-iqs-evk-raspberrypi-dsi-7inch: Raspberry Pi 7-inch DSI
panel with touch via the 22-pin JDISP1 DSI0 connector for IQS
shikra-iqs-evk-waveshare-dsi-8inch: Waveshare 8-inch DSI panel
with touch via the 22-pin JDISP1 DSI0 connector for IQS
CRs-Fixed: 4718841