Re: [PATCH] drm: Don't grab an fb reference for the idr

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Aug 8, 2014 at 12:35 PM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote:
> Ewww, this is ugly. You now make the unregistration dynamic and it's
> no longer under driver control. The typical device-control flow
> assumes there's an authority that controls at which point objects are
> registered and unregistered. You now bind it to ref-counts. To be
> fair, I think lastclose is equally hackish (and doesn't really work
> like you argued already).

Nope, it don't bind the unregister to the refcount, I only make the
registerstration weak so that you can do such games. For all the
normal framebuffers and anything controlled by drivers we can still
unregister at any point before the final unref.

> I think the real problem is that you want two ref-counts: One
> ref-count controls the object availability, the other ref-count
> controls the visibility to user-space. This is also what gem does: you
> have a kernel-internal ref-count for each gem-object, but you also
> have user-space handles. A handle implies a kernel-internal ref-count
> but not vice versa. And the object is only accessible from user-space,
> as long as you own a handle. I think we want something similar for
> FBs. This way you could unregister the bios-FB once no handle exists
> (assuming a CRTC owns a handle as long as the FB is used as scan-out).
>
> But I guess no-one wants to implement this, so I still think this
> patch is the nicest way to make it work. So I'm fine with it.

This doesn't actually solve anything here - the problem is exactly
that this fb just exists, with no one having an access handle (beyond
the internal usage refcount) on it. Not the fbdev emulation, not
anything from userspace. But we want userspace to get at it with a
gettfb call for smooth transitions, so simply not registering it also
won't work.

The thing just hangs of a few crtcs and should survive as long as
that's the case, but as soon as it's no longer used it should get
reaped. So the right place to hook the unregistration into is really
when the last refcount goes away.
-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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux