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>
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>
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.
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>
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>
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
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>
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>
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.
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.
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.
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.
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.
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.
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.
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.
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/
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>
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>
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>
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>
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>
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>
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/
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>
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:
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>
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.
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Patchwork: https://patchwork.freedesktop.org/patch/645597/ Signed-off-by: Rob Clark <robdclark@chromium.org>
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.
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>
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.
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.
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.
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.
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.
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().
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
If several interfaces are being handled through a single CTL, a main
('master') INTF needs to be programmed into a separate register. Write
corresponding value into that register.
In case of complex pipelines (e.g. the forthcoming quad-pipe) the DPU
might use more that one MERGE_3D block for a single output. Follow the
pattern and extend the CTL_MERGE_3D_ACTIVE active register instead of
simply writing new value there. Currently at most one MERGE_3D block is
being used, so this has no impact on existing targets.
drm/panthor: Fix build warning when DEBUG_FS is disabled
Commit a3707f53eb3f ("drm/panthor: show device-wide list of DRM GEM
objects over DebugFS") causes a build warning and linking error when
built without support for DebugFS, because of a non-inline non-static
function declaration in a header file.
On top of that, the function is only being used inside a single
compilation unit, so there is no point in exposing it as a global
symbol.
This is a follow-up from Arnd Bergmann's first fix.
Also move panthor_gem_debugfs_set_usage_flags() into panthor_gem.c and
declare it static.
Fixes: a3707f53eb3f ("drm/panthor: show device-wide list of DRM GEM objects over DebugFS") Reported-by: Arnd Bergmann <arnd@arndb.de> Closes: https://lore.kernel.org/dri-devel/20250424142419.47b9d457@collabora.com/T/#t Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/r/20250424184041.356191-1-adrian.larumbe@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
The appletbdrm driver is exclusively for Touch Bars on x86 Intel Macs.
The M1 Macs have a separate driver. So, lets avoid compiling it for
other architectures.
Petr Mladek [Mon, 28 Apr 2025 12:31:32 +0000 (14:31 +0200)]
vsprintf: Use %p4chR instead of %p4cn for reading data in reversed host ordering
The generic FourCC format always prints the data using the big endian
order. It is generic because it allows to read the data using a custom
ordering.
The current code uses "n" for reading data in the reverse host ordering.
It makes the 4 variants [hnbl] consistent with the generic printing
of IPv4 addresses.
Unfortunately, it creates confusion on big endian systems. For example,
it shows the data &(u32)0x67503030 as
%p4cn 00Pg (0x30305067)
But people expect that the ordering stays the same. The network ordering
is a big-endian ordering.
The problem is that the semantic is not the same. The modifiers affect
the output ordering of IPv4 addresses while they affect the reading order
in case of FourCC code.
Avoid the confusion by replacing the "n" modifier with "hR", aka
reverse host ordering. It is inspired by the existing %p[mM]R printf
format.
drm/bridge: imx8*-ldb: convert to devm_drm_bridge_alloc() API
This is the new API for allocating DRM bridges.
These two drivers are tangled together by the ldb_add_bridge_helper(), so
they are converted at once.
They also have a similar design, each embedding an array of channels in
their main struct, and each channel embeds a drm_bridge. This prevents
dynamic, refcount-based deallocation of the bridges.
To make the new, dynamic bridge allocation possible:
* change the array of channels into an array of channel pointers
* allocate each channel using devm_drm_bridge_alloc()
* adapt ldb_add_bridge_helper() to not set the funcs pointer
(now done by devm_drm_bridge_alloc())
* adapt the code wherever using the channels
This driver already implements refcounting of the struct vc4_dsi, which
embeds struct drm_bridge. Now this is a duplicate of the refcounting
implemented by the DRM bridge core, so convert the vc4_dsi_get/put() calls
into drm_bridge_get/put() calls and get rid of the driver-specific
refcounting implementation.
projects / thirdparty / linux.git / log
