linux-kernel - Re: [PATCH] dt-bindings: lcdif: Add support for specifying display with timings

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]

Message-ID: <16316a89-04f8-4a63-b453-45562e4294d7@denx.de>
Date: Wed, 25 Sep 2024 01:44:14 +0200
From: Marek Vasut <marex@...x.de>
To: Rob Herring <robh@...nel.org>
Cc: Lukasz Majewski <lukma@...x.de>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
 Stefan Agner <stefan@...er.ch>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Fabio Estevam <festevam@...il.com>, Maxime Ripard <mripard@...nel.org>,
 Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>, dri-devel@...ts.freedesktop.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dt-bindings: lcdif: Add support for specifying display
 with timings

On 9/25/24 12:57 AM, Rob Herring wrote:
> On Mon, Sep 23, 2024 at 07:53:57PM +0200, Marek Vasut wrote:
>> On 9/23/24 3:57 PM, Lukasz Majewski wrote:
>>> Up till now the fsl,lcdif.yaml was requiring the "port" property as a
>>> must have to specify the display interface on iMX devices.
>>>
>>> However, it shall also be possible to specify the display only with
>>> passing its timing parameters (h* and v* ones) via "display" property:
>>> (as in
>>> Documentation/devicetree/bindings/display/panel/display-timings.yaml).
>>
>> Timings should go into panel node, not into scanout engine node.
>>
>> See e.g. panel-timings in arch/arm64/boot/dts/freescale/imx8mm-phg.dts , in
>> your case the compatible might be "panel-dpi" .
> 
> I agree, but if this is already in use, we should allow it. We can mark
> it deprecated though.
I don't think it is in use yet, at least not in upstream, so let's not 
allow this.