On Thu, 15 May 2025 16:44:47 +
Zhi Wang wrote:
> On 15.5.2025 13.29, Alexey Kardashevskiy wrote:
> >
> >
> > On 13/5/25 20:03, Zhi Wang wrote:
> >> On Mon, 12 May 2025 11:06:17 -0300
> >> Jason Gunthorpe wrote:
> >>
> >>> On Mon, May 12, 2025 at 07:30:21PM +1000, Alexey Kardashevskiy
> >>>
On Thu, May 15, 2025 at 12:15 PM Rob Clark wrote:
>
> On Thu, May 15, 2025 at 2:28 AM Philipp Stanner wrote:
> >
> > Hello,
> >
> > On Wed, 2025-05-14 at 09:59 -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > Similar to the existing credit limit mechanism, but applying to jobs
> > > enq
Hi,
On Thu, 15 May 2025 at 15:11, Harry Wentland wrote:
> On 2025-05-15 05:45, Simon Ser wrote:
> > I've reviewed all of the core DRM patches :)
> >
> > Have there been updates from user-space implementations?
>
> I know Leandro has been working on Weston to make use of
> this and last year Xaver
On 5/15/25 6:21 PM, Dmitry Baryshkov wrote:
> On 15/05/2025 19:18, Konrad Dybcio wrote:
>> On 5/14/25 10:33 PM, Dmitry Baryshkov wrote:
>>> On 14/05/2025 23:05, Konrad Dybcio wrote:
On 5/14/25 9:23 PM, Dmitry Baryshkov wrote:
> On Wed, May 14, 2025 at 05:10:33PM +0200, Konrad Dybcio wrote:
On 15.5.2025 13.29, Alexey Kardashevskiy wrote:
>
>
> On 13/5/25 20:03, Zhi Wang wrote:
>> On Mon, 12 May 2025 11:06:17 -0300
>> Jason Gunthorpe wrote:
>>
>>> On Mon, May 12, 2025 at 07:30:21PM +1000, Alexey Kardashevskiy wrote:
>>>
>> I'm surprised by this.. iommufd shouldn't be doing PCI s
On 5/14/2025 5:21 PM, Dmitry Baryshkov wrote:
On Wed, May 14, 2025 at 04:52:30PM -0700, Jessica Zhang wrote:
Add max_dsc_encoder_width to dpu_caps struct and max_linewidth to
dpu_pingpong_cfg for all chipsets within the HW catalog.
Note: The max supported PINGPONG width was 4096 but increase
On Thu, May 15, 2025 at 09:15:08AM -0700, Rob Clark wrote:
> Basically it is a way to throttle userspace to prevent it from OoM'ing
> itself. (I suppose userspace could throttle itself, but it doesn't
> really know how much pre-allocation will need to be done for pgtable
> updates.)
I assume you
On Thu, May 15, 2025 at 8:30 AM Danilo Krummrich wrote:
>
> On Thu, May 15, 2025 at 07:59:16AM -0700, Rob Clark wrote:
>
> Thanks for the detailed explanation!
>
> > On Thu, May 15, 2025 at 2:00 AM Danilo Krummrich wrote:
> > >
> > > On Wed, May 14, 2025 at 10:53:16AM -0700, Rob Clark wrote:
> >
Make use of __free(device_node) to simplify the of_node_put() error
handling paths. No functional changes.
Signed-off-by: Marco Felsch
---
Changelog:
v2:
- drop __free() from panel_node
drivers/gpu/drm/bridge/fsl-ldb.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(
Make use of dev_err_probe() to easily spot issues via the debugfs or
kernel log. No functional changes.
Signed-off-by: Marco Felsch
Reviewed-by: Laurent Pinchart
Reviewed-by: Alexander Stein
---
Changelog:
v2:
- add Laurent's r-b
- add Alexander's r-b
drivers/gpu/drm/bridge/fsl-ldb.c | 19 +
On Thu, May 15, 2025 at 10:23 AM Danilo Krummrich wrote:
>
> On Thu, May 15, 2025 at 09:15:08AM -0700, Rob Clark wrote:
> > Basically it is a way to throttle userspace to prevent it from OoM'ing
> > itself. (I suppose userspace could throttle itself, but it doesn't
> > really know how much pre-al
Hi,
just a small series to cleanup the fsl-ldb lvds bridge driver a bit.
Regards,
Marco
Marco Felsch (2):
drm/bridge: fsl-ldb: make use of dev_err_probe
drm/bridge: fsl-ldb: simplify device_node error handling
drivers/gpu/drm/bridge/fsl-ldb.c | 41 ++--
1 file c
(Cc: Boris)
On Thu, May 15, 2025 at 12:22:18PM -0400, Connor Abbott wrote:
> For some context, other drivers have the concept of a "synchronous"
> VM_BIND ioctl which completes immediately, and drivers implement it by
> waiting for the whole thing to finish before returning.
Nouveau implements sy
On Thu, May 15, 2025 at 2:06 AM Danilo Krummrich wrote:
>
> On Thu, May 15, 2025 at 10:54:27AM +0200, Danilo Krummrich wrote:
> > Hi Rob,
> >
> > Can you please CC me on patches for GPUVM?
> >
> > On Wed, May 14, 2025 at 10:53:15AM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > See com
On Thu, May 15, 2025 at 10:30 AM Danilo Krummrich wrote:
>
> (Cc: Boris)
>
> On Thu, May 15, 2025 at 12:22:18PM -0400, Connor Abbott wrote:
> > For some context, other drivers have the concept of a "synchronous"
> > VM_BIND ioctl which completes immediately, and drivers implement it by
> > waiting
On Thu, May 15, 2025 at 10:34:07AM -0700, Rob Clark wrote:
> On Thu, May 15, 2025 at 8:30 AM Danilo Krummrich wrote:
> >
> > On Thu, May 15, 2025 at 07:59:16AM -0700, Rob Clark wrote:
> >
> > Thanks for the detailed explanation!
> >
> > > On Thu, May 15, 2025 at 2:00 AM Danilo Krummrich wrote:
>
On Thu, May 15, 2025 at 10:35:21AM -0700, Rob Clark wrote:
> On Thu, May 15, 2025 at 2:06 AM Danilo Krummrich wrote:
> >
> > On Thu, May 15, 2025 at 10:54:27AM +0200, Danilo Krummrich wrote:
> > > Hi Rob,
> > >
> > > Can you please CC me on patches for GPUVM?
> > >
> > > On Wed, May 14, 2025 at 10
On 5/15/25 7:15 PM, Dmitry Baryshkov wrote:
> On Thu, 15 May 2025 at 19:36, Konrad Dybcio
> wrote:
>>
>> On 5/15/25 6:21 PM, Dmitry Baryshkov wrote:
>>> On 15/05/2025 19:18, Konrad Dybcio wrote:
On 5/14/25 10:33 PM, Dmitry Baryshkov wrote:
> On 14/05/2025 23:05, Konrad Dybcio wrote:
>
On Fri, May 16, 2025 at 12:04:04AM +0800, Xu Yilun wrote:
> > arches this was mostly invisible to the hypervisor?
>
> Attest & Accept can be invisible to hypervisor, or host just help pass
> data blobs between guest, firmware & device.
>
> Bind cannot be host agnostic, host should be aware not to
On 15/05/2025 20:56, Konrad Dybcio wrote:
On 5/15/25 7:15 PM, Dmitry Baryshkov wrote:
On Thu, 15 May 2025 at 19:36, Konrad Dybcio
wrote:
On 5/15/25 6:21 PM, Dmitry Baryshkov wrote:
On 15/05/2025 19:18, Konrad Dybcio wrote:
On 5/14/25 10:33 PM, Dmitry Baryshkov wrote:
On 14/05/2025 23:05, K
Hi Steven,
thanks for the bisect.
In order to avoid display artifacts (especially for HDR) we had to
allow higher bit depth color output on the wire. The driver should
fallback to a lower resolution as needed but looks like there's a
bug with this particular TV. Are you able to share the specific
Hi Steven,
On Thu, 8 May 2025 at 11:42, Steven Price wrote:
> I'm also seeing a splat when running this, see below. I haven't got my
> head around how this is happening, but I see it when glmark quits at the
> end of the test.
>
> [ 399.505066] Unable to handle kernel NULL pointer dereference at
> IMHO, I think it might be helpful that you can picture out what are the
> minimum requirements (function/life cycle) to the current IOMMUFD TSM
> bind architecture:
>
> 1.host tsm_bind (preparation) is in IOMMUFD, triggered by QEMU handling
> the TVM-HOST call.
> 2. TDI acceptance is handled in
On Thu, May 15, 2025 at 03:26:13PM +0900, Alexandre Courbot wrote:
> CONFIG_AUXILIARY_BUS cannot be enabled explicitly, and unless we select
> it we have no way to include it (and thus to enable the auxiliary driver
> sample) unless a driver happens to do it for us.
>
> Signed-off-by: Alexandre Co
On Wed, May 14, 2025 at 10:53:19AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> In situations where mapping/unmapping sequence can be controlled by
> userspace, attempting to map over a region that has not yet been
> unmapped is an error. But not something that should spam dmesg.
>
> Now that
On Thu, 15 May 2025 at 19:36, Konrad Dybcio
wrote:
>
> On 5/15/25 6:21 PM, Dmitry Baryshkov wrote:
> > On 15/05/2025 19:18, Konrad Dybcio wrote:
> >> On 5/14/25 10:33 PM, Dmitry Baryshkov wrote:
> >>> On 14/05/2025 23:05, Konrad Dybcio wrote:
> On 5/14/25 9:23 PM, Dmitry Baryshkov wrote:
> >>
On Sun, May 11, 2025 at 6:42 PM Ryan Walklin wrote:
>
> The Allwinner H616 and variants have a new display engine revision
> (DE33).
>
> Add a display engine bus binding for the DE33.
>
> Signed-off-by: Ryan Walklin
> Acked-by: Conor Dooley
> Reviewed-by: Chen-Yu Tsai
> Signed-off-by: Chris Mor
On Thu May 15, 2025 at 3:26 PM JST, Alexandre Courbot wrote:
> I noticed this after trying to understand why my minimal Nova defconfig
> was not selecting NOVA_CORE anymore and why I couldn't even find it in
> menuconfig.
>
> CONFIG_AUXILIARY_BUS cannot be enabled directly and must be selected by
>
CONFIG_AUXILIARY_BUS cannot be enabled explicitly, and unless we select
it we have no way to include it (and thus to enable NOVA_CORE) unless
another driver happens to do it for us.
Fixes: e041d81a0377 ("gpu: nova-core: register auxiliary device for nova-drm")
Signed-off-by: Alexandre Courbot
---
CONFIG_AUXILIARY_BUS cannot be enabled explicitly, and unless we select
it we have no way to include it (and thus to enable NOVA_DRM) unless
another driver happens to do it for us.
Fixes: cdeaeb9dd762 ("drm: nova-drm: add initial driver skeleton")
Signed-off-by: Alexandre Courbot
---
drivers/gpu
fixes into the original patches if you think
it makes more sense.
Signed-off-by: Alexandre Courbot
---
Changes in v2:
- Added missing Fixes: tags.
- Collected Reviewed-by: tag.
- Link to v1:
https://lore.kernel.org/r/20250515-aux_bus-v1-0-1781b5442...@nvidia.com
---
Alexandre Courbot (3):
sa
CONFIG_AUXILIARY_BUS cannot be enabled explicitly, and unless we select
it we have no way to include it (and thus to enable the auxiliary driver
sample) unless a driver happens to do it for us.
Fixes: 96609a1969f4 ("samples: rust: add Rust auxiliary driver sample")
Reviewed-by: Greg Kroah-Hartman
Hi Dave & Sima,
Here goes the drm-intel-next-fixes PR for this week.
Just one MST fix and one PSR fix this round.
The CI results for drm-intel-next-fixes are bit all over the place after -rc1,
before further rc backmerges.
Regards, Joonas
***
drm-intel-next-fixes-2025-05-15:
- Stop writing A
On Wed, May 14, 2025 at 7:50 PM Nicolas Frattaroli
wrote:
>
> On Wednesday, 14 May 2025 17:18:22 Central European Summer Time Tomeu Vizoso
> wrote:
> > Hi Nicolas,
> >
> > Thanks for looking at this. Some thoughts below:
> >
> > On Fri, Apr 25, 2025 at 8:50 PM Nicolas Frattaroli
> > wrote:
> > >
On Tue, Apr 15, 2025 at 01:22:14PM +0200, Luca Ceresoli wrote:
> > > +/*
> > > + * Mimick the typical struct defined by a bridge driver, which embeds a
> > > + * bridge plus other fields.
> > > + */
> > > +struct dummy_drm_bridge {
> > > + int dummy; // ensure we test non-zero @bridge offset
> > >
On 5/14/25 19:07, Maarten Lankhorst wrote:
> Hey,
>
> On 2025-05-14 13:55, Christian König wrote:
>> On 5/14/25 13:41, Maarten Lankhorst wrote:
>>> Hi Dave,
>>>
>>> We've had a small discussion on irc, so I wanted to summarize it here:
>>>
>>> All memory allocated should be accounted, even memory
Hi Rob,
Can you please CC me on patches for GPUVM?
On Wed, May 14, 2025 at 10:53:15AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> See commit a414fe3a2129 ("drm/msm/gem: Drop obj lock in
> msm_gem_free_object()") for justification.
Please write a proper commit message that explains the proble
On 5/15/25 05:02, Dave Airlie wrote:
>> I have to admit I'm pretty clueless about the gpu driver internals and
>> can't really judge how feasible this is. But from a cgroup POV, if you
>> want proper memory isolation between groups, it seems to me that's the
>> direction you'd have to take this in.
Explicitly adding the scheduler maintainers.
On 5/15/25 04:07, Lin.Cao wrote:
> Previously we only signaled finished fence which may cause some
> submission's dependency cannot be cleared the cause benchmark hang.
> Signal both scheduled fence and finished fence could fix this issue.
>
> Signed-o
On Wed, May 14, 2025 at 10:53:16AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Eases migration for drivers where VAs don't hold hard references to
> their associated BO, avoiding reference loops.
>
> In particular, msm uses soft references to optimistically keep around
> mappings until the BO
On Thu, 2025-05-15 at 10:48 +0200, Christian König wrote:
> Explicitly adding the scheduler maintainers.
>
> On 5/15/25 04:07, Lin.Cao wrote:
> > Previously we only signaled finished fence which may cause some
> > submission's dependency cannot be cleared the cause benchmark hang.
> > Signal both
On 5/14/2025 6:55 PM, Sumit Garg wrote:
> Hi Amir,
>
> Apologies for getting to this patch review a bit late, mostly due to
> it's enormous size.
>
> On Mon, Apr 28, 2025 at 11:06:29PM -0700, Amirreza Zarrabi wrote:
>> Introduce qcomtee_object, which represents an object in both QTEE and
>> th
On Thu, May 15, 2025 at 10:54:27AM +0200, Danilo Krummrich wrote:
> Hi Rob,
>
> Can you please CC me on patches for GPUVM?
>
> On Wed, May 14, 2025 at 10:53:15AM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > See commit a414fe3a2129 ("drm/msm/gem: Drop obj lock in
> > msm_gem_free_object()
Hi,
Le 14/05/2025 à 14:44, Philipp Stanner a écrit :
On Thu, 2025-04-24 at 10:38 +0200, Pierre-Eric Pelloux-Prayer wrote:
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
Hello,
On Wed, 2025-05-14 at 09:59 -0700, Rob Clark wrote:
> From: Rob Clark
>
> Similar to the existing credit limit mechanism, but applying to jobs
> enqueued to the scheduler but not yet run.
>
> The use case is to put an upper bound on preallocated, and
> potentially
> unneeded, pgtable pag
Hey,
On 2025-05-15 10:40, Christian König wrote:
> On 5/14/25 19:07, Maarten Lankhorst wrote:
>> Hey,
>>
>> On 2025-05-14 13:55, Christian König wrote:
>>> On 5/14/25 13:41, Maarten Lankhorst wrote:
Hi Dave,
We've had a small discussion on irc, so I wanted to summarize it here:
Reviewed-by: Simon Ser
From: Karol Wachowski
Add new inference_timeout_ms parameter that allows specifying
maximum allowed duration in milliseconds that inference can take before
triggering a recovery.
Calculate maximum number of heartbeat retries based on ratio between
inference timeout and tdr timeout.
Signed-off-b
From: Nancy Lin
Add compatible string to support mutex for MT8196.
Acked-by: Krzysztof Kozlowski
Signed-off-by: Nancy Lin
Signed-off-by: Paul-pl Chen
---
.../devicetree/bindings/soc/mediatek/mediatek,mutex.yaml| 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/device
From: Nancy Lin
- Add initialization of top clocks and async clocks for each MMSYS.
- Add PM runtime control and new functions to manage these clocks.
- Add functions to set these clocks according to the default
configuration of the corresponding MMSYS.
Signed-off-by: Nancy Lin
Signed-off-by:
From: Paul-pl Chen
Add mediatek,exdma.yaml to support EXDMA for MT8196.
The MediaTek display overlap extended DMA engine, namely
OVL_EXDMA or EXDMA, primarily functions as a DMA engine
for reading data from DRAM with various DRAM footprints
and data formats.
Signed-off-by: Nancy Lin
Signed-off-
From: Nancy Lin
Ovlsys_adaptor is an encapsulated module designed to
simplify the DRM control flow. This module is composed
of 20 EXDMAs, 20 BLENDERs, and 12 OUTPROCs.
Two EXDMAs merge into one layer, allowing the module
to support 20 layers for 3 display paths.
Ovlsys_adaptor driver is integrate
From: Paul-pl Chen
Refactor SOF settings by adding mtk_mutex_get_output_comp_sof()
and extracting SOF logic from mtk_mutex_add_comp()
and mtk_mutex_remove_comp().
Signed-off-by: Nancy Lin
Signed-off-by: Paul-pl Chen
---
drivers/soc/mediatek/mtk-mutex.c | 60 +-
i
From: Nancy Lin
OUTPROC handles the post-stage of pixel processing in
the overlapping procedure.OUTPROC manages pixels for
gamma correction and ensures that pixel values are
within the correct range.
Signed-off-by: Nancy Lin
Signed-off-by: Paul-pl Chen
---
drivers/gpu/drm/mediatek/Makefile
From: Nancy Lin
In upcoming SoCs, the OVL component will be divided into multiple
smaller hardware units to enhance flexibility. To facilitate this
transition, the OVL format definitions and format conversion API
should be exported for reuse across these units.
Signed-off-by: Nancy Lin
Signed-o
From: Paul-pl Chen
This patch series adds support for the MediaTek MT8196 SoC's display
subsystem in the DRM driver.
Changes in v3:
- [PATCH v3 06/17]
Refine runtime PM, top clocks and async controls for MMSYS
- [PATCH v3 08/17]
Refactor SOF settings by adding mtk_mutex_get_output_comp_so
Reviewed-by: Simon Ser
From: Nancy Lin
EXDMA is a DMA engine for reading data from DRAM with
various DRAM footprints and data formats. For input
sources in certain color formats and color domains,
EXDMA also includes a color transfer function to
process pixels into a consistent color domain.
New Add: 6320385 Fix RG16 a
From: Nancy Lin
Add code to support MT8196 SOC Multi MMSYS Driver
Signed-off-by: Nancy Lin
Signed-off-by: Paul-pl Chen
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 119 -
1 file changed, 115 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_d
From: Paul-pl Chen
BLENDER executes the alpha blending function for overlapping
layers from different sources, which is the primary function
of the overlapping system.
Signed-off-by: Nancy Lin
Signed-off-by: Paul-pl Chen
---
drivers/gpu/drm/mediatek/Makefile | 1 +
drivers/gpu/drm
From: Paul-pl Chen
Reused the switch case for SOF IDs.
Signed-off-by: Nancy Lin
Signed-off-by: Paul-pl Chen
---
drivers/soc/mediatek/mtk-mutex.c | 81 ++--
1 file changed, 36 insertions(+), 45 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-mutex.c b/drivers/so
From: Paul-pl Chen
To support multiple mmsys instances in the one mediatek-drm instance,
providing improved flexibility and scalability by the following changes:
1. Add DDP_COMPONENT_DRM_OVLSYS_ADAPTOR* to probe the
ovlsys_adaptor drivers and support different mmsys composition.
2. Added new c
> -Original Message-
> From: Christian König
> Sent: Tuesday, May 13, 2025 9:18 PM
> To: wangtao ; sumit.sem...@linaro.org;
> benjamin.gaign...@collabora.com; brian.star...@arm.com;
> jstu...@google.com; tjmerc...@google.com
> Cc: linux-me...@vger.kernel.org; dri-devel@lists.freedesktop.
Reviewed-by: Simon Ser
From: Paul-pl Chen
Add mediatek,blender.yaml to support BLENDER for MT8196.
MediaTek display overlap blender, namely OVL_BLENDER or BLENDER,
executes the alpha blending function for overlapping layers
from different sources.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Nancy Lin
Signed-off
From: Nancy Lin
Add driver data for MT8196 and add the routing table for each mmsys.
Signed-off-by: Nancy Lin
Signed-off-by: Paul-pl Chen
---
drivers/soc/mediatek/mt8196-mmsys.h| 396 +
drivers/soc/mediatek/mtk-mmsys.c | 54
include/linux/soc/mediatek/m
Reviewed-by: Simon Ser
From: Karol Wachowski
Refactor ivpu_cmdq_unregister() to ensure the doorbell is unregistered
before destroying the command queue. The NPU firmware requires doorbells
to be unregistered prior to command queue destruction.
If doorbell remains registered when command queue destroy command is sent
f
From: Nancy Lin
For the new BLENDER component, the OVL ignore pixel alpha logic
should be exported as a function and reused it.
Signed-off-by: Nancy Lin
Signed-off-by: Paul-pl Chen
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 24 ++--
drivers/gpu/drm/mediatek/mtk_disp_ovl
I've reviewed all of the core DRM patches :)
Have there been updates from user-space implementations?
Access the dma-fence internals via the previously added helpers.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Christian König
---
drivers/dma-buf/sync_file.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index
Add some helpers in order to enable preventing dma-fence users accessing
the implementation details directly and make the implementation itself use
them.
This will also enable later adding some asserts to a consolidated
location.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Christian König
---
d
Hi all,
tl;dr;
Xe and probably some other drivers can tear down the internal state referenced
by an exported sync_file fence which then causes a null pointer derefences on
accessing said fence.
IGT that exploits the problem:
https://patchwork.freedesktop.org/patch/642709/?series=146211&rev=2
It
Protect the access to driver and timeline name which otherwise could be
freed as dma-fence exported is signalling fences.
Signed-off-by: Tvrtko Ursulin
---
drivers/dma-buf/sync_file.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_fil
Dma-fence objects currently suffer from a potential use after free problem
where fences exported to userspace and other drivers can outlive the
exporting driver, or the associated data structures.
The discussion on how to address this concluded that adding reference
counting to all the involved ob
With the goal of reducing the need for drivers to touch (and dereference)
fence->ops, we move the 64-bit seqnos flag from struct dma_fence_ops to
the fence->flags.
Drivers which were setting this flag are changed to use new
dma_fence_init64() instead of dma_fence_init().
v2:
* Streamlined init a
Xe can free some of the data pointed to by the dma-fences it exports. Most
notably the timeline name can get freed if userspace closes the associated
submit queue. At the same time the fence could have been exported to a
third party (for example a sync_fence fd) which will then cause an use-
after-
With the goal of reducing the need for drivers to touch (and dereference)
fence->ops, we change the prototype of __dma_fence_is_later() to take
fence instead of fence->ops.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Christian König
---
drivers/dma-buf/dma-fence-chain.c | 2 +-
drivers/dma-buf/
From: Paul-pl Chen
Add mediate,outproc.yaml to support OUTPROC for MT8196.
MediaTek display overlap output processor, namely OVL_OUTPROC
or OUTPROC,handles the post-stage of pixel processing in the
overlapping procedure.
Signed-off-by: Nancy Lin
Signed-off-by: Paul-pl Chen
---
.../display/med
Access the dma-fence internals via the previously added helpers.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Christian König
---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 4 ++--
drivers/gpu/drm/i915/i915_request.c | 2 +-
drivers/gpu/drm/i915/i915_sw_fence.c| 4 ++--
3 files
Protect the access to driver and timeline name which otherwise could be
freed as dma-fence exported is signalling fences.
Now that the safe access is handled in the dma-fence API, the external
callers such as sync_file, and our internal code paths, we can drop the
similar protection from i915_fenc
On Thu, May 15, 2025 at 02:35:34PM +0530, Kuldeep Singh wrote:
>
>
> On 5/14/2025 6:55 PM, Sumit Garg wrote:
> > Hi Amir,
> >
> > Apologies for getting to this patch review a bit late, mostly due to
> > it's enormous size.
> >
> > On Mon, Apr 28, 2025 at 11:06:29PM -0700, Amirreza Zarrabi wrote
From: Nancy Lin
Add mutex support for the main and external displays in MT8196:
- Introduce a new DVO0 output component for the new mutex
settings of MT8196.
- Add a need_sof_mof flag to configure both SOF and MOD settings
for the output component.
Signed-off-by: Nancy Lin
Signed-off-by: Pa
> Subject: Re: [PATCH v9 02/12] mtd: add driver for intel graphics non-volatile
> memory device
>
> On Thu, Apr 24, 2025 at 04:25:26PM +0300, Alexander Usyskin wrote:
> > Add auxiliary driver for intel discrete graphics
> > non-volatile memory device.
>
> ...
>
> > +static int intel_dg_mtd_probe
On 15/05/2025 10:05, Philipp Stanner wrote:
On Thu, 2025-05-15 at 10:48 +0200, Christian König wrote:
Explicitly adding the scheduler maintainers.
On 5/15/25 04:07, Lin.Cao wrote:
Previously we only signaled finished fence which may cause some
submission's dependency cannot be cleared the ca
On 13/5/25 20:03, Zhi Wang wrote:
On Mon, 12 May 2025 11:06:17 -0300
Jason Gunthorpe wrote:
On Mon, May 12, 2025 at 07:30:21PM +1000, Alexey Kardashevskiy wrote:
I'm surprised by this.. iommufd shouldn't be doing PCI stuff,
it is just about managing the translation control of the device.
: edef457004774e598fc4c1b7d1d4f0bcd9d0bb30
patch link:
https://lore.kernel.org/r/20250514-topic-ubwc_central-v2-3-09ecbc0a05ce%40oss.qualcomm.com
patch subject: [PATCH RFT v2 03/15] drm/msm: Use the central UBWC config
database
config: arm64-randconfig-002-20250515
(https://download.01.org/0day-ci/archive/20250515/202505151822
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 correctly.
Signed-off-by: Ashley Smith
---
drivers/g
On Thu, 15 May 2025 17:34:14 +0800, paul-pl.chen wrote:
> From: Paul-pl Chen
>
> Add mediatek,exdma.yaml to support EXDMA for MT8196.
> The MediaTek display overlap extended DMA engine, namely
> OVL_EXDMA or EXDMA, primarily functions as a DMA engine
> for reading data from DRAM with various DR
On Thu, 15 May 2025 11:33:05 +0100
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 t
On Tue, 13 May 2025 16:39:51 -0400
Harry Wentland wrote:
> On 2025-05-13 11:36, Melissa Wen wrote:
> > On 05/13, Pekka Paalanen wrote:
> >> On Mon, 12 May 2025 15:50:17 -0300
> >> Melissa Wen wrote:
> >>
> >>> On 04/29, Alex Hung wrote:
> Expose one 1D curve colorop with support for
>
> Subject: Re: [PATCH v9 03/12] mtd: intel-dg: implement region enumeration
>
> On Thu, Apr 24, 2025 at 04:25:27PM +0300, Alexander Usyskin wrote:
> > In intel-dg, there is no access to the spi controller,
> > the information is extracted from the descriptor region.
>
> ...
>
> > @@ -22,9 +24,19
On Thu, May 15, 2025 at 03:41:08PM +0530, Usyskin, Alexander wrote:
> > On Thu, Apr 24, 2025 at 04:25:26PM +0300, Alexander Usyskin wrote:
> > > Add auxiliary driver for intel discrete graphics
> > > non-volatile memory device.
...
> > > + for (n = 0, i = 0; i < INTEL_DG_NVM_REGIONS; i++) {
> > >
On Thu, May 15, 2025 at 04:53:38PM +0530, Usyskin, Alexander wrote:
> > On Thu, Apr 24, 2025 at 04:25:27PM +0300, Alexander Usyskin wrote:
> > > In intel-dg, there is no access to the spi controller,
> > > the information is extracted from the descriptor region.
> >
> > ...
> >
> > > @@ -22,9 +24
On 5/15/25 11:05, Philipp Stanner wrote:
> On Thu, 2025-05-15 at 10:48 +0200, Christian König wrote:
>> Explicitly adding the scheduler maintainers.
>>
>> On 5/15/25 04:07, Lin.Cao wrote:
>>> Previously we only signaled finished fence which may cause some
>>> submission's dependency cannot be clear
Hi Maxime,
On 5/13/25 4:35 PM, Maxime Ripard wrote:
> Hi,
>
> On Fri, Apr 25, 2025 at 01:26:57PM +0300, Cristian Ciocaltea wrote:
>> Try to make use of YUV420 when computing the best output format and
>> RGB cannot be supported for any of the available color depths.
>>
>> Signed-off-by: Cristian
On 27/04/2025 12:18, Ryosuke Yasuoka wrote:
Drop simple-KMS in favor of regular atomic helpers to make the code more
modular. The simple-KMS helper mix up plane and CRTC state, so it is
obsolete and should go away [1]. Since it just split the simple-pipe
functions into per-plane and per-CRTC, no
Hi,
Am Dienstag, 13. Mai 2025, 03:19:04 Mitteleuropäische Sommerzeit schrieb Chaoyi
Chen:
> From: Chaoyi Chen
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: Input
Hi Dave, Sima,
here's the weekly PR for drm-misc-fixes. The dma-buf fix affects
multiple subsystems.
Best regards
Thomas
drm-misc-fixes-2025-05-15:
Short summary of fixes pull:
dma-buf:
- Avoid memory reordering in fence handling
ivpu:
- Fix buffer size in debugfs code
meson:
- Avoid integer
> Subject: Re: [PATCH v9 03/12] mtd: intel-dg: implement region enumeration
>
> On Thu, May 15, 2025 at 04:53:38PM +0530, Usyskin, Alexander wrote:
> > > On Thu, Apr 24, 2025 at 04:25:27PM +0300, Alexander Usyskin wrote:
> > > > In intel-dg, there is no access to the spi controller,
> > > > the in
1 - 100 of 181 matches
Mail list logo
