linux-kernel - Re: [PATCH v2 7/9] media: dt-bindings: Add Chameleon v3 framebuffer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Tue, 23 Apr 2024 19:00:53 +0200
From: Paweł Anikiel <panikiel@...gle.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: 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, 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

Hi, sorry for the long delay

On Mon, Feb 26, 2024 at 10:10 AM Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.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@...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?

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.