From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7FB3DC021B8 for ; Wed, 26 Feb 2025 13:16:54 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 48E2910E911; Wed, 26 Feb 2025 13:16:54 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="YpK+PVum"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) by gabe.freedesktop.org (Postfix) with ESMTPS id BFDE710E911; Wed, 26 Feb 2025 13:16:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1740575812; x=1772111812; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=M0KUb1R9ZAxv/fYnGR+wrbHAKhnjFGMnpOXKwgFRw9k=; b=YpK+PVumjFA61F69xgOxm0h1afj9wyWJGtLiPDqka8Dgk+hGtu8+TGhU 17IVEdCVM7BTADqwu5u88rZHlE/c0+NWaP5ZCpfJYH6iIsPDGBxFTOD0J U1C/N9pktpmCrT5ZHsgBJb+tk3jpbTWICEpbtcQlVP2Eq2lm96GzuJtyz 69WK6c73sjytXWvrQMC4uXTvH1LG0mLCq5/HVW7C/NYObYIn1lv0VprFm iUtemm3eoHDzJGEz2dEZ4rkROxMNtcBl1nLIc7XPHY0aI4HdauwiKdNSb tFpvMrpjUS3Qo0+IYe8zjpf5JwTMVmcOOcOwW+dxTqngh/OUzpMuYoQsA A==; X-CSE-ConnectionGUID: A3Mkixt6TgGsob++T5/FlQ== X-CSE-MsgGUID: 4hmRgq6nQ1ioUzf5Ij3Fkw== X-IronPort-AV: E=McAfee;i="6700,10204,11314"; a="52834494" X-IronPort-AV: E=Sophos;i="6.12,310,1728975600"; d="scan'208";a="52834494" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Feb 2025 05:16:52 -0800 X-CSE-ConnectionGUID: t6PF8+zvT6qRaziAdPrn4w== X-CSE-MsgGUID: Jzsv9cUHT/67Es6jyelu7A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,317,1732608000"; d="scan'208";a="121304614" Received: from ideak-desk.fi.intel.com ([10.237.72.78]) by fmviesa005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Feb 2025 05:16:51 -0800 Date: Wed, 26 Feb 2025 15:17:50 +0200 From: Imre Deak To: Jani Nikula Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org Subject: Re: [PATCH 0/5] drm/dp: Fix link training interrupted by HPD pulse Message-ID: References: <20250224193115.2058512-1-imre.deak@intel.com> <87jz9c50hn.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87jz9c50hn.fsf@intel.com> X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: imre.deak@intel.com Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Wed, Feb 26, 2025 at 02:55:32PM +0200, Jani Nikula wrote: > On Mon, 24 Feb 2025, Imre Deak wrote: > > This patchset fixes a problem during Display Port link training, where > > the link training is interrupted by a short HPD pulse generated by the > > sink. Generally the sink signals a bad link state via such short pulses, > > but the sink should prevent such signaling during link training. > > > > Some sinks do generate a short pulse as above during link training, or a > > pulse generated before the link training started may be handled from a > > scheduled work during link training. Such a handling may interfere with > > the link training (see patch 3 for the reason), so this patchset > > prevents the handling of pulses during link training. > > I'm wondering if this series is made unnecessarily complicated by > blocking the hotplug handling at the hpd pin level, while what is > actually needed is blocking at the encoder level. I believe that would > be simpler too. > > Thoughts? I think handling it at the HPD pin level makes more sense, since handling of the HPD IRQs should still happen after they are unblocked. Also in case of encoders sharing an HPD pin the handling of the IRQs should be blocked for all the encoders using this pin. The same block/unblock functionality is also needed for the CRT encoder, so it makes sense to extend that (intel_hpd_disable/enable) to support digital ports as well. > BR, > Jani. > > > > > Imre Deak (5): > > drm/i915/hpd: Let an HPD pin be in the disabled state when handling > > missed IRQs > > drm/i915/hpd: Add support for suspending the IRQ handling on an HPD > > pin > > drm/i915/dp: Fix link training interrupted by a short HPD pulse > > drm/i915/dp: Queue a link check after link training is complete > > drm/i915/crt: Use intel_hpd_suspend/resume() instead of > > intel_hpd_disable/enable() > > > > drivers/gpu/drm/i915/display/intel_crt.c | 7 +- > > .../gpu/drm/i915/display/intel_display_core.h | 2 + > > .../drm/i915/display/intel_dp_link_training.c | 23 +- > > drivers/gpu/drm/i915/display/intel_hotplug.c | 264 ++++++++++++++---- > > drivers/gpu/drm/i915/display/intel_hotplug.h | 5 +- > > 5 files changed, 237 insertions(+), 64 deletions(-) > > -- > Jani Nikula, Intel