linux-kernel - Re: [PATCH v2 2/4] media: rockchip: Introduce the rkvdec2 driver

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]

Message-ID: <klzru2ak3yxccywqr57bslyctqtmrl2d3eghgv5letp7jkel6s@rlupljmxfijg>
Date: Thu, 20 Jun 2024 15:41:03 +0200
From: Sebastian Reichel <sebastian.reichel@...labora.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Detlev Casanova <detlev.casanova@...labora.com>, 
	linux-kernel@...r.kernel.org, Ezequiel Garcia <ezequiel@...guardiasur.com.ar>, 
	Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Heiko Stuebner <heiko@...ech.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	Dragan Simic <dsimic@...jaro.org>, Diederik de Haas <didi.debian@...ow.org>, 
	Andy Yan <andy.yan@...k-chips.com>, Boris Brezillon <boris.brezillon@...labora.com>, 
	Hans Verkuil <hverkuil-cisco@...all.nl>, Daniel Almeida <daniel.almeida@...labora.com>, 
	Paul Kocialkowski <paul.kocialkowski@...tlin.com>, Nicolas Dufresne <nicolas.dufresne@...labora.com>, 
	Benjamin Gaignard <benjamin.gaignard@...labora.com>, Jonas Karlman <jonas@...boo.se>, Alex Bee <knaerzche@...il.com>, 
	linux-media@...r.kernel.org, linux-rockchip@...ts.infradead.org, devicetree@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-staging@...ts.linux.dev
Subject: Re: [PATCH v2 2/4] media: rockchip: Introduce the rkvdec2 driver

Hi,

On Thu, Jun 20, 2024 at 12:30:00PM GMT, Krzysztof Kozlowski wrote:
> On 19/06/2024 16:57, Detlev Casanova wrote:
> > +static const char * const rkvdec2_clk_names[] = {
> > +	"axi",
> > +	"ahb",
> > +	"core",
> > +	"cabac",
> > +	"hevc_cabac",
> > +};
> > +
> > +/*
> > + * Some SoCs, like RK3588 have multiple identical vdpu34x cores, but the
> > + * kernel is currently missing support for multi-core handling. Exposing
> > + * separate devices for each core to userspace is bad, since that does
> > + * not allow scheduling tasks properly (and creates ABI). With this workaround
> > + * the driver will only probe for the first core and early exit for the other
> > + * cores. Once the driver gains multi-core support, the same technique
> > + * for detecting the main core can be used to cluster all cores together.
> > + */
> > +static int rkvdec2_disable_multicore(struct rkvdec2_dev *rkvdec)
> > +{
> > +	const char *compatible;
> > +	struct device_node *node;
> > +	int ret;
> > +
> > +	/* Intentionally ignores the fallback strings */
> > +	ret = of_property_read_string(rkvdec->dev->of_node, "compatible", &compatible);
> > +	if (ret)
> > +		return ret;
> > +
> > +	/* first compatible node found from the root node is considered the main core */
> 
> So you rely on order of nodes? Before you claim "identical cores", but
> now "main core" suggests one is different than others.

Heh, I wrote that comment for Hantro. By main core I was referencing
the software side of things. With a number of equal cores and no DT
node describing a cluster (from HW point of view it's just equal
cores), they somehow need to be combined into a single entity to allow
scheduling work between them. This solves the issue by making one of
the devices the "main" device. From the HW point it's exactly the same
as the others. The function could also use the last core or the second
one. It does not matter as long as there is only one "main" core.

Greetings,

-- Sebastian

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)