On Tue, Dec 17, 2013 at 10:04 PM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: >> > Hm yeah the ownership is less clear in the CONFIG_FB=n case. I think >> > the driver will own the buffer, and it'll get dropped on the first mode >> > set with a new buffer. But even then there will be no process to deref >> > the object finally, so it'll stick around. Hm... maybe just disable it >> > if CONFIG_FB=n is the right answer for now. >> >> If you switch the fbdev code to look at crtc->fb instead of >> crtc->plane_config.fb and just drop the plane_config.fb pointer (and it's >> reference) it should pan out. Then the only reference+pointers we have are >> the ones in crtc->fb, and the drm core will take care of those. > > How can I switch to looking at crtc->fb? Or do you mean > get_plane_config should stuff a full fb into crtc->fb instead of the > plane_config struct? Yeah, that would be my idea. Since crtc->fb is managed by the drm core we could also enable the recovery for CONFIG_FB=n and so enable smooth transitions without fbdev being present. Well, super-smooth only with fastboot ofc ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
