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

[Inki Dae]

2012/12/5 Rob Clark <robdclark at gmail.com>

> On Wed, Dec 5, 2012 at 12:55 AM, Inki Dae <inki.dae at samsung.com> wrote:
> > Hi
> >
> > 2012/12/5 Prathyush K <prathyush at chromium.org>
> >>
> >> Hi,
> >>
> >> Please check the reference counts for framebuffers: This is for one
> >> modetest (without flipping)
> >>
> >> Bootup:
> >> [    2.310000] KP: drm_framebuffer_init edb86900                   - fb0
> >> refcount 1
> >> [    2.310000] KP: drm_framebuffer_reference edb86900          - fb0
> >> refcount 2
> >>
> >> Modetest:
> >> [   26.560000] KP: drm_framebuffer_init ed43c900                  - fb1
> >> refcount 1   (done in addFB)
> >> [   26.560000] KP: drm_framebuffer_reference ed43c900         - fb1
> >> refcount 2   (done in setCRTC for new fb)
> >> [   26.570000] KP: drm_framebuffer_unreference edb86900      - fb0
> >> refcount 1   (done in setCRTC for old fb)
> >>
> >> End of modetest and drm release:
> >> [   39.080000] KP: drm_framebuffer_unreference ed43c900      - fb1
> >> refcount 1 (this is done by the unref in drm_framebuffer_remove)
> >> [   39.100000] KP: drm_framebuffer_reference edb86900          - fb0
> >> refcount 2 (this is done when we restore fbdev)
> >>
> >> At the end of modetest, you can see that fb1 refcount is still 1 and the
> >> memory does not get freed.
> >>
> >> You can put a print in the low level buffer allocate and deallocate and
> >> you can see that deallocate does not get called for fb1.
> >>
> >> And also, I see a new dma-address getting created each time - e.g.
> >> 20400000, 20800000, 20C00000.
> >>
> >> Please check modetest without enabling flipping. modetest  -s
> >> 17 at 4:1280x720.
> >
> >
> > We missed the test without vblank. Right tested and confirmed.
> >
>
> just fwiw, I've found debugfs file giving a dump of all the fb's and
> gem objects in omapdrm has been quite useful in testing for and
> debugging memory leaks
>
>
>
Thanks for information. I looked into your driver and it seems useful to
us. Actually we have been using similar way and that includes other memory
relevant things also.

Thanks,
Inki Dae

BR,
> -R
> _______________________________________________
> 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/20121207/53f72da5/attachment.html>