linux-kernel - Re: [PATCH 3/5] dt-bindings: display: simple-bridge: Document DPI color encoder

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1891036.atdPhlSkOF@steina-w>
Date: Wed, 05 Mar 2025 10:35:26 +0100
From: Alexander Stein <alexander.stein@...tq-group.com>
To: Liu Ying <victor.liu@....com>, dri-devel@...ts.freedesktop.org
Cc: dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
 andrzej.hajda@...el.com, neil.armstrong@...aro.org, rfoss@...nel.org,
 Laurent.pinchart@...asonboard.com, jonas@...boo.se, jernej.skrabec@...il.com,
 maarten.lankhorst@...ux.intel.com, mripard@...nel.org, tzimmermann@...e.de,
 airlied@...il.com, simona@...ll.ch, Rob Herring <robh@...nel.org>
Subject:
 Re: [PATCH 3/5] dt-bindings: display: simple-bridge: Document DPI color
 encoder

Hi,

Am Dienstag, 4. März 2025, 16:23:20 CET schrieb Rob Herring:
> On Tue, Mar 04, 2025 at 06:15:28PM +0800, Liu Ying wrote:
> > A DPI color encoder, as a simple display bridge, converts input DPI color
> > coding to output DPI color coding, like Adafruit Kippah DPI hat[1] which
> > converts input 18-bit pixel data to 24-bit pixel data(with 2 low padding
> > bits in every color component though). Document the DPI color encoder.
> 
> Why do we need a node for this? Isn't this just wired how it is wired 
> and there's nothing for s/w to see or do? I suppose if you are trying to 
> resolve the mode with 24-bit on one end and 18-bit on the other end, you 
> need to allow that and not require an exact match. You still might need 
> to figure out which pins the 18-bit data comes out on, but you have that 
> problem with an 18-bit panel too. IOW, how is this any different if you 
> have an 18-bit panel versus 24-bit panel?

Especially panel-simple.c has a fixed configuration for each display, such as:
> .bus_format = MEDIA_BUS_FMT_RGB666_1X18

How would you allow or even know it should be addressed as
MEDIA_BUS_FMT_RGB888_1X24 instead? I see different ways:
1. Create a new display setting/compatible
2. Add an overwrite property to the displays
3. Use a (transparent) bridge (this series)

Number 1 is IMHO out of question. I personally don't like number 2 as this
feels like adding quirks to displays, which they don't have.
Number 3 actually describe the hardware connection. The only impact for
software is to know which bus format it should use.

Best regards
Alexander
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/