From: Stephen Rothwell <sfr@canb•auug.org.au>
To: Dave Airlie <airlied@redhat•com>,
Alex Deucher <alexander.deucher@amd•com>
Cc: "Simona Vetter" <simona.vetter@ffwll•ch>,
"Intel Graphics" <intel-gfx@lists•freedesktop.org>,
DRI <dri-devel@lists•freedesktop.org>,
"André Almeida" <andrealmeid@igalia•com>,
"Christian König" <christian.koenig@amd•com>,
"Christian König" <ckoenig.leichtzumerken@gmail•com>,
"Linux Kernel Mailing List" <linux-kernel@vger•kernel.org>,
"Linux Next Mailing List" <linux-next@vger•kernel.org>
Subject: Re: linux-next: manual merge of the drm-misc tree with the drm tree
Date: Tue, 1 Jul 2025 13:21:59 +1000 [thread overview]
Message-ID: <20250701132159.01cce959@canb.auug.org.au> (raw)
In-Reply-To: <20250701130702.416ba635@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 4241 bytes --]
Hi all,
Sorry, this was actually a conflict between the amdgpu tree and the drm
tree.
On Tue, 1 Jul 2025 13:07:02 +1000 Stephen Rothwell <sfr@canb•auug.org.au> wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>
> between commits:
>
> 183bccafa176 ("drm: Create a task info option for wedge events")
> a72002cb181f ("drm/amdgpu: Make use of drm_wedge_task_info")
>
> from the drm tree and commits:
>
> 821aacb2dcf0 ("drm/amdgpu: rework queue reset scheduler interaction")
> 43ca5eb94b38 ("drm/amdgpu: move guilty handling into ring resets")
> 38b20968f3d8 ("drm/amdgpu: move scheduler wqueue handling into callbacks")
>
> from the drm-misc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> index 6b4ffa9ceb7a,f0b7080dccb8..000000000000
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> @@@ -89,11 -89,9 +89,10 @@@ static enum drm_gpu_sched_stat amdgpu_j
> {
> struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
> struct amdgpu_job *job = to_amdgpu_job(s_job);
> + struct drm_wedge_task_info *info = NULL;
> struct amdgpu_task_info *ti;
> struct amdgpu_device *adev = ring->adev;
> - int idx;
> - int r;
> + int idx, r;
>
> if (!drm_dev_enter(adev_to_drm(adev), &idx)) {
> dev_info(adev->dev, "%s - device unplugged skipping recovery on scheduler:%s",
> @@@ -133,47 -133,22 +132,24 @@@
> if (unlikely(adev->debug_disable_gpu_ring_reset)) {
> dev_err(adev->dev, "Ring reset disabled by debug mask\n");
> } else if (amdgpu_gpu_recovery && ring->funcs->reset) {
> - bool is_guilty;
> -
> - dev_err(adev->dev, "Starting %s ring reset\n", s_job->sched->name);
> - /* stop the scheduler, but don't mess with the
> - * bad job yet because if ring reset fails
> - * we'll fall back to full GPU reset.
> - */
> - drm_sched_wqueue_stop(&ring->sched);
> -
> - /* for engine resets, we need to reset the engine,
> - * but individual queues may be unaffected.
> - * check here to make sure the accounting is correct.
> - */
> - if (ring->funcs->is_guilty)
> - is_guilty = ring->funcs->is_guilty(ring);
> - else
> - is_guilty = true;
> -
> - if (is_guilty)
> - dma_fence_set_error(&s_job->s_fence->finished, -ETIME);
> -
> - r = amdgpu_ring_reset(ring, job->vmid);
> + dev_err(adev->dev, "Starting %s ring reset\n",
> + s_job->sched->name);
> + r = amdgpu_ring_reset(ring, job->vmid, NULL);
> if (!r) {
> - if (amdgpu_ring_sched_ready(ring))
> - drm_sched_stop(&ring->sched, s_job);
> - if (is_guilty) {
> - atomic_inc(&ring->adev->gpu_reset_counter);
> - amdgpu_fence_driver_force_completion(ring);
> - }
> - if (amdgpu_ring_sched_ready(ring))
> - drm_sched_start(&ring->sched, 0);
> - dev_err(adev->dev, "Ring %s reset succeeded\n", ring->sched.name);
> - drm_dev_wedged_event(adev_to_drm(adev), DRM_WEDGE_RECOVERY_NONE, info);
> + atomic_inc(&ring->adev->gpu_reset_counter);
> + dev_err(adev->dev, "Ring %s reset succeeded\n",
> + ring->sched.name);
> + drm_dev_wedged_event(adev_to_drm(adev),
> - DRM_WEDGE_RECOVERY_NONE);
> ++ DRM_WEDGE_RECOVERY_NONE, info);
> goto exit;
> }
> - dev_err(adev->dev, "Ring %s reset failure\n", ring->sched.name);
> + dev_err(adev->dev, "Ring %s reset failed\n", ring->sched.name);
> }
> +
> dma_fence_set_error(&s_job->s_fence->finished, -ETIME);
>
> + amdgpu_vm_put_task_info(ti);
> +
> if (amdgpu_device_should_recover_gpu(ring->adev)) {
> struct amdgpu_reset_context reset_context;
> memset(&reset_context, 0, sizeof(reset_context));
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2025-07-01 3:22 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-01 3:07 linux-next: manual merge of the drm-misc tree with the drm tree Stephen Rothwell
2025-07-01 3:21 ` Stephen Rothwell [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-04-03 13:34 Mark Brown
2026-03-30 16:02 Mark Brown
2026-03-30 16:02 Mark Brown
2022-11-09 23:54 Stephen Rothwell
2019-10-09 0:12 Stephen Rothwell
2019-10-09 0:10 Stephen Rothwell
2019-10-08 23:46 Stephen Rothwell
2019-10-08 23:38 Stephen Rothwell
2019-10-08 23:33 Stephen Rothwell
2019-08-19 3:18 Stephen Rothwell
2019-06-11 3:52 Stephen Rothwell
2019-06-11 3:38 Stephen Rothwell
2019-04-09 1:34 Stephen Rothwell
2019-04-09 7:23 ` Gerd Hoffmann
2019-02-08 1:27 Stephen Rothwell
2019-02-08 8:53 ` Daniel Vetter
2019-02-08 9:25 ` Stephen Rothwell
2019-02-08 9:34 ` Daniel Vetter
2018-11-23 0:13 Stephen Rothwell
2018-09-18 1:31 Stephen Rothwell
2018-09-12 0:39 Stephen Rothwell
2018-03-19 1:29 Stephen Rothwell
2018-03-19 14:14 ` Ville Syrjälä
2017-11-01 3:36 Stephen Rothwell
2017-04-03 3:18 Stephen Rothwell
2016-09-28 2:11 Stephen Rothwell
2014-12-10 1:49 Stephen Rothwell
2014-12-03 2:43 Stephen Rothwell
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=20250701132159.01cce959@canb.auug.org.au \
--to=sfr@canb$(echo .)auug.org.au \
--cc=airlied@redhat$(echo .)com \
--cc=alexander.deucher@amd$(echo .)com \
--cc=andrealmeid@igalia$(echo .)com \
--cc=christian.koenig@amd$(echo .)com \
--cc=ckoenig.leichtzumerken@gmail$(echo .)com \
--cc=dri-devel@lists$(echo .)freedesktop.org \
--cc=intel-gfx@lists$(echo .)freedesktop.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=simona.vetter@ffwll$(echo .)ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox