From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcus Lorentzon <marcus.xm.lorentzon@stericsson.com>
Subject: Re: CDF meeting @FOSDEM report
Date: Wed, 13 Feb 2013 10:25:14 +0100
Message-ID: <511B5BFA.4050005@stericsson.com>
References: <1990856.qS9uisuiVF@avalon>
	<CACP_E+JRVppfvJBGqHk0fTCyN7Yb0LF4fbX_c0EGNAxE8wiCkQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Content-Transfer-Encoding: quoted-printable
Return-path: <dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org>
Received: from eu1sys200aog114.obsmtp.com (eu1sys200aog114.obsmtp.com
	[207.126.144.137])
	by gabe.freedesktop.org (Postfix) with ESMTP id 34CE4E5D50
	for <dri-devel@lists.freedesktop.org>;
	Wed, 13 Feb 2013 01:25:46 -0800 (PST)
In-Reply-To: <CACP_E+JRVppfvJBGqHk0fTCyN7Yb0LF4fbX_c0EGNAxE8wiCkQ@mail.gmail.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/dri-devel>
List-Post: <mailto:dri-devel@lists.freedesktop.org>
List-Help: <mailto:dri-devel-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=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: =?ISO-8859-1?Q?St=E9phane_Marchesin?= <stephane.marchesin@gmail.com>
Cc: "linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>, Sebastien Guiriec <s-guiriec@ti.com>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, Jesse Barnes <jesse.barnes@intel.com>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Benjamin Gaignard <benjamin.gaignard@linaro.org>, Sumit Semwal <sumit.semwal@linaro.org>, Tom Gall <tom.gall@linaro.org>, Kyungmin Park <kyungmin.park@samsung.com>, Tomi Valkeinen <tomi.valkeinen@ti.com>, "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>, Stephen Warren <swarren@wwwdotorg.org>, Mark Zhang <markz@nvidia.com>, "linaro-mm-sig@lists.linaro.org" <linaro-mm-sig@lists.linaro.org>, Alexandre Courbot <acourbot@nvidia.com>, Ragesh Radhakrishnan <Ragesh.R@linaro.org>, Thomas Petazzoni <thomas.petazzoni@free-electrons.com>, Sunil Joshi <joshi@samsung.com>, Maxime Ripard <maxime.ripard@free-electro>
List-Id: dri-devel@lists.freedesktop.org

On 02/12/2013 11:45 PM, St=E9phane Marchesin wrote:
>> - Do we need to support chaining several encoders ? We can come up with
>> >  several theoretical use cases, some of them probably exist in real ha=
rdware,
>> >  but the details are still a bit fuzzy.
> So, a part which is completely omitted in this thread is how to handle
> suspend/resume ordering. If you have multiple encoders which need to
> be turned on/off in a given order at suspend/resume, how do you handle
> that given the current scheme where they are just separate platform
> drivers in drivers/video?
>
> This problems occurs with drm/exynos in current 3.8 kernels for
> example. On that platform, the DP driver and the FIMD driver will
> suspend/resume in random order, and therefore fail resuming half the
> time. Is there something which could be done in CDF to address that?
My idea here is two parts. First hide the chaining within the CDF =

driver. So it is always the first CDF driver that is responsible for the =

rest of the chain. Second, I'm looking at using the dev->parent and bus =

relationchip to describe this dependency. Then power usually works out =

fine, since children could be forced to be suspended before parent =

("bus" host).

/BR
/Marcus