All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yadav, Arvind" <arvyadav@amd.com>
To: "Christian König" <christian.koenig@amd.com>,
	"Arvind Yadav" <Arvind.Yadav@amd.com>,
	andrey.grodzovsky@amd.com, shashank.sharma@amd.com,
	amaranath.somalapuram@amd.com, Arunpravin.PaneerSelvam@amd.com,
	sumit.semwal@linaro.org, gustavo@padovan.org, airlied@linux.ie,
	daniel@ffwll.ch, linux-media@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/4] dma-buf: enable signaling for the stub fence on debug
Date: Fri, 9 Sep 2022 22:02:34 +0530	[thread overview]
Message-ID: <d88185fb-0c8c-f379-a6ea-856c00a4e5c9@amd.com> (raw)
In-Reply-To: <37ec6f1d-a3f4-6fa3-6d5c-fe89bb958d87@amd.com>


On 9/6/2022 12:39 PM, Christian König wrote:
>
>
> Am 05.09.22 um 18:35 schrieb Arvind Yadav:
>> Here's on debug enabling software signaling for the stub fence
>> which is always signaled. This fence should enable software
>> signaling otherwise the AMD GPU scheduler will cause a GPU reset
>> due to a GPU scheduler cleanup activity timeout.
>>
>> Signed-off-by: Arvind Yadav <Arvind.Yadav@amd.com>
>> ---
>>
>> Changes in v1 :
>> 1- Addressing Christian's comment to remove unnecessary callback.
>> 2- Replacing CONFIG_DEBUG_WW_MUTEX_SLOWPATH instead of CONFIG_DEBUG_FS.
>> 3- The version of this patch is also changed and previously
>> it was [PATCH 3/4]
>>
>> ---
>>   drivers/dma-buf/dma-fence.c | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
>> index 066400ed8841..2378b12538c4 100644
>> --- a/drivers/dma-buf/dma-fence.c
>> +++ b/drivers/dma-buf/dma-fence.c
>> @@ -27,6 +27,10 @@ EXPORT_TRACEPOINT_SYMBOL(dma_fence_signaled);
>>   static DEFINE_SPINLOCK(dma_fence_stub_lock);
>>   static struct dma_fence dma_fence_stub;
>>   +#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH
>> +static bool __dma_fence_enable_signaling(struct dma_fence *fence);
>> +#endif
>> +
>
> I would rename the function to something like 
> dma_fence_enable_signaling_locked().
>
> And please don't add any #ifdef if it isn't absolutely necessary. This 
> makes the code pretty fragile.
>
>>   /*
>>    * fence context counter: each execution context should have its own
>>    * fence context, this allows checking if fences belong to the same
>> @@ -136,6 +140,9 @@ struct dma_fence *dma_fence_get_stub(void)
>>                      &dma_fence_stub_ops,
>>                      &dma_fence_stub_lock,
>>                      0, 0);
>> +#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH
>> +        __dma_fence_enable_signaling(&dma_fence_stub);
>> +#endif
>
> Alternatively in this particular case you could just set the bit 
> manually here since this is part of the dma_fence code anyway.
>
> Christian.
>
As per per review comment. I will set the bit manually.

~arvind

>> dma_fence_signal_locked(&dma_fence_stub);
>>       }
>>       spin_unlock(&dma_fence_stub_lock);
>

  reply	other threads:[~2022-09-09 16:32 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-05 16:34 [PATCH v2 0/4] dma-buf: To check enable signaling before signaled Arvind Yadav
2022-09-05 16:34 ` [PATCH v2 1/4] drm/sched: Enable signaling for finished fence Arvind Yadav
2022-09-06  6:34   ` Christian König
2022-09-06 19:55     ` Andrey Grodzovsky
2022-09-07  6:37       ` Christian König
2022-09-07 16:18         ` Andrey Grodzovsky
2022-09-05 16:35 ` [PATCH v2 2/4] dma-buf: enable signaling for the stub fence on debug Arvind Yadav
2022-09-06  7:09   ` Christian König
2022-09-09 16:32     ` Yadav, Arvind [this message]
2022-09-05 16:35 ` [PATCH v2 3/4] dma-buf: enable signaling for selftest " Arvind Yadav
2022-09-06  7:11   ` Christian König
2022-09-05 16:35 ` [PATCH v2 4/4] dma-buf: Check status of enable-signaling bit " Arvind Yadav
2022-09-06  8:39   ` Christian König
2022-09-06 10:20     ` Tvrtko Ursulin
2022-09-06 10:43       ` Christian König
2022-09-06 11:21         ` Tvrtko Ursulin
2022-09-06 11:35           ` Christian König
2022-09-06 11:38           ` Tvrtko Ursulin

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=d88185fb-0c8c-f379-a6ea-856c00a4e5c9@amd.com \
    --to=arvyadav@amd.com \
    --cc=Arunpravin.PaneerSelvam@amd.com \
    --cc=Arvind.Yadav@amd.com \
    --cc=airlied@linux.ie \
    --cc=amaranath.somalapuram@amd.com \
    --cc=andrey.grodzovsky@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo@padovan.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=shashank.sharma@amd.com \
    --cc=sumit.semwal@linaro.org \
    /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.