Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp770661pxb; Fri, 14 Jan 2022 16:15:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJyeytvhzh3VpneiqQStKHcwxCwI2LTPkLj+ACXoEKk3TvbFVaNLIL9xg+nCv/XpUehAzqqg X-Received: by 2002:aa7:c941:: with SMTP id h1mr11167537edt.319.1642205715286; Fri, 14 Jan 2022 16:15:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642205715; cv=none; d=google.com; s=arc-20160816; b=OVrt6BcRiE0mDo8Cahbwgqx/ndfaXIiV0wZzGx3Y6OGpqRKvqHs7hsJsVKbKwyAmDB 32GEWRzCn3mGf2CYuNQkfU/6Ww+TlOfFj1ULL0YKw6bsrNP6/zdN30DCEfUbpR0227pb eVhpCDaYX4q50daI3irAx3w3diKEpJ+5I3dO7+leHjOlLuZw/6cyJH5+0kdZ78kli+39 owkFe6Gbb+5VJSgxiL72nv74SX6tSHOHph7xSW+xRmsMWabiZnXbBxFWzOTVrlwkMr8H us4fjdJXJ9xMS1kSwVBESiIvGVFkwfR+rv5t1/l7t6aPuNOTKCqdVKfPEre7uqnxTNeW hqUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=SMYVXUFcqvm73ktl2Lmgp3uM9JleJ3uNnTtTQe48tYY=; b=jcPerJ5e/4hsbhfV8wNLxOAIEpPWYh3vpW1+Pgpc51W/gQvuPQNEvhnEDLD0zX+pRD ZMOKfS+xb5Rn8ejtX48/xjaKOfqb0bUu1hgIoJ41I3VucKwyJ5HPynYe//tavzRMP6D8 zBOgGSRI6y8aIYr4gjIkpfpJL5ya6wuknSfnZSP7dL9ZTzZXwsORStuXuPP0d9Wbbh4c K3c02YUkFw+5+xYPqL6QZizbCJc3nEkcgFScvVDvcW9Iheuk6OrpFr5uCObrjQhd/htj nZldVCfssdNGEZwNH0RSL6aJ73aOKIvgKRplWgPWxaaUGieM8+Jg60j23vtKYDpB5Vp4 f8Qg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=Vsgqy6d9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e17si4472712edz.432.2022.01.14.16.14.45; Fri, 14 Jan 2022 16:15:15 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=Vsgqy6d9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230440AbiANW2z (ORCPT + 99 others); Fri, 14 Jan 2022 17:28:55 -0500 Received: from alexa-out-sd-02.qualcomm.com ([199.106.114.39]:34147 "EHLO alexa-out-sd-02.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230310AbiANW2z (ORCPT ); Fri, 14 Jan 2022 17:28:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1642199335; x=1673735335; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=SMYVXUFcqvm73ktl2Lmgp3uM9JleJ3uNnTtTQe48tYY=; b=Vsgqy6d9rwoEH0jqTJ4bNigZVbEaiRP6MQQlChWY7OapKZ45qi7kTPsW RkeJmr44prPiGoke8/dCFZ8SfagKHea5K8N0R+T4sf1Yv43r7Q8LsFpc9 mpsZRN98ZmGZUqoteE0PGgNXAyMHpsjCWrrJTmLwzsTE6J/j9QVUxZQ8O 8=; Received: from unknown (HELO ironmsg04-sd.qualcomm.com) ([10.53.140.144]) by alexa-out-sd-02.qualcomm.com with ESMTP; 14 Jan 2022 14:28:54 -0800 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg04-sd.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jan 2022 14:28:54 -0800 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.922.19; Fri, 14 Jan 2022 14:28:53 -0800 Received: from [10.110.125.36] (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.922.19; Fri, 14 Jan 2022 14:28:52 -0800 Message-ID: Date: Fri, 14 Jan 2022 14:28:52 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH v15 1/4] drm/msm/dp: do not initialize phy until plugin interrupt received Content-Language: en-US To: Stephen Boyd , , , , , , , , , CC: , , , , , References: <1642194710-2512-1-git-send-email-quic_khsieh@quicinc.com> <1642194710-2512-2-git-send-email-quic_khsieh@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: nasanex01a.na.qualcomm.com (10.52.223.231) To nalasex01a.na.qualcomm.com (10.47.209.196) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/14/2022 1:41 PM, Stephen Boyd wrote: > Quoting Kuogee Hsieh (2022-01-14 13:11:47) >> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c >> index 7cc4d21..7cd6222 100644 >> --- a/drivers/gpu/drm/msm/dp/dp_display.c >> +++ b/drivers/gpu/drm/msm/dp/dp_display.c >> @@ -696,12 +699,9 @@ static int dp_irq_hpd_handle(struct dp_display_private *dp, u32 data) >> * dp core (ahb/aux clks) must be initialized before >> * irq_hpd be handled >> */ >> - if (dp->core_initialized) { >> - ret = dp_display_usbpd_attention_cb(&dp->pdev->dev); >> - if (ret == -ECONNRESET) { /* cable unplugged */ >> - dp->core_initialized = false; >> - } >> - } >> + if (dp->core_initialized) > When is this condition false? The irq isn't unmasked until the core has > been initialized. On the resume path I suppose the irq is enabled in > dp_display_host_init() calling dp_ctrl_reset_irq_ctrl(), and then we > could immediately get the interrupt but it will block on the event_mutex > lock. This is left over form Lazor. I remember that there is an extreme case that several irq_hpd interrupts happen right after dongle plug inĀ  (happen at resume too) and sometime cause system crash at dpcd read due to AHB clock is not enabled yet. It took some time to debug it. From looking into code, it does not look likely it will happen. But it did happen at real world. So that I would like to keep this condition checking. >> + dp_display_usbpd_attention_cb(&dp->pdev->dev); >> + >> DRM_DEBUG_DP("hpd_state=%d\n", state); >> >> mutex_unlock(&dp->event_mutex); >> @@ -1363,14 +1373,16 @@ static int dp_pm_suspend(struct device *dev) >> if (dp_power_clk_status(dp->power, DP_CTRL_PM)) >> dp_ctrl_off_link_stream(dp->ctrl); >> >> + dp_display_host_phy_exit(dp); >> + >> + /* host_init will be called at pm_resume */ >> dp_display_host_deinit(dp); >> + } else { >> + dp_display_host_phy_exit(dp); > I fail to see where this condition happens. Can we suspend the device > without the irq being installed? Agree, with this new mechanism it should not happen. Will remove it. >> } >> >> dp->hpd_state = ST_SUSPENDED; >> >> - /* host_init will be called at pm_resume */ >> - dp->core_initialized = false; >> - >> DRM_DEBUG_DP("After, core_inited=%d power_on=%d\n", >> dp->core_initialized, dp_display->power_on); >>