From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (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 76359423A78 for ; Tue, 16 Jun 2026 09:51:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781603517; cv=none; b=fz/BshIkhJpbGPsISll5a9xAjQ/v6UxNKPpoQ6aa/UuLxEdqbJhLtD/7apL6jgKgLu9sfaxZnMAaB3V4c/f7JEf6fMV9SFmgvayiaXBS2yutTx6itxTK/ft9sN3TCsbP3/yFkRxOs08518Mv5/Qbc1tB72NIxohatZ6ck6VS9xY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781603517; c=relaxed/simple; bh=IWAW/fQBEPZiTaCdacTP7PqDqStxP/BFTF0KywhLwSo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=OnUy078yyZ+Be7Z8B6OwyB4gqNMUMWyTTziX0sqlF4LOBVsP0SjWsMfJZL3yagwTXBa+02lnGLwvgT4wv5+1x74OJAJfKvl8yNMALU4y5va49fcEjaY+QRUjBKWeSkJXGoysGAALOJn8mBvcdnTiPpSbp0Lsd7fv+BOAWNldXf0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=JLASb6/a; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=XYZN6noH; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="JLASb6/a"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="XYZN6noH" Received: from pps.filterd (m0279864.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 65G64J7o2289473 for ; Tue, 16 Jun 2026 09:51:56 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= sMOZTRu51g9pUPpWMnqPhEB0vPr07XkL6hULH16byek=; b=JLASb6/aL0EfAJIf BZD20bmA4208cHOjVVvPbO52FaL07bm2ihQ1TxZ/7kzzEYJMkBupZbIcrIb6WA2g QZzlbulVUOJOSVN3/LNkQ3YNzRtGX+s5V07pcX6h1QbQmUPewa/nTReetOqOYmQE b4FkcNv958bboc1V/EPIBnqNXSc9r6KQnn4R4/v+4F/D8SmhqCMFDTzRuIeWhDS6 ruHpyPiQbhM3jce/Jus+H22ywzdpp+JbbL07F+G+88j/GkEOXo7CoCIwOeOGIfZS s7Et4KMid+YHNHrGxZnkqRJLeAAVBqjzw3WcN3Z84A9qlaeSae+vv6W6FWvXAQDA Rwg6nA== Received: from mail-pj1-f69.google.com (mail-pj1-f69.google.com [209.85.216.69]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4etx8k9nsh-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 16 Jun 2026 09:51:55 +0000 (GMT) Received: by mail-pj1-f69.google.com with SMTP id 98e67ed59e1d1-3772b6b31b4so3244625a91.3 for ; Tue, 16 Jun 2026 02:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1781603515; x=1782208315; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=sMOZTRu51g9pUPpWMnqPhEB0vPr07XkL6hULH16byek=; b=XYZN6noHulCYpa6tmQ/9udq2/CD891cNbLeGf1rOZCnqqP7f+I337tFGjO6v72Y8NL +7NNXxtqHa4hS8W529LviuaoHe1vQKxuzRpCasAr8KvLMYGcXDpuXWyPwAE3axOcYmQv Whd44wIKc4hP03YqWUGEg5e87jQOhyQGwcsPiEouWfle6beA4z1P05T1mYy6QcOiPmWV hJszScDRIoCfSbayMbPzcNXN8GKhh3Q51xdLOg8r1G/7cTKj+zfTPVDgmcWa06j2DfH2 YM1GaRmOyk0fq6svByy/9kDh8cgi5m2ySrUp4OqY/OgI39W6g3SDYN5ooHhWCdfiGzPO slEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781603515; x=1782208315; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sMOZTRu51g9pUPpWMnqPhEB0vPr07XkL6hULH16byek=; b=eBeKEz0Z56SCR64a9/8lMWspiHGnnhB1x7JftND6F7lQAxtz/h46ypX1F7hrCW+V91 AelGm7fay1HGYUt87R4sq4HqpUecvqKkZAZBeu57EYuEhLj8g8kOo3qu95dZRR/5TkSp g7DQ43qNNgwHQEzDJ/I4lyhn0DfMvdaXvUkm45dRw1D/BuZqNOtB4jpzd7ivucYXyzFj TbvFNm5A4qMnAJXRbMWhbUTF+Zm+Y2pZcj7pL4gwosLbIEVxoXNT3/V8wQUoU3mUlPDO SebAelH4O1R4CIW8W+v9sMzTMjLp/bLAOHwZrN6tjaS5weOTIpu+QkH0mjpWTNAdefyn YbyA== X-Forwarded-Encrypted: i=1; AFNElJ89Xr4BNYGvZfUTXmCbQrrUY3H5GZVC28II1+BnDKlglNrN6PJ9STDQ53TcUJlOQzmxAmicjtnioAsQXvc=@vger.kernel.org X-Gm-Message-State: AOJu0YxVZKArEOSKcZDv5oDpcCMVKA6JN1m9eeAsZ+ylBTERqBa3n3a0 laLrVBdPEp32iSME3jpOVie/tqGaXUI/vL5nqabj/+csT207pfrnQ4oPDoRiSdMgTpe1HcD8YNO cH5yuyd15SQXRlyGnbPbpLqrQ7wBmPIr2dDyf20/mQzo/U4cisQvTKrlTfnZokuFAXWg= X-Gm-Gg: Acq92OFxjg8VK3MNg9ezYR9yCovIAgVBcJERdmwyguA9p/Ct0cpnMyTBioiqCEWyTcZ mtZetvBR3dHanMOa9XF0GMS3XYQsfQHgQOAO2UlcZwXWBnwNh0l5sNMy/DvZ7ZCfvqBuVZclV6e Zoq1H3bYG/XsmcPIC8bA+netnlF7yNW13/bnvU8w0g3YkFjqrc10gBKlnXQ5g16kv9STmj8LMV7 tXzKwkYKBTEIwUYihvMzeMxpgxoR+fzQmqSRlP43BZ5yKiJZTgXNKR5uDXRCKHE+xqyYD0wUVgc lFaKYvRtTbx/SlJ4q5TTocWNW5KvXVufszgLhVBEgkTAkb8gCeUUt5SQElX/Bcjjuss7vd7mr8Q G/E5K4aSt47vU4l7PN4J09UFKlGW2nVC5rPeWbu41zegJxFq7/fi8cHOq7q0QpjZOGx+7DcPL6u 5ONCj8iVKp17WT2iZP X-Received: by 2002:a17:90b:55c7:b0:35e:d015:d675 with SMTP id 98e67ed59e1d1-37c5231731amr3218113a91.7.1781603515040; Tue, 16 Jun 2026 02:51:55 -0700 (PDT) X-Received: by 2002:a17:90b:55c7:b0:35e:d015:d675 with SMTP id 98e67ed59e1d1-37c5231731amr3218075a91.7.1781603514551; Tue, 16 Jun 2026 02:51:54 -0700 (PDT) Received: from [10.133.33.98] (tpe-colo-wan-fw-bordernet.qualcomm.com. [103.229.16.4]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-37c5208fd0fsm2258085a91.0.2026.06.16.02.51.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Jun 2026 02:51:54 -0700 (PDT) Message-ID: Date: Tue, 16 Jun 2026 17:51:47 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 37/39] drm/msm/dp: add HPD callback for dp MST To: Dmitry Baryshkov Cc: Rob Clark , Dmitry Baryshkov , Abhinav Kumar , Sean Paul , Marijn Suijten , David Airlie , Simona Vetter , Jessica Zhang , linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org, Abhinav Kumar References: <20260410-msm-dp-mst-v4-0-b20518dea8de@oss.qualcomm.com> <20260410-msm-dp-mst-v4-37-b20518dea8de@oss.qualcomm.com> <42c2bbab-dd86-4ba8-94f6-a6f377425be9@oss.qualcomm.com> Content-Language: en-US From: Yongxing Mou In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNjE2MDA5OSBTYWx0ZWRfXypSYKB3sfCLz oYDL3j/ec8c7GJGgTQVP0IWBpdpUkzqqlKeC1dikuk8Ng4L79D6yKmsQl/H+Zoa4pvo/FJYD5W1 wl7Iv5ZNBB73KR0EvC380bFN30Gl5GZFSNvVAlGE2fOFzn19wStELB2yYtlyK5zycsvVEIaQRhx pmOYQ9uJB9m9P7TgDD+sGAnVE7tk54Zah9ZeaHleNDdQL/lz9xeK4ZMwLOaFYBsJcCaMWf5NT76 r8usuKRfx4PAaABlaLn5ZJvmkuBdsVYL4aF7Lkq1ztEpLXCIFiWdMXT3/eGgVVfhGDvXLlJJo7Q +/pY3nLOwo+e9i/oRVArPmBscNpNG2OlWXdocZrrqv3PD3VLl45UrkUHn/79Jy71s5kWLKNaNR9 m5t2cjJPQd74uxyxATjmZFjvj/TzfucvAyi7O40J1favYrVzIOYsCGuYcVOaezMHFdC/sJl5oCz jt6jW46glY+63cq3nnA== X-Proofpoint-Spam-Info: AW1haW4tMjYwNjE2MDA5OSBTYWx0ZWRfXzOWwdieOKBfK QK39ysppI+1aPMwOIyLiCu34BQ3ZlJhBEOmiXNTbDZbDKZ36moyMqz6yGLkwdTDAfYfN+HtcGJE cmaTohg+ZbaD5Y1oQQoUpH+l0/M2+LU= X-Proofpoint-ORIG-GUID: tvC_RitQ3C8MIJCcYD1uYdhV7r-3vIIT X-Authority-Analysis: v=2.4 cv=dZawG3Xe c=1 sm=1 tr=0 ts=6a311cbb cx=c_pps a=vVfyC5vLCtgYJKYeQD43oA==:117 a=nuhDOHQX5FNHPW3J6Bj6AA==:17 a=IkcTkHD0fZMA:10 a=FelO9ux0wxsA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=DJpcGTmdVt4CTyJn9g5Z:22 a=e5mUnYsNAAAA:8 a=COk6AnOGAAAA:8 a=EUspDBNiAAAA:8 a=btda8m9z8dVjgjKQGyEA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=rl5im9kqc5Lf4LNbBjHf:22 a=Vxmtnl_E_bksehYqCbjh:22 a=TjNXssC_j7lpFel5tvFf:22 X-Proofpoint-GUID: tvC_RitQ3C8MIJCcYD1uYdhV7r-3vIIT X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.125,FMLib:17.12.100.49 definitions=2026-06-16_02,2026-06-15_04,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 lowpriorityscore=0 clxscore=1015 impostorscore=0 suspectscore=0 phishscore=0 priorityscore=1501 malwarescore=0 bulkscore=0 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606040000 definitions=main-2606160099 On 6/16/2026 8:50 AM, Dmitry Baryshkov wrote: > On Mon, Jun 15, 2026 at 06:05:07PM +0800, Yongxing Mou wrote: >> >> >> On 4/12/2026 6:00 AM, Dmitry Baryshkov wrote: >>> On Fri, Apr 10, 2026 at 05:34:12PM +0800, Yongxing Mou wrote: >>>> From: Abhinav Kumar >>>> >>>> Add HPD callback for the MST module which shall be invoked from the >>>> dp_display's HPD handler to perform MST specific operations in case >>>> of HPD. In MST case, route the HPD messages to MST module. >>>> >>>> Signed-off-by: Abhinav Kumar >>>> Signed-off-by: Yongxing Mou >>>> --- >>>> drivers/gpu/drm/msm/dp/dp_display.c | 23 +++++++++++++++++++---- >>>> drivers/gpu/drm/msm/dp/dp_mst_drm.c | 34 ++++++++++++++++++++++++++++++++++ >>>> drivers/gpu/drm/msm/dp/dp_mst_drm.h | 1 + >>>> 3 files changed, 54 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c >>>> index 919767945ba5..ca89e20b7563 100644 >>>> --- a/drivers/gpu/drm/msm/dp/dp_display.c >>>> +++ b/drivers/gpu/drm/msm/dp/dp_display.c >>>> @@ -454,6 +454,9 @@ static int msm_dp_hpd_plug_handle(struct msm_dp_display_private *dp) >>>> dp->msm_dp_display.connector_type, >>>> dp->link->sink_count); >>>> + if (dp->plugged) >>>> + return 0; >>>> + >>>> mutex_lock(&dp->plugged_lock); >>>> ret = pm_runtime_resume_and_get(&pdev->dev); >>>> @@ -556,12 +559,19 @@ static int msm_dp_irq_hpd_handle(struct msm_dp_display_private *dp) >>>> { >>>> u32 sink_request; >>>> int rc = 0; >>>> + struct msm_dp *msm_dp_display = &dp->msm_dp_display; >>>> /* irq_hpd can happen at either connected or disconnected state */ >>>> drm_dbg_dp(dp->drm_dev, "Before, type=%d, sink_count=%d\n", >>>> dp->msm_dp_display.connector_type, >>>> dp->link->sink_count); >>>> + if (msm_dp_display->mst_active) { >>>> + if (msm_dp_aux_is_link_connected(dp->aux) != ISR_DISCONNECTED) >>> >>> Will this work for USB-C? >>> >> Hmm not work for USB-C. We can remove this check here, as the IRQ thread can >> handle the disconnect case itself. > > Please. Start testing with USB-C too. > Yeah. will test USB-C also. Could you rebase this series on top of the HPD refactor series? Thanks. >>>> + msm_dp_mst_display_hpd_irq(&dp->msm_dp_display); >>>> + return 0; >>>> + } >>>> + >>>> /* check for any test request issued by sink */ >>>> rc = msm_dp_link_process_request(dp->link); >>>> if (!rc) { >>>> @@ -1125,9 +1135,13 @@ static irqreturn_t msm_dp_display_irq_thread(int irq, void *dev_id) >>>> connector_status_connected); >>>> /* Send HPD as connected and distinguish it in the notifier */ >>>> - if (hpd_isr_status & DP_DP_IRQ_HPD_INT_MASK) >>>> - drm_bridge_hpd_notify(dp->msm_dp_display.bridge, >>>> - connector_status_connected); >>>> + if (hpd_isr_status & DP_DP_IRQ_HPD_INT_MASK) { >>>> + if (dp->msm_dp_display.mst_active) >>>> + msm_dp_irq_hpd_handle(dp); >>> >>> No, don't touch this code. HPD notifications might be coming from the >>> other entities. This IRQ thread can only send the HPD notification. >>> There rest should be handled in the notifier. >>> >> Ok. From my understanding, after this series >> (https://patchwork.freedesktop.org/series/164954/#rev5) is rebased, we >> should use drm_aux_hpd_bridge_notify_extra() here to notify the IRQ? > > No. There is no aux bridge here. But yes, I'd need to call a different > function in that series. > There is one concern here: if we use drm_aux_hpd_bridge_notify_*() to notify IRQ events, does that mean every IRQ notification would also trigger a hotplug event? If so, this may not be necessary, since the MST core framework already notifies userspace/client on its own. Additional hotplug events could cause userspace to query connector status again, which in turn might trigger the bridge notification repeatedly. Please correct me if my understanding is wrong. >>>> + else >>>> + drm_bridge_hpd_notify(dp->msm_dp_display.bridge, >>>> + connector_status_connected); >>>> + } >>>> ret = IRQ_HANDLED; >>>> @@ -1793,7 +1807,8 @@ void msm_dp_bridge_hpd_notify(struct drm_bridge *bridge, >>>> msm_dp_hpd_plug_handle(dp); >>>> } >>>> } else { >>>> - msm_dp_hpd_unplug_handle(dp); >>>> + if (hpd_link_status == ISR_DISCONNECTED) >>> >>> Why? >>> >> Let me explain this in more detail here. >> Currently, MST hotplug and IRQ events are handled through the SST bridge. >> This guards against spurious unplug handling caused by >> msm_dp_bridge_hpd_notify() being invoked from non-HPD contexts where status >> == connector_status_disconnected does not actually mean the cable is gone. >> >> In addition to the real HPD IRQ path, drm_bridge_connector_detect() also >> calls drm_bridge_connector_hpd_notify() to broadcast the detect result to >> all bridges in the chain. So a single physical plug-in produces multiple >> msm_dp_bridge_hpd_notify() calls — one from the real IRQ, then several more >> from various probe/poll paths. Stack traces from a single insertion on >> QCS8300: >> >> 1. msm_dp_display_irq_thread → real HPD plug, status=connected >> 2. fbdev probe triggered by (1) → drm_bridge_connector_detect → >> status=disconnected (link not ready yet) > > This should not be happening. We don't use link status anymore to return > connected status. > Let me double-check this. >> 3. output_poll_execute worker → same path → status=disconnected >> 4. drm_dp_mst_link_probe_work → same path → status=disconnected >> 5. output_poll_execute again → status=disconnected >> >> Here not work for USB-C case yet, I’d like to switch to using >> drm_dp_read_sink_count to detect whether the sink is actually disconnected >> or no sink devices. > > drm_dp_read_sink_count() isn't enough here. See the plugged flag. Maybe > we need more flags here. > Got it. Let me see if there’s a better way to handle this. >> >>>> + msm_dp_hpd_unplug_handle(dp); >>>> } >>>> pm_runtime_put_sync(&msm_dp_display->pdev->dev); >