On Tue, Feb 19, 2019 at 6:54 AM Rob Herring [off-list ref] wrote:
quoted
I believe using eDP connector binding wouldn't help much in my case
and it won't improve accuracy of hardware description while adding
unnecessary code duplication (edp-connector will be pretty much
simple-panel).
Since currently there're no standalone connector drivers, implementing
one requires significant refactoring of the code that I'm not
familiar.
I'm not talking about drivers. I'm talking about bindings. Those are
not necessarily 1-1. There's no reason the simple panel driver can't
have an 'edp-connector' entry.
These aren't independent things. Bindings are useless without drivers.
Also how are you going to address mainlined platforms that have eDP
and use panel bindings? E.g. rk3399 supports eDP and uses panel
binding - see rk3399-gru-kevin.dts as example.
Also, since you have EDID, you should be using that for timing data
IMO, and the binding needs to have enough information to support that.
It may if DP-aux comes from the bridge chip or it may not if you need
to describe that connection. Again, this is independent from what
Linux chooses to do. If Linux chooses to have its own timing
information that's its choice. Another OS may choose to use EDID.
I see nothing wrong here - anx6345 driver reads EDID (over AUX) and
uses timing from it, if reading EDID failed it fallback to timings
defined in panel driver.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel