[PATCH 01/29] drm/exynos/fimd: only finish pageflip if START == START_S

[Daniel Stone]

Hi,

On 12 January 2015 at 21:13, Gustavo Padovan <gustavo at padovan.org> wrote:

> 2014-12-30 Inki Dae <inki.dae at samsung.com>:
> > On 2014년 12월 18일 22:58, Gustavo Padovan wrote:
> > > +    * This works around a race between a page_flip request and the
> latency
> > > +    * between vblank interrupt and this irq_handler:
> > > +    *   => FIMD vblank: BUF_START_S[0] := BUF_START[0], and asserts
> irq
> > > +    *   | => fimd_win_commit(0) writes new BUF_START[0]
> > > +    *   |    exynos_drm_crtc_try_do_flip() marks exynos_fb as prepared
> > > +    *   => fimd_irq_handler()
> > > +    *       exynos_drm_crtc_finish_pageflip() sees prepared exynos_fb,
> > > +    *           and unmaps "old" fb
> > > +    *   ==> but, since BUF_START_S[0] still points to that "old" fb...
> > > +    *   ==> FIMD iommu fault
> > > +    */
> > > +   start = readl(ctx->regs + VIDWx_BUF_START(0, 0));
> > > +   start_s = readl(ctx->regs + VIDWx_BUF_START_S(0, 0));
> > > +   if (start == start_s)
> > >             exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
> > And what if 'start_s' has a value different from one of 'start'? Is it
> > ok to skip finish_pageflip request this time? Shouldn't it ensure to
> > wait for that until 'start_s' has a value same as one of 'start'?
>
> I think it is okay to skip finish_pageflip, but we could return directly
> if they are different, so we keep the wait_vsync_queue running until the
> next
> irq happens or it timeouts. How does this look to you?
>

Right, you'd need to keep the vblank IRQ alive until start == start_s.

As an aside, there is currently some refcounting code (e.g. in the DPMS off
and/or framebuffer final-unref paths if I remember correctly) which assumes
that waiting one vblank is enough to be able to unpin resources. Obviously,
as this patch shows, this is not actually true. This patch doesn't make
this any better or worse; just something to bear in mind. (I have WIP code
which fixes this.)

Cheers,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150119/295c8d95/attachment.html>