From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F440372B3C for ; Tue, 3 Feb 2026 21:48:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770155337; cv=none; b=mCRuYV+kKvYrAjq0n1TGuQSZz36JiEpwrhVRRP+dWKDzZksjAnb7dMYC5TY/ASZ/PU2+AkE40+Fh9Q53ygkGT5sqsd0PpaUShoZYaKPFeR4GR42lcvRkRb2h5VgtWBssFJoeppnok2hzmbuPeNwx1tLpEQdtKFwtAph5UnIdoPQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770155337; c=relaxed/simple; bh=EOyw3MaQo4lDd393arkCTn4hcIpFAf6muvV/CwKSO1E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=eqEQvQSrHRD9TlonpIMlre/z0ujhYKaUw2YhGnoosnVKUXLRtd37j6pQdOx9y7ymQRmkSLorSF99BFgtMOIlE4mymf+2wQP0Gd/Q+VocSPAo4Ba5zedfvJI1rZUEp0ZNbuFwkYEs2RCtbOxANBKbLQ2P/UusVh3rL6/jYfk+E40= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=JQvpco7R; arc=none smtp.client-ip=209.85.218.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JQvpco7R" Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-b8e526081ceso40319766b.1 for ; Tue, 03 Feb 2026 13:48:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770155334; x=1770760134; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=EOyw3MaQo4lDd393arkCTn4hcIpFAf6muvV/CwKSO1E=; b=JQvpco7R/iusSJ3Sfr8r4ksg8qlhFdA8WbT04LcFRi/K7/5ehm97SGLhX6nhSqsrEq Z8NeuDQoGwUWIeJ1nJmjLl6HZAZdppWw3IQJ2JC9y3JibXFSY0sBKvKpmFRZ15ElV6Ml HF2KAJJXNUKt5AtHACeTY2wUOsiq78IIG4GagxbIZr3FGm91GBdJRxVPwUoBjUFaZ0IR PqtAmQl2qKcuK9hvcWv/G0tMZgOwQ/0mKmEFN3mF/JcOUmEQXVcXRmEOYl/JyMhgMGW6 PNef8agflvB9iSc9TzQV52TBTgS4SEKjYbuLimGrpH1uVVxnqmeXGYE5stGtafoy+iVK 47Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770155334; x=1770760134; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=EOyw3MaQo4lDd393arkCTn4hcIpFAf6muvV/CwKSO1E=; b=XU+oYihIUh+tlT1w9EsfGymYXpSdh8DqDxDe+eyGQIdoXxnp9l3iP5i7KyExz1DPmf 2U/yBAzvZOshsxfK5+j0gkpe7tRwxyuwOgsUxNpo/3uGZricENr/Wio59hGAWbTge5Y2 6mWgHn8c/THTxSaHf8Vw0G8Uxt6YktDSXRNuD8MJWVOr8VdFyNJmVeliOaueDprWRDst wHaCzPnbjUgwwm/m/wDfadPGhLVQ0GTEzr7Am9fvzgEZLwVgLkP7JkSCjV6sp80/SBEt Ew7q6tX/8M36kJhHGcqtQ44UzTQY7QVL0XOmPr0B1JUpZZg1BB9n8BQKcz6O9nBVKLdK pzCQ== X-Forwarded-Encrypted: i=1; AJvYcCWYRZnTptl2PoaZv4LLxuNGBPRyR3MFbQOgY5DidslBF/g7+lvC6KkdY1/hm1R+3OJNqcw9xWbrmoOtH4k=@vger.kernel.org X-Gm-Message-State: AOJu0YzO9VESFWe1JIpwujoaUnZPL0P9rE9OfNn9CTLuMt7MaUBr0awZ 5im/UilRr1W0h1/ClYmU94X9VJLjkwuQT22iu0TUtlQagV176Z4+oA+O X-Gm-Gg: AZuq6aLNiCYJaKW+wbQxK6Wg2bXLLrt2DD5IwxaiH7JzfPi8S+W7lJuI5sZ/8o1Jo4/ WprUnAn7GOc2idXLT+0jyr4B+KIsKkWW89ovlbMlFcjDV7vZV4AJh4sRE6DT6ePNiQdKvDc5qWr MojIJ1TuEjiIaYuAJI0cZcVZC2eIh0L0Vdh+vgfNRZQ3q+GQGHeT0p4aH1GSkKUrp8OD9NSaLaA eTwoAvLAGWJ24xxMQSTKpqnf664ZnGFmRtTUjyX3e63GiOUbJ3ggra2/EGrjr7yBmuQgNdIrp5k 7jS2mgPpWRXuKCBcbUQm5eXu1qvaqOD0g9WB/NLTbLOpNjKmOMkGi1wOvOEfrFdBE6OcbL8aGxC v42ScYtRCDQWxZuqI7eYZ3qgDHJsN2jozaRf4blQsxC72zXxF5bODcVD65AVpXp+jmKqzOr5xZe Ib1LTQZMz5je/LAbD4mqYMDeVH+zgm9vkXReE1aWDtq4bok3+t9fhZ X-Received: by 2002:a17:907:9449:b0:b88:1e2:ed49 with SMTP id a640c23a62f3a-b8e9f95d967mr62528166b.8.1770155334110; Tue, 03 Feb 2026 13:48:54 -0800 (PST) Received: from timur-max.localnet (185.180.91.41.zt.hu. [185.180.91.41]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8e9feeff5csm32034966b.34.2026.02.03.13.48.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Feb 2026 13:48:53 -0800 (PST) From: Timur =?UTF-8?B?S3Jpc3TDs2Y=?= To: Alex Deucher , Hamza Mahfooz , Michel =?UTF-8?B?RMOkbnplcg==?= , Christian =?UTF-8?B?S8O2bmln?= Cc: Mario Limonciello , dri-devel@lists.freedesktop.org, Alex Deucher , David Airlie , Simona Vetter , Harry Wentland , Leo Li , Rodrigo Siqueira , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Sunil Khatri , Ce Sun , Lijo Lazar , Kenneth Feng , Ivan Lipski , Alex Hung , Tom Chung , Melissa Wen , Fangzhi Zuo , amd-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] drm: introduce page_flip_timeout() Date: Tue, 03 Feb 2026 22:48:52 +0100 Message-ID: <27239220.1r3eYUQgxm@timur-max> In-Reply-To: <2f9bc706-02d6-4dec-a56c-53abc5d43f46@amd.com> References: <20260123000537.2450496-1-someguy@effective-light.com> <2285353.hkbZ0PkbqX@timur-hyperion> <2f9bc706-02d6-4dec-a56c-53abc5d43f46@amd.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On 2026. janu=C3=A1r 29., cs=C3=BCt=C3=B6rt=C3=B6k 13:59:00 k=C3=B6z=C3=A9p= =2Deur=C3=B3pai t=C3=A9li id=C5=91 Christian K=C3=B6nig=20 wrote: > On 1/29/26 13:06, Timur Krist=C3=B3f wrote: > > On Thursday, January 29, 2026 12:38:30=E2=80=AFPM Central European Stan= dard Time > >=20 > > Christian K=C3=B6nig wrote: > >>> However, just like we do with ring timeouts, we also need to be prepa= red > >>> for the situation where a page flip timeout happens and we should try= to > >>> recover from it. And if it isn't recoverable, fall back to GPU reset. > >>=20 > >> No, that is clearly a bad idea. > >=20 > > I don't see why it's "clearly" a bad idea. It's not clear to me at all, > > please clarify it for me. >=20 > The GPU resets are necessary because we allow Turing complete programs to= be > submitted by userspace and that in turn is then messing up the HW state a= nd > we need to reset it to get into a known working state again (e.g. classic > reset signal in electronics). >=20 > But in this case here when you see a frozen picture on the screen then th= at > means the CRTC is still working, e.g. power is there, clocks are running, > hblank, vblank is happening ... this doesn't looks like a HW failure at > all. I don't see why that is an argument against performing a reset. Regardless of whether the display is Turing complete or not, it can freeze = up,=20 and resetting it will allow the system to recover. >=20 > After the input from Michel I'm pretty sure that what we have here is just > messed up SW state, e.g. the DC/DM code has no fallback handling and not > only misses the HW event but also blocks all further page flip requests > from userspace which would resolve the issue. The display HW can hang in other ways, as already explained in this thread.= =20 Also the amdgpu_dm code already acknowledges that the DMU and SMU can hang.= =20 Those would be fixed by a reset. > >> CRTCs are fixed function devices that GPU > >> reset helps here is just pure coincident. > >=20 > > Currently, the driver doesn't handle page flip timeouts at all, which > > means > > that if it happens, there is 0% chance of recovering from it. >=20 > Yeah and I completely agree that this is the absolutely worse thing we can > do. > > If the GPU reset improves that chance to non-zero, it's already an > > improvement, and already more than what AMD did to address this problem > > for > > the past few years. I just find it incredibly disrespectful towards the > > community that AMD proposes a solution that they neglect to implement, > > then > > when somebody from the community steps up to implement it, it's rejecte= d. >=20 > Well, I've heard about this problem just a few days ago. Harry presented the problem and the proposed solution at XDC, and the displ= ay=20 team already merged some patches which are intended to hook up to the GPU=20 recovery, see: dm_helpers_dmu_timeout() dm_helpers_smu_timeout() Do you disagree with how these are handled as well? >=20 > >> What we can certainly do is to improve the error handling, e.g. that t= he > >> system doesn't sit there forever after a page flip timeout. > >=20 > > Sure. > >=20 > >> Let's maybe try a complete different approach. We force a page flip > >> timeout, and see if the system can handle that or not. > >>=20 > >> E.g. every 300 page flip we just fail to signal and see if things still > >> work after the timeout. > >=20 > > How do you propose to do that? >=20 > I need to dig a bit into the DAL/DC code and see how the signaling path > actually goes. >=20 > Going to give that a try tomorrow. >=20 Have you had any luck?