Skip to content

HDMI and display overlays - #191

Open
quic-vishsain wants to merge 50 commits into
qualcomm-linux:resolute-qcom-develfrom
quic-vishsain:shikra_ubuntu_display
Open

quic-vishsain wants to merge 50 commits into
qualcomm-linux:resolute-qcom-develfrom
quic-vishsain:shikra_ubuntu_display

Conversation

@quic-vishsain

Copy link
Copy Markdown

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

Comment thread drivers/gpu/drm/panel/panel-himax-hx83102.c

@bjordiscollaku Bjordis Collaku (bjordiscollaku) left a comment •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread debian.qcom/config/annotations Outdated
Comment thread debian.qcom/config/annotations Outdated
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>
Comment thread drivers/gpu/drm/drm_bridge.c
Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
@bjordiscollaku

Copy link
Copy Markdown
Contributor

Build check is green and the annotations fix is right, thanks.

Both Semgrep findings are in BACKPORT: commits, and I'd rather not patch upstream code locally to quiet a scanner. Semgrep isn't a required check here, but unresolved review threads do block the merge, so if you're satisfied they're false positives please resolve those two conversations with a one-line note. If either turns out to be real, it should go upstream and come back as a backport.

Same on the license check: the five new .dtso files are flagged for BSD-3-Clause, which the existing shikra DTS files in this tree already use, so I don't think anything needs changing.

@bjordiscollaku
Bjordis Collaku (bjordiscollaku) dismissed their stale review October 26, 2026 21:08

Annotations fix applied and Build check is green.

@quic-vishsain

Copy link
Copy Markdown
Author

Build check is green and the annotations fix is right, thanks.

Both Semgrep findings are in BACKPORT: commits, and I'd rather not patch upstream code locally to quiet a scanner. Semgrep isn't a required check here, but unresolved review threads do block the merge, so if you're satisfied they're false positives please resolve those two conversations with a one-line note. If either turns out to be real, it should go upstream and come back as a backport.

Same on the license check: the five new .dtso files are flagged for BSD-3-Clause, which the existing shikra DTS files in this tree already use, so I don't think anything needs changing.

[Check failure on line 1241 in drivers/gpu/drm/panel/panel-himax-hx83102.c]
Semgrep Finding: reusable-workflows.semgrep_rules.cxx.locret.ret.local-address-returned
Error

Check warning on line 474 in drivers/gpu/drm/drm_bridge.c
Function returns macro-like expression 'ERR_CAST(state)' involving local stack variable 'state'. If the macro expands to the address of the local variable, the returned pointer will be dangling.

Above 2 Semgrep Findings are in BACKPORT commits, patches are already present in qcom-next and backported cleanly from there.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants