Simona Vetter [Wed, 8 Jan 2025 17:24:16 +0000 (18:24 +0100)]
drm/atomic: clarify the rules around drm_atomic_state->allow_modeset
msm is automagically upgrading normal commits to full modesets, and
that's a big no-no:
- for one this results in full on->off->on transitions on all these
crtc, at least if you're using the usual helpers. Which seems to be
the case, and is breaking uapi
- further even if the ctm change itself would not result in flicker,
this can hide modesets for other reasons. Which again breaks the
uapi
v2: I forgot the case of adding unrelated crtc state. Add that case
and link to the existing kerneldoc explainers. This has come up in an
irc discussion with Manasi and Ville about intel's bigjoiner mode.
Also cc everyone involved in the msm irc discussion, more people
joined after I sent out v1.
v3: Wording polish from Pekka and Thomas
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Simon Ser <contact@emersion.fr> Cc: Manasi Navare <navaremanasi@google.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Simona Vetter <simona.vetter@intel.com> Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20250108172417.160831-1-simona.vetter@ffwll.ch
Lin.Cao [Thu, 26 Dec 2024 07:01:15 +0000 (12:31 +0530)]
drm/buddy: fix issue that force_merge cannot free all roots
If buddy manager have more than one roots and each root have sub-block
need to be free. When drm_buddy_fini called, the first loop of
force_merge will merge and free all of the sub block of first root,
which offset is 0x0 and size is biggest(more than have of the mm size).
In subsequent force_merge rounds, if we use 0 as start and use remaining
mm size as end, the block of other roots will be skipped in
__force_merge function. It will cause the other roots can not be freed.
Solution: use roots' offset as the start could fix this issue.
The mailbox payload pointer is void __iomem *. Casting it to u32 * is
incorrect and causes sparse warning.
cast removes address space '__iomem' of expression
Fixes: b87f920b9344 ("accel/amdxdna: Support hardware mailbox") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501130921.ktqwsMLH-lkp@intel.com/ Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250113182617.1256094-1-lizhi.hou@amd.com
We've been unable to locate a datasheet for this panel and our partner
has not been responsive, but all Starry eDP datasheets that we can
find agree on the same timing (delay_100_500_e200) so it should be
safe to use that here instead of the super conservative timings. We'll
still go a little extra conservative and allow `hpd_absent` of 200
instead of 100 because that won't add any real-world delay in most
cases.
We'll associate the string from the EDID ("116KHD024006") with this
panel. Given that the ID is the suspicious value of 0x0004 it seems
likely that Starry doesn't always update their IDs but the string will
still work to differentiate if we ever need to in the future.
Thomas Hellström [Tue, 17 Dec 2024 14:58:46 +0000 (15:58 +0100)]
drm/ttm/pool: Restructure the pool allocation code
Simplify the pool allocation code somewhat by merging loop arguments
used by multiple functions together in a struct and simplifying the
loop. Also add documentation.
This hopefully makes the behaviour of the allocation loop
simplier to understand, but above all paves the way for upcoming
restore-while-allocating functionality.
There are no functional changes, but the "allow_pools" bool
introduced to keep current functionality could be removed as a
follow up, which would enable using write-back cached pools when
allocating memory for other caching modes, rather than to resort
to allocating from the system directly.
v15:
- Introduce this patch to simplify the upcoming patch that introduces
restore while allocating.
Boris Brezillon [Tue, 17 Dec 2024 09:24:57 +0000 (10:24 +0100)]
drm/panthor: Fix a race between the reset and suspend path
If a reset is scheduled when the suspend happens, we drop the
reset-pending info on the floor assuming the resume will fix things,
but the resume logic might try a fast reset. If we're lucky, the
fast reset fails and we fallback to a slow reset, but if the FW was
corrupted in a way that makes it partially functional (it boots but
doesn't quite do what it's expected to do), we won't notice immediately
that things are not working correctly, leading to a new reset further
down the road.
Randy Dunlap [Sat, 11 Jan 2025 06:28:32 +0000 (22:28 -0800)]
drm/panthor: fix all mmu kernel-doc comments
Use the correct format for all kernel-doc comments.
Use structname.membername for named structs.
Don't precede function names in kernel-doc with '@' sign.
Use the correct function parameter names in kernel-doc comments.
This fixes around 80 kernel-doc warnings.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Steven Price <steven.price@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250111062832.910495-1-rdunlap@infradead.org
The code that changes hdmi->ref_clk was accidentally copied from
downstream code that sets a different clock. We don't actually
want to set any clock here at all.
Setting this clock incorrectly leads to incorrect timings for
DDC, CEC, and HDCP signal generation.
No Fixes listed, as the theoretical timing error in DDC appears to
still be within tolerances and harmless - and HDCP and CEC are not
yet supported.
Lizhi Hou [Thu, 9 Jan 2025 19:48:11 +0000 (11:48 -0800)]
accel/amdxdna: Return error when setting clock failed for npu1
Due to miss returning error when setting clock, the smatch static
checker reports warning:
drivers/accel/amdxdna/aie2_smu.c:68 npu1_set_dpm()
error: uninitialized symbol 'freq'.
Fixes: f4d7b8a6bc8c ("accel/amdxdna: Enhance power management settings") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/dri-devel/202267d0-882e-4593-b58d-be9274592f9b@stanley.mountain/ Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250109194811.499505-1-lizhi.hou@amd.com
Tvrtko Ursulin [Fri, 15 Nov 2024 10:21:51 +0000 (10:21 +0000)]
dma-fence: Add a single fence fast path for fence merging
Testing some workloads in two different scenarios, such as games running
under Gamescope on a Steam Deck, or vkcube under a Plasma desktop, shows
that in a significant portion of calls the dma_fence_unwrap_merge helper
is called with just a single unsignalled fence.
Therefore it is worthile to add a fast path for that case and so bypass
the memory allocation and insertion sort attempts.
Tested scenarios:
1) Hogwarts Legacy under Gamescope
~1500 calls per second to __dma_fence_unwrap_merge.
Percentages per number of fences buckets, before and after checking for
signalled status, sorting and flattening:
N Before After
0 0.85%
1 69.80% -> The new fast path.
2-9 29.36% 9% (Ie. 91% of this bucket flattened to 1 fence)
10-19
20-40
50+
2) Cyberpunk 2077 under Gamescope
~2400 calls per second.
N Before After
0 0.71%
1 52.53% -> The new fast path.
2-9 44.38% 50.60% (Ie. half resolved to a single fence)
10-19 2.34%
20-40 0.06%
50+
3) vkcube under Plasma
90 calls per second.
N Before After
0
1
2-9 100% 0% (Ie. all resolved to a single fence)
10-19
20-40
50+
In the case of vkcube all invocations in the 2-9 bucket were actually
just two input fences.
v2:
* Correct local variable name and hold on to unsignaled reference. (Chistian)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Friedrich Vock <friedrich.vock@gmx.de> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241115102153.1980-4-tursulin@igalia.com
Dmitry Osipenko [Mon, 2 Dec 2024 05:39:55 +0000 (08:39 +0300)]
drm/virtio: Factor out common dmabuf unmapping code
Move out dmabuf detachment and unmapping into separate function. This
removes duplicated code and there is no need to check the GEM's kref now,
since both bo->attached and bo->sgt are unset under held reservation lock.
Dmitry Osipenko [Fri, 29 Nov 2024 15:53:57 +0000 (18:53 +0300)]
drm/virtio: Set missing bo->attached flag
VirtIO-GPU driver now supports detachment of shmem BOs from host, but
doing it only for imported dma-bufs. Mark all shmem BOs as attached, not
just dma-bufs. This is a minor correction since detachment of a non-dmabuf
BOs not supported today.
Vivek Kasireddy [Wed, 11 Dec 2024 06:43:43 +0000 (22:43 -0800)]
drm/virtio: Lock the VGA resources during initialization
If another driver for a VGA compatible GPU (that is passthrough'd)
locks the VGA resources (by calling vga_get()), then virtio_gpu
driver would encounter the following errors and fail to load during
probe and initialization:
Invalid read at addr 0x7200005014, size 1, region '(null)', reason: rejected
Invalid write at addr 0x7200005014, size 1, region '(null)', reason: rejected
virtio_gpu virtio0: virtio: device uses modern interface but does not have VIRTIO_F_VERSION_1
virtio_gpu virtio0: probe with driver virtio_gpu failed with error -22
This issue is only seen if virtio-gpu and the other GPU are on
different PCI buses, which can happen if the user includes an
additional PCIe port and associates the VGA compatible GPU with
it while launching Qemu:
qemu-system-x86_64...
-device virtio-vga,max_outputs=1,xres=1920,yres=1080,blob=true
-device pcie-root-port,id=pcie.1,bus=pcie.0,addr=1c.0,slot=1,chassis=1,multifunction=on
-device vfio-pci,host=03:00.0,bus=pcie.1,addr=00.0 ...
In the above example, the device 03:00.0 is an Intel DG2 card and
this issue is seen when both i915 driver and virtio_gpu driver are
loading (or initializing) concurrently or when i915 is loaded first.
Note that during initalization, i915 driver does the following in
intel_vga_reset_io_mem():
vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO);
outb(inb(VGA_MIS_R), VGA_MIS_W);
vga_put(pdev, VGA_RSRC_LEGACY_IO);
Although, virtio-gpu might own the VGA resources initially, the
above call (in i915) to vga_get_uninterruptible() would result in
these resources being taken away, which means that virtio-gpu would
not be able to decode VGA anymore. This happens in __vga_tryget()
when it calls
pci_set_vga_state(conflict->pdev, false, pci_bits, flags);
where
pci_bits = PCI_COMMAND_MEMORY | PCI_COMMAND_IO
flags = PCI_VGA_STATE_CHANGE_DECODES | PCI_VGA_STATE_CHANGE_BRIDGE
Therefore, to solve this issue, virtio-gpu driver needs to call
vga_get() whenever it needs to reclaim and access VGA resources,
which is during initial probe and setup. After that, a call to
vga_put() would release the lock to allow other VGA compatible
devices to access these shared VGA resources.
Vivek Kasireddy [Thu, 12 Dec 2024 05:54:21 +0000 (21:54 -0800)]
drm/virtio: Fix UAF in virtgpu_dma_buf_free_obj()
Fix the following issues identified by Smatch static checker:
- The call to dma_buf_put(attach->dmabuf) after dma_buf_detach()
leads to a UAF bug as dma_buf_detach() frees the attach object.
Fix this by extracting the dmabuf object from attach and using
that in the call to dma_buf_put().
- The resv object is extracted from attach before checking to see
if attach is valid (that is !NULL) or not. Although, attach would
very likely be valid, fix this by making sure that the resv object
is used only after ensuring that attach is valid.
Fixes: 2885e575abc7 ("drm/virtio: Add helpers to initialize and free the imported object") Fixes: ca77f27a2665 ("drm/virtio: Import prime buffers from other devices as guest blobs") Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Cc: Gurchetan Singh <gurchetansingh@chromium.org> Cc: Chia-I Wu <olvaffe@gmail.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241212055421.775759-1-vivek.kasireddy@intel.com Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
[dmitry.osipenko@collabora.com: Edited commit title]
Karol Wachowski [Tue, 7 Jan 2025 17:32:35 +0000 (18:32 +0100)]
accel/ivpu: Add handling of VPU_JSM_STATUS_MVNCI_CONTEXT_VIOLATION_HW
Mark as invalid context of a job that returned HW context violation
error and queue work that aborts jobs from faulty context.
Add engine reset to the context abort thread handler to not only abort
currently executing jobs but also to ensure NPU invalid state recovery.
Karol Wachowski [Tue, 7 Jan 2025 17:32:34 +0000 (18:32 +0100)]
accel/ivpu: Fix locking order in ivpu_job_submit
Fix deadlock in job submission and abort handling.
When a thread aborts currently executing jobs due to a fault,
it first locks the global lock protecting submitted_jobs (#1).
After the last job is destroyed, it proceeds to release the related context
and locks file_priv (#2). Meanwhile, in the job submission thread,
the file_priv lock (#2) is taken first, and then the submitted_jobs
lock (#1) is obtained when a job is added to the submitted jobs list.
CPU0 CPU1
---- ----
(for example due to a fault) (jobs submissions keep coming)
Karol Wachowski [Tue, 7 Jan 2025 17:32:33 +0000 (18:32 +0100)]
accel/ivpu: Fix locking order in ivpu_cmdq_destroy_ioctl
Fix deadlock caused by inversed locking order in ivpu_job_submit()
and ivpu_cmdq_destroy_ioctl(). Both functions operate locking
file_priv->lock and submitted_jobs_lock.
Unlock file_priv->lock in ivpu_cmdq_destroy_ioctl() before calling
ivpu_cmdq_abort_all_jobs() function which locks submitted_jobs_lock.
That way locking order is maintained:
1) global submitted_jobs_lock first
2) per context file_priv->lock second
Karol Wachowski [Tue, 7 Jan 2025 17:32:32 +0000 (18:32 +0100)]
accel/ivpu: Set command queue management capability based on HWS
Control explicit command queue management capability bit based on
scheduling mode. Capability will be available only when hardware
scheduling mode is set.
There is no point of allowing user space to create and destroy command
queues with OS schedling mode because FW does not support all required
functionalities for correct command queue management with OS scheduling.
Return -ENODEV from command queue create/destroy/submit IOCTLs.
Karol Wachowski [Tue, 7 Jan 2025 17:32:31 +0000 (18:32 +0100)]
accel/ivpu: Fix missing MMU events from reserved SSID
Generate recovery when fault from reserved context is detected.
Add Abort (A) bit to reserved (1) SSID to ensure NPU also receives a fault.
There is no way to create a file_priv with reserved SSID
but it is still possible to receive MMU faults from that SSID
as it is a default NPU HW setting. Such situation will occur if
FW freed context related resources but still performed access to DRAM.
Karol Wachowski [Tue, 7 Jan 2025 17:32:30 +0000 (18:32 +0100)]
accel/ivpu: Move parts of MMU event IRQ handling to thread handler
To prevent looping infinitely in MMU event handler we stop
generating new events by removing 'R' (record) bit from context
descriptor, but to ensure this change has effect KMD has to perform
configuration invalidation followed by sync command.
Because of that move parts of the interrupt handler that can take longer
to a thread not to block in interrupt handler for too long.
This includes:
* disabling event queue for the time KMD updates MMU event queue consumer
to ensure proper synchronization between MMU and KMD
* removal of 'R' (record) bit from context descriptor to ensure no more
faults are recorded until that context is destroyed
Karol Wachowski [Tue, 7 Jan 2025 17:32:29 +0000 (18:32 +0100)]
accel/ivpu: Dump only first MMU fault from single context
Stop dumping consecutive faults from an already faulty context immediately,
instead of waiting for the context abort thread handler (IRQ handler bottom
half) to abort currently executing jobs.
Remove 'R' (record events) bit from context descriptor of a faulty
context to prevent future faults generation.
This change speeds up the IRQ handler by eliminating the need to print the
fault content repeatedly. Additionally, it prevents flooding dmesg with
errors, which was occurring due to the delay in the bottom half of the
handler stopping fault-generating jobs.
Maciej Falkowski [Tue, 7 Jan 2025 17:32:28 +0000 (18:32 +0100)]
accel/ivpu: Use workqueue for IRQ handling
Convert IRQ bottom half from the thread handler into workqueue.
This increases a stability in rare scenarios where driver on
debugging/hardening kernels processes IRQ too slow and misses
some interrupts due to it.
Workqueue handler also gives a very minor performance increase.
Karol Wachowski [Tue, 7 Jan 2025 17:32:26 +0000 (18:32 +0100)]
accel/ivpu: Abort all jobs after command queue unregister
With hardware scheduler it is not expected to receive JOB_DONE
notifications from NPU FW for the jobs aborted due to command queue destroy
JSM command.
Remove jobs submitted to unregistered command queue from submitted_jobs_xa
to avoid triggering a TDR in such case.
Add explicit submitted_jobs_lock that protects access to list of submitted
jobs which is now used to find jobs to abort.
Move context abort procedure to separate work queue not to slow down
handling of IPCs or DCT requests in case where job abort takes longer,
especially when destruction of the last job of a specific context results
in context release.
Karol Wachowski [Tue, 7 Jan 2025 17:32:25 +0000 (18:32 +0100)]
accel/ivpu: Add API for command queue create/destroy/submit
Implement support for explicit command queue management.
To allow more flexible control over command queues add capabilities
to create, destroy and submit jobs to specific command queues.
Karol Wachowski [Tue, 7 Jan 2025 17:32:24 +0000 (18:32 +0100)]
accel/ivpu: Separate DB ID and CMDQ ID allocations from CMDQ allocation
Move doorbell ID and command queue ID XArray allocations from command
queue memory allocation function. This will allow ID allocations to be
done without the need for actual memory allocation.
Javier Martinez Canillas [Tue, 31 Dec 2024 11:44:58 +0000 (12:44 +0100)]
drm/ssd130x: Set SPI .id_table to prevent an SPI core warning
The only reason for the ssd130x-spi driver to have an spi_device_id table
is that the SPI core always reports an "spi:" MODALIAS, even when the SPI
device has been registered via a Device Tree Blob.
Without spi_device_id table information in the module's metadata, module
autoloading would not work because there won't be an alias that matches
the MODALIAS reported by the SPI core.
This spi_device_id table is not needed for device matching though, since
the of_device_id table is always used in this case. For this reason, the
struct spi_driver .id_table member is currently not set in the SPI driver.
Because the spi_device_id table is always required for module autoloading,
the SPI core checks during driver registration that both an of_device_id
table and a spi_device_id table are present and that they contain the same
entries for all the SPI devices.
Not setting the .id_table member in the driver then confuses the core and
leads to the following warning when the ssd130x-spi driver is registered:
[ 41.091198] SPI driver ssd130x-spi has no spi_device_id for sinowealth,sh1106
[ 41.098614] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1305
[ 41.105862] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1306
[ 41.113062] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1307
[ 41.120247] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1309
[ 41.127449] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1322
[ 41.134627] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1325
[ 41.141784] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1327
[ 41.149021] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1331
To prevent the warning, set the .id_table even though it's not necessary.
Since the check is done even for built-in drivers, drop the condition to
only define the ID table when the driver is built as a module. Finally,
rename the variable to use the "_spi_id" convention used for ID tables.
Jessica Zhang [Tue, 17 Dec 2024 00:43:12 +0000 (16:43 -0800)]
drm: add clone mode check for CRTC
Add a common helper to check if the given CRTC state is in clone mode.
This can be used by drivers to help detect if a CRTC is being shared by
multiple encoders
Abhinav Kumar [Wed, 11 Dec 2024 21:18:42 +0000 (13:18 -0800)]
drm: allow encoder mode_set even when connectors change for crtc
In certain use-cases, a CRTC could switch between two encoders
and because the mode being programmed on the CRTC remains
the same during this switch, the CRTC's mode_changed remains false.
In such cases, the encoder's mode_set also gets skipped.
Skipping mode_set on the encoder for such cases could cause an issue
because even though the same CRTC mode was being used, the encoder
type could have changed like the CRTC could have switched from a
real time encoder to a writeback encoder OR vice-versa.
Allow encoder's mode_set to happen even when connectors changed on a
CRTC and not just when the mode changed.
Geert Uytterhoeven [Tue, 10 Dec 2024 14:18:46 +0000 (15:18 +0100)]
drm/bridge: ti-sn65dsi86: Fix multiple instances
Each bridge instance creates up to four auxiliary devices with different
names. However, their IDs are always zero, causing duplicate filename
errors when a system has multiple bridges:
Fix this by using a unique instance ID per bridge instance. The
instance ID is derived from the I2C adapter number and the bridge's I2C
address, to support multiple instances on the same bus.
Dmitry Baryshkov [Sun, 5 Jan 2025 23:00:14 +0000 (01:00 +0200)]
drm/nouveau: vendor in drm_encoder_slave API
Nouveau driver is the only user of the drm_encoder_slave API. Rework
necessary bits of drm_encoder_slave into the nouveau_i2c_encoder API and
drop drm_encoder_slave.c from the DRM KMS helper.
Dmitry Baryshkov [Sun, 5 Jan 2025 23:00:13 +0000 (01:00 +0200)]
drm/nouveau: incorporate I2C TV encoder drivers
Chrontel CH7006 and Silicon Image sil164 drivers use drm_encoder_slave
interface which is being used only by the nouveau driver. It doesn't
make sense to keep this interface inside the DRM subsystem. In
preparation to moving this set of helpers to the nouveau driver, move
the only two I2C driver that use that interface to the nouveau driver
too.
Dmitry Baryshkov [Sat, 14 Dec 2024 13:37:09 +0000 (15:37 +0200)]
drm/connector: make mode_valid take a const struct drm_display_mode
The mode_valid() callbacks of drm_encoder, drm_crtc and drm_bridge
take a const struct drm_display_mode argument. Change the mode_valid
callback of drm_connector to also take a const argument.
Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241214-drm-connector-mode-valid-const-v2-5-4f9498a4c822@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Dmitry Baryshkov [Sat, 14 Dec 2024 13:37:08 +0000 (15:37 +0200)]
drm/connector: make mode_valid_ctx take a const struct drm_display_mode
The mode_valid() callbacks of drm_encoder, drm_crtc and drm_bridge
take a const struct drm_display_mode argument. Change the mode_valid_ctx
callback of drm_connector to also take a const argument.
Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241214-drm-connector-mode-valid-const-v2-4-4f9498a4c822@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Dmitry Baryshkov [Sat, 14 Dec 2024 13:37:07 +0000 (15:37 +0200)]
drm/sti: hda: pass const struct drm_display_mode* to hda_get_mode_idx()
Make hda_get_mode_idx() take a const struct drm_display_mode pointer
instead of just raw struct drm_display_mode. This is a preparation to
converting the mode_valid() callback of drm_connector to take a const
struct drm_display_mode argument.
Acked-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241214-drm-connector-mode-valid-const-v2-3-4f9498a4c822@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Dmitry Baryshkov [Sat, 14 Dec 2024 13:37:06 +0000 (15:37 +0200)]
drm/amdgpu: don't change mode in amdgpu_dm_connector_mode_valid()
Make amdgpu_dm_connector_mode_valid() duplicate the mode during the
test rather than modifying the passed mode. This is a preparation to
converting the mode_valid() callback of drm_connector to take a const
struct drm_display_mode argument.
Dmitry Baryshkov [Sat, 14 Dec 2024 13:37:05 +0000 (15:37 +0200)]
drm/encoder_slave: make mode_valid accept const struct drm_display_mode
The mode_valid() callbacks of drm_encoder, drm_crtc and drm_bridge
accept const struct drm_display_mode argument. Change the mode_valid
callback of drm_encoder_slave to also accept const argument.
There are some control bits for IO and interrupts status scattered
across different GRF on differt SOC.
Add platform callback for this IO setting and interrupts status
handling.
Dmitry Baryshkov [Tue, 24 Dec 2024 01:48:02 +0000 (03:48 +0200)]
drm/vc4: hdmi: use drm_atomic_helper_connector_hdmi_hotplug()
Use the helper function to update the connector's information. This
makes sure that HDMI-related events are handled in a generic way.
Currently it is limited to the HDMI state reporting to the sound system.
Dmitry Baryshkov [Tue, 24 Dec 2024 01:48:01 +0000 (03:48 +0200)]
drm/vc4: hdmi: stop rereading EDID in get_modes()
The vc4_hdmi_connector_detect_ctx() via vc4_hdmi_handle_hotplug()
already reads EDID and propagates it to the drm_connector. Stop
rereading EDID as a part of the .get_modes() callback and just update
the list of modes. This matches the behaviour of the i915 driver.
Extend drm_bridge_connector code to read the EDID and use it to update
connector status if the bridge chain implements HDMI bridge. Performing
it from the generic location minimizes individual bridge's code and
enforces standard behaviour from all corresponding drivers.
Dmitry Baryshkov [Tue, 24 Dec 2024 01:47:58 +0000 (03:47 +0200)]
drm/display/hdmi: implement hotplug functions
The HDMI Connectors need to perform a variety of tasks when the HDMI
connector state changes. Such tasks include setting or invalidating CEC
address, notifying HDMI codec driver, updating scrambler data, etc.
Implementing such tasks in a driver-specific callbacks is error prone.
Start implementing the generic helper function (currently handling only
the HDMI Codec framework) to be used by drivers utilizing HDMI Connector
framework.
Dmitry Baryshkov [Tue, 24 Dec 2024 01:47:57 +0000 (03:47 +0200)]
drm/bridge: lt9611: switch to using the DRM HDMI codec framework
Make the Lontium LT9611 DSI-to-HDMI bridge driver use the DRM HDMI Codec
framework. This enables programming of Audio InfoFrames using the HDMI
Connector interface and also enables support for the missing features,
including the ELD retrieval and better hotplug support.
Dmitry Baryshkov [Tue, 24 Dec 2024 01:47:56 +0000 (03:47 +0200)]
drm/bridge: connector: add support for HDMI codec framework
Add necessary glue code to be able to use new HDMI codec framework from
the DRM bridge drivers. The drm_bridge implements a limited set of the
hdmi_codec_ops interface, with the functions accepting both
drm_connector and drm_bridge instead of just a generic void pointer.
This framework is integrated with the DRM HDMI Connector framework, but
can also be used for DisplayPort connectors.
Several DRM drivers implement HDMI codec support (despite its name it
applies to both HDMI and DisplayPort drivers). Implement generic
framework to be used by these drivers. This removes a requirement to
implement get_eld() callback and provides default implementation for
codec's plug handling.
Dmitry Baryshkov [Tue, 24 Dec 2024 01:47:54 +0000 (03:47 +0200)]
ASoC: hdmi-codec: move no_capture_mute to struct hdmi_codec_pdata
The no_capture_mute flag might differ from platform to platform,
especially in the case of the wrapping implementations, like the
upcoming DRM HDMI Codec framework. Move the flag next to all other flags
in struct hdmi_codec_pdata.
Dmitry Baryshkov [Tue, 24 Dec 2024 01:47:53 +0000 (03:47 +0200)]
ASoC: hdmi-codec: pass data to get_dai_id too
The upcoming DRM connector HDMI codec implementation is going to use
codec-specific data in the .get_dai_id to get drm_connector. Pass data
to the callback, as it is done with other hdmi_codec_ops callbacks.
Lizhi Hou [Thu, 2 Jan 2025 21:22:39 +0000 (13:22 -0800)]
accel/amdxdna: Declare mailbox register base as __iomem pointer
Declare mailbox ringbuf_base and mbox_base as 'void __iomem *' to fix
sparse warnings:
cast removes address space '__iomem' of expression
incorrect type in argument 2 (different address spaces)
Fixes: b87f920b9344 ("accel/amdxdna: Support hardware mailbox") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202412310857.syD1sXXO-lkp@intel.com/ Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250102212244.1586340-2-lizhi.hou@amd.com
Lizhi Hou [Thu, 2 Jan 2025 21:22:38 +0000 (13:22 -0800)]
accel/amdxdna: Declare npu device profile as static variables
Declare the variables as static to fix the sparse warnings:
symbol 'npu5_dev_priv' was not declared. Should it be static?
symbol 'npu1_dev_priv' was not declared. Should it be static?
symbol 'npu4_dev_priv' was not declared. Should it be static?
symbol 'npu2_dev_priv' was not declared. Should it be static?
Fixes: 8c9ff1b181ba ("accel/amdxdna: Add a new driver for AMD AI Engine") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202412310648.dtMHgGem-lkp@intel.com/ Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250102212244.1586340-1-lizhi.hou@amd.com
Hermes Wu [Mon, 30 Dec 2024 10:51:28 +0000 (18:51 +0800)]
drm/bridge: it6505: add I2C functionality on AUX
DisplayPort AUX protocol supports I2C transport which is capable of
reading EDID or supports MCCS.
In drm_dp_helper, drm_dp_i2c_xfer() packs I2C requests into a
sequence of AUX requests.
it6505_aux_i2c_operation() is implemented to match drm_dp_i2c_xfer()
operactions.
it6505_aux_i2c_transfer() adds I2C functionality
for it6505_aux_transfer().
Hermes Wu [Mon, 30 Dec 2024 10:51:27 +0000 (18:51 +0800)]
drm/bridge: it6505: fix HDCP CTS KSV list wait timer
HDCP must disabled encryption and restart authentication after
waiting KSV for 5s.
The original method uses a counter in a waitting loop that may
wait much longer than it is supposed to.
Use time_after() for KSV wait timeout.
Hermes Wu [Mon, 30 Dec 2024 10:51:25 +0000 (18:51 +0800)]
drm/bridge: it6505: fix HDCP CTS KSV list read with UNIGRAF DPR-100.
When running the HDCP CTS test with UNIGRAF DPR-100.
KSV list must be read from DP_AUX_HDCP_KSV_FIFO in an AUX request,
and can not separate with multiple read requests.
The AUX operation command "CMD_AUX_GET_KSV_LIST" reads the KSV list
with AUX FIFO and is able to read DP_AUX_HDCP_KSV_FIFO in an AUX request.
Add it6505_get_ksvlist() which uses CMD_AUX_GET_KSV_LIST operation
to read the KSV list.
Hermes Wu [Mon, 30 Dec 2024 10:51:21 +0000 (18:51 +0800)]
drm/bridge: it6505: add AUX operation for HDCP KSV list read
HDCP KSV list readback can choose to use AUX FIFO or
general data register.
For some DisplayPort devices, the KSV list must be read
in 5 byte boundaries.
The original AUX read command does not support these devices.
The AUX command operation control register "REG_AUX_CMD_REQ" uses b[3:0]
as AUX operacion control, and b[7:4] are status bits and read only.
To change KSV read operation uses "CMD_AUX_NATIVE_READ" from using
the data registers to using AUX FIFO.
The extended command "CMD_AUX_GET_KSV_LIST" is added as
"CMD_AUX_NATIVE_READ" with the 0x10 flag which selects AUX FIFO mode.
Hermes Wu [Mon, 30 Dec 2024 10:51:20 +0000 (18:51 +0800)]
drm/bridge: it6505: improve AUX operation for edid read
The original AUX operation using data registers is limited to 4 bytes.
The AUX operation command CMD_AUX_I2C_EDID_READ uses AUX FIFO and
is capable of reading 16 bytes.
This improves the speed of EDID read.
Baihan Li [Fri, 3 Jan 2025 09:38:24 +0000 (17:38 +0800)]
drm/hisilicon/hibmc: add dp module in hibmc
To support DP interface displaying in hibmc driver. Add
a encoder and connector for DP modual. The HPD function
and get_edid function will be add in next series, so temporarily
using 1024x768 as default in hibmc_dp_connector_get_modes()
Dmitry Baryshkov [Tue, 10 Dec 2024 14:16:50 +0000 (16:16 +0200)]
drm/bridge: dw-hdmi-qp: drop atomic_check() callback
As drm_bridge_connector now provides atomic_check() implementation which
calls drm_atomic_helper_connector_hdmi_check(), drop the duplicating
callback from the bridge driver.
Dmitry Baryshkov [Tue, 10 Dec 2024 14:16:49 +0000 (16:16 +0200)]
drm/bridge: lontium-lt9611: drop atomic_check() callback
As drm_bridge_connector now provides atomic_check() implementation which
calls drm_atomic_helper_connector_hdmi_check(), drop the duplicating
callback from the bridge driver.
Dmitry Baryshkov [Tue, 10 Dec 2024 14:16:48 +0000 (16:16 +0200)]
drm/bridge: ite-it6263: drop atomic_check() callback
As drm_bridge_connector now provides atomic_check() implementation which
calls drm_atomic_helper_connector_hdmi_check(), drop the duplicating
callback from the bridge driver.
Dmitry Baryshkov [Tue, 10 Dec 2024 14:16:47 +0000 (16:16 +0200)]
drm/display: bridge_connector: provide atomic_check for HDMI bridges
The bridges using HDMI connector framework have a call to
drm_atomic_helper_connector_hdmi_check() in their atomic_check()
callback. In order to reduce boilerplate and make simplify bridge's
code, use drm_atomic_helper_connector_hdmi_check() to implement
drm_connector.atomic_check() for HDMI bridges.
Linus Walleij [Thu, 19 Dec 2024 18:36:05 +0000 (19:36 +0100)]
MAINTAINERS: Assume maintainership of PL111
Emma Anholt dropped maintainership for PL111 and I
didn't notice it at the time. I've written part of it
and I'm happy to maintain it, list myself as maintainer
and assume active maintainership.
projects / users / jedix / linux-maple.git / log