From: "Onur Özkan" <work@onurozkan.dev>
To: Daniel Almeida <daniel.almeida@collabora.com>
Cc: linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
dri-devel@lists.freedesktop.org, dakr@kernel.org,
aliceryhl@google.com, airlied@gmail.com, simona@ffwll.ch,
ojeda@kernel.org, boqun@kernel.org, gary@garyguo.net,
bjorn3_gh@protonmail.com, lossin@kernel.org,
a.hindborg@kernel.org, tmgross@umich.edu
Subject: Re: [PATCH v3 0/3] implement GPU reset API
Date: Mon, 10 Aug 2026 12:25:22 +0300 [thread overview]
Message-ID: <20260810092527.116794-1-work@onurozkan.dev> (raw)
In-Reply-To: <ED267FF1-08A7-4C77-B0ED-F74D250DA93F@collabora.com>
On Wed, 05 Aug 2026 21:06:31 -0300
Daniel Almeida <daniel.almeida@collabora.com> wrote:
> Hi Onur,
>
> I went through this and Sami's downstream implementation as asked. I think we
> can strike a middle ground here, because it looks like the two trees need
> different things at the moment.
>
> Upstream tyr today has no scheduler and no jobs. It seems like everywhere we
> might want to issue resets can get a hold of &Device<Bound>: probe,
> ScopedQueue, IRQ handlers and etc. For this, I think your 'bound design fits,
> and I'd like v4 to keep it.
>
> I think the problem starts when the job queue lands, because now we might find
> ourselves in places that only have access to the DRM device data which has a
> 'static bound and thus a hard requirement on Devres, AFAIU. I think we can keep
> that in tyr-dev for now and land on top of your code later, if we shape a few
> things accordingly. I will leave comments on 3/3.
>
> In any case, there are changes in !74 which I think are improvements regardless
> of the 'bound vs devres question, and I also think v4 should come with a user.
> How about adding the GLB_PING watchdog? It would exercise schedule(), give
> ScopedQueue its first user and lets us test this on the board.
>
> Lastly, can you use b4 to manage the dependencies for this series, if you
> haven't yet? It would make it easier to apply.
>
>
> -- Daniel
>
Hi Daniel,
Sorry for the late response, I forgot to reply. As I mentioned in our previous
call, I have v4 on my TODO list and I will try to address everything there.
For now, I am waiting for Sami's response on GitLab [1].
[1]: https://gitlab.freedesktop.org/panfrost/linux/-/merge_requests/74#note_3607402
Regards,
Onur
prev parent reply other threads:[~2026-08-10 9:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 11:43 [PATCH v3 0/3] implement GPU reset API Onur Özkan
2026-07-08 11:43 ` [PATCH v3 1/3] rust: workqueue: impl Send and Sync for OwnedQueue Onur Özkan
2026-08-10 18:29 ` Daniel Almeida
2026-07-08 11:43 ` [PATCH v3 2/3] drm/tyr: clear stale IRQ state before soft reset Onur Özkan
2026-08-10 18:34 ` Daniel Almeida
2026-07-08 11:43 ` [PATCH v3 3/3] drm/tyr: add GPU reset infrastructure Onur Özkan
2026-08-10 19:44 ` Daniel Almeida
2026-08-10 22:19 ` Danilo Krummrich
2026-07-08 11:47 ` [PATCH v3 0/3] implement GPU reset API Onur Özkan
2026-08-06 0:06 ` Daniel Almeida
2026-08-10 9:25 ` Onur Özkan [this message]
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=20260810092527.116794-1-work@onurozkan.dev \
--to=work@onurozkan.dev \
--cc=a.hindborg@kernel.org \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
/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.