From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from h6.fbrelay.privateemail.com (h6.fbrelay.privateemail.com [162.0.218.229]) (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 B2CBF478873 for ; Fri, 27 Feb 2026 20:59:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=162.0.218.229 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772225974; cv=none; b=C+nlnH1ntzocj22BDVW7f+aeDrH2/L56yO5S9PhgtwQCWy9iyj2EeqsFQZ7iU52Ki6HRkdmCsWXeP7GDmCwPb6lifqcMvMZSJnICLdB+q6LsD8623JeK0O0n5TKt36YB6LD2DWsiS1OoOWyi9lEsPCdoz4sZ6tMOgDGo9GEQl60= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772225974; c=relaxed/simple; bh=G2alOf6JX2Pm9YNm3tBcWAo/SDWtqSpbZGtheFVyYzg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GTd1cwY2KtfOzTLyvvy71QkYw9UvYO1WeowxLZDtQABg92y7Lf8CkWFf0Qc9dVtssQLEYvaUzfY1aVCELwZTElT1ploJhxbyb0MeqIQaB8HhuIfmaPU1l1mqfBPIVgRNe8Zd9YRScQaXmZA+ZTVK4w57hd3QWKkkO7IUzRozKIA= 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=162.0.218.229 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 MTA-12-4.privateemail.com (mta-12-1.privateemail.com [198.54.122.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by h5.fbrelay.privateemail.com (Postfix) with ESMTPSA id 4fN10W75Jmz2x9F for ; Fri, 27 Feb 2026 20:59:23 +0000 (UTC) Received: from mta-12.privateemail.com (localhost [127.0.0.1]) by mta-12.privateemail.com (Postfix) with ESMTP id 4fN10M50PHz3hhTn; Fri, 27 Feb 2026 15:59:15 -0500 (EST) Received: from hal-station (ip74-208-79-7.pbiaas.com [74.208.79.7]) by mta-12.privateemail.com (Postfix) with ESMTPA; Fri, 27 Feb 2026 15:58:47 -0500 (EST) Date: Fri, 27 Feb 2026 15:58:43 -0500 From: Hamza Mahfooz To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: dri-devel@lists.freedesktop.org, Michel =?iso-8859-1?Q?D=E4nzer?= , Mario Limonciello , Harry Wentland , Leo Li , Rodrigo Siqueira , Alex Deucher , David Airlie , Simona Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Alex Hung , Aurabindo Pillai , Wayne Lin , Timur =?iso-8859-1?Q?Krist=F3f?= , Ivan Lipski , Dominik Kaszewski , amd-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 2/2] drm/amd/display: add vendor specific reset Message-ID: References: <20260220171518.711594-1-someguy@effective-light.com> <20260220171518.711594-2-someguy@effective-light.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: X-Virus-Scanned: ClamAV using ClamSMTP X-Rspamd-Queue-Id: 4fN10W75Jmz2x9F On Mon, Feb 23, 2026 at 10:34:17AM +0100, Christian König wrote: > > @@ -11085,8 +11087,26 @@ static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state) > > /* Signal HW programming completion */ > > drm_atomic_helper_commit_hw_done(state); > > > > - if (wait_for_vblank) > > - drm_atomic_helper_wait_for_flip_done(dev, state); > > + if (wait_for_vblank && > > + drm_atomic_helper_wait_for_flip_done(dev, state)) { > > + mutex_lock(&dm->dc_lock); > > + if (dm_dmub_hw_init(adev)) > > From Michel's explanation that is pretty much a no-go because it potentially causes other atomic commits to react in unforeseen ways. > This code would only run if the forced modeset fails, which is to say we are already in a hung state, so I don't expect any other atomic commits to be firing off. Also, evidently the timeout isn't a one off, so it's almost certainly caused by hung firmware and not by a bug in the driver's vblanking code. > > + drm_dev_wedged_event(dev, DRM_WEDGE_RECOVERY_REBIND | > > + DRM_WEDGE_RECOVERY_BUS_RESET, > > + NULL); > > Please completely drop that. This here is a sledge hammer and not going to fly anywhere. > I don't feel too strongly about it, though isn't the point to inform userspace that we were unable to recover? AFAIK the prescribed methods are mere suggestions and users can choose to ignore them if they feel that they are too hard hitting. > > + mutex_unlock(&dm->dc_lock); > > + > > + spin_lock_irqsave(&dev->event_lock, flags); > > + drm_for_each_crtc(crtc, dev) { > > This should go over only the CRTCs in the atomic commit currently handled. > > Have you tried sending a hotplug event for the connectors in question as Michel suggested? > Sure, I can look into that. However, we would still need the firmware reload. Otherwise, we would just be forcing a modeset twice in succession.