From mboxrd@z Thu Jan 1 00:00:00 1970 From: Archit Taneja Subject: Re: Synchronization between a crtc mode_set and page_flip? Date: Fri, 4 Apr 2014 12:51:12 +0530 Message-ID: <533E5D68.6040008@ti.com> References: <533BDDEF.1050900@ti.com> <533D22B8.7040908@ti.com> <20140403212459.GR7225@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from arroyo.ext.ti.com (arroyo.ext.ti.com [192.94.94.40]) by gabe.freedesktop.org (Postfix) with ESMTP id 1E73A6EC9B for ; Fri, 4 Apr 2014 00:22:11 -0700 (PDT) In-Reply-To: <20140403212459.GR7225@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter Cc: "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org On Friday 04 April 2014 02:54 AM, Daniel Vetter wrote: > On Thu, Apr 03, 2014 at 02:28:32PM +0530, Archit Taneja wrote: >> On Wednesday 02 April 2014 06:41 PM, Rob Clark wrote: >>> On Wed, Apr 2, 2014 at 5:52 AM, Archit Taneja wrote: >>>> Hi, >>>> >>>> I was trying to figure out how we are supposed to manage synchronization >>>> between a mode_set and a page_flip called on a crtc. >>>> >>>> Say, if a mode_set is immediately followed by a page_flip. The driver can't >>>> process the page_flip straight away since the hardware is still completing >>>> the mode_set. >>> >>> I guess setcrtc is expected to be synchronous(ish).. so a lot of >>> userspace won't expect the first pageflip to fail with -EBUSY. >> >> Okay, thanks. I guess having setcrtc synchronous isn't that bad. > > Yeah, atm I think the rules are that pageflip can only return -EBUSY if > there's still a pageflip ongoing. Everything else is presumed to be at > least implicitly ordered, so if your hw can do async modesets then you > need to synchronize. Also if there's still a pageflip outstanding you need > to wait for that to complete in your set_config callback first (usually in > the set_base or the crtc->disable/prepare hooks when using the crtc > helpers). Thanks for the info. I didn't realize that the prepare/commit hooks get executed when using drm_crtc_helper_set_mode() for the set_config helper. Rob, We disable the crtc in prepare, and enable it in commit. If setcrtc changes the mode, I don't see how apply worker can execute prepare() -> mode_set() -> commit() hooks in a row for the crtc drm_crtc_helper_set_mode(). We can't queue more than one 'apply' of the same entity. So the latter queues are bound to get rejected, I see omap_crtc_apply() bailing out for crtc's apply in this case. I guess making prepare() and mode_set() wait for a vsync should fix this. Or, combining mode_set and commit as a single queue to apply should work too. Any suggestions? Thanks, Archit