From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-ob0-f169.google.com ([209.85.214.169]:49327 "EHLO mail-ob0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750854Ab2LRFJh (ORCPT ); Tue, 18 Dec 2012 00:09:37 -0500 MIME-Version: 1.0 In-Reply-To: <1353620736-6517-1-git-send-email-laurent.pinchart@ideasonboard.com> References: <1353620736-6517-1-git-send-email-laurent.pinchart@ideasonboard.com> Date: Tue, 18 Dec 2012 15:04:02 +1000 Message-ID: Subject: Re: [RFC v2 0/5] Common Display Framework From: Dave Airlie To: Laurent Pinchart Cc: linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org, Archit Taneja , Benjamin Gaignard , Bryan Wu , Inki Dae , Jesse Barker , Kyungmin Park , Marcus Lorentzon , Maxime Ripard , Philipp Zabel , Ragesh Radhakrishnan , Rob Clark , Sascha Hauer , Sebastien Guiriec , Sumit Semwal , Thomas Petazzoni , Tom Gall , Tomi Valkeinen , Vikas Sajjan Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-media-owner@vger.kernel.org List-ID: > > Many developers showed interest in the first RFC, and I've had the opportunity > to discuss it with most of them. I would like to thank (in no particular > order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus > Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for > inviting me to Connect and providing a venue to discuss this topic. > So this might be a bit off topic but this whole CDF triggered me looking at stuff I generally avoid: The biggest problem I'm having currently with the whole ARM graphics and output world is the proliferation of platform drivers for every little thing. The whole ordering of operations with respect to things like suspend/resume or dynamic power management is going to be a real nightmare if there are dependencies between the drivers. How do you enforce ordering of s/r operations between all the various components? The other thing I'd like you guys to do is kill the idea of fbdev and v4l drivers that are "shared" with the drm codebase, really just implement fbdev and v4l on top of the drm layer, some people might think this is some sort of maintainer thing, but really nothing else makes sense, and having these shared display frameworks just to avoid having using drm/kms drivers seems totally pointless. Fix the drm fbdev emulation if an fbdev interface is needed. But creating a fourth framework because our previous 3 frameworks didn't work out doesn't seem like a situation I want to get behind too much. Dave. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Airlie Date: Tue, 18 Dec 2012 05:04:02 +0000 Subject: Re: [RFC v2 0/5] Common Display Framework Message-Id: List-Id: References: <1353620736-6517-1-git-send-email-laurent.pinchart@ideasonboard.com> In-Reply-To: <1353620736-6517-1-git-send-email-laurent.pinchart@ideasonboard.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Laurent Pinchart Cc: Thomas Petazzoni , linux-fbdev@vger.kernel.org, Philipp Zabel , Tom Gall , Ragesh Radhakrishnan , dri-devel@lists.freedesktop.org, Rob Clark , Kyungmin Park , Tomi Valkeinen , Benjamin Gaignard , Bryan Wu , Maxime Ripard , Vikas Sajjan , Sumit Semwal , Sebastien Guiriec , linux-media@vger.kernel.org > > Many developers showed interest in the first RFC, and I've had the opportunity > to discuss it with most of them. I would like to thank (in no particular > order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus > Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for > inviting me to Connect and providing a venue to discuss this topic. > So this might be a bit off topic but this whole CDF triggered me looking at stuff I generally avoid: The biggest problem I'm having currently with the whole ARM graphics and output world is the proliferation of platform drivers for every little thing. The whole ordering of operations with respect to things like suspend/resume or dynamic power management is going to be a real nightmare if there are dependencies between the drivers. How do you enforce ordering of s/r operations between all the various components? The other thing I'd like you guys to do is kill the idea of fbdev and v4l drivers that are "shared" with the drm codebase, really just implement fbdev and v4l on top of the drm layer, some people might think this is some sort of maintainer thing, but really nothing else makes sense, and having these shared display frameworks just to avoid having using drm/kms drivers seems totally pointless. Fix the drm fbdev emulation if an fbdev interface is needed. But creating a fourth framework because our previous 3 frameworks didn't work out doesn't seem like a situation I want to get behind too much. Dave. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Airlie Subject: Re: [RFC v2 0/5] Common Display Framework Date: Tue, 18 Dec 2012 15:04:02 +1000 Message-ID: References: <1353620736-6517-1-git-send-email-laurent.pinchart@ideasonboard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by gabe.freedesktop.org (Postfix) with ESMTP id AD0DEE5E0E for ; Mon, 17 Dec 2012 21:04:03 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id oi10so187952obb.12 for ; Mon, 17 Dec 2012 21:04:03 -0800 (PST) In-Reply-To: <1353620736-6517-1-git-send-email-laurent.pinchart@ideasonboard.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: Laurent Pinchart Cc: Thomas Petazzoni , linux-fbdev@vger.kernel.org, Philipp Zabel , Tom Gall , Ragesh Radhakrishnan , dri-devel@lists.freedesktop.org, Rob Clark , Kyungmin Park , Tomi Valkeinen , Benjamin Gaignard , Bryan Wu , Maxime Ripard , Vikas Sajjan , Sumit Semwal , Sebastien Guiriec , linux-media@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org > > Many developers showed interest in the first RFC, and I've had the opportunity > to discuss it with most of them. I would like to thank (in no particular > order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus > Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for > inviting me to Connect and providing a venue to discuss this topic. > So this might be a bit off topic but this whole CDF triggered me looking at stuff I generally avoid: The biggest problem I'm having currently with the whole ARM graphics and output world is the proliferation of platform drivers for every little thing. The whole ordering of operations with respect to things like suspend/resume or dynamic power management is going to be a real nightmare if there are dependencies between the drivers. How do you enforce ordering of s/r operations between all the various components? The other thing I'd like you guys to do is kill the idea of fbdev and v4l drivers that are "shared" with the drm codebase, really just implement fbdev and v4l on top of the drm layer, some people might think this is some sort of maintainer thing, but really nothing else makes sense, and having these shared display frameworks just to avoid having using drm/kms drivers seems totally pointless. Fix the drm fbdev emulation if an fbdev interface is needed. But creating a fourth framework because our previous 3 frameworks didn't work out doesn't seem like a situation I want to get behind too much. Dave.