mbox series

[v5,0/3] Enable JPEG Encoder on RK3566/RK3568

Message ID 20220612155346.16288-1-frattaroli.nicolas@gmail.com
Headers show
Series Enable JPEG Encoder on RK3566/RK3568 | expand

Message

Nicolas Frattaroli June 12, 2022, 3:53 p.m. UTC 
Hello,

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.

The second patch makes the actual driver changes to support this variant.

The third and final patch makes the necessary device tree changes for
the rk356x device tree file to add both the node for the encoder and
its MMU.

The series has been tested on a PINE64 Quartz64 Model A with an RK3566
SoC using GStreamer.

Regards,
Nicolas Frattaroli

Changes in v5:
 - rename rockchip-vepu.yaml to rockchip,rk3568-vepu.yaml
 - fix #address-cells/#size-cells in bindings example
 - fix indentation in bindings example

Changes in v4:
 - bindings: move vepu to its own binding, also add it to MAINTAINERS
 - driver: rename a stray rk3568_jpeg_enc_codec_ops to
   rk3568_vepu_codec_ops
 - devicetree: remove interrupt-names property
 - rebase onto linux-next

Changes in v3:
 - bindings: change consts to an enum
 - bindings: add check to make sure devices with a -vepu compatible only
   have the vepu interrupt

Changes in v2:
 - rename compatible as it's not JPEG only
 - rename device tree nodes as it's not JPEG only
 - reword commits as it's not JPEG only
 - get rid of a whole bunch of redundant struct definitions, as, you
   guessed it, it's not JPEG only


Nicolas Frattaroli (3):
  media: dt-binding: media: Add rk3568-vepu binding
  media: hantro: Add support for RK356x encoder
  arm64: dts: rockchip: Add Hantro encoder node to rk356x

 .../bindings/media/rockchip,rk3568-vepu.yaml  | 69 +++++++++++++++++++
 MAINTAINERS                                   |  1 +
 arch/arm64/boot/dts/rockchip/rk356x.dtsi      | 20 ++++++
 drivers/staging/media/hantro/hantro_drv.c     |  1 +
 drivers/staging/media/hantro/hantro_hw.h      |  1 +
 .../staging/media/hantro/rockchip_vpu_hw.c    | 25 +++++++
 6 files changed, 117 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml

Comments

Rob Herring (Arm) June 14, 2022, 9:02 p.m. UTC | #1 
On Sun, 12 Jun 2022 17:53:44 +0200, Nicolas Frattaroli wrote:
> The RK3568 and RK3566 have a Hantro VPU node solely dedicated to
> encoding. This patch adds a new binding to describe it, as it
> does not really fit the rockchip-vpu binding, since there is no
> decoder.
> 
> Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
> ---
>  .../bindings/media/rockchip,rk3568-vepu.yaml  | 69 +++++++++++++++++++
>  MAINTAINERS                                   |  1 +
>  2 files changed, 70 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml
> 

Reviewed-by: Rob Herring <robh@kernel.org>
Heiko Stübner Sept. 9, 2022, 11:10 p.m. UTC | #2 
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,