[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250304152320.GA2630063-robh@kernel.org>
Date: Tue, 4 Mar 2025 09:23:20 -0600
From: Rob Herring <robh@...nel.org>
To: Liu Ying <victor.liu@....com>
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
Subject: Re: [PATCH 3/5] dt-bindings: display: simple-bridge: Document DPI
color encoder
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?
Rob
Powered by blists - more mailing lists