Am 27.08.24 um 18:14 schrieb Lucas De Marchi:
On Tue, Aug 27, 2024 at 11:42:59AM GMT, Thomas Hellström wrote:
On Wed, 2024-08-21 at 11:50 +0200, Nirmoy Das wrote:
Remove TTM_TT_FLAG_CLEARED_ON_FREE now that XE stopped using this
flag.
This reverts commit decbfaf06db05fa1f9b33149ebb3c145b44e878
> -Original Message-
> From: Laurent Pinchart
> Sent: Tuesday, August 27, 2024 11:23 PM
> Subject: Re: [PATCH v2] drm: rcar-du: Fix memory leak in rcar_du_vsps_init()
>
> Hi Biju,
>
> On Tue, Aug 27, 2024 at 04:43:12PM +, Biju Das wrote:
> > Hi Laurent and Tomi,
> >
> > Gentle ping
On 23-08-2024 09:15, Raag Jadav wrote:
Add hwmon support for fan1_input attribute, which will expose fan speed
in RPM. With this in place we can monitor fan speed using lm-sensors tool.
$ sensors
i915-pci-0300
Adapter: PCI adapter
in0: 653.00 mV
fan1:3833 RPM
power1:
Now we can use new port related functions for port parsing. Use it.
Signed-off-by: Kuninori Morimoto
Reviewed-by: Tomi Valkeinen
---
drivers/media/platform/xilinx/xilinx-tpg.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/xilinx/xilinx-tpg.c
b/dri
Now we can use new port related functions for port parsing. Use it.
Signed-off-by: Kuninori Morimoto
---
drivers/video/fbdev/omap2/omapfb/dss/dpi.c| 3 +-
drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 66 ---
drivers/video/fbdev/omap2/omapfb/dss/dss.c| 9 +--
drivers/
Now we can use new port related functions for port parsing. Use it.
Signed-off-by: Kuninori Morimoto
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 3 ++-
drivers/gpu/drm/omapdrm/dss/sdi.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/d
Now we can use new port related functions for port parsing. Use it.
Signed-off-by: Kuninori Morimoto
Acked-by: Mark Brown
---
sound/soc/generic/audio-graph-card2.c | 113 +++---
1 file changed, 48 insertions(+), 65 deletions(-)
diff --git a/sound/soc/generic/audio-graph-car
Now we can use new port related functions for port parsing. Use it.
Signed-off-by: Kuninori Morimoto
Acked-by: Mark Brown
---
sound/soc/generic/audio-graph-card.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/sound/soc/generic/audio-graph-card.c
b/sound/soc/ge
Now we can use new port related functions for port parsing. Use it.
Signed-off-by: Kuninori Morimoto
Acked-by: Mark Brown
---
sound/soc/sh/rcar/core.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c
i
Current test-component.c is using for_each_endpoint_of_node()
for parsing "port", because there was no "port" base loop before.
It has been assuming 1 port has 1 endpoint here.
But now we can use "port" base loop (= for_each_of_graph_port()).
Let's replace for_each function from "endpoint" base to
We already have of_graph_get_next_endpoint(), but it is not
intuitive to use in some case.
(X) node {
(Y) ports {
(P0)port@0 { endpoint { remote-endpoint = ...; };};
(P10) port@1 { endpoint { remote-endpoint = ...; };
(P11)
We have endpoint base functions
- of_graph_get_next_device_endpoint()
- of_graph_get_device_endpoint_count()
- for_each_of_graph_device_endpoint()
Here, for_each_of_graph_device_endpoint() loop finds each endpoints
ports {
port@0 {
(1)
Hi Rob, Saravana, Tomi, Laurent, Sakari
This is v4 patch-set
Current Of-graph has "endpoint base" for loop, but doesn't have
"port base" loop. "endpoint base" loop only is not enough.
This patch-set add new "port base" for loop, and use it.
v3 -> v4
- new for_each loop includes __free(
On 28/8/24 12:37, Dave Airlie wrote:
From: Dave Airlie
This aligns with what open gpu does, the 0x15 hex is just to trick you.
Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM")
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/fwsec.c | 2 +-
To prevent erros from occurring when the src string is longer than the
dst string in strcpy(), we should use strscpy() instead. This
approach also facilitates future extensions to the task comm.
Signed-off-by: Yafang Shao
Acked-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thom
To prevent errors from occurring when the src string is longer than the dst
string in strcpy(), we should use strscpy() instead. This approach
also facilitates future extensions to the task comm.
Signed-off-by: Yafang Shao
Cc: "David S. Miller"
Cc: David Ahern
Cc: Eric Dumazet
Cc: Jakub Kicins
These three functions follow the same pattern. To deduplicate the code,
let's introduce a common helper __kmemdup_nul().
Suggested-by: Andrew Morton
Signed-off-by: Yafang Shao
Cc: Simon Horman
Cc: Matthew Wilcox
Cc: Alejandro Colomar
---
mm/util.c | 68 ++-
In kstrdup(), it is critical to ensure that the dest string is always
NUL-terminated. However, potential race condidtion can occur between a
writer and a reader.
Consider the following scenario involving task->comm:
readerwriter
len = strlen(s) + 1;
Let's explicitly ensure the destination string is NUL-terminated. This way,
it won't be affected by changes to the source string.
Signed-off-by: Yafang Shao
Reviewed-by: Quentin Monnet
---
tools/bpf/bpftool/pids.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/bpf/bpftool/pids.c b/
Quoted from Linus [0]:
selinux never wanted a lock, and never wanted any kind of *consistent*
result, it just wanted a *stable* result.
Using get_task_comm() to read the task comm ensures that the name is
always NUL-terminated, regardless of the source string. This approach also
facilitates f
Using strscpy() to read the task comm ensures that the name is
always NUL-terminated, regardless of the source string. This approach also
facilitates future extensions to the task comm.
Signed-off-by: Yafang Shao
Acked-by: Paul Moore
Cc: Eric Paris
---
kernel/auditsc.c | 6 +++---
1 file chang
We want to eliminate the use of __get_task_comm() for the following
reasons:
- The task_lock() is unnecessary
Quoted from Linus [0]:
: Since user space can randomly change their names anyway, using locking
: was always wrong for readers (for writers it probably does make sense
: to have so
Using {memcpy,strncpy,strcpy,kstrdup} to copy the task comm relies on the
length of task comm. Changes in the task comm could result in a destination
string that is overflow. Therefore, we should explicitly ensure the
destination string is always NUL-terminated, regardless of the task comm.
This ap
Migration is implemented with range granularity, with VRAM backing being
a VM private TTM BO (i.e., shares dma-resv with VM). The lifetime of the
TTM BO is limited to when the SVM range is in VRAM (i.e., when a VRAM
SVM range is migrated to SRAM, the TTM BO is destroyed).
The design choice for usi
Add XE_BO_FLAG_SYSTEM_ALLOC to indicate BO is tied to SVM range.
Add XE_BO_FLAG_SKIP_CLEAR to indicate BO does not need to cleared.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_bo.c | 11 +++
drivers/gpu/drm/xe/xe_bo.h | 2 ++
2 files changed, 9 insertions(+), 4 deletions(-)
Useful to experiment with notifier size and how it affects performance.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_module.c | 4
drivers/gpu/drm/xe/xe_module.h | 1 +
drivers/gpu/drm/xe/xe_svm.c| 5 +++--
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers
uAPI is designed with the the use case that only mapping a BO to a
malloc'd address will unbind a system allocator VMA. Thus it doesn't
make tons of sense to allow a system allocator VMA unbind if the GPU has
bindings in the range being unbound. Do not support this as it
simplifies the code. Can al
Useful to experiment with SVM prefault and how it affects performance.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_module.c | 3 +++
drivers/gpu/drm/xe/xe_module.h | 1 +
drivers/gpu/drm/xe/xe_svm.c| 2 ++
3 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_module
Add (re)bind to SVM page fault handler. To facilitate add support
function to VM layer which (re)binds a SVM range. Also teach PT layer to
understand (re)binds of SVM ranges.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_pt.c | 140 +++
drivers/gpu/drm/
Add some useful SVM debug logging.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_pt.c | 13 --
drivers/gpu/drm/xe/xe_svm.c | 93 -
drivers/gpu/drm/xe/xe_svm.h | 2 +
3 files changed, 93 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/dr
Wire xe_bo_move to GPUSVM migration to SRAM with trylocking of mmap
lock.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_bo.c | 35 +++-
drivers/gpu/drm/xe/xe_bo_types.h | 3 +++
drivers/gpu/drm/xe/xe_svm.c | 2 ++
drivers/gpu/drm/xe/xe_svm.h
Let's make sure we know what we are doing and check to ensure all pages
are migrated upon eviction.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/drm_gpusvm.c | 39 +
1 file changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/xe/drm_gpusvm.c b/drivers/gp
Kinda cheating here using BO directly rather than VRAM pages. Same at
the moment as mixed mappings are not supported. If this changes, then
the arary of pages / dma addresses will need a cursor.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_pt.c | 22 --
drivers/gpu
This patch introduces support for GPU Shared Virtual Memory (SVM) in the
Direct Rendering Manager (DRM) subsystem. SVM allows for seamless
sharing of memory between the CPU and GPU, enhancing performance and
flexibility in GPU computing tasks.
The patch adds the necessary infrastructure for SVM, i
Add basic SVM garbage collector which can destroy an SVM range upon an
MMU UNMAP event.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_svm.c | 85 +++-
drivers/gpu/drm/xe/xe_svm.h | 1 +
drivers/gpu/drm/xe/xe_vm.c | 6 +++
drivers/gpu/drm/xe/
Add SVM range invalidation vfunc.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_gt_pagefault.c | 17 ++-
drivers/gpu/drm/xe/xe_pt.c | 24
drivers/gpu/drm/xe/xe_pt.h | 3 +
drivers/gpu/drm/xe/xe_svm.c | 201 ++-
drivers/gpu/dr
Support for system allocator bindings in SRAM fully in place, enable the
implementation.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_vm.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
index d9bff07ef8d1..f7dc681a8b0e 1
Add SVM init / fini to faulting VMs. Minimual implementation.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/Makefile | 1 +
drivers/gpu/drm/xe/xe_svm.c | 40
drivers/gpu/drm/xe/xe_svm.h | 14 +++
drivers/gpu/drm/xe/xe_vm.c | 10
Add DRM_GPUVA_OP_USER which allows driver to define their own gpuvm ops.
Cc: Danilo Krummrich
Signed-off-by: Matthew Brost
---
include/drm/drm_gpuvm.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/drm/drm_gpuvm.h b/include/drm/drm_gpuvm.h
index 00d4e43b76b6..cc3f8ed5113b 1006
Add functions which migrate to / from VRAM accepting a single DPA
argument (VRAM) and array of dma addresses (SRAM).
Signed-off-by: Oak Zeng
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_migrate.c | 150
drivers/gpu/drm/xe/xe_migrate.h | 10 +++
2 file
Add the DRM_XE_VM_BIND_FLAG_SYSTEM_ALLOCATOR flag, which is used to
create unpopulated virtual memory areas (VMAs) without memory backing or
GPU page tables. These VMAs are referred to as system allocator VMAs.
The idea is that upon a page fault or prefetch, the memory backing and
GPU page tables w
Add unbind to SVM garbage collector. To facilitate add unbind support
function to VM layer which unbinds a SVM range. Also teach PY layer to
understand unbinds of SVM ranges.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_pt.c | 84 ++--
drivers/gpu/drm/
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_svm.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_svm.c b/drivers/gpu/drm/xe/xe_svm.c
index 6c690ba827e7..82cb5a260c87 100644
--- a
Add SVM device memory mirroring which enables device pages for
migration.
TODO: Hide this behind Kconfig
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_device_types.h | 8
drivers/gpu/drm/xe/xe_svm.c | 56 +
Implement with a simple BO put.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_svm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_svm.c b/drivers/gpu/drm/xe/xe_svm.c
index 82cb5a260c87..4372c02a341f 100644
--- a/drivers/gpu/drm/xe/xe_svm.c
+++ b/driver
Add GPUSVM copy SRAM / VRAM vfunc functions and connect to migration
layer.
Signed-off-by: Matthew Brost
Me: Fix vram_addr == 0 case
---
drivers/gpu/drm/xe/xe_svm.c | 153
1 file changed, 153 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_svm.c b/drivers/
Useful for SVM ranges in SRAM and programing page tables.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_res_cursor.h | 50 +-
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xe/xe_res_cursor.h
b/drivers/gpu/drm/xe/xe_res_cursor.
TTM doesn't support fair eviction via WW locking, this mitigated in by
using retry loops in exec and preempt rebind worker. Extend this retry
loop to BO allocation. Once TTM supports fair eviction this patch can be
reverted.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_bo.c | 8 +++
Testing on LNL has shown media GT's TLBs need to be invalidated via the
GuC, update PT code appropriately.
v2:
- Do dma_fence_get before first call of invalidation_fence_init (Himal)
- No need to check for valid chain fence (Himal)
v3:
- Use dma-fence-array
Fixes: 3330361543fc ("drm/xe/lnl: Ad
Add migrate_device_vma_range which prepares an array of pre-populated
device pages for migration and issues a MMU invalidation.
Cc: Andrew Morton
Signed-off-by: Matthew Brost
---
include/linux/migrate.h | 3 +++
mm/migrate_device.c | 53 +
2 files ch
Useful to preallocate dma fence array and then arm in path of reclaim or
a dma fence.
v2:
- s/arm/init (Christian)
- Drop !array warn (Christian)
Cc: Sumit Semwal
Cc: Christian König
Signed-off-by: Matthew Brost
---
drivers/dma-buf/dma-fence-array.c | 78 ++-
inc
Continuation of SVM work by Oak Zeng [1][2] based on community feedback.
Introduces GPU SVM layer and new Xe uAPI. Supports GPU page faults for
system allocations (e.g., malloc), runtime allocations (e.g., binding a
BO), migration to and from VRAM, and unified eviction (BO and SVM VRAM
allocations
Dear Miquèl,
Thank you for your reply.
On 2024/8/24 上午 12:26, Miquel Raynal wrote:
Hi,
hpchen0...@gmail.com wrote on Wed, 21 Aug 2024 07:11:31 +:
Add dt-bindings for the Nuvoton MA35 SoC NAND Controller.
Signed-off-by: Hui-Ping Chen
Reviewed-by: Krzysztof Kozlowski
---
.../binding
From: Dave Airlie
This aligns with what open gpu does, the 0x15 hex is just to trick you.
Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM")
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/fwsec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/
On Sun, 25 Aug 2024 04:15:03 + Mina Almasry wrote:
> + /* Assume net_iov are on the preferred node without actually
> + * checking...
> + *
> + * This check is only used to check for recycling memory in the page
> + * pool's fast paths. Currently the only implementation
On Sun, 25 Aug 2024 04:15:02 + Mina Almasry wrote:
> +void net_devmem_free_dmabuf(struct net_iov *niov)
> +{
> + struct net_devmem_dmabuf_binding *binding = net_iov_binding(niov);
> + unsigned long dma_addr = net_devmem_get_dma_addr(niov);
> +
> + if (gen_pool_has_addr(binding->chun
Hi all,
On Mon, 26 Aug 2024 11:10:22 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the amdgpu tree got a conflict in:
>
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>
> between commits:
>
> 537ef0f88897 ("drm/amd/display: use new vblank enable policy for DCN35+")
>
On Sun, 25 Aug 2024 04:15:01 + Mina Almasry wrote:
> +u32 dev_get_min_mp_channel_count(const struct net_device *dev)
> +{
> + u32 i, max = 0;
> +
> + ASSERT_RTNL();
> +
> + for (i = 0; i < dev->real_num_rx_queues; i++)
> + if (dev->_rx[i].mp_params.mp_priv)
> +
On Mon, 26 Aug 2024 10:30:54 +0800 Yafang Shao wrote:
> Hello Andrew,
>
> Could you please apply this series to the mm tree ?
Your comment in
https://lkml.kernel.org/r/CALOAHbA5VDjRYcoMOMKcLMVR0=zwtz5fbtvqzexi6w8we9j...@mail.gmail.com
led me to believe that a v8 is to be sent?
Hi Rob
> > And, we still need to consider about of_fwnode_graph_get_next_endpoint()
> > which is the last user of of_graph_get_next_endpoint()
>
> I missed fwnode_graph_get_next_endpoint() which has lots of users.
> Though almost all of those are just "get the endpoint" and assume
> there is on
On 8/27/24 11:07 PM, Rob Clark wrote:
On Tue, Aug 27, 2024 at 1:25 PM Antonino Maniscalco
wrote:
On 8/27/24 9:48 PM, Akhil P Oommen wrote:
On Fri, Aug 23, 2024 at 10:23:48AM +0100, Connor Abbott wrote:
On Fri, Aug 23, 2024 at 10:21 AM Connor Abbott wrote:
On Thu, Aug 22, 2024 at 9:06 PM A
Hi Biju,
On Tue, Aug 27, 2024 at 04:43:12PM +, Biju Das wrote:
> Hi Laurent and Tomi,
>
> Gentle ping. Are you happy with this patch?
I've sent a pull request last Friday, see
https://lore.kernel.org/r/20240822234445.ga23...@pendragon.ideasonboard.com
> > -Original Message-
> > From
Hi Biju,
Thank you for the patch.
On Tue, Aug 27, 2024 at 05:37:24PM +0100, Biju Das wrote:
> Add Kconfig dependency between RZG2L_DU and RZG2L_MIPI_DSI, so that
> DSI module has functional dependency on DU. It is similar way that
> the R-Car MIPI DSI encoder is handled.
>
> While at it drop ARC
On Tue, Aug 20, 2024 at 12:09 AM Vignesh Raman
wrote:
>
> Set the timeout of all drm-ci jobs to 1h30m since
> some jobs takes more than 1 hour to complete.
>
> Signed-off-by: Vignesh Raman
Acked-by: Rob Clark
> ---
> drivers/gpu/drm/ci/test.yml | 5 -
> 1 file changed, 4 insertions(+), 1
On Tue, Aug 27, 2024 at 1:25 PM Antonino Maniscalco
wrote:
>
> On 8/27/24 9:48 PM, Akhil P Oommen wrote:
> > On Fri, Aug 23, 2024 at 10:23:48AM +0100, Connor Abbott wrote:
> >> On Fri, Aug 23, 2024 at 10:21 AM Connor Abbott wrote:
> >>>
> >>> On Thu, Aug 22, 2024 at 9:06 PM Akhil P Oommen
> >>>
On 6/26/2024 2:46 PM, Dmitry Baryshkov wrote:
Max upscale / downscale factors are constant between platforms. In
preparation to adding support for virtual planes and allocating SSPP
blocks on demand move max scaling factors out of the HW catalog and
handle them in the dpu_plane directly. If an
On Tue, 27 Aug 2024 14:09:05 +0200, Thomas Zimmermann wrote:
> Setting 'nomodeset' on the kernel command line disables all graphics
> drivers with modesetting capabilities, leaving only firmware drivers,
> such as simpledrm or efifb.
>
> Most DRM drivers automatically support 'nomodeset' via DRM
On 6/26/2024 2:45 PM, Dmitry Baryshkov wrote:
In preparation for virtualized planes support, move pstate->pipe
initialization from dpu_plane_reset() to dpu_plane_atomic_check(). In
case of virtual planes the plane's pipe will not be known up to the
point of atomic_check() callback.
Signed-off
On 7/16/2024 4:06 PM, Dmitry Baryshkov wrote:
On Wed, 17 Jul 2024 at 01:40, Abhinav Kumar wrote:
On 6/24/2024 2:13 PM, Dmitry Baryshkov wrote:
Historically CRTC resources (LMs and CTLs) were assigned in
dpu_crtc_atomic_begin(). The commit 9222cdd27e82 ("drm/msm/dpu: move hw
resource trac
On Tue, 20 Aug 2024 04:08:16 -0300 Vignesh Raman wrote ---
> Set the timeout of all drm-ci jobs to 1h30m since
> some jobs takes more than 1 hour to complete.
>
> Signed-off-by: Vignesh Raman vignesh.ra...@collabora.com>
Acked-by: Helen Koike
Thanks
Helen
> ---
> driver
On 8/27/24 9:48 PM, Akhil P Oommen wrote:
On Fri, Aug 23, 2024 at 10:23:48AM +0100, Connor Abbott wrote:
On Fri, Aug 23, 2024 at 10:21 AM Connor Abbott wrote:
On Thu, Aug 22, 2024 at 9:06 PM Akhil P Oommen wrote:
On Wed, Aug 21, 2024 at 05:02:56PM +0100, Connor Abbott wrote:
On Mon, Aug 1
resending with updated Konrad email addr
On Mon, Aug 26, 2024 at 2:09 PM Rob Clark wrote:
>
> On Mon, Aug 26, 2024 at 2:07 PM Rob Clark wrote:
> >
> > On Fri, Jul 19, 2024 at 3:03 AM Konrad Dybcio
> > wrote:
> > >
> > > This was apparently almost never set on a6xx.. move the existing values
>
On Fri, Aug 23, 2024 at 10:23:48AM +0100, Connor Abbott wrote:
> On Fri, Aug 23, 2024 at 10:21 AM Connor Abbott wrote:
> >
> > On Thu, Aug 22, 2024 at 9:06 PM Akhil P Oommen
> > wrote:
> > >
> > > On Wed, Aug 21, 2024 at 05:02:56PM +0100, Connor Abbott wrote:
> > > > On Mon, Aug 19, 2024 at 9:09
On 8/27/24 00:20, Heiko Stübner wrote:
Hi Guenter,
Am Samstag, 24. August 2024, 18:44:29 CEST schrieb Guenter Roeck:
On Fri, Aug 23, 2024 at 10:52:36AM -0400, Detlev Casanova wrote:
It is compatible with the other rockchip SoCs.
Signed-off-by: Detlev Casanova
Acked-by: Guenter Roeck
For
Hi,
On Tue, Aug 27, 2024 at 9:26 AM wrote:
>
> On 27/08/2024 17:36, Doug Anderson wrote:
> > Hi,
> >
> > On Mon, Jul 22, 2024 at 8:49 AM Doug Anderson wrote:
> >>
> >> Hi,
> >>
> >> On Mon, Jul 15, 2024 at 6:51 AM Doug Anderson
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Mon, Jul 15, 2024 at 6:
Hi,
On Sat, Aug 24, 2024 at 1:44 AM Tejas Vipin wrote:
>
> +static void nt35950_set_cmd2_page(struct mipi_dsi_multi_context *dsi_ctx,
> + struct nt35950 *nt, u8 page)
> {
> const u8 mauc_cmd2_page[] = { MCS_CMD_MAUCCTR, 0x55, 0xaa, 0x52,
>
On 22/08/24 11:27, Kees Cook wrote:
On Wed, Aug 21, 2024 at 02:16:21PM -0600, Gustavo A. R. Silva wrote:
Use the `DEFINE_RAW_FLEX()` helper for an on-stack definition of
a flexible structure where the size of the flexible-array member
is known at compile-time, and refactor the rest of the cod
On Tue, Aug 27, 2024 at 12:58 PM Daniel Vetter wrote:
>
> [machine died, new one working now, I can read complicated mails again an
> answer.]
>
> On Thu, Aug 22, 2024 at 03:19:29PM +0200, Christian König wrote:
> > Am 22.08.24 um 11:23 schrieb Daniel Vetter:
> > > On Wed, Aug 21, 2024 at 10:14:34
From: Rob Clark
In the case of iova fault triggered devcore dumps, include additional
debug information based on what we think is the current page tables,
including the TTBR0 value (which should match what we have in
adreno_smmu_fault_info unless things have gone horribly wrong), and
the pagetabl
From: Rob Clark
This series extends io-pgtable-arm with a method to retrieve the page
table entries traversed in the process of address translation, and then
beefs up drm/msm gpu devcore dump to include this (and additional info)
in the devcore dump.
This is a respin of https://patchwork.freedes
On Tue, Aug 27, 2024 at 06:52:13PM +0200, Daniel Vetter wrote:
> On Thu, Aug 22, 2024 at 03:19:29PM +0200, Christian König wrote:
> > Completely agree that this is complicated, but I still don't see the need
> > for it.
> >
> > Drivers just need to use pm_runtime_get_if_in_use() inside the shrinke
On 8/27/2024 9:53 AM, Sherry Yang wrote:
The following build error was triggered because of NULL string argument:
BUILDSTDERR: drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c: In function
'mdp5_smp_dump':
BUILDSTDERR: drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c:352:51: error: '%s'
directive argument
Le 19/08/24 - 16:56, Harry Wentland a écrit :
[...]
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 3d6785d081f2..3ecda70c2b55 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -435,3 +435,7
Le 19/08/24 - 16:56, Harry Wentland a écrit :
[...]
> +#ifndef __DRM_COLOROP_H__
> +#define __DRM_COLOROP_H__
> +
> +#include
> +#include
> +#include
> +
> +/**
> + * struct drm_colorop_state - mutable colorop state
> + */
> +struct drm_colorop_state {
> + /** @colorop: backpointer to the
Le 19/08/24 - 16:56, Harry Wentland a écrit :
> We add two 3x4 matrices into the VKMS color pipeline. The reason
> we're adding matrices is so that we can test that application
> of a matrix and its inverse yields an output equal to the input
> image.
>
> One complication with the matrix implement
Le 19/08/24 - 16:57, Harry Wentland a écrit :
> Not all HW will be able to do bypass on all color
> operations. Introduce an 'allow_bypass' boolean for
> all colorop init functions and only create the BYPASS
> property when it's true.
You did not change the documentation of struct drm_colorop_stat
Le 19/08/24 - 16:56, Harry Wentland a écrit :
> +static int vkms_initialize_color_pipeline(struct drm_plane *plane, struct
> drm_prop_enum_list *list)
> +{
> +
> + struct drm_colorop *op, *prev_op;
> + struct drm_device *dev = plane->dev;
> + int ret;
> +
> + /* 1st op: 1d curve *
Le 19/08/24 - 16:56, Harry Wentland a écrit :
> Certain operations require us to preserve values below 0.0 and
> above 1.0 (0x0 and 0x respectively in 16 bpc unorm). One
> such operation is a BT709 encoding operation followed by its
> decoding operation, or the reverse.
>
> We'll use s32 value
Le 19/08/24 - 16:56, Harry Wentland a écrit :
> fixp2int always rounds down, fixp2int_ceil rounds up. We need
> the new fixp2int_round.
>
> Signed-off-by: Harry Wentland
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers
Le 19/08/24 - 16:56, Harry Wentland a écrit :
> This is an RFC set for a color pipeline API, along with implementations
> in VKMS and amdgpu. It is tested with a set of IGT tests that can be
> found at [1]. The IGT tests run a pixel-by-pixel comparison with an
> allowable delta variation as the goa
Hi Louis,
> Add documentation around vkms_output and its initialization.
>
> Signed-off-by: Louis Chauvet
> ---
> This series does not introduce functionnal changes, only some
> documentation and renaming to clarify the code.
> ---
> Changes in v2:
> - Dropped already applied patches
> - Dropped
On Mon, Aug 26, 2024 at 02:25:41PM +0200, Christian König wrote:
> That would be rather nice to have and the kernel side is really trivial,
> only the userspace side might be a bit more complex.
>
> Signed-off-by: Christian König
I think patch 1 should ideally have acks from a few drivers using
On Fri, Aug 23, 2024 at 03:08:55PM +0200, Andi Shyti wrote:
> Create the 'ccs_mode' file under
>
> /sys/class/drm/cardX/gt/gt0/ccs_mode
>
> This file allows the user to read and set the current CCS mode.
>
> - Reading: The user can read the current CCS mode, which can be
>1, 2, or 4. This v
On Mon, Aug 26, 2024 at 11:39:17AM +0200, Philipp Stanner wrote:
> The GPU Scheduler's job initialization is split into two steps,
> drm_sched_job_init() and drm_sched_job_arm(). One reason for this is
> that actually arming a job results in the job's fences getting
> initialized (armed).
>
> Curr
On Fri, Aug 23, 2024 at 03:08:40PM +0200, Andi Shyti wrote:
> Hi,
>
> This patch series introduces static load balancing for GPUs with
> multiple compute engines. It's a lengthy series, and some
> challenging aspects still need to be resolved.
Do we have an actual user for this, where just reload
On Fri, Aug 23, 2024 at 03:46:05PM +, Matthew Brost wrote:
> On Fri, Aug 23, 2024 at 08:37:30AM +0200, Christian König wrote:
> > Am 23.08.24 um 06:54 schrieb Matthew Brost:
> > > Useful to preallocate dma fence array and then arm in path of reclaim or
> > > a dma fence.
> >
> > Exactly that w
On Mon, Aug 19, 2024 at 01:31:40PM +0200, Andi Shyti wrote:
> The i915 driver generates sysfs entries for each engine of the
> GPU in /sys/class/drm/cardX/engines/.
>
> The process is straightforward: we loop over the UABI engines and
> for each one, we:
>
> - Create the object.
> - Create basi
On Thu, Aug 22, 2024 at 11:29:24AM +0200, Christian König wrote:
> Am 22.08.24 um 10:21 schrieb Thomas Hellström:
> > On Thu, 2024-08-22 at 09:55 +0200, Christian König wrote:
> > > In my opinion device drivers should *never* resume runtime PM in a
> > > shrinker callback in the first place.
> > Ru
[machine died, new one working now, I can read complicated mails again an
answer.]
On Thu, Aug 22, 2024 at 03:19:29PM +0200, Christian König wrote:
> Am 22.08.24 um 11:23 schrieb Daniel Vetter:
> > On Wed, Aug 21, 2024 at 10:14:34AM +0200, Christian König wrote:
> > > Am 20.08.24 um 18:00 schrieb
Hi Laurent and Tomi,
Gentle ping. Are you happy with this patch?
Cheers,
Biju
> -Original Message-
> From: Laurent Pinchart
> Sent: Monday, December 18, 2023 10:39 AM
> Subject: Re: [PATCH v2] drm: rcar-du: Fix memory leak in rcar_du_vsps_init()
>
> Hi Biju,
>
> Thank you for the patc
1 - 100 of 181 matches
Mail list logo
