From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (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 67A262DAFBA for ; Wed, 28 Jan 2026 11:14:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769598854; cv=none; b=CG1qCkM6m/81yqE+JkNx+7bQF00ivJCfm0LJW5fYDNOMKZeyRmmDM6aX39e1vLxPEFPXfrb6M1smIHChVr/RCCbupWafDAp+xekKCAnNf2qFmp3yS9Rk9Nf9lCtczuZFwJ/cAGqBIk/rcnhkeP35HQcB7waYrMh9XyLiNWF1cWw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769598854; c=relaxed/simple; bh=EqxiDDJL8+kOG7viwOsgkBd749Kmuo+B5Ya1pZqhFsU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=XcbdfZRHZHRC8Z6czKBjxxGkjpyl6sCHGeKbVbLUn2sEEvxujdfCePkGrRDBSVOi75xjREdTX2OFnqgq6yvzba2VAWMO2GbDkyI9oH4bqFagOT9ISp7C9cudYFz6EIqYgx9PYDG7i+sR4nkHpjxQNJJ3v6XkLZ8SV7zz7Imorr0= 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=WdBKc1NA; arc=none smtp.client-ip=209.85.128.52 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="WdBKc1NA" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-48069a48629so16849895e9.0 for ; Wed, 28 Jan 2026 03:14:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769598851; x=1770203651; 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=EqxiDDJL8+kOG7viwOsgkBd749Kmuo+B5Ya1pZqhFsU=; b=WdBKc1NATuwYyQhRXCsSotkvF1sr1RuYVcoaxDI2td3OA9WoU5bmpvSC3hA5G0KpIX aZTUFM2Hl6dm1bHGr41kiHYgbd1lKJtxnZUQJXQ+wB0dRc4p2t5LK2ltqm+WLAYy+ccO sGBhproepFp5+dqoVyzqefE+Zn/nSPs+68Mqgy/7/AuPxI5o8AlUPLQjqNBakVDQDK71 k1R/mIEQiTKdc+jCc7rbTRPbBCMkp/o4/+sY/9fpiYr0/wCx8/AaHR940/M9roP9fYkU vWU1XKtbS2QdAtmR3HTtunMwTUITlNC7W4pkpdvGgsIZI0F/71v2w00DQ9i3I09S7Mbl uYBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769598851; x=1770203651; 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=EqxiDDJL8+kOG7viwOsgkBd749Kmuo+B5Ya1pZqhFsU=; b=bsUHA/AJDmcZxAV/vfUNYyRafyyW9nJ9uwHQTU2wPu7X4yew9Tb3hdaaTeoDgHrOG9 H7MSKxNiMviY4YXf9qkWvjF035m5A+pljdfoWmuKPWMOU618+odm2khNeBh3hwzY9sc/ AuhKB7CGeILuk/alBWPlsX5/Irwgw3eOxO0ewQYxcJQbriJObHAeGCP5xBGa1UC4ygef ptWpIXWDYHmjml6HQYw0Tbz5V0tw3wth/ELFkp87SX6gi3A1ZxEjwczMXyUaSFlcQjtg fYubCd7TVmr1/lq9/ACHlEJCI1D0RCPcNvCBkaCj3YnNB5jCAL8PLgVAvODGQ3gi3yro JMhw== X-Forwarded-Encrypted: i=1; AJvYcCXerd7IliIGVOWc1cGOFXUmWzAtQeU2vUBOZxRv+tskpoaytseDyUNL+v5Ej8Z1aAeJBB7s6TNHj33okR4=@vger.kernel.org X-Gm-Message-State: AOJu0YwniJ4D464TQ7UVLz7ykSfUeA/Oo1bTgZ/I5dCBrM1XVYJNiWW1 hgIPAfoGqiWdrSPWc1diMpjV7qM0KZ+GgCxRuXMfRNZ7VOUojiXJnqhc+AxuuQ== X-Gm-Gg: AZuq6aJeoJ7L/NFJDv8sEDQxIjbZiem+drA2HBf5y9uvNFnvpwGv/y6kWpUUFcvhaFl rNUBWcldcTAQ/LdZpySoI/IHBpIQJn29AQztHQ/mbML37pJvQva7uyH6WOL+X8CbHN5/gMvwCzD /kkjW6dh1GGy1/84u+TTcXzcO3s/Cw1wX/3lLwvO3J8e76yuDEsh+2wFQfqD//+hDjuZ/x+UbFl 1KfocuaAxOIHPXvbDeJE4IafY0zQydyRL5+UZs8I+UN3T76y9yJkIIHpGKuPI/gIBMNoZTBiBdo LVglQcY5XHVSKNUIZU/ynqCWLBpTB/hE6/3uQEG3KSIH9ddxcS5xS3RZRsPQSQoeSbNtMpHS8Hr qogzGuIz72Q+BJQxR+NC6N9YhGkB7YkMM31AEKITjjcKn/92cblyqkdp5wehhGtTJFzYoDyZNmO QjSyy3NN34rUWC/YdtbmERRNuZJ0mYU0o3ksYgSrAmpwgN3llz9bCSrqYoqhgrvWbhuQ514zpGh cOfanIcwcMuPCVQkg== X-Received: by 2002:a05:6000:26ce:b0:430:b100:f591 with SMTP id ffacd0b85a97d-435dd0649c9mr6800554f8f.28.1769591974093; Wed, 28 Jan 2026 01:19:34 -0800 (PST) Received: from timur-max.localnet (20014C4E24CAAB0049977272BDA969E7.dsl.pool.telekom.hu. [2001:4c4e:24ca:ab00:4997:7272:bda9:69e7]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e10e490esm5431242f8f.9.2026.01.28.01.19.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Jan 2026 01:19:33 -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 10:19:32 +0100 Message-ID: <5173841.OV4Wx5bFTl@timur-max> In-Reply-To: <601b38b5-1890-48f9-adf9-54fb85650852@amd.com> References: <20260123000537.2450496-1-someguy@effective-light.com> <79ed136a-cedd-4e97-adb8-bc3f4f2b8bb4@mailbox.org> <601b38b5-1890-48f9-adf9-54fb85650852@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 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 Stand= ard 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 Harr= y's > >>> presentation, "DRM calls driver callback to attempt recovery", see pa= ge > >>> 9 in this slide deck: > >>>=20 > >>> https://indico.freedesktop.org/event/10/contributions/431/attachments/ > >>> 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 c= ame > >> 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. > 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 with = the > usual rat tail of consequences. So no allocation of memory or taking 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 into= an > async work item, but that might created more problems then it solves. >=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 a= nd > it would be better to tell userspace that we couldn't display it on time > and wait for a new frame to be generated. I agree with Michel here. It's a kernel bug, it should be solved by the=20 kernel. I don't like the tendency of pushing userspace to handle kernel bug= s,=20 especially if this is just needed for one vendor's buggy driver. (No offenc= e.) >=20 > And third, there must be a root cause of the page flip not completing. >=20 > My educated guess is that we have some atomic property change or even > turning the CRTC off in parallel with the page flip. I mean HW rarely tur= ns > off its reoccurring vblank interrupt on its own. I think a page flip timeout can many root causes, so it's unlikely that a=20 single solution would solve all of it. See: https://gitlab.freedesktop.org/drm/amd/-/issues? label_name[]=3Dpage%20flip%20timeout Best regards, Timur