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

[Tomi Valkeinen]

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

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130909/aec7acde/attachment.pgp>