From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/imagination: Count paired job fence as dependency in prepare_job() Date: Tue, 31 Mar 2026 17:33:24 +1000 Message-ID: In-Reply-To: <20260330-job-submission-fixes-cleanup-v1-1-7de8c09cef8c@imgtec.com> References: <20260330-job-submission-fixes-cleanup-v1-0-7de8c09cef8c@imgtec.com> <20260330-job-submission-fixes-cleanup-v1-1-7de8c09cef8c@imgtec.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review **Status**: Correct fix, Cc: stable appropriate. This fixes the case where `job_count_remaining_native_deps()` failed to count the paired job fence as a native dependency because `to_pvr_queue_job_fence()` can't resolve it (the parent fence isn't assigned until submission). The fix manually counts it. The `is_paired_job_fence()` helper is well-factored and immediately reused in the existing `pvr_queue_submit_job_to_cccb()` check: ```c +static bool +is_paired_job_fence(struct dma_fence *fence, struct pvr_job *job) +{ + /* This assumes "fence" is one of "job"'s drm_sched_job::dependencies */ + return job->type == DRM_PVR_JOB_TYPE_FRAGMENT && + job->paired_job && + &job->paired_job->base.s_fence->scheduled == fence; +} ``` The `WARN_ON(dma_fence_is_signaled(fence))` in the counting code is a reasonable sanity check - the paired job's scheduled fence shouldn't be signaled before submission. One minor observation: the comment update `"backed by a UFO"` -> `"already backed by a UFO"` on `to_pvr_queue_job_fence()` is a good clarification to include here since it directly relates to understanding why the paired fence can't be resolved. **No issues.** --- Generated by Claude Code Patch Reviewer