[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