From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) (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 5C86923D7DB for ; Wed, 28 Jan 2026 14:09:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769609370; cv=none; b=sclHZfhTN+LtTQLDEIdAhOhqsgT/+9+tOsWbiSpq37dMiBAEoWdg9zpcEIdYRnoL8tc0jwh6HLGHiSvAQstkc4a8jUJKMaU1JbHl9zwqF46fAl3790wyYIC39utDfv8Q3qhK8/mFlvUARxtwLZr7wExogN+H3HD+lDll2axjlYM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769609370; c=relaxed/simple; bh=QuRBJsDCSrwFtqMVKXPOBvEwtKqngmn1pY31nw2tKng=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=PqoKOeEMz2cPRUvDg0ZBhvolJyF9XB47XwSCiNpc4E1UmhKynokLCMB1BHV/xd/LuSqZU7mVeaz5jPp9JWRcOylrQWAj7l/YjKnOsFuFk1+oRZPlSeCQz1lnyt5cFAkZU+82Rj21iWtQJhCLybHl+FPktz6ronA+Jtvj5ud1qT4= 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=K8OLpsy6; arc=none smtp.client-ip=209.85.208.47 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="K8OLpsy6" Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-64b791b5584so10229226a12.0 for ; Wed, 28 Jan 2026 06:09:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769609368; x=1770214168; 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=QuRBJsDCSrwFtqMVKXPOBvEwtKqngmn1pY31nw2tKng=; b=K8OLpsy6jugxvY9fU2NjGyc9KqWGrAw0dOCdsmdusY8o4/yUZFwQZYXVPDBT4R3Q7k hQVOmRI+9T0WErSlHtuWpSO5WrXARhvGnHIJ+PxNE+IvLObuH2tuRNw7VN3u1aOghbTK SQbUFG0cnGCIIuwTY5VHgDGvVd4HDLey7XcE/zX3tU8Vvk9l7b/L/T1BJW1BqIvf6xY4 KNlcJIcSfsH2yw/f+3lbz6xTSpH65BCyC2eFeI8C7gSdSpYjOXOxbeW/gnpTNrlvKWhf 2N3lQGflvui5es3kbTWqibiQFAAVuwR9fptjEjnsw0MMR6Pfei9LBTQX+98jzgrk8/zb oLKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769609368; x=1770214168; 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=QuRBJsDCSrwFtqMVKXPOBvEwtKqngmn1pY31nw2tKng=; b=Zy/XNMtbHhFCn9rMLbMdzIR9/YzQD8YFSw0ocJ3qEG4dmz9UnlN1QLRhl6ha9fd58a Op+oAxNvPJct93vtKSmzF9oFCERhBu3T6YfTmFZ7WF+xNNBFY1vbYBazmOWiCxlPXBMI eWfw3aGdTTbvab7YwmCl9LWAWxZ94UQ6p5H4RsVaJfm6tJT//Kcxn+theugIZKkYO2PY CfI9gcLEfSQnXUJUqB9OQDB81x29VSYut5/00cf5oM4TBk1UmoZBZdAi/0+KUv9IJgYG 854PS7oTrbPtNylMnFsbI6Uk1N+HTHHdFmjyRtr4THF647FXpYExf8Cxb2QUqphu1RXC wPZA== X-Forwarded-Encrypted: i=1; AJvYcCUmN/UGt5PdRIvrpkSF808EurrPJeCu2ixsVC0L4saO1UjPy2OJIgoewq7EPGQzxG6oWDA/h1qK+TeAC+0=@vger.kernel.org X-Gm-Message-State: AOJu0YyQ6RDhz+imk5ZeEUGSKEY4IDxJm2FTlje0KULXcnolON5oinu2 lXPv7RGgHsg7TutE6dTu7Z5lnKVkX6qAN1liSdh5yf+bOU/PaE8FazOI X-Gm-Gg: AZuq6aJz5dfOqY1MR99MGKcVbkOPLP4QvHFk0SLrjSDDNbCULTWzKu8dOyP1Y3ZO4nm iW9khCsY+9MKpBjDElaC/N20eshj1V3k6q6q40ospXqQ8LVzWCEqS+lWoQHfE91iLDYJwm+RPX8 hMTzbPhZaeZD1Q9b+GX2cgha09yGLgvaUWD7B7Ld6HBAbPneQ22hSuo91fEE0PKwySL3JosOYuW 502/5BM8nQe48wYbpnqvcu0xEbPu9CxmzG8tRLw45YxzeEkMxrPWUERB1MuvOUwsOG+MCrxWYxB vRqaoTwDl6TFXGaK5UW3Kckzy1X3GuUPVuRpWirGNpHMDPykZbEeIdZfDVvQBsanRc8100VCOR+ vTY5ImZ9aQtGUQE5n3uMeRDnZ0eBwkW8BRVfAu5UE0bqVGmLedbi5Sz0KGpZadERUpH+OeqIHyl 08dU0vGnaWYg1yezk34H9sVJ6Q8KOj/ZTxH9bxqG0d8PP2S24MquwNg1GVbGo= X-Received: by 2002:a05:600c:1994:b0:46e:1a5e:211 with SMTP id 5b1f17b1804b1-48069c788c5mr66971155e9.21.1769602974756; Wed, 28 Jan 2026 04:22:54 -0800 (PST) Received: from timur-hyperion.localnet (5401DF8B.dsl.pool.telekom.hu. [84.1.223.139]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066bfb59asm119139985e9.7.2026.01.28.04.22.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Jan 2026 04:22:54 -0800 (PST) From: Timur =?UTF-8?B?S3Jpc3TDs2Y=?= To: Michel =?UTF-8?B?RMOkbnplcg==?= , Hamza Mahfooz , dri-devel@lists.freedesktop.org, Christian =?UTF-8?B?S8O2bmln?= Cc: 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 , Michel =?UTF-8?B?RMOkbnplcg==?= , Fangzhi Zuo , amd-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, Mario Limonciello Subject: Re: [PATCH 1/2] drm: introduce page_flip_timeout() Date: Wed, 28 Jan 2026 13:22:53 +0100 Message-ID: <2770547.lGaqSPkdTl@timur-hyperion> In-Reply-To: References: <20260123000537.2450496-1-someguy@effective-light.com> <5173841.OV4Wx5bFTl@timur-max> 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 Wednesday, January 28, 2026 12:25:31=E2=80=AFPM Central European Standar= d Time=20 Christian K=C3=B6nig wrote: > On 1/28/26 10:19, Timur Krist=C3=B3f wrote: > > On 2026. janu=C3=A1r 26., h=C3=A9tf=C5=91 14:00:59 k=C3=B6z=C3=A9p-eur= =C3=B3pai t=C3=A9li id=C5=91 Christian K=C3=B6nig > >=20 > > wrote: > >> On 1/26/26 11:27, Michel D=C3=A4nzer wrote: > >>> On 1/26/26 11:14, Christian K=C3=B6nig wrote: > >>>> On 1/23/26 15:44, Timur Krist=C3=B3f wrote: > >>>>> On Friday, January 23, 2026 2:52:44=E2=80=AFPM Central European Sta= ndard Time > >>>>>=20 > >>>>> Christian K=C3=B6nig wrote: > >>>>>> So as far as I can see the whole approach doesn't make any sense at > >>>>>> all. > >>>>>=20 > >>>>> Actually this approach was proposed as a solution at XDC 2025 in > >>>>> Harry's > >>>>> presentation, "DRM calls driver callback to attempt recovery", see > >>>>> page > >>>>> 9 in this slide deck: > >>>>>=20 > >>>>> https://indico.freedesktop.org/event/10/contributions/431/attachmen= ts/ > >>>>> 267/355/2025%20XDC%20Hackfest%20Update%20v1.2.pdf > >>>>>=20 > >>>>> If you disagree with Harry, please make a counter-proposal. > >>>>=20 > >>>> Well I must have missed that detail otherwise I would have objected. > >>>>=20 > >>>> But looking at the slide Harry actually pointed out what immediately > >>>> came > >>>> to my mind as well, e.g. that the Compositor needs to issue a full > >>>> modeset to re-program the CRTC.> > >>>=20 > >>> In principle, the kernel driver has all the information it needs to > >>> reprogram the HW by itself. Not sure why the compositor would need to= be > >>> actively involved. > >>=20 > >> Well first of all I'm not sure if we can reprogram the HW even if all > >> information are available. > >>=20 > >> Please keep in mind that we are in a dma_fence timeout handler here wi= th > >> the usual rat tail of consequences. So no allocation of memory or taki= ng > >> locks under which memory is allocated or are part of preparing the page > >> flip etc... I'm not so deep in the atomic code, so Alex, Sima and > >> probably you as well can answer that much better than I do, but of hand > >> it sounds questionable. > >>=20 > >> On the other hand we could of course postpone reprogramming the CRTC i= nto > >> an async work item, but that might created more problems then it solve= s. > >>=20 > >> Then second even if the kernel can do it I'm not sure if it should do = it. > >>=20 > >> I mean userspace asked for a quick page flip and not some expensive > >> CRTC/PLL reprogramming. Stuff like that usually takes some time and by > >> then the frame which should be displayed by the page flip might already > >> be stale and it would be better to tell userspace that we couldn't > >> display it on time and wait for a new frame to be generated. > >=20 > > I agree with Michel here. It's a kernel bug, it should be solved by the > > kernel. I don't like the tendency of pushing userspace to handle kernel > > bugs, especially if this is just needed for one vendor's buggy driver. > > (No offence.) > Well I strongly disagree. The kernel is not here to serve userspace, but = to > give userspace access to the HW in a generalized manner. Isn't this why kernel mode setting was invented in favour of the mess that = we=20 used to have in the DDX drivers? > If this is caused by a HW failure then reporting back to userspace is the > most reasonable thing to do. Nothing wrong with reporting the problem back to userspace. But it isn't wo= rth=20 much, because userspace is extremely unlikely to be able to fix it. How wou= ld=20 userspace fix a missed or broken interrupt, a firmware hang, or buggy=20 programming of display engine registers? Also, even if it were possible, expecting userspace to fix it would just pl= ace=20 extra burden on compositor maintainers, which in turn would put us in a=20 similar situation where were with GPU recovery before queue reset was=20 implemented. Only a small handful of compositors can handle it (only one of= =20 the major players and maybe a few smaller ones). That gives all other users= a=20 bad experience by default.