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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A929C433F5 for ; Wed, 20 Apr 2022 23:57:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1383355AbiDUAA1 (ORCPT ); Wed, 20 Apr 2022 20:00:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40786 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376789AbiDUAAX (ORCPT ); Wed, 20 Apr 2022 20:00:23 -0400 Received: from alexa-out.qualcomm.com (alexa-out.qualcomm.com [129.46.98.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C2E613B2AC; Wed, 20 Apr 2022 16:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1650499056; x=1682035056; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=tV9q1FcF378yrdx5+hEGskQjYdOotMDfqbP0qjm2Llo=; b=M84PGDrYyxK/MuYM0NmLJ5bJb/aoUcCy6EYpKhkrwG1NxUmv3SsC8gDQ fKEXgqksn0gORseeAtRzRDgBTPCbb20Pujsi0DYhdra59K/bBJHPAYjb2 MTOq+vWiZqUdX2/ArZokot0o1oyNbdCWxngjmkPDnyAxzpGCPZZrObOR3 g=; Received: from ironmsg-lv-alpha.qualcomm.com ([10.47.202.13]) by alexa-out.qualcomm.com with ESMTP; 20 Apr 2022 16:57:35 -0700 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg-lv-alpha.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2022 16:57:34 -0700 Received: from nalasex01a.na.qualcomm.com (10.47.209.196) by nasanex01c.na.qualcomm.com (10.47.97.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Wed, 20 Apr 2022 16:57:34 -0700 Received: from [10.110.1.198] (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Wed, 20 Apr 2022 16:57:33 -0700 Message-ID: <0b92cab4-d46b-a419-43ad-0fa08c8c0e4d@quicinc.com> Date: Wed, 20 Apr 2022 16:57:25 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH v2] drm/msm/dp: enhance both connect and disconnect pending_timeout handle Content-Language: en-US To: Stephen Boyd , Dmitry Baryshkov CC: , , , , , , , , , , , , , References: <1649280493-4393-1-git-send-email-quic_khsieh@quicinc.com> <625ce8a0-4e25-5513-5599-c1cdebf5a3a5@linaro.org> <09fd563f-4a2c-f670-51c2-0e5ff023816d@quicinc.com> <2039ef97-4fdb-bffe-1e02-18ae79c18be4@quicinc.com> <27bb2732-b322-75b0-3883-773e6eb4b1b9@linaro.org> <02d31565-4ae4-a319-30b0-76a6e4917f6f@quicinc.com> From: Kuogee Hsieh In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01a.na.qualcomm.com (10.47.209.196) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/20/2022 3:58 PM, Stephen Boyd wrote: > Quoting Kuogee Hsieh (2022-04-15 17:06:48) >> On 4/14/2022 4:34 PM, Dmitry Baryshkov wrote: >>> I'm not sure how should the driver react if the client doesn't disable >>> the output, but then the sink gets reattached? >> I do not know that either. >> >> But it should not happen as long as framework response to uevent. > In talking with seanpaul@ it sounds like we can update the link status > to BAD with drm_connector_set_link_status_property() and then put it > back to GOOD when the link is re-established. This way userspace will > know it needs to retry the modeset. Does that help here? To setup connection, dp driver have to enable phy and do link training then transfer dp controller to video ready state. After that, dp driver signal framework to set up frame buffer fetching/layer mixer and start timing engine at final step to have video stream start transmitting to panel. Do opposite way to tear down connection since dp driver can not reset dp controller and disable phy before timing engine has been stopped. Otherwise vsync timeout or buffer underrun/overrun may happen. this means user space framework need to stop timing engine (stop frame buffer fetching/layer mixer) first and then stop video ready state of dp controller and then disable phy. (note, there may have something else at drm stack need to be teared down but i do not know details) In this case, since framework is not response to uevent to stop timing engine,  dp controller still in video ready state and phy still enabled even dongle had been removed already. At this point, I am not sure what dp driver should do if dongle re plugged back in. Tear down dp mainlink while timing engine is still running and re setup dp mainlink? However, I think this scenario most likely will not happen since if framework responses uevent to setup connection earlier it should be there to response uevent to tear down connection.