[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 10 Sep 2022 01:10:55 +0200
From: Heiko Stuebner <heiko@...ech.de>
To: Rob Herring <robh+dt@...nel.org>,
Ezequiel Garcia <ezequiel@...guardiasur.com.ar>,
Liang Chen <cl@...k-chips.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
Peter Geis <pgwipeout@...il.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Michael Riesch <michael.riesch@...fvision.net>,
Nicolas Frattaroli <frattaroli.nicolas@...il.com>
Cc: Heiko Stuebner <heiko@...ech.de>, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, linux-media@...r.kernel.org,
linux-staging@...ts.linux.dev, linux-rockchip@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: (subset) [PATCH v5 0/3] Enable JPEG Encoder on RK3566/RK3568
On Sun, 12 Jun 2022 17:53:43 +0200, Nicolas Frattaroli wrote:
> this is v5 of my RK356x JPEG encoder patch set. It enables the Hantro
> hardware encoder of the RK3566 and RK3568 line of SoCs, with JPEG being
> the only format the driver currently supports encoding for.
>
> The first patch adds a new binding, the rockchip,rk3568-vepu binding, to
> describe this kind of hardware. The reason for going with a new binding
> instead of modifying the vpu binding as the previous versions did is
> that the vpu binding is getting quite long, and Ezequiel Garcia suggested
> (on IRC) that we could document encoder only instances in their own
> binding. This makes sense to me, especially considering that RK3588 will
> have more Hantro instances like this to document.
>
> [...]
Applied, thanks!
[3/3] arm64: dts: rockchip: Add Hantro encoder node to rk356x
commit: 03d86fb5a56919ccf47e1cc5861bb5452017ab93
Best regards,
--
Heiko Stuebner <heiko@...ech.de>
Powered by blists - more mailing lists