On Tue, Jul 09, 2019 at 04:58:35PM +0800, Icenowy Zheng wrote:

于 2019年7月9日 GMT+08:00 下午4:55:32, Maxime Ripard [off-list ref] 写到:

quoted

On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote:

quoted

quoted

quoted

Maybe instead of edp-connector one would introduce integrator's

specific

quoted

quoted

quoted

connector, for example with compatible

"olimex,teres-edp-connector"

quoted

quoted

quoted

which should follow edp abstract connector rules? This will be at

least

quoted

quoted

quoted

consistent with below presentation[1] - eDP requirements depends

on

quoted

quoted

quoted

integrator. Then if olimex has standard way of dealing with

panels

quoted

quoted

quoted

present in olimex/teres platforms the driver would then create
drm_panel/drm_connector/drm_bridge(?) according to these rules, I

guess.

quoted

quoted

quoted

Anyway it still looks fishy for me :), maybe because I am not
familiarized with details of these platforms.

That makes sense yes

Actually, it makes no sense at all. Current implementation for

anx6345

quoted

driver works fine as is with any panel specified assuming panel

delays

quoted

are long enough for connected panel. It just doesn't use panel

timings

quoted

from the driver. Creating a platform driver for connector itself

looks

quoted

redundant since it can't be reused, it doesn't describe actual
hardware and it's just defeats purpose of DT by introducing
board-specific code.

I'm not sure where you got the idea that the purpose of DT is to not
have any board-specific code.

It's perfectly fine to have some, that's even why there's a compatible
assigned to each and every board.

What the DT is about is allowing us to have a generic behaviour that
we can detect: we can have a given behaviour for a given board, and a
separate one for another one, and this will be evaluated at runtime.

This is *exactly* what this is about: we can have a compatible that
sets a given, more specific, behaviour (olimex,teres-edp-connector)
while saying that this is compatible with the generic behaviour
(edp-connector). That way, any OS will know what quirk to apply if
needed, and if not that it can use the generic behaviour.

And we could create a generic driver, for the generic behaviour if
needed.

quoted

There's another issue: if we introduce edp-connector we'll have to
specify power up delays somewhere (in dts? or in platform driver?),

so

quoted

edp-connector doesn't really solve the issue of multiple panels with
same motherboard.

And that's what that compatible is about :)

Maybe we can introduce a connector w/o any driver just like hdmi-connector?

Ironically, a driver for it has been sent yesterday :)

But yeah, we can definitely do that too.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com