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 5FF871D6193 for ; Mon, 9 Feb 2026 23:04: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=1770678296; cv=none; b=XjoWW+DZzSkXozknpW+Tz0KBU9ujaTMVANBKV3i/KgSBs4uArBnBOjUjQS/wW1rx6r4gsPJYiCsP0DfSos0Sjjeb0xZUXJAAxiAWLqKTU0pVhZRsyUqt9VHBpsEvyFV0OXeVXI+Zuw/LyR42u2b/BP+gZdXrBcGGmBHLPInI7x8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770678296; c=relaxed/simple; bh=kCry24Fnz/cObxXjWl/y7fqizGwHXmpxi52mzaXL3wY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=f+Xro/7WAzXlQXw57sYhlP8RKFfBf0ExIp6YyWFpencIPDIXGOR1R6oOfAK5kQLaDfOzQKIzyXFuhPH1dRfZVc/RWOXxFeSxJrJ06gClFJ/R/IDWm1e3eNxW4WQsKo0HixMO6axoRYOY3irV1lB++DMyW3K+3YE2dUcydc7gFPw= 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 (unknown [23.129.64.210]) by mta-06.privateemail.com (Postfix) with ESMTPA id 4f90d107YPz3hhTF; Mon, 9 Feb 2026 18:04:20 -0500 (EST) Date: Mon, 9 Feb 2026 18:04:15 -0500 From: Hamza Mahfooz To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: dri-devel@lists.freedesktop.org, Timur =?iso-8859-1?Q?Krist=F3f?= , Michel =?iso-8859-1?Q?D=E4nzer?= , Xaver Hugl , Harry Wentland , Leo Li , Rodrigo Siqueira , Alex Deucher , David Airlie , Simona Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Ivan Lipski , Kenneth Feng , Alex Hung , Tom Chung , Melissa Wen , Michel =?iso-8859-1?Q?D=E4nzer?= , Fangzhi Zuo , amd-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/2] drm: introduce KMS recovery mechanism Message-ID: References: <20260206235846.1019172-1-someguy@effective-light.com> <2ac2dc2f-552c-4084-872b-179a1e489156@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: <2ac2dc2f-552c-4084-872b-179a1e489156@amd.com> On Mon, Feb 09, 2026 at 10:35:05AM +0100, Christian König wrote: > > + /** > > + * @page_flip_timeout: > > + * > > + * This optional hook is called if &drm_crtc_commit.flip_done times out, > > + * and can be used by drivers to attempt to recover from a page flip > > + * timeout. > > + */ > > + void (*page_flip_timeout)(struct drm_crtc *crtc); > > As far as I can see a callback is clearly not the right approach. > > The drm_atomic_helper_wait_for_flip_done() helper is called by the driver, isn't it? > > So what we need is just to give an error code back to the driver. > I guess we could just have the function return -ETIMEOUT, but then drivers wouldn't know which crtc is timing out and AFAIK drivers aren't supposed to touch `drm_crtc_commit`s so they don't really have a sanctioned means to figure that out on their own.