On Mon, 2026-10-26 at 14:25 +0100, David Rosca wrote:
>
> On 10/26/26 14:00, Timur Kristóf wrote:
> > On Sunday, October 25, 2026 7:22:04 PM Central European Standard
> > Time David
> > Rosca wrote:
> > > On 10/6/26 19:03, Timur Kristóf wrote:
> > > > It turns out that the VCE_STATUS register bits that we
> > > > used to check whether VCE1 is idle are actually not useful:
> > > > VCE_STATUS.JOB_BUSY doesn't exist until VCE3
> > > > VCE_STATUS.UENC_BUSY seems to be stuck high on Cape Verde
> > > >
> > > > Instead, do the following:
> > > > Check that the read and write pointer matches for each ring.
> > > > Check VCE_STATUS.VCPU_REPORT bits to check busy status.
> > > > Finally, also check SRBM_STATUS2.VCE_BUSY just in case,
> > > > although this one seems bogus on VCE1.
> > > >
> > > > Fixes: d4a640d4b9f3 ("drm/amdgpu/vce1: Implement VCE1 IP block
> > > > (v2)")
> > > > Signed-off-by: Timur Kristóf <[email protected]>
> > > There's still occasional warning that VCE is not idle on my cape
> > > verde,
> > > but it's much better than the current state where it prints it
> > > every time.
> > >
> > Hi David,
> >
> > Can you say what the remaining warning says?
> > Do you think we could fix the remaining warning by removing the
> > check for the
> > SRBM_STATUS bit entirely?
> VCE busy: VCE_STATUS=0x142, SRBM_STATUS2=0x80
> VCE busy: VCE_STATUS=0x152, SRBM_STATUS2=0x80
>
> which does look like VCE is indeed busy.
>
> David
It looks like 0x152 has the RB0_BUSY bit set, but 0x142 seems like it
doesn't have any of the busy bits set and only the SRBM thinks that the
VCE is busy but it may not be actually busy. It's hard to judge without
more information.
When do you see the warning? Does it happen after an encoding job or
after suspend/resume? Or...?
Thanks,
Timur
