archive mirror
 help / color / mirror / Atom feed
From: Andrzej Hajda <>
To: Douglas Anderson <>,
	Thierry Reding <>,
	Rob Herring <>, Sam Ravnborg <>
	"Maxime Ripard" <>,,
	"NXP Linux Team" <>,,,,,,,,,
	"Łukasz Stelmach" <>
Subject: Re: [PATCH v3 00/16] eDP: Support probing eDP panels dynamically instead of hardcoding
Date: Fri, 3 Sep 2021 00:10:06 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Removed most CC: SMTP server protested.

On 01.09.2021 22:19, Douglas Anderson wrote:
> The goal of this patch series is to move away from hardcoding exact
> eDP panels in device tree files. As discussed in the various patches
> in this series (I'm not repeating everything here), most eDP panels
> are 99% probable and we can get that last 1% by allowing two "power
> up" delays to be specified in the device tree file and then using the
> panel ID (found in the EDID) to look up additional power sequencing
> delays for the panel.
> This patch series is the logical contiunation of a previous patch
> series where I proposed solving this problem by adding a
> board-specific compatible string [1]. In the discussion that followed
> it sounded like people were open to something like the solution
> proposed in this new series.
> In version 2 I got rid of the idea that we could have a "fallback"
> compatible string that we'd use if we didn't recognize the ID in the
> EDID. This simplifies the bindings a lot and the implementation
> somewhat. As a result of not having a "fallback", though, I'm not
> confident in transitioning any existing boards over to this since
> we'll have to fallback to very conservative timings if we don't
> recognize the ID from the EDID and I can't guarantee that I've seen
> every panel that might have shipped on an existing product. The plan
> is to use "edp-panel" only on new boards or new revisions of old
> boards where we can guarantee that every EDID that ships out of the
> factory has an ID in the table.
> Version 3 of this series now splits out all eDP panels to their own
> driver and adds the generic eDP panel support to this new driver. I
> believe this is what Sam was looking for [2].
> [1]
> [2]
I like the idea - if something can be configured dynamically lets do it.
But I have few questions:
1. Have you read different real panels id's? In many cases (MIPI DSI, 
LVDS with EDID) manufacturers often forgot to set proper id fields. I do 
not know how EDID's ids are reliable in case of edp panels.
2. You are working with edp panels - beside EDID they have DPCD which 
contains things like IEEE_OUI and "Device Identification String", I 
guess they could be also used for detecting panels, have you considered 
it? I think DPCD Id should be assigned to EDP-Sink interface, and EDID 
Id to the actual panel behind it. With this assumption one could 
consider which timings should be property of which entity.


  parent reply	other threads:[~2021-09-02 22:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-01 20:19 [PATCH v3 00/16] eDP: Support probing eDP panels dynamically instead of hardcoding Douglas Anderson
2021-09-01 20:19 ` [PATCH v3 06/16] ARM: configs: Everyone who had PANEL_SIMPLE now gets PANEL_SIMPLE_EDP Douglas Anderson
2021-09-01 21:12   ` Olof Johansson
2021-09-01 23:10     ` Doug Anderson
     [not found]       ` <>
2021-09-03  7:18         ` Andrzej Hajda
     [not found]       ` <>
2021-09-08 22:36         ` Doug Anderson
2021-09-08 23:08           ` Olof Johansson
     [not found] ` <>
2021-09-02 22:10   ` Andrzej Hajda [this message]
2021-09-02 22:33     ` [PATCH v3 00/16] eDP: Support probing eDP panels dynamically instead of hardcoding Doug Anderson
     [not found] ` <>
2021-09-09  0:24   ` Doug Anderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).