linux-kernel - Re: [PATCH] drm: bridge: fsl-ldb: fixup mode on freq mismatch

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: <a07188ac-0bca-4ae2-8bec-c4ec504af46e@denx.de>
Date: Mon, 9 Dec 2024 22:46:18 +0100
From: Marek Vasut <marex@...x.de>
To: Nikolaus Voss <nv@...n.de>
Cc: Liu Ying <victor.liu@....nxp.com>,
 Alexander Stein <alexander.stein@...tq-group.com>,
 Liu Ying <victor.liu@....com>, Luca Ceresoli <luca.ceresoli@...tlin.com>,
 Fabio Estevam <festevam@...x.de>, Andrzej Hajda <andrzej.hajda@...el.com>,
 Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>,
 Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
 Jonas Karlman <jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>,
 David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
 dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
 nikolaus.voss@...g-streit.com, miquel.raynal@...tlin.com
Subject: Re: [PATCH] drm: bridge: fsl-ldb: fixup mode on freq mismatch

On 12/9/24 9:46 AM, Nikolaus Voss wrote:

Hi,

>>>>> and store the panel's timing in EDID EEPROM.
>>>> Oh, that is a new one. Does the EDID EEPROM store the entirety of
>>>> 'struct display_timing {}' somehow , or is that a custom format ?
>>>
>>> Well, sort of ;-). VESA has taken care of this 30 years ago
>>> (https://en.wikipedia.org/wiki/Extended_Display_Identification_Data).
>>>
>>> DRM handles this with drm_get_edid() and siblings, e.g. :
>>
>> EDID can not encode all the information in struct display_timing {} ,
>> or can it ?
>>
>> I think what you would be missing are bus_flags , bus_format and
>> possibly the single/dual link and channel (odd/even) mapping, won't
>> you ?
> 
> Yes, that's right. I use the vendor block for bus_flags and bus_format
> now, but that's not standard and not portable of course.
> 
> My first idea was to store the DT overlay in the display EEPROM but
> a standard 1k EEPROM is too small for that.
Understood. I had the same problem, in the end I went for custom 
encoding in the EEPROM but the amount of panels was limited in my case.

Indeed, DTO does not fit the EEPROM and EDID is not really fitting too 
well to DPI/LVDS panels, it has too many fields that are specific to 
regular pluggable panels and not useful on DPI/LVDS ones.