| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In this function, there are two refcount leak bugs:
(1) when breaking out of for_each_endpoint_of_node(), we need call
the of_node_put() for the 'ep';
(2) we should call of_node_put() for the reference returned by
of_graph_get_remote_port() when it is not used anymore.
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: Liang He <[email protected]>
Acked-by: Martin Blumenstingl <[email protected]>
Acked-by: Neil Armstrong <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Appears to be ok with general GA10x code.
Signed-off-by: Karol Herbst <[email protected]>
Cc: <[email protected]> # v5.15+
Reviewed-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This check determines whether a given address is part of
image 0 or image 1. Image 1 starts at offset image0_size,
so that address should be included.
Fixes: 4d4e9907ff572 ("drm/nouveau/bios: guard against out-of-bounds accesses to image")
Signed-off-by: Timur Tabi <[email protected]>
Reviewed-by: Karol Herbst <[email protected]>
Signed-off-by: Karol Herbst <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
When DCSS + MIPI_DSI is used, and the last bridge in the chain supports
HPD, we can see a "Hot plug detection already enabled" warning stack
trace dump that's thrown when DCSS is initialized.
The problem appeared when HPD was enabled by default in the
bridge_connector initialization, which made the
drm_bridge_connector_enable_hpd() call, in DCSS init path, redundant.
So, let's remove that call.
Fixes: 09077bc311658 ("drm/bridge_connector: enable HPD by default if supported")
Signed-off-by: Laurentiu Palcu <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Users may request that pages from an OpenCL SVM allocation be migrated
to the GPU with clEnqueueSVMMigrateMem(). In Nouveau this will call into
nouveau_dmem_migrate_vma() to do the migration. If the total range to be
migrated exceeds SG_MAX_SINGLE_ALLOC the pages will be migrated in
chunks of size SG_MAX_SINGLE_ALLOC. However a typo in updating the
starting address means that only the first chunk will get migrated.
Fix the calculation so that the entire range will get migrated if
possible.
Signed-off-by: Alistair Popple <[email protected]>
Fixes: e3d8b0890469 ("drm/nouveau/svm: map pages after migration")
Reviewed-by: Ralph Campbell <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Cc: <[email protected]> # v5.8+
|
|
When booting a kernel compiled with clang's CFI protection
(CONFIG_CFI_CLANG), there is a CFI failure in
drm_simple_kms_crtc_mode_valid() when trying to call
simpledrm_simple_display_pipe_mode_valid() through ->mode_valid():
[ 0.322802] CFI failure (target: simpledrm_simple_display_pipe_mode_valid+0x0/0x8):
...
[ 0.324928] Call trace:
[ 0.324969] __ubsan_handle_cfi_check_fail+0x58/0x60
[ 0.325053] __cfi_check_fail+0x3c/0x44
[ 0.325120] __cfi_slowpath_diag+0x178/0x200
[ 0.325192] drm_simple_kms_crtc_mode_valid+0x58/0x80
[ 0.325279] __drm_helper_update_and_validate+0x31c/0x464
...
The ->mode_valid() member in 'struct drm_simple_display_pipe_funcs'
expects a return type of 'enum drm_mode_status', not 'int'. Correct it
to fix the CFI failure.
Cc: [email protected]
Fixes: 11e8f5fd223b ("drm: Add simpledrm driver")
Link: https://github.com/ClangBuiltLinux/linux/issues/1647
Reported-by: Tomasz Paweł Gajc <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Sami Tolvanen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
In dcss_dev_create() and dcss_dev_destroy(), we should call of_node_put()
in fail path or before the dcss's destroy as of_graph_get_port_by_id() has
increased the refcount.
Fixes: 9021c317b770 ("drm/imx: Add initial support for DCSS on iMX8MQ")
Signed-off-by: Liang He <[email protected]>
Reviewed-by: Laurentiu Palcu <[email protected]>
Signed-off-by: Laurentiu Palcu <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The value read from the "hpd-absent-delay-ms" property in DT was being
saved to the wrong variable, overriding the hpd_reliable delay. Fix the
typo.
Fixes: 5540cf8f3e8d ("drm/panel-edp: Implement generic "edp-panel"s probed by EDID")
Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
Reviewed-by: André Almeida <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Douglas Anderson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
I've stumbled over this while reviewing patches for DMA-buf and it looks
like we completely messed the locking up here.
In general most TTM function should only be called while holding the
appropriate BO resv lock. Without this we could break the internal
buffer object state here.
Only compile tested!
Signed-off-by: Christian König <[email protected]>
Fixes: 43676605f890 ("drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers")
Cc: [email protected]
Reviewed-by: Dmitry Osipenko <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Interrupt context can't sleep. Drivers like Panfrost and MSM are taking
mutex when job is released, and thus, that code can sleep. This results
into "BUG: scheduling while atomic" if locks are contented while job is
freed. There is no good reason for releasing scheduler's jobs in IRQ
context, hence use normal context to fix the trouble.
Cc: [email protected]
Fixes: 542cff7893a3 ("drm/sched: Avoid lockdep spalt on killing a processes")
Signed-off-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Andrey Grodzovsky <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This reverts commit c9cad937c0c58618fe5b0310fd539a854dc1ae95.
This is part of a revert of the following commits:
commit 708d19d9f362 ("drm/amdgpu: move internal vram_mgr function into the C file")
commit 5e3f1e7729ec ("drm/amdgpu: fix start calculation in amdgpu_vram_mgr_new")
commit c9cad937c0c5 ("drm/amdgpu: add drm buddy support to amdgpu")
[WHY]
Few users reported garbaged graphics as soon as x starts,
reverting until this can be resolved.
Signed-off-by: Arunpravin Paneer Selvam <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Christian König <[email protected]>
Signed-off-by: Christian König <[email protected]>
|
|
Fix small typo which causes the mask for the 'precharge1' setting
to be used with the 'precharge2' value.
Signed-off-by: Ezequiel Garcia <[email protected]>
Acked-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Need get the new fence when we replace the old one.
Fixes: 047a1b877ed48 ("dma-buf & drm/amdgpu: remove dma_resv workaround")
Signed-off-by: xinhui pan <[email protected]>
Reviewed-by: Christian König <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Christian König <[email protected]>
|
|
Calling madvise IOCTL twice on BO causes memory shrinker list corruption
and crashes kernel because BO is already on the list and it's added to
the list again, while BO should be removed from the list before it's
re-added. Fix it.
Cc: [email protected]
Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support")
Acked-by: Alyssa Rosenzweig <[email protected]>
Reviewed-by: Steven Price <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Steven Price <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
panfrost_mmu_map_fault_addr() error
When panfrost_mmu_map_fault_addr() fails, the BO's mapping should be
unreferenced and not the shmem object which backs the mapping.
Cc: [email protected]
Fixes: bdefca2d8dc0 ("drm/panfrost: Add the panfrost_gem_mapping concept")
Reviewed-by: Steven Price <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Steven Price <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Since commit 1ea2a07a532b ("iommu: Add DMA ownership management
interfaces") the Rockchip display driver on the Firefly RK3288 fails to
initialise properly. This is because ARM DMA domain is still attached.
Let's follow the lead of exynos and tegra and add code to explicitly
remove the ARM domain before attaching a new one.
Fixes: 1ea2a07a532b ("iommu: Add DMA ownership management interfaces")
Suggested-by: Robin Murphy <[email protected]>
Signed-off-by: Steven Price <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
It's unnecessary to invert input data enable signal polarity
according to the output one. Let's drop the inversion.
Since ->atomic_check() does nothing more than the inversion,
it can be dropped entirely as well.
Without this patch, 'koe,tx26d202vm0bwa' LVDS panel connected
with i.MX8MP EVK board does not show any data on screen.
Fixes: 463db5c2ed4a ("drm: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridge")
Cc: Andrzej Hajda <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Robert Foss <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Jonas Karlman <[email protected]>
Cc: Jernej Skrabec <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Cc: Marek Vasut <[email protected]>
Cc: NXP Linux Team <[email protected]>
Signed-off-by: Liu Ying <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
When LVDS dual link is used, we have to enable the LDB_CTRL_SPLIT_MODE bit.
Fixes: 463db5c2ed4a ("drm: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridge")
Cc: Andrzej Hajda <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Robert Foss <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Jonas Karlman <[email protected]>
Cc: Jernej Skrabec <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Cc: Marek Vasut <[email protected]>
Cc: NXP Linux Team <[email protected]>
Signed-off-by: Liu Ying <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
With LVDS dual link, up to 160MHz mode clock rate is supported.
With LVDS single link, up to 80MHz mode clock rate is supported.
Fix mode clock rate validation by swapping the maximum mode clock
rates of the two link modes.
Fixes: 463db5c2ed4a ("drm: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridge")
Cc: Andrzej Hajda <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Robert Foss <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Jonas Karlman <[email protected]>
Cc: Jernej Skrabec <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Cc: Marek Vasut <[email protected]>
Cc: NXP Linux Team <[email protected]>
Signed-off-by: Liu Ying <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Always run fbdev removal first to remove simpledrm via
sysfb_disable(). This clears the internal state. The later call
to drm_aperture_detach_drivers() then does nothing. Otherwise,
with drm_aperture_detach_drivers() running first, the call to
sysfb_disable() uses inconsistent state.
Example backtrace show below:
[ 11.663422] ==================================================================
[ 11.663426] BUG: KASAN: use-after-free in device_del+0x79/0x5f0
[ 11.663435] Read of size 8 at addr ffff888108185050 by task systemd-udevd/311
[ 11.663440] CPU: 0 PID: 311 Comm: systemd-udevd Tainted: G E 5
.19.0-rc2-1-default+ #1689
[ 11.663445] Hardware name: HP ProLiant DL120 G7, BIOS J01 04/21/2011
[ 11.663447] Call Trace:
[ 11.663449] <TASK>
[ 11.663451] ? device_del+0x79/0x5f0
[ 11.663456] dump_stack_lvl+0x5b/0x73
[ 11.663462] print_address_description.constprop.0+0x1f/0x1b0
[ 11.663468] ? device_del+0x79/0x5f0
[ 11.663471] ? device_del+0x79/0x5f0
[ 11.663475] print_report.cold+0x3c/0x21c
[ 11.663481] ? lock_acquired+0x87/0x1e0
[ 11.663484] ? lock_acquired+0x87/0x1e0
[ 11.663489] ? device_del+0x79/0x5f0
[ 11.663492] kasan_report+0xbf/0xf0
[ 11.663498] ? device_del+0x79/0x5f0
[ 11.663503] device_del+0x79/0x5f0
[ 11.663509] ? device_remove_attrs+0x170/0x170
[ 11.663514] ? lock_is_held_type+0xe8/0x140
[ 11.663523] platform_device_del.part.0+0x19/0xe0
[ 11.663530] platform_device_unregister+0x1c/0x30
[ 11.663535] sysfb_disable+0x2d/0x70
[ 11.663540] remove_conflicting_framebuffers+0x1c/0xf0
[ 11.663546] remove_conflicting_pci_framebuffers+0x130/0x1a0
[ 11.663554] drm_aperture_remove_conflicting_pci_framebuffers+0x86/0xb0
[ 11.663561] ? mgag200_pci_remove+0x30/0x30 [mgag200]
[ 11.663578] mgag200_pci_probe+0x2d/0x140 [mgag200]
Reported-by: Zack Rusin <[email protected]>
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Zack Rusin <[email protected]>
Fixes: ee7a69aa38d8 ("fbdev: Disable sysfb device registration when removing conflicting FBs")
Cc: Javier Martinez Canillas <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: Alex Deucher <[email protected]>
Cc: Zhen Lei <[email protected]>
Cc: Changcheng Deng <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit fb84efa28a48e30b87fa1122e8aab8016c7347cd)
Signed-off-by: Thomas Zimmermann <[email protected]>
|
|
The Lenovo Yoga Tablet 2 830F / 830L use a panel which has been mounted
90 degrees rotated. Add a quirk for this.
Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The platform devices registered by sysfb match with firmware-based DRM or
fbdev drivers, that are used to have early graphics using a framebuffer
provided by the system firmware.
DRM or fbdev drivers later are probed and remove conflicting framebuffers,
leading to these platform devices for generic drivers to be unregistered.
But the current solution has a race, since the sysfb_init() function could
be called after a DRM or fbdev driver is probed and request to unregister
the devices for drivers with conflicting framebuffes.
To prevent this, disable any future sysfb platform device registration by
calling sysfb_disable(), if a driver requests to remove the conflicting
framebuffers.
Suggested-by: Daniel Vetter <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This can be used by subsystems to unregister a platform device registered
by sysfb and also to disable future platform device registration in sysfb.
Suggested-by: Daniel Vetter <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This function just returned 0 on success or an errno code on error, but it
could be useful for sysfb_init() callers to have a pointer to the device.
Signed-off-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Reviewed-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Commit 30f8c74ca9b7 ("drm/vc4: Warn if some v3d code is run on BCM2711")
introduced a check in vc4_perfmon_get() that dereferences a pointer before
we checked whether that pointer is valid or not.
Let's rework that function a bit to do things in the proper order.
Reported-by: kernel test robot <[email protected]>
Reported-by: Dan Carpenter <[email protected]>
Fixes: 30f8c74ca9b7 ("drm/vc4: Warn if some v3d code is run on BCM2711")
Signed-off-by: Maxime Ripard <[email protected]>
Reviewed-by: José Expósito <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Added return statement in sun4i_layer_format_mod_supported()
in case frontend is not present.
Signed-off-by: Saud Farooqui <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/PA4P189MB1421E93EF5F8E8E00E71B7878BB29@PA4P189MB1421.EURP189.PROD.OUTLOOK.COM
|
|
The vc4_check_tex_size() function is supposed to return false on error
but this error path accidentally returns -ENODEV (which means true).
Fixes: 30f8c74ca9b7 ("drm/vc4: Warn if some v3d code is run on BCM2711")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/YrMKK89/viQiaiAg@kili
|
|
Kernel occasionally complains that there is mismatch in segment size
when trying to render HW decoded videos and rendering them directly with
sun4i DRM driver. Following message can be observed on H6 SoC:
[ 184.298308] ------------[ cut here ]------------
[ 184.298326] DMA-API: sun4i-drm display-engine: mapping sg segment longer than device claims to support [len=6144000] [max=65536]
[ 184.298364] WARNING: CPU: 1 PID: 382 at kernel/dma/debug.c:1162 debug_dma_map_sg+0x2b0/0x350
[ 184.322997] CPU: 1 PID: 382 Comm: ffmpeg Not tainted 5.19.0-rc1+ #1331
[ 184.329533] Hardware name: Tanix TX6 (DT)
[ 184.333544] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 184.340512] pc : debug_dma_map_sg+0x2b0/0x350
[ 184.344882] lr : debug_dma_map_sg+0x2b0/0x350
[ 184.349250] sp : ffff800009f33a50
[ 184.352567] x29: ffff800009f33a50 x28: 0000000000010000 x27: ffff000001b86c00
[ 184.359725] x26: ffffffffffffffff x25: ffff000005d8cc80 x24: 0000000000000000
[ 184.366879] x23: ffff80000939ab18 x22: 0000000000000001 x21: 0000000000000001
[ 184.374031] x20: 0000000000000000 x19: ffff0000018a7410 x18: ffffffffffffffff
[ 184.381186] x17: 0000000000000000 x16: 0000000000000000 x15: ffffffffffffffff
[ 184.388338] x14: 0000000000000001 x13: ffff800009534e86 x12: 6f70707573206f74
[ 184.395493] x11: 20736d69616c6320 x10: 000000000000000a x9 : 0000000000010000
[ 184.402647] x8 : ffff8000093b6d40 x7 : ffff800009f33850 x6 : 000000000000000c
[ 184.409800] x5 : ffff0000bf997940 x4 : 0000000000000000 x3 : 0000000000000027
[ 184.416953] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000003960e80
[ 184.424106] Call trace:
[ 184.426556] debug_dma_map_sg+0x2b0/0x350
[ 184.430580] __dma_map_sg_attrs+0xa0/0x110
[ 184.434687] dma_map_sgtable+0x28/0x4c
[ 184.438447] vb2_dc_dmabuf_ops_map+0x60/0xcc
[ 184.442729] __map_dma_buf+0x2c/0xd4
[ 184.446321] dma_buf_map_attachment+0xa0/0x130
[ 184.450777] drm_gem_prime_import_dev+0x7c/0x18c
[ 184.455410] drm_gem_prime_fd_to_handle+0x1b8/0x214
[ 184.460300] drm_prime_fd_to_handle_ioctl+0x2c/0x40
[ 184.465190] drm_ioctl_kernel+0xc4/0x174
[ 184.469123] drm_ioctl+0x204/0x420
[ 184.472534] __arm64_sys_ioctl+0xac/0xf0
[ 184.476474] invoke_syscall+0x48/0x114
[ 184.480240] el0_svc_common.constprop.0+0x44/0xec
[ 184.484956] do_el0_svc+0x2c/0xc0
[ 184.488283] el0_svc+0x2c/0x84
[ 184.491354] el0t_64_sync_handler+0x11c/0x150
[ 184.495723] el0t_64_sync+0x18c/0x190
[ 184.499397] ---[ end trace 0000000000000000 ]---
Fix that by setting DMA mask and segment size.
Signed-off-by: Jernej Skrabec <[email protected]>
Reviewed-by: Samuel Holland <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Multiplying ints and saving it in unsigned long long
could lead to integer overflow before being type casted to
unsigned long long.
Addresses-Coverity: 1505113: Unintentional integer overflow.
Signed-off-by: Saud Farooqui <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/PA4P189MB1421E63C0FF3EBF234A80AB38BA79@PA4P189MB1421.EURP189.PROD.OUTLOOK.COM
|
|
The device is identified by "NEXT" in board name, however there are
different versions of it, "Next Advance" and "Next Pro", that have
different DMI board names.
Due to a production error a batch or two have their board names prefixed
by "AYANEO", this makes it 6 different DMI board names. To save some
space in final kernel image DMI_MATCH is used instead of
DMI_EXACT_MATCH.
Signed-off-by: Maya Matuszczyk <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The BCM2711 has a separate driver for the v3d, and thus we can't call
into any of the driver entrypoints that rely on the v3d being there.
Let's add a bunch of checks and complain loudly if that ever happen.
Reviewed-by: Melissa Wen <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
When doing an asynchronous page flip (PAGE_FLIP ioctl with the
DRM_MODE_PAGE_FLIP_ASYNC flag set), the current code waits for the
possible GPU buffer being rendered through a call to
vc4_queue_seqno_cb().
On the BCM2835-37, the GPU driver is part of the vc4 driver and that
function is defined in vc4_gem.c to wait for the buffer to be rendered,
and once it's done, call a callback.
However, on the BCM2711 used on the RaspberryPi4, the GPU driver is
separate (v3d) and that function won't do anything. This was working
because we were going into a path, due to uninitialized variables, that
was always scheduling the callback.
However, we were never actually waiting for the buffer to be rendered
which was resulting in frames being displayed out of order.
The generic API to signal those kind of completion in the kernel are the
DMA fences, and fortunately the v3d drivers supports them and signal
when its job is done. That API also provides an equivalent function that
allows to have a callback being executed when the fence is signalled as
done.
Let's change our driver a bit to rely on the previous function for the
older SoCs, and on DMA fences for the BCM2711.
Signed-off-by: Maxime Ripard <[email protected]>
Reviewed-by: Melissa Wen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The BCM2711 doesn't have a v3d GPU so we don't want to call into its BO
management code. Let's create an asynchronous page-flip handler for the
BCM2711 that just calls into the common code.
Reviewed-by: Melissa Wen <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The function vc4_async_page_flip() handles asynchronous page-flips in
the vc4 driver.
However, it mixes some generic code with code that should only be run on
older generations that have the GPU handled by the vc4 driver.
Let's split the generic part out of vc4_async_page_flip() and into a
common function that we be reusable by an handler made for the BCM2711.
Reviewed-by: Melissa Wen <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
We'll soon introduce another completion callback source that won't need
to use the BO reference counting, so let's move it around to create a
function we will be able to share between both callbacks.
Reviewed-by: Melissa Wen <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
We'll need to extend the vc4_async_flip_state structure to rely on
another callback implementation, so let's move the current one into a
union.
Reviewed-by: Melissa Wen <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
On the BCM2711, we currently call the vc4_bo_cache_init() and
vc4_gem_init() functions. These functions initialize the BO and GEM
backends.
However, this code was initially created to accomodate the requirements
of the GPU on the older SoCs, while the BCM2711 has a separate driver
for it. So let's just skip these calls when we're on a newer hardware.
Reviewed-by: Melissa Wen <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
On the BCM2711, our current definition of drm_plane_helper_funcs uses
the custom vc4_prepare_fb() and vc4_cleanup_fb().
Those functions rely on the buffer allocation path that was relying on
the GPU, and is no longer relevant.
Let's create another drm_plane_helper_funcs structure that we will
register on the BCM2711.
Reviewed-by: Melissa Wen <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
On the BCM2711, our current definition of drm_mode_config_funcs uses the
custom vc4_fb_create().
However, that function relies on the buffer allocation path that was
relying on the GPU, and is no longer relevant.
Let's create another drm_mode_config_funcs structure that we will
register on the BCM2711.
Reviewed-by: Melissa Wen <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Prior to the BCM2711/RaspberryPi4, the GPU was a part of the display
components of the SoC. It was thus a part of the vc4 driver.
However, with the BCM2711, it got split out and thus the v3d driver was
created. The vc4 driver now only handles the display part.
We didn't properly split out the code when doing the BCM2711 support
though, and most of the code around buffer allocations is still
involved, even though it doesn't have the backing hardware anymore.
Let's start the split out by creating a new drm_driver that only reports
and uses what we support on the BCM2711. The ioctl were properly
filtered already, but we were still exposing a .gem_create_object hook,
as well as having an .open and .postclose hooks which are only relevant
on older generations.
Reviewed-by: Melissa Wen <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The vc4_bo_dumb_create() both fixes up the allocation arguments to match
the hardware constraints and actually performs the allocation.
Since we're going to introduce a new function that uses a different
allocator, let's split the arguments fixup to a separate function we
will be able to reuse.
Reviewed-by: Melissa Wen <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
We're going to add a new variant of the dumb BO allocation function, so
let's rename vc4_dumb_create() to something a bit more specific.
Reviewed-by: Melissa Wen <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
A new generation of controller has been introduced with the
BCM2711/RaspberryPi4. This generation needs a bunch of quirks, and over
time we've piled on a number of checks in most parts of the drivers.
All these checks are performed several times, and are not always
consistent. Let's create a single, global, variable to hold it and use
it everywhere.
Reviewed-by: Melissa Wen <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The vc4 planes are setup in hardware by creating a hardware descriptor
in a dedicated RAM. As part of the process to setup a plane in KMS, we
thus need to allocate some part of that dedicated RAM to store our
descriptor there.
The async update path will just reuse the descriptor already allocated
for that plane and will modify it directly in RAM to match whatever has
been asked for.
In order to do that, it will compare the descriptor for the old plane
state and the new plane state, will make sure they fit in the same size,
and check that only the position or buffer address have changed.
Reviewed-by: Melissa Wen <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
If the component driver fails to bind, or is unbound, the driver data
for the top-level platform device points to a freed drm_device. If the
system is then suspended, the driver passes this dangling pointer to
drm_mode_config_helper_suspend(), which crashes.
Fix this by only setting the driver data while the platform driver holds
a reference to the drm_device.
Fixes: 624b4b48d9d8 ("drm: sun4i: Add support for suspending the display driver")
Signed-off-by: Samuel Holland <[email protected]>
Reviewed-by: Jernej Skrabec <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
commit 6de79dd3a920 ("drm/bridge: display-connector: add ddc-en gpio
support") added a consumer for this GPIO in the HDMI connector device.
This new consumer conflicts with the pre-existing GPIO consumer in the
sun8i HDMI controller driver, which prevents the driver from probing:
[ 4.983358] display-connector connector: GPIO lookup for consumer ddc-en
[ 4.983364] display-connector connector: using device tree for GPIO lookup
[ 4.983392] gpio-226 (ddc-en): gpiod_request: status -16
[ 4.983399] sun8i-dw-hdmi 6000000.hdmi: Couldn't get ddc-en gpio
[ 4.983618] sun4i-drm display-engine: failed to bind 6000000.hdmi (ops sun8i_dw_hdmi_ops [sun8i_drm_hdmi]): -16
[ 4.984082] sun4i-drm display-engine: Couldn't bind all pipelines components
[ 4.984171] sun4i-drm display-engine: adev bind failed: -16
[ 4.984179] sun8i-dw-hdmi: probe of 6000000.hdmi failed with error -16
Both drivers have the same behavior: they leave the GPIO active for the
life of the device. Let's take advantage of the new implementation, and
drop the now-obsolete code from the HDMI controller driver.
Fixes: 6de79dd3a920 ("drm/bridge: display-connector: add ddc-en gpio support")
Signed-off-by: Samuel Holland <[email protected]>
Reviewed-by: Jernej Skrabec <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The resource must be on the LRU before ttm_lru_bulk_move_add() is called
and we need to check if the BO is pinned or not before adding it.
Additional to that we missed taking the LRU spinlock in ttm_bo_unpin().
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Arunpravin Paneer Selvam <[email protected]>
Acked-by: Luben Tuikov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Fixes: fee2ede15542 ("drm/ttm: rework bulk move handling v5")
|
|
Resources about to be destructed are not tied to BOs any more.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Felix Kuehling <[email protected]>
Fixes: 6a9b02899402 ("drm/ttm: move the LRU into resource handling v4")
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Fix the `unused-but-set-variable` warning as how other iteration
wrappers do.
Link: https://lore.kernel.org/all/[email protected]/
Reported-by: kernel test robot <[email protected]>
Signed-off-by: GONG, Ruiqi <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Systems with AST graphics can have multiple output; typically VGA
plus some other port. Record detected output chips in a bitmask and
initialize each output on its own.
Assume a VGA output by default and use SIL164 and DP501 if available.
For ASTDP assume that it can run in parallel with VGA.
Tested on AST2100.
v3:
* define a macro for each BIT(ast_tx_chip) (Patrik)
v2:
* make VGA/SIL164/DP501 mutually exclusive
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Patrik Jakobsson <[email protected]>
Fixes: a59b026419f3 ("drm/ast: Initialize encoder and connector for VGA in helper function")
Cc: Thomas Zimmermann <[email protected]>
Cc: Javier Martinez Canillas <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: [email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 7f35680ada234ce00828b8ea841ba7ca1e00ff52)
Signed-off-by: Thomas Zimmermann <[email protected]>
|