From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from MTA-06-4.privateemail.com (mta-06-4.privateemail.com [198.54.122.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0ED1D1E1A3D for ; Fri, 23 Jan 2026 14:44:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.54.122.146 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769179497; cv=none; b=Sde1EGY940AkDrjQgqXvoxT3+Co0KoDUJX4XH8OOWCfdoW2UHxZ+FJ9LGAMWqZ9q/BVxVH2g5GspyCBvsw0Qo492BLRLa3/gx2UTZJstXi5/Gm6M7yqPbyLJfENi9WU7u7KNQdDYP/Tk9ha7TmKSzdWVYBuT5r6AegqvJOQq/+I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769179497; c=relaxed/simple; bh=KyeMHyC5KUq46RkzM7iAIr0bq/Tih/+LnuLq9r+wHVE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TDD1X1O8Jy6DjQOoqRANOIGuRzN5bzfxI1CrGhFk2CKo+hu/TMWNRL7nRJPHUu65P9FGCf2x7BwV2e6hmP8gpZP0wGdO794bWr/Fr5WKpc5i6DQ8UL63r43y81yiY35AkNjM7DlgwyKmMrP8hAa1mon0gQ28N/7udQlWf8v6+rM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=effective-light.com; spf=pass smtp.mailfrom=effective-light.com; arc=none smtp.client-ip=198.54.122.146 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=effective-light.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=effective-light.com Received: from hal-station.localdomain (bras-base-toroon4332w-grc-44-142-112-152-160.dsl.bell.ca [142.112.152.160]) by mta-06.privateemail.com (Postfix) with ESMTPA id 4dyLL26hDsz3hhTD; Fri, 23 Jan 2026 09:44:26 -0500 (EST) Date: Fri, 23 Jan 2026 09:44:21 -0500 From: Hamza Mahfooz To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: 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 , Michel =?iso-8859-1?Q?D=E4nzer?= , Fangzhi Zuo , Timur =?iso-8859-1?Q?Krist=F3f?= , amd-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] drm: introduce page_flip_timeout() Message-ID: References: <20260123000537.2450496-1-someguy@effective-light.com> <2de6d428-b997-4ba8-8766-a211e5612e72@amd.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2de6d428-b997-4ba8-8766-a211e5612e72@amd.com> On Fri, Jan 23, 2026 at 02:52:44PM +0100, Christian König wrote: > I can only see two reasons why you could run into a timeout: > > 1. A dma_fence never signals. > How that should be handled is already well documented and doesn't require any of this. > > 2. A coding error in the vblank or page flip handler leading to waiting forever. > In that case calling back into the driver doesn't help either. > > So as far as I can see the whole approach doesn't make any sense at all. It appears that resetting display firmware is able to put at least a subset of these systems back into a consistent (usable) state. Though, I don't have a reliable way to reproduce the issue that I'm seeing so I can't say for sure what it boils down to.