[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