StarFive Tech Linux Kernel for VisionFive (JH7110) boards (mirror) https://git.radix-linux.su/starfive-tech/linux.git/atom?h=visionfive 2025-10-09T14:57:13+00:00 2025-10-09T14:57:13+00:00 sw.multimedia sw.multimedia@starfivetech.com 2021-08-31T08:48:57+00:00 urn:sha1:3d923bef34427227fe12f403de6cdcb7ea65c83a A proper solution to this hack should be found. Signed-off-by: jack.zhu <jack.zhu@starfivetech.com> Signed-off-by: keith.zhao <keith.zhao@starfivetech.com> 2025-10-09T14:57:13+00:00 Andreas Schwab schwab@suse.de 2024-10-29T14:03:06+00:00 urn:sha1:802499181dec9abaf3cbf5308ffa95d3c11bdfa3 This fixes the error from drm_open: [ +0.000020] [ C1] WARNING: CPU: 1 PID: 1110 at drivers/gpu/drm/drm_file.c Signed-off-by: Andreas Schwab <schwab@suse.de> 2025-10-09T14:57:13+00:00 Emil Renner Berthing kernel@esmil.dk 2021-09-22T14:35:15+00:00 urn:sha1:a3806e816f60587ff8bb6160b93b75042ebce4bd When creating dumb buffers with 32bpp and 24bit colour depth this is default mode return by drm_mode_legacy_fb_format. So we need to support this for common dumb buffers to just work. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk> 2025-10-09T14:57:13+00:00 sw.multimedia sw.multimedia@starfivetech.com 2021-08-31T08:48:57+00:00 urn:sha1:c4ec020d1969261b0248f4040bdf149cd3edd920 Add starfive DRM Display driver framework Signed-off-by: jack.zhu <jack.zhu@starfivetech.com> Signed-off-by: keith.zhao <keith.zhao@starfivetech.com> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Signed-off-by: Emil Renner Berthing <kernel@esmil.dk> 2025-09-26T04:12:33+00:00 Dave Airlie airlied@redhat.com 2025-09-26T04:12:28+00:00 urn:sha1:ec73e5984e01bfdf92234eaf5a2c3e54aa67f2aa - Don't expose sysfs attributes not applicable for VFs (Michal) - Fix build with CONFIG_MODULES=n (Lucas) - Don't copy pinned kernel bos twice on suspend (Thomas) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/aNU-FkJEcA3T4aDB@intel.com 2025-09-26T04:05:40+00:00 Dave Airlie airlied@redhat.com 2025-09-26T04:05:01+00:00 urn:sha1:366a9295079731654bf0e0c6c5ac47b1f346b410 A CPU stall fix for ast, a NULL pointer dereference fix for gma500, an OOB and overflow fixes for fbcon, and a race condition fix for panthor. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://lore.kernel.org/r/20250925-smilodon-of-luxurious-genius-4ebee7@penduick 2025-09-26T03:56:22+00:00 Dave Airlie airlied@redhat.com 2025-09-26T03:56:21+00:00 urn:sha1:4d486a51772421b1c6e37e6bfec9b3c60af58dba - Set O_LARGEFILE in __create_shmem() (Taotao Chen) - Guard reg_val against a INVALID_TRANSCODER [ddi] (Suraj Kandpal) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Tvrtko Ursulin <tursulin@igalia.com> Link: https://lore.kernel.org/r/aNTxWfhsMkFZ3Q-a@linux 2025-09-25T08:52:03+00:00 Adrián Larumbe adrian.larumbe@collabora.com 2025-09-19T16:43:48+00:00 urn:sha1:7d9c3442b02ab7dd3c44e20095a178fd57d2eccb Commit de8548813824 ("drm/panthor: Add the scheduler logical block") handled destruction of a group's queues' drm scheduler entities early into the group destruction procedure. However, that races with the group submit ioctl, because by the time entities are destroyed (through the group destroy ioctl), the submission procedure might've already obtained a group handle, and therefore the ability to push jobs into entities. This is met with a DRM error message within the drm scheduler core as a situation that should never occur. Fix by deferring drm scheduler entity destruction to queue release time. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250919164436.531930-1-adrian.larumbe@collabora.com 2025-09-23T17:54:50+00:00 Melissa Wen mwen@igalia.com 2025-09-01T21:51:05+00:00 urn:sha1:41b1f9fcba62b06195e625bb88c1031102892439 Remove this flag as the driver stopped managing it individually since commit a4056c2a6344 ("drm/amd/display: use HW hdr mult for brightness boost"). After some back and forth it was reintroduced as a condition to `set_output_transfer_func()` in [1]. Without direct management, this flag only changes value when all surface update flags are set true on UPDATE_TYPE_FULL with no output TF status meaning. Fixes: bb622e0c0044 ("drm/amd/display: program output tf when required") [1] Signed-off-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 752e6f283ec59ae007aa15a93d5a4b2eefa8cec9) 2025-09-23T17:54:43+00:00 Leo Li sunpeng.li@amd.com 2025-09-12T15:01:50+00:00 urn:sha1:361ee85e980c16c9b9e236ccfac33014e8602485 [Why] We did not initialize dc clocks with boot-time hw values during init. This lead to incorrect clock values in dc, causing `dcn35_update_clocks` to make incorrect updates. [How] Correctly initialize DC with pre-os clk values from HW. s/dump/save/ as that accurately reflects the purpose of the functions. Fixes: 8774029f76b9 ("drm/amd/display: Add DCN35 CLK_MGR") Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit d43cc4ea1f9d720ab4bf06806f79260bfe981508)