linux-kernel - Re: [PATCH v4 0/2] Enable JPEG encoding on rk3588

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sun, 28 Apr 2024 19:01:38 +0200
From: Heiko Stübner <heiko@...ech.de>
To: linkmauve@...kmauve.fr, Jianfeng Liu <liujianfeng1994@...il.com>
Cc: andy.yan@...k-chips.com, conor+dt@...nel.org,
 cristian.ciocaltea@...labora.com, devicetree@...r.kernel.org,
 dsimic@...jaro.org, ezequiel@...guardiasur.com.ar,
 frattaroli.nicolas@...il.com, iommu@...ts.linux.dev, joro@...tes.org,
 krzysztof.kozlowski+dt@...aro.org, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
 linux-rockchip@...ts.infradead.org, macromorgan@...mail.com,
 mchehab@...nel.org, p.zabel@...gutronix.de, robh@...nel.org,
 robin.murphy@....com, sebastian.reichel@...labora.com,
 shreeya.patel@...labora.com, will@...nel.org, sigmaris@...il.com,
 nicolas@...fresne.ca
Subject: Re: [PATCH v4 0/2] Enable JPEG encoding on rk3588

Hi Jianfeng,

Am Samstag, 27. April 2024, 09:16:38 CEST schrieb Jianfeng Liu:
> Hi Emmanuel,
> 
> On Thu, 18 Apr 2024 16:15:04 +0200, Emmanuel Gil Peyrot wrote:
> >- Only expose a single VEPU121, since the driver doesn’t yet support
> >  exposing them all as a single video node to userspace.
> I'm also doing work with the hantro node on rk3588 which has both vdpu
> and vepu. Discussions can be found here[1]. If I enable the jpeg encoder
> at feb50000, would it cause any side effects if other jpeg encoders in
> your patch are enabled? And what's the disadvantage of enabling multi
> jpeg endoers in devicetree?

the basic problem is that exposing multiple jpeg encoders would require
userspace to do the scheduling. Which is bad.
I.e. all userspace programms would need to know the existence of
all jpeg encoders and then somehow negotiate how to use all of them
most efficiently.

Think multiple different programs that would need to negotiate to
spread across all of them in the best way.

Doing this in the kernel, we just expose one encoder (and queue) all
programs would just pile onto that one encoder and the kernel then
would be on the hook to do the scheduling - which the kernel can do
better (with relevant code implemented)