Hi Ville, On 23 March 2018 at 14:42, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote: > On Fri, Mar 23, 2018 at 01:45:50PM +0000, Daniel Stone wrote: >> --- a/drivers/gpu/drm/i915/intel_display.c >> +++ b/drivers/gpu/drm/i915/intel_display.c >> @@ -13916,7 +13916,8 @@ static void intel_user_framebuffer_destroy(struct >> drm_framebuffer *fb) >> drm_framebuffer_cleanup(fb); >> >> i915_gem_object_lock(obj); >> - WARN_ON(!obj->framebuffer_references--); >> + WARN_ON(obj->framebuffer_references < fb->format->num_planes); >> + obj->framebuffer_references -= fb->format->num_planes; > > Hmm. I'm thinking we can stick to the single reference per fb. > IIRC this counter is there just to prevent changes of the obj > tiling mode as long as any fb exists that uses the object. So > doesn't actually matter how many planes the fb has. > > Naturally the story would be slightly difference if we supported > fbs using multiple different BOs, as each BO would need to get its > framebuffer_references adjusted.
Yeah, fair enough. It looks a little bit weird (perhaps deserving of a comment) there. The reason to do that was just the general principle of having one reference per object pointer, especially when other drivers (ones which can have separate BOs in a single logical image) will and do refcount them separately. Having different refcounting semantics in shared structures depending on which driver is in use makes me itchy. Cheers, Daniel _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
