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 >
