[PATCH 1/2] [RESEND] media: rkvdec: reduce excessive stack usage in assemble_hw_pps()

Nicolas Dufresne nicolas.dufresne at collabora.com
Thu Mar 5 10:43:09 PST 2026


Hi,

Le jeudi 05 mars 2026 à 18:10 +0100, Arnd Bergmann a écrit :
> On Thu, Mar 5, 2026, at 17:37, Nicolas Dufresne wrote:
> > 
> > Le jeudi 05 mars 2026 à 16:26 +0100, Arnd Bergmann a écrit :
> > > From: Arnd Bergmann <arnd at arndb.de>
> > > 
> > > The rkvdec_pps had a large set of bitfields, all of which
> > > as misaligned. This causes clang-21 and likely other versions to
> > > produce absolutely awful object code and a warning about very
> > > large stack usage, on targets without unaligned access:
> > 
> > I'm a bit surprised you felt the need for resend. Perhaps you can help us
> > understand what made you think your patch wasn't being processed ?
> 
> I updated the second patch today after I found a corner case that
> wasn't addressed by the first version. As I had sent both as a series
> a month ago, and neither was in linux-next yet, it seemed more helpful
> to send an updated series rather than replace only one of the two.

If you updated the code I'd prefer if it is sent as a new version, not a resend.
As for the media merge window, its been about a week since rc1 got merged into
media tree, with couple of weeks before that waiting for rc1 to land. I believe
your month gap is there and accurate. I did also took a small break on review
and PR concurrently.

> 
> > My PR:
> > https://patchwork.linuxtv.org/project/linux-media/patch/2074ba5a5d05e239f432d176eb051105f7e692f9.camel@collabora.com/
> > 
> > And Hans/Mauro did logistic on the #linux-maint IRC channel this morning. I
> > believe I've marked all the relevant patches on patchwork our of "New" state
> > and
> > you have my Rb. What else would help you ?
> 
> That's fine then, I did not mean to seem impatient. I assume
> the original patches will be in linux-next then, and [v2 2/2]
> will conflict. I'll let you review that one first, but can
> send a rebased version if you think we should merge it on top.

It will first reach media media-fixes (and not media-next, to avoid duplicating
the patches), but I have no idea if someone picks from media-fixes into linux-
next. I recall there was a gap to be fixed in this "pre-integration" process.
Though, patch from fixes reaches RCs quickly, which are linux-next base.

Now, concurrently, Detlev is working on removing the bitfield for the RPS, and
the SPS will come later. Perhaps you want to sync to make sure we don't just
cancel out the work.

To solve the patch conflict issue, you can work on top of your existing series
(just put a comment in the cover). I'll request a merge of rc2 / rc3 into media-
next, before I pick it up.

regards,
Nicolas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20260305/b792d4f9/attachment.sig>


More information about the Linux-rockchip mailing list