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

On Fri, 21 Aug 2026 13:39:45 -0300
Daniel Almeida <[email protected]> wrote:

> 
> 
> > On 21 Aug 2026, at 12:58, Onur Özkan <[email protected]> wrote:
> > 
> > On Fri, 21 Aug 2026 12:31:03 -0300
> > Daniel Almeida <[email protected]> wrote:
> > 
> >> Hi Onur,
> >> 
> >>> On 19 Aug 2026, at 15:45, Onur Özkan <[email protected]> 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 <[email protected]>
> >> 
> >> 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?

Yeah, I wrote it incorrectly.

> 
> > 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.
> 

Okay.

- Onur

> 
> — Daniel
>