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

Nicolas Dufresne <[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]>
Le mardi 25 août 2026 à 07:39 +0000, Sascha Hauer a écrit :
> 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.

I'd like to recommend doing the opposite next time. Create a separate series for
the fixes, and place your fresh bindings, driver and updated DTS in a v2.

The reason is that you are sending 1 series to 3 maintainers, and we all have to
keep a different patchwork up-to-date, having v2 makes it clear as we can see
from the changelog what happened and why it got rewritten.

Nicolas

> 
> > 
> > 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 |
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
signature.asc (application/pgp-signature, 228 B)
-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQTvDVKBFcTDwhoEbxLZQZRRKWBy9AUCao2K6gAKCRDZQZRRKWBy
9AepAP9LKy3L2SDezcHWRKeGBxhM7jMPnAdAPPhP2UALllz2iwD9H7t7vcPXscK+
c8c3Swnx7HKx4J+UNpsV0i3RGR3GZgw=
=pluw
-----END PGP SIGNATURE-----
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.