Thomas Zimmermann [Tue, 24 Sep 2024 07:12:01 +0000 (09:12 +0200)]
drm/fbdev: Add memory-agnostic fbdev client
Add an fbdev client that can work with any memory manager. The
client implementation is the same as existing code in fbdev-dma or
fbdev-shmem.
Provide struct drm_driver.fbdev_probe for the new client to allocate
the surface GEM buffer. The new callback replaces fb_probe of struct
drm_fb_helper_funcs, which does the same.
To use the new client, DRM drivers set fbdev_probe in their struct
drm_driver instance and call drm_fbdev_client_setup(). Probing and
creating the fbdev surface buffer is now independent from the other
operations in struct drm_fb_helper. For the pixel format, the fbdev
client either uses a specified format, the value in preferred_depth
or 32-bit RGB.
v2:
- test for struct drm_fb_helper.funcs for NULL (Sui)
- respect struct drm_mode_config.preferred_depth for default format
Thomas Zimmermann [Tue, 24 Sep 2024 07:12:00 +0000 (09:12 +0200)]
drm/fbdev-helper: Set and clear VGA switcheroo client from fb_info
Call vga_switcheroo_client_fb_set() with the PCI device from the
instance of struct fb_info. All fbdev clients now run these calls.
For non-PCI devices or drivers without vga-switcheroo, this does
nothing. For i915 and radeon, it allows these drivers to use a
common fbdev client.
The device is the same as the one stored in struct drm_client and
struct drm_fb_helper, so there is no difference in behavior. Some
NULL-pointer checks are being removed, where those pointers cannot
be NULL.
v4:
- clarify call semantics for drm_fb_helper_unregister_info() (Javier)
Thomas Zimmermann [Tue, 24 Sep 2024 07:11:59 +0000 (09:11 +0200)]
drm/fbdev-helper: Move color-mode lookup into 4CC format helper
The color mode as specified on the kernel command line gives the user's
preferred color depth and number of bits per pixel. Move the
color-mode-to-format conversion from fbdev helpers into a 4CC helper,
so that it can be shared among DRM clients.
Jon Hunter [Wed, 25 Sep 2024 16:05:04 +0000 (17:05 +0100)]
gpu: host1x: Fix boot regression for Tegra
Commit 4c27ac45e622 ("gpu: host1x: Request syncpoint IRQs only during
probe") caused a boot regression for the Tegra186 device. Following this
update the function host1x_intr_init() now calls
host1x_hw_intr_disable_all_syncpt_intrs() during probe. However,
host1x_intr_init() is called before runtime power-management is enabled
for Host1x and the function host1x_hw_intr_disable_all_syncpt_intrs() is
accessing hardware registers. So if the Host1x hardware is not enabled
prior to probing then the device will now hang on attempting to access
the registers. So far this is only observed on Tegra186, but potentially
could be seen on other devices.
Fix this by moving the call to the function host1x_intr_init() in probe
to after enabling the runtime power-management in the probe and update
the failure path in probe as necessary.
In order to store device DMA parameters, the DMA framework depends on
the device's dma_parms field to point at a valid memory location. Add
backing storage for this in struct host1x_memory_context and point to
it.
Add a new V3D parameter to expose the support of Super Pages to
userspace. The userspace might want to know this information to
apply optimizations that are specific to kernels with Super Pages
enabled.
drm/v3d: Add modparam for turning off Big/Super Pages
Add a modparam for turning off Big/Super Pages to make sure that if an
user doesn't want Big/Super Pages enabled, it can disabled it by setting
the modparam to false.
drm/v3d: Use gemfs/THP in BO creation if available
Although Big/Super Pages could appear naturally, it would be quite hard
to have 1MB or 64KB allocated contiguously naturally. Therefore, we can
force the creation of large pages allocated contiguously by using a
mountpoint with "huge=within_size" enabled.
Therefore, as V3D has a mountpoint with "huge=within_size" (if user has
THP enabled), use this mountpoint for BO creation if available. This
will allow us to create large pages allocated contiguously and make use
of Big/Super Pages.
drm/v3d: Support Big/Super Pages when writing out PTEs
The V3D MMU also supports 64KB and 1MB pages, called big and super pages,
respectively. In order to set a 64KB page or 1MB page in the MMU, we need
to make sure that page table entries for all 4KB pages within a big/super
page must be correctly configured.
In order to create a big/super page, we need a contiguous memory region.
That's why we use a separate mountpoint with THP enabled. In order to
place the page table entries in the MMU, we iterate over the 16 4KB pages
(for big pages) or 256 4KB pages (for super pages) and insert the PTE.
drm/v3d: Reduce the alignment of the node allocation
Currently, we are using an alignment of 128 kB to insert a node, which
ends up wasting memory as we perform plenty of small BOs allocations
(<= 4 kB). We require that allocations are aligned to 128Kb so for any
allocation smaller than that, we are wasting the difference.
This implies that we cannot effectively use the whole 4 GB address space
available for the GPU in the RPi 4. Currently, we can allocate up to
32000 BOs of 4 kB (~140 MB) and 3000 BOs of 400 kB (~1,3 GB). This can be
quite limiting for applications that have a high memory requirement, such
as vkoverhead [1].
By reducing the page alignment to 4 kB, we can allocate up to 1000000 BOs
of 4 kB (~4 GB) and 10000 BOs of 400 kB (~4 GB). Moreover, by performing
benchmarks, we were able to attest that reducing the page alignment to
4 kB can provide a general performance improvement in OpenGL
applications (e.g. glmark2).
Therefore, this patch reduces the alignment of the node allocation to 4
kB, which will allow RPi users to explore the whole 4GB virtual
address space provided by the hardware. Also, this patch allow users to
fully run vkoverhead in the RPi 4/5, solving the issue reported in [1].
drm/gem: Create shmem GEM object in a given mountpoint
Create a function `drm_gem_shmem_create_with_mnt()`, similar to
`drm_gem_shmem_create()`, that has a mountpoint as a argument. This
function will create a shmem GEM object in a given tmpfs mountpoint.
This function will be useful for drivers that have a special mountpoint
with flags enabled.
Create a separate "tmpfs" kernel mount for V3D. This will allow us to
move away from the shmemfs `shm_mnt` and gives the flexibility to do
things like set our own mount options. Here, the interest is to use
"huge=", which should allow us to enable the use of THP for our
shmem-backed objects.
drm/gem: Create a drm_gem_object_init_with_mnt() function
For some applications, such as applications that uses huge pages, we might
want to have a different mountpoint, for which we pass mount flags that
better match our usecase.
Therefore, create a new function `drm_gem_object_init_with_mnt()` that
allow us to define the tmpfs mountpoint where the GEM object will be
created. If this parameter is NULL, then we fallback to `shmem_file_setup()`.
drm/v3d: Fix return if scheduler initialization fails
If the scheduler initialization fails, GEM initialization must fail as
well. Therefore, if `v3d_sched_init()` fails, free the DMA memory
allocated and return the error value in `v3d_gem_init()`.
We must first flush the MMU cache and then, flush the TLB, not the other
way around. Currently, we can see a race condition between the MMU cache
and the TLB when running multiple rendering processes at the same time.
This is evidenced by MMU errors triggered by the IRQ.
Fix the MMU flush order by flushing the MMU cache and then the TLB.
Also, in order to address the race condition, wait for the MMU cache flush
to finish before starting the TLB flush.
Louis Chauvet [Thu, 12 Sep 2024 15:25:33 +0000 (17:25 +0200)]
drm/vkms: Suppress context imbalance detected by sparse warning
The functions `vkms_crtc_atomic_begin` and `vkms_crtc_atomic_flush` are
responsible for locking and unlocking a mutex, respectively. Add the
`__acquires` and `__releases` annotations to these functions to prevent
the associated sparse warning about context imbalance.
Louis Chauvet [Thu, 5 Sep 2024 13:27:06 +0000 (15:27 +0200)]
drm/vkms: Add documentation
Add documentation around vkms_output and its initialization.
Add some documentation on pixel conversion functions.
Update of outdated comments for pixel_write functions.
Louis Chauvet [Tue, 10 Sep 2024 15:10:45 +0000 (17:10 +0200)]
MAINTAINERS: Add myself as VKMS Maintainer
I've been actively working on VKMS to provide new features and
participated in reviews and testing. To help Maìra with her work, add
myself as co-maintainer of VKMS.
I haven't been able to follow or review the work on the driver for a
long time and I don't see the situation improving anytime soon. Hence,
this commit removes me from the maintainers list.
drm/sched: Add locking to drm_sched_entity_modify_sched
Without the locking amdgpu currently can race between
amdgpu_ctx_set_entity_priority() (via drm_sched_entity_modify_sched()) and
drm_sched_job_arm(), leading to the latter accesing potentially
inconsitent entity->sched_list and entity->num_sched_list pair.
v2:
* Improve commit message. (Philipp)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: b37aced31eb0 ("drm/scheduler: implement a function to modify sched list") Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Luben Tuikov <ltuikov89@gmail.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: Philipp Stanner <pstanner@redhat.com> Cc: <stable@vger.kernel.org> # v5.7+ Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240924101914.2713-2-tursulin@igalia.com Signed-off-by: Christian König <christian.koenig@amd.com>
Thomas Zimmermann [Thu, 19 Sep 2024 18:53:43 +0000 (20:53 +0200)]
drm: Link drm_rect.o into DRM core module
Several places in drm.ko use struct drm_rect and its helpers. This
only works as the called interfaces are declared as static inline in
the header file. Fix the issue by linking drm_rect.o into drm.ko.
Tommy Chiang [Fri, 19 Jan 2024 03:31:26 +0000 (03:31 +0000)]
dma-buf: Add syntax highlighting to code listings in the document
This patch tries to improve the display of the code listing
on The Linux Kernel documentation website for dma-buf [1] .
Originally, it appears that it was attempting to escape
the '*' character, but looks like it's not necessary (now),
so we are seeing something like '\*' on the webite.
This patch removes these unnecessary backslashes and adds syntax
highlighting to improve the readability of the code listing.
The commit introducing the Frida display started to write the
SETVCMOFF registers unconditionally, and some (not all!) Hydis
display seem to be affected by ghosting after the commit.
Make SETVCMOFF optional and only send these commands on the
Frida display for now.
Reported-by: Stefan Hansson <newbyte@postmarketos.org> Fixes: 219a1f49094f ("drm/panel: nt35510: support FRIDA FRD400B25025-A-CTK") Acked-by: Jessica Zhang <quic_jesszhan@quicinc.com> Tested-by: Stefan Hansson <newbyte@postmarketos.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240908-fix-nt35510-v2-1-d4834b9cdb9b@linaro.org
drm: panel-orientation-quirks: Add quirk for AYA NEO GEEK
Add quirk orientation for AYA NEO GEEK. The name appears without
spaces in DMI strings. The board name is completely different to
the previous models making it difficult to reuse their quirks
despite being the same resolution and using the same orientation.
Tested by the JELOS team that has been patching their own kernel for a
while now and confirmed by users in the AYA NEO and ChimeraOS discord
servers.
drm: panel-orientation-quirks: Add quirk for AYA NEO Founder edition
Add quirk orientation for AYA NEO Founder. The name appears with spaces in
DMI strings as other devices of the brand. The panel is the same as the
NEXT and 2021 models. Those could not be reused as the former has VENDOR
name as "AYANEO" without spaces and the latter has "AYADEVICE".
Tested by the JELOS team that has been patching their own kernel for a
while now and confirmed by users in the AYA NEO and ChimeraOS discord
servers.
drm: panel-orientation-quirks: Add quirk for AYA NEO 2 model
Add quirk orientation for AYA NEO 2. The name appears without spaces in
DMI strings. That made it difficult to reuse the 2021 match. Also the
display is larger in resolution.
Tested by the JELOS team that has been patching their own kernel for a
while now and confirmed by users in the AYA NEO and ChimeraOS discord
servers.
drm/imx/ipuv3: Use IRQF_NO_AUTOEN flag in request_irq()
disable_irq() after request_irq() still has a time gap in which
interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
disable IRQ auto-enable when request IRQ.
Fixes: 47b1be5c0f4e ("staging: imx/drm: request irq only after adding the crtc") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240912083020.3720233-4-ruanjinjie@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
drm/imx/dcss: Use IRQF_NO_AUTOEN flag in request_irq()
disable_irq() after request_irq() still has a time gap in which
interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
disable IRQ auto-enable when request IRQ.
Fixes: 9021c317b770 ("drm/imx: Add initial support for DCSS on iMX8MQ") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240912083020.3720233-3-ruanjinjie@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
drm/imx/dcss: Use IRQF_NO_AUTOEN flag in request_irq()
disable_irq() after request_irq() still has a time gap in which
interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
disable IRQ auto-enable when request IRQ.
Huan Yang [Wed, 18 Sep 2024 02:52:30 +0000 (10:52 +0800)]
udmabuf: reuse folio array when pin folios
When invoke memfd_pin_folios, we need offer an array to save each folio
which we pinned.
The current way is dynamic alloc an array(use kvmalloc), get folios,
save into udmabuf and then free.
Depend on the size, kvmalloc can do something different:
Below PAGE_SIZE, slab allocator will be used, which have good alloc
performance, due to it cached page.
PAGE_SIZE - PCP Order, PCP(per-cpu-pageset) also given buddy page a
cache in each CPU, so different CPU no need to hold some lock(zone or
some) to get the locally page. If PCP cached page, the access also fast.
PAGE_SIZE - BUDDY_MAX, try to get page from buddy, due to kvmalloc adjusted
the gfp flags, if zone freelist can't alloc page(fast path), we will not
enter slowpath to reclaim memory. Due to need hold lock and check, may
slow, but still fast than vmalloc.
Anything wrong will fallback into vmalloc to alloc memory, it obtains
contiguous virtual addresses by loop alloc order 0 page(PAGE_SIZE), and
then map it into vmalloc area. If necessary, page alloc may enter
slowpath to reclaim memory. Hence, if fallback into vmalloc, it's slow.
When create, we need to iter each udmabuf item, then pin it's range
folios, if each item's range folio's count is large, we may fallback each
into vmalloc.
This patch find the largest range folio in items, then alloc this size's
folio array. When pin range folios, reuse this array.
Huan Yang [Wed, 18 Sep 2024 02:52:29 +0000 (10:52 +0800)]
udmabuf: remove udmabuf_folio
Currently, udmabuf handles folio by create an unpin list to record
each folio obtained from the list and unpinning them when released. To
maintain this, many struct have been established.
However, maintain this requires a significant amount of memory and
iter the list is a substantial overhead, which is not friendly to the
CPU cache.
When create, we arranged the folio array in the order of pin and set
the offset according to pgcnt. So, if record each pinned folio when
create, then can easy unpin it. Compare to use list to record it,
an array also can do this.
Hence, this patch setup a pinned_folios array(size is the pgcnt) to
instead of udmabuf_folio struct, it record each folio which pinned when
invoke memfd_pin_folios, then unpin folio by iter pinned_folios.
Note that, since a folio may be pinned multiple times, each folio can be
added to pinned_folios multiple times, depend on how many times the
folio has been pinned when create.
Compare to udmabuf_folio(24 byte size), a folio pointer is 8 byte, if no
large folio - each folio is PAGE_SIZE - and need to unpin when release.
So need to record each folio, by this patch, each folio can save 16 byte.
But if large folio used, depend on the large folio's number, the
pinned_folios array may take more memory, but it still can makes unpin
access more cache-friendly.
Huan Yang [Wed, 18 Sep 2024 02:52:28 +0000 (10:52 +0800)]
udmabuf: introduce udmabuf init and deinit helper
After udmabuf is allocated, its resources need to be initialized,
including various array structures. The current array structure has
already been greatly expanded.
Also, before udmabuf needs to be kfree, the occupied resources need to
be released.
This part is repetitive and maybe overlooked.
This patch give a helper function when init and deinit, by this,
reduce duplicate code.
Because MAX_PAGE_ORDER, kmalloc can max alloc 4096 * (1 << 10), 4MB
memory, each array entry is pointer(8byte), so can save 524288 pages(2GB).
Further more, costly order(order 3) may not be guaranteed that it can be
applied for, due to fragmentation.
This patch change udmabuf array use kvmalloc_array, this can fallback
alloc into vmalloc, which can guarantee allocation for any size and does
not affect the performance of kmalloc allocations.
Huan Yang [Wed, 18 Sep 2024 02:52:24 +0000 (10:52 +0800)]
udmabuf: pre-fault when first page fault
The current udmabuf mmap only fills the physical memory to the
corresponding virtual address when the user actually accesses the
virtual address.
However, the current udmabuf has already obtained and pinned the folio
upon completion of the creation.This means that the physical memory has
already been acquired, rather than being accessed dynamically.
As a result, the page fault has lost its purpose as a demanding
page. Due to the fact that page fault requires trapping into kernel mode
and filling in when accessing the corresponding virtual address in mmap,
when creating a large size udmabuf, this represents a considerable
overhead.
This patch fill the pfn into page table, and then pre-fault each pfn
into vma, when first access.
Notice, if anything wrong , we do not return an error during this
pre-fault step. However, an error will be returned if the failure occurs
when the addr is truly accessed
Vivek Kasireddy [Thu, 22 Aug 2024 04:58:06 +0000 (21:58 -0700)]
MAINTAINERS: udmabuf: Add myself as co-maintainer for udmabuf driver
I would like to help maintain the udmabuf driver, in light of the
recent changes that converted the driver to use folios instead
of pages. Furthermore, I also contribute to Qemu's virtio-gpu
module (and UI modules), that are primary users of udmabuf driver.
The driver might here use a utility that is annotated as intended for the
dma-fence signalling critical path. Now if the upper layer isn't correctly
annotated yet for whatever reason, resulting in
We will receive a false lockdep locking order violation notification from
dma_fence_begin_signalling(). However entering a dma-fence signalling
critical section itself doesn't block and could not cause a deadlock.
So use a successful read_trylock() annotation instead for
dma_fence_begin_signalling(). That will make sure that the locking order
is correctly registered in the first case, and doesn't register any
locking order in the second case.
The alternative is of course to make sure that the "Upper layer" is always
correctly annotated. But experience shows that's not easily achievable
in all cases.
Douglas Anderson [Sun, 8 Sep 2024 14:55:02 +0000 (14:55 +0000)]
drm/rockchip: dw_hdmi: Use auto-generated tables
The previous tables for mpll_cfg and curr_ctrl were created using the
20-pages of example settings provided by the PHY vendor. Those
example settings weren't particularly dense, so there were places
where we were guessing what the settings would be for 10-bit and
12-bit (not that we use those anyway). It was also always a lot of
extra work every time we wanted to add a new clock rate since we had
to cross-reference several tables.
In <https://crrev.com/c/285855> I've gone through the work to figure
out how to generate this table automatically. Let's now use the
automatically generated table and then we'll never need to look at it
again.
We only support 8-bit mode right now and only support a small number
of clock rates and I've verified that the only 8-bit rate that was
affected was 148.5. That mode appears to have been wrong in the old
table.
Douglas Anderson [Sun, 8 Sep 2024 14:55:01 +0000 (14:55 +0000)]
drm/rockchip: dw_hdmi: Set cur_ctr to 0 always
Jitter was improved by lowering the MPLL bandwidth to account for high
frequency noise in the rk3288 PLL. In each case MPLL bandwidth was
lowered only enough to get us a comfortable margin. We believe that
lowering the bandwidth like this is safe given sufficient testing.
1. We decided to reduce voltage value to lower, but VSwing still
keep high, RF/EMI have been improved but still failed.
ck: lvl = 6, term=100, vlo = 2.61, vhi=3.11, vswing = 0.50
tx: lvl = 6, term=100, vlo = 2.61, vhi=3.11, vswing = 0.50
2. We try to keep voltage value and vswing both lower, then RF/EMI
test all passed ;)
ck: lvl = 11, term= 66, vlo = 2.68, vhi=3.09, vswing = 0.40
tx: lvl = 11, term= 66, vlo = 2.68, vhi=3.09, vswing = 0.40
When we back to run HDMI different test and single-end test, we see
different test passed, but signle-end test failed. The oscilloscope
show that simgle-end clock's VL value is 1.78v (which remind LowLimit
should not lower then 2.6v).
3. That's to say there are some different between PHY document and
measure value. And according to experiment 2 results, we need to
higher clock voltage and lower data voltage, then we can keep RF/EMI
satisfied and single-end & differen test passed.
ck: lvl = 9, term=100, vlo = 2.65, vhi=3.12, vswing = 0.47
tx: lvl = 16, term=100, vlo = 2.75, vhi=3.15, vswing = 0.39
Thomas Zimmermann [Mon, 16 Sep 2024 08:25:15 +0000 (10:25 +0200)]
drm/ast: Warn about unsupported TX chips
A number of TX chips are listed in VGACRD1, but not supported by
the ast driver. Whether any existing product uses such a chip is
unknown. Warn if the driver encounters any. We can then add
support as necessary.
Lyude Paul [Mon, 16 Sep 2024 23:00:08 +0000 (19:00 -0400)]
drm/panic: Fix uninitialized spinlock acquisition with CONFIG_DRM_PANIC=n
It turns out that if you happen to have a kernel config where
CONFIG_DRM_PANIC is disabled and spinlock debugging is enabled, along with
KMS being enabled - we'll end up trying to acquire an uninitialized
spin_lock with drm_panic_lock() when we try to do a commit:
Tomi Valkeinen [Tue, 6 Aug 2024 13:50:29 +0000 (16:50 +0300)]
drm/omap: Fix locking in omap_gem_new_dmabuf()
omap_gem_new_dmabuf() creates the new gem object, and then takes and
holds the omap_obj->lock for the rest of the function. This has two
issues:
- omap_gem_free_object(), which is called in the error paths, also takes
the same lock, leading to deadlock
- Even if the above wouldn't happen, in the error cases
omap_gem_new_dmabuf() still unlocks omap_obj->lock, even after the
omap_obj has already been freed.
Furthermore, I don't think there's any reason to take the lock at all,
as the object was just created and not yet shared with anyone else.
To fix all this, drop taking the lock.
Fixes: 3cbd0c587b12 ("drm/omap: gem: Replace struct_mutex usage with omap_obj private lock") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/511b99d7-aade-4f92-bd3e-63163a13d617@stanley.mountain/ Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240806-omapdrm-misc-fixes-v1-3-15d31aea0831@ideasonboard.com
Tomi Valkeinen [Tue, 6 Aug 2024 13:50:28 +0000 (16:50 +0300)]
drm/omap: Hide sparse warnings
sparse reports:
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:122:16: warning: incorrect type in argument 1 (different address spaces)
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:122:16: expected void const volatile [noderef] __iomem *addr
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:122:16: got unsigned int [usertype] *wa_dma_data
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:130:9: warning: incorrect type in argument 2 (different address spaces)
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:130:9: expected void volatile [noderef] __iomem *addr
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:130:9: got unsigned int [usertype] *wa_dma_data
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:414:9: warning: incorrect type in argument 1 (different address spaces)
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:414:9: expected void const volatile [noderef] __iomem *addr
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:414:9: got unsigned int *
These come from pieces of code which do essentially:
p = dma_alloc_coherent()
dma_transfer_to_p()
readl(p)
writel(x, p)
dma_transfer_from_p()
I think we would do just fine without readl() and writel(), accessing
the memory without any extras, but ensuring that the necessary barriers
are in place. But this code is for a legacy platform, has been working
for ages, and it's doing work-arounds for hardware issues, and those
hardware issues are very difficult to trigger... So I would just rather
leave the code be as it is now.
However, the warnings are not nice. Hide the warnings by a (__iomem void
*) typecast.
Tomi Valkeinen [Tue, 6 Aug 2024 13:50:27 +0000 (16:50 +0300)]
drm/omap: Fix possible NULL dereference
smatch reports:
drivers/gpu/drm/omapdrm/dss/base.c:176 omapdss_device_disconnect() error: we previously assumed 'src' could be null (see line 169)
This code is mostly from a time when omapdrm had its own display device
model. I can't honestly remember the details, and I don't think it's
worth digging in deeply into that for a legacy driver.
However, it looks like we only call omapdss_device_disconnect() and
omapdss_device_connect() with NULL as the src parameter. We can thus
drop the src parameter from both functions, and fix the smatch warning.
I don't think omapdss_device_disconnect() ever gets NULL for the dst
parameter (if it did, we'd crash soon after returning from the
function), but I have kept the !dst check, just in case, but I added a
WARN_ON() there.
Also, if the dst parameter can be NULL, we can't always get the struct
dss_device pointer from dst->dss (which is only used for a debug print).
To make sure we can't hit that issue, do it similarly to the
omapdss_device_connect() function: add 'struct dss_device *dss' as the
first parameter, so that we always have it regardless of the dst.
Thomas Zimmermann [Wed, 11 Sep 2024 11:51:28 +0000 (13:51 +0200)]
drm/ast: Avoid upcasting to struct ast_device
Several functions receive an instance of struct drm_device only to
upcast it to struct ast_device. Improve type safety by passing the
AST device directly.
Thomas Zimmermann [Wed, 11 Sep 2024 11:51:26 +0000 (13:51 +0200)]
drm/ast: vga: Inline ast_vga_connector_init()
Inline ast_vga_connector_init() into its only caller. The helper
currently only does half of the connector-init work and is trivial
enough to be inlined. While at it, remove the error message from the
call to ast_ddc_create(). The function already warns on errors.
Also set the local variables for encoder and connector as late as
possible, so that the compiler warns if we use them before having
initialized the instance.
Inline ast_sil164_connector_init() into its only caller. The helper
currently only does half of the connector-init work and is trivial
enough to be inlined. While at it, remove the error message from the
call to ast_ddc_create(). The function already warns on errors.
Also set the local variables for encoder and connector as late as
possible, so that the compiler warns if we use them before having
initialized the instance.
Thomas Zimmermann [Wed, 11 Sep 2024 11:51:24 +0000 (13:51 +0200)]
drm/ast: dp501: Avoid upcasting to struct ast_device
Several functions receive an instance of struct drm_device only to
upcast it to struct ast_device. Improve type safety by passing the
AST device directly.
Thomas Zimmermann [Wed, 11 Sep 2024 11:51:23 +0000 (13:51 +0200)]
drm/ast: dp501: Inline ast_dp501_connector_init()
Inline ast_dp501_connector_init() into its only caller. The helper
currently only does half of the connector-init work and is trivial
enough to be inlined.
Also set the local variables for encoder and connector as late as
possible, so that the compiler warns if we use them before having
initialized the instance.
Thomas Zimmermann [Wed, 11 Sep 2024 11:51:22 +0000 (13:51 +0200)]
drm/ast: astdp: Replace ast_dp_set_on_off()
Replace ast_dp_set_on_off() with ast_dp_set_enable(). The helper's
new name reflects the performed operation. If enabling fails, the
new helper prints a warning. The code that waits for the programmed
effect to take place is now located in __ast_dp_wait_enable().
Also align the register constants with the rest of the code.
Thomas Zimmermann [Wed, 11 Sep 2024 11:51:21 +0000 (13:51 +0200)]
drm/ast: astdp: Replace power_on helpers
Replace the helper for controlling power on the physical connector,
ast_dp_power_on_off(), with ast_dp_set_phy_sleep(). The new name
reflects the effect of the operation. Simplify the implementation.
The call now controls sleeping, hence semantics are inversed. Each
'on' becomes an 'off' operation and vice versa.
Do the same for ast_dp_power_is_on() and also align naming of the
register constant with the rest of the code.
Thomas Zimmermann [Wed, 11 Sep 2024 11:51:20 +0000 (13:51 +0200)]
drm/ast: astdp: Avoid upcasting to struct ast_device
Several functions receive an instance of struct drm_device only to
upcast it to struct ast_device. Improve type safety by passing the
AST device directly.
Thomas Zimmermann [Wed, 11 Sep 2024 11:51:19 +0000 (13:51 +0200)]
drm/ast: astdp: Inline ast_astdp_connector_init()
Inline ast_astdp_connector_init() into its only caller. The helper
currently only does half of the connector-init work and is trivial
enough to be inlined.
Also set the local variables for encoder and connector as late as
possible, so that the compiler warns if we use them before having
initialized the instance.
Jani Nikula [Tue, 10 Sep 2024 10:03:39 +0000 (13:03 +0300)]
drm/kmb: annotate set_test_mode_src_osc_freq_target_{low, hi}_bits() with __maybe_unused
Building with clang and and W=1 leads to warning about unused
set_test_mode_src_osc_freq_target_low_bits() and
set_test_mode_src_osc_freq_target_hi_bits(). Fix by annotating them with
__maybe_unused.
See also commit 6863f5643dd7 ("kbuild: allow Clang to find unused static
inline functions for W=1 build").
drm/panel: khadas-ts050: make ts050[v2]_panel_data static
make ts050_panel_data and ts050v2_panel_data static because they
are only used in drivers/gpu/drm/panel/panel-khadas-ts050.c,
and fix the following sparse warnings:
drivers/gpu/drm/panel/panel-khadas-ts050.c:620:32:
sparse: warning: symbol 'ts050_panel_data' was not declared. Should it be static?
drivers/gpu/drm/panel/panel-khadas-ts050.c:625:32:
sparse: warning: symbol 'ts050v2_panel_data' was not declared. Should it be static?
drm/bridge: imx8mp-hdmi-tx: allow 0.5% margin with selected clock
This allows the hdmi driver to pick e.g. 64.8MHz instead of 65Mhz when we
cannot output the exact frequency, enabling the imx8mp HDMI output to
support more modes
Fabio Estevam [Wed, 26 Jun 2024 23:07:04 +0000 (20:07 -0300)]
drm/bridge: imx8qxp-ldb: Switch to RUNTIME_PM_OPS()
Replace SET_RUNTIME_PM_OPS with its modern RUNTIME_PM_OPS() alternative.
The combined usage of pm_ptr() and RUNTIME_PM_OPS()
allows the compiler to evaluate if the runtime suspend/resume() functions
are used at build time or are simply dead code.
This allows removing the __maybe_unused notation from the runtime
suspend/resume() functions.
Fabio Estevam [Wed, 26 Jun 2024 23:07:03 +0000 (20:07 -0300)]
drm/bridge: dw-hdmi-cec: Switch to SYSTEM_SLEEP_PM_OPS()
Replace SET_SYSTEM_SLEEP_PM_OPS with its modern SYSTEM_SLEEP_PM_OPS()
alternative.
The combined usage of pm_ptr() and SYSTEM_SLEEP_PM_OPS()
allows the compiler to evaluate if the runtime suspend/resume() functions
are used at build time or are simply dead code.
This allows removing the __maybe_unused notation from the runtime
suspend/resume() functions.
Fabio Estevam [Wed, 26 Jun 2024 23:07:02 +0000 (20:07 -0300)]
drm/bridge: samsung-dsim: Switch to RUNTIME_PM_OPS()
Replace SET_RUNTIME_PM_OPS with its modern RUNTIME_PM_OPS() alternative.
The combined usage of pm_ptr() and RUNTIME_PM_OPS()
allows the compiler to evaluate if the runtime suspend/resume() functions
are used at build time or are simply dead code.
This allows removing the __maybe_unused notation from the runtime
suspend/resume() functions.
Fabio Estevam [Wed, 26 Jun 2024 23:07:01 +0000 (20:07 -0300)]
drm/bridge: imx8qxp-pixel-combiner: Switch to RUNTIME_PM_OPS()
Replace SET_RUNTIME_PM_OPS with its modern RUNTIME_PM_OPS() alternative.
The combined usage of pm_ptr() and RUNTIME_PM_OPS()
allows the compiler to evaluate if the runtime suspend/resume() functions
are used at build time or are simply dead code.
This allows removing the __maybe_unused notation from the runtime
suspend/resume() functions.
Fabio Estevam [Wed, 26 Jun 2024 23:07:00 +0000 (20:07 -0300)]
drm/bridge: imx8qm-ldb: Switch to RUNTIME_PM_OPS()
Replace SET_RUNTIME_PM_OPS with its modern RUNTIME_PM_OPS() alternative.
The combined usage of pm_ptr() and RUNTIME_PM_OPS()
allows the compiler to evaluate if the runtime suspend/resume() functions
are used at build time or are simply dead code.
This allows removing the __maybe_unused notation from the runtime
suspend/resume() functions.
Fabio Estevam [Wed, 26 Jun 2024 23:06:59 +0000 (20:06 -0300)]
drm/bridge: imx8mp-hdmi-tx: Switch to SYSTEM_SLEEP_PM_OPS()
Replace SET_SYSTEM_SLEEP_PM_OPS with its modern SYSTEM_SLEEP_PM_OPS()
alternative.
The combined usage of pm_ptr() and SYSTEM_SLEEP_PM_OPS()
allows the compiler to evaluate if the runtime suspend/resume() functions
are used at build time or are simply dead code.
This allows removing the __maybe_unused notation from the runtime
suspend/resume() functions.
Alexander Stein [Wed, 4 Sep 2024 12:05:45 +0000 (14:05 +0200)]
drm/bridge: tc358767: Support write-only registers
Most registers are read-writable, but some are only RO or even WO.
regmap does not support using readable_reg and wr_table when outputting
in debugfs, so switch to writeable_reg.
First check for RO or WO registers and fallback tc_readable_reg() for the
leftover RW registers.
Alexander Stein [Wed, 4 Sep 2024 12:05:44 +0000 (14:05 +0200)]
drm/bridge: tc358767: Only print GPIO debug output if they actually occur
Currently the output the following output is printed upon each interrupt:
tc358767 1-000f: GPIO0:
This spams the kernel log while debugging an IRQ storm from the bridge.
Only print the debug output if the GPIO hotplug event actually happened.
Alexander Stein [Wed, 4 Sep 2024 12:05:43 +0000 (14:05 +0200)]
drm/bridge: tc358767: Use dev_err_probe
The function calls preceding these returns can return -EPROBE_DEFER. So
use dev_err_probe to add some information to
/sys/kernel/debug/devices_deferred
Yan Zhao [Mon, 9 Sep 2024 13:16:43 +0000 (21:16 +0800)]
drm/bochs: use devm_ioremap_wc() to map framebuffer
Opt for devm_ioremap_wc() over devm_ioremap() when mapping the framebuffer.
Using devm_ioremap() results in the VA being mapped with PAT=UC-, which
considerably slows down drm_fb_memcpy(). In contrast, devm_ioremap_wc()
maps the VA with PAT set to WC, leading to better performance on platforms
where access to UC memory is much slower than WC memory.
Here's the performance data measured in a guest on the physical machine
"Sapphire Rapids XCC".
With host KVM honors guest PAT memory types, the effective memory type
for this framebuffer range is
- WC when devm_ioremap_wc() is used
- UC- when devm_ioremap() is used.
The data presented is an average from 10 execution runs.
Cycles: Avg cycles of executed bochs_primary_plane_helper_atomic_update()
from VM boot to GDM show up
Cnt: Avg cnt of executed bochs_primary_plane_helper_atomic_update()
from VM boot to GDM show up
T: Avg time of each bochs_primary_plane_helper_atomic_update().
Note:
Following the rebase to [3], the previously reported GDM failure on the
VGA device [1] can no longer be reproduced, thanks to the memory management
improvements made in [2]. Despite this, I have proceeded to submit this
patch because of the noticeable performance improvements it provides.
Steven Price [Fri, 6 Sep 2024 09:40:25 +0000 (10:40 +0100)]
drm/panthor: Display FW version information
The version number output when loading the firmware is actually the
interface version not the version of the firmware itself. Update the
message to make this clearer.
However, the firmware binary has a git SHA embedded into it which can be
used to identify which firmware binary is being loaded. So output this
as a drm_info() so that it's obvious from a dmesg log which firmware
binary is being used.
projects / users / jedix / linux-maple.git / log