All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Move drm_framebuffer_unreference out of struct_mutex for takeover
Date: Mon, 13 Apr 2015 15:09:19 +0300	[thread overview]
Message-ID: <87r3rop6vk.fsf@intel.com> (raw)
In-Reply-To: <5514123C.4020907@linux.intel.com>

On Thu, 26 Mar 2015, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote:
> On 03/26/2015 01:30 PM, Ville Syrjälä wrote:
>> On Thu, Mar 26, 2015 at 12:39:40PM +0000, Tvrtko Ursulin wrote:
>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>
>>> intel_user_framebuffer_destroy() requires the struct_mutex for its
>>> object bookkeeping, so this means that all calls to
>>> drm_framebuffer_unreference must be held without that lock.
>>>
>>> This is a simplified version of the identically named patch by Chris Wilson.
>>>
>>> References: https://bugs.freedesktop.org/show_bug.cgi?id=89166
>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>> ---
>>>   drivers/gpu/drm/i915/intel_display.c | 10 ++++++++++
>>>   1 file changed, 10 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>>> index cb50854..0788507 100644
>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>> @@ -14020,11 +14020,21 @@ void intel_modeset_gem_init(struct drm_device *dev)
>>>   					       c->primary->fb,
>>>   					       c->primary->state,
>>>   					       NULL)) {
>>> +			/*
>>> +			 * We must drop struct_mutex when calling
>>> +			 * drm_framebuffer_unreference and it is safe to do so
>>> +			 * because it is not needed at this point anyway.
>>> +			 * At this stage the driver is still single-threaded and
>>> +			 * we are taking it only to silence a warning in
>>> +			 * intel_pin_and_fence_fb_obj.
>>> +			 */
>>> +			mutex_unlock(&dev->struct_mutex);
>>>   			DRM_ERROR("failed to pin boot fb on pipe %d\n",
>>>   				  to_intel_crtc(c)->pipe);
>>>   			drm_framebuffer_unreference(c->primary->fb);
>>>   			c->primary->fb = NULL;
>>>   			update_state_fb(c->primary);
>>> +			mutex_lock(&dev->struct_mutex);
>>>   		}
>>>   	}
>>>   	mutex_unlock(&dev->struct_mutex);
>>
>> Just grab the mutex around the pin_and_fence inside the loop. It doesn't
>> protect anything else.
>
> Well the comment says so, but this way it only grabs and releases it 
> once if there are multiple active crtcs and nothing fails. So I was 
> hoping the comment was enough to explain the reality, even though the 
> other option would be more obvious code strictly speaking.

Tvrtko & Ville, can you reach a solution on this one? Or is there a
new patch that I may have missed?

BR,
Jani.


>
> Regards,
>
> Tvrtko
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-04-13 12:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-26 12:39 [PATCH] drm/i915: Move drm_framebuffer_unreference out of struct_mutex for takeover Tvrtko Ursulin
2015-03-26 13:30 ` Ville Syrjälä
2015-03-26 14:05   ` Tvrtko Ursulin
2015-04-13 12:09     ` Jani Nikula [this message]
2015-04-13 13:37       ` Tvrtko Ursulin
2015-04-13 13:52         ` Ville Syrjälä
2015-03-26 20:13 ` shuang.he
2015-04-13 15:03 Tvrtko Ursulin
2015-04-13 18:18 ` shuang.he
2015-04-14  9:00 ` Ville Syrjälä
2015-04-14 13:19   ` Jani Nikula

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r3rop6vk.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=tvrtko.ursulin@linux.intel.com \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.