On 09/09/13 17:17, Rob Clark wrote: > On Mon, Sep 9, 2013 at 8:12 AM, Tomi Valkeinen <tomi.valkei...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
