[PATCH v2] drm/exynos: release fb pended by page flip

[Inki Dae]

2012/12/5 Daniel Vetter <daniel at ffwll.ch>

> On Tue, Dec 4, 2012 at 1:14 PM, Inki Dae <inki.dae at samsung.com> wrote:
> > Changelog v2:
> > fix page fault issue.
> > - defer to unreference old fb to avoid page fault issue.
> > So with this fixup, new fb would be updated to hardware
> > prior to old fb unreferencing. And it removes unnecessary
> > patch, "drm/exynos: Unreference fb in exynos_disable_plane()"
> >
> > Changelog v1:
> > This patch releases the fb pended by page flip after fbdev is
> > restored propely. And fixes invalid memory access when drm is
> > released while doing pageflip.
> >
> > This patch makes fb's refcount to be increased when setcrtc and
> > pageflip are requested. In other words, it increases fb's refcount
> > only if dma is going to access memory region to fb and decreases
> > old fb's because the old fb isn't accessed by dma anymore.
> >
> > This could guarantee releasing gem buffer to the fb after dma
> > access to the gem buffer has been completed.
> >
> > Signed-off-by: Inki Dae <inki.dae at samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
>
> Just an fyi, I'm looking into revamping the locking/refcounting in
> this area in the drm core right now. No patches yet for public
> consumption, but I hope that I can send out and rfc at the end of this
> week. Might fix your problem, too, and certainly addresses the issue
> Prathyush noticed, since the refcounting is done in the drm core and
> should be able to catch all the cases where we need to
> reference/unreference an fb.
>

Right, referencing/unreferencing an fb should be done in drm core and I
think this is generic way.

Thanks for your effort,
Inki Dae


> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121205/46f9f9bc/attachment-0001.html>