]> www.infradead.org Git - users/jedix/linux-maple.git/log
users/jedix/linux-maple.git
6 weeks agodrm/msm: Fix inverted WARN_ON() logic
Rob Clark [Fri, 13 Jun 2025 14:41:44 +0000 (07:41 -0700)]
drm/msm: Fix inverted WARN_ON() logic

We want to WARN_ON() if info is NULL.

Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Fixes: 0838fc3e6718 ("drm/msm/adreno: Check for recognized GPU before bind")
Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Reported-by: Alexey Klimov <alexey.klimov@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/658631/

6 weeks agodrm/msm/adreno: Check for recognized GPU before bind
Rob Clark [Mon, 9 Jun 2025 18:24:37 +0000 (11:24 -0700)]
drm/msm/adreno: Check for recognized GPU before bind

If we have a newer dtb than kernel, we could end up in a situation where
the GPU device is present in the dtb, but not in the drivers device
table.  We don't want this to prevent the display from probing.  So
check that we recognize the GPU before adding the GPU component.

v2: use %pOF

Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/657701/

6 weeks agodrm/msm/adreno: Pass device_node to find_chipid()
Rob Clark [Mon, 9 Jun 2025 18:24:36 +0000 (11:24 -0700)]
drm/msm/adreno: Pass device_node to find_chipid()

We are going to want to re-use this before the component is bound, when
we don't yet have the device pointer (but we do have the of node).

v2: use %pOF

Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/657705/

6 weeks agodrm/msm: Rename add_components_mdp()
Rob Clark [Mon, 9 Jun 2025 18:24:35 +0000 (11:24 -0700)]
drm/msm: Rename add_components_mdp()

To better match add_gpu_components().

Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/657700/

6 weeks agodrivers: gpu: drm: msm: registers: improve reproducibility
Ryan Eatmon [Sat, 24 May 2025 15:55:37 +0000 (21:25 +0530)]
drivers: gpu: drm: msm: registers: improve reproducibility

The files generated by gen_header.py capture the source path to the
input files and the date.  While that can be informative, it varies
based on where and when the kernel was built as the full path is
captured.

Since all of the files that this tool is run on is under the drivers
directory, this modifies the application to strip all of the path before
drivers.  Additionally it prints <stripped> instead of the date.

Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Viswanath Kraleti <viswanath.kraleti@oss.qualcomm.com>
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/655599/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
6 weeks agodrm/msm/a7xx: Call CP_RESET_CONTEXT_STATE
Connor Abbott [Tue, 20 May 2025 22:28:06 +0000 (18:28 -0400)]
drm/msm/a7xx: Call CP_RESET_CONTEXT_STATE

Calling this packet is necessary when we switch contexts because there
are various pieces of state used by userspace to synchronize between BR
and BV that are persistent across submits and we need to make sure that
they are in a "safe" state when switching contexts. Otherwise a
userspace submission in one context could cause another context to
function incorrectly and hang, effectively a denial of service (although
without leaking data). This was missed during initial a7xx bringup.

Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support")
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/654924/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
6 weeks agodrm/msm: Fix CP_RESET_CONTEXT_STATE bitfield names
Connor Abbott [Tue, 20 May 2025 22:28:05 +0000 (18:28 -0400)]
drm/msm: Fix CP_RESET_CONTEXT_STATE bitfield names

Based on kgsl.

Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support")
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/654922/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
6 weeks agodrm/msm: Temporarily disable stall-on-fault after a page fault
Connor Abbott [Tue, 20 May 2025 19:08:59 +0000 (15:08 -0400)]
drm/msm: Temporarily disable stall-on-fault after a page fault

When things go wrong, the GPU is capable of quickly generating millions
of faulting translation requests per second. When that happens, in the
stall-on-fault model each access will stall until it wins the race to
signal the fault and then the RESUME register is written. This slows
processing page faults to a crawl as the GPU can generate faults much
faster than the CPU can acknowledge them. It also means that all
available resources in the SMMU are saturated waiting for the stalled
transactions, so that other transactions such as transactions generated
by the GMU, which shares translation resources with the GPU, cannot
proceed. This causes a GMU watchdog timeout, which leads to a failed
reset because GX cannot collapse when there is a transaction pending and
a permanently hung GPU.

On older platforms with qcom,smmu-v2, it seems that when one transaction
is stalled subsequent faulting transactions are terminated, which avoids
this problem, but the MMU-500 follows the spec here.

To work around these problems, disable stall-on-fault as soon as we get a
page fault until a cooldown period after pagefaults stop. This allows
the GMU some guaranteed time to continue working. We only use
stall-on-fault to halt the GPU while we collect a devcoredump and we
always terminate the transaction afterward, so it's fine to miss some
subsequent page faults. We also keep it disabled so long as the current
devcoredump hasn't been deleted, because in that case we likely won't
capture another one if there's a fault.

After this commit HFI messages still occasionally time out, because the
crashdump handler doesn't run fast enough to let the GMU resume, but the
driver seems to recover from it. This will probably go away after the
HFI timeout is increased.

Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/654891/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
6 weeks agodrm/msm: Delete resume_translation()
Connor Abbott [Tue, 20 May 2025 19:08:58 +0000 (15:08 -0400)]
drm/msm: Delete resume_translation()

Unused since the previous commit.

Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/654890/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
6 weeks agodrm/msm: Don't use a worker to capture fault devcoredump
Connor Abbott [Tue, 20 May 2025 19:08:57 +0000 (15:08 -0400)]
drm/msm: Don't use a worker to capture fault devcoredump

Now that we use a threaded IRQ, it should be safe to do this in the
fault handler.

We can also remove fault_info from struct msm_gpu and just pass it
directly.

Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/654889/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
6 weeks agodrm/msm: Fix another leak in the submit error path
Rob Clark [Wed, 14 May 2025 16:33:33 +0000 (09:33 -0700)]
drm/msm: Fix another leak in the submit error path

put_unused_fd() doesn't free the installed file, if we've already done
fd_install().  So we need to also free the sync_file.

Signed-off-by: Rob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/653583/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
6 weeks agodrm/msm: Fix a fence leak in submit error path
Rob Clark [Wed, 14 May 2025 16:33:32 +0000 (09:33 -0700)]
drm/msm: Fix a fence leak in submit error path

In error paths, we could unref the submit without calling
drm_sched_entity_push_job(), so msm_job_free() will never get
called.  Since drm_sched_job_cleanup() will NULL out the
s_fence, we can use that to detect this case.

Signed-off-by: Rob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/653584/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
7 weeks agodrm/msm/dsi/dsi_phy_10nm: Fix missing initial VCO rate
Krzysztof Kozlowski [Tue, 20 May 2025 11:13:26 +0000 (13:13 +0200)]
drm/msm/dsi/dsi_phy_10nm: Fix missing initial VCO rate

Driver unconditionally saves current state on first init in
dsi_pll_10nm_init(), but does not save the VCO rate, only some of the
divider registers.  The state is then restored during probe/enable via
msm_dsi_phy_enable() -> msm_dsi_phy_pll_restore_state() ->
dsi_10nm_pll_restore_state().

Restoring calls dsi_pll_10nm_vco_set_rate() with
pll_10nm->vco_current_rate=0, which basically overwrites existing rate of
VCO and messes with clock hierarchy, by setting frequency to 0 to clock
tree.  This makes anyway little sense - VCO rate was not saved, so
should not be restored.

If PLL was not configured configure it to minimum rate to avoid glitches
and configuring entire in clock hierarchy to 0 Hz.

Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/sz4kbwy5nwsebgf64ia7uq4ee7wbsa5uy3xmlqwcstsbntzcov@ew3dcyjdzmi2/
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Fixes: a4ccc37693a2 ("drm/msm/dsi_pll_10nm: restore VCO rate during
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/654796/
Link: https://lore.kernel.org/r/20250520111325.92352-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
7 weeks agodrm/msm/disp: Correct porch timing for SDM845
James A. MacInnes [Wed, 12 Feb 2025 23:03:47 +0000 (15:03 -0800)]
drm/msm/disp: Correct porch timing for SDM845

Type-C DisplayPort inoperable due to incorrect porch settings.
- Re-used wide_bus_en as flag to prevent porch shifting

Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
Signed-off-by: James A. MacInnes <james.a.macinnes@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/636945/
Link: https://lore.kernel.org/r/20250212-sdm845_dp-v2-2-4954e51458f4@gmail.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
7 weeks agodrm/msm/dp: Disable wide bus support for SDM845
James A. MacInnes [Wed, 12 Feb 2025 23:03:46 +0000 (15:03 -0800)]
drm/msm/dp: Disable wide bus support for SDM845

When widebus was enabled for DisplayPort in commit c7c412202623
("drm/msm/dp: enable widebus on all relevant chipsets") it was clarified
that it is only supported on DPU 5.0.0 onwards which includes SC7180 on
DPU revision 6.2.  However, this patch missed that the description
structure for SC7180 is also reused for SDM845 (because of identical
io_start address) which is only DPU 4.0.0, leading to a wrongly enbled
widebus feature and corruption on that platform.

Create a separate msm_dp_desc_sdm845 structure for this SoC compatible,
with the wide_bus_supported flag turned off.

Fixes: c7c412202623 ("drm/msm/dp: enable widebus on all relevant chipsets")
Signed-off-by: James A. MacInnes <james.a.macinnes@gmail.com>
[DB: reworded commit text following Marijn's suggestion]
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/636944/
Link: https://lore.kernel.org/r/20250212-sdm845_dp-v2-1-4954e51458f4@gmail.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
7 weeks agoMAINTAINERS: .mailmap: update Rob Clark's email address
Rob Clark [Wed, 4 Jun 2025 17:55:58 +0000 (10:55 -0700)]
MAINTAINERS: .mailmap: update Rob Clark's email address

Remap historical email addresses to @oss.qualcomm.com.

Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Patchwork: https://patchwork.freedesktop.org/patch/656974/

7 weeks agomailmap: Update entry for Akhil P Oommen
Akhil P Oommen [Tue, 3 Jun 2025 12:15:06 +0000 (17:45 +0530)]
mailmap: Update entry for Akhil P Oommen

A new policy within qualcomm requires me to use a new email address
for all future contributions to Linux kernel. Update the mailmap to
map my old email addresses to the new one, ie akhilpo@oss.qualcomm.com

Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Link: https://lore.kernel.org/lkml/20250603121508.296678-1-quic_akhilpo@quicinc.com
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
7 weeks agoMAINTAINERS: update my email address
Abhinav Kumar [Fri, 23 May 2025 18:27:27 +0000 (11:27 -0700)]
MAINTAINERS: update my email address

My current email address will stop working soon. Use
linux.dev email instead.

Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/655555/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
7 weeks agoMAINTAINERS: drop myself as maintainer
Abhinav Kumar [Fri, 23 May 2025 18:27:26 +0000 (11:27 -0700)]
MAINTAINERS: drop myself as maintainer

I will no longer regularly work on this platform. Hence will
step down from maintainer duties.

Also, add Jessica as a reviewer to the MSM DRM subsystem to help
out with the reviews.

Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/655558/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2 months agodt-bindings: display: msm: correct example in SM8350 MDSS schema
Dmitry Baryshkov [Mon, 5 May 2025 12:56:26 +0000 (15:56 +0300)]
dt-bindings: display: msm: correct example in SM8350 MDSS schema

Fix the interconnects in the example to follow the schema changes.

Fixes: 60b8d3a2365a ("dt-bindings: display: msm: sm8350-mdss: Describe the CPU-CFG icc path")
Reported-by: Rob Herring <robh@kernel.org>
Closes: http://lore.kernel.org/r/CAL_JsqKr8Xd8uxFzE0YJTyD+V6N++VV8SX-GB5Xt0_BKkeoGUQ@mail.gmail.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/651775/
Link: https://lore.kernel.org/r/20250505-sm8350-fix-example-v1-1-36d5d9ccba66@oss.qualcomm.com
2 months agodt-bindings: display/msm: hdmi: Fix constraints on additional 'port' properties
Rob Herring (Arm) [Wed, 7 May 2025 21:59:12 +0000 (16:59 -0500)]
dt-bindings: display/msm: hdmi: Fix constraints on additional 'port' properties

The MSM HDMI port nodes are missing any restrictions on additional
properties. The $ref should be to "/properties/port" rather than
"/$defs/port-base" as there are not additional properties in the nodes
to define.

Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/652299/
Link: https://lore.kernel.org/r/20250507215912.2748964-1-robh@kernel.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dp: Introduce link training per-segment for LTTPRs
Aleksandrs Vinarskis [Wed, 7 May 2025 22:59:02 +0000 (00:59 +0200)]
drm/msm/dp: Introduce link training per-segment for LTTPRs

DisplayPort requires per-segment link training when LTTPR are switched
to non-transparent mode, starting with LTTPR closest to the source.
Only when each segment is trained individually, source can link train
to sink.

Implement per-segment link traning when LTTPR(s) are detected, to
support external docking stations. On higher level, changes are:

* Pass phy being trained down to all required helpers
* Run CR, EQ link training per phy
* Set voltage swing, pre-emphasis levels per phy

Since at least some LTTPRs (eg. Parade PS8830) do not correctly report
voltage-swing, pre-emphasis level 3 support, always assume level 3 is
supported. This is permitted under DP 2.1(a) section 3.6.7.2 stating
that LTTPR shall set its transmitter levels as close as possible to
those requested by the DPTX, if the DPTX sets the voltage swing or
pre-emphasis to a level that the LTTPR does not support. It shall be
noted that LTTPR’s level choosing is implementation-specific.

This ensures successful link training both when connected directly to
the monitor (single LTTPR onboard most X1E laptops) and via the docking
station (at least two LTTPRs).

Fixes: 72d0af4accd9 ("drm/msm/dp: Add support for LTTPR handling")
Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com> # SA8775P
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Tested-by: Rob Clark <robdclark@gmail.com>
Tested-by: Stefan Schmidt <stefan.schmidt@linaro.org>
Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/652305/
Link: https://lore.kernel.org/r/20250507230113.14270-5-alex.vinarskis@gmail.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dp: Prepare for link training per-segment for LTTPRs
Aleksandrs Vinarskis [Wed, 7 May 2025 22:59:01 +0000 (00:59 +0200)]
drm/msm/dp: Prepare for link training per-segment for LTTPRs

Per-segment link training requires knowing the number of LTTPRs
(if any) present. Store the count during LTTPRs' initialization.

Fixes: 72d0af4accd9 ("drm/msm/dp: Add support for LTTPR handling")
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com> # SA8775P
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Tested-by: Rob Clark <robdclark@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/652306/
Link: https://lore.kernel.org/r/20250507230113.14270-4-alex.vinarskis@gmail.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dp: Account for LTTPRs capabilities
Aleksandrs Vinarskis [Wed, 7 May 2025 22:59:00 +0000 (00:59 +0200)]
drm/msm/dp: Account for LTTPRs capabilities

Take into account LTTPR capabilities when selecting maximum allowed
link rate, number of data lines.

Fixes: 72d0af4accd9 ("drm/msm/dp: Add support for LTTPR handling")
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com> # SA8775P
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Tested-by: Rob Clark <robdclark@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/652302/
Link: https://lore.kernel.org/r/20250507230113.14270-3-alex.vinarskis@gmail.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dp: Fix support of LTTPR initialization
Aleksandrs Vinarskis [Wed, 7 May 2025 22:58:59 +0000 (00:58 +0200)]
drm/msm/dp: Fix support of LTTPR initialization

Initialize LTTPR before msm_dp_panel_read_sink_caps, as DPTX shall
(re)read DPRX caps after LTTPR detection, as required by DP 2.1a,
Section 3.6.7.6.1.

Fixes: 72d0af4accd9 ("drm/msm/dp: Add support for LTTPR handling")
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com> # SA8775P
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Tested-by: Rob Clark <robdclark@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/652301/
Link: https://lore.kernel.org/r/20250507230113.14270-2-alex.vinarskis@gmail.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: remove DPU_CTL_SPLIT_DISPLAY from SAR2130P CTL blocks
Dmitry Baryshkov [Wed, 7 May 2025 13:29:06 +0000 (16:29 +0300)]
drm/msm/dpu: remove DPU_CTL_SPLIT_DISPLAY from SAR2130P CTL blocks

Follow the changes in the commit a2649952f66e ("drm/msm/dpu: remove
DPU_CTL_SPLIT_DISPLAY from CTL blocks on DPU >= 5.0") and remove
DPU_CTL_SPLIT_DISPLAY from the CTL blocks on the SAR2130P platform.
Single CTL is used for all interfaces used by a single path

Fixes: 178575173472 ("drm/msm/dpu: add catalog entry for SAR2130P")
Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/651883/
Link: https://lore.kernel.org/r/20250506-dpu-sar2130p-no-split-display-v1-1-b619c0fddea5@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: Add handling of LM_6 and LM_7 bits in pending flush mask
Krzysztof Kozlowski [Wed, 30 Apr 2025 13:00:43 +0000 (15:00 +0200)]
drm/msm/dpu: Add handling of LM_6 and LM_7 bits in pending flush mask

MDSS/MDP v12 comes with new bits in flush registers (e.g.
MDP_CTL_0_FLUSH) for Layer Mixer 6 and 7.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651260/
Link: https://lore.kernel.org/r/20250430-b4-sm8750-display-v5-13-8cab30c3e4df@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: Add LM_7, DSC_[67], PP_[67] and MERGE_3D_5
Krzysztof Kozlowski [Wed, 30 Apr 2025 13:00:42 +0000 (15:00 +0200)]
drm/msm/dpu: Add LM_7, DSC_[67], PP_[67] and MERGE_3D_5

Add IDs for new blocks present in MDSS/MDP v12 for LM, DSC, PINGPONG and
MERGE_3D blocks.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651262/
Link: https://lore.kernel.org/r/20250430-b4-sm8750-display-v5-12-8cab30c3e4df@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: Drop useless comments
Krzysztof Kozlowski [Wed, 30 Apr 2025 13:00:41 +0000 (15:00 +0200)]
drm/msm/dpu: Drop useless comments

Drop comments about SoC before each 'struct dpu_lm_sub_blks' for given
SoC because it's duplicating the actual name of structure.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651251/
Link: https://lore.kernel.org/r/20250430-b4-sm8750-display-v5-11-8cab30c3e4df@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: Clear CTL_FETCH_PIPE_ACTIVE before blend setup
Krzysztof Kozlowski [Wed, 30 Apr 2025 13:00:40 +0000 (15:00 +0200)]
drm/msm/dpu: Clear CTL_FETCH_PIPE_ACTIVE before blend setup

Before blend setup, all existing blend stages are cleared, so shall be
active fetch pipes.

Fixes: b3652e87c03c ("drm/msm/disp/dpu1: add support to program fetch active in ctl path")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651263/
Link: https://lore.kernel.org/r/20250430-b4-sm8750-display-v5-10-8cab30c3e4df@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: Clear CTL_FETCH_PIPE_ACTIVE on ctl_path reset
Krzysztof Kozlowski [Wed, 30 Apr 2025 13:00:39 +0000 (15:00 +0200)]
drm/msm/dpu: Clear CTL_FETCH_PIPE_ACTIVE on ctl_path reset

Resetting entire CTL path should also include resetting active fetch
pipes.

Fixes: e1a950eec256 ("drm/msm/dpu: add reset_intf_cfg operation for dpu_hw_ctl")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651252/
Link: https://lore.kernel.org/r/20250430-b4-sm8750-display-v5-9-8cab30c3e4df@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: Clear CTL_FETCH_PIPE_ACTIVE on mixer reset
Krzysztof Kozlowski [Wed, 30 Apr 2025 13:00:38 +0000 (15:00 +0200)]
drm/msm/dpu: Clear CTL_FETCH_PIPE_ACTIVE on mixer reset

Resetting mixers should also include resetting active fetch pipes.

Fixes: ae4d721ce100 ("drm/msm/dpu: add an API to reset the encoder related hw blocks")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651246/
Link: https://lore.kernel.org/r/20250430-b4-sm8750-display-v5-8-8cab30c3e4df@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: Add missing "fetch" name to set_active_pipes()
Krzysztof Kozlowski [Wed, 30 Apr 2025 13:00:37 +0000 (15:00 +0200)]
drm/msm/dpu: Add missing "fetch" name to set_active_pipes()

The set_active_pipes() callback configures CTL_FETCH_PIPE_ACTIVE and
newer DPU v12.0 comes with CTL_PIPE_ACTIVE, thus rename it to
set_active_fetch_pipes() to better match the purpose.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651261/
Link: https://lore.kernel.org/r/20250430-b4-sm8750-display-v5-7-8cab30c3e4df@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/hdmi: wire in hpd_enable/hpd_disable bridge ops
Dmitry Baryshkov [Mon, 5 May 2025 00:55:47 +0000 (03:55 +0300)]
drm/msm/hdmi: wire in hpd_enable/hpd_disable bridge ops

The HDMI driver already has msm_hdmi_hpd_enable() and
msm_hdmi_hpd_disable() functions. Wire them into the
msm_hdmi_bridge_funcs, so that HPD  can be enabled and disabled
dynamically rather than always having HPD events generation enabled.

Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-13-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/hdmi: ensure that HDMI is up if HPD is requested
Dmitry Baryshkov [Mon, 5 May 2025 00:14:56 +0000 (03:14 +0300)]
drm/msm/hdmi: ensure that HDMI is up if HPD is requested

The HDMI block needs to be enabled to properly generate HPD events. Make
sure it is not turned off in the disable paths if HPD delivery is enabled.

Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651722/
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-12-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/hdmi: expand the HDMI_CFG macro
Dmitry Baryshkov [Mon, 5 May 2025 00:14:55 +0000 (03:14 +0300)]
drm/msm/hdmi: expand the HDMI_CFG macro

Expand the HDMI_CFG() macro in HDMI config description. It has no added
value other than hiding some boilerplate declarations.

Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651724/
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-11-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/hdmi: rename hpd_clks to pwr_clks
Dmitry Baryshkov [Mon, 5 May 2025 00:14:54 +0000 (03:14 +0300)]
drm/msm/hdmi: rename hpd_clks to pwr_clks

As these clocks are now used in the runtime PM callbacks, they have no
connection to 'HPD'. Rename corresponding fields to follow clocks
purpose, to power up the HDMI controller.

Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651720/
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-10-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/hdmi: implement proper runtime PM handling
Dmitry Baryshkov [Mon, 5 May 2025 00:14:53 +0000 (03:14 +0300)]
drm/msm/hdmi: implement proper runtime PM handling

It is completely not obvious, but the so-called 'hpd' clocks and
regulators are required for the HDMI host to function properly. Merge
pwr and hpd regulators. Use regulators, clocks and pinctrl to implement
proper runtime PM callbacks.

Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651715/
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-9-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/hdmi: add runtime PM calls to DDC transfer function
Dmitry Baryshkov [Mon, 5 May 2025 00:14:52 +0000 (03:14 +0300)]
drm/msm/hdmi: add runtime PM calls to DDC transfer function

We must be sure that the HDMI controller is powered on, while performing
the DDC transfer. Add corresponding runtime PM calls to
msm_hdmi_i2c_xfer().

Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651727/
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-8-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/hdmi: switch to pm_runtime_resume_and_get()
Dmitry Baryshkov [Mon, 5 May 2025 00:14:51 +0000 (03:14 +0300)]
drm/msm/hdmi: switch to pm_runtime_resume_and_get()

The pm_runtime_get_sync() function is a bad choise for runtime power
management. Switch HDMI driver to pm_runtime_resume_and_get() and add
proper error handling, while we are at it.

Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651713/
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-7-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/hdmi: switch to clk_bulk API
Dmitry Baryshkov [Mon, 5 May 2025 00:14:50 +0000 (03:14 +0300)]
drm/msm/hdmi: switch to clk_bulk API

The last platform using legacy clock names for HDMI block (APQ8064)
switched to new clock names in 5.16. It's time to stop caring about old
DT, drop hand-coded helpers and switch to clk_bulk_* API.

Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651716/
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-6-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/hdmi: drop clock frequency assignment
Dmitry Baryshkov [Mon, 5 May 2025 00:14:49 +0000 (03:14 +0300)]
drm/msm/hdmi: drop clock frequency assignment

The only clock which has frequency being set through hpd_freqs is the
"core" aka MDSS_HDMI_CLK clock. It always has the specified frequency,
so we can drop corresponding clk_set_rate() call together with the
hpd_freq infrastructure.

Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651717/
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-5-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/hdmi: simplify extp clock handling
Dmitry Baryshkov [Mon, 5 May 2025 00:14:48 +0000 (03:14 +0300)]
drm/msm/hdmi: simplify extp clock handling

With the extp being the only "power" clock left, remove the surrounding
loops and handle the extp clock directly.

Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651710/
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-4-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/hdmi: move the alt_iface clock to the hpd list
Dmitry Baryshkov [Mon, 5 May 2025 00:14:47 +0000 (03:14 +0300)]
drm/msm/hdmi: move the alt_iface clock to the hpd list

According to the vendor kernel [1] , the alt_iface clock should be
enabled together with the rest of HPD clocks, to make HPD to work
properly.

[1] https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/commit/e07a5487e521e57f76083c0a6e2f995414ac6d03

Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651709/
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-3-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/hdmi: convert clock and regulator arrays to const arrays
Dmitry Baryshkov [Mon, 5 May 2025 00:14:46 +0000 (03:14 +0300)]
drm/msm/hdmi: convert clock and regulator arrays to const arrays

As a preparation to the next patches convert 'static const char *'
arrays to 'static const char * const', as required by the checkpatch.pl

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/651705/
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-2-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodt-bindings: display/msm/hdmi: drop obsolete GPIOs from schema
Dmitry Baryshkov [Mon, 5 May 2025 00:14:45 +0000 (03:14 +0300)]
dt-bindings: display/msm/hdmi: drop obsolete GPIOs from schema

The commit 68e674b13b17 ("drm/msm/hdmi: drop unused GPIO support")
dropped support for obsolete qcom,hdmi-tx-mux-* gpios. They were not
used by any of the upstream platforms. Drop them from the bindings too.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651708/
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-1-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/adreno: Remove MODULE_FIRMWARE()'s
Rob Clark [Wed, 7 May 2025 15:47:22 +0000 (08:47 -0700)]
drm/msm/adreno: Remove MODULE_FIRMWARE()'s

The driver handles the case where gpu fw is not in the initrd.  OTOH it
doesn't always handle the case where _some_ fw is in the initrd, but
others are not.  In particular the zap fw tends to be signed with an OEM
specific key, so the paths/names differ across devices with the same
SoC/GPU, so we cannot sanely list them with MODULE_FIRMWARE().

So MODULE_FIRMWARE() just ends up causing problems without actually
solving anything.  Remove them!

Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/652195/

2 months agodrm/msm/a6xx: Disable rgb565_predicator on Adreno 7c3
Konrad Dybcio [Mon, 5 May 2025 11:13:40 +0000 (13:13 +0200)]
drm/msm/a6xx: Disable rgb565_predicator on Adreno 7c3

This feature is supposed to be enabled with UBWC v4 or later.
Implementations of this SKU feature an effective UBWC version of 3, so
disable it, in line with the BSP kernel.

Reported-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Fixes: 192f4ee3e408 ("drm/msm/a6xx: Add support for Adreno 7c Gen 3 gpu")
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/651759/
Signed-off-by: Rob Clark <robdclark@chromium.org>
2 months agoarm64: dts: qcom: x1e80100: Add OPPs up to Turbo L3 for GPU
Akhil P Oommen [Sat, 19 Apr 2025 14:51:36 +0000 (20:21 +0530)]
arm64: dts: qcom: x1e80100: Add OPPs up to Turbo L3 for GPU

Now that we have ACD support for GPU, add additional OPPs up to
Turbo L3 which are supported across all existing SKUs.

Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Tested-by: Maya Matuszczyk <maccraft123mc@gmail.com>
Tested-by: Anthony Ruhier <aruhier@mailbox.org>
Acked-by: Bjorn Andersson <andersson@kernel.org>
Patchwork: https://patchwork.freedesktop.org/patch/649354/
Signed-off-by: Rob Clark <robdclark@chromium.org>
2 months agoarm64: dts: qcom: x1e80100: Add ACD levels for GPU
Akhil P Oommen [Sat, 19 Apr 2025 14:51:35 +0000 (20:21 +0530)]
arm64: dts: qcom: x1e80100: Add ACD levels for GPU

Update GPU node to include acd level values.

Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Tested-by: Maya Matuszczyk <maccraft123mc@gmail.com>
Tested-by: Anthony Ruhier <aruhier@mailbox.org>
Acked-by: Bjorn Andersson <andersson@kernel.org>
Patchwork: https://patchwork.freedesktop.org/patch/649352/
Signed-off-by: Rob Clark <robdclark@chromium.org>
2 months agodt-bindings: opp: Add v2-qcom-adreno vendor bindings
Akhil P Oommen [Sat, 19 Apr 2025 14:51:34 +0000 (20:21 +0530)]
dt-bindings: opp: Add v2-qcom-adreno vendor bindings

Add a new schema which extends opp-v2 to support a new vendor specific
property required for Adreno GPUs found in Qualcomm's SoCs. The new
property called "qcom,opp-acd-level" carries a u32 value recommended
for each opp needs to be shared to GMU during runtime.

Also, update MAINTAINERS file include the new opp-v2-qcom-adreno.yaml.

Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Tested-by: Maya Matuszczyk <maccraft123mc@gmail.com>
Tested-by: Anthony Ruhier <aruhier@mailbox.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/649351/
Signed-off-by: Rob Clark <robdclark@chromium.org>
2 months agodrm/msm/adreno: Add module param to disable ACD
Akhil P Oommen [Sat, 19 Apr 2025 14:51:33 +0000 (20:21 +0530)]
drm/msm/adreno: Add module param to disable ACD

Add a module param to disable ACD which will help to quickly rule it
out for any GPU issues.

Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Tested-by: Maya Matuszczyk <maccraft123mc@gmail.com>
Tested-by: Anthony Ruhier <aruhier@mailbox.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/649349/
Signed-off-by: Rob Clark <robdclark@chromium.org>
2 months agodrm/msm: a6x: Rework qmp_get() error handling
Akhil P Oommen [Sat, 19 Apr 2025 14:51:32 +0000 (20:21 +0530)]
drm/msm: a6x: Rework qmp_get() error handling

Fix the following for qmp_get() errors:

1. Correctly handle probe defer for A6x GPUs
2. Ignore other errors because those are okay when GPU ACD is
not required. They are checked again during gpu acd probe.

Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Tested-by: Maya Matuszczyk <maccraft123mc@gmail.com>
Tested-by: Anthony Ruhier <aruhier@mailbox.org>
Patchwork: https://patchwork.freedesktop.org/patch/649346/
Signed-off-by: Rob Clark <robdclark@chromium.org>
2 months agodrm/msm/a6xx: Increase HFI response timeout
Akhil P Oommen [Sat, 19 Apr 2025 14:51:31 +0000 (20:21 +0530)]
drm/msm/a6xx: Increase HFI response timeout

When ACD feature is enabled, it triggers some internal calibrations
which result in a pretty long delay during the first HFI perf vote.
So, increase the HFI response timeout to match the downstream driver.

Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Tested-by: Maya Matuszczyk <maccraft123mc@gmail.com>
Tested-by: Anthony Ruhier <aruhier@mailbox.org>
Patchwork: https://patchwork.freedesktop.org/patch/649344/
Signed-off-by: Rob Clark <robdclark@chromium.org>
2 months agodrm/msm/adreno: Add support for ACD
Akhil P Oommen [Sat, 19 Apr 2025 14:51:30 +0000 (20:21 +0530)]
drm/msm/adreno: Add support for ACD

ACD a.k.a Adaptive Clock Distribution is a feature which helps to reduce
the power consumption. In some chipsets, it is also a requirement to
support higher GPU frequencies. This patch adds support for GPU ACD by
sending necessary data to GMU and AOSS. The feature support for the
chipset is detected based on devicetree data.

Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Tested-by: Maya Matuszczyk <maccraft123mc@gmail.com>
Tested-by: Anthony Ruhier <aruhier@mailbox.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/649342/
Signed-off-by: Rob Clark <robdclark@chromium.org>
2 months agodrm/msm/adreno: Drop fictional address_space_size
Rob Clark [Mon, 21 Apr 2025 17:21:43 +0000 (10:21 -0700)]
drm/msm/adreno: Drop fictional address_space_size

Really the only purpose of this was to limit the address space size to
4GB to avoid 32b rollover problems in 64b pointer math in older sqe fw.
So replace the address_space_size with a quirk limiting the address
space to 4GB.  In all other cases, use the SMMU input address size (IAS)
to determine the address space size.

v2: Properly account for vm_start

Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/649467/

2 months agodrm/msm: Be more robust when HFI response times out
Connor Abbott [Thu, 24 Apr 2025 13:30:17 +0000 (09:30 -0400)]
drm/msm: Be more robust when HFI response times out

If the GMU takes too long to respond to an HFI message, we may return
early. If the GMU does eventually respond, and then we send a second
message, we will see the response for the first, throw another error,
and keep going. But we don't currently wait for the interrupt from the
GMU again, so if the second response isn't there immediately we may
prematurely return. This can cause a continuous cycle of missed HFI
messages, and for reasons I don't quite understand the GMU does not shut
down properly when this happens.

Fix this by waiting for the GMU interrupt when we see an empty queue. If
the GMU never responds then the queue really is empty and we quit. We
can't wait for the interrupt when we see a wrong response seqnum because
the GMU might have already queued both responses by the time we clear
the interrupt the first time so we do need to check the queue before
waiting on the interrupt again.

Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/650013/
Signed-off-by: Rob Clark <robdclark@chromium.org>
2 months agodrm/msm/gpu: Fix crash when throttling GPU immediately during boot
Stephan Gerhold [Tue, 29 Apr 2025 08:33:56 +0000 (10:33 +0200)]
drm/msm/gpu: Fix crash when throttling GPU immediately during boot

There is a small chance that the GPU is already hot during boot. In that
case, the call to of_devfreq_cooling_register() will immediately try to
apply devfreq cooling, as seen in the following crash:

  Unable to handle kernel paging request at virtual address 0000000000014110
  pc : a6xx_gpu_busy+0x1c/0x58 [msm]
  lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm]
  Call trace:
   a6xx_gpu_busy+0x1c/0x58 [msm] (P)
   devfreq_simple_ondemand_func+0x3c/0x150
   devfreq_update_target+0x44/0xd8
   qos_max_notifier_call+0x30/0x84
   blocking_notifier_call_chain+0x6c/0xa0
   pm_qos_update_target+0xd0/0x110
   freq_qos_apply+0x3c/0x74
   apply_constraint+0x88/0x148
   __dev_pm_qos_update_request+0x7c/0xcc
   dev_pm_qos_update_request+0x38/0x5c
   devfreq_cooling_set_cur_state+0x98/0xf0
   __thermal_cdev_update+0x64/0xb4
   thermal_cdev_update+0x4c/0x58
   step_wise_manage+0x1f0/0x318
   __thermal_zone_device_update+0x278/0x424
   __thermal_cooling_device_register+0x2bc/0x308
   thermal_of_cooling_device_register+0x10/0x1c
   of_devfreq_cooling_register_power+0x240/0x2bc
   of_devfreq_cooling_register+0x14/0x20
   msm_devfreq_init+0xc4/0x1a0 [msm]
   msm_gpu_init+0x304/0x574 [msm]
   adreno_gpu_init+0x1c4/0x2e0 [msm]
   a6xx_gpu_init+0x5c8/0x9c8 [msm]
   adreno_bind+0x2a8/0x33c [msm]
   ...

At this point we haven't initialized the GMU at all yet, so we cannot read
the GMU registers inside a6xx_gpu_busy(). A similar issue was fixed before
in commit 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in
6xx gpu_busy"): msm_devfreq_init() does call devfreq_suspend_device(), but
unlike msm_devfreq_suspend(), it doesn't set the df->suspended flag
accordingly. This means the df->suspended flag does not match the actual
devfreq state after initialization and msm_devfreq_get_dev_status() will
end up accessing GMU registers, causing the crash.

Fix this by setting df->suspended correctly during initialization.

Cc: stable@vger.kernel.org
Fixes: 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy")
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/650772/
Signed-off-by: Rob Clark <robdclark@chromium.org>
2 months agodrm/ci: uprev mesa
Vignesh Raman [Fri, 28 Mar 2025 11:02:33 +0000 (16:32 +0530)]
drm/ci: uprev mesa

The current s3cp implementation does not work anymore after the
migration, and instead of fixing it and propagating the fix down to us,
it's simpler to directly use curl. Uprev mesa [1][2] to adapt these
changes. Also replace broken s3cp command with a curl wrapper call in
drm-ci.

[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34120
[2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34244

Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Patchwork: https://patchwork.freedesktop.org/patch/645597/
Signed-off-by: Rob Clark <robdclark@chromium.org>
2 months agodrm/msm/dsi: add DSI support for SA8775P
Ayushi Makhija [Thu, 1 May 2025 22:44:35 +0000 (01:44 +0300)]
drm/msm/dsi: add DSI support for SA8775P

Add DSI Controller v2.5.1 support for SA8775P SoC.

Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com>
Reviewed-by: Dmitry Baryshkov <lumag@kernel.org>
Patchwork: https://patchwork.freedesktop.org/patch/651433/
Link: https://lore.kernel.org/r/20250424062431.2040692-6-quic_amakhija@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dsi: add DSI PHY configuration on SA8775P
Ayushi Makhija [Thu, 24 Apr 2025 06:24:24 +0000 (11:54 +0530)]
drm/msm/dsi: add DSI PHY configuration on SA8775P

The SA8775P SoC uses the 5nm (v4.2) DSI PHY driver with
different enable regulator load.

Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com>
Reviewed-by: Dmitry Baryshkov <lumag@kernel.org>
Patchwork: https://patchwork.freedesktop.org/patch/649842/
Link: https://lore.kernel.org/r/20250424062431.2040692-5-quic_amakhija@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodt-bindings: display: msm: document DSI controller and phy on SA8775P
Ayushi Makhija [Thu, 24 Apr 2025 06:24:23 +0000 (11:54 +0530)]
dt-bindings: display: msm: document DSI controller and phy on SA8775P

Document DSI controller and phy on SA8775P platform.

Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/649839/
Link: https://lore.kernel.org/r/20250424062431.2040692-4-quic_amakhija@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodt-bindings: msm: dsi-controller-main: document the SA8775P DSI CTRL
Ayushi Makhija [Thu, 24 Apr 2025 06:24:22 +0000 (11:54 +0530)]
dt-bindings: msm: dsi-controller-main: document the SA8775P DSI CTRL

Document the DSI CTRL on the SA8775P Platform.

Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/649855/
Link: https://lore.kernel.org/r/20250424062431.2040692-3-quic_amakhija@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodt-bindings: display: msm-dsi-phy-7nm: document the SA8775P DSI PHY
Ayushi Makhija [Thu, 24 Apr 2025 06:24:21 +0000 (11:54 +0530)]
dt-bindings: display: msm-dsi-phy-7nm: document the SA8775P DSI PHY

Document the DSI PHY on the SA8775P Platform.

Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/649838/
Link: https://lore.kernel.org/r/20250424062431.2040692-2-quic_amakhija@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodt-bindings: display: msm: sm8350-mdss: Describe the CPU-CFG icc path
Konrad Dybcio [Thu, 6 Mar 2025 18:11:14 +0000 (19:11 +0100)]
dt-bindings: display: msm: sm8350-mdss: Describe the CPU-CFG icc path

There's a separate path that allows register access from CPUSS.
Describe it.

Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/641464/
Link: https://lore.kernel.org/r/20250306-topic-dt_bindings_fixups-v1-2-0c84aceb0ef9@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dp: reuse generic HDMI codec implementation
Dmitry Baryshkov [Thu, 1 May 2025 22:41:42 +0000 (01:41 +0300)]
drm/msm/dp: reuse generic HDMI codec implementation

The MSM DisplayPort driver implements several HDMI codec functions
in the driver, e.g. it manually manages HDMI codec device registration,
returning ELD and plugged_cb support. In order to reduce code
duplication reuse drm_hdmi_audio_* helpers and drm_bridge_connector
integration.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/649728/
Link: https://lore.kernel.org/r/20250423-dp-hdmi-audio-v7-1-8407a23e55b2@oss.qualcomm.com
2 months agodrm/msm/dpu: remove DSC feature bit for PINGPONG on SDM630
Dmitry Baryshkov [Sat, 1 Mar 2025 09:24:58 +0000 (11:24 +0200)]
drm/msm/dpu: remove DSC feature bit for PINGPONG on SDM630

The SDM630 platform doesn't have DSC blocks nor does have it DSC
registers in the PINGPONG block. Drop the DPU_PINGPONG_DSC feature bit
from the PINGPONG's feature mask, replacing PINGPONG_SDM845_MASK with
BIT(DPU_PINGPONG_DITHER).

Fixes: 7204df5e7e68 ("drm/msm/dpu: add support for SDM660 and SDM630 platforms")
Reported-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/640308/
Link: https://lore.kernel.org/r/20250301-dpu-fix-catalog-v2-5-498271be8b50@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: drop TE2 definitions
Dmitry Baryshkov [Sat, 1 Mar 2025 09:24:57 +0000 (11:24 +0200)]
drm/msm/dpu: drop TE2 definitions

Neither DPU driver nor vendor SDE driver do not use TE2 definitions
(and, in case of SDE driver, never did). Semantics of the TE2 feature
bit and .te2 sblk are not completely clear. Drop these bits from the
catalog with the possibility of reintroducing them later if we need to
support ppsplit.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/640305/
Link: https://lore.kernel.org/r/20250301-dpu-fix-catalog-v2-4-498271be8b50@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: remove DSC feature bit for PINGPONG on MSM8953
Dmitry Baryshkov [Sat, 1 Mar 2025 09:24:56 +0000 (11:24 +0200)]
drm/msm/dpu: remove DSC feature bit for PINGPONG on MSM8953

The MSM8953 platform doesn't have DSC blocks nor does have it DSC
registers in the PINGPONG block. Drop the DPU_PINGPONG_DSC feature bit
from the PINGPONG's feature mask and, as it is the only remaining bit,
drop the .features assignment completely.

Fixes: 7a6109ce1c2c ("drm/msm/dpu: Add support for MSM8953")
Reported-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/640303/
Link: https://lore.kernel.org/r/20250301-dpu-fix-catalog-v2-3-498271be8b50@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: remove DSC feature bit for PINGPONG on MSM8917
Dmitry Baryshkov [Sat, 1 Mar 2025 09:24:55 +0000 (11:24 +0200)]
drm/msm/dpu: remove DSC feature bit for PINGPONG on MSM8917

The MSM8917 platform doesn't have DSC blocks nor does have it DSC
registers in the PINGPONG block. Drop the DPU_PINGPONG_DSC feature bit
from the PINGPONG's feature mask and, as it is the only remaining bit,
drop the .features assignment completely.

Fixes: 62af6e1cb596 ("drm/msm/dpu: Add support for MSM8917")
Reported-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/640301/
Link: https://lore.kernel.org/r/20250301-dpu-fix-catalog-v2-2-498271be8b50@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: remove DSC feature bit for PINGPONG on MSM8937
Dmitry Baryshkov [Sat, 1 Mar 2025 09:24:54 +0000 (11:24 +0200)]
drm/msm/dpu: remove DSC feature bit for PINGPONG on MSM8937

The MSM8937 platform doesn't have DSC blocks nor does have it DSC
registers in the PINGPONG block. Drop the DPU_PINGPONG_DSC feature bit
from the PINGPONG's feature mask and, as it is the only remaining bit,
drop the .features assignment completely.

Fixes: c079680bb0fa ("drm/msm/dpu: Add support for MSM8937")
Reported-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/640299/
Link: https://lore.kernel.org/r/20250301-dpu-fix-catalog-v2-1-498271be8b50@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/hdmi: use new helper for ACR tables
Dmitry Baryshkov [Tue, 8 Apr 2025 13:54:27 +0000 (16:54 +0300)]
drm/msm/hdmi: use new helper for ACR tables

Use new drm_hdmi_acr_get_n_cts() helper instead of hand-coding the
tables. Instead of storing the rate 'index', store the audio sample rate
in hdmi->audio.rate, removing the need for even more defines.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/647507/
Link: https://lore.kernel.org/r/20250408-drm-hdmi-acr-v2-3-dee7298ab1af@oss.qualcomm.com
2 months agodrm/msm/hdmi: move msm_hdmi_audio_update() out of msm_hdmi_set_timings()
Dmitry Baryshkov [Tue, 8 Apr 2025 13:54:26 +0000 (16:54 +0300)]
drm/msm/hdmi: move msm_hdmi_audio_update() out of msm_hdmi_set_timings()

There is a duplication between msm_hdmi_audio_update() calls in
msm_hdmi_set_timings() and msm_hdmi_bridge_atomic_pre_enable(). Merge
those two calls to be performed unconditionally at
msm_hdmi_bridge_atomic_pre_enable().

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/647505/
Link: https://lore.kernel.org/r/20250408-drm-hdmi-acr-v2-2-dee7298ab1af@oss.qualcomm.com
2 months agodrm/msm/dpu: add catalog entry for SAR2130P
Dmitry Baryshkov [Fri, 18 Apr 2025 07:50:03 +0000 (10:50 +0300)]
drm/msm/dpu: add catalog entry for SAR2130P

Add DPU driver support for the Qualcomm SAR2130P platform. It is mostly
the same as SM8550, minor differences in the CDP configuration.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/649258/
Link: https://lore.kernel.org/r/20250418-sar2130p-display-v5-8-442c905cb3a4@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dsi/phy: add configuration for SAR2130P
Dmitry Baryshkov [Fri, 18 Apr 2025 07:50:02 +0000 (10:50 +0300)]
drm/msm/dsi/phy: add configuration for SAR2130P

Qualcomm SAR2130P requires slightly different setup for the DSI PHY. It
is a 5nm PHY (like SM8450), so supplies are the same, but the rest of
the configuration is the same as SM8550 DSI PHY.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/649257/
Link: https://lore.kernel.org/r/20250418-sar2130p-display-v5-7-442c905cb3a4@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/mdss: add SAR2130P device configuration
Dmitry Baryshkov [Fri, 18 Apr 2025 07:50:01 +0000 (10:50 +0300)]
drm/msm/mdss: add SAR2130P device configuration

Add compatible and device configuration for the Qualcomm SAR2130P
platform.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/649256/
Link: https://lore.kernel.org/r/20250418-sar2130p-display-v5-6-442c905cb3a4@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodt-bindings: display/msm: Add Qualcomm SAR2130P
Dmitry Baryshkov [Fri, 18 Apr 2025 07:50:00 +0000 (10:50 +0300)]
dt-bindings: display/msm: Add Qualcomm SAR2130P

Describe the Mobile Display SubSystem (MDSS) device present on the
Qualcomm SAR2130P platform. It looks pretty close to SM8550 on the
system level. SAR2130P features two DSI hosts and single DisplayPort
controller.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/649265/
Link: https://lore.kernel.org/r/20250418-sar2130p-display-v5-5-442c905cb3a4@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodt-bindings: display/msm: qcom,sc7280-dpu: describe SAR2130P
Dmitry Baryshkov [Fri, 18 Apr 2025 07:49:59 +0000 (10:49 +0300)]
dt-bindings: display/msm: qcom,sc7280-dpu: describe SAR2130P

Describe DPU controller present on Qualcomm SAR2130P platform.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/649254/
Link: https://lore.kernel.org/r/20250418-sar2130p-display-v5-4-442c905cb3a4@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodt-bindings: display/msm: dsi-phy-7nm: describe SAR2130P
Dmitry Baryshkov [Fri, 18 Apr 2025 07:49:58 +0000 (10:49 +0300)]
dt-bindings: display/msm: dsi-phy-7nm: describe SAR2130P

Describe MIPI DSI PHY present on Qualcomm SAR2130P platform.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/649252/
Link: https://lore.kernel.org/r/20250418-sar2130p-display-v5-3-442c905cb3a4@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodt-bindings: display/msm: dsi-controller-main: describe SAR2130P
Dmitry Baryshkov [Fri, 18 Apr 2025 07:49:57 +0000 (10:49 +0300)]
dt-bindings: display/msm: dsi-controller-main: describe SAR2130P

Describe MIPI DSI controller present on Qualcomm SAR2130P platform.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/649250/
Link: https://lore.kernel.org/r/20250418-sar2130p-display-v5-2-442c905cb3a4@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodt-bindings: display/msm: dp-controller: describe SAR2130P
Dmitry Baryshkov [Fri, 18 Apr 2025 07:49:56 +0000 (10:49 +0300)]
dt-bindings: display/msm: dp-controller: describe SAR2130P

Describe DisplayPort controller present on Qualcomm SAR2130P platform.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/649263/
Link: https://lore.kernel.org/r/20250418-sar2130p-display-v5-1-442c905cb3a4@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: rename non-SmartDMA feature masks to be more explicit
Dmitry Baryshkov [Fri, 25 Apr 2025 19:49:12 +0000 (22:49 +0300)]
drm/msm/dpu: rename non-SmartDMA feature masks to be more explicit

It is easy to skip or ignore the fact that the default SSPP feature
masks for SDM845+ don't include the SmartDMA bit (both during
development and during the review stage). Rename SSPP feature masks to
make it more explicit that using non-SmartDMA masks should not be an
exception rather than the rule.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/650425/
Link: https://lore.kernel.org/r/20250425-dpu-rework-vig-masks-v2-5-c71900687d08@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: enable SmartDMA on SM8550
Dmitry Baryshkov [Fri, 25 Apr 2025 19:49:11 +0000 (22:49 +0300)]
drm/msm/dpu: enable SmartDMA on SM8550

In order to support more versatile configuration of the display pipes on
SM8550, enable SmartDMA for this platform.

Patchwork: https://patchwork.freedesktop.org/patch/650424/
Link: https://lore.kernel.org/r/20250425-dpu-rework-vig-masks-v2-4-c71900687d08@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: enable SmartDMA on SC8280XP
Dmitry Baryshkov [Fri, 25 Apr 2025 19:49:10 +0000 (22:49 +0300)]
drm/msm/dpu: enable SmartDMA on SC8280XP

In order to support more versatile configuration of the display pipes on
SC8280XP, enable SmartDMA for this platform.

Patchwork: https://patchwork.freedesktop.org/patch/650420/
Link: https://lore.kernel.org/r/20250425-dpu-rework-vig-masks-v2-3-c71900687d08@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: enable SmartDMA on SC8180X
Dmitry Baryshkov [Fri, 25 Apr 2025 19:49:09 +0000 (22:49 +0300)]
drm/msm/dpu: enable SmartDMA on SC8180X

Reworking of the catalog dropped the SmartDMA feature bit on the SC8180X
platform. Renable SmartDMA support on this SoC.

Fixes: 460c410f02e4 ("drm/msm/dpu: duplicate sdm845 catalog entries")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/650421/
Link: https://lore.kernel.org/r/20250425-dpu-rework-vig-masks-v2-2-c71900687d08@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: enable SmartDMA on SM8150
Dmitry Baryshkov [Fri, 25 Apr 2025 19:49:08 +0000 (22:49 +0300)]
drm/msm/dpu: enable SmartDMA on SM8150

Reworking of the catalog dropped the SmartDMA feature bit on the SM8150
platform. Renable SmartDMA support on this SoC.

Fixes: 460c410f02e4 ("drm/msm/dpu: duplicate sdm845 catalog entries")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/650418/
Link: https://lore.kernel.org/r/20250425-dpu-rework-vig-masks-v2-1-c71900687d08@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: allow sharing SSPP between planes
Dmitry Baryshkov [Sat, 26 Apr 2025 04:51:17 +0000 (07:51 +0300)]
drm/msm/dpu: allow sharing SSPP between planes

Since SmartDMA planes provide two rectangles, it is possible to use them
to drive two different DRM planes, first plane getting the rect_0,
another one using rect_1 of the same SSPP. The sharing algorithm is
pretty simple, it requires that each of the planes can be driven by the
single rectangle and only consecutive planes are considered.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/650441/
Link: https://lore.kernel.org/r/20250426-dpu-share-sspp-v7-1-6f4c719e373c@oss.qualcomm.com
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
2 months agodrm/msm/mdp4: switch LVDS to use drm_bridge/_connector
Dmitry Baryshkov [Fri, 25 Apr 2025 09:51:56 +0000 (12:51 +0300)]
drm/msm/mdp4: switch LVDS to use drm_bridge/_connector

LVDS support in MDP4 driver makes use of drm_connector directly. However
LCDC encoder and LVDS connector are wrappers around drm_panel. Switch
them to use drm_panel_bridge/drm_bridge_connector. This allows using
standard interface for the drm_panel and also inserting additional
bridges between encoder and panel.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/650290/
Link: https://lore.kernel.org/r/20250425-fd-mdp4-lvds-v4-6-6b212160b44c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/mdp4: move move_valid callback to lcdc_encoder
Dmitry Baryshkov [Fri, 25 Apr 2025 09:51:55 +0000 (12:51 +0300)]
drm/msm/mdp4: move move_valid callback to lcdc_encoder

We can check the LCDC clock directly from the LCDC encoder driver, so
remove it from the LVDS connector.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/650285/
Link: https://lore.kernel.org/r/20250425-fd-mdp4-lvds-v4-5-6b212160b44c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/mdp4: use parent_data for LVDS PLL
Dmitry Baryshkov [Fri, 25 Apr 2025 09:51:54 +0000 (12:51 +0300)]
drm/msm/mdp4: use parent_data for LVDS PLL

Instead of using .parent_names, use .parent_data, which binds parent
clocks by using relative names specified in DT in addition to using global
system clock names.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/650284/
Link: https://lore.kernel.org/r/20250425-fd-mdp4-lvds-v4-4-6b212160b44c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/mdp4: register the LVDS PLL as a clock provider
Dmitry Baryshkov [Fri, 25 Apr 2025 09:51:53 +0000 (12:51 +0300)]
drm/msm/mdp4: register the LVDS PLL as a clock provider

The LVDS/LCDC controller uses pixel clock coming from the multimedia
controller (mmcc) rather than using the PLL directly. Stop using LVDS
PLL directly and register it as a clock provider. Use lcdc_clk as a
pixel clock for the LCDC.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/650280/
Link: https://lore.kernel.org/r/20250425-fd-mdp4-lvds-v4-3-6b212160b44c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/mdp4: drop mpd4_lvds_pll_init stub
Dmitry Baryshkov [Fri, 25 Apr 2025 09:51:52 +0000 (12:51 +0300)]
drm/msm/mdp4: drop mpd4_lvds_pll_init stub

Drop the !COMMON_CLK stub for mpd4_lvds_pll_init(), the DRM_MSM driver
depends on COMMON_CLK.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/650281/
Link: https://lore.kernel.org/r/20250425-fd-mdp4-lvds-v4-2-6b212160b44c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodt-bindings: display: msm: mdp4: add LCDC clock and PLL source
Dmitry Baryshkov [Fri, 25 Apr 2025 09:51:51 +0000 (12:51 +0300)]
dt-bindings: display: msm: mdp4: add LCDC clock and PLL source

Add the LCDC / LVDS clock input and the XO used to drive internal LVDS
PLL to MDP4 controller bindings. The controller also provides LVDS PHY
PLL, so add optional #clock-cells to the device.

Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/650278/
Link: https://lore.kernel.org/r/20250425-fd-mdp4-lvds-v4-1-6b212160b44c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodt-bindings: msm: qcom,mdss: Document interconnect paths
Luca Weiss [Sun, 20 Apr 2025 15:12:43 +0000 (17:12 +0200)]
dt-bindings: msm: qcom,mdss: Document interconnect paths

Document two interconnect paths found on the MDSS on MSM8953.

Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/649391/
Link: https://lore.kernel.org/r/20250420-msm8953-interconnect-v2-1-828715dcb674@lucaweiss.eu
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm: Convert comma to semicolon
Chen Ni [Thu, 10 Apr 2025 02:52:21 +0000 (10:52 +0800)]
drm/msm: Convert comma to semicolon

Replace comma between expressions with semicolons.

Using a ',' in place of a ';' can have unintended side effects.
Although that is not the case here, it is seems best to use ';'
unless ',' is intended.

Found by inspection.
No functional change intended.
Compile tested only.

Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/647875/
Link: https://lore.kernel.org/r/20250410025221.3358387-1-nichen@iscas.ac.cn
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: drop now-unused condition for has_legacy_ctls
Dmitry Baryshkov [Fri, 7 Mar 2025 06:24:56 +0000 (08:24 +0200)]
drm/msm/dpu: drop now-unused condition for has_legacy_ctls

Now as we have dropped the DPU_CTL_SPLIT_DISPLAY from DPU >= 5.0
configuration, drop the rm->has_legacy_ctl condition which short-cutted
the check for those platforms.

Suggested-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/641586/
Link: https://lore.kernel.org/r/20250307-dpu-active-ctl-v3-8-5d20655f10ca@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: remove DPU_CTL_SPLIT_DISPLAY from CTL blocks on DPU >= 5.0
Dmitry Baryshkov [Fri, 7 Mar 2025 06:24:55 +0000 (08:24 +0200)]
drm/msm/dpu: remove DPU_CTL_SPLIT_DISPLAY from CTL blocks on DPU >= 5.0

Since DPU 5.0 CTL blocks do not require DPU_CTL_SPLIT_DISPLAY, as single
CTL is used for both interfaces. As both RM and encoder now handle
active CTLs, drop that feature bit.

Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/641592/
Link: https://lore.kernel.org/r/20250307-dpu-active-ctl-v3-7-5d20655f10ca@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: allocate single CTL for DPU >= 5.0
Dmitry Baryshkov [Fri, 7 Mar 2025 06:24:54 +0000 (08:24 +0200)]
drm/msm/dpu: allocate single CTL for DPU >= 5.0

Unlike previous generation, since DPU 5.0 it is possible to use just one
CTL to handle all INTF and WB blocks for a single output. And one has to
use single CTL to support bonded DSI config. Allocate single CTL for
these DPU versions.

Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/641587/
Link: https://lore.kernel.org/r/20250307-dpu-active-ctl-v3-6-5d20655f10ca@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: don't select single flush for active CTL blocks
Dmitry Baryshkov [Fri, 7 Mar 2025 06:24:53 +0000 (08:24 +0200)]
drm/msm/dpu: don't select single flush for active CTL blocks

In case of ACTIVE CTLs, a single CTL is being used for flushing all INTF
blocks. Don't skip programming the CTL on those targets.

Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/641585/
Link: https://lore.kernel.org/r/20250307-dpu-active-ctl-v3-5-5d20655f10ca@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2 months agodrm/msm/dpu: use single CTL if it is the only CTL returned by RM
Dmitry Baryshkov [Fri, 7 Mar 2025 06:24:52 +0000 (08:24 +0200)]
drm/msm/dpu: use single CTL if it is the only CTL returned by RM

On DPU >= 5.0 CTL blocks were reworked in order to support using a
single CTL for all outputs. In preparation of reworking the RM code to
return single CTL make sure that dpu_encoder can cope with that.

Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/641582/
Link: https://lore.kernel.org/r/20250307-dpu-active-ctl-v3-4-5d20655f10ca@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>