Hi Dave & Sima,
Here goes another drm-intel-next-fixes PR towards 6.16-rc1.
Thunderbolt disconnect fix for MTL/ARL/LNL, DDI port clock fix for PTL+ and WQ
allocation error check for display init code.
Regards, Joonas
PS. CI results were for one patch more, which I reverted during review
of the
On Wed, May 21, 2025 at 9:13 AM Christian König
wrote:
>
> On 5/20/25 17:16, Jens Wiklander wrote:
> > Export the dma-buf heap functions declared in .
>
> That is what this patch does and that should be obvious by looking at it. You
> need to explain why you do this.
>
> Looking at the rest of th
From: Dave Airlie
This adds accessors inlines to the iosys-map. The intent is to
roll the iomem flag into the lower bits of the vaddr eventually.
First just add accessors to move all current in-tree users over to.
Signed-off-by: Dave Airlie
---
include/linux/iosys-map.h | 53 +
From: Dave Airlie
This uses the new accessors to avoid touch iosys_map internals.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/xe/display/intel_fbdev_fb.c | 2 +-
drivers/gpu/drm/xe/xe_bo.c | 8
drivers/gpu/drm/xe/xe_eu_stall.c| 2 +-
drivers/gpu/drm/
From: Dave Airlie
This avoids directly accessing the iosys_map internals using new interfaces.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_cache.c | 28 +--
drivers/gpu/drm/drm_fbdev_shmem.c | 4 +--
drivers/gpu/drm/drm_format_helper.c
From: Dave Airlie
This reduces this struct from 16 to 8 bytes, and it gets embedded
into a lot of things.
Signed-off-by: Dave Airlie
---
include/linux/iosys-map.h | 30 --
1 file changed, 8 insertions(+), 22 deletions(-)
diff --git a/include/linux/iosys-map.h b/inc
From: Dave Airlie
Now hide the current implementation details, to catch any new
users entering the tree and trying to trick us up.
Signed-off-by: Dave Airlie
---
include/linux/iosys-map.h | 48 +++
1 file changed, 24 insertions(+), 24 deletions(-)
diff --gi
From: Dave Airlie
This uses the new accessors to use iosys_map.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 12 ++--
drivers/gpu/drm/ttm/ttm_resource.c | 8
drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
3 files changed, 11 insertions(+), 11 deletions(-)
Hey iosys_map users :)
I fell down a bit of a refactor hole today, it was just random and
sometimes you just have to let these things run their course.
I noticed iosys_map has a 7-byte hole in a 16-byte structure, and
it gets embedded into a bunch of other structs and it offended my
sensibilities
From: Dave Airlie
This just avoids looking into the internals of the iosys_map.
Signed-off-by: Dave Airlie
---
drivers/dma-buf/udmabuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 7eee3eb47a8e..101cc7853043 10
From: Dave Airlie
This uses the new accessors to avoid touching the iosys_map internals.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/qxl/qxl_display.c | 14 +++---
drivers/gpu/drm/qxl/qxl_draw.c| 4 ++--
drivers/gpu/drm/qxl/qxl_object.c | 8
3 files changed, 13 inser
From: Dave Airlie
Use the new accessor interfaces to avoid directly accessing the
internals.
Signed-off-by: Dave Airlie
---
drivers/firmware/tegra/ivc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware/tegra/ivc.c b/drivers/firmware/tegra/ivc.c
in
On Wed May 21, 2025 at 9:43 PM JST, Boqun Feng wrote:
> On Wed, May 21, 2025 at 03:44:56PM +0900, Alexandre Courbot wrote:
>> These properties are very useful to have and should be accessible.
>>
>> Signed-off-by: Alexandre Courbot
>> ---
>> rust/kernel/dma.rs | 18 ++
>> 1 file
Hello DRM Maintainers,
I have two patches (01/12 and 02/12) in this set I would like to merge
via drm-intel/drm-intel-next. Is that ok to you? They are touching i915
display driver and drm_dp.h header and rest of the patch set is
depending on those changes. Can one of you ack those two patches?
T
On Wed May 21, 2025 at 5:00 PM JST, Danilo Krummrich wrote:
> On Wed, May 21, 2025 at 03:44:56PM +0900, Alexandre Courbot wrote:
>> These properties are very useful to have and should be accessible.
>>
>> Signed-off-by: Alexandre Courbot
>> ---
>> rust/kernel/dma.rs | 18 ++
>> 1
On Wed May 21, 2025 at 5:37 PM JST, Danilo Krummrich wrote:
> On Wed, May 21, 2025 at 03:45:03PM +0900, Alexandre Courbot wrote:
>> Some registers (notably scratch registers) don't have a definitive
>> purpose, but need to be interpreted differently depending on context.
>>
>> Expand the register!
Add device tree nodes for the DSI0 and DSI1 controllers
with their corresponding PHYs found on Qualcomm SA8775P SoC.
Signed-off-by: Ayushi Makhija
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sa8775p.dtsi | 177 +-
1 file changed
Add anx7625 DSI to DP bridge device nodes.
Signed-off-by: Ayushi Makhija
Reviewed-by: Konrad Dybcio
Reviewed-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 232 +
1 file changed, 232 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride.dt
This series enables the support for DSI to DP bridge ports
(labled as DSI0 and DSI1) of the Qualcomm's SA8775P Ride platform.
SA8775P SoC has DSI controller v2.5.1 and DSI PHY v4.2.
The Ride platform is having ANX7625 DSI to DP bridge chip from Analogix.
---
Changes in v8: Fixed the review comme
On 5/19/2025 5:11 PM, Srinivas Kandagatla wrote:
> On 5/13/25 05:28, Ekansh Gupta wrote:
>> The initially allocated memory is not properly included in the pool,
>> leading to potential issues with memory management. Set the number
>> of pages to one to ensure that the initially allocated memory
On 5/19/2025 5:05 PM, Srinivas Kandagatla wrote:
> On 5/13/25 05:28, Ekansh Gupta wrote:
>> Remote heap allocations are not organized in a maintainable manner,
>> leading to potential issues with memory management. As the remote
>> heap allocations are maintained in fl mmaps list, the allocation
On 5/19/2025 7:04 PM, Dmitry Baryshkov wrote:
> On Mon, May 19, 2025 at 04:28:34PM +0530, Ekansh Gupta wrote:
>>
>> On 5/19/2025 4:22 PM, Dmitry Baryshkov wrote:
>>> On Tue, May 13, 2025 at 09:58:25AM +0530, Ekansh Gupta wrote:
User request for remote heap allocation is supported using ioct
On 5/19/2025 7:01 PM, Dmitry Baryshkov wrote:
> On Mon, May 19, 2025 at 04:23:28PM +0530, Ekansh Gupta wrote:
>>
>> On 5/19/2025 3:47 PM, Dmitry Baryshkov wrote:
>>> On Tue, May 13, 2025 at 09:58:23AM +0530, Ekansh Gupta wrote:
The initially allocated memory is not properly included in the
On 5/19/2025 6:59 PM, Dmitry Baryshkov wrote:
> On Mon, May 19, 2025 at 04:36:13PM +0530, Ekansh Gupta wrote:
>>
>> On 5/19/2025 3:46 PM, Dmitry Baryshkov wrote:
>>> On Tue, May 13, 2025 at 09:58:22AM +0530, Ekansh Gupta wrote:
Remote heap allocations are not organized in a maintainable man
On 5/20/2025 5:55 PM, Jani Nikula wrote:
On Tue, 20 May 2025, Ankit Nautiyal wrote:
Commit 584cf613c24a ("drm/i915/dp: Reject HBR3 when sink doesn't support
TPS4") introduced a blanket rejection of HBR3 link rate when the sink does
not support TPS4. While this was intended to address instabil
On Wed May 21, 2025 at 3:44 PM JST, Alexandre Courbot wrote:
> Introduce the `num` module, featuring the `NumExt` extension trait
> that expands unsigned integers with useful operations for the kernel.
>
> These are to be used by the nova-core driver, but they are so ubiquitous
> that other drivers
On 16/5/25 02:04, Xu Yilun wrote:
On Wed, May 14, 2025 at 01:33:39PM -0300, Jason Gunthorpe wrote:
On Wed, May 14, 2025 at 03:02:53PM +0800, Xu Yilun wrote:
We have an awkward fit for what CCA people are doing to the various
Linux APIs. Looking somewhat maximally across all the arches a "bin
Hi Hugo,
kernel test robot noticed the following build errors:
[auto build test ERROR on 7c1a9408ce5f34ded5a85db81cf80e0975901685]
url:
https://github.com/intel-lab-lkp/linux/commits/Hugo-Villeneuve/drm-rcar-du-rzg2l_mipi_dsi-Implement-host-transfers/20250521-011613
base
On 21/05/2025 18:10, Krzysztof Niemiec wrote:
On 2025-05-21 at 09:06:43 GMT, Tvrtko Ursulin wrote:
On 20/05/2025 16:01, Joonas Lahtinen wrote:
(+ Tvrtko, Rodrigo and Jani)
Quoting Krzysztof Niemiec (2025-05-19 18:34:14)
Hi,
This series introduces a way for applications to read local memor
Hi Pierre-Eric,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-xe/drm-xe-next]
[also build test ERROR on next-20250521]
[cannot apply to lwn/docs-next linus/master v6.15-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On 05/21/2025, Luca Ceresoli wrote:
> Hello Maxime, Shawn, Liu, all,
>
> On Fri, 09 May 2025 15:53:26 +0200
> Luca Ceresoli wrote:
>
>> devm_drm_bridge_alloc() [0] is the new API to allocate and initialize a DRM
>> bridge, and the only one supported from now on. It is the first milestone
>> towa
On 05/07/2025, Luca Ceresoli wrote:
[...]
>> After looking into this patch and patch 31(though I've already provided my
>> A-b)
>> more closely, I think the imx8qxp_pc and imx8{qm,qxp}_ldb main structures
>> should have the same life time with the embedded DRM bridges, because for
>> example the
Hi David,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20250521]
[cannot apply to drm-exynos/exynos-drm-next linus/master v6.15-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And
Hi Andy,
On 2025/5/21 20:09, Andy Yan wrote:
Hi Chaoyi，
At 2025-05-07 11:51:48, "Chaoyi Chen" wrote:
From: Chaoyi Chen
Convert it to drm bridge driver, it will be convenient for us to
migrate the connector part to the display driver later.
Tested with RK3399 EVB IND board.
Signed-off-by:
Hi,
On Thu, May 8, 2025 at 4:54 AM Jayesh Choudhary wrote:
>
> By default, HPD was disabled on SN65DSI86 bridge. When the driver was
> added (commit "a095f15c00e27"), the HPD_DISABLE bit was set in pre-enable
> call which was moved to other function calls subsequently.
> Later on, commit "c312b0d
On 5/7/2025 11:18 PM, Krzysztof Kozlowski wrote:
On 23/04/2025 04:46, Abhinav Kumar wrote:
Hi Krzysztof
On 12/3/2024 12:04 AM, Krzysztof Kozlowski wrote:
On 03/12/2024 04:31, Abhinav Kumar wrote:
On some chipsets the display port controller can support more
Which chipsets?
From the
On 4/23/2025 7:23 AM, Dmitry Baryshkov wrote:
On Tue, Apr 22, 2025 at 07:46:57PM -0700, Abhinav Kumar wrote:
On 12/3/2024 5:43 AM, Dmitry Baryshkov wrote:
On Mon, Dec 02, 2024 at 07:31:41PM -0800, Abhinav Kumar wrote:
On some chipsets the display port controller can support more
than one
It's unclear why I originally wrote in the description of
`prepare_to_enable` that "This is not specified in a standard way on
eDP timing diagrams" and then also wrote "It is effectively the time
from HPD going high till you can turn on the backlight." It seems
pretty clear that it's (T4+T5+T6+T8)-
Hi,
On Wed, May 21, 2025 at 2:37 AM Langyan Ye
wrote:
>
> Add support for the KDC KD116N3730A05, pleace the EDID here for
> subsequent reference.
>
> 00 ff ff ff ff ff ff 00 2c 83 20 12 00 00 00 00
> 30 22 01 04 95 1a 0e 78 03 3a 75 9b 5d 5b 96 28
> 19 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
kzalloc() already zero-initializes the destination buffers, making
strscpy() sufficient for safely copying the names. The additional
NUL-padding performed by strscpy_pad() is unnecessary.
If the destination buffer has a fixed length, strscpy() automatically
determines its size using sizeof() when
On Thu, May 15, 2025 at 04:33:39PM +0300, Alexander Usyskin wrote:
> Register the on-die nvm device with the mtd subsystem.
> Refcount nvm object on _get and _put mtd callbacks.
> For erase operation address and size should be 4K aligned.
> For write operation address and size has to be 4bytes alig
Currently we expose the ability to retrieve an SGTable for an shmem gem
object using gem::shmem::Objectsg_table(). However, this only gives us a
borrowed reference. This being said - retrieving an SGTable is a fallible
operation, and as such it's reasonable that a driver may want to hold
onto a
This is an associated type that may be used in order to specify a data-type
to pass to gem objects when construction them, allowing for drivers to more
easily initialize their private-data for gem objects.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nova/gem.rs | 5 +++--
rust/kernel/drm/gem/
In order to implement the gem export callback, we need a type to represent
struct dma_buf. So - this commit introduces a set of stub bindings for
dma_buf. These bindings provide a ref-counted DmaBuf object, but don't
currently implement any functionality for using the DmaBuf.
Signed-off-by: Lyude
We just added an export() callback that GEM objects can implement, but
without any way of actually exporting a DmaBuf. So let's add one by
introducing bindings for drm_gem_prime_export().
Signed-off-by: Lyude Paul
---
rust/kernel/drm/gem/mod.rs | 23 +++
1 file changed, 23 in
This introduces an optional export() callback for GEM objects, which is
used to implement the drm_gem_object_funcs->export function.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nova/gem.rs | 1 +
rust/kernel/drm/gem/mod.rs | 73 +++-
rust/kernel/drm/gem/shme
From: Asahi Lina
Allow a GEM object to share another object's DMA reservation, for use
with drm_gpuvm. To keep memory safety, we hold a reference to the GEM
object owning the resv, and drop it when the child object is freed.
Signed-off-by: Asahi Lina
Signed-off-by: Lyude Paul
---
rust/kernel/
From: Asahi Lina
The DRM shmem helper includes common code useful for drivers which
allocate GEM objects as anonymous shmem. Add a Rust abstraction for
this. Drivers can choose the raw GEM implementation or the shmem layer,
depending on their needs.
Signed-off-by: Asahi Lina
Signed-off-by: Dani
With gem objects in rust, the most ideal way for us to be able to handle
gem shmem object creation is to be able to handle the memory allocation of
a gem object ourselves - and then have the DRM gem shmem helpers initialize
the object we've allocated afterwards. So, let's spit out
drm_gem_shmem_ini
In the future, we want to have the ability for a driver to have private gem
objects - or use gem objects across ffi boundaries that don't use our
driver's GEM object implementation. So, let's take some inspiration from
the KMS bindings I've been working on and introduce an OpaqueObject type.
This
At the moment the way that freeing gem shmem objects is not ideal for rust
bindings. drm_gem_shmem_free() releases all of the associated memory with a
gem shmem object with kfree(), which means that for us to correctly release
a gem shmem object in rust we have to manually drop all of the contents
For retrieving a pointer to the struct dma_resv for a given GEM object. We
also introduce it in a new trait, BaseObjectPrivate, which we automatically
implement for all gem objects and don't expose to users outside of the
crate.
Signed-off-by: Lyude Paul
---
rust/kernel/drm/gem/mod.rs | 11 +
This is the next version of the shmem backed GEM objects series
originally from Asahi, previously posted by Daniel Almeida. Along with
bindings for shmem backed GEM objects, it also adds a few features that
various users like Tyr and Asahi are interested in:
* The ability to pass custom arguments
From: Asahi Lina
This is just for basic usage in the DRM shmem abstractions for implied
locking, not intended as a full DMA Reservation abstraction yet.
Signed-off-by: Asahi Lina
Signed-off-by: Daniel Almeida
Signed-off-by: Lyude Paul
---
rust/bindings/bindings_helper.h | 1 +
rust/helpers/
On Thu, May 15, 2025 at 04:33:38PM +0300, Alexander Usyskin wrote:
> Implement read(), erase() and write() functions.
...
> +__maybe_unused
> +static ssize_t idg_write(struct intel_dg_nvm *nvm, u8 region,
> + loff_t to, size_t len, const unsigned char *buf)
> +{
> + size_
Hi Marco,
Thank you for the patch.
On Thu, May 15, 2025 at 07:36:43PM +0200, Marco Felsch wrote:
> Make use of __free(device_node) to simplify the of_node_put() error
> handling paths. No functional changes.
>
> Signed-off-by: Marco Felsch
Reviewed-by: Laurent Pinchart
> ---
> Changelog:
> v
From: Dave Airlie
This device pointer is nearly always available without storing
an extra copy for each tt in the system.
Just noticed this while reading over the xe shrinker code.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/xe/tests/xe_bo.c | 4 +--
drivers/gpu/drm/xe/xe_bo.c | 59
On 2025-05-17 07:51, Xaver Hugl wrote:
> Am Do., 15. Mai 2025 um 22:00 Uhr schrieb Leandro Ribeiro
> :
>>
>>
>>
>> On 5/15/25 15:39, Daniel Stone wrote:
>>> Hi,
>>>
>>> On Thu, 15 May 2025 at 19:02, Harry Wentland wrote:
On 2025-05-15 13:19, Daniel Stone wrote:
> Yeah, the Weston patch
Hi Chris Brandt,
Thanks for the patch.
> -Original Message-
> From: Chris Brandt
> Sent: 21 May 2025 15:24
> Subject: [PATCH] drm: renesas: rz-du: Add atomic_pre_enable
>
> When drm_panel.prepare_prev_first is set to true in a panel driver, the panel
> expects the MIPI DSI
> hardware t
On 2025-05-20 16:13, Harry Wentland wrote:
>
>
> On 2025-05-19 19:43, Simon Ser wrote:
>> On Sunday, May 18th, 2025 at 00:32, Xaver Hugl wrote:
>>
We can always make the property mutable on drivers that support it in
>>>
the future, much like the zpos property. I think we should kee
Hi Biju,
On Wed, 21 May 2025 07:43:08 +
Biju Das wrote:
> Hi Hugo,
>
> Thanks for the patch.
>
> For some reason, your cover letter is not showing link to this patch
> [1] https://lore.kernel.org/all/20250520164034.3453315-1-h...@hugovil.com/
My server had problems, and only sent the cove
Hi Laurent,
Thank you for the review.
On Tue, May 20, 2025 at 3:16 PM Laurent Pinchart
wrote:
>
> Hi Prabhakar,
>
> On Mon, May 12, 2025 at 07:23:23PM +0100, Prabhakar wrote:
> > From: Lad Prabhakar
> >
> > Update the RZ/G2L MIPI DSI driver to calculate HSFREQ using the actual
> > VCLK rate ins
[AMD Official Use Only - AMD Internal Distribution Only]
Hi Mike,
Thanks for the details. We tried to repro the issue at our end on 9000 and 7000
series dgpu, but we're not seeing the dmub errors. We were on Ubunti, so we'll
try Fedora.
--
Regards,
Jay
From: M
On 2025-05-21 at 09:06:43 GMT, Tvrtko Ursulin wrote:
>
> On 20/05/2025 16:01, Joonas Lahtinen wrote:
> > (+ Tvrtko, Rodrigo and Jani)
> >
> > Quoting Krzysztof Niemiec (2025-05-19 18:34:14)
> > > Hi,
> > >
> > > This series introduces a way for applications to read local memory
> > > information
Hi,
On 2025-05-20 at 19:46:48 GMT, Andi Shyti wrote:
> Hi,
>
> On Tue, May 20, 2025 at 06:01:12PM +0300, Joonas Lahtinen wrote:
> > Quoting Krzysztof Niemiec (2025-05-19 18:34:14)
> > > This series introduces a way for applications to read local memory
> > > information via files in the sysfs. So
Hi,
On 2025-05-20 at 18:01:12 GMT, Joonas Lahtinen wrote:
> (+ Tvrtko, Rodrigo and Jani)
>
> Quoting Krzysztof Niemiec (2025-05-19 18:34:14)
> > Hi,
> >
> > This series introduces a way for applications to read local memory
> > information via files in the sysfs. So far the only way to do this w
Convert fsl,dcu.txt to yaml format.
Additional changes:
- remove label in example.
- change node to display-controller in example.
- use 32bit address in example.
- add interrupts property.
Signed-off-by: Frank Li
Reviewed-by: Stefan Agner
---
Change from v1 to v2
- add Reviewed-by: Stefan Agne
As it isn't supported by rk3399. From the datasheet[1]
("1.2.10 Video IN/OUT", "Display Interface", p. 17):
Support AFBC function co-operation with GPU
* support 2560x1600 UI
Signed-off-by: Konstantin Shabanov
Cc: Daniel Stone
Cc: Andy Yan
Reported-by: Dan Callaghan
Closes: https://gitl
On Tue, May 20, 2025 at 9:22 PM Mikhail Gavrilov
wrote:
>
> > Could you more details about your setup, and how you were able to repro it ?
> >
Hi,
Were you able to reproduce the issue?
I’ve prepared a step-by-step guide that may help:
1. Set up a system with a Radeon 6900XT and an LG TV connecte
On 5/21/2025 11:57 AM, Joel Fernandes wrote:
>
>
> On 5/21/2025 8:43 AM, Boqun Feng wrote:
>> On Wed, May 21, 2025 at 03:44:56PM +0900, Alexandre Courbot wrote:
>>> These properties are very useful to have and should be accessible.
>>>
>>> Signed-off-by: Alexandre Courbot
>>> ---
>>> rust/ke
On 5/21/2025 8:43 AM, Boqun Feng wrote:
> On Wed, May 21, 2025 at 03:44:56PM +0900, Alexandre Courbot wrote:
>> These properties are very useful to have and should be accessible.
>>
>> Signed-off-by: Alexandre Courbot
>> ---
>> rust/kernel/dma.rs | 18 ++
>> 1 file changed, 18
Em 21/05/2025 06:11, Raag Jadav escreveu:
On Tue, May 20, 2025 at 01:32:41PM -0300, André Almeida wrote:
When a device get wedged, it might be caused by a guilty application.
For userspace, knowing which task was the cause can be useful for some
situations, like for implementing a policy, logs o
On 20/05/2025 18:44, Adrián Larumbe wrote:
> Commit 64111a0e22a9 ("drm/panfrost: Fix incorrect updating of current
> device frequency") was a Panfrost port of a similar fix in Panthor.
>
> Fix the Panfrost device pointer variable name so that it follows
> Panfrost naming conventions.
>
> Signed-o
On 20/05/2025 18:44, Adrián Larumbe wrote:
> This change is essentially a Panfrost port of commit a3707f53eb3f
> ("drm/panthor: show device-wide list of DRM GEM objects over DebugFS").
>
> The DebugFS file is almost the same as in Panthor, minus the GEM object
> usage flags, since Panfrost has no
On 20/05/2025 18:43, Adrián Larumbe wrote:
> Perfcnt samples buffer is not exposed to UM, but we would like to keep
> a tag on it as a potential debug aid.
>
> PRIME imported GEM buffers are UM exposed, but since the usual Panfrost
> UM driver code path is not followed in their creation, they migh
Log fences using the same format for coherency.
Signed-off-by: Pierre-Eric Pelloux-Prayer
Reviewed-by: Christian König
Reviewed-by: Arvind Yadav
---
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gp
This commit adds a document section in drm-uapi.rst about tracepoints,
and mark the events gpu_scheduler_trace.h as stable uAPI.
The goal is to explicitly state that tools can rely on the fields,
formats and semantics of these events.
Acked-by: Lucas Stach
Acked-by: Maíra Canal
Reviewed-by: Chr
Its only purpose was for trace events, but jobs can already be
uniquely identified using their fence.
The downside of using the fence is that it's only available
after 'drm_sched_job_arm' was called which is true for all trace
events that used job.id so they can safely switch to using it.
Suggest
All events now start with the same prefix (drm_sched_job_).
drm_sched_job_wait_dep was misleading because it wasn't waiting
at all. It's now replaced by trace_drm_sched_job_unschedulable,
which is only traced if the job cannot be scheduled.
For moot dependencies, nothing is traced.
Signed-off-by:
For processes with multiple drm_file instances, the drm_client_id is
the only way to map jobs back to their unique owner.
It's even more useful if drm client_name is set, because now a tool
can map jobs to the client name instead of only having access to
the process name.
Reviewed-by: Christian K
We can't trace dependencies from drm_sched_job_add_dependency
because when it's called the job's fence is not available yet.
So instead each dependency is traced individually when
drm_sched_entity_push_job is used.
Tracing the dependencies allows tools to analyze the dependencies
between the jobs
A fence uniquely identify a job, so this commits updates the places
where a kernel pointer was used as an identifier by:
"fence=%llu:%llu"
Signed-off-by: Pierre-Eric Pelloux-Prayer
Reviewed-by: Tvrtko Ursulin
---
.../gpu/drm/scheduler/gpu_scheduler_trace.h | 44 ++-
1 file
Since switching the scheduler from using kthreads to workqueues in
commit a6149f039369 ("drm/sched: Convert drm scheduler to use a work
queue rather than kthread") userspace applications cannot determine
the device from the PID of the threads sending the trace events
anymore.
Each queue had its ow
This will be used in a later commit to trace the drm client_id in
some of the gpu_scheduler trace events.
This requires changing all the users of drm_sched_job_init to
add an extra parameter.
The newly added drm_client_id field in the drm_sched_fence is a bit
of a duplicate of the owner one. One
client_id is a unique id used by fdinfo. Having it listed in 'clients'
output means a userspace application can correlate the fields, eg:
given a fdinfo id get the fdinfo name.
Geiven that client_id is a uint64_t, we use a %20llu printf format to
keep the output aligned (20 = digit count of the bi
Hi,
The initial goal of this series was to improve the drm and amdgpu
trace events to be able to expose more of the inner workings of
the scheduler and drivers to developers via tools.
Then, the series evolved to become focused only on gpu_scheduler.
The changes around vblank events will be part
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
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 19 +--
drivers/gpu/drm/amd/amdgpu/a
When a device get wedged, it might be caused by a guilty application.
For userspace, knowing which task was the cause 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 caused the problem.
This is an optio
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
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 Jared,
On Thu, Apr 24, 2025 at 09:11:24AM -0700, Jared Kangas wrote:
> > > struct cma_heap {
> > > struct dma_heap *heap;
> > > @@ -394,15 +395,26 @@ static int __init __add_cma_heap(struct cma *cma,
> > > const char *name)
> > > static int __init add_default_cma_heap(void)
> > > {
> > >
…
> There are a lot of occurences of the panel allocation across the
> subsystem. Much thanks to Maxime for the semanic patch which actually
> gives a list of panels allocated unsafely.
I imagine that the shown SmPL code can be improved another bit
(like the following).
@find_add@
identifier add
On 19/05/2025 15:50, Ashley Smith wrote:
> This fixes a bug where if we timeout after a suspend and the termination
> fails, due to waiting on a fence that will never be signalled for
> example, we do not resume the group correctly. The fix forces a reset
> for groups that are not terminated correc
On 5/21/25 16:06, David Francis wrote:
> 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
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
On Wed, May 21, 2025 at 12:23:58PM +1000, Dave Airlie wrote:
> >
> > So in the GPU case, you'd charge on allocation, free objects into a
> > cgroup-specific pool, and shrink using a cgroup-specific LRU
> > list. Freed objects can be reused by this cgroup, but nobody else.
> > They're reclaimed thro
On 5/21/25 16:06, David Francis wrote:
> 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
On Wed, May 21, 2025 at 08:09:14AM +0200, Krzysztof Kozlowski wrote:
> On 20/05/2025 22:06, Dmitry Baryshkov wrote:
> > On Tue, May 20, 2025 at 01:13:26PM +0200, Krzysztof Kozlowski wrote:
> >> Driver unconditionally saves current state on first init in
> >> dsi_pll_10nm_init(), but does not save t
Hello Maxime, Shawn, Liu, all,
On Fri, 09 May 2025 15:53:26 +0200
Luca Ceresoli wrote:
> devm_drm_bridge_alloc() [0] is the new API to allocate and initialize a DRM
> bridge, and the only one supported from now on. It is the first milestone
> towards removal of bridges from a still existing DRM
Hi Laurent,
Thank you for the review.
On Tue, May 20, 2025 at 3:22 PM Laurent Pinchart
wrote:
>
> Hi Prabhakar,
>
> Thank you for the patch.
>
> On Mon, May 12, 2025 at 07:23:24PM +0100, Prabhakar wrote:
> > From: Lad Prabhakar
> >
> > In preparation for adding support for the Renesas RZ/V2H(P)
1 - 100 of 191 matches
Mail list logo
