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

[Rob Clark]

On Mon, Sep 9, 2013 at 10:58 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> 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.

yeah, I wasn't particularly referring to that (although it would have
been quicker to fix if it was all in drm)

> 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.

If there are easy / non-intrusive ways to make helpers more generic, I
don't mind.  But for better or for worse, drm/kms is the modern
display framework for the kernel, so moving helpers outside of drm
isn't something I'm going to go out of my way to do.  And, speaking
with my distro-hat on, dependencies outside of drm make my work harder
to backport new hw support of bugfixes to long-term supported distro
kernels..  but that doesn't stop us, when there is good reason to do
so (see ww_mutex, for example), but it doesn't make me super excited
about increasing dependencies outside of drm when there is no good
reason.  I suppose the folks porting drm/kms drivers to *BSD probably
feel the same way.

BR,
-R

>  Tomi
>
>