* Synchronization between a crtc mode_set and page_flip? @ 2014-04-02 9:52 Archit Taneja 2014-04-02 13:11 ` Rob Clark 0 siblings, 1 reply; 6+ messages in thread From: Archit Taneja @ 2014-04-02 9:52 UTC (permalink / raw) To: dri-devel@lists.freedesktop.org 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. What is the driver supposed to do? Should it return -EBUSY? Or should it somehow queue the page_flip task internally? A lot of libdrm applications seem to call mode_set, and call a page_flip soon after it. They tend to bail out if page_flip returns an error, they don't try to do another page_flip if it fails the first time. Is this okay behaviour? Thanks, Archit ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Synchronization between a crtc mode_set and page_flip? 2014-04-02 9:52 Synchronization between a crtc mode_set and page_flip? Archit Taneja @ 2014-04-02 13:11 ` Rob Clark 2014-04-03 8:58 ` Archit Taneja 0 siblings, 1 reply; 6+ messages in thread From: Rob Clark @ 2014-04-02 13:11 UTC (permalink / raw) To: Archit Taneja; +Cc: dri-devel@lists.freedesktop.org On Wed, Apr 2, 2014 at 5:52 AM, Archit Taneja <archit@ti.com> 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. BR, -R > What is the driver supposed to do? Should it return -EBUSY? Or should it > somehow queue the page_flip task internally? > > A lot of libdrm applications seem to call mode_set, and call a page_flip > soon after it. They tend to bail out if page_flip returns an error, they > don't try to do another page_flip if it fails the first time. Is this okay > behaviour? > > Thanks, > Archit > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Synchronization between a crtc mode_set and page_flip? 2014-04-02 13:11 ` Rob Clark @ 2014-04-03 8:58 ` Archit Taneja 2014-04-03 21:24 ` Daniel Vetter 0 siblings, 1 reply; 6+ messages in thread From: Archit Taneja @ 2014-04-03 8:58 UTC (permalink / raw) To: Rob Clark; +Cc: dri-devel@lists.freedesktop.org On Wednesday 02 April 2014 06:41 PM, Rob Clark wrote: > On Wed, Apr 2, 2014 at 5:52 AM, Archit Taneja <archit@ti.com> 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. Archit ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Synchronization between a crtc mode_set and page_flip? 2014-04-03 8:58 ` Archit Taneja @ 2014-04-03 21:24 ` Daniel Vetter 2014-04-04 7:21 ` Archit Taneja 0 siblings, 1 reply; 6+ messages in thread From: Daniel Vetter @ 2014-04-03 21:24 UTC (permalink / raw) To: Archit Taneja; +Cc: dri-devel@lists.freedesktop.org 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 <archit@ti.com> 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). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Synchronization between a crtc mode_set and page_flip? 2014-04-03 21:24 ` Daniel Vetter @ 2014-04-04 7:21 ` Archit Taneja 2014-04-04 11:54 ` Rob Clark 0 siblings, 1 reply; 6+ messages in thread From: Archit Taneja @ 2014-04-04 7:21 UTC (permalink / raw) To: Daniel Vetter; +Cc: 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 <archit@ti.com> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Synchronization between a crtc mode_set and page_flip? 2014-04-04 7:21 ` Archit Taneja @ 2014-04-04 11:54 ` Rob Clark 0 siblings, 0 replies; 6+ messages in thread From: Rob Clark @ 2014-04-04 11:54 UTC (permalink / raw) To: Archit Taneja; +Cc: dri-devel@lists.freedesktop.org On Fri, Apr 4, 2014 at 3:21 AM, Archit Taneja <archit@ti.com> wrote: > 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 <archit@ti.com> 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. What is *supposed* to happen is that whenever apply worker gets a chance to run, it applies whatever are the most recent settings. So even if you somehow managed to do two modesets before the apply worker had a chance to run, it would simply apply whatever is the most recent mode.. so modeset is not synchronized, but it is serialized. So we don't actually need to queue up the same apply multiple times. Looking at omap_crtc_pre_apply(), I think that should be fine. Even if we miss the dpms(OFF) from the prepare step, omap_crtc_pre_apply() will still disable and reenable power if switching encoder. That said, we probably do at least need to handle a pending pageflip during setcrtc. I think it would be reasonable to make prepare() block until no pending pageflip or apply. (Note: a pageflip to a buffer still being rendered by the GPU won't have triggered an apply *yet*) BR, -R > 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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-04-04 11:54 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-04-02 9:52 Synchronization between a crtc mode_set and page_flip? Archit Taneja 2014-04-02 13:11 ` Rob Clark 2014-04-03 8:58 ` Archit Taneja 2014-04-03 21:24 ` Daniel Vetter 2014-04-04 7:21 ` Archit Taneja 2014-04-04 11:54 ` Rob Clark
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.