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-----