[PATCH/RFC v3 00/19] Common Display Framework

[Rob Clark]

On Mon, Sep 9, 2013 at 8:12 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> On 21/08/13 15:22, Rob Clark wrote:
>
>> And just to be clear, part of my negative experience about this is the
>> omapdss/omapdrm split.  I just see cfd outside of drm as encouraging
>> others to make the same mistake.
>
> Feel free to disagree, but I think the omapdss/omapdrm split is a bit
> different matter. The main problem there was splitting the control of a
> single device (OMAP DSS, and more specifically, DISPC) into two.

I don't completely care about the *device* split (we have drm drivers
that are multiple devices), as much as the directory and code layout
split.

We have helper code for edid probing, DP, etc in drm.  Drivers should
be using this to avoid duplicating code unnecessarily.  But that gets
difficult when the drivers are outside of drm.  (That is the best case
scenario, assuming we avoid any impedance mismatch between CDF and
KMS, that we come up with a way to share property code, etc.)

I don't see any way that putting it outside of drm/kms makes anything
any easier.. and I see plenty of potential for making things harder.
I have enough other work to do, hence I vote for 'easier' ;-)

That all said, I don't think CDF really changes anything from the
perspective of needing drm_bridge, drm_panel, etc.  I suppose they can
co-exist, possibly in some cases drm/kms objects are just wrappers for
CDF objects.  But if I do see new driver code that is duplicating what
can be done w/ helpers in drm (see drivers/video/exynos/*dp*), or with
unnecessary complexity, I would nak it.. just the same as I would do
with new drivers in drm which aren't using the appropriate helpers,
etc.

BR,
-R


> I don't see CDF causing anything similar. A single DRM driver should
> manage the DISPC in OMAP's case, and it should (probably) also control
> the external encoders and panel, even if those are independent CDF drivers.
>
>  Tomi
>
>