From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Packard Date: Sat, 18 Feb 2012 00:56:49 +0000 Subject: Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes Message-Id: <867gzlarhq.fsf@sumi.keithp.com> List-Id: References: <201201171126.42675.laurent.pinchart@ideasonboard.com> <1654816.MX2JJ87BEo@avalon> <1775349.d0yvHiVdjB@avalon> In-Reply-To: <1775349.d0yvHiVdjB@avalon> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Laurent Pinchart Laurent Pinchart Cc: Tomasz Stanislawski , linux-fbdev@vger.kernel.org, Sakari Ailus , Pawel Osciak , Marcus Lorentzon , Magnus Damm , dri-devel@lists.freedesktop.org, Alexander Deucher , Rob Clark , Marek Szyprowski , linux-media@vger.kernel.org <#part sign=pgpmime> On Fri, 17 Feb 2012 00:25:51 +0100, Laurent Pinchart wrote: > *** Synchronous pipeline changes *** > > Goal: Create an API to apply complex changes to a video pipeline atomically. > > Needed for complex camera use cases. On the DRM/KMS side, the approach is to > use one big ioctl to configure the whole pipeline. This is the only credible approach for most desktop chips -- you must have the whole configuration available before you can make any commitment to supporting the requested modes. > One solution is a commit ioctl, through the media controller device, that > would be dispatched to entities internally with a prepare step and a commit > step. The current plan for the i915 KMS code is to use a single ioctl -- the application sends a buffer full of configuration commands down to the kernel which can then figure out whether it can be supported or not. The kernel will have to store the intermediate data until the commit arrives anyways, and you still need a central authority in the kernel controlling the final commit decision. -- keith.packard@intel.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Packard Subject: Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes Date: Sat, 18 Feb 2012 13:56:49 +1300 Message-ID: <867gzlarhq.fsf@sumi.keithp.com> References: <201201171126.42675.laurent.pinchart@ideasonboard.com> <1654816.MX2JJ87BEo@avalon> <1775349.d0yvHiVdjB@avalon> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from keithp.com (home.keithp.com [63.227.221.253]) by gabe.freedesktop.org (Postfix) with ESMTP id 9FFF29E803 for ; Sun, 19 Feb 2012 00:56:24 -0800 (PST) In-Reply-To: <1775349.d0yvHiVdjB@avalon> 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 Laurent Pinchart Cc: Tomasz Stanislawski , linux-fbdev@vger.kernel.org, Sakari Ailus , Pawel Osciak , Marcus Lorentzon , Magnus Damm , dri-devel@lists.freedesktop.org, Alexander Deucher , Rob Clark , Marek Szyprowski , linux-media@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org <#part sign=pgpmime> On Fri, 17 Feb 2012 00:25:51 +0100, Laurent Pinchart wrote: > *** Synchronous pipeline changes *** > > Goal: Create an API to apply complex changes to a video pipeline atomically. > > Needed for complex camera use cases. On the DRM/KMS side, the approach is to > use one big ioctl to configure the whole pipeline. This is the only credible approach for most desktop chips -- you must have the whole configuration available before you can make any commitment to supporting the requested modes. > One solution is a commit ioctl, through the media controller device, that > would be dispatched to entities internally with a prepare step and a commit > step. The current plan for the i915 KMS code is to use a single ioctl -- the application sends a buffer full of configuration commands down to the kernel which can then figure out whether it can be supported or not. The kernel will have to store the intermediate data until the commit arrives anyways, and you still need a central authority in the kernel controlling the final commit decision. -- keith.packard@intel.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from home.keithp.com ([63.227.221.253]:33523 "EHLO keithp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752694Ab2BSI41 (ORCPT ); Sun, 19 Feb 2012 03:56:27 -0500 From: Keith Packard To: Laurent Pinchart , Laurent Pinchart Cc: Tomasz Stanislawski , linux-fbdev@vger.kernel.org, Sakari Ailus , Pawel Osciak , Magnus Damm , Marcus Lorentzon , dri-devel@lists.freedesktop.org, Alexander Deucher , Rob Clark , linux-media@vger.kernel.org, Marek Szyprowski Subject: Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes In-Reply-To: <1775349.d0yvHiVdjB@avalon> References: <201201171126.42675.laurent.pinchart@ideasonboard.com> <1654816.MX2JJ87BEo@avalon> <1775349.d0yvHiVdjB@avalon> Date: Sat, 18 Feb 2012 13:56:49 +1300 Message-ID: <867gzlarhq.fsf@sumi.keithp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-media-owner@vger.kernel.org List-ID: <#part sign=pgpmime> On Fri, 17 Feb 2012 00:25:51 +0100, Laurent Pinchart wrote: > *** Synchronous pipeline changes *** > > Goal: Create an API to apply complex changes to a video pipeline atomically. > > Needed for complex camera use cases. On the DRM/KMS side, the approach is to > use one big ioctl to configure the whole pipeline. This is the only credible approach for most desktop chips -- you must have the whole configuration available before you can make any commitment to supporting the requested modes. > One solution is a commit ioctl, through the media controller device, that > would be dispatched to entities internally with a prepare step and a commit > step. The current plan for the i915 KMS code is to use a single ioctl -- the application sends a buffer full of configuration commands down to the kernel which can then figure out whether it can be supported or not. The kernel will have to store the intermediate data until the commit arrives anyways, and you still need a central authority in the kernel controlling the final commit decision. -- keith.packard@intel.com