<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/next/linux-next.git/drivers/gpu/drm/vc4, branch master</title>
<subtitle>The linux-next integration testing tree</subtitle>
<id>https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/atom?h=master</id>
<link rel='self' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/'/>
<updated>2026-08-31T13:18:00+00:00</updated>
<entry>
<title>drm/vc4: Convert to atomic_create_state</title>
<updated>2026-08-31T13:18:00+00:00</updated>
<author>
<name>Maxime Ripard</name>
<email>mripard@kernel.org</email>
</author>
<published>2026-08-21T14:39:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=56f115da1b7e862f62c79aee233acbe5918c6040'/>
<id>urn:sha1:56f115da1b7e862f62c79aee233acbe5918c6040</id>
<content type='text'>
The vc4 crtc implementation provides a custom reset hook. However,
this hook only allocates the state, initializes it with
__drm_atomic_helper_crtc_reset(), sets the assigned_channel field to
VC4_HVS_CHANNEL_DISABLED, and frees the previous state. It does not
perform any hardware reset.

Since this is exactly what the atomic_create_state hook is meant to
do, minus the old state cleanup which the caller handles, convert the
implementation to use atomic_create_state with
__drm_atomic_helper_crtc_state_init() instead.

Reviewed-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Link: https://patch.msgid.link/20260821-drm-no-more-crtc-reset-v1-66-fb793475c05a@kernel.org
Signed-off-by: Maxime Ripard &lt;mripard@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge drm/drm-next into drm-misc-next</title>
<updated>2026-08-31T07:01:06+00:00</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2026-08-31T06:25:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=1ae7fe832c2d3ecc75815eed037a07290586b6be'/>
<id>urn:sha1:1ae7fe832c2d3ecc75815eed037a07290586b6be</id>
<content type='text'>
Getting drm-misc-next up to v7.3-rc1.

In exynos, there was a conflict in exynos_dbi_bind(). The merge resolves
it to the state of commit 3cc8eee9f346 ("drm/exynos: remove dependency
on DRM simple helpers").

Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
</content>
</entry>
<entry>
<title>drm/vc4: Convert to atomic_create_state</title>
<updated>2026-08-21T14:20:32+00:00</updated>
<author>
<name>Maxime Ripard</name>
<email>mripard@kernel.org</email>
</author>
<published>2026-08-14T14:57:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=5a7530adceaee703ac63fe33e87888733e9aacec'/>
<id>urn:sha1:5a7530adceaee703ac63fe33e87888733e9aacec</id>
<content type='text'>
The plane reset implementation creates a custom state
subclass, but only initializes a pristine state without resetting any
hardware. This is equivalent to what atomic_create_state expects.
Convert to it.

The conversion was done using the following Coccinelle semantic patch:

@@
identifier funcs;
symbol drm_atomic_helper_plane_reset;
symbol drm_atomic_helper_plane_create_state;
@@

struct drm_plane_funcs funcs = {
  ...,
- .reset = drm_atomic_helper_plane_reset,
+ .atomic_create_state = drm_atomic_helper_plane_create_state,
  ...,
};

@match_struct_reset@
identifier funcs, reset_func;
@@
struct drm_plane_funcs funcs = {
    ...,
    .reset = reset_func,
    ...,
};

@reset_uses_helpers depends on match_struct_reset@
identifier match_struct_reset.reset_func;
@@

 void reset_func(...)
 {
 	&lt;+...
(
 	__drm_atomic_helper_plane_reset(...);
|
	__drm_gem_reset_shadow_plane(...);
)
 	...+&gt;
 }

@match_struct_destroy@
identifier funcs, destroy_func;
@@
struct drm_plane_funcs funcs = {
    ...,
    .atomic_destroy_state = destroy_func,
    ...,
};

@script:python renamed_func@
old_name &lt;&lt; match_struct_reset.reset_func;
new_name;
@@
if old_name.endswith("_reset"):
    coccinelle.new_name = old_name.replace("_reset", "_create_state")
else:
    coccinelle.new_name = old_name

@update_struct depends on match_struct_reset &amp;&amp; reset_uses_helpers@
identifier match_struct_reset.funcs, match_struct_reset.reset_func;
identifier renamed_func.new_name;
@@
struct drm_plane_funcs funcs = {
    ...,
-   .reset = reset_func,
+   .atomic_create_state = new_name,
    ...,
};

@drop_destroy depends on update_struct &amp;&amp; match_struct_destroy@
identifier match_struct_reset.reset_func;
identifier match_struct_destroy.destroy_func;
identifier container_func;
identifier P;
symbol drm_atomic_helper_plane_destroy_state;
symbol __drm_atomic_helper_plane_destroy_state;
@@

 void reset_func(struct drm_plane *P)
 {
 	...
(
-	if (P-&gt;state) {
- 		&lt;+...
(
-		drm_atomic_helper_plane_destroy_state(P, P-&gt;state);
|
-		__drm_atomic_helper_plane_destroy_state(P-&gt;state);
|
-		P-&gt;funcs-&gt;atomic_destroy_state(P, P-&gt;state);
|
-		destroy_func(P, P-&gt;state);
)
- 		...+&gt;
- 	}
|
-	drm_WARN_ON_ONCE(P-&gt;dev, P-&gt;state);
|
-	WARN_ON(P-&gt;state);
)
 	...
(
-	kfree(P-&gt;state);
|
-	kfree(container_func(P-&gt;state));
|
 	// kfree is optional
)
(
-	P-&gt;state = NULL;
|
 	// plane-&gt;state clearing is optional
)
 	...
 }

@drop_destroy_mtk depends on update_struct@
identifier P;
symbol __drm_atomic_helper_plane_destroy_state;
symbol to_mtk_plane_state;
@@

 void mtk_plane_reset(struct drm_plane *P)
 {
 	...
-	if (P-&gt;state) {
-		__drm_atomic_helper_plane_destroy_state(P-&gt;state);
-		...
-	} else {
 		...
-	}
 	...
 }

@transform_nv50_wndw depends on update_struct@
identifier S;
@@

 void nv50_wndw_reset(...)
 {
 	...
-	if (WARN_ON(!(S = kzalloc_obj(*S))))
+	S = kzalloc_obj(*S);
+	if (WARN_ON(!S))
 		return;
 	...
 }

@transform_kzalloc depends on update_struct@
identifier match_struct_reset.reset_func;
identifier P, S;
statement ST;
statement list STL;
@@

 void reset_func(struct drm_plane *P)
 {
 	&lt;...
 	S = kzalloc_obj(*S);
(
-	if (S)
-	{
-		STL
-	}
+	if (!S) return;
+
+	STL
|
-	if (S) ST
+	if (!S) return;
+
+	ST
)
	...&gt;
 }

@transform_body depends on update_struct@
identifier match_struct_reset.reset_func;
identifier renamed_func.new_name;
identifier S, P;
expression PS;
@@
- void reset_func(struct drm_plane *P)
+ struct drm_plane_state *new_name(struct drm_plane *P)
{
	...
 	S = kzalloc_obj(*S);
	...
(
 	if (!S) {
		...
-		return;
+		return ERR_PTR(-ENOMEM);
 	}
|
 	if (WARN_ON(!S)) {
		...
-		return;
+		return ERR_PTR(-ENOMEM);
 	}
|
 	if (S == NULL) {
 		...
-		return;
+		return ERR_PTR(-ENOMEM);
 	}
)
	...
(
-	__drm_atomic_helper_plane_reset(P, PS);
+	__drm_atomic_helper_plane_state_init(PS, P);
|
-	__drm_gem_reset_shadow_plane(P, PS);
+	__drm_gem_shadow_plane_state_init(P, PS);
)
	...
}

@update_early_return depends on update_struct@
identifier match_struct_reset.reset_func;
identifier renamed_func.new_name;
identifier P;
expression PS;
@@
 struct drm_plane_state *new_name(struct drm_plane *P)
{
	&lt;+...
-	return;
+	return ERR_PTR(-EINVAL);
	...+&gt;
}

@update_return_plane depends on update_struct@
identifier match_struct_reset.reset_func;
identifier renamed_func.new_name;
identifier P;
expression PS;
@@
 struct drm_plane_state *new_name(struct drm_plane *P)
{
	...
 	__drm_atomic_helper_plane_state_init(PS, P);
	...
+
+	return PS;
}

@update_return_shadow depends on update_struct@
identifier renamed_func.new_name;
identifier P;
expression PS;
@@
 struct drm_plane_state *new_name(struct drm_plane *P)
{
	...
 	__drm_gem_shadow_plane_state_init(P, PS);
	...
+
+	return &amp;PS-&gt;base;
}

Reviewed-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Link: https://patch.msgid.link/20260814-drm-no-more-plane-reset-v2-57-82d2963dd134@kernel.org
Signed-off-by: Maxime Ripard &lt;mripard@kernel.org&gt;
</content>
</entry>
<entry>
<title>BackMerge tag 'v7.2' into drm-next</title>
<updated>2026-08-20T00:58:44+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2026-08-20T00:58:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c44e278ce02efd0c4be79a8eda1ea6885c1ce5ec'/>
<id>urn:sha1:c44e278ce02efd0c4be79a8eda1ea6885c1ce5ec</id>
<content type='text'>
Linux 7.2

There was a lot of conflicts this round between fixes and next,
and I'd like to get the merge resolutions that we have in drm-tip.

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/debugfs: Move HDMI debugfs registration to state helper</title>
<updated>2026-08-13T15:07:41+00:00</updated>
<author>
<name>Nicolas Frattaroli</name>
<email>nicolas.frattaroli@collabora.com</email>
</author>
<published>2026-07-24T14:22:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c72198cceeae040d23f5a50e2830c84c296ec551'/>
<id>urn:sha1:c72198cceeae040d23f5a50e2830c84c296ec551</id>
<content type='text'>
The HDMI debugfs files are only useful for connectors that already make
use of the HDMI state helpers. In addition, relying on HDMI-specific
functions in drm_debugfs.c can lead to circular linking problems later
down the line.

Move hdmi_debugfs_add() and friends to a new helper in
drm_hdmi_state_helper.c, and make all current users (vc4, sun4i, bridge)
either use it as a debugfs_init func, or call it directly in its
debugfs_init func.

Suggested-by: Maxime Ripard &lt;mripard@kernel.org&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Acked-by: Maxime Ripard &lt;mripard@kernel.org&gt;
Signed-off-by: Nicolas Frattaroli &lt;nicolas.frattaroli@collabora.com&gt;
Tested-by: Hans Verkuil &lt;hverkuil+cisco@kernel.org&gt;
Link: https://patch.msgid.link/20260724-scdc-link-health-v9-4-bdda406d016d@collabora.com
Signed-off-by: Daniel Stone &lt;daniels@collabora.com&gt;
</content>
</entry>
<entry>
<title>drm/vc4: Zero the tile state data array before each BIN job</title>
<updated>2026-07-28T12:16:30+00:00</updated>
<author>
<name>Maíra Canal</name>
<email>mcanal@igalia.com</email>
</author>
<published>2026-07-27T14:32:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=48a570c964d8e37d353381e4195106277e17f5cb'/>
<id>urn:sha1:48a570c964d8e37d353381e4195106277e17f5cb</id>
<content type='text'>
The binner BO is a single 16MB buffer split into 512KB slots that are
handed out to jobs at submission time and recycled as jobs complete,
without ever being cleared. Each slot holds the job's Tile State Data
Array (TSDA) at its start, followed by the tile allocation pool.

While the tile allocation pool is only walked by the render thread
through branches the binner generated during the current job, the
TSDA is the PTB's own per-tile bookkeeping and is consumed by the
hardware itself. Although the kernel sets the "Auto-initialise Tile
State Data Array" flag in the tile binning mode configuration, the
PTB demonstrably still acts on stale tile state left by the slot's
previous user: the binner ends up creating invalid command streams
with invalid primitive streams and branches, which can cause GPU hangs
as observed in [1][2].

Zero the TSDA when the job's binning slot is configured. This clears
48 bytes per tile (~24KB for a 1080p frame) in the submission path, and
guarantees the PTB never sees another job's tile state.

The tile count is only checked for being non-zero today, so the 8-bit
fields it comes from can describe a tile state array almost six times
larger than the slot it has to live in. Bound it before the slot is
handed out, since such size decides how much of the slot is left for
the tile alloc pool.

Link: https://github.com/raspberrypi/linux/issues/3221 [1]
Link: https://github.com/raspberrypi/linux/issues/5780 [2]
Fixes: 553c942f8b2c ("drm/vc4: Allow using more than 256MB of CMA memory.")
Cc: stable@vger.kernel.org
Reviewed-by: Iago Toral Quiroga &lt;itoral@igalia.com&gt;
Link: https://patch.msgid.link/20260727-vc4-bin-oom-fixes-v2-2-0d8a5eddc7c9@igalia.com
Signed-off-by: Maíra Canal &lt;mcanal@igalia.com&gt;
</content>
</entry>
<entry>
<title>drm/vc4: Supply the overflow slot size in BPOS, not the whole bin BO size</title>
<updated>2026-07-28T12:16:09+00:00</updated>
<author>
<name>Jose Maria Casanova Crespo</name>
<email>jmcasanova@igalia.com</email>
</author>
<published>2026-07-27T14:32:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=6395789e4739aa5177bbec0fa0f07ccc38d249b0'/>
<id>urn:sha1:6395789e4739aa5177bbec0fa0f07ccc38d249b0</id>
<content type='text'>
vc4_overflow_mem_work() points BPOA at a 512KB slot inside the 16MB
binner BO, but writes the size of the whole BO to BPOS. On every binner
out-of-memory event the PTB is therefore authorized to write tile lists
across all the other slots (which may hold the tile state, tile alloc and
overflow memory of in-flight jobs) and, for any slot but the first, past
the end of the binner BO into unrelated CMA memory.

Since CMA pages are recycled into page cache and user allocations, this
is arbitrary memory corruption by GPU DMA. In practice it shows up as GPU
hangs with corrupted control list pointers, userspace heap corruption, a
GPU that stays permanently wedged after the first hang, and occasional
full system crashes, whenever a job overflows the initial binner slot.

The bug dates back to the conversion from a dedicated overflow BO (where
writing the full BO size was correct) to the slotted binner BO.

Fixes: 553c942f8b2c ("drm/vc4: Allow using more than 256MB of CMA memory.")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4.8
Signed-off-by: Jose Maria Casanova Crespo &lt;jmcasanova@igalia.com&gt;
Reviewed-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Reviewed-by: Iago Toral Quiroga &lt;itoral@igalia.com&gt;
Link: https://patch.msgid.link/20260727-vc4-bin-oom-fixes-v2-1-0d8a5eddc7c9@igalia.com
Signed-off-by: Maíra Canal &lt;mcanal@igalia.com&gt;
</content>
</entry>
<entry>
<title>drm/vc4: Shut down BO cache timer before teardown</title>
<updated>2026-07-23T23:07:23+00:00</updated>
<author>
<name>Linmao Li</name>
<email>lilinmao@kylinos.cn</email>
</author>
<published>2026-07-20T08:44:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=6273dd3ffb54ec581855b82ae77331b66028249c'/>
<id>urn:sha1:6273dd3ffb54ec581855b82ae77331b66028249c</id>
<content type='text'>
The BO cache timer callback schedules time_work, and time_work can rearm
the timer through vc4_bo_cache_free_old().

vc4_bo_cache_destroy() deletes the timer and then cancels the work, which
does not break that cycle: the work being cancelled can rearm the timer,
and the timer then queues work again after teardown.

Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the
cycle ends with cancel_work_sync().

Fixes: c826a6e10644 ("drm/vc4: Add a BO cache.")
Cc: stable@vger.kernel.org
Signed-off-by: Linmao Li &lt;lilinmao@kylinos.cn&gt;
Link: https://patch.msgid.link/20260720084426.1632508-1-lilinmao@kylinos.cn
Reviewed-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Signed-off-by: Maíra Canal &lt;mcanal@igalia.com&gt;
</content>
</entry>
<entry>
<title>drm/vc4: hvs/v3d: Fix null dereference in unbind</title>
<updated>2026-07-22T14:29:29+00:00</updated>
<author>
<name>Gregor Herburger</name>
<email>gregor.herburger@linutronix.de</email>
</author>
<published>2026-07-21T15:38:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=7dc3680b7ffe01add3e9299fde8471d2dd53a8ae'/>
<id>urn:sha1:7dc3680b7ffe01add3e9299fde8471d2dd53a8ae</id>
<content type='text'>
The hvs and v3d drivers use dev_get_drvdata(master) in their unbind
functions. Since the vc4-drm gets removed before its dependent drivers
(vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to
get drvdata of its master and fails with a null dereference error.

Use the data pointer passed to the unbind functions directly instead of
dev_get_drvdata(master). This avoids using potentially freed memory.

Fixes: d3f5168a0810 ("drm/vc4: Bind and initialize the V3D engine.")
Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.")
Signed-off-by: Gregor Herburger &lt;gregor.herburger@linutronix.de&gt;
Link: https://patch.msgid.link/20260721-rpi-vc4-fix-v2-1-b813dcd01dc7@linutronix.de
Reviewed-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Signed-off-by: Maíra Canal &lt;mcanal@igalia.com&gt;
</content>
</entry>
<entry>
<title>drm/vc4: Prevent shader BO mappings from becoming writable</title>
<updated>2026-07-21T12:53:28+00:00</updated>
<author>
<name>Linmao Li</name>
<email>lilinmao@kylinos.cn</email>
</author>
<published>2026-07-21T01:15:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=0c9e6367639548307d3f578f6943ce72c9d39087'/>
<id>urn:sha1:0c9e6367639548307d3f578f6943ce72c9d39087</id>
<content type='text'>
vc4_gem_object_mmap() rejects a writable mapping of a validated shader
BO, but leaves VM_MAYWRITE set.  Userspace can map the BO read-only and
then turn it writable with mprotect().

Validated shader BOs must stay read-only: the validator checks the
instructions once and the GPU trusts them afterwards.  A writable
mapping lets userspace rewrite the code after validation, bypassing the
validator.

Clear VM_MAYWRITE on the read-only path so the mapping cannot be
upgraded, as i915 already does for its read-only objects.

Fixes: 463873d57014 ("drm/vc4: Add an API for creating GPU shaders in GEM BOs.")
Cc: stable@vger.kernel.org
Reported-by: Sashiko &lt;sashiko-bot@kernel.org&gt;
Closes: https://lore.kernel.org/dri-devel/20260720085554.B0AF01F000E9@smtp.kernel.org/
Signed-off-by: Linmao Li &lt;lilinmao@kylinos.cn&gt;
Link: https://patch.msgid.link/20260721011558.1672477-1-lilinmao@kylinos.cn
Reviewed-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Signed-off-by: Maíra Canal &lt;mcanal@igalia.com&gt;
</content>
</entry>
</feed>
