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

[Rob Clark]

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

BR,
-R