On Tue, Apr 15, 2014 at 12:10 PM, Rob Clark robdclark@gmail.com wrote:
so, what triggers this is that previously drm_framebuffer_remove() did not process private planes. But now the fb shows up attached to a plane as well, the crtc's primary plane.
That shouldn're really matter - if we have the fb assigned as the primary plane then the set_config_internal should clear crtc->primary->fb. Which means in the next loop (where we go over all planes) we won't look at it again. Or at least this is how it should work.
So dropping a ref twice due to that would indeed be a bug, but one in drm_crtc.c. I have to admit that I don't see it really. -Daniel