From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Christian_K=F6nig?= Subject: Re: [PATCH 1/3] drm/radeon: move ring locking out of reset path Date: Mon, 02 Jul 2012 17:58:33 +0200 Message-ID: <4FF1C529.3030009@vodafone.de> References: <1340981103-3717-1-git-send-email-deathsimple@vodafone.de> <1340982540.3562.204.camel@thor.local> <4FEDC75C.2020003@vodafone.de> <1340986534.3562.224.camel@thor.local> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from outgoing.email.vodafone.de (outgoing.email.vodafone.de [139.7.28.128]) by gabe.freedesktop.org (Postfix) with ESMTP id 396CF9E9A3 for ; Mon, 2 Jul 2012 08:58:37 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Jerome Glisse Cc: =?ISO-8859-1?Q?Michel_D=E4nzer?= , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On 02.07.2012 17:41, Jerome Glisse wrote: > On Fri, Jun 29, 2012 at 12:15 PM, Michel D=E4nzer wr= ote: >> On Fre, 2012-06-29 at 17:18 +0200, Christian K=F6nig wrote: >>> On 29.06.2012 17:09, Michel D=E4nzer wrote: >>>> On Fre, 2012-06-29 at 16:45 +0200, Christian K=F6nig wrote: >>>>> Hold the ring lock the whole time the reset is in progress, >>>>> otherwise another process can submit new jobs. >>>> Sounds good, but doesn't this create other paths (e.g. initialization, >>>> resume) where the ring is being accessed without holding the lock? Isn= 't >>>> that a problem? >>> Thought about that also. >>> >>> For init I'm pretty sure that no application can submit commands before >>> we are done, otherwise we are doomed anyway. >>> >>> For resume I'm not really sure, but I think that applications are >>> resumed after the hardware driver had a chance of doing so. >> I hope you're right... but if it's not too much trouble, it might be >> better to be safe than sorry and take the lock for those paths as well. >> >> > NAK this is the wrong way to solve the issue, we need a global lock on > all path that can trigger gpu activities. Previously it was the cs > mutex, but i haven't thought about it too much when it got removed. So > to fix the situation i am sending a patch with rw semaphore. So what I'm missing? What else can trigger GPU activity when not the rings? I'm currently working on ring-partial resets and also resets where you = only skip over a single faulty IB instead of flushing the whole ring. = And my current idea for that to work is that we hold the ring lock while = we do suspend, ring_save, asic_reset, resume and ring_restore. Christian. > > Cheers, > Jerome >