From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 7F656385EE1 for ; Thu, 29 Jan 2026 12:06:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769688396; cv=none; b=hEBCUENfS+RWDkG2Rvh3mnuReQoa+QWCM8uWfzqVDiiKFnKvkOdhLXERoxNqzLIwXxP8/zAmMC9xt7tlJLd7lIXvCzF2w0aFnneVjE44qtGlmTTZ7eiEcNsOD7e5STU9f3/zZP2GAqRp6X/AYi94bcklZOKEeF9n/psfsSFtr/s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769688396; c=relaxed/simple; bh=6QTOQktx+T8aTDWlJDPhGlWk3qvhIQsNrxNsbMFHUik=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=IiEMxl8/3lET3FZjR3uIFli9zQ+Sbl2GjLND+l3r1QRl3ku9//TkOUcgOFrjPb462zLZPJfsBwolli6hi73iA/h+O0+YqV8O9QA2tSmXrOMpWdSSq60aIqOm44GDLiGIIDmGe+QVZnlhOfryHLjsB22FE6BQMLgAkkJkq/ylRlE= 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=UX8WqNNn; arc=none smtp.client-ip=209.85.221.44 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="UX8WqNNn" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-42fb4eeb482so686755f8f.0 for ; Thu, 29 Jan 2026 04:06:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769688393; x=1770293193; 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=6QTOQktx+T8aTDWlJDPhGlWk3qvhIQsNrxNsbMFHUik=; b=UX8WqNNnusKInUJ3dBYr/6XZ2O/nPrMkQ4yTuVdH4pe6vD0eB6Zrvc7NQRK2RMRUnx r0FFVl/LZ8H11cgqndIGRQ97FYKwACyKkZ/R+g3xQUSKqIiCAQOFM/VpFfszeb66kMST Z1ODPHf8EAOWSGUlljl9FP7xntGhaBGjz+fvFlLkwM0U70mIRdm3xn8l5fD40vXWMXP4 4QCxDq4vaA/bgme93o7qB8iqiJkBZhnXYHfBm2mh+HsV95OBkAGiKIEQLrp6B1kf4MYo Drh2vv2WzOokn/zeP3zQHL5EK6b+ax6c99lKy0ELEDLEwKE1DFUVKF3A6qWevmlWZphs ANEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769688393; x=1770293193; 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=6QTOQktx+T8aTDWlJDPhGlWk3qvhIQsNrxNsbMFHUik=; b=OG/SDOn8KcpQ4fR+XGhirGRyWgftyusVCJ41+HtO8fiMPRh4u16Z3K++aCn+GP98eJ Lgw9HsrJHUqMtMLUCo+DZfnYzGBkP10cLJVoYbFWFvwce+0URdLvgtpeBBWZ/d9CGqtw NyP09VLcez2tET9+XGQ17y76k87o2PDM/sqkNfeT4Sq441LU3d9mhYpaIIPiEozE/MQs 2WVGMEsexdfGcy1Jxc9byz9cx0WXBf5JgAtnQmSuRBFKm6rXhQBxak9UZQrImPB6MefD WrDR0Qq2EBgUZ93ixm8i09/Kli2z5AC39/Zr1u/YqA8FA69gwuj6djazuxYuxPJr0gqq 86jQ== X-Forwarded-Encrypted: i=1; AJvYcCU6f/pllbNCriI2vr4646/9lHdqmeMYp81JxXblc9+QSgUKLuNasisS17G4iXIUaKTU2w7U0P4VNGjG374=@vger.kernel.org X-Gm-Message-State: AOJu0YyBl+0EfF1hO5nGWsLBHWx1mK3+mUNZVtCq2ia7f+fbLMzQ35/k I530RPQJl3XPGjMjuq7P/GZz7cS+lPMs1MnTyp2aaMHKajLsgHblAqpU X-Gm-Gg: AZuq6aKWrsMsqhyxS5cVsTLiE93fvr4mNFH7pv0o+cAv50CGoz1Gyo1uKkHXmvsTgYk 3HzzVIHGoyRwHB3lRskDn4AnmGF/3gBKfoETNQ8pq5wyQrdgMpQ3kOuJ3CSHCtjO6pENcpJoomN LM74liYy7GNisZ6XtEqyKeht8a2AlK4NhRAFvicoQLsrzIo/PlKU9wu5uDMtDXTzn6ZX44mCRyb GX6wzQZo3bSt1af2LsZS6TPTIZpt2MT8Cchl6dIYA126rYIiP8Ma2tcfeksqXQRVCvMW6K5sO9L wD61GRG3LIdcmbBGyDGXjRxayJ8NXwUvF/yP3Qpg2ipOpwxBj45Xiur4GVVTRYSC8wcsO6JvMmJ Y4bZ+aLakFgCvEvNLJGLXaW3/9tNyYiAfh0ydT6kzMNDkrQEn8lV+djCSgb4/Xw/ZqAQA3uXBS+ hDN+mIHohQF0nOIPYbN7FSVCy+alUwW9tS8MMteH96z/d7L1baTUt/lU9FrXw= X-Received: by 2002:a05:6000:258a:b0:430:fdc8:8bbd with SMTP id ffacd0b85a97d-435dd0b3702mr13425165f8f.41.1769688392626; Thu, 29 Jan 2026 04:06:32 -0800 (PST) Received: from timur-hyperion.localnet (5401DF8B.dsl.pool.telekom.hu. [84.1.223.139]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e131ce93sm13719217f8f.24.2026.01.29.04.06.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Jan 2026 04:06:31 -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: Thu, 29 Jan 2026 13:06:30 +0100 Message-ID: <2285353.hkbZ0PkbqX@timur-hyperion> In-Reply-To: <30f2480d-016f-417e-9ddf-7805e4943e7b@amd.com> References: <20260123000537.2450496-1-someguy@effective-light.com> <2719069.vYhyI6sBWr@timur-hyperion> <30f2480d-016f-417e-9ddf-7805e4943e7b@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 Thursday, January 29, 2026 12:38:30=E2=80=AFPM Central European Standard= Time=20 Christian K=C3=B6nig wrote: > >=20 > > However, just like we do with ring timeouts, we also need to be prepared > > 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. I don't see why it's "clearly" a bad idea. It's not clear to me at all, ple= ase=20 clarify it for me. > CRTCs are fixed function devices that GPU > reset helps here is just pure coincident. Currently, the driver doesn't handle page flip timeouts at all, which means= =20 that if it happens, there is 0% chance of recovering from it. If the GPU reset improves that chance to non-zero, it's already an=20 improvement, and already more than what AMD did to address this problem for= =20 the past few years. I just find it incredibly disrespectful towards the=20 community that AMD proposes a solution that they neglect to implement, then= =20 when somebody from the community steps up to implement it, it's rejected. > What we can certainly do is to improve the error handling, e.g. that the > system doesn't sit there forever after a page flip timeout. Sure. >=20 > Let's maybe try a complete different approach. We force a page flip timeo= ut, > 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 w= ork > after the timeout. How do you propose to do that?