Alex Deucher [Wed, 15 May 2024 15:25:49 +0000 (11:25 -0400)]
drm/amdgpu: Adjust logic in amdgpu_device_partner_bandwidth()
Use current speed/width on devices which don't support
dynamic PCIe switching.
Fixes: 466a7d115326 ("drm/amd: Use the first non-dGPU PCI device for BW limits") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3289 Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Mario Limonciello [Wed, 8 May 2024 21:45:35 +0000 (16:45 -0500)]
drm/amd/display: Enable colorspace property for MST connectors
MST colorspace property support was disabled due to a series of warnings
that came up when the device was plugged in since the properties weren't
made at device creation. Create the properties in advance instead.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 69a959610229 ("drm/amd/display: Temporary Disable MST DP Colorspace Property"). Reported-and-tested-by: Tyler Schneider <tyler.schneider@amd.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3353 Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Li Ma [Mon, 20 May 2024 10:43:55 +0000 (18:43 +0800)]
drm/amdgpu/atomfirmware: add intergrated info v2.3 table
[Why]
The vram width value is 0.
Because the integratedsysteminfo table in VBIOS has updated to 2.3.
[How]
Driver needs a new intergrated info v2.3 table too.
Then the vram width value will be correct.
Signed-off-by: Li Ma <li.ma@amd.com> Reviewed-by: Yifan Zhang <yifan1.zhang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
Wayne Lin [Thu, 7 Mar 2024 06:29:57 +0000 (14:29 +0800)]
drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2
[Why]
Commit:
- commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload allocation/removement")
accidently overwrite the commit
- commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2")
which cause regression.
[How]
Recover the original NULL fix and remove the unnecessary input parameter 'state' for
drm_dp_add_payload_part2().
Lang Yu [Fri, 26 Apr 2024 06:56:35 +0000 (14:56 +0800)]
drm/amdkfd: Let VRAM allocations go to GTT domain on small APUs
Small APUs(i.e., consumer, embedded products) usually have a small
carveout device memory which can't satisfy most compute workloads
memory allocation requirements.
We can't even run a Basic MNIST Example with a default 512MB carveout.
https://github.com/pytorch/examples/tree/main/mnist. Error Log:
"torch.cuda.OutOfMemoryError: HIP out of memory. Tried to allocate
84.00 MiB. GPU 0 has a total capacity of 512.00 MiB of which 0 bytes
is free. Of the allocated memory 103.83 MiB is allocated by PyTorch,
and 22.17 MiB is reserved by PyTorch but unallocated"
Though we can change BIOS settings to enlarge carveout size,
which is inflexible and may bring complaint. On the other hand,
the memory resource can't be effectively used between host and device.
The solution is MI300A approach, i.e., let VRAM allocations go to GTT.
Then device and host can flexibly and effectively share memory resource.
v2: Report local_mem_size_private as 0. (Felix)
Signed-off-by: Lang Yu <Lang.Yu@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Liu Ying [Mon, 13 May 2024 08:02:43 +0000 (16:02 +0800)]
drm/bridge: adv7511: Attach next bridge without creating connector
The connector is created by either this ADV7511 bridge driver or
any DRM device driver/previous bridge driver, so this ADV7511
bridge driver should not let the next bridge driver create connector.
If the next bridge is a HDMI connector, the next bridge driver
would fail to attach bridge from display_connector_attach() without
the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
Add that flag to drm_bridge_attach() function call in
adv7511_bridge_attach() to fix the issue.
This fixes the issue where the HDMI connector bridge fails to attach
to the previous ADV7535 bridge on i.MX8MP EVK platform:
[ 2.216442] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /hdmi-connector to encoder None-37: -22
[ 2.220675] mmc1: SDHCI controller on 30b50000.mmc [30b50000.mmc] using ADMA
[ 2.226262] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@30800000/i2c@30a30000/hdmi@3d to encoder None-37: -22
[ 2.245204] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@32c00000/dsi@32e60000 to encoder None-37: -22
[ 2.256445] imx-lcdif 32e80000.display-controller: error -EINVAL: Failed to attach bridge for endpoint0
[ 2.265850] imx-lcdif 32e80000.display-controller: error -EINVAL: Cannot connect bridge
[ 2.274009] imx-lcdif 32e80000.display-controller: probe with driver imx-lcdif failed with error -22
Fixes: 14b3cdbd0e5b ("drm/bridge: adv7511: make it honour next bridge in DT") Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Robert Foss <rfoss@kernel.org> Acked-by: Sui Jingfeng <suijingfeng@bosc.ac.cn> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240513080243.3952292-1-victor.liu@nxp.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Move the fallback and block incompatible checks
above, so that we dont unnecessarily split the blocks
and leaving the unmerged. This resolves the unnecessary
warn on's thrown during force_merge call.
v2:(Matthew)
- Move the fallback and block incompatible checks above
the contains check.
drm/tests: Add a unit test for range bias allocation
Allocate cleared blocks in the bias range when the DRM
buddy's clear avail is zero. This will validate the bias
range allocation in scenarios like system boot when no
cleared blocks are available and exercise the fallback
path too. The resulting blocks should always be dirty.
v1:(Matthew)
- move the size to the variable declaration section.
- move the mm.clear_avail init to allocator init.
drm/buddy: Fix the range bias clear memory allocation issue
Problem statement: During the system boot time, an application request
for the bulk volume of cleared range bias memory when the clear_avail
is zero, we dont fallback into normal allocation method as we had an
unnecessary clear_avail check which prevents the fallback method leads
to fb allocation failure following system goes into unresponsive state.
Solution: Remove the unnecessary clear_avail check in the range bias
allocation function.
v2: add a kunit for this corner case (Daniel Vetter)
Mohamed Ahmed [Thu, 9 May 2024 20:43:52 +0000 (23:43 +0300)]
drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations
Allow PTE kind and tile mode on BO create with VM_BIND, and add a
GETPARAM to indicate this change. This is needed to support modifiers in
NVK and ensure correctness when dealing with the nouveau GL driver.
The userspace modifiers implementation this is for can be found here:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24795
Mohamed Ahmed [Thu, 9 May 2024 20:43:52 +0000 (23:43 +0300)]
drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations
Allow PTE kind and tile mode on BO create with VM_BIND, and add a
GETPARAM to indicate this change. This is needed to support modifiers in
NVK and ensure correctness when dealing with the nouveau GL driver.
The userspace modifiers implementation this is for can be found here:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24795
Boris Brezillon [Thu, 2 May 2024 18:38:12 +0000 (20:38 +0200)]
drm/panthor: Call panthor_sched_post_reset() even if the reset failed
We need to undo what was done in panthor_sched_pre_reset() even if the
reset failed. We just flag all previously running groups as terminated
when that happens to unblock things.
Boris Brezillon [Thu, 2 May 2024 16:51:57 +0000 (18:51 +0200)]
drm/panthor: Fix an off-by-one in the heap context retrieval logic
The heap ID is used to index the heap context pool, and allocating
in the [1:MAX_HEAPS_PER_POOL] leads to an off-by-one. This was
originally to avoid returning a zero heap handle, but given the handle
is formed with (vm_id << 16) | heap_id, with vm_id > 0, we already can't
end up with a valid heap handle that's zero.
v4:
- s/XA_FLAGS_ALLOC1/XA_FLAGS_ALLOC/
v3:
- Allocate in the [0:MAX_HEAPS_PER_POOL-1] range
v2:
- New patch
Fixes: 9cca48fa4f89 ("drm/panthor: Add the heap logical block") Reported-by: Eric Smith <eric.smith@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Tested-by: Eric Smith <eric.smith@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240502165158.1458959-5-boris.brezillon@collabora.com
Boris Brezillon [Thu, 2 May 2024 16:51:56 +0000 (18:51 +0200)]
drm/panthor: Relax the constraints on the tiler chunk size
The field used to store the chunk size if 12 bits wide, and the encoding
is chunk_size = chunk_header.chunk_size << 12, which gives us a
theoretical [4k:8M] range. This range is further limited by
implementation constraints, and all known implementations seem to
impose a [128k:8M] range, so do the same here.
We also relax the power-of-two constraint, which doesn't seem to
exist on v10. This will allow userspace to fine-tune initial/max
tiler memory on memory-constrained devices.
v4:
- Actually fix the range in the kerneldoc
v3:
- Add R-bs
- Fix valid range in the kerneldoc
v2:
- Turn the power-of-two constraint into a page-aligned constraint to allow
fine-tune of the initial/max heap memory size
- Fix the panthor_heap_create() kerneldoc
Antonino Maniscalco [Thu, 2 May 2024 16:51:54 +0000 (18:51 +0200)]
drm/panthor: Fix tiler OOM handling to allow incremental rendering
If the kernel couldn't allocate memory because we reached the maximum
number of chunks but no render passes are in flight
(panthor_heap_grow() returning -ENOMEM), we should defer the OOM
handling to the FW by returning a NULL chunk. The FW will then call
the tiler OOM exception handler, which is supposed to implement
incremental rendering (execute an intermediate fragment job to flush
the pending primitives, release the tiler memory that was used to
store those primitives, and start over from where it stopped).
Instead of checking for both ENOMEM and EBUSY, make panthor_heap_grow()
return ENOMEM no matter the reason of this allocation failure, the FW
doesn't care anyway.
v3:
- Add R-bs
v2:
- Make panthor_heap_grow() return -ENOMEM for all kind of allocation
failures
- Document the panthor_heap_grow() semantics
Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Signed-off-by: Antonino Maniscalco <antonino.maniscalco@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240502165158.1458959-2-boris.brezillon@collabora.com
Dave Airlie [Fri, 10 May 2024 00:22:58 +0000 (10:22 +1000)]
Merge tag 'drm-msm-next-2024-05-07' of https://gitlab.freedesktop.org/drm/msm into drm-next
Updates for v6.10
Core:
- Switched to generating register header files during build process
instead of shipping pre-generated headers
- Merged DPU and MDP4 format databases.
DP:
- Stop using compat string to distinguish DP and eDP cases
- Added support for X Elite platform (X1E80100)
- Reworked DP aux/audio support
- Added SM6350 DP to the bindings (no driver changes, using SM8350
as a fallback compat)
Lucas De Marchi [Mon, 6 May 2024 14:19:17 +0000 (07:19 -0700)]
drm/xe/ads: Use flexible-array
Zero-length arrays are deprecated and flexible arrays should be
used instead: https://www.kernel.org/doc/html/v6.9-rc7/process/deprecated.html#zero-length-and-one-element-arrays
Reported-by: kernel test robot <lkp@intel.com> Reported-by: Julia Lawall <julia.lawall@inria.fr> Closes: https://lore.kernel.org/r/202405051824.AmjAI5Pg-lkp@intel.com/ Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240506141917.205714-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
(cherry picked from commit ee7284230644e21fef0e38fc5bf8f907b6bb7f7c) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Dmitry Baryshkov [Fri, 3 May 2024 18:15:03 +0000 (21:15 +0300)]
drm/msm/gen_header: allow skipping the validation
We don't need to run the validation of the XML files if we are just
compiling the kernel. Skip the validation unless the user enables
corresponding Kconfig option. This removes a warning from gen_header.py
about lxml being not installed.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/all/20240409120108.2303d0bd@canb.auug.org.au/ Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/592558/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Rob Clark [Sat, 4 May 2024 16:31:13 +0000 (09:31 -0700)]
drm/msm/a6xx: Cleanup indexed regs const'ness
These tables were made non-const in commit 3cba4a2cdff3 ("drm/msm/a6xx:
Update ROQ size in coredump") in order to avoid powering up the GPU when
reading back a devcoredump. Instead let's just stash the count that is
potentially read from hw in struct a6xx_gpu_state_obj, and make the
tables const again.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/592699/
Connor Abbott [Fri, 3 May 2024 13:42:34 +0000 (14:42 +0100)]
drm/msm: Add devcoredump support for a750
Add an a750 case to the various places where we choose a list of
registers.
Patchwork: https://patchwork.freedesktop.org/patch/592519/
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/592519 Signed-off-by: Rob Clark <robdclark@chromium.org>
Connor Abbott [Fri, 3 May 2024 13:42:33 +0000 (14:42 +0100)]
drm/msm: Adjust a7xx GBIF debugbus dumping
Use the kgsl-style list of indices, because this is about to change for
a750 and we want to reuse the downstream header directly.
Patchwork: https://patchwork.freedesktop.org/patch/592520/
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/592520 Signed-off-by: Rob Clark <robdclark@chromium.org>
Connor Abbott [Fri, 3 May 2024 13:42:32 +0000 (14:42 +0100)]
drm/msm: Update a6xx registers XML
Update to Mesa commit e82d70d472cc ("freedreno/a7xx: Add
A7XX_HLSQ_DP_STR location from kgsl").
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/592518/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Connor Abbott [Fri, 3 May 2024 13:42:31 +0000 (14:42 +0100)]
drm/msm: Fix imported a750 snapshot header for upstream
Add A7XX prefixes necessary because we use the same code for dumping
a6xx and a7xx, fix register name prefixes for upstream, and use the
upstream header.
Patchwork: https://patchwork.freedesktop.org/patch/592517/
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/592517 Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/592516/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Konrad Dybcio [Mon, 22 Apr 2024 22:41:32 +0000 (00:41 +0200)]
MAINTAINERS: Add Konrad Dybcio as a reviewer for the Adreno driver
Add myself as a reviewer for Adreno driver changes.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/590705/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Konrad Dybcio [Mon, 22 Apr 2024 22:41:31 +0000 (00:41 +0200)]
MAINTAINERS: Add a separate entry for Qualcomm Adreno GPU drivers
The msm driver is.. gigantic and covers display hardware (incl. things
concerning (e)DP, DSI, HDMI), as well as the entire lineup of Adreno
GPUs (with hw bringup, memory mappings, userspace interaction etc.).
Because of that, people listed as M:/R: receive patches concerning
drivers for any part of the display block OR the GPU. Separate the
latter, as it's both a functionally separate block and is of
interest to different folks.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/590704/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Instead of relying on handwavy null checks down the cleanup chain,
explicitly de-allocate the LLC data and free a6xx_gpu instead.
Fixes: 76efc2453d0e ("drm/msm/gpu: Fix crash during system suspend after unbind") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/588919/ Signed-off-by: Rob Clark <robdclark@chromium.org>
drm/msm/adreno: fix CP cycles stat retrieval on a7xx
a7xx_submit() should use the a7xx variant of the RBBM_PERFCTR_CP register
for retrieving the CP cycles value before and after the submitted command
stream execution.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com> Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support")
Patchwork: https://patchwork.freedesktop.org/patch/588445/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Zan Dobersek [Thu, 29 Feb 2024 07:49:11 +0000 (08:49 +0100)]
drm/msm/a7xx: allow writing to CP_BV counter selection registers
In addition to the CP_PERFCTR_CP_SEL register range, allow writes to the
CP_BV_PERFCTR_CP_SEL registers in the 0x8e0-0x8e6 range for profiling
purposes of tools like fdperf and perfetto.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Patchwork: https://patchwork.freedesktop.org/patch/580548/
[fixup a730_protect size] Signed-off-by: Rob Clark <robdclark@chromium.org>
When no mode is set, the utility pin appears to be grounded. No signal
is getting through.
This is problematic because ARC and eARC use this line and may do so even
if no display mode is set.
This change enable the bandgap setting on g12 chip, which fix the problem
with the utility pin. This is done by restoring init values on PHY init and
disable.
The phy is not in a useful state right after init. It will become useful,
including for auxiliary function such as CEC or ARC, after the first mode
is set. This is a problem on systems where the display is using another
interface like DSI or CVBS.
This change refactor the init and mode change callback to power up the PHY
on init and leave only what is necessary for mode changes in the related
function. This is enough to fix CEC operation when HDMI display is not
enabled.
Sean Anderson [Fri, 8 Mar 2024 20:47:41 +0000 (15:47 -0500)]
drm: zynqmp_dpsub: Always register bridge
We must always register the DRM bridge, since zynqmp_dp_hpd_work_func
calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be
initialized. We do this before zynqmp_dpsub_drm_init since that calls
drm_bridge_attach. This fixes the following lockdep warning:
The regulator_disable() added by the original commit solves one kind of
regulator imbalance but adds another one as it allows the regulator to be
disabled one more time than it is enabled in the following scenario:
The use case for introducing the additional regulator_disable() was
removing the module for debugging (see link below for the discussion). If
the module is removed after a .atomic_pre_enable, i.e. with an active
pipeline from the DRM point of view, .atomic_disable is not called and thus
the regulator would not be disabled.
According to the discussion however there is no actual use case for
removing the module with an active pipeline, except for
debugging/development.
On the other hand, the occurrence of a PLL lock failure is possible due to
any physical reason (e.g. a temporary hardware failure for electrical
reasons) so handling it gracefully should be supported. As there is no way
for .atomic[_pre]_enable to report an error to the core, the only clean way
to support it is calling regulator_disabled() only in .atomic_disable,
unconditionally, as it was before.
Thomas Zimmermann [Fri, 19 Apr 2024 08:28:54 +0000 (10:28 +0200)]
drm/fbdev-generic: Do not set physical framebuffer address
Framebuffer memory is allocated via vzalloc() from non-contiguous
physical pages. The physical framebuffer start address is therefore
meaningless. Do not set it.
The value is not used within the kernel and only exported to userspace
on dedicated ARM configs. No functional change is expected.
v2:
- refer to vzalloc() in commit message (Javier)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: a5b44c4adb16 ("drm/fbdev-generic: Always use shadow buffering") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Zack Rusin <zackr@vmware.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: <stable@vger.kernel.org> # v6.4+ Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Sui Jingfeng <sui.jingfeng@linux.dev> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240419083331.7761-2-tzimmermann@suse.de
(cherry picked from commit 73ef0aecba78aa9ebd309b10b6cd17d94e632892) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Boris Brezillon [Tue, 30 Apr 2024 11:37:27 +0000 (13:37 +0200)]
drm/panthor: Fix the FW reset logic
In the post_reset function, if the fast reset didn't succeed, we
are not clearing the fast_reset flag, which prevents firmware
sections from being reloaded. While at it, use panthor_fw_stop()
instead of manually writing DISABLE to the MCU_CONTROL register.
Boris Brezillon [Thu, 2 May 2024 15:52:48 +0000 (17:52 +0200)]
drm/panthor: Make sure we handle 'unknown group state' case properly
When we check for state values returned by the FW, we only cover part of
the 0:7 range. Make sure we catch FW inconsistencies by adding a default
to the switch statement, and flagging the group state as unknown in that
case.
When an unknown state is detected, we trigger a reset, and consider the
group as unusable after that point, to prevent the potential corruption
from creeping in other places if we continue executing stuff on this
context.
v2:
- Add Steve's R-b
- Fix commit message
Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/dri-devel/3b7fd2f2-679e-440c-81cd-42fc2573b515@moroto.mountain/T/#u Suggested-by: Steven Price <steven.price@arm.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240502155248.1430582-1-boris.brezillon@collabora.com
drm: move DRM-related CONFIG options into DRM submenu
When you create a submenu using the 'menu' syntax, there is no
ambiguity about its end because the code between 'menu' and 'endmenu'
becomes the submenu.
In contrast, 'menuconfig' does not have the corresponding end marker.
Instead, the end of the submenu is inferred from symbol dependencies.
This is detailed in Documentation/kbuild/kconfig-language.rst, starting
line 348. It outlines two methods to place the code under the submenu:
(1) Open an if-block immediately after 'menuconfig', enclosing the
submenu content within it
(2) Add 'depends on' to every symbol intended for the submenu
Many subsystems opt for (1) because it reliably maintains the submenu
structure.
The DRM subsystem adopts (2). The submenu ends when the sequence of
'depends on DRM' breaks. It can be confirmed by running a GUI frontend
such as 'make menuconfig' and visiting the DRM menu:
< > Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) ----
If you toggle this, you will notice most of the DRM-related options
appear below it, not in the submenu.
I highly recommend the approach (1). Obviously, (2) is not reliable,
as the submenu breaks whenever someone forgets to add 'depends on DRM'.
This commit encloses the entire DRM configuration with 'if DRM' and
'endif', except for DRM_PANEL_ORIENTATION_QUIRKS.
Note:
Now, 'depends on DRM' properties inside the if-block are all redundant.
I leave it as follow-up cleanups.
Revert "drm/display: Make all helpers visible and switch to depends on"
This reverts commit d674858ff979550a0e97b4ac766f2640f0d9d7e7, as helper
code should always be selected by the driver that needs it, for the
convenience of the final user configuring a kernel.
The user who configures a kernel should not need to know which helpers
are needed for the driver he is interested in. Making a driver depend
on helper code means that the user needs to know which helpers to enable
first, which is very user-unfriendly.
This reverts commit c0e0f139354c01e0213204e4a96e7076e5a3e396, as helper
code should always be selected by the driver that needs it, for the
convenience of the final user configuring a kernel.
The user who configures a kernel should not need to know which helpers
are needed for the driver he is interested in. Making a driver depend
on helper code means that the user needs to know which helpers to enable
first, which is very user-unfriendly.
Revert "drm: Switch DRM_DISPLAY_HELPER to depends on"
This reverts commit e075e496f516bf92bc0cbaf94d64e8d4a6b58321, as helper
code should always be selected by the driver that needs it, for the
convenience of the final user configuring a kernel.
The user who configures a kernel should not need to know which helpers
are needed for the driver he is interested in. Making a driver depend
on helper code means that the user needs to know which helpers to enable
first, which is very user-unfriendly.
Revert "drm: Switch DRM_DISPLAY_DP_AUX_BUS to depends on"
This reverts commit 4d15125d7fe637f401e64e33c99513adf6586fdd, as helper
code should always be selected by the driver that needs it, for the
convenience of the final user configuring a kernel.
The user who configures a kernel should not need to know which helpers
are needed for the driver he is interested in. Making a driver depend
on helper code means that the user needs to know which helpers to enable
first, which is very user-unfriendly.
Revert "drm: Switch DRM_DISPLAY_DP_HELPER to depends on"
This reverts commit 0323287de87d7e6e9c22c57d7440aa353a2298d0, as helper
code should always be selected by the driver that needs it, for the
convenience of the final user configuring a kernel.
The user who configures a kernel should not need to know which helpers
are needed for the driver he is interested in. Making a driver depend
on helper code means that the user needs to know which helpers to enable
first, which is very user-unfriendly.
Revert "drm: Switch DRM_DISPLAY_HDCP_HELPER to depends on"
This reverts commit 3166e7e6d935caaef07605a5c90773fbf9ffeaf4, as helper
code should always be selected by the driver that needs it, for the
convenience of the final user configuring a kernel.
The user who configures a kernel should not need to know which helpers
are needed for the driver he is interested in. Making a driver depend
on helper code means that the user needs to know which helpers to enable
first, which is very user-unfriendly.
Revert "drm: Switch DRM_DISPLAY_HDMI_HELPER to depends on"
This reverts commit f6d2dc03fa8546b284dd8c1af027d9fac5725921, as helper
code should always be selected by the driver that needs it, for the
convenience of the final user configuring a kernel.
The user who configures a kernel should not need to know which helpers
are needed for the driver he is interested in. Making a driver depend
on helper code means that the user needs to know which helpers to enable
first, which is very user-unfriendly.
In order to detect duplicate implementations for the same workaround,
early in the implementation of RTP it was decided to error out even if
the values set are exactly the same. With the introduction of 18034896535
in commit 74671d23ca18 ("drm/xe/xe2: Add workaround 18034896535"), LNL
stepping with graphics stepping A1 now gives the following error on
module load:
Matthew Auld [Tue, 23 Apr 2024 07:47:23 +0000 (08:47 +0100)]
drm/xe/vm: prevent UAF in rebind_work_func()
We flush the rebind worker during the vm close phase, however in places
like preempt_fence_work_func() we seem to queue the rebind worker
without first checking if the vm has already been closed. The concern
here is the vm being closed with the worker flushed, but then being
rearmed later, which looks like potential uaf, since there is no actual
refcounting to track the queued worker. We can't take the vm->lock here
in preempt_rebind_work_func() to first check if the vm is closed since
that will deadlock, so instead flush the worker again when the vm
refcount reaches zero.
v2:
- Grabbing vm->lock in the preempt worker creates a deadlock, so
checking the closed state is tricky. Instead flush the worker when
the refcount reaches zero. It should be impossible to queue the
preempt worker without already holding vm ref.
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1676 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1591 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1364 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1304 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1249 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240423074721.119633-4-matthew.auld@intel.com
(cherry picked from commit 3d44d67c441a9fe6f81a1d705f7de009a32a5b35) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Thomas Hellström [Tue, 23 Apr 2024 12:11:14 +0000 (14:11 +0200)]
drm/xe: Fix unexpected backmerge results
The recent backmerge from drm-next to drm-xe-next brought with it
some silent unexpected results. One code snippet was added twice
and a partial revert had merge errors. Fix that up to
reinstate the affected code as it was before the backmerge.
Andy Shevchenko [Thu, 25 Apr 2024 14:26:19 +0000 (17:26 +0300)]
drm/panel: ili9341: Use predefined error codes
In one case the -1 is returned which is quite confusing code for
the wrong device ID, in another the ret is returning instead of
plain 0 that also confusing as readed may ask the possible meaning
of positive codes, which are never the case there. Convert both
to use explicit predefined error codes to make it clear what's going
on there.
Andy Shevchenko [Thu, 25 Apr 2024 14:26:18 +0000 (17:26 +0300)]
drm/panel: ili9341: Respect deferred probe
GPIO controller might not be available when driver is being probed.
There are plenty of reasons why, one of which is deferred probe.
Since GPIOs are optional, return any error code we got to the upper
layer, including deferred probe. With that in mind, use dev_err_probe()
in order to avoid spamming the logs.
Display i915:
- More initial work to make display code more independent from i915 (Jani)
- Convert i915/xe fbdev to DRM client (Thomas Zimmermann)
- VLV/CHV DPIO register cleanup (Ville)
Ville Syrjälä [Mon, 22 Apr 2024 08:34:56 +0000 (11:34 +0300)]
drm/i915/dpio: Clean up the vlv/chv PHY register bits
Use REG_BIT() & co. for the vlv/chv DPIO PHY registers.
Note that DPIO_BIAS_CURRENT_CTL_SHIFT was incorrectly defined
to be 21 wheres 20 is the correct value. It is not used in the
code though so didn't bother splitting to a separate patch.
Ville Syrjälä [Mon, 22 Apr 2024 08:34:54 +0000 (11:34 +0300)]
drm/i915/dpio: Rename a few CHV DPIO PHY registers
Drop the leading underscore from the CHV PHY common lane
register definitions. We use these directly from actual
code so the underscore here is misleading as usually it indicates
an intermediate define that shouldn't be used directly.
Ville Syrjälä [Mon, 22 Apr 2024 08:34:53 +0000 (11:34 +0300)]
drm/i915/dpio: Give VLV DPIO group register a clearer name
Include _GRP in VLV DPIO PHY group access register define
names. Makes it more obvious where the accesses will land.
Also matches the naming used by BXT already.
Ville Syrjälä [Mon, 22 Apr 2024 08:34:52 +0000 (11:34 +0300)]
drm/i915/dpio: Derive the phy from the port rather than pipe in encoder hooks
In the encoder hooks we are dealing primarily with the encoder,
so derive the DPIO PHY from the encoder rather than the pipe.
Technically this doesn't matter as we can't cross connect
pipes<->port across PHY boundaries, but it does conveny the
intention more accurately.
Ville Syrjälä [Mon, 22 Apr 2024 08:34:51 +0000 (11:34 +0300)]
drm/i915/dpio: s/pipe/ch/
Stop using 'pipe' directly as the DPIO PHY channel. This
does happen to work on VLV since it just has the one PHY
with CH0==pipe A and CH1==pipe B. But explicitly converting
the thing to the right enum makes the whole thing less
confusing.
VLV_PLL_DW9_BCAST is actually VLV_PCS_DW17_BCAST. The address
does kinda look like it goes to the PLL block on a first glance,
but broadcast is special and doesn't even exist for the PLL
(only PCS and TX have it).
The fact that we use a broadcast write here is a bit sketchy
IMO since we're now blasting the register to all PCS splines
across the whole PHY. So the PCS registers in the other channel
(ie. other pipe/port) will also be written. But I guess the
fact that we always write the same value should make this a nop
even if the other channel is already enabled (assuming the VBIOS/GOP
didn't screw up and use some other value...).
drm/vmwgfx: Fix invalid reads in fence signaled events
Correctly set the length of the drm_event to the size of the structure
that's actually used.
The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.
Lyude Paul [Mon, 29 Apr 2024 18:23:09 +0000 (14:23 -0400)]
drm/nouveau/gsp: Use the sg allocator for level 2 of radix3
Currently we allocate all 3 levels of radix3 page tables using
nvkm_gsp_mem_ctor(), which uses dma_alloc_coherent() for allocating all of
the relevant memory. This can end up failing in scenarios where the system
has very high memory fragmentation, and we can't find enough contiguous
memory to allocate level 2 of the page table.
Currently, this can result in runtime PM issues on systems where memory
fragmentation is high - as we'll fail to allocate the page table for our
suspend/resume buffer:
Luckily, we don't actually need to allocate coherent memory for the page
table thanks to being able to pass the GPU a radix3 page table for
suspend/resume data. So, let's rewrite nvkm_gsp_radix3_sg() to use the sg
allocator for level 2. We continue using coherent allocations for lvl0 and
1, since they only take a single page.
V2:
* Don't forget to actually jump to the next scatterlist when we reach the
end of the scatterlist we're currently on when writing out the page table
for level 2
We hit this when trying to initialize firmware of type
NVKM_FIRMWARE_IMG_DMA because we allocate our memory with
dma_alloc_coherent, and DMA allocations can't be turned back into memory
pages - which a scatterlist needs in order to map them.
So, fix this by allocating the memory with vmalloc instead().
V2:
* Fixup explanation as the prior one was bogus
projects / users / dwmw2 / linux.git / log