Re: [PATCH v6 2/3] drm/tyr: add GPU reset infrastructure

[Daniel Almeida <daniel.almeida@collabora.com>]

> On 21 Aug 2026, at 12:58, Onur Özkan <work@onurozkan.dev> wrote:
> 
> On Fri, 21 Aug 2026 12:31:03 -0300
> Daniel Almeida <daniel.almeida@collabora.com> wrote:
> 
>> Hi Onur,
>> 
>>> On 19 Aug 2026, at 15:45, Onur Özkan <work@onurozkan.dev> wrote:
>>> 
>>> Add support for scheduling GPU resets on a dedicated workqueue. Track
>>> the reset state to avoid queueing another reset while one is already
>>> pending or in progress.
>>> 
>>> Use an SRCU based gate with mutex-protected reader admission to block
>>> hardware accesses while reset work runs and wait for current users
>>> before resetting.
>>> 
>>> Stop new reset requests during teardown and drain any queued or running
>>> reset work before releasing the device resources.
>>> 
>>> This is the initial reset infrastructure only. It is not wired to a reset
>>> source yet as those will follow in separate work.
>>> 
>>> Link: https://gitlab.freedesktop.org/panfrost/linux/-/work_items/28
>>> Signed-off-by: Onur Özkan <work@onurozkan.dev>
>> 
>> I’d use dev_info instead, I don’t think a reset belongs in dev_dbg.
> 
> It was dev_dbg initially, Danillo said otherwise and I changed it. I have no
> strong feeling on both.
> 

You mean it was dev_info initially?

> Does it deserve a new version to switch back into dev_dbg again? I think we can
> easily switch that when pulling this series.

My point is that resetting the GPU should not be a “debug” trace, but rather something
that should hit dmesg unconditionally. Of all things that are printed on a driver, a 
“hey the GPU is being reset because something crashed” is something that should
always show up IMHO.

I don’t think you need to send a new version though, let’s wait for more feedback
as well.


— Daniel