[PATCH] drm/msm: Be more robust when HFI response times out
Konrad Dybcio
konrad.dybcio at oss.qualcomm.com
Wed Apr 23 10:12:10 UTC 2025
On 4/22/25 6:00 PM, Connor Abbott wrote:
> If the GMU takes too long to respond to an HFI message, we may return
> early. If the GMU does eventually respond, and then we send a second
> message, we will see the response for the first, throw another error,
> and keep going. But we don't currently wait for the interrupt from the
> GMU again, so if the second response isn't there immediately we may
> prematurely return. This can cause a continuous cycle of missed HFI
> messages, and for reasons I don't quite understand the GMU does not shut
> down properly when this happens.
>
> Fix this by waiting for the GMU interrupt when we see an empty queue. If
> the GMU never responds then the queue really is empty and we quit. We
> can't wait for the interrupt when we see a wrong response seqnum because
> the GMU might have already queued both responses by the time we clear
> the interrupt the first time so we do need to check the queue before
> waiting on the interrupt again.
>
> Signed-off-by: Connor Abbott <cwabbott0 at gmail.com>
> ---
[...]
> - /* If the queue is empty our response never made it */
> + /* If the queue is empty, there may have been previous missed
> + * responses that preceded the response to our packet. Wait
> + * further before we give up.
> + */
> if (!ret) {
> - DRM_DEV_ERROR(gmu->dev,
> - "The HFI response queue is unexpectedly empty\n");
> -
> - return -ENOENT;
> + ret = a6xx_hfi_wait_for_msg_interrupt(gmu, id, seqnum);
> + if (ret)
> + return ret;
I think we should keep the error print in the second-failure case
Konrad
More information about the Freedreno
mailing list