[PATCH v2 0/3] drm/amdgpu: Remove in_interrupt() usage.

[Christian König]

Hi Sebastian,

to be honest I'm thinking about that for quite some time now and I don't 
think that this is possible without a severe rewrite of the driver.

The problem is simply that we have a lot of functions which deal with 
hardware handling independent of the context. But how registers are 
accessed needs to be different depending if your are in the interrupt 
handler or not.

You would need to push the information if we are coming in from the 
interrupt handler through a > 10 function calls.

I don't think that this is feasible nor good design.

Regards,
Christian.

Am 09.02.21 um 17:53 schrieb Sebastian Andrzej Siewior:
> On 2021-02-09 13:50:31 [+0100], Christian König wrote:
>> Reviewed-by: Christian König <christian.koenig at amd.com> for the series.
> Thank you.
> Any chance you could give me a hand with the remaining three users
> within the amdgpu driver? I don't know if the in_interrupt() check can
> be limited to certain callers.
> What I noticed while tracing v5.10 is this:
>
> |             Xorg-2257    [007] d... 57261.620043: amdgpu_device_wreg: 0x699f, 0x00001bcf, 0x00000100
> |  => trace_event_raw_event_amdgpu_device_wreg
> |  => amdgpu_device_wreg.part.0
> |  => dce110_arm_vert_intr
> |  => dce110_vblank_set
> |  => dm_enable_vblank
> |  => drm_vblank_enable
> |  => drm_vblank_get
> |  => drm_wait_vblank_ioctl
> |  => drm_ioctl_kernel
> |  => drm_ioctl
> |  => amdgpu_drm_ioctl
> |  => __x64_sys_ioctl
> |  => do_syscall_64
> |  => entry_SYSCALL_64_after_hwframe
>
> I think that amdgpu_device_wreg() -> amdgpu_kiq_wreg() could be invoked.
> It doesn't here because amdgpu_sriov_runtime() is false.
> The trace says `d' which means interrupts are disabled but
> in_interrupt() will return false in this case (no IRQ/softirq).
>
> Sebastian