[PATCH v2 7/9] media: dt-bindings: Add Chameleon v3 framebuffer
Paweł Anikiel
panikiel at google.com
Tue Apr 23 17:00:53 UTC 2024
Hi, sorry for the long delay
On Mon, Feb 26, 2024 at 10:10 AM Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
>
> 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 at google.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?
The input streams are defined by this hardware module - there are
specific input lines for red, green, blue channels, h/v sync, etc.
However, there are two variants of this module which behave
differently - one has 60 input lines and outputs BGRX32, and the other
one has 192 input lines and outputs RGB24.
The "incoming 32-bit padded mode" referred to an internal bus inside
of the module, which I realize isn't very meaningful. Instead, I think
it would be better to have two compatibles, one for each variant of
the module.
More information about the dri-devel
mailing list