[RFC PATCH 1/4] drm/msm: register a fault handler for display mmu faults
Abhinav Kumar
quic_abhinavk at quicinc.com
Sat Jun 22 01:54:19 UTC 2024
On 5/20/2024 9:12 PM, Stephen Boyd wrote:
> Quoting Abhinav Kumar (2024-05-17 16:37:56)
>> diff --git a/drivers/gpu/drm/msm/msm_kms.c b/drivers/gpu/drm/msm/msm_kms.c
>> index af6a6fcb1173..62c8e6163e81 100644
>> --- a/drivers/gpu/drm/msm/msm_kms.c
>> +++ b/drivers/gpu/drm/msm/msm_kms.c
>> @@ -200,6 +200,28 @@ struct msm_gem_address_space *msm_kms_init_aspace(struct drm_device *dev)
>> return aspace;
>> }
>>
>> +static int msm_kms_fault_handler(void *arg, unsigned long iova, int flags, void *data)
>> +{
>> + struct msm_kms *kms = arg;
>> + struct msm_disp_state *state;
>> + int ret;
>> +
>> + ret = mutex_lock_interruptible(&kms->dump_mutex);
>
> From past experience I've seen the smmu fault handler called in hardirq
> context, so it can't sleep. Is there some way to grab the register
> contents without sleeping? Otherwise this will have to fork off
> somewhere else that can take locks, runtime PM resume, etc.
>
Sorry for the delay in this series.
Yes, this is a valid point.
Let me see move to msm_disp_snapshot_state() as that one will spawn a
kthread then dump the registers.
>> + if (ret)
>> + return ret;
>> +
>> + state = msm_disp_snapshot_state_sync(kms);
>> +
>> + mutex_unlock(&kms->dump_mutex);
>> +
More information about the dri-devel
mailing list