Variable var->pixclock can be set by user. In case it equals to
zero, divide by zero would occur in acornfb_validate_timing.
Similar crashes have happened in other fbdev drivers. We fix this
by checking whether 'pixclock' is zero.
Similar commit: commit 16844e58704 ("video: fbdev: tridentfb:
Error
Variable var->pixclock can be set by user. In case it equals to
zero, divide by zero would occur in i810fb_fill_var_timings and
i810_get_watermark.
We cannot find the default valid value of pixclock for driver
i810, so we fix this by returning directly if 'pixclock' is
zero.
Similar commit: commit
Variable var->pixclock can be set by user. In case it equals to
zero, divide by zero would occur in 4 switch branches in
i740fb_decode_var.
Similar crashes have happened in other fbdev drivers. We fix this
by checking whether 'pixclock' is zero.
Similar commit: commit 16844e58704 ("video: fbdev: t
Variable var->pixclock can be set by user. In case it equals to
zero, divide by zero would occur in sm501fb_set_par_common.
Similar crashes have happened in other fbdev drivers.
We cannot find the default vaild value for pixclock for driver
sm501, so we fix this by checking whether 'pixclock' is ze
Variable var->pixclock can be set by user. In case it equals to
zero, divide by zero would occur in get_var_refresh.
Similar crashes have happened in other fbdev drivers. We fix this
by checking whether 'pixclock' is zero.
Similar commit: commit 16844e58704 ("video: fbdev: tridentfb:
Error out if
On 6/12/25 10:42 PM, Stephen Rothwell wrote:
> Hi all,
>
on i386, when:
# CONFIG_ACPI is not set
CONFIG_DRM_I915=y
CONFIG_BACKLIGHT_CLASS_DEVICE=m
drivers/gpu/drm/i915/display/intel_backlight.c:973:(.text+0x2613): undefined
reference to `backlight_device_get_by_name'
ld: drivers/gpu/drm/i915/
From: John Harrison
There is a sporadic failure to enable CTs ocurring in CI on one
specific machine that can't be reproduced locally. The driver already
supports dumping out a whole bunch of GuC related debug info on such a
failure but only when the verbose GuC debug config option is enabled.
It
From: John Harrison
There is a sporadic failure to enable CTs ocurring in CI on one
specific machine that can't be reproduced locally. The driver already
supports dumping out a whole bunch of GuC related debug info on such a
failure but only when the verbose GuC debug config option is enabled.
It
The pull request you sent on Sat, 14 Jun 2025 06:42:46 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2025-06-14
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/25294cb8a404e8116eecaf2f151ee2fd6c17fb9b
Thank you!
--
Deet-doot-dot, I am a bot.
h
Variable var->pixclock can be set by user. In case it equals to
zero, divide by zero would occur in viafb_fill_crtc_timing.
Similar crashes have happened in other fbdev drivers. We fix this
by checking whether 'pixclock' is zero.
Similar commit: commit 16844e58704 ("video: fbdev: tridentfb:
Error
Variable var->pixclock can be set by user. In case it equals to
zero, divide by zero would occur in tdfxfb_check_var. Similar
crashes have happened in other fbdev drivers. We fix this by
checking whether 'pixclock' is zero.
Signed-off-by: Alex Guo
---
drivers/video/fbdev/tdfxfb.c | 3 +++
1 file
Variable var->pixclock can be set by user. In case it equals to
zero, divide by zero would occur in viafb_dvi_set_mode. Similar
crashes have happened in other fbdev drivers. We fix this by
checking whether 'pixclock' is zero.
Signed-off-by: Alex Guo
---
drivers/video/fbdev/via/dvi.c | 2 +-
1 fi
Variable var->pixclock can be set by user. In case it equals to
zero, divide by zero would occur in sstfb_check_var. Similar
crashes have happened in other fbdev drivers. We fix this by
checking whether 'pixclock' is zero.
Signed-off-by: Alex Guo
---
drivers/video/fbdev/sstfb.c | 2 +-
1 file c
Variable var->pixclock can be set by user. In case it equals to
zero, divide by zero would occur in sstfb_check_var. Similar
crashes have happened in other fbdev drivers. We fix this by
checking whether 'pixclock' is zero.
Signed-off-by: Alex Guo
---
drivers/video/fbdev/sstfb.c | 2 +-
1 file c
On Fri, Jun 13, 2025 at 4:57 PM Rob Clark wrote:
>
> For UNMAP/REMAP steps we could be needing to lock objects that are not
> explicitly listed in the VM_BIND ioctl in order to tear-down unmapped
> VAs. These helpers handle locking/preparing the needed objects.
>
> Note that these functions do no
From: "Dr. David Alan Gilbert"
The last use of vmw_kms_sou_do_bo_dirty() was removed in 2018 by
commit 2f5544ff0300 ("drm/vmwgfx: Use atomic helper function for dirty fb
IOCTL")
Remove it, and its helpers.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 8 --
Correctly summerize drm_gpuvm_sm_map/unmap, and fix the parameter order
and names. Just something I noticed in passing.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gpuvm.c | 6 +++---
include/drm/drm_gpuvm.h | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/dri
First patch is just some cleanup. The second patch adds helpers for
drivers to deal with "invisible" unmapped BO locking. Ie. a VM_BIND
ioctl won't explicitly list BOs associated with unmapped/remapped VAs
making locking all the BOs involved in a VM_BIND ioclt harder than it
needs to be. The hel
For UNMAP/REMAP steps we could be needing to lock objects that are not
explicitly listed in the VM_BIND ioctl in order to tear-down unmapped
VAs. These helpers handle locking/preparing the needed objects.
Note that these functions do not strictly require the VM changes to be
applied before the ne
Hi Sunil,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-exynos/exynos-drm-next]
[also build test ERROR on linus/master drm/drm-next v6.16-rc1 next-20250613]
[cannot apply to drm-intel/for-linux-next drm-intel/for-linux-next-fixes
drm-misc/drm-misc-next drm
-Original Message-
From: Intel-xe On Behalf Of Matthew
Brost
Sent: Friday, June 13, 2025 2:20 PM
To: intel...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: d...@kernel.org; christian.koe...@amd.com; pstan...@redhat.com
Subject: [PATCH] drm/sched: Increment job count before sw
A small race exists between spsc_queue_push and the run-job worker, in
which spsc_queue_push may return not-first while the run-job worker has
already idled due to the job count being zero. If this race occurs, job
scheduling stops, leading to hangs while waiting on the job’s DMA
fences.
Seal this
Hi.
This patch series adds the DT bindings and tree entries for the GPU
present in Apple M-series SoCs. The driver itself is in Rust and
upstream is currently missing several prerequisite bindings, so will
be sent later.
The kernel and m1n1 (bootloader) that are using those bindings are
available
From: Sasha Finkelstein
Add device tree entries for GPUs in M-series SoCs
Reviewed-by: Alyssa Rosenzweig
Reviewed-by: Sven Peter
Signed-off-by: Sasha Finkelstein
---
arch/arm64/boot/dts/apple/t6000.dtsi| 4
arch/arm64/boot/dts/apple/t6001.dtsi| 4
arch/arm64/boot/
From: Sasha Finkelstein
Add bindings for the GPU present in Apple SoCs
Signed-off-by: Sasha Finkelstein
---
Documentation/devicetree/bindings/gpu/apple,agx.yaml | 94
++
MAINTAINERS
On Fri, Jun 13, 2025 at 2:44 PM André Almeida wrote:
>
> To notify userspace about which task (if any) made the device get in a
> wedge state, make use of drm_wedge_task_info parameter, filling it with
> the task PID and name.
>
> Signed-off-by: André Almeida
If you want the guilty state to be r
Hi Linus,
Quiet week, only two PRs came my way, xe has a couple of fixes and
then a bunch of fixes across the board, vc4 probably fixes the biggest
problem,
Regards,
Dave.
drm-fixes-2025-06-14:
drm fixes for 6.16-rc2
vc4:
- Fix infinite EPROBE_DEFER loop in vc4 probing.
amdxdna:
- Fix amdxdna
On 6/13/25 4:57 PM, Alexey Klimov wrote:
> On Fri Jun 13, 2025 at 3:41 PM BST, Rob Clark wrote:
>> We want to WARN_ON() if info is NULL.
>>
>> Suggested-by: Konrad Dybcio
>> Fixes: 0838fc3e6718 ("drm/msm/adreno: Check for recognized GPU before bind")
>> Tested-by: Neil Armstrong
>> Signed-off-by:
On Fri, Jun 13, 2025 at 07:26:22PM +0200, Christian König wrote:
> On 6/13/25 19:01, Matthew Brost wrote:
> > All,
> >
> > After about six hours of debugging, I found an issue in a fairly
> > aggressive test case involving the DRM scheduler function
> > drm_sched_entity_push_job. The problem is th
Fix the following compile time warning when building with W=1:
warning: EXPORT_SYMBOL() is not used, but #include is present
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 1 -
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 1 -
drivers/gpu/drm/amd/amdkfd/kfd_f
On 6/13/2025 9:58 AM, Melissa Wen wrote:
Since [1], we can use drm_edid_product_id to get debug info from
drm_edid instead of directly parsing EDID.
Link:
https://lore.kernel.org/dri-devel/cover.1712655867.git.jani.nik...@intel.com/
[1]
This is a pretty old commit. It's landed now a while,
On 6/13/2025 9:58 AM, Melissa Wen wrote:
Instead of using driver-specific code, use DRM helpers.
Signed-off-by: Melissa Wen
Reviewed-by: Mario Limonciello
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --g
On 6/13/2025 9:58 AM, Melissa Wen wrote:
drm_edid_connector_update() updates display info, filling ELD with audio
info from Short-Audio Descriptors in the last step of
update_dislay_info(). Our goal is stopping using raw edid, so we can
extract SAD from drm_eld instead of access raw edid to get a
On 6/13/2025 9:58 AM, Melissa Wen wrote:
drm_edid_connector_update() updates display info, filling ELD with
speaker allocation data in the last step of update_dislay_info(). Our
goal is stopping using raw edid, so we can extract SADB from drm_eld
instead of access raw edid to get audio caps.
Sig
On 6/13/2025 9:58 AM, Melissa Wen wrote:
From: Rodrigo Siqueira
Since DC is a shared code, this commit introduces a new file to work as
a mid-layer in DC for the edid manipulation.
v3:
- rebase on top of asdn
Can you put changelog below cutlist (---)?
Signed-off-by: Rodrigo Siqueira
Co-dev
To notify userspace about which task (if any) made the device get in a
wedge state, make use of drm_wedge_task_info parameter, filling it with
the task PID and name.
Signed-off-by: André Almeida
---
v7:
- Remove struct cast, now we can use `info = &ti->task`
- Fix struct lifetime, move amdgpu_v
Le 11/06/2025 à 22:24, Maíra Canal a écrit :
Hi Louis,
On 5/30/25 11:06, Louis Chauvet wrote:
Some YUV format uses 16 bit values, so change the helper function for
conversion to support those new formats.
Add support for the YUV format P010
Hum, I don't think this patch added support for
To avoid repetitive code in amdgpu, create a function that prints the
content of struct amdgpu_task_info.
Signed-off-by: André Almeida
---
v7: new patch
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 4 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 9 +
drivers/gpu/drm/amd/amdgpu/amdgpu_
To avoid a cast when calling drm_dev_wedged_event(), replace pid and
task name inside of struct amdgpu_task_info with struct
drm_wedge_task_info.
Signed-off-by: André Almeida
---
v7: New patch
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_dev_cor
Add a section about "Task information" for the wedge API.
Reviewed-by: Krzysztof Karas
Reviewed-by: Raag Jadav
Signed-off-by: André Almeida
---
v5:
- Change app to task in the text as well
v4:
- Change APP to TASK
v3:
- Change "app that caused ..." to "app involved ..."
- Clarify that devco
When a device get wedged, it might be caused by a guilty application.
For userspace, knowing which task was involved can be useful for some
situations, like for implementing a policy, logs or for giving a chance
for the compositor to let the user know what task was involved in the
problem. This is
This patchset implements a request made by Xaver Hugl about wedge events:
"I'd really like to have the PID of the client that triggered the GPU
reset, so that we can kill it if multiple resets are triggered in a
row (or switch to software rendering if it's KWin itself) and show a
user-friendly not
Hi Thomas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-xe/drm-xe-next]
[also build test WARNING on linus/master v6.16-rc1 next-20250613]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to
On 6/13/2025 9:58 AM, Melissa Wen wrote:
From: Rodrigo Siqueira
As part of the effort of stopping using raw edid, this commit move the
copy of the edid in DC to a dedicated function that will allow the usage
of drm_edid in the next steps.
v3:
- remove superfulous cast (jani)
I don't think th
On 6/13/2025 9:58 AM, Melissa Wen wrote:
AMD driver has a function used to compare if two edid are the same; this
is useful to some of the link detection algorithms implemented by
amdgpu. Since the amdgpu function can be helpful for other drivers, this
commit abstracts the AMD function to make it
On 6/13/2025 9:58 AM, Melissa Wen wrote:
Reduce direct handling of edid data by resorting to drm helpers that
deal with this info inside drm_edid infrastructure.
v3:
- use dc_edid_sink_edid_free in link_detection
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |
Fix the following compile time warning when building with W=1:
warning: EXPORT_SYMBOL() is used, but #include is missing
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 1 +
drivers/gpu/drm/amd/amdxcp/amdgpu_xcp_drv.c | 1 +
2 files changed, 2 insertions(+)
diff
Commit 7d95680d64ac ("scripts/misc-check: check unnecessary #include
when W=1") and commit a934a57a42f6 ("scripts/misc-check:
check missing #include when W=1") added new checks for when the
include is missued by drivers. This patchset make drm/amd code
compliant to this new commits.
See also:
This patch series adds support for CRIU checkpointing of processes that
share memory with the amdgpu dmabuf interface.
This v6 cleans up the locking and moves some of the mapping info code
into amdgpu_vm.c.
The mapping flags code is a placeholder awaiting the mapping flags
rework.
amdgpu CRIU requires an amdgpu CRIU ioctl. This ioctl
has a similar interface to the amdkfd CRIU ioctl.
The objects that can be checkpointed and restored are bos and vm
mappings. Because a single amdgpu bo can have multiple mappings.
the mappings are recorded separately.
The ioctl has two modes:
CRIU restore of drm buffer objects requires the ability to create
or import a buffer object with a specific gem handle.
Add new drm ioctl DRM_IOCTL_GEM_CHANGE_HANDLE, which takes
the gem handle of an object and moves that object to a
specified new gem handle.
This ioctl needs to call drm_prime_re
The kfd CRIU checkpoint ioctl would return an error if trying
to checkpoint a process with no kfd buffer objects.
This is a normal case and should not be an error.
Signed-off-by: David Francis
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
On 6/13/2025 12:42 PM, Melissa Wen wrote:
On 06/13, Mario Limonciello wrote:
On 6/13/2025 7:58 AM, Melissa Wen wrote:
Add Linux opaque object to dc_sink for storing edid data cross driver,
drm_edid. Also include the Linux call to free this object, the
drm_edid_free()
v3:
- remove uneccessary i
Hi Thomas,
Em 12/06/2025 09:09, Thomas Zimmermann escreveu:
Some source files in DRM do not include properly;
others do when they don't have to. The build scripts now warn about
these cases.
This series fixes DRM core and helpers. There are a few more warnings
in drivers.
Commit 7d95680d64ac
On Wed, Jun 11, 2025 at 12:23 PM Tamir Duberstein wrote:
>
> This series depends on "rust: retain pointer mut-ness in
> `container_of!`"[1].
Not anymore! :)
> Signed-off-by: Tamir Duberstein
Thanks for rebasing, Tamir, I appreciate it.
This has a bunch of hits in configfs, cpufreq and Nova [1
On Fri, 2025-06-13 at 09:34 -0500, Lucas De Marchi wrote:
> On Fri, Jun 13, 2025 at 03:14:24PM +0100, Tvrtko Ursulin wrote:
> >
> > On 13/06/2025 15:10, Lucas De Marchi wrote:
> > > On Fri, Jun 13, 2025 at 09:02:27AM +0100, Tvrtko Ursulin wrote:
> > > >
> > > > On 12/06/2025 19:53, Yiwei Zhang wr
On 06/13, Mario Limonciello wrote:
> On 6/13/2025 7:58 AM, Melissa Wen wrote:
> > Add Linux opaque object to dc_sink for storing edid data cross driver,
> > drm_edid. Also include the Linux call to free this object, the
> > drm_edid_free()
> >
> > v3:
> > - remove uneccessary include (jani)
> >
>
Le 11/06/2025 à 22:02, Maíra Canal a écrit :
Hi Louis,
On 5/30/25 11:05, Louis Chauvet wrote:
The format RGB565 was already supported. Add the support for:
- BGR565
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_formats.c | 23 +++
drivers/gpu/drm/vkms/
Le 11/06/2025 à 21:55, Maíra Canal a écrit :
Hi Louis,
On 5/30/25 11:05, Louis Chauvet wrote:
The formats XRGB and ARGB were already supported.
Add the support for:
- XBGR
- RGBX
- BGRX
- ABGR
- RGBA
- BGRA
Signed-off-by: Louis Chauvet
---
[...]
+READ_LI
On 6/13/25 19:01, Matthew Brost wrote:
> All,
>
> After about six hours of debugging, I found an issue in a fairly
> aggressive test case involving the DRM scheduler function
> drm_sched_entity_push_job. The problem is that spsc_queue_push does not
> correctly return first on a job push, causing t
On Wed, 11 Jun 2025 17:56:49 -0300, Maíra Canal wrote:
> The Kconfig option `CONFIG_DRM_VKMS_KUNIT_TESTS` does not exist. However,
> the VKMS format tests use such an option for compilation, meaning that
> they are not compiled at all.
>
> Use the Kconfig option `CONFIG_DRM_VKMS_KUNIT_TEST` to c
Danilo,
>
>
+// SAFETY: DRM GpuVmBo objects are always reference counted and the
get/put functions
+// satisfy the requirements.
+unsafe impl AlwaysRefCounted for GpuVmBo {
+fn inc_ref(&self) {
+// SAFETY: The drm_gpuvm_get function satisfies the requi
All,
After about six hours of debugging, I found an issue in a fairly
aggressive test case involving the DRM scheduler function
drm_sched_entity_push_job. The problem is that spsc_queue_push does not
correctly return first on a job push, causing the queue to fail to run
even though it is ready.
I
On 6/13/2025 7:58 AM, Melissa Wen wrote:
Add Linux opaque object to dc_sink for storing edid data cross driver,
drm_edid. Also include the Linux call to free this object, the
drm_edid_free()
v3:
- remove uneccessary include (jani)
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/am
On 6/11/25 4:08 AM, Bagas Sanjaya wrote:
GSP message queue docs has been moved following RPC handling split in
8a8b1ec5261f20 ("drm/nouveau/gsp: split rpc handling out on its own"),
before GSP-RM implementation is versioned in c472d828348caf
("drm/nouveau/gsp: move subdev/engine impls to subdev/g
Hi
Am 13.06.25 um 16:03 schrieb José Expósito:
On Thu, Jun 12, 2025 at 03:52:23PM +0200, Thomas Zimmermann wrote:
Only sysfb drivers use drm_fb_build_fourcc_list(). The helper will
be moved from format helpers to sysfb helpers. Moving the related
tests to their own test suite.
v2:
- rename fil
On 6/10/25 11:54 PM, Jacob Keller wrote:
The nouveau_get_backlight_name() function generates a unique name for the
backlight interface, appending an id from 1 to 99 for all backlight devices
after the first.
GCC 15 (and likely other compilers) produce the following
-Wformat-truncation warning:
On 5/27/25 6:37 PM, Zhi Wang wrote:
The RPC container is released after being passed to r535_gsp_rpc_send().
When sending the initial fragment of a large RPC and passing the
caller's RPC container, the container will be freed prematurely. Subsequent
attempts to send remaining fragments will t
On 5/22/25 3:15 PM, Colin Ian King wrote:
The left shift int 32 bit integer constants 1 is evaluated using 32 bit
arithmetic and then assigned to a 64 bit unsigned integer. In the case
where the shift is 32 or more this can lead to an overflow. Avoid this
by shifting using the BIT_ULL macro inste
From: Rodrigo Siqueira
Since DC is a shared code, this commit introduces a new file to work as
a mid-layer in DC for the edid manipulation.
v3:
- rebase on top of asdn
Signed-off-by: Rodrigo Siqueira
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_
Hi
Am 13.06.25 um 17:28 schrieb José Expósito:
Hi,
On Fri, Jun 13, 2025 at 02:33:36PM +0200, Thomas Zimmermann wrote:
Hi
Am 13.06.25 um 13:55 schrieb José Expósito:
Hi Thomas,
Thanks for the heads up, this issue fall through the cracks.
On Fri, Jun 13, 2025 at 10:15:05AM +0200, Thomas Zimm
Hi,
On Fri, Jun 13, 2025 at 02:33:36PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 13.06.25 um 13:55 schrieb José Expósito:
> > Hi Thomas,
> >
> > Thanks for the heads up, this issue fall through the cracks.
> >
> > On Fri, Jun 13, 2025 at 10:15:05AM +0200, Thomas Zimmermann wrote:
> > > Hi
> >
On Fri, Jun 13, 2025 at 11:16:10PM +0900, Alexandre Courbot wrote:
[...]
> >> +#[repr(transparent)]
> >> +pub struct PowerOfTwo(T);
> >> +
> >> +macro_rules! power_of_two_impl {
> >> +($($t:ty),+) => {
> >> +$(
> >> +impl PowerOfTwo<$t> {
> >> +/// Validates
Let the locking functions take the new struct ttm_lru_walk_arg
as argument in order for them to be easily used from both
types of walk.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_bo.c | 24 ++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 26 ++--
To avoid duplicating the tricky bo locking implementation,
Implement ttm_lru_walk_for_evict() using the guarded bo LRU iteration.
To facilitate this, support ticketlocking from the guarded bo LRU
iteration.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 166
Instead of the struct ttm_operation_ctx, Pass a struct ttm_lru_walk_arg
to enable us to easily extend the walk functionality, and to
implement ttm_lru_walk_for_evict() using the guarded LRU iteration.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 10 +-
drivers/
This is a deferred task from the Xe bo shrinker addition.
TTM currently have two separate ways of doing buffer object LRU
walks, of which one is exposed to drivers. Both have their benefits
but we shouldn't be implementing the complex bo locking in
two different places. So implement the ttm_lru_wa
Instead of using driver-specific code, use DRM helpers.
Signed-off-by: Melissa Wen
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/d
On 6/13/25 16:35, Simona Vetter wrote:
> On Fri, Jun 13, 2025 at 04:12:47PM +0200, Christian König wrote:
>> On 6/13/25 16:04, Simona Vetter wrote:
>>> On Fri, Jun 13, 2025 at 03:12:01PM +0200, Christian König wrote:
It is possible through flink or IOCTLs like MODE_GETFB2 to create
multip
Add Linux opaque object to dc_sink for storing edid data cross driver,
drm_edid. Also include the Linux call to free this object, the
drm_edid_free()
v3:
- remove uneccessary include (jani)
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/dc_edid.c | 6 ++
drivers/gpu/dr
Reduce direct handling of edid data by resorting to drm helpers that
deal with this info inside drm_edid infrastructure.
v3:
- use dc_edid_sink_edid_free in link_detection
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 26 +++
.../amd/display/amdg
From: Rodrigo Siqueira
As part of the effort of stopping using raw edid, this commit move the
copy of the edid in DC to a dedicated function that will allow the usage
of drm_edid in the next steps.
v3:
- remove superfulous cast (jani)
Signed-off-by: Rodrigo Siqueira
Co-developer--by: Melissa W
AMD driver has a function used to compare if two edid are the same; this
is useful to some of the link detection algorithms implemented by
amdgpu. Since the amdgpu function can be helpful for other drivers, this
commit abstracts the AMD function to make it available at the DRM level
by wrapping exi
drm_edid_connector_update() updates display info, filling ELD with audio
info from Short-Audio Descriptors in the last step of
update_dislay_info(). Our goal is stopping using raw edid, so we can
extract SAD from drm_eld instead of access raw edid to get audio caps.
Signed-off-by: Melissa Wen
---
There is an opaque obj in Linux/DRM to encapsulate edid data as
`drm_edid`. This obj isn't present in other platforms but we need to
pass it through DC when adding sink. To pass this data without
compromise the independence of DC code, make some DC functions accept
edid data as private options.
Si
Pass dc_sink to dm_helpers_parse_edid_caps(), since it already contains
edid info. It's a groundwork to get rid of raw edid stored as dc_edid.
v4:
- fix kernel-doc
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers
drm_edid_connector_update() updates display info, filling ELD with
speaker allocation data in the last step of update_dislay_info(). Our
goal is stopping using raw edid, so we can extract SADB from drm_eld
instead of access raw edid to get audio caps.
Signed-off-by: Melissa Wen
---
.../drm/amd/d
Original drm_edid_get_monitor_name encapsulates raw edid in drm_edid and
then call get_monitor_name. AMD still stores the display name for
debugging, but it is migrating to drm_edid, on the other hand,
drm_dp_mst_topology and sil-sii8620 still use the raw edid version.
Split drm_edid_get_monitor_n
Groundwork that allocates a temporary drm_edid from raw edid to take
advantage of DRM common-code helpers instead of driver-specific code.
Signed-off-by: Melissa Wen
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c| 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff
Since [1], we can use drm_edid_product_id to get debug info from
drm_edid instead of directly parsing EDID.
Link:
https://lore.kernel.org/dri-devel/cover.1712655867.git.jani.nik...@intel.com/
[1]
Signed-off-by: Melissa Wen
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 15
Hi,
Siqueira and I have been working on a solution to reduce the usage of
drm_edid_raw in the AMD display driver, since the current guideline in
the DRM subsystem is to stop handling raw edid data in driver-specific
implementation and use opaque `drm_edid` object with common-code
helpers.
In shor
Make sure the drm_edid container stored in aconnector is freed when
destroying the aconnector.
Fixes: 48edb2a4 ("drm/amd/display: switch amdgpu_dm_connector to use struct
drm_edid")
Reviewed-by: Mario Limonciello
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
On Fri, Jun 13, 2025 at 03:14:24PM +0100, Tvrtko Ursulin wrote:
On 13/06/2025 15:10, Lucas De Marchi wrote:
On Fri, Jun 13, 2025 at 09:02:27AM +0100, Tvrtko Ursulin wrote:
On 12/06/2025 19:53, Yiwei Zhang wrote:
On Thu, Jun 12, 2025 at 11:02 AM Lucas De Marchi
wrote:
On Thu, Jun 12, 2025
On Fri, 13 Jun 2025 08:28:40 -0400 Yury Norov wrote:
> > > And perhaps that (and more potential users) could persuade Jakub that
> > > this is not that weird after all?
> >
> > I will operate under the assumption that Jakub's opinion will not change
> > as he ignored the commit message that talk
On Fri Jun 13, 2025 at 3:41 PM BST, Rob Clark wrote:
> We want to WARN_ON() if info is NULL.
>
> Suggested-by: Konrad Dybcio
> Fixes: 0838fc3e6718 ("drm/msm/adreno: Check for recognized GPU before bind")
> Tested-by: Neil Armstrong
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/a
Hi Jani,
On 6/12/25 5:27 PM, Jani Nikula wrote:
Fix the kernel-doc directive after the rename
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/{r535,rm/r535/gsp}.c leading to
erros:
Thanks for the patch! This is already fixed by [1]. Since this patch appears to
be before yours in my inbox I take this o
On Thu, Jun 12, 2025 at 03:52:24PM +0200, Thomas Zimmermann wrote:
> Only sysfb drivers use drm_fb_build_fourcc_list(). Move the function
> to sysfb helpers and rename it accordingly. Update drivers and tests.
>
> v2:
> - select DRM_SYSFB_HELPER (kernel test robot)
>
> Signed-off-by: Thomas Zimme
On Fri, Jun 13, 2025 at 02:54:50PM +0100, Robin Murphy wrote:
> On 2025-06-12 7:56 pm, Nicolas Frattaroli wrote:
> > Hardware of various vendors, but very notably Rockchip, often uses
> > 32-bit registers where the upper 16-bit half of the register is a
> > write-enable mask for the lower half.
> >
On Fri Jun 13, 2025 at 3:41 PM BST, Rob Clark wrote:
> We want to WARN_ON() if info is NULL.
>
> Suggested-by: Konrad Dybcio
> Fixes: 0838fc3e6718 ("drm/msm/adreno: Check for recognized GPU before bind")
> Tested-by: Neil Armstrong
> Signed-off-by: Rob Clark
You forgot Reported-by tag.
Reporte
to sample rates in the deleted code.
Full log:
https://lava.sirena.org.uk/scheduler/job/1473785#L1435
A bisection points at this patch:
# bad: [bc6e0ba6c9bafa6241b05524b9829808056ac4ad] Add linux-next specific files
for 20250613
# good: [afc47587aec9fbefabca94da7225f371d1f24ca5
1 - 100 of 221 matches
Mail list logo
