[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <09579b62-77fe-4ba4-b3a1-e3b17dff0188@linaro.org>
Date: Mon, 26 Feb 2024 10:10:08 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Paweł Anikiel <panikiel@...gle.com>, airlied@...il.com,
akpm@...ux-foundation.org, conor+dt@...nel.org, daniel@...ll.ch,
dinguyen@...nel.org, hverkuil-cisco@...all.nl,
krzysztof.kozlowski+dt@...aro.org, maarten.lankhorst@...ux.intel.com,
mchehab@...nel.org, mripard@...nel.org, robh+dt@...nel.org,
tzimmermann@...e.de
Cc: devicetree@...r.kernel.org, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
chromeos-krk-upstreaming@...gle.com, ribalda@...omium.org
Subject: Re: [PATCH v2 7/9] media: dt-bindings: Add Chameleon v3 framebuffer
On 21/02/2024 17:02, Paweł Anikiel wrote:
> The Chameleon v3 uses the framebuffer IP core to take the video signal
> from different sources and directly write frames into memory.
>
> Signed-off-by: Paweł Anikiel <panikiel@...gle.com>
..
> +
> + reg:
> + items:
> + - description: core registers
> + - description: irq registers
> +
> + interrupts:
> + maxItems: 1
> +
> + google,legacy-format:
> + type: boolean
> + description: The incoming video stream is in 32-bit padded mode.
Why is this a property of board DTS? Can't the input streams change
depending on the usage? Who defines the incoming stream format?
> +
Best regards,
Krzysztof
Powered by blists - more mailing lists