From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-172.mta1.migadu.com (out-172.mta1.migadu.com [95.215.58.172]) (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 E292D224FA for ; Wed, 18 Mar 2026 01:59:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773799152; cv=none; b=mZEhZkz8Cgr4C+wDOyVQ6muVGTyB8eM3VRDFvEidxo8KHk0CoKYkrdtk5WNk0jFx+v2LctWLFYY2rhcJRXUVydkKQhKWxlshgQLuC51Wx1WIr7R5yVCxTAcqCnssiT1QhkrgUu7CWEeHwUn3N8lFiwW7J5uE6Y9gIu+AdS+5snA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773799152; c=relaxed/simple; bh=JyMLJhd1UGbaqIUpV83QvoOoV3NMwwly5W6iPBOnkCc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=aAjcWUZbNCvGqjaqwZZz1WUpFeg6bUHl69jzpeGz9mTEdJWMCjqrEizxQYLxiqRhyBAUE8SlzoBgNdcSdSGGWQfaKbz+Lrt2NzQfEnK2AMg8j8faBK7OCL4xS4GOl8UBS5D9R2WkQnyU3CSjPoGsR2JXEHLXwX5N7o1frXQ9rYs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=packett.cool; spf=pass smtp.mailfrom=packett.cool; dkim=pass (2048-bit key) header.d=packett.cool header.i=@packett.cool header.b=stt9YDRu; arc=none smtp.client-ip=95.215.58.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=packett.cool Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=packett.cool Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=packett.cool header.i=@packett.cool header.b="stt9YDRu" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packett.cool; s=key1; t=1773799136; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g2SvxubjTMbqqciMbziqIiQ2xfH3+6n9bjV5XXagZwI=; b=stt9YDRu9sZ/tnpYW1DfoMeG0rtqzqyOh7Glq+7bYo7dHcEKNOOfHe2hB+AZ659O9dMIMI GDFRZCZ1eIaMB0bf1yRfJOpkUjRWcWehCwi968j28AfggeIIwwkBaomKvhw73++mHtEatY Xk0/XVSXGGOyE14pLb1e0+tU1fpghmpaV1IhXaN6nrrQ3GbmKH+doWf7desEoBMEw8CD4C RvFzJYeC9Vq/B/5KLPnoDwFwtBo2b7lY73/IjZnkEtKU3nK7uL1YJSgmPu+5OEd9MqSVSC 7zDvJOyUa+89aTg9K9XZs2ze5B9jWUgvWyap4fKAqDtyR8R9r4djPXHLbB+IJw== Date: Tue, 17 Mar 2026 22:58:44 -0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v5 00/10] drm/msm/dp: Drop the HPD state machine To: Dmitry Baryshkov Cc: Rob Clark , Dmitry Baryshkov , Abhinav Kumar , Jessica Zhang , Sean Paul , Marijn Suijten , David Airlie , Simona Vetter , Kuogee Hsieh , Yongxing Mou , linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20260314-hpd-refactor-v5-0-0c8450737d64@oss.qualcomm.com> <9c4dad2c-25bd-47d2-bc40-9b551d023615@packett.cool> <38e87937-194f-43ca-ab27-a3a9cf7267d4@packett.cool> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Val Packett In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 3/17/26 10:03 PM, Dmitry Baryshkov wrote: > On Tue, Mar 17, 2026 at 08:15:54PM -0300, Val Packett wrote: >> On 3/16/26 12:23 AM, Dmitry Baryshkov wrote: >>> On Sat, Mar 14, 2026 at 10:10:26PM -0300, Val Packett wrote: >>>> On 3/14/26 9:51 PM, Val Packett wrote: >>>>> On 3/13/26 10:09 PM, Dmitry Baryshkov wrote: >>>>>> Currently, all HPD interrupt handling must go through the HPD state >>>>>> machine. >>>>>> >>>>>> This has caused many issues where the DRM framework assumes that DP is >>>>>> in one state while the state machine is stuck in another state. >>>>>> >>>>>> As discussed here [1], this series: >>>>>> >>>>>> - Removes the state machine >>>>>> - Moves link training to atomic_enable() >>>>>> - Changes the detect() behavior to return true if a display is >>>>>> physically >>>>>>    plugged in (as opposed to if the DP link is ready). >>>>>> - Remove event queue and move internal HPD handling to hpd_notify() >>>>>> >>>>>> To correctly detect the displays which are plugged on boot on the boards >>>>>> which use dp-connector devices, this series depends on [2]. USB-C and >>>>>> eDP panels are handled natively. >>>>>> >>>>>> [1] https://patchwork.freedesktop.org/patch/656312/?series=142010&rev=2#comment_1201738 >>>>>> [2] https://lore.kernel.org/all/20260314-dp-connector-hpd-v1-0-786044cedc17@oss.qualcomm.com/ >>>>> Unfortunately this currently seems to mostly break link training with >>>>> USB-C, on x1e80100-dell-latitude-7455: >>>>> >>>>> [  102.190083] [drm:msm_dp_ctrl_link_train_1_2 [msm]] *ERROR* link >>>>> training #2 on phy 1 failed. ret=-110 >>>>> [  102.192846] [drm:msm_dp_ctrl_setup_main_link [msm]] *ERROR* link >>>>> training of LTTPR(s) failed. ret=-110 >>>>> [  102.211095] [drm:msm_dp_bridge_atomic_enable [msm]] *ERROR* Failed >>>>> link training (rc=-104) >>>>> [  102.211164] [drm:msm_dp_aux_isr [msm]] *ERROR* Unexpected DP AUX IRQ >>>>> 0x01000000 when not busy >>>>> [  102.247168] [drm:msm_dp_ctrl_link_train_1_2 [msm]] *ERROR* link >>>>> training #2 on phy 1 failed. ret=-110 >>>>> [  102.252859] [drm:msm_dp_ctrl_setup_main_link [msm]] *ERROR* link >>>>> training of LTTPR(s) failed. ret=-110 >>>>> >>>>> [..] >>>> Actually looks like that might've been due to having applied the [2] >>>> dp-connector series from above. >>> Interesting. The series only affects dp-connector. It can't affect >>> pmic-glink usecase. >>> >>>> Removed it and rebooted, now plugging and unplugging multiple times between >>>> the 2 ports works fine. >>>> >>>> Except unplug is still not reliable, the "ghost" monitor often remains after >>>> unplugging. >>> Does the patch at [3] fix the issue? >>> >>> [3] https://lore.kernel.org/linux-arm-msm/177362655076.7429.3868048981197120360.b4-ty@kernel.org/ >> Yes! >> >> Overall works better than ever now, looks like I can unplug the cable with >> the laptop closed and then open it and it's all fine, and even play with >> dual-role / gadget mode USB and plug the alt-mode/dock cable back in and it >> doesn't crash. > Tested-by? Yeah, since I guess the link training is kinda orthogonal to this, sure! Tested-by: Val Packett # x1e80100-dell-latitude-7455 >> Still, rare link training failures can happen, e.g.: > Thanks! > > The link training is one of the items that I want to check next. >