Hi,
On 12 January 2015 at 21:13, Gustavo Padovan <gustavo@xxxxxxxxxxx> wrote:
2014-12-30 Inki Dae <inki.dae@xxxxxxxxxxx>:> ok to skip finish_pageflip request this time? Shouldn't it ensure to> 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
> 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
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
