From: Gustavo Padovan <gustavo@padovan.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "Daniel Stone" <daniel@fooishbar.org>,
"Joonyoung Shim" <jy0922.shim@samsung.com>,
linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
"'대인기/Mobile S/W Platform Lab.(통신연)/E3(사원)/삼성전자'"
<inki.dae@samsung.com>
Subject: Re: [PATCH -v2] drm/exynos: track vblank events on a per crtc basis
Date: Fri, 30 Jan 2015 15:17:18 -0200 [thread overview]
Message-ID: <20150130171718.GI30820@joana> (raw)
In-Reply-To: <20150130160806.GB14009@phenom.ffwll.local>
2015-01-30 Daniel Vetter <daniel@ffwll.ch>:
> On Fri, Jan 30, 2015 at 03:57:53PM +0000, Daniel Stone wrote:
> > Hi,
> >
> > On 30 January 2015 at 14:30, Gustavo Padovan <gustavo@padovan.org> wrote:
> > > 2015-01-30 Joonyoung Shim <jy0922.shim@samsung.com>:
> > >> We will lose unfinished prior events by this change. That's why we use
> > >> linked list.
> > >
> > > I think you are right, but I was using exynos_crtc->event to do exactly the
> > > same as exynos_crtc->pending_flip. So we were losing a event in
> > > exynos_drm_crtc_dpms() before too. I change this patch to have a page_flip
> > > list on the crtc.
> >
> > The usual approach in other drivers is to return -EBUSY when there is
> > already an async pageflip pending. This definitely makes sense to me,
> > as I don't see the point of submitting pageflips faster than the
> > hardware can actually render, and pretending to the application that
> > they were actually shown.
>
> Yes, right now drm doesn't really support anything like a pageflip queue.
> Same for atomic really. Even the async pageflip mode works like it, it
> just ends up flipping faster.
>
> Long-term we want a flip queue where subsequent flips can be folded
> together on the next vblank. That makes benchmark-mode games happy,
> without resulting in tearing like async flips and still resulting in the
> lowest possible latency (since the kernel we just commit the flips for
> which all the buffers are ready and not stall).
Yeah, that makes sense. I'll just add a check for -EBUSY and send a v2.
Gustavo
next prev parent reply other threads:[~2015-01-30 17:17 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-23 12:42 [PATCH 1/6] drm/exynos: remove leftover code using event_list Gustavo Padovan
2015-01-23 12:42 ` [PATCH 2/6] drm/exynos: track vblank events on a per crtc basis Gustavo Padovan
2015-01-27 12:59 ` Daniel Stone
2015-01-27 13:02 ` Daniel Vetter
2015-01-29 17:10 ` [PATCH -v2] " Gustavo Padovan
2015-01-30 2:44 ` Joonyoung Shim
2015-01-30 14:30 ` Gustavo Padovan
2015-01-30 15:57 ` Daniel Stone
2015-01-30 16:08 ` Daniel Vetter
2015-01-30 17:17 ` Gustavo Padovan [this message]
2015-02-02 5:38 ` Joonyoung Shim
2015-01-23 12:42 ` [PATCH 3/6] drm/exynos: Remove exynos_plane_dpms() call with no effect Gustavo Padovan
2015-01-30 2:12 ` Joonyoung Shim
2015-01-30 14:36 ` Gustavo Padovan
2015-02-02 4:32 ` Joonyoung Shim
2015-01-23 12:42 ` [PATCH 4/6] drm/exynos: remove leftover functions declarations Gustavo Padovan
2015-01-30 2:48 ` Joonyoung Shim
2015-01-23 12:42 ` [PATCH 5/6] drm/exynos: remove struct *_win_data abstraction on planes Gustavo Padovan
2015-01-30 4:32 ` Joonyoung Shim
2015-01-30 14:42 ` Gustavo Padovan
2015-02-02 4:53 ` Joonyoung Shim
2015-01-23 12:43 ` [PATCH 6/6] drm/exynos: do not copy adjusted mode into mode during crtc mode_set Gustavo Padovan
2015-01-30 4:53 ` Joonyoung Shim
2015-01-30 14:44 ` Gustavo Padovan
2015-02-02 4:55 ` Joonyoung Shim
2015-02-03 14:16 ` Gustavo Padovan
2015-02-04 2:10 ` Joonyoung Shim
2015-01-30 2:21 ` [PATCH 1/6] drm/exynos: remove leftover code using event_list Joonyoung Shim
2015-01-30 13:37 ` Gustavo Padovan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150130171718.GI30820@joana \
--to=gustavo@padovan.org \
--cc=daniel@ffwll.ch \
--cc=daniel@fooishbar.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=inki.dae@samsung.com \
--cc=jy0922.shim@samsung.com \
--cc=linux-samsung-soc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox