From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Clark Subject: Re: [PATCH/RFC v3 00/19] Common Display Framework Date: Mon, 9 Sep 2013 10:17:27 -0400 Message-ID: References: <1376068510-30363-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com> <1599910.F5touEILFq@avalon> <20130821070947.GM31036@pengutronix.de> <522DBB38.2040109@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by gabe.freedesktop.org (Postfix) with ESMTP id 7E1ABE603F for ; Mon, 9 Sep 2013 07:17:28 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id y16so7273508ieg.26 for ; Mon, 09 Sep 2013 07:17:28 -0700 (PDT) In-Reply-To: <522DBB38.2040109@ti.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Tomi Valkeinen Cc: Linux Fbdev development list , "dri-devel@lists.freedesktop.org" , Jesse Barnes , Laurent Pinchart , Benjamin Gaignard , Laurent Pinchart , Tom Gall , Ragesh Radhakrishnan , "linux-media@vger.kernel.org" , Stephen Warren , Mark Zhang , Alexandre Courbot , Thomas Petazzoni , Sunil Joshi , Kyungmin Park , Maxime Ripard , Vikas Sajjan , Marcus Lorentzon List-Id: dri-devel@lists.freedesktop.org On Mon, Sep 9, 2013 at 8:12 AM, Tomi Valkeinen 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 > >