Continue migration to the MDSS-revision based checks and replace
DPU_WB_INPUT_CTRL feature bit with the core_major_ver >= 5 check.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Neil Armstrong
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h | 2 +-
dr
On Thu, May 22, 2025 at 1:52 PM Christian König
wrote:
>
> On 5/22/25 08:56, Jens Wiklander wrote:
> > 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 pat
On Thu, 2025-05-22 at 14:34 +0200, Christian König wrote:
> On 5/22/25 14:20, Philipp Stanner wrote:
> > On Thu, 2025-05-22 at 14:06 +0200, Christian König wrote:
> > > On 5/22/25 13:25, Philipp Stanner wrote:
> > > > dma_fence_is_signaled_locked(), which is used in
> > > > nouveau_fence_context_ki
Apologies for interrupting the filesystem/memory experts. Due to dmabuf's
attachment/map/fence model, its mmap callback uses remap_pfn_range, making
read(file_fd, dmabuf_ptr, len) support buffer I/O only, not Direct I/O
zero-copy. Embedded/mobile devices urgently require dmabuf Direct I/O for
large
On 5/22/25 14:42, Philipp Stanner wrote:
> On Thu, 2025-05-22 at 14:34 +0200, Christian König wrote:
>> On 5/22/25 14:20, Philipp Stanner wrote:
>>> On Thu, 2025-05-22 at 14:06 +0200, Christian König wrote:
On 5/22/25 13:25, Philipp Stanner wrote:
> dma_fence_is_signaled_locked(), which is
On 22/05/2025 09:27, Philipp Stanner wrote:
From: Philipp Stanner
The GPU scheduler currently does not ensure that its pending_list is
empty before performing various other teardown tasks in
drm_sched_fini().
If there are still jobs in the pending_list, this is problematic because
after sche
Since we already iterated over the xarray we know at which index the new
entry should be stored. So instead of using xa_alloc use xa_store and
write into the index directly.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 12 ++--
1 file changed, 6 insertions(
Hi guys,
fourth revision of those patches.
Tvrtko got me on another idea how to avoid returning the index of the
reserved slot to the caller. That simplfies the handling quite a bit and
makes the code more resilent to errors.
Please take another look,
Christian.
Just to exercise the functionality.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/tests/tests_basic.c | 56 ++-
1 file changed, 55 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/tests/tests_basic.c
b/drivers/gpu/drm/scheduler/tests/tests_basi
For the unlikely case that we ran into an ENOMEM while fixing up the gang
submission dependencies we can't clean up any more since the gang
members are already armed.
Fix this by using pre-allocated dependency slots and re-ordering the
code, also fix a double unref since the fence reference is als
On Thu, May 22, 2025 at 03:09:49PM +0200, Christian König wrote:
> On 5/22/25 14:59, Danilo Krummrich wrote:
> > On Thu, May 22, 2025 at 02:34:33PM +0200, Christian König wrote:
> >> See all the functions inside include/linux/dma-fence.h can be used by
> >> everybody. It's basically the public int
From: Hugo Villeneuve
Hello,
this patch series add support for sending MIPI DSI command packets to the
Renesas RZ/G2L MIPI DSI driver.
Tested on a custom board with a SolidRun RZ/G2L SOM, with two different LCD
panels using the jd9365da and st7703 drivers.
Tested short and long writes.
Tested
On 5/22/25 15:25, Alex Deucher wrote:
> On Thu, May 15, 2025 at 4:58 AM 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
On Wed, 2025-05-21 at 11:24 +0100, Tvrtko Ursulin wrote:
>
> On 21/05/2025 11:04, Philipp Stanner wrote:
> > When the unit tests were implemented, each scheduler job got its
> > own,
> > distinct lock. This is not how dma_fence context locking rules are
> > to be
> > implemented. All jobs belongin
On 22/05/2025 09:27, Philipp Stanner wrote:
The drm_gpu_scheduler now supports a callback to help drm_sched_fini()
avoid memory leaks. This callback instructs the driver to signal all
pending hardware fences.
Implement the new callback
drm_sched_backend_ops.cancel_pending_fences().
Have the c
Hi,
On 22/05/2025 13:34, Wolfram Sang wrote:
> Not RCAR, but R-Car.
>
> Signed-off-by: Wolfram Sang
> Reviewed-by: Kieran Bingham
> Reviewed-by: Geert Uytterhoeven
> ---
> drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a
On Tue, May 20, 2025 at 02:08:36PM +0200, Maxime Ripard wrote:
> Commit 30188df0c387 ("drm/tests: Drop drm_kunit_helper_acquire_ctx_alloc()")
> removed a kunit-managed function to get a drm_modeset_acquire_ctx.
>
> It converted the vc4_pv_muxing_test_init() function, used by
> drm_vc4_test_pv_muxi
On Thu, May 22, 2025 at 11:20:17AM +0800, Liu Ying wrote:
> >> drm: convert many bridge drivers from devm_kzalloc() to
> >> devm_drm_bridge_alloc() API
> >
> > This patch affects multiple drivers. Running get_maintainers.pl
> > points at Shawn Guo's repository. After reviewing the MAINTAINE
Hello Luca Ceresoli,
2025년 5월 21일 (수) 오후 11:23, Luca Ceresoli 님이 작성:
>
> 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 o
On 22/05/2025 15:50, Lucas De Marchi wrote:
+ dri-devel
On Wed, May 21, 2025 at 10:42:35PM +, Juston Li wrote:
Add tracepoints behind CONFIG_DRM_XE_GPU_MEM_TRACEPOINTS for tracking
global and per-process GPU memory usage.
These are required by VSR on Android 12+ for reporting GPU driver
On Thu, May 22, 2025 at 04:52:18PM +1000, Dave Airlie wrote:
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
Replied too early on cover. Chatting with Michal Wajdeczko today, this
may break things as we the
On Thu, May 22, 2025 at 9:03 AM Konrad Dybcio
wrote:
>
> On 5/11/25 11:51 AM, Akhil P Oommen wrote:
> > On 5/1/2025 9:23 PM, Konrad Dybcio wrote:
> >> On 5/1/25 11:29 AM, Akhil P Oommen wrote:
> >>> On 4/30/2025 10:26 PM, neil.armstr...@linaro.org wrote:
> On 30/04/2025 18:39, Konrad Dybcio w
Hi Maxime,
On 5/22/25 7:16 PM, Maxime Ripard wrote:
> Hi,
>
> On Mon, May 19, 2025 at 01:55:10PM +0300, Cristian Ciocaltea wrote:
>> On 5/19/25 11:42 AM, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Fri, Apr 25, 2025 at 01:27:14PM +0300, Cristian Ciocaltea wrote:
Provide a test to verify that if
Hi Chris,
On Wed, 21 May 2025 17:03:35 -0400
Chris Brandt wrote:
> When drm_panel.prepare_prev_first is set to true in a panel driver, the
> panel expects the MIPI DSI hardware to be already configured before the
> panel's prepare function is called because it might need to send DCS
> commands.
Hi Nemesa,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20250522]
[cannot apply to linus/master drm-intel/for-linux-next-fixes drm-tip/drm-tip
v6.15-rc7]
[If your patch is applied to the wrong git tree
Hi Thomas,
Em 12/05/2025 03:52, Thomas Zimmermann escreveu:
Hi
Am 09.05.25 um 16:26 schrieb André Almeida:
Replace open-coded mutex handling with cleanup.h guard(mutex). This
simplifies the code and removes the "goto unlock" pattern.
Tested with igt tests core_auth and core_setmaster.
Signed
Hi Dave, Simona,
One fix for 6.15.
The following changes since commit a5806cd506af5a7c19bcd596e4708b5c464bfd21:
Linux 6.15-rc7 (2025-05-18 13:57:29 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.15-2025-05-22
for you to
Hello,
On Sat, May 17, 2025 at 06:25:02AM +1000, Dave Airlie wrote:
> I think this is where we have 2 options:
> (a) moving this stuff into core mm and out of shrinker context
> (b) fix our shrinker to be cgroup aware and solve that first.
>
> The main question I have for Christian, is can you gi
On Fri, 23 May 2025 at 01:10, Lucas De Marchi wrote:
>
> On Thu, May 22, 2025 at 04:52:18PM +1000, Dave Airlie wrote:
> >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
>
> Replied too early on
On Fri, May 23, 2025 at 06:32:43AM +1000, Dave Airlie wrote:
On Fri, 23 May 2025 at 01:10, Lucas De Marchi wrote:
On Thu, May 22, 2025 at 04:52:18PM +1000, Dave Airlie wrote:
>From: Dave Airlie
>
>This reduces this struct from 16 to 8 bytes, and it gets embedded
>into a lot of things.
>
>Sign
> @@ -1311,8 +1311,6 @@ static inline struct drm_bridge
>> *devm_drm_of_get_bridge(struct device *dev,
>> return ERR_PTR(-ENODEV);
>> }
>>
>> -static inline void devm_drm_put_bridge(struct device *dev, struct
>> drm_bridge *bridge) {}
>> -
>> static inline struct drm_b
On 12/05/2025 11:32, Vitor Soares wrote:
From: Vitor Soares
The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks
for both runtime PM and system sleep. This causes the DSI clocks to be
disabled twice: once during runtime suspend and again during system
suspend, resulting in a
On Thu May 22, 2025 at 5:44 PM JST, Miguel Ojeda wrote:
> On Thu, May 22, 2025 at 6:01 AM Alexandre Courbot wrote:
>>
>> Either that, or we enable `#![feature(const_trait_impl)]`. I just tried
>> and with it we could indeed define and implement `NumExt` as const,
>> which looks like the cleanest w
On 2024/12/6 16:51, Dmitry Baryshkov wrote:
On Thu, Dec 05, 2024 at 08:31:35PM -0800, Abhinav Kumar wrote:
In preparation of DP MST where link caps are read for the
immediate downstream device and the edid is read through
sideband messaging, split the msm_dp_panel_read_sink_caps() into
two pa
Add a helper to wrap OF-specific calls in drm_panel_add_follower() in
preparation for adding an ACPI equivalent in the future. No functional
changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_panel.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --
> Subject: Re: [PATCH v10 03/10] mtd: intel-dg: implement access functions
>
> 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,
Il 22/05/25 10:34, Jason-JH Lin ha scritto:
Our hardware registers are set through GCE, not by the CPU.
DRM might assume the hardware is disabled immediately after calling
atomic_disable() of drm_plane, but it is only truly disabled after the
GCE IRQ is triggered.
Additionally, the cursor plane
Not RCAR, but R-Car.
Signed-off-by: Wolfram Sang
Reviewed-by: Kieran Bingham
Reviewed-by: Geert Uytterhoeven
---
drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h
b/drivers/gpu/dr
On Wed, May 21, 2025 at 12:53:09PM GMT, Frank Li wrote:
> 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
> Review
> -Original Message-
> From: Christian König
> Sent: Wednesday, May 21, 2025 7:57 PM
> To: wangtao ; T.J. Mercier
>
> Cc: sumit.sem...@linaro.org; benjamin.gaign...@collabora.com;
> brian.star...@arm.com; jstu...@google.com; linux-me...@vger.kernel.org;
> dri-devel@lists.freedesktop.org
truct drm_device
> *drm,
>struct device_node *node,
>u32 port,
>
> ---
> base-commit: a3436f63aa4f93b043a970cc72a196a501191ecc
> change-id: 20250522-devm_drm_put_bridge-fix-non-of-build-fbb67d28494c
>
> Best regards,
> --
> Luca Ceresoli
Hello，
At 2025-05-08 17:11:01, "Daniel Stone" wrote:
>Hi Andy,
>
>On Thu, 8 May 2025 at 11:49, Andy Yan wrote:
>> Let the user know what went wrong in drm_gem_fb_afbc_init
>> failure paths.
>
>Thanks for this, and thanks also for using drm_dbg_kms() to make sure
>that userspace can't flood the
On Wed, 21 May 2025 15:48:00 -0400
Harry Wentland wrote:
> 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
From: Philipp Stanner
The GPU scheduler currently does not ensure that its pending_list is
empty before performing various other teardown tasks in
drm_sched_fini().
If there are still jobs in the pending_list, this is problematic because
after scheduler teardown, no one will call backend_ops.fre
The drm_gpu_scheduler now supports a callback to help drm_sched_fini()
avoid memory leaks. This callback instructs the driver to signal all
pending hardware fences.
Implement the new callback
drm_sched_backend_ops.cancel_pending_fences().
Have the callback use drm_mock_sched_job_complete() with a
drm_sched_fini() can leak jobs under certain circumstances.
Warn if that happens.
Signed-off-by: Philipp Stanner
---
drivers/gpu/drm/scheduler/sched_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
ind
struct nouveau_sched contains a waitque needed to prevent
drm_sched_fini() from being called while there are still jobs pending.
Doing so so far would have caused memory leaks.
With the new memleak-free mode of operation switched on in
drm_sched_fini() by providing the callback
nouveau_sched_fence
Changelog below.
I experimented with the alternative solution (cancel_job() callback) and
maintain the position that this approach is more stable and robust,
despite more code added. I feel more comfortable with it regarding
stability and the possiblity of porting more drivers.
Changes in v3:
-
There is a new callback for always tearing the scheduler down in a
leak-free, deadlock-free manner.
Port Nouveau as its first user by providing the scheduler with a
callback that ensures the fence context gets killed in drm_sched_fini().
Signed-off-by: Philipp Stanner
---
drivers/gpu/drm/nouvea
On 5/21/25 22:29, Lyude Paul wrote:
> 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.
Looks good in general, but my question is if it wouldn't be better to export
the higher level drm_
On 16/05/2025 11:58, Heiko Stübner wrote:
> Am Donnerstag, 15. Mai 2025, 17:54:20 Mitteleuropäische Sommerzeit schrieb
> Krzysztof Kozlowski:
>> On 15/05/2025 14:35, long.yunj...@zte.com.cn wrote:
>>> From: Yumeng Fang
>>>
>>> In the probe path, dev_err() can be replaced with dev_err_probe()
>>
>
On Thu, May 22, 2025 at 6:01 AM Alexandre Courbot wrote:
>
> Either that, or we enable `#![feature(const_trait_impl)]`. I just tried
> and with it we could indeed define and implement `NumExt` as const,
> which looks like the cleanest way to do this to me.
Hmm... I think that one is actively bein
On Thu, 22 May 2025, Dave Airlie wrote:
> From: Dave Airlie
>
> This reduces this struct from 16 to 8 bytes, and it gets embedded
> into a lot of things.
It's an abomination.
And i915 has helpers for it. Because of course it does.
i915_utils.h contains ptr_mask_bits(), ptr_unmask_bits(),
ptr_p
Our hardware registers are set through GCE, not by the CPU.
DRM might assume the hardware is disabled immediately after calling
atomic_disable() of drm_plane, but it is only truly disabled after the
GCE IRQ is triggered.
Additionally, the cursor plane in DRM uses async_commit, so DRM will
not wait
On Thu, 22 May 2025 at 00:43, Johannes Weiner wrote:
>
> 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
From: Shixiong Ou
[WHY]
1. Drivers using DRM_GEM_SHADOW_PLANE_HELPER_FUNCS and
DRM_GEM_SHMEM_DRIVER_OPS (e.g., udl, ast) do not require
sg_table import.
They only need dma_buf_vmap() to access the shared buffer's
kernel virtual address.
2. On certain Aspeed-based boards, a dma_mask o
From: Shixiong Ou
Import dmabuf without mapping its sg_table to avoid issues likes:
ast :07:00.0: swiotlb buffer is full (sz: 3145728 bytes), total 32768
(slots), used 0 (slots)
Signed-off-by: Shixiong Ou
---
drivers/gpu/drm/ast/ast_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
From: Shixiong Ou
Import dmabuf without mapping its sg_table to avoid issues likes:
udl 2-1.4:1.0: swiotlb buffer is full (sz: 2097152 bytes), total 65536
(slots), used 1 (slots)
Signed-off-by: Shixiong Ou
---
drivers/gpu/drm/udl/udl_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On Thu, 22 May 2025 at 16:57, Dave Airlie wrote:
>
> 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've put the tree here, and I realised I sent the patches, but when I
rebased onto lat
tatic inline struct drm_bridge *drmm_of_get_bridge(struct drm_device *drm,
struct device_node *node,
u32 port,
---
base-commit: a3436f63aa4f93b043a970cc72a196a501191ecc
change-id: 20250522-devm_d
Hi Geert,
On 21.5.2025 10.06, Geert Uytterhoeven wrote:
On Wed, 21 May 2025 at 01:59, Eero Tamminen wrote:
I tried your "atari-drm-wip-v1" branch commits on top of 6.14.
Thanks for testing!
After some minor changes those applied. Getting it to build required
adding "&shadow_plane_state->fm
On 20/05/2025 22:44, Dmitry Baryshkov wrote:
From: Dmitry Baryshkov
The "uni" PLL is shared between several PHYS: APQ8064's SATA,
MSM8974/APQ8084 HDMI, MSM8916 DSI, MSM8974/APQ8084 DSI.
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Dmitry Baryshkov
---
drivers/phy/qualcomm/phy-qcom-apq806
Correction: There is no issue with my patch.
The problem was that when I applied Hugo's patch ("[PATCH 2/2] drm: rcar-du:
rzg2l_mipi_dsi: Set DCS maximum return packet size") on top of mine, his code
breaks because the enable function was split into 2 functions.
Since his new code needs to go i
On 22/05/2025 02:32, Douglas Anderson wrote:
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."
On 20/05/2025 22:44, Dmitry Baryshkov wrote:
From: Dmitry Baryshkov
Import register definitions from 28nm DSI and HDMI PHYs, adding more UNI
PHY registers.
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Dmitry Baryshkov
---
drivers/phy/qualcomm/phy-qcom-uniphy.h | 33 ++
When drm_panel.prepare_prev_first is set to true in a panel driver, the
panel expects the MIPI DSI hardware to be already configured before the
panel's prepare function is called because it might need to send DCS
commands.
Signed-off-by: Chris Brandt
---
drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_
Hi Biju,
> Check patch is complaining about Alignment. Please check and fix it.
>
> scripts/checkpatch.pl --strict *.patch
I ran checkpatch first like I always do, but I didn't use --strict.
I didn't even know there was such a thing.
I'll send a V2
Thanks!
Chris
-Original Message-
Fr
Sorry, ignore this version.
The local variables are wrong.
I'll submit a V2.
Chris
-Original Message-
From: Chris Brandt
Sent: Wednesday, May 21, 2025 10:24 AM
To: Biju Das ; Maarten Lankhorst
; Maxime Ripard ; Thomas
Zimmermann ; David Airlie ; Simona
Vetter ; Hien Huynh ; Hu
On 20/05/2025 22:44, Dmitry Baryshkov wrote:
From: Dmitry Baryshkov
Change the MSM HDMI driver to use generic PHY subsystem. Moving PHY
drivers allows better code sharing with the rest of the PHY system.
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/ms
Hello Liu,
On Thu, 22 May 2025 11:20:17 +0800
Liu Ying wrote:
> > If not, can we at least add a band-aid 'X:' entry for
> > drivers/gpu/drm/bridge/imx?
> >
> > I think the other matching entry is the one to consider:
> >
> > DRM DRIVERS FOR FREESCALE IMX BRIDGE
> > M: Liu Ying
> > L: dri-de
When drm_panel.prepare_prev_first is set to true in a panel driver, the
panel expects the MIPI DSI hardware to be already configured before the
panel's prepare function is called because it might need to send DCS
commands.
Signed-off-by: Chris Brandt
---
v1->v2
- Fixed alignment reported by chec
On Tue, May 20, 2025 at 10:22:54AM -0700, Rob Clark wrote:
> On Tue, May 20, 2025 at 9:54 AM Danilo Krummrich wrote:
> > On Tue, May 20, 2025 at 09:07:05AM -0700, Rob Clark wrote:
> > > On Tue, May 20, 2025 at 12:06 AM Danilo Krummrich wrote:
> > > > But let's assume we agree that we want to avoi
Some parties want to check whether a function is already signaled
without actually signaling the fence, which is what
dma_fence_is_signaled() might due if the fence ops 'signaled' callback
is implemented.
Add __dma_fence_is_signaled(), which _only_ checks whether a fence is
signaled. Use it intern
dma_fence_is_signaled_locked(), which is used in
nouveau_fence_context_kill(), can signal fences below the surface
through a callback.
There is neither need for nor use in doing that when killing a fence
context.
Replace dma_fence_is_signaled_locked() with __dma_fence_is_signaled(), a
function wh
On Wednesday, May 21st, 2025 at 21:18, Harry Wentland
wrote:
> 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 xaver.h...@gmail.com wrote:
> > >
> > > > > We can always make the property mutable on
> -Original Message-
> From: wayland-devel On Behalf
> Of Simon Ser
> Sent: Tuesday, April 15, 2025 9:55 PM
> To: Harry Wentland
> Cc: Shankar, Uma ; Alex Hung ;
> dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; wayland-de...@lists.fr
> -Original Message-
> From: Simon Ser
> Sent: Thursday, May 22, 2025 3:45 PM
> To: Harry Wentland
> Cc: Xaver Hugl ; Alex Hung ; dri-
> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org; wayland-
> de...@lists.freedesktop.org; leo@amd.com; ville.syrj...@linux.intel.com;
>
Hi Dave, Sima,
only one fix from drm-misc-fixes this week.
Best regards
Thomas
drm-misc-fixes-2025-05-22:
Short summary of fixes pull:
edid:
- fix HDR metadata reset
The following changes since commit 72c7d62583ebce7baeb61acce6057c361f73be4a:
dma-buf: insert memory barrier before updating nu
On 5/22/25 08:56, Jens Wiklander wrote:
> 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 expla
Durmuş , 22 May 2025 Per, 14:27 tarihinde şunu yazdı:
>
> Hello,
>
Hello,
did you get a message in dmesg from kernel, for example an error like this?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1106268
The dmesg command will give you an output maybe journalctl output or
mesa (glxinfo) out
On 5/22/25 10:02, wangtao wrote:
>> -Original Message-
>> From: Christian König
>> Sent: Wednesday, May 21, 2025 7:57 PM
>> To: wangtao ; T.J. Mercier
>>
>> Cc: sumit.sem...@linaro.org; benjamin.gaign...@collabora.com;
>> brian.star...@arm.com; jstu...@google.com; linux-me...@vger.kernel.
Am 22.05.25 um 08:52 schrieb Dave Airlie:
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
---
Hi
Am 22.05.25 um 08:52 schrieb Dave Airlie:
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 cha
cc'ing Lucas, who should also take a look.
Am 22.05.25 um 08:52 schrieb Dave Airlie:
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 struct
On 5/22/25 13:25, Philipp Stanner wrote:
> dma_fence_is_signaled_locked(), which is used in
> nouveau_fence_context_kill(), can signal fences below the surface
> through a callback.
>
> There is neither need for nor use in doing that when killing a fence
> context.
>
> Replace dma_fence_is_signal
On Thu, 22 May 2025 at 07:54, Ekansh Gupta
wrote:
>
>
>
> 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:
> >>
Hi
Am 22.05.25 um 08:52 schrieb Dave Airlie:
From: Dave Airlie
This reduces this struct from 16 to 8 bytes, and it gets embedded
into a lot of things.
IIRC this has been discussed before. Makes sense to me.
Signed-off-by: Dave Airlie
---
include/linux/iosys-map.h | 30 --
On Thu, 22 May 2025 at 07:58, Ekansh Gupta
wrote:
>
>
>
> 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:
> >>
On Thu, 22 May 2025 at 08:01, Ekansh Gupta
wrote:
>
>
>
> 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:
> >>
> Subject: Re: [PATCH v10 04/10] mtd: intel-dg: register with mtd
>
> 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 shoul
On Tue, May 20, 2025 at 10:47:18AM +0800, Chaoyi Chen wrote:
> From: Chaoyi Chen
>
> Convert cdn-dp-rockchip.txt to yaml.
>
> Add new "port@1" property which represents the CDN DP output to keep
> the same style as the other display interfaces.
>
> This patch also changes the constraints for "p
On Thu, 2025-05-22 at 14:06 +0200, Christian König wrote:
> On 5/22/25 13:25, Philipp Stanner wrote:
> > dma_fence_is_signaled_locked(), which is used in
> > nouveau_fence_context_kill(), can signal fences below the surface
> > through a callback.
> >
> > There is neither need for nor use in doing
Hi Dave and Sima,
Here's the pull request for the drm-xe fixes targeting 6.15-rc8/6.15.
This week we are back to normal, with just a few fixes.
drm-xe-fixes-2025-05-23:
Driver Changes:
- Make sure to check all forcewakes when dumping mocs
- Fix wrong use of read64 on 32b register
- Synchronize P
On Thu, May 22, 2025 at 09:21:00PM -0700, Abhinav Kumar wrote:
>
>
> On 12/23/2024 10:32 PM, Dmitry Baryshkov wrote:
> > On Wed, Dec 04, 2024 at 12:32:55PM +0200, Dmitry Baryshkov wrote:
> > > On Tue, Dec 03, 2024 at 07:24:46PM -0800, Abhinav Kumar wrote:
> > > >
> > > >
> > > > On 12/3/2024 5:
Hi all,
Today's linux-next merge of the rust tree got a conflict in:
rust/bindings/bindings_helper.h
between commits:
9a69570682b1 ("rust: drm: ioctl: Add DRM ioctl abstraction")
07c9016085f9 ("rust: drm: add driver abstractions")
1e4b8896c0f3 ("rust: drm: add device abstraction")
a98
From: Yumeng Fang
Remove hard-coded strings by using the str_true_false() helper.
Signed-off-by: Yumeng Fang
Signed-off-by: Yunjian Long
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/displ
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.
Considering that some code depend on the connector, the following
changes have been made:
- Do not get edid in cdn_dp_get_sink_capability() when connector is
On Tue, May 20, 2025 at 3:31 PM Dave Airlie wrote:
>
> On Wed, 21 May 2025 at 07:53, Rob Clark wrote:
> >
> > On Tue, May 20, 2025 at 2:25 PM Dave Airlie wrote:
> > >
> > > On Sat, 17 May 2025 at 02:20, Rob Clark wrote:
> > > >
> > > > On Fri, May 16, 2025 at 2:01 AM Danilo Krummrich
> > > >
On Thu, May 22, 2025 at 8:53 AM Danilo Krummrich wrote:
>
> On Thu, May 22, 2025 at 07:47:17AM -0700, Rob Clark wrote:
> > On Thu, May 22, 2025 at 4:00 AM Danilo Krummrich wrote:
> > > On Tue, May 20, 2025 at 10:22:54AM -0700, Rob Clark wrote:
> > > > On Tue, May 20, 2025 at 9:54 AM Danilo Krummr
On Wed, May 21, 2025 at 12:33:21PM -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
s/cause/involved
> situations, like for implementing a policy, logs or for giving a chanc
101 - 200 of 225 matches
Mail list logo
