Re: [PATCH v8 03/12] accel/rocket: factor the completion tail out of the IRQ handler
Igor Paunovic <[email protected]>
| Newsgroups | dev.linux.lists.iommu,org.freedesktop.lists.dri-devel,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-rockchip,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pm |
|---|---|
| Message-ID | <CAEWPSH4VAR5VTJUW4PdJczrtueQzPzzo6og8PzWaupwd-t=BFQ@mail.gmail.com> |
Hi Jiaxing, You asked for a look at this one, so I checked it as a no functional change refactor rather than only reading it. It holds. I reconstructed the three source states from the posted diffs and built the before and after with the driver's own kernel flags for arm64. rocket_job_handle_irq() is static and inlines into rocket_job_irq_handler_thread(); at -O2 both states emit the same calls and the same stack frame, and differ only in which side of the branch the rocket_job_hw_submit() call is laid out on. The load bearing sentence in your message is the early return, and that checks out too. At -O1 the pre-3/12 code emits mutex_unlock twice, once on the path straight after rocket_job_hw_submit() and once at the guard exit. That is the scoped_guard cleanup firing on the early return. After 3/12 there is one, because the return leaves the helper and all three paths converge on the guard exit. Both versions unlock exactly once on every path. "Nothing follows it" also holds through the rest of the series, not only here. 10/12 is the only later patch that touches rocket_job.c, and its two hunks are the defines at the top and the PC_TASK_CON write inside rocket_job_hw_submit(). Nothing is added after the scoped_guard in the handler anywhere in v8. While reconstructing the base I checked where the series sits. drivers/accel/rocket/rocket_job.c in next-20260814 hashes to 3141f210f, which is exactly 1/12's pre-image, and applying 1, 2 and 3 in order reproduces 5f0f9682e, d484a3a6f and 0bb11c718 byte for byte. So these three apply to an unmodified linux-next rocket_job.c and need neither the RK3576 patches nor my clocks-by-name patch. Tomeu, that is meant as information in case you want to pick them up independently, not as a request for a re-cut. Reviewed-by: Igor Paunovic <[email protected]> Regards, Igor On Mon, Aug 17, 2026 at 1:36 PM Jiaxing Hu <[email protected]> wrote: > > rocket_job_handle_irq() stops the block and then either starts the job's > next task or retires the job. The second half is a step of its own and > reads better with a name, now that taking the register writes under > job_lock has moved it a level deeper inside the scoped guard. > > Move it to rocket_job_next_locked(). The early return that used to leave > the handler now leaves the helper, which is the same thing here: the > scoped guard drops job_lock either way and nothing follows it. > > Doing it as its own patch keeps the locking fix at the head of the > series minimal, so a bisect that stops before this one gets that fix and > nothing else. There is one caller, and no functional change. > > Signed-off-by: Jiaxing Hu <[email protected]> > --- > drivers/accel/rocket/rocket_job.c | 31 ++++++++++++++++++++----------- > 1 file changed, 20 insertions(+), 11 deletions(-) > > diff --git a/drivers/accel/rocket/rocket_job.c b/drivers/accel/rocket/rocket_job.c > index d484a3a6f..0bb11c718 100644 > --- a/drivers/accel/rocket/rocket_job.c > +++ b/drivers/accel/rocket/rocket_job.c > @@ -341,6 +341,25 @@ static struct dma_fence *rocket_job_run(struct drm_sched_job *sched_job) > return ERR_PTR(ret); > } > > +/* Start the job's next task, or retire it. Caller holds job_lock. */ > +static void rocket_job_next_locked(struct rocket_core *core) > +{ > + lockdep_assert_held(&core->job_lock); > + > + if (!core->in_flight_job) > + return; > + > + if (core->in_flight_job->next_task_idx < core->in_flight_job->task_count) { > + rocket_job_hw_submit(core, core->in_flight_job); > + return; > + } > + > + iommu_detach_group(NULL, iommu_group_get(core->dev)); > + dma_fence_signal(core->in_flight_job->done_fence); > + pm_runtime_put_autosuspend(core->dev); > + core->in_flight_job = NULL; > +} > + > static void rocket_job_handle_irq(struct rocket_core *core) > { > pm_runtime_mark_last_busy(core->dev); > @@ -354,17 +373,7 @@ static void rocket_job_handle_irq(struct rocket_core *core) > rocket_pc_writel(core, OPERATION_ENABLE, 0x0); > rocket_pc_writel(core, INTERRUPT_CLEAR, 0x1ffff); > > - if (core->in_flight_job) { > - if (core->in_flight_job->next_task_idx < core->in_flight_job->task_count) { > - rocket_job_hw_submit(core, core->in_flight_job); > - return; > - } > - > - iommu_detach_group(NULL, iommu_group_get(core->dev)); > - dma_fence_signal(core->in_flight_job->done_fence); > - pm_runtime_put_autosuspend(core->dev); > - core->in_flight_job = NULL; > - } > + rocket_job_next_locked(core); > } > } > > -- > 2.43.0 >