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

From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Rob Clark <robdclark@gmail.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 17:58:06 +0300	[thread overview]
Message-ID: <522DE1FE.9030508@ti.com> (raw)
In-Reply-To: <CAF6AEGu8Ks7P6=h3C=QOQd-vWq+QEzURAV_L8xZ+bT0etf=PXA@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 1729 bytes --]

On 09/09/13 17:17, Rob Clark wrote:
> 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.)

Ok, I thought you were referring to the apply etc. stuff we spent lots
of time solving for omapdss/omapdrm. That all was caused by the split we
have for the control for DISPC.

I, on the other hand, don't so much care about duplicating code. Sure, I
always try to avoid it. But if I need a helper in non-DRM context that
does the same thing as a helper DRM already has, I don't see any issue
in implementing it.

In fact, I'd prefer at least some of the helpers DRM has (say, videomode
related and EDID parsing) to be moved out from DRM. There's no reason to
tie them to DRM. That would avoid code duplication.

 Tomi

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel