Re: [PATCH 4/4] HID: picolcd: implement refcounting of framebuffer

["Bruno Prémont" <bonbons@linux-vserver.org>]

On Mon, 28 June 2010 Bernie Thompson <bernie@plugable.com> wrote:
> On Mon, Jun 28, 2010 at 1:33 PM, Bruno Prémont
> <bonbons@linux-vserver.org> wrote:
> > As our device may be hot-unplugged and framebuffer cannot handle
> > this case by itself we need to keep track of usage count so as
> > to release fb_info and framebuffer memory only after the last user
> > has closed framebuffer.
> >
> > We need to do the freeing in a scheduled work as fb_release()
> > is called with fb_info lock held.
> 
> The udlfb (DisplayLink) framebuffer driver just got a similar fix in
> the last few days:
> http://git.plugable.com/gitphp/index.php?p=udlfb&a=commit&h®0502457e54904b1a9e0d67db6719182824da7c
> 
> The need to schedule work in fb_release() because fbmem.c touches it
> after release is especially unfortunate (we had to do the same).
> 
> Anyone have existing thoughts about fixing the release path more centrally?

The best option IMHO would be that framebuffer_release() would free up
memory when framebuffer is not in use anymore (or last close if FB was
in use when framebuffer_release() was called).

Something like
  framebuffer_alloc()              <-- set refcount to 1
  ...
  register_framebuffer()           <-- inc refcount
  ...
  and open() of fb device would inc refcount
  and close() would decrement it

  unregister_framebuffer()         <-- dec refcount
  framebuffer_release()            <-- dec refcount

When after decrementing refcount, refcount reaches zero
close() or framebuffer_release() would free the framebuffer, calling
fbops fb_release() callback so owner can do cleanup if it has something
to do.

That way it would be easiest for drivers of removable framebuffers,
possibly also useful for kms adding/removing framebuffers for extra
monitors.

Thanks,
Bruno