- Make 'guc_hw_reg_state' static as it isn't exported (Ben)
- Fix doc build on mei related interface header (Jani)
Display related:
- Fix ggtt fb alignment on Xe display (Tvrtko)
- More display clean-up towards deduplication and full separation (Jani)
- Use the consolidated HDMI tables (Suraj)
- Account for DSC slice overhead (Ankit)
- Prepare GVT for display modularization (Ankit, Jani)
- Enable/Disable DC balance along with VRR DSB (Mitul, Ville)
- Protection against unsupported modes in LT PHY (Suraj)
- Display W/a addition and fixes (Gustavo)
- Fix many SPDX identifier comments (Ankit)
- Incorporate Xe3_LPD changes for CD2X divider (Gustavo)
- Clean up link BW/DSC slice config computation (Imre)
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEbSBwaO7dZQkcLOKj+mJfZA7rE8oFAmlpDOcACgkQ+mJfZA7r
E8pWZwf/Rxj3MBgS2TNtGj2w+vwWAJqVwsbIj3PZXp+0uuH7mWeuG9v9kZP8m16N
SSeKXt+/5ShSc1KZwhVlhvfRk1hMyQ4CDmjURZ2IdV/qxMskeUnMdGaoPdpWpPKq
YT0HaT2BcMR2dmEDzC7HzCj12Jz1JuxaMrY2AHX4iCYhfMuabtpiz1qiKtGbrSrZ
/xy0V+mM0Lrjx10z7AH8ej4UW7u0Y7MKzmGK7Xa7pydh/TD7CaeyM5YKuV02dd4e
W2B8Nqy+Zfll9Yw9iPBXo/8eex+vjhyGuGcqmemblWVDWmXdeXEiFUsdcy9ILWTl
x3rqacz3QvsrAYsg9lTaXmSM9ih/kw==
=Fjtv
-----END PGP SIGNATURE-----
Merge tag 'drm-intel-next-2026-01-15' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-next
Beyond Display:
- Make 'guc_hw_reg_state' static as it isn't exported (Ben)
- Fix doc build on mei related interface header (Jani)
Display related:
- Fix ggtt fb alignment on Xe display (Tvrtko)
- More display clean-up towards deduplication and full separation (Jani)
- Use the consolidated HDMI tables (Suraj)
- Account for DSC slice overhead (Ankit)
- Prepare GVT for display modularization (Ankit, Jani)
- Enable/Disable DC balance along with VRR DSB (Mitul, Ville)
- Protection against unsupported modes in LT PHY (Suraj)
- Display W/a addition and fixes (Gustavo)
- Fix many SPDX identifier comments (Ankit)
- Incorporate Xe3_LPD changes for CD2X divider (Gustavo)
- Clean up link BW/DSC slice config computation (Imre)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/aWkNThVRSkGAfUVv@intel.com
Create notifier_wq with WQ_MEM_RECLAIM flag to fix the possible warning.
workqueue: WQ_MEM_RECLAIM amdxdna_js:drm_sched_free_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM notifier_wq:0x0
Fixes: e486147c91 ("accel/amdxdna: Add BO import and export")
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Reviewed-by: Maciej Falkowski <maciej.falkowski@linux.intel.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260113173624.256053-1-lizhi.hou@amd.com
Make sure to drop the reference taken when looking up the companion
(ganged) device and its driver data during probe().
Note that holding a reference to a device does not prevent its driver
data from going away so there is no point in keeping the reference.
Fixes: e94236cde4 ("drm/tegra: dsi: Add ganged mode support")
Fixes: 221e3638fe ("drm/tegra: Fix reference leak in tegra_dsi_ganged_probe")
Cc: stable@vger.kernel.org # 3.19: 221e3638fe
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20251121164201.13188-1-johan@kernel.org
Rockchip display hardware is only available on Rockchip SoCs. Hence add
a dependency on ARCH_ROCKCHIP, to prevent asking the user about this
driver when configuring a kernel without Rockchip platform support.
Before, this dependency was implicit through a hard dependency on
ROCKCHIP_IOMMU.
Fixes: 0244539f9a ("drm/rockchip: Drop ROCKCHIP_IOMMU depend for DRM_ROCKCHIP")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/5db192d31cc51f027f107c01c01a353a0569ebf4.1768310045.git.geert+renesas@glider.be
The kernel specifies LUT table sizes in a separate property, however it
doesn't enforce it as a maximum. Some drivers implement max size check
on their own in the atomic_check path. Other drivers simply ignore the
issue. Perform LUT size validation in the generic place.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260106-drm-fix-lut-checks-v3-3-f7f979eb73c8@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The function drm_property_replace_blob_from_id() allows checking whether
the blob size is equal to a predefined value. In case of variable-size
properties (like the gamma / degamma LUTs) we might want to check for
the blob size against the maximum, allowing properties of the size
lesser than the max supported by the hardware. Extend the function in
order to support such checks.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260106-drm-fix-lut-checks-v3-2-f7f979eb73c8@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
We have a helper to get property values for non-atomic drivers and
another one default property values for atomic drivers. In some cases we
need the ability to get value of immutable property, no matter what kind
of driver it is. Implement new property-related helper,
drm_object_immutable_property_get_value(), which lets the caller to get
the value of the immutable property.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260106-drm-fix-lut-checks-v3-1-f7f979eb73c8@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The minimum/maximum DSC input (i.e. pipe) and compressed (i.e. link) BPP
limits are computed already in intel_dp_compute_config_limits(), so
there is no need to do this again in
mst_stream_dsc_compute_link_config() called later. Remove the
corresponding alignments from the latter function and use the
precomputed (aligned and within bounds) maximum pipe BPP and the min/max
compressed BPP values instead as-is.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-21-imre.deak@intel.com
intel_edp_dsc_compute_pipe_bpp() matches now
intel_dp_dsc_compute_pipe_bpp(), remove the former function.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-20-imre.deak@intel.com
Move computing the eDP compressed BPP value to the function computing
this for DP, allowing further simplifications later.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-19-imre.deak@intel.com
If dsc_compute_compressed_bpp() failed with a forced pipe BPP value
(where the forced pipe BPP value itself is valid within the min/max pipe
BPP limits), the function will also fail when called with the maximum
pipe BPP value: dsc_compute_compressed_bpp() will try all compressed
BPPs below the passed in pipe BPP value and if the function failed with
a given (low) compressed BPP value it will also fail with a compressed
BPP value higher than the one which failed already.
Based on the above remove the logic to retry computing a compressed BPP
value with the maximum pipe BPP value if computing the compressed BPP
failed already with the (lower) forced pipe BPP value.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-18-imre.deak@intel.com
The maximum pipe BPP value (used as the DSC input BPP) has been aligned
already to the corresponding source/sink input BPP capabilities in
intel_dp_compute_config_limits(). So it isn't needed to perform the same
alignment again in intel_dp_dsc_compute_pipe_bpp() called later, this
function can simply use the already aligned maximum pipe BPP value, do
that.
Also, there is no point in trying pipe BPP values lower than the
maximum: this would only make dsc_compute_compressed_bpp() start with a
lower _compressed_ BPP value, but this lower compressed BPP value has
been tried already when dsc_compute_compressed_bpp() was called with the
higher pipe BPP value (i.e. the first dsc_compute_compressed_bpp() call
tries already all the possible compressed BPP values which are all below
the pipe BPP value passed to it). Simplify the function accordingly
trying only the maximum pipe BPP value.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-17-imre.deak@intel.com
The maximum pipe BPP value (used as the DSC input BPP) has been aligned
already to the corresponding source/sink input BPP capabilities in
intel_dp_compute_config_limits(). So it isn't needed to perform the same
alignment again in intel_edp_dsc_compute_pipe_bpp() called later, this
function can simply use the already aligned maximum pipe BPP value, do
that.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-16-imre.deak@intel.com
The minimum/maximum compressed BPP values are aligned/bounded in
intel_dp_compute_link_bpp_limits() to the corresponding source limits.
The minimum compressed BPP value doesn't change afterwards, so no need
to align it again, remove that.
The maximum compressed BPP, which depends on the pipe BPP value still
needs to be aligned, since the pipe BPP value could change after the
above limits were computed, via intel_dp_force_dsc_pipe_bpp(). Use the
corresponding helper for this alignment instead of open-coding the same.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-15-imre.deak@intel.com
Atm, a DP DSC video mode's required BW vs. the available BW is
determined by calculating the maximum compressed BPP value allowed by
the available BW. Doing that using a closed-form formula as it's done
atm (vs. an iterative way) is problematic, since the overhead of the
required BW itself depends on the BPP value being calculated. Instead of
that calculate the required BW for the minimum compressed BPP value
supported both by the source and the sink and check this BW against the
available BW. This change also aligns the BW calculation during mode
validation with how this is done during state computation, calculating
the required effective data rate with the corresponding BW overhead.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-14-imre.deak@intel.com
Add intel_dp_mode_valid_with_dsc() and call this for an SST/MST mode
validation to prepare for a follow-up change using a way to verify the
mode's required BW the same way this is done elsewhere during state
computation (which in turn depends on the mode's effective data rate
with the corresponding BW overhead).
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-13-imre.deak@intel.com
Factor out compute_max_compressed_bpp_x16() also used during mode
validation in a follow-up change.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-12-imre.deak@intel.com
Factor out compute_min_compressed_bpp_x16() also used during mode
validation in a follow-up change.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-11-imre.deak@intel.com
Prepare for follow-up changes using dsc_throughput_quirk_max_bpp_x16()
without an intel_crtc_state pointer.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-10-imre.deak@intel.com
Prepare for follow-up changes also calling
intel_dp_dsc_min_sink_compressed_bpp() /
intel_dp_dsc_max_sink_compressed_bpp_x16()
without an intel_crtc_state.
While at it remove the stale function declarations from the header file.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-9-imre.deak@intel.com
The intel_dp pointer can be deducted from the connector pointer, so it's
enough to pass only connector to
intel_dp_compute_config_link_bpp_limits(), do so.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-8-imre.deak@intel.com
Align the minimum/maximum DSC compressed BPPs to the corresponding
source compressed BPP limits already when computing the BPP limits. This
alignment is also performed later during state computation, however
there is no reason to initialize the limits to an unaligned/incorrect
value.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-7-imre.deak@intel.com
Align the minimum/maximum DSC input BPPs to the corresponding sink DSC
input BPP capability limits already when computing the BPP limits. This
alignment is also performed later during state computation, however
there is no reason to initialize the limits to an unaligned/incorrect
value.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-6-imre.deak@intel.com
Factor out align_max_vesa_compressed_bpp_x16(), also used later for
computing the maximum DSC compressed BPP limit.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-5-imre.deak@intel.com
Factor out align_max_sink_dsc_input_bpp(), also used later for computing
the maximum DSC input BPP limit.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-4-imre.deak@intel.com
Drop the unused timeslots parameter from dsc_compute_link_config() and
other functions calling it.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-2-imre.deak@intel.com
On some platforms, notably MediaTek MT8196, the shader_present bitmask
in the Mali GPU register for it has cores enabled that may be faulty.
The true shader_present bitmask is found in an efuse instead.
Implement reading shader_present from an nvmem cell if one is present,
falling back to the Mali register if it's absent. The error codes are
trickled up through to the probe function so that probe deferral works.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Link: https://patch.msgid.link/20251220-mt8196-shader-present-v2-3-45b1ff1dfab0@collabora.com
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
On the MediaTek MT8196 SoC, the bitmask for which shader cores are
present and functional is not the one in the Mali GPU's registers, but
in an external efuse.
Add the nvmem cell properties to describe such a setup, and make them
required on MT8196.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://patch.msgid.link/20251220-mt8196-shader-present-v2-1-45b1ff1dfab0@collabora.com
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
The callbacks .probe(), .remove() and .shutdown() for device_drivers
should go away. So migrate to bus methods. There are two differences
that need addressing:
- The bus remove callback returns void while the driver remove callback
returns int (the actual value is ignored by the core).
- The bus shutdown callback is also called for unbound devices, so an
additional check for dev->driver != NULL is needed.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # tegra20 tegra-video
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/dd55d034c68953268ea416aa5c13e41b158fcbb4.1765355236.git.u.kleine-koenig@baylibre.com
The return value of struct device_driver::remove is ignored by the core
(see device_remove() in drivers/base/dd.c). So it doesn't make sense to
let the host1x remove callback return an int just to ignore it later.
So make the callback return void. All current implementors return 0, so
they are easily converted.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # tegra20 tegra-video
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/d364fd4ec043d36ee12e46eaef98c57658884f63.1765355236.git.u.kleine-koenig@baylibre.com
It's better to use gpiod_set_value_cansleep because the panel can be
connected via i2c/spi expander or similar external devices
for reference see Documentation/driver-api/gpio/consumer.rst
Signed-off-by: Vladimir Yakovlev <vovchkir@gmail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20251208161613.3763049-1-vovchkir@gmail.com
The "data-mapping" property is in use already with the
"yes-optoelectronics,ytc700tlag-05-201c" panel, so allow it in the
schema.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260105193220.3166778-1-robh@kernel.org
This command is part of LIC sequence included in FT8006P firmware.
There's no need to repeat it here.
Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260105-mantix-halo-fixes-v1-4-1ebc9b195a34@puri.sm
According to the sequence from section 7.3.4 of FT8006P datasheet,
TP_RSTN and RESX should be asserted after disabling AVDD and AVEE and
together with VDDI.
Also, AVEE power down needs to happen at least 150ms after entering
sleep mode.
Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260105-mantix-halo-fixes-v1-3-1ebc9b195a34@puri.sm
FP8006P datasheet mentions:
> It is necessary to wait 15msec after releasing RESX before sending
> commands. Also Sleep Out command cannot be sent for 120 msec.
This hasn't been respected by the driver so far, which could interfere
with the LCD init code sequence performed by the controller. In some cases
this leads to VCOM voltage being set to a wrong value, causing "halo"
effects, temporary burn-in around the edges of the screen and degraded
image contrast.
T3 and T4 are counted from when VDDI is enabled. There's no need to add
them when we've already waited more than that in T2 and T2d.
While FT8006P datasheet does not mention a delay between exiting sleep
mode and turning the display on, code provided by the vendor uses 120ms
there and it happens to be the same value as required in newer datasheets
for newer controllers from the same family, so it seems appropriate to
use it here as well.
Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260105-mantix-halo-fixes-v1-2-1ebc9b195a34@puri.sm
This improves reliability of sending DSI commands.
Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260105-mantix-halo-fixes-v1-1-1ebc9b195a34@puri.sm
In jdi_panel_dsi_remove(), jdi is explicitly checked, indicating that it
may be NULL:
if (!jdi)
mipi_dsi_detach(dsi);
However, when jdi is NULL, the function does not return and continues by
calling jdi_panel_disable():
err = jdi_panel_disable(&jdi->base);
Inside jdi_panel_disable(), jdi is dereferenced unconditionally, which can
lead to a NULL-pointer dereference:
struct jdi_panel *jdi = to_panel_jdi(panel);
backlight_disable(jdi->backlight);
To prevent such a potential NULL-pointer dereference, return early from
jdi_panel_dsi_remove() when jdi is NULL.
Signed-off-by: Tuo Li <islituo@gmail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20251218120955.11185-1-islituo@gmail.com
Add support for the Innolux G150XGE-L05 15.0" TFT 1024x768 LVDS panel.
Signed-off-by: Fabio Estevam <festevam@nabladev.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260102141706.36842-2-festevam@gmail.com
Migrate the TL121BVMS07 panel from non-DSC 60 Hz to DSC-enabled 120 Hz,
including updated init sequence, DSC configuration, and display timings.
Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20251216075530.1966327-1-yelangyan@huaqin.corp-partner.google.com
The DRM buddy allocator is a shared DRM memory management
component used by multiple DRM drivers.
Matthew Auld and Arun Pravin have been actively involved in
maintaining this code, including patch review and functional
changes.
Add a dedicated MAINTAINERS entry to reflect the current
maintainership.
v2: Include drivers/gpu/drm/tests/drm_buddy_test.c file (Matthew).
Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Acked-by: Matthew Auld <matthew.auld@intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20260112114022.315139-1-Arunpravin.PaneerSelvam@amd.com
Fix all kernel-doc warnings in rocket_accel.h:
Warning: include/uapi/drm/rocket_accel.h:35 Incorrect use of kernel-doc
format: * Output: DMA address for the BO in the NPU address space.
This address
and 22 warnings like these:
Warning: include/uapi/drm/rocket_accel.h:43 struct member 'size'
not described in 'drm_rocket_create_bo'
Warning: include/uapi/drm/rocket_accel.h:60 struct member 'handle'
not described in 'drm_rocket_prep_bo'
Warning: include/uapi/drm/rocket_accel.h:73 struct member 'handle'
not described in 'drm_rocket_fini_bo'
Warning: include/uapi/drm/rocket_accel.h:86 struct member 'regcmd'
not described in 'drm_rocket_task'
Warning: include/uapi/drm/rocket_accel.h:116 struct member 'tasks'
not described in 'drm_rocket_job'
Warning: include/uapi/drm/rocket_accel.h:135 struct member 'jobs'
not described in 'drm_rocket_submit'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Signed-off-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Link: https://patch.msgid.link/20251023062440.4093661-1-rdunlap@infradead.org
There already is a function to return the offset of the core for a given
struct device, so let's reuse that function instead of reimplementing
the same logic.
There's one change in behavior when a struct device is passed which
doesn't match any core's. Before, we would continue through
rocket_remove() but now we exit early, to match what other callers of
find_core_for_dev() (rocket_device_runtime_resume/suspend()) are doing.
This however should never happen. Aside from that, no intended change in
behavior.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Signed-off-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Link: https://patch.msgid.link/20251215-rocket-reuse-find-core-v1-1-be86a1d2734c@cherry.de
When rocket_core_init() fails (as could be the case with EPROBE_DEFER),
we need to properly unwind by decrementing the counter we just
incremented and if this is the first core we failed to probe, remove the
rocket DRM device with rocket_device_fini() as well. This matches the
logic in rocket_remove(). Failing to properly unwind results in
out-of-bounds accesses.
Fixes: 0810d5ad88 ("accel/rocket: Add job submission IOCTL")
Cc: stable@vger.kernel.org
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Signed-off-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Link: https://patch.msgid.link/20251215-rocket-error-path-v1-2-eec3bf29dc3b@cherry.de
When rocket_job_init() is called, iommu_group_get() has already been
called, therefore we should call iommu_group_put() and make the
iommu_group pointer NULL. This aligns with what's done in
rocket_core_fini().
If pm_runtime_resume_and_get() somehow fails, not only should
rocket_job_fini() be called but we should also unwind everything done
before that, that is, disable PM, put the iommu_group, NULLify it and
then call rocket_job_fini(). This is exactly what's done in
rocket_core_fini() so let's call that function instead of duplicating
the code.
Fixes: 0810d5ad88 ("accel/rocket: Add job submission IOCTL")
Cc: stable@vger.kernel.org
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Signed-off-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Link: https://patch.msgid.link/20251215-rocket-error-path-v1-1-eec3bf29dc3b@cherry.de
Add support for the dw-hdmi-qp driver to handle devices with missing
HPD pins.
Since in this situation we are now polling for the EDID data via i2c
change the error message to a rate limited debug message when we are
unable to complete an i2c read, as a disconnected device would
otherwise fill dmesg with i2c read errors.
Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251119225526.70588-3-macroalpha82@gmail.com
Add an attribute of "no-hpd" for the Rockchip dw-hdmi-qp controller.
This is used to describe implementations where the HPD pin is not
connected or used for other purposes, such as in the RK3588S based
Gameforce Ace which repurposed the GPIO for an additional face
button.
The "no-hpd" option was chosen to be consistent with other devices
which already define this parameter for broken or missing hpd
functionality.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251119225526.70588-2-macroalpha82@gmail.com
