All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: David Airlie <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
	Alex Deucher <alexander.deucher@amd.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2 0/3] drm/amdgpu: Remove in_interrupt() usage.
Date: Thu, 11 Mar 2021 11:42:54 +0100	[thread overview]
Message-ID: <df66a184-fa04-bea0-9ba7-a8a93c43b06a@amd.com> (raw)
In-Reply-To: <20210310174734.hxzmmn5eo5bc5whb@linutronix.de>

Hi Sebastian,

Am 10.03.21 um 18:47 schrieb Sebastian Andrzej Siewior:
> On 2021-02-09 18:43:54 [+0100], Christian König wrote:
>> 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.
> Yeah, that is what I saw and didn't even try.

I also have no idea where to start.

> The possible backtrace (at the bottom of this email) is this a correct
> assumption?

It's one of many, yes. But the real complicated once are in the CS UAPI 
and interrupt handling.

>
> Another quick question: You acked my three-patch series. I don't see it
> in the next tree as of today. Is there anything for me to do?

Alex usually picks them up into amd-staging-drm-next which is then 
merged into drm-next.

Regards,
Christian.

>
>> 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@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
> Sebastian

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: David Airlie <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
	Daniel Vetter <daniel@ffwll.ch>,
	Alex Deucher <alexander.deucher@amd.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2 0/3] drm/amdgpu: Remove in_interrupt() usage.
Date: Thu, 11 Mar 2021 11:42:54 +0100	[thread overview]
Message-ID: <df66a184-fa04-bea0-9ba7-a8a93c43b06a@amd.com> (raw)
In-Reply-To: <20210310174734.hxzmmn5eo5bc5whb@linutronix.de>

Hi Sebastian,

Am 10.03.21 um 18:47 schrieb Sebastian Andrzej Siewior:
> On 2021-02-09 18:43:54 [+0100], Christian König wrote:
>> 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.
> Yeah, that is what I saw and didn't even try.

I also have no idea where to start.

> The possible backtrace (at the bottom of this email) is this a correct
> assumption?

It's one of many, yes. But the real complicated once are in the CS UAPI 
and interrupt handling.

>
> Another quick question: You acked my three-patch series. I don't see it
> in the next tree as of today. Is there anything for me to do?

Alex usually picks them up into amd-staging-drm-next which is then 
merged into drm-next.

Regards,
Christian.

>
>> 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@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
> Sebastian

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  reply	other threads:[~2021-03-11 10:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-09 12:44 [PATCH v2 0/3] drm/amdgpu: Remove in_interrupt() usage Sebastian Andrzej Siewior
2021-02-09 12:44 ` Sebastian Andrzej Siewior
2021-02-09 12:44 ` [PATCH 1/3] drm/amdgpu: Replace in_interrupt() usage in gmc_v*_process_interrupt() Sebastian Andrzej Siewior
2021-02-09 12:44   ` Sebastian Andrzej Siewior
2021-02-09 12:44 ` [PATCH 2/3] drm/amdgpu: Remove in_interrupt() usage in gfx_v9_0_kiq_read_clock() Sebastian Andrzej Siewior
2021-02-09 12:44   ` Sebastian Andrzej Siewior
2021-02-09 12:44 ` [PATCH 3/3] drm/amdgpu: Replace in_task() in gfx_v8_0_parse_sq_irq() Sebastian Andrzej Siewior
2021-02-09 12:44   ` Sebastian Andrzej Siewior
2021-02-09 12:50 ` [PATCH v2 0/3] drm/amdgpu: Remove in_interrupt() usage Christian König
2021-02-09 12:50   ` Christian König
2021-02-09 16:53   ` Sebastian Andrzej Siewior
2021-02-09 16:53     ` Sebastian Andrzej Siewior
2021-02-09 17:43     ` Christian König
2021-02-09 17:43       ` Christian König
2021-03-10 17:47       ` Sebastian Andrzej Siewior
2021-03-10 17:47         ` Sebastian Andrzej Siewior
2021-03-11 10:42         ` Christian König [this message]
2021-03-11 10:42           ` Christian König
2021-03-11 15:45   ` Alex Deucher
2021-03-11 15:45     ` Alex Deucher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=df66a184-fa04-bea0-9ba7-a8a93c43b06a@amd.com \
    --to=christian.koenig@amd.com \
    --cc=airlied@linux.ie \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=bigeasy@linutronix.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.