[PATCH v2] drm/msm: Be more robust when HFI response times out

Konrad Dybcio konrad.dybcio at oss.qualcomm.com
Thu Apr 24 23:18:00 UTC 2025


On 4/24/25 3:30 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>
> ---
> Changes in v2:
> - Add back error print about the queue being empty if we timeout while
>   waiting for a message when the queue is empty.
> - Link to v1: https://lore.kernel.org/r/20250422-msm-hfi-resp-fix-v1-1-b0ba02b93b91@gmail.com
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio at oss.qualcomm.com>

Konrad


More information about the Freedreno mailing list