Re: [PATCH 1/4] media: dt-bindings: Add Rockchip JPEG decoder

"Sascha Hauer" <[email protected]>
Newsgroups org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-rockchip,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.linux-media
Message-ID <[email protected]>
On 2026-08-25 09:21, Krzysztof Kozlowski wrote:
> On 24/08/2026 09:01, Sascha Hauer wrote:
> > Add a devicetree binding schema for the JPEG hardware decoder Rockchip
> > integrates into a number of its SoCs.  Documents the single register
> > window (task registers plus the LLP link-table block at offset 0x300),
> > the decode interrupt, the aclk/hclk clocks, the AXI/AHB resets, the IOMMU
> > and the power domain.
> > 
> > The core is not tied to one SoC.  Downstream it is known as the VDPU720
> > and the same block sits on the RK3528, RK3562, RK356x, RK3576, RK3588 and
> > RV1126B, with only the clocks, the resets and the power domain differing,
> > none of which this schema constrains.  A compatible per SoC is all it
> > takes to cover them; the RK3568 and the RK3588 are the two that have been
> > tested and are enabled here.
> > 
> > The resets and the power domain are required.  The block cannot be
> > reached with its domain off, and the driver falls back to pulsing the
> > reset lines when a frame times out and the in-block soft reset does not
> > complete, which a node without them would leave with no way to recover.
> > 
> > The IOMMU stays optional.  The driver never refers to it, it is a platform
> > integration detail, and rockchip-vpu.yaml does not require it for the
> > other codec blocks on these SoCs either.
> > 
> > Assisted-by: Claude:claude-opus-5
> > ---
> >  .../bindings/media/rockchip,jpeg-decoder.yaml      | 92 ++++++++++++++++++++++
> >  MAINTAINERS                                        |  8 ++
> >  2 files changed, 100 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/media/rockchip,jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/rockchip,jpeg-decoder.yaml
> > new file mode 100644
> > index 0000000000000..e20c1bf43ef3e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/rockchip,jpeg-decoder.yaml
> > @@ -0,0 +1,92 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/rockchip,jpeg-decoder.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Rockchip JPEG Decoder
> > +
> > +maintainers:
> > +  - Lucas Sinn <[email protected]>
> > +  - Sascha Hauer <[email protected]>
> > +
> > +description:
> > +  Rockchip's in-house JPEG/MJPEG hardware decoder, known downstream as the
> > +  VDPU720.  The same core is integrated into a number of Rockchip SoCs, which
> > +  differ only in the clocks, resets and power domain they are wired to.  A
> > +  dedicated Link List Processor (LLP) register block, located at offset 0x300
> > +  within the same register window, allows the hardware to decode a chain of
> > +  frames autonomously ("link mode").
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - rockchip,rk3568-jpegd
> > +      - rockchip,rk3588-jpegd
> 
> How this can be v1 if you send VPU720 for rk3588 already?
> 
> https://lore.kernel.org/all/[email protected]/

The above has the JPEG decoder driver integrated into the hantro driver
which turned out to be the wrong abstraction, so I had to split this
series up into two, one for the Hantro fixes and one for the now
standalone JPEG decoder driver which is this series. I decided to start
freshly for both series instead of treating one as continuation of the
other.

> 
> Were there more versions?

No.

Sascha

--
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.