On Wed, 2025-11-12 at 15:12 +0100, Boris Brezillon wrote: > On Wed, 12 Nov 2025 14:48:51 +0100 > Philipp Stanner <[email protected]> wrote: > > >
[…] > > > > > > > > > > > You could write a proper drm_sched API function which serves your > > > > usecase. > > > > > > It's not really lack of support for our usecase that drives this > > > change, but more the fact the current helpers are racy for drivers that > > > have a 1:1 entity:sched relationship with queues that can be scheduled > > > out behind drm_gpu_scheduler's back. > > > > And you also can't stop drm_sched to prevent races? > > That's the thing, I don't want to stop the drm_gpu_scheduler attached > to a panthor_queue, I want new jobs to be queued to the ring buffer > until this ring buffer is full (which is controller with the > ::credit_limit property), even if the group this queue belongs to is > not currently active on the FW side. Those jobs will get executed at > some later point when the group gets picked by the panthor scheduler. Ah, OK! Understood. > > > > As you know I only learned a few weeks ago about your group scheduler > > on top of drm_sched. I wish I had heard about it when it was > > implemented; we might have come up with the idea for drm_jobqueue > > sooner. > > Might have simplified things, I guess, but that's life, and I'm happy > to transition to drm_jobqueue when it's deemed ready. JQ is in Rust, potentially one day with a C ABI. So that could only happen if your driver's users are OK with relying on LLVM for building the kernel. BTW would be interesting for me to know to what degree that's a problem for common distributions and users. > > > > > > > > > > […] > > > > > > > > > queue->scheduler.timeout = MAX_SCHEDULE_TIMEOUT; > > > > > > is a leftover from a previous version. We shouldn't have to modify that > > > here because the timeout is initialized to MAX_SCHEDULE_TIMEOUT and > > > never touched again. > > > > So you agree that it can be removed in v8? > > Yep, I think it can go away. I'll make sure it still works without it, > and also get the wq from some driver fields instead of going back to > drm_gpu_scheduler::timeout_wq. > I saw your other reply. I mean, it's all not ideal, but as already stated timeout_wq is intended for sharing and, furthermore, we have so many users of interna by now that it often can't even be determined anymore what's legal and what's not. Let's live with it for now. P.
