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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 36F15C433F5 for ; Tue, 2 Nov 2021 22:31:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 101AC61050 for ; Tue, 2 Nov 2021 22:31:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229736AbhKBWe3 (ORCPT ); Tue, 2 Nov 2021 18:34:29 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:36553 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229685AbhKBWe3 (ORCPT ); Tue, 2 Nov 2021 18:34:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1635892313; 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=s7LptIgu+syWserQTVVGwm5xGU03s5Ksw96xU5k2+b0=; b=CsBIGMpp198JmXtnLNTNsG2OnnUizzxONN7lb6UX0/7PEsXArmHvIzShxpsVSAkjkMzFIx Bal422pmoC+Yg8r2+AAFGdXdVOJXI+6KQD5JcczTjy95uNWx23tdTWfO2X+HR3WYa53YpG n3IMwClEYnviXZ9XBBw7ZoYv1SAqCZQ= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-569-otMI0ScHO-2SIb8q10TwDg-1; Tue, 02 Nov 2021 18:31:52 -0400 X-MC-Unique: otMI0ScHO-2SIb8q10TwDg-1 Received: by mail-qv1-f70.google.com with SMTP id hf12-20020a0562140e8c00b00382cdfe644eso426238qvb.23 for ; Tue, 02 Nov 2021 15:31:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:organization:user-agent:mime-version :content-transfer-encoding; bh=s7LptIgu+syWserQTVVGwm5xGU03s5Ksw96xU5k2+b0=; b=1I9Ui/E4CCPzD8R2bvWf9I+qE72dZPU7lb6WEwRsCkTMkTvmA7rvm/FqdRH1q5fxzq vQMz15YADR1s1Tc0xlt7xb1Dw9bC16jWM6lRKvzMWFTL15SgKZ/9Sz+8HecLSaEmbW8I KFJYHedVjCoin7jTGwyLvTz1/4wxsyaFwvCFwCFNqY1Rk/br8B2qWzJw8Lqg6DRwnWBB KcL1eUuT7uQqjmFrwKrciDqpWqfCQAT6zWuzh5dL0ov/mpRmzFySZ6Qa1NG6wxEr13Ba Byn0vRUVJx6sQpSUz/Qwt8hR/otyofO4QAtKeenhW25jZOL/U6bJuMrRGV4N3rszwzDT yNlg== X-Gm-Message-State: AOAM532ptm5slG/pdroqZeoT3LmyjSvt493+/XmpXi3tO1VLgeEMhGls xe9GyBzjC0OJQ58FV0w/QkRafgjVz2Lt1JW92T3Qyr3KOpg6mc8FBTdCtJQX5qquD5wVSos6jC6 AblGu78U4KA4tPP6y X-Received: by 2002:a05:620a:25c8:: with SMTP id y8mr31292608qko.42.1635892311475; Tue, 02 Nov 2021 15:31:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz4Mn2/N4/VkaTugW1IbEV+gcQbmtzqiNbmi541UL6/BSzvvYeXqRyvJXZucZIrbqNTBihSRA== X-Received: by 2002:a05:620a:25c8:: with SMTP id y8mr31292576qko.42.1635892311148; Tue, 02 Nov 2021 15:31:51 -0700 (PDT) Received: from [192.168.8.138] (pool-96-230-249-157.bstnma.fios.verizon.net. [96.230.249.157]) by smtp.gmail.com with ESMTPSA id n18sm244365qtk.91.2021.11.02.15.31.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Nov 2021 15:31:50 -0700 (PDT) Message-ID: <0badd704d7014481cc87a42e58c96a84205f1ca3.camel@redhat.com> Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected end device From: Lyude Paul To: "Lin, Wayne" , "dri-devel@lists.freedesktop.org" Cc: "Kazlauskas, Nicholas" , "Wentland, Harry" , "Zuo, Jerry" , "Wu, Hersen" , Juston Li , Imre Deak , Ville =?ISO-8859-1?Q?Syrj=E4l=E4?= , Daniel Vetter , Sean Paul , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , "Deucher, Alexander" , "Siqueira, Rodrigo" , "Pillai, Aurabindo" , Bas Nieuwenhuizen , "Cornij, Nikola" , Jani Nikula , Manasi Navare , Ankit Nautiyal , =?ISO-8859-1?Q?Jos=E9?= Roberto de Souza , Sean Paul , Ben Skeggs , "stable@vger.kernel.org" Date: Tue, 02 Nov 2021 18:31:48 -0400 In-Reply-To: References: <20210720160342.11415-1-Wayne.Lin@amd.com> <20210720160342.11415-3-Wayne.Lin@amd.com> <69a5f39580f0d3519468f45ecbfd50d7ad1b3036.camel@redhat.com> <292d6ead03d6afe54f81d52f705e38bbf9feb7bd.camel@redhat.com> <2012d26bb2bece43e65ce435e6ba03f1d8767f61.camel@redhat.com> <6a0868a8ce6befd5f7ddea3481e70285079fcb6a.camel@redhat.com> <5282ad02ecd3fde8ab78fe798f066a5c03153815.camel@redhat.com> Organization: Red Hat Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-2.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Fri, 2021-10-29 at 12:11 +0000, Lin, Wayne wrote: > [Public] > > Thanks Lyude for patiently guiding on this : ) > Would like to learn more as following I do follow your bit about connectors only being created when a virtual path is instantiated, but that still doesn't follow how connectors in DRM typically behave though as this idea still comes down to "we don't have disconnected connectors, only connected ones". Which still breaks force probing (if the connector doesn't exist in userspace because we destroyed it, how do we get to it's force sysfs file?), and also just makes hides information from userspace that it might actually care about (what if for instance, a GUI wanted to display the topology layout of an MST hub -including- all of the currently disconnected ports on it? Considering we allow this for things like USB, it doesn't make sense to hide them for MST. As well, while your idea for what an MST connector is honestly does make a lot more sense then what we have, that's not really the issue here. The problem is that connector creation/destruction is already quite racy, and requires a _lot_ of care to get right. We've already had tons of bugs in the past that lead to us resorting to all of the tricks we're currently using, for instance: Which just seems to add a lot of complication to the current MST code, without much reason here besides trying to reduce the amount of connectors along with a potential bug with leaking connectors that we still don't know the cause of. Trying to solve problems without understanding exactly what's causing them something around a bug that could be entirely unrelated to how we create connectors, because then it's not even really guaranteed we've fixed anything if we don't know what caused the problem in the first place. Working around problems might temporarily fix the ones we're dealing with right now, but without understanding what's causing it there's no guarantee it won't just pop up again in the future or that we won't introduce new problems in the process. > > > > > Regardless though, I would think that we could just handle this mostly > > from the atomic state even with a connector for every port. For > > instance, i915 already has something called "big joiner" for supporting > > display configurations where one display can take up two > > separate display pipes (CRTCs). We could likely do something similar but > > with connectors if we end up having to deal with a display > > driven by two DP links. > > > > > I was thinking to associate a drm connector for end stream sink only. > > > I think we probably won't want to attach a connector to a > > > relay/retimer/redriver within a stream path? I treat MST port as the > > > similar role when It's fixed to connect to a MST branch device. > > > > If it's a fixed connection, this might actually be OK to avoid attaching > > connectors on. Currently with input ports where we know we can > > never receive a CSN for them during runtime, we're able to avoid creating > > a connector because no potential for CSN during runtime > > means the only possible time an input port could transition would be > > suspend/resume. So if we detect we're on another topology > > where something that was previously an output port that is an input port > > on the new topology, we get rid of the connector by > > removing the drm_dp_mst_port it's associated with from the topology and > > replace it with a new one. This works pretty well, as it > > avoids doing any actual connector destruction from the suspend/resume > > codepath and ensures that any pointer references to the > > now non-existent output port remain valid for as long as needed. So I > > might actually be open to expanding this for fixed connections > > like relays, retimers and redrivers if we handle things in a similar > > manner. > > For anything that can receive a CSN though, a drm_connector is > > unconditionally needed even if nothing's connected. > > Want to deepen my knowledge here. Sorry Lyude could you explain more on this > please? > Are you saying that if we change to associate drm connector as what I > proposed in this patch, we will create actual connector destruction > from the suspend/resume codepath and which is a problem here? I thought once > the connection status changed from connected to > disconnected during suspend/resume, we still use the same way as what we did > in drm_dp_delayed_destroy_port(): > i.e. > if (port->connector) { >         drm_connector_unregister(port->connector); >         drm_connector_put(port->connector); > } > We won't directly destruct the drm connector? Something like that, I'd need to to go look further into the details because I very vividly remember most of the tricks we do in the MST helpers regarding delayed connector destruction and when/how we change various members of the drm_dp_mst_port/drm_dp_mst_branch structures. I vaguely remember the problem with trying to hot add/remove connectors (I -did- actually try to do this once I believe! but not as thoroughly as you have) being some kind of lockdep issue. I started trying to dig into the MST code a bit deeper to get a clear answer on this, but I actually decided to take that time and just finish up the debug helpers I mentioned (I'll send the WIP patch I've got to you in a moment, and will send it off the mailing list once I finish hooking things up in i915) because it really just doesn't seem to me like we actually have a clear understanding of how this issue is being caused - and it's not a good idea for us to make any kind of API change like this to attempt (and inevitably fail or break something else) to fix an issue we don't fully understand. [snip...] > > > Right! I might not recall correctly, but I think that's why I want this > patch. I probably encountered that userspace doesn’t explicitly > try to react to this unplug event. Instead, it tries to react when we plug > in monitor next time. And the problem is when we plug in > monitor next time, stale resources are not released yet. It then hits the > limitation within our HW. Which let me want to explicitly > release resource once driver detect the unplug event (just like sst long HPD > event I think).  By the way, just out of curiosity, when > do you think is the timing to release sink related resource if we rely on > hotplug event notifying userspace? When userspace frees the > associated pipe of the connector? Won't it be a transient state that > userspace just free the pipe temporarily? The timing of releasing resources should be done at the same time that we disable the connector. In general, MST modesetting shouldn't be much different from anything else - except for having to maintain a payload table and bandwidth limitations across a shared connection. So pretty much everything related to enabling or disabling streams should be in the atomic commit phase (with any bandwidth calculations done beforehand, WIP...). I'm going to say, let's figure out where this is happening first. I've got the debugging patches for this ready and will send them to you now. > > > Also, I'm still working on the debugging stuff btw! > Much appreciate Lyude! Thanks! > > > > > -- > > Cheers, > >  Lyude Paul (she/her) > >  Software Engineer at Red Hat > -- > Regards, > Wayne Lin -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C0749C433FE for ; Tue, 2 Nov 2021 22:31:56 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 8842F60273 for ; Tue, 2 Nov 2021 22:31:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8842F60273 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CA00D6E0C1; Tue, 2 Nov 2021 22:31:55 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id 729B96E0A6 for ; Tue, 2 Nov 2021 22:31:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1635892313; 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=s7LptIgu+syWserQTVVGwm5xGU03s5Ksw96xU5k2+b0=; b=CsBIGMpp198JmXtnLNTNsG2OnnUizzxONN7lb6UX0/7PEsXArmHvIzShxpsVSAkjkMzFIx Bal422pmoC+Yg8r2+AAFGdXdVOJXI+6KQD5JcczTjy95uNWx23tdTWfO2X+HR3WYa53YpG n3IMwClEYnviXZ9XBBw7ZoYv1SAqCZQ= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-286-FD1HXnSdOQObQcdogX0kkw-1; Tue, 02 Nov 2021 18:31:52 -0400 X-MC-Unique: FD1HXnSdOQObQcdogX0kkw-1 Received: by mail-qv1-f72.google.com with SMTP id j9-20020a05621419c900b003b815c01a54so467017qvc.10 for ; Tue, 02 Nov 2021 15:31:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:organization:user-agent:mime-version :content-transfer-encoding; bh=s7LptIgu+syWserQTVVGwm5xGU03s5Ksw96xU5k2+b0=; b=66O8Fq/Sai57SEyg6Gst7BiexxjyI2mLB3w0FRxKldsbpYi0wAJqVamV4jfcafvX5o ngKeIPf4cy4G2uUGpZ1L325dt+9dRWdnlXe1K/c9ThC4uL+61zrMTto8SfSnCobD/8Vz xhgZkC+rjDzP4BMBPrQziYAv/i+HGrhBzfuhIO2tY4AMtwnDFXMZmWqf/+oj1s+U2F/q r5gR/Vh9xaF6d13Tbw8UKr2ncPyFtwFmZ9oMw4ZAkIJojOVNmznoPBDjqtBxESyEz5SQ mntzfDI/OwXSMHmaq5yzmPDnsaALVCz0jg1zBRpIYjyiAaLt37NgTmyG5IblI4MfukIY O5kA== X-Gm-Message-State: AOAM532tNyyRelIm8esT0VwCSk+WkC9lxwgE90nVfp667C32Zfs+oMLF exeKqygnEyoowsFwKWE0B3RMmqvsHNCJdjb2wHrrwME6mHHLNodxDt08xSXoHiE3x/RSvqAVdho q0Q23rfegGzM8iJqeQfwDxipa22lp X-Received: by 2002:a05:620a:25c8:: with SMTP id y8mr31292618qko.42.1635892311495; Tue, 02 Nov 2021 15:31:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz4Mn2/N4/VkaTugW1IbEV+gcQbmtzqiNbmi541UL6/BSzvvYeXqRyvJXZucZIrbqNTBihSRA== X-Received: by 2002:a05:620a:25c8:: with SMTP id y8mr31292576qko.42.1635892311148; Tue, 02 Nov 2021 15:31:51 -0700 (PDT) Received: from [192.168.8.138] (pool-96-230-249-157.bstnma.fios.verizon.net. [96.230.249.157]) by smtp.gmail.com with ESMTPSA id n18sm244365qtk.91.2021.11.02.15.31.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Nov 2021 15:31:50 -0700 (PDT) Message-ID: <0badd704d7014481cc87a42e58c96a84205f1ca3.camel@redhat.com> Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected end device From: Lyude Paul To: "Lin, Wayne" , "dri-devel@lists.freedesktop.org" Date: Tue, 02 Nov 2021 18:31:48 -0400 In-Reply-To: References: <20210720160342.11415-1-Wayne.Lin@amd.com> <20210720160342.11415-3-Wayne.Lin@amd.com> <69a5f39580f0d3519468f45ecbfd50d7ad1b3036.camel@redhat.com> <292d6ead03d6afe54f81d52f705e38bbf9feb7bd.camel@redhat.com> <2012d26bb2bece43e65ce435e6ba03f1d8767f61.camel@redhat.com> <6a0868a8ce6befd5f7ddea3481e70285079fcb6a.camel@redhat.com> <5282ad02ecd3fde8ab78fe798f066a5c03153815.camel@redhat.com> Organization: Red Hat User-Agent: Evolution 3.40.4 (3.40.4-2.fc34) MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lyude@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: David Airlie , Daniel Vetter , =?ISO-8859-1?Q?Jos=E9?= Roberto de Souza , "Siqueira, Rodrigo" , "Zuo, Jerry" , "Pillai, Aurabindo" , Ben Skeggs , Ankit Nautiyal , Juston Li , Thomas Zimmermann , Jani Nikula , "Cornij, Nikola" , "Wu, Hersen" , Sean Paul , "stable@vger.kernel.org" , Manasi Navare , "Deucher, Alexander" , Sean Paul , "Kazlauskas, Nicholas" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, 2021-10-29 at 12:11 +0000, Lin, Wayne wrote: > [Public] > > Thanks Lyude for patiently guiding on this : ) > Would like to learn more as following I do follow your bit about connectors only being created when a virtual path is instantiated, but that still doesn't follow how connectors in DRM typically behave though as this idea still comes down to "we don't have disconnected connectors, only connected ones". Which still breaks force probing (if the connector doesn't exist in userspace because we destroyed it, how do we get to it's force sysfs file?), and also just makes hides information from userspace that it might actually care about (what if for instance, a GUI wanted to display the topology layout of an MST hub -including- all of the currently disconnected ports on it? Considering we allow this for things like USB, it doesn't make sense to hide them for MST. As well, while your idea for what an MST connector is honestly does make a lot more sense then what we have, that's not really the issue here. The problem is that connector creation/destruction is already quite racy, and requires a _lot_ of care to get right. We've already had tons of bugs in the past that lead to us resorting to all of the tricks we're currently using, for instance: Which just seems to add a lot of complication to the current MST code, without much reason here besides trying to reduce the amount of connectors along with a potential bug with leaking connectors that we still don't know the cause of. Trying to solve problems without understanding exactly what's causing them something around a bug that could be entirely unrelated to how we create connectors, because then it's not even really guaranteed we've fixed anything if we don't know what caused the problem in the first place. Working around problems might temporarily fix the ones we're dealing with right now, but without understanding what's causing it there's no guarantee it won't just pop up again in the future or that we won't introduce new problems in the process. > > > > > Regardless though, I would think that we could just handle this mostly > > from the atomic state even with a connector for every port. For > > instance, i915 already has something called "big joiner" for supporting > > display configurations where one display can take up two > > separate display pipes (CRTCs). We could likely do something similar but > > with connectors if we end up having to deal with a display > > driven by two DP links. > > > > > I was thinking to associate a drm connector for end stream sink only. > > > I think we probably won't want to attach a connector to a > > > relay/retimer/redriver within a stream path? I treat MST port as the > > > similar role when It's fixed to connect to a MST branch device. > > > > If it's a fixed connection, this might actually be OK to avoid attaching > > connectors on. Currently with input ports where we know we can > > never receive a CSN for them during runtime, we're able to avoid creating > > a connector because no potential for CSN during runtime > > means the only possible time an input port could transition would be > > suspend/resume. So if we detect we're on another topology > > where something that was previously an output port that is an input port > > on the new topology, we get rid of the connector by > > removing the drm_dp_mst_port it's associated with from the topology and > > replace it with a new one. This works pretty well, as it > > avoids doing any actual connector destruction from the suspend/resume > > codepath and ensures that any pointer references to the > > now non-existent output port remain valid for as long as needed. So I > > might actually be open to expanding this for fixed connections > > like relays, retimers and redrivers if we handle things in a similar > > manner. > > For anything that can receive a CSN though, a drm_connector is > > unconditionally needed even if nothing's connected. > > Want to deepen my knowledge here. Sorry Lyude could you explain more on this > please? > Are you saying that if we change to associate drm connector as what I > proposed in this patch, we will create actual connector destruction > from the suspend/resume codepath and which is a problem here? I thought once > the connection status changed from connected to > disconnected during suspend/resume, we still use the same way as what we did > in drm_dp_delayed_destroy_port(): > i.e. > if (port->connector) { >         drm_connector_unregister(port->connector); >         drm_connector_put(port->connector); > } > We won't directly destruct the drm connector? Something like that, I'd need to to go look further into the details because I very vividly remember most of the tricks we do in the MST helpers regarding delayed connector destruction and when/how we change various members of the drm_dp_mst_port/drm_dp_mst_branch structures. I vaguely remember the problem with trying to hot add/remove connectors (I -did- actually try to do this once I believe! but not as thoroughly as you have) being some kind of lockdep issue. I started trying to dig into the MST code a bit deeper to get a clear answer on this, but I actually decided to take that time and just finish up the debug helpers I mentioned (I'll send the WIP patch I've got to you in a moment, and will send it off the mailing list once I finish hooking things up in i915) because it really just doesn't seem to me like we actually have a clear understanding of how this issue is being caused - and it's not a good idea for us to make any kind of API change like this to attempt (and inevitably fail or break something else) to fix an issue we don't fully understand. [snip...] > > > Right! I might not recall correctly, but I think that's why I want this > patch. I probably encountered that userspace doesn’t explicitly > try to react to this unplug event. Instead, it tries to react when we plug > in monitor next time. And the problem is when we plug in > monitor next time, stale resources are not released yet. It then hits the > limitation within our HW. Which let me want to explicitly > release resource once driver detect the unplug event (just like sst long HPD > event I think).  By the way, just out of curiosity, when > do you think is the timing to release sink related resource if we rely on > hotplug event notifying userspace? When userspace frees the > associated pipe of the connector? Won't it be a transient state that > userspace just free the pipe temporarily? The timing of releasing resources should be done at the same time that we disable the connector. In general, MST modesetting shouldn't be much different from anything else - except for having to maintain a payload table and bandwidth limitations across a shared connection. So pretty much everything related to enabling or disabling streams should be in the atomic commit phase (with any bandwidth calculations done beforehand, WIP...). I'm going to say, let's figure out where this is happening first. I've got the debugging patches for this ready and will send them to you now. > > > Also, I'm still working on the debugging stuff btw! > Much appreciate Lyude! Thanks! > > > > > -- > > Cheers, > >  Lyude Paul (she/her) > >  Software Engineer at Red Hat > -- > Regards, > Wayne Lin -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat