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

From: Rob Clark <robdclark@gmail.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	Jesse Barnes <jesse.barnes@intel.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Benjamin Gaignard <benjamin.gaignard@linaro.org>,
	Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	Tom Gall <tom.gall@linaro.org>,
	Ragesh Radhakrishnan <Ragesh.R@linaro.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Mark Zhang <markz@nvidia.com>,
	Alexandre Courbot <acourbot@nvidia.com>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Sunil Joshi <joshi@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	Vikas Sajjan <vikas.sajjan@linaro.org>,
	Marcus Lorentzon <marcus.lorentzon@huawei.com>
Subject: Re: [PATCH/RFC v3 00/19] Common Display Framework
Date: Mon, 9 Sep 2013 10:17:27 -0400	[thread overview]
Message-ID: <CAF6AEGu8Ks7P6=h3C=QOQd-vWq+QEzURAV_L8xZ+bT0etf=PXA@mail.gmail.com> (raw)
In-Reply-To: <522DBB38.2040109@ti.com>

On Mon, Sep 9, 2013 at 8:12 AM, Tomi Valkeinen <tomi.valkeinen@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
>
>