Re: [PATCH V2 08/10] dt-bindings: media: nxp,imx8mq-vpu: Add support for G1 and G2 on imx8mm
From: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Date: 2021-12-16 23:03:59
Also in:
linux-arm-kernel, linux-media, linux-rockchip, linux-staging, lkml
Hi Adam, On Thu, 16 Dec 2021 at 18:21, Adam Ford [off-list ref] wrote:
On Thu, Dec 16, 2021 at 3:07 PM Rob Herring [off-list ref] wrote:quoted
On Thu, Dec 16, 2021 at 05:12:53AM -0600, Adam Ford wrote:quoted
The i.MX8M mini appears to have a similar G1 and G2 decoder but the post-procesing isn't present, so different compatible flags are requred.post-processingquoted
Since all the other parameters are the same with imx8mq, just add the new compatible flags to nxp,imx8mq-vpu.yaml. Signed-off-by: Adam Ford <redacted>diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml index c1e157251de7..b1f24c48c73b 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml@@ -5,7 +5,7 @@ $id: "http://devicetree.org/schemas/media/nxp,imx8mq-vpu.yaml#" $schema: "http://devicetree.org/meta-schemas/core.yaml#" -title: Hantro G1/G2 VPU codecs implemented on i.MX8MQ SoCs +title: Hantro G1/G2 VPU codecs implemented on i.MX8MQ/i.MX8MM SoCsJust 'i.MX8' so we don't have to change this everytime?Are you OK with i.MX8M? 8MQ, 8MM, and 8MP all appear to have G1 and G2 decoders. The i.MX8 is different.quoted
quoted
maintainers: - Philipp Zabel [off-list ref]@@ -20,6 +20,8 @@ properties: deprecated: true - const: nxp,imx8mq-vpu-g1 - const: nxp,imx8mq-vpu-g2 + - const: nxp,imx8mm-vpu-g1 + - const: nxp,imx8mm-vpu-g2Not compatible with the imx8mq variants?No, the structures associated with these compatible flags telling the driver what features are available have options for the post-processor in the 8MQ which are not present in the 8MM.
Just as G1 and G2 are different blocks, their "post-processor" features are really different too. The G2 core typically produces a tiled format, NV12_4L4, and it an inline post-processor to convert that to linear NV12. How does this work on the 8MM? What pixel format does it produce natively? It's hard to imagine the G2 block doesn't do linear NV12, so I'm inclined to think it has that post-processing feature. Thanks, Ezequiel