Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp202493pxy; Tue, 20 Apr 2021 16:41:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxxDnfGMO9mSA3UOQN8JmW1AYcwDI8wceT6hc1kap1zQO9f8VlFraufFQHB3aw2qS4Q1A1Y X-Received: by 2002:a05:6402:22f9:: with SMTP id dn25mr34828194edb.171.1618962100202; Tue, 20 Apr 2021 16:41:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618962100; cv=none; d=google.com; s=arc-20160816; b=OgtDUOeQja97Ev2ZSiX5tS7EKlJP/lceJvbJmBYbQY+VRPilu0+AxwI7VLpRrcSCSV TMJEJMEFjzdiwvtESHoxsBh2FaBG9mPJpOSOfNPqBdeQOfOXhp6k5YYCx+/e/de5FucC WyV5NrIgEnMcJvmVANPrgnIh+eRyplgXNcPk7unKLzwns219PPjl0eU4WFdb1s3B7LP4 J4MnfsVr3J8VBgsdH1K80L+t6wJ1f9Bz3N/qxTzMggYA2hR7CSB07k9YYbDZrgk8CGKg PVeCHdJq9KV2jiSw4b4sJgofzshDpen/K+TBwJ+U5J+6iYFsh0lOGlz1CS5mh9lFgSNe 8FSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:message-id:date:to:cc:from:subject :references:in-reply-to:content-transfer-encoding:mime-version :dkim-signature; bh=rUEcOAL+JdYx7iw/rsaYqBg6P/fDtNoMJwsAvdMr4k8=; b=P+ORiE0DZFKR02Gg857YqWazqVmDB4aj4Dg5goXxUfFZoK10vPtY0oP8z6Esj0UIMH 1dNvO5pi3AU466L5sw88Gc/atukV1GKWzfcGB8BZfNuES+jf09MHhz/eJcTL4Rr1j3zr vzeuHTJUYspbVU/rDSPk4AQWOFgqcmd667y8YIO+vzfGtbOTFEPNal+G9djCAVzyIEhW +HTd3YrQMlFDBxKeLGkCRWkDmkcDO3P8yY0DOS+3A5Gi9rtJRiMIa9n/AMo2LGQtQMFt VQUb5QYR3B2c5Tr8+Wfidafsspv9q0nStEpoT0ScmwfhMvV/Y36TvzKDbcZFo8hyLvk4 fcrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ZtpSHHCa; 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=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p31si498477edb.415.2021.04.20.16.41.14; Tue, 20 Apr 2021 16:41:40 -0700 (PDT) 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=@chromium.org header.s=google header.b=ZtpSHHCa; 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=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234444AbhDTXj0 (ORCPT + 99 others); Tue, 20 Apr 2021 19:39:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60012 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234437AbhDTXjZ (ORCPT ); Tue, 20 Apr 2021 19:39:25 -0400 Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6680AC06174A for ; Tue, 20 Apr 2021 16:38:53 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id m12so7237143pgr.9 for ; Tue, 20 Apr 2021 16:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:content-transfer-encoding:in-reply-to:references :subject:from:cc:to:date:message-id:user-agent; bh=rUEcOAL+JdYx7iw/rsaYqBg6P/fDtNoMJwsAvdMr4k8=; b=ZtpSHHCa3/J8Q01BlM9ud01JiqjG6VpT4jrLH7nfoh0ZpIi8KROK+UzYFdOnAHv64Y CPOB9aO3tqTwU+EzkIGARznb+Fck3IRcGC/40Qx1xaqQSg93VSjQwgwG6CVyaSvLvI7Q I9dscI7B21TE96Aa8oufyl1VbcaTs4vfL2n5k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :in-reply-to:references:subject:from:cc:to:date:message-id :user-agent; bh=rUEcOAL+JdYx7iw/rsaYqBg6P/fDtNoMJwsAvdMr4k8=; b=Uis/XQfjwHX+7HhE246Y6UqyOVIiQW30oJazGHZs6STLvojEsC4fE9M1rLDw+SLz73 2CIBIByzgnLNorVNmdDRUHLMuVUg7JMOX3+jLG7MqAu1Pl5lEsumsUwTVc9QU2Er8hQx juGO/vO50AUcpj/yBxw/Br7ohuxcK9QD9Q/MATWJNrUbvUPWX69HIfcfa4Tt9ESe0nbt t+RWFiqP5FiY6onmzaMFrSutgu1bfuG2Mazpd0J3x+2n3BvBRnDGMlGfQ+rJRdhCxAve g8jtk6+5oVGE2fKNbo4cDd12o4CeTMW33wRIJoKpMAvllSssBwxoJ4d3bsN5yPlmQTYV dHFA== X-Gm-Message-State: AOAM530IXd+GYFyzzxbRHMftHo+NyZ+JHQd64vhUGEFFL1Tp19Z9dIwi vlX+22jvEuxIB2IMj0yBOE88BA== X-Received: by 2002:a17:90a:9509:: with SMTP id t9mr7754936pjo.3.1618961932968; Tue, 20 Apr 2021 16:38:52 -0700 (PDT) Received: from chromium.org ([2620:15c:202:201:bf8b:4b8b:2315:3719]) by smtp.gmail.com with ESMTPSA id r3sm111567pfl.159.2021.04.20.16.38.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Apr 2021 16:38:52 -0700 (PDT) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <1618594731-556-1-git-send-email-khsieh@codeaurora.org> References: <1618594731-556-1-git-send-email-khsieh@codeaurora.org> Subject: Re: [PATCH v3 3/3] drm/msm/dp: check main link status before start aux read From: Stephen Boyd Cc: abhinavk@codeaurora.org, aravindh@codeaurora.org, khsieh@codeaurora.org, airlied@linux.ie, daniel@ffwll.ch, linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org To: Kuogee Hsieh , robdclark@gmail.com, sean@poorly.run Date: Tue, 20 Apr 2021 16:38:50 -0700 Message-ID: <161896193053.46595.7590816467281538002@swboyd.mtv.corp.google.com> User-Agent: alot/0.9.1 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Kuogee Hsieh (2021-04-16 10:38:51) > Maybe when the cable is disconnected the DP phy should be shutdown and > some bit in the phy could effectively "cut off" the aux channel and then > NAKs would start coming through here in the DP controller I/O register > space. This patch have DP aux channel read/write to return NAK immediately > if DP controller connection status is in unplugged state. >=20 > Changes in V3: > -- check core_initialized before handle irq_hpd > Signed-off-by: Kuogee Hsieh > --- > drivers/gpu/drm/msm/dp/dp_aux.c | 5 +++++ > drivers/gpu/drm/msm/dp/dp_display.c | 14 ++++++++++---- > drivers/gpu/drm/msm/dp/dp_link.c | 20 +++++++++++++++----- > 3 files changed, 30 insertions(+), 9 deletions(-) >=20 > diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_= aux.c > index 7c22bfe..fae3806 100644 > --- a/drivers/gpu/drm/msm/dp/dp_aux.c > +++ b/drivers/gpu/drm/msm/dp/dp_aux.c > @@ -343,6 +343,11 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp= _aux, > =20 > mutex_lock(&aux->mutex); > =20 > + if (!dp_catalog_link_is_connected(aux->catalog)) { > + ret =3D -ETIMEDOUT; > + goto unlock_exit; > + } > + This still makes me concerned. Any possibility to not do this and have the phy cut the connection off and have this transfer timeout immediately? > aux->native =3D msg->request & (DP_AUX_NATIVE_WRITE & DP_AUX_NATI= VE_READ); > =20 > /* Ignore address only message */ > diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp= /dp_display.c > index 1784e11..db3f45e 100644 > --- a/drivers/gpu/drm/msm/dp/dp_display.c > +++ b/drivers/gpu/drm/msm/dp/dp_display.c > @@ -571,7 +571,7 @@ static int dp_hpd_plug_handle(struct dp_display_priva= te *dp, u32 data) > dp->hpd_state =3D ST_DISCONNECTED; > =20 > if (ret =3D=3D -ECONNRESET) { /* cable unplugged */ > - dp->core_initialized =3D false; > + DRM_ERROR("dongle unplugged =3D %d\n", ret); Is this a debug message? > } > =20 > } else { > @@ -711,9 +711,15 @@ static int dp_irq_hpd_handle(struct dp_display_priva= te *dp, u32 data) > return 0; > } > =20 > - ret =3D dp_display_usbpd_attention_cb(&dp->pdev->dev); > - if (ret =3D=3D -ECONNRESET) { /* cable unplugged */ > - dp->core_initialized =3D false; > + /* > + * dp core (ahb/aux clks) must be initialized before > + * irq_hpd be handled > + */ > + if (dp->core_initialized) { > + ret =3D dp_display_usbpd_attention_cb(&dp->pdev->dev); > + if (ret =3D=3D -ECONNRESET) { /* cable unplugged */ > + DRM_ERROR("dongle unplugged =3D %d\n", ret); Another debug message? > + } > } > =20 > mutex_unlock(&dp->event_mutex); > diff --git a/drivers/gpu/drm/msm/dp/dp_link.c b/drivers/gpu/drm/msm/dp/dp= _link.c > index be986da..53ecae6 100644 > --- a/drivers/gpu/drm/msm/dp/dp_link.c > +++ b/drivers/gpu/drm/msm/dp/dp_link.c > @@ -737,18 +737,25 @@ static int dp_link_parse_sink_count(struct dp_link = *dp_link) > return 0; > } > =20 > -static void dp_link_parse_sink_status_field(struct dp_link_private *link) > +static int dp_link_parse_sink_status_field(struct dp_link_private *link) > { > int len =3D 0; > =20 > link->prev_sink_count =3D link->dp_link.sink_count; > - dp_link_parse_sink_count(&link->dp_link); > + len =3D dp_link_parse_sink_count(&link->dp_link); > + if (len < 0) { > + DRM_ERROR("DP parse sink count failed\n"); > + return len; > + } > =20 > len =3D drm_dp_dpcd_read_link_status(link->aux, > link->link_status); > - if (len < DP_LINK_STATUS_SIZE) > + if (len < DP_LINK_STATUS_SIZE) { > DRM_ERROR("DP link status read failed\n"); > - dp_link_parse_request(link); > + return len; > + } > + > + return dp_link_parse_request(link); > } > =20 > /** > @@ -1032,7 +1039,10 @@ int dp_link_process_request(struct dp_link *dp_lin= k) > =20 > dp_link_reset_data(link); > =20 > - dp_link_parse_sink_status_field(link); > + ret =3D dp_link_parse_sink_status_field(link); > + if (ret) { > + return ret; > + } > =20 > if (link->request.test_requested =3D=3D DP_TEST_LINK_EDID_READ) { > dp_link->sink_request |=3D DP_TEST_LINK_EDID_READ; > --=20 Can you split this part off into another patch? It seems to stand on its own as it makes the code more robust to transfer errors in the sink parsing code.