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