[Intel-gfx] [PATCH 2/4] drm/i915: Move GEM BO inside drm_framebuffer

Daniel Stone daniel at fooishbar.org
Fri Mar 23 14:49:33 UTC 2018

Hi Ville,

On 23 March 2018 at 14:42, Ville Syrjälä <ville.syrjala at 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.


More information about the Intel-gfx mailing list