From nobody Mon May 11 02:06:56 2026 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 79473C433EF for ; Mon, 18 Apr 2022 17:18:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346927AbiDRRVD (ORCPT ); Mon, 18 Apr 2022 13:21:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243899AbiDRRUz (ORCPT ); Mon, 18 Apr 2022 13:20:55 -0400 Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DA8AC24F18 for ; Mon, 18 Apr 2022 10:18:15 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id t184so7005777pgd.4 for ; Mon, 18 Apr 2022 10:18:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=9+5hNAQUGRBcWMyhUpii4SZ/5UNEY0wJyFcuVeraWLE=; b=U9m9xDxROs6AJXCzZAbutdOmIcD7SEJEZyfVo4+CqKf1YtHMSEAC89p81Qq3A1HSzg sRZWMfN4cZg7GlQ0cjKBsgRDzAL4x/cV2ZmLrMe20ZJ/20tThrCmscLUXDNWs+xxmHYE VUfQkvIOnGAd16z5FgdCUu7QL8dWIpV3pNqf4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=9+5hNAQUGRBcWMyhUpii4SZ/5UNEY0wJyFcuVeraWLE=; b=xhyGmFaEngaMNAnoxQ0KZMYo6RoszpCrCpgvCfUqjNGTGhsC33VhhITVTsN3OY0rk0 za4aw4N9li51RHK6NpMK1JSHiXHhOjC8iiBd79XDWbndYfMDpoe8Xt9gKmzOB/S+BBno AyesefXsiMAmgf2/OFe0ttw+uwj/kO6kvs32J9RoKDBEr51X+PDhCKxBwS/BKOrvZv2e djKEvKKciS3evzYmGQ34FpqD97rWTCA7oPZFOKOtBEhj5qTGvUdpknKK0DK9OvCOE0zk rAb7xn47XNmz/FMYh5zaPasZnBXWz7OoUfrAIXs3FY59f4G6NVjd2Sl52Zz2WoUcaByo VxxA== X-Gm-Message-State: AOAM5316A9PsKpwCcYG31I2IqK/+7vU5KWg8Fd1l93STeuZvs1ZJxNqW bAU89ilAoJXtmqk4Hsb0FddYRw== X-Google-Smtp-Source: ABdhPJwB+bu7EH+6U633uQKznBlc8LCNPkt9FKjrOTOZQoBsIoc+zKqtsdsUrREDVd7x4JZVu6g/Cg== X-Received: by 2002:a63:fd05:0:b0:3aa:127d:538a with SMTP id d5-20020a63fd05000000b003aa127d538amr3006395pgh.95.1650302295398; Mon, 18 Apr 2022 10:18:15 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:94f4:f90:c59f:129b]) by smtp.gmail.com with ESMTPSA id n184-20020a6227c1000000b0050a3bbd36d6sm12152126pfn.204.2022.04.18.10.18.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Apr 2022 10:18:15 -0700 (PDT) From: Douglas Anderson To: dri-devel@lists.freedesktop.org Cc: Hsin-Yi Wang , Sankeerth Billakanti , Philip Chen , Robert Foss , Stephen Boyd , Dmitry Baryshkov , Abhinav Kumar , Douglas Anderson , Daniel Vetter , David Airlie , Jani Nikula , Kees Cook , Lyude Paul , Maxime Ripard , linux-kernel@vger.kernel.org Subject: [PATCH v3 1/4] drm/dp: Add wait_hpd_asserted() callback to struct drm_dp_aux Date: Mon, 18 Apr 2022 10:17:54 -0700 Message-Id: <20220418101725.v3.1.Icf57bb12233a47727013c6ab69eebf803e22ebc1@changeid> X-Mailer: git-send-email 2.36.0.rc0.470.gd361397f0d-goog In-Reply-To: <20220418171757.2282651-1-dianders@chromium.org> References: <20220418171757.2282651-1-dianders@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Sometimes it's useful for users of the DP AUX bus (like panels) to be able to poll HPD. Let's add a callback that allows DP AUX busses drivers to provide this. Suggested-by: Dmitry Baryshkov Signed-off-by: Douglas Anderson Reviewed-by: Dmitry Baryshkov --- Left Dmitry's Reviewed-by tag off since patch changed enough. (no changes since v2) Changes in v2: - Change is_hpd_asserted() to wait_hpd_asserted() include/drm/dp/drm_dp_helper.h | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/include/drm/dp/drm_dp_helper.h b/include/drm/dp/drm_dp_helper.h index 53d1e722f4de..0940c415db8c 100644 --- a/include/drm/dp/drm_dp_helper.h +++ b/include/drm/dp/drm_dp_helper.h @@ -2035,6 +2035,32 @@ struct drm_dp_aux { ssize_t (*transfer)(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg); =20 + /** + * @wait_hpd_asserted: wait for HPD to be asserted + * + * This is mainly useful for eDP panels drivers to wait for an eDP + * panel to finish powering on. This is an optional function. + * + * This function will efficiently wait for up to `wait_us` microseconds + * for HPD to be asserted and might sleep. + * + * This function returns 0 if HPD was asserted or -ETIMEDOUT if time + * expired and HPD wasn't asserted. This function should not print + * timeout errors to the log. + * + * The semantics of this function are designed to match the + * readx_poll_timeout() function. That means a `wait_us` of 0 means + * to wait forever. If you want to do a quick poll you could pass 1 + * for `wait_us`. + * + * NOTE: this function specifically reports the state of the HPD pin + * that's associated with the DP AUX channel. This is different from + * the HPD concept in much of the rest of DRM which is more about + * physical presence of a display. For eDP, for instance, a display is + * assumed always present even if the HPD pin is deasserted. + */ + int (*wait_hpd_asserted)(struct drm_dp_aux *aux, unsigned long wait_us); + /** * @i2c_nack_count: Counts I2C NACKs, used for DP validation. */ --=20 2.36.0.rc0.470.gd361397f0d-goog From nobody Mon May 11 02:06:56 2026 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 1D415C433EF for ; Mon, 18 Apr 2022 17:18:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346936AbiDRRVH (ORCPT ); Mon, 18 Apr 2022 13:21:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346908AbiDRRU5 (ORCPT ); Mon, 18 Apr 2022 13:20:57 -0400 Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 79F7624F18 for ; Mon, 18 Apr 2022 10:18:17 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id j71so6483453pge.11 for ; Mon, 18 Apr 2022 10:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=DLAqWrA31cWgX8epcIr4h9J52vxj5o5pqIOrUPKn5S4=; b=KILwivJrPWKKJ1y5zZh+ncB6eMJS2O9v9XkT5RRNeph3Mbmp0KiTr5egSKSVpefSaQ fKFAKVw+EEQnsiQiq9QrFapzWOuW4D27bF0nMgQ9fvFQesXhKqLEXHPfsm2VxI4jehJK zkPQPdkSLyfTs60HrShwO18Qi2n4W56nuc/Ak= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=DLAqWrA31cWgX8epcIr4h9J52vxj5o5pqIOrUPKn5S4=; b=ElKUx16vPtojPXxlvYr1DTkC63vFSPKF9YPU222IeawcR0RvZZ3B/xDioNJuVI/qR4 CKq06FFHFn9pOlg33jUFmm/F0Oi+XLJY75f8YQrAbqTrMTuGxvONw3d7ENJMOXK2HwSG DwV5HEhOlG2/GnmJBF6VtH7JzJpnN9OuHxrvSu1PWnkR+RplYigByeUslCrep9CctSBG uMl/TNE3vpULRkyqmnF+UtRkI/4Sou9ARxInVkHazK/JGyHhVjQIta3KM7KVuHHW9K8g tkaay0RZ/p886Vw2KuaYYuFdAQvqmlTayXW78clgC8CtHkTpF0EsQRYqDZqIzOm6meGK tAZw== X-Gm-Message-State: AOAM532zy010NXNjuMg7ARwwhQfwZdzb817yHVZS4+hDzihLsOvUZTIP ayJEQPZrxVhXSsvQl/NqAK9lSv1HwXS2amrGUPI= X-Google-Smtp-Source: ABdhPJwymO4gXLgRq2ZPiT4Fq2+87RbqQjRO4fTV99PpIyLcWe1ylHS4ghzL7MVN0bYPqe/lCiBeuQ== X-Received: by 2002:a05:6a02:20c:b0:381:f276:98d6 with SMTP id bh12-20020a056a02020c00b00381f27698d6mr10702933pgb.39.1650302297040; Mon, 18 Apr 2022 10:18:17 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:94f4:f90:c59f:129b]) by smtp.gmail.com with ESMTPSA id n184-20020a6227c1000000b0050a3bbd36d6sm12152126pfn.204.2022.04.18.10.18.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Apr 2022 10:18:16 -0700 (PDT) From: Douglas Anderson To: dri-devel@lists.freedesktop.org Cc: Hsin-Yi Wang , Sankeerth Billakanti , Philip Chen , Robert Foss , Stephen Boyd , Dmitry Baryshkov , Abhinav Kumar , Douglas Anderson , Daniel Vetter , David Airlie , Sam Ravnborg , Thierry Reding , linux-kernel@vger.kernel.org Subject: [PATCH v3 2/4] drm/panel-edp: Take advantage of wait_hpd_asserted() in struct drm_dp_aux Date: Mon, 18 Apr 2022 10:17:55 -0700 Message-Id: <20220418101725.v3.2.Icea616f57331fbaa3d48c529f300c9a8ebd37fb5@changeid> X-Mailer: git-send-email 2.36.0.rc0.470.gd361397f0d-goog In-Reply-To: <20220418171757.2282651-1-dianders@chromium.org> References: <20220418171757.2282651-1-dianders@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Let's add support for being able to read the HPD pin even if it's hooked directly to the controller. This will allow us to get more accurate delays also lets us take away the waiting in the AUX transfer functions of the eDP controller drivers. Signed-off-by: Douglas Anderson Reviewed-by: Dmitry Baryshkov --- (no changes since v2) Changes in v2: - Change is_hpd_asserted() to wait_hpd_asserted() drivers/gpu/drm/panel/panel-edp.c | 33 +++++++++++++++++++++---------- 1 file changed, 23 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/pane= l-edp.c index 1732b4f56e38..086e0bf52fb9 100644 --- a/drivers/gpu/drm/panel/panel-edp.c +++ b/drivers/gpu/drm/panel/panel-edp.c @@ -417,6 +417,11 @@ static int panel_edp_get_hpd_gpio(struct device *dev, = struct panel_edp *p) return 0; } =20 +static bool panel_edp_can_read_hpd(struct panel_edp *p) +{ + return !p->no_hpd && (p->hpd_gpio || (p->aux && p->aux->wait_hpd_asserted= )); +} + static int panel_edp_prepare_once(struct panel_edp *p) { struct device *dev =3D p->base.dev; @@ -441,17 +446,21 @@ static int panel_edp_prepare_once(struct panel_edp *p) if (delay) msleep(delay); =20 - if (p->hpd_gpio) { + if (panel_edp_can_read_hpd(p)) { if (p->desc->delay.hpd_absent) hpd_wait_us =3D p->desc->delay.hpd_absent * 1000UL; else hpd_wait_us =3D 2000000; =20 - err =3D readx_poll_timeout(gpiod_get_value_cansleep, p->hpd_gpio, - hpd_asserted, hpd_asserted, - 1000, hpd_wait_us); - if (hpd_asserted < 0) - err =3D hpd_asserted; + if (p->hpd_gpio) { + err =3D readx_poll_timeout(gpiod_get_value_cansleep, + p->hpd_gpio, hpd_asserted, + hpd_asserted, 1000, hpd_wait_us); + if (hpd_asserted < 0) + err =3D hpd_asserted; + } else { + err =3D p->aux->wait_hpd_asserted(p->aux, hpd_wait_us); + } =20 if (err) { if (err !=3D -ETIMEDOUT) @@ -532,18 +541,22 @@ static int panel_edp_enable(struct drm_panel *panel) /* * If there is a "prepare_to_enable" delay then that's supposed to be * the delay from HPD going high until we can turn the backlight on. - * However, we can only count this if HPD is handled by the panel - * driver, not if it goes to a dedicated pin on the controller. + * However, we can only count this if HPD is readable by the panel + * driver. + * * If we aren't handling the HPD pin ourselves then the best we * can do is assume that HPD went high immediately before we were - * called (and link training took zero time). + * called (and link training took zero time). Note that "no-hpd" + * actually counts as handling HPD ourselves since we're doing the + * worst case delay (in prepare) ourselves. * * NOTE: if we ever end up in this "if" statement then we're * guaranteed that the panel_edp_wait() call below will do no delay. * It already handles that case, though, so we don't need any special * code for it. */ - if (p->desc->delay.prepare_to_enable && !p->hpd_gpio && !p->no_hpd) + if (p->desc->delay.prepare_to_enable && + !panel_edp_can_read_hpd(p) && !p->no_hpd) delay =3D max(delay, p->desc->delay.prepare_to_enable); =20 if (delay) --=20 2.36.0.rc0.470.gd361397f0d-goog From nobody Mon May 11 02:06:56 2026 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 7C2D6C433EF for ; Mon, 18 Apr 2022 17:18:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346949AbiDRRVK (ORCPT ); Mon, 18 Apr 2022 13:21:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38132 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346911AbiDRRU6 (ORCPT ); Mon, 18 Apr 2022 13:20:58 -0400 Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0FC526556 for ; Mon, 18 Apr 2022 10:18:18 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id s14so12854028plk.8 for ; Mon, 18 Apr 2022 10:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=CbyBbjg8gyQUteF6HieSyj7KxxSHSKGjYqQSaFd6TEU=; b=Zwq7VaOgsewiCmFbE/n3kyjx9CnT9hrV1iH13ddciUfogTYoP3vKbKr2r6xIr489kr OKKvgazeoIC641p9t8uY7He78fymv9yeCfFKojsIC6FDtcegdms0UggwymRnd6JZkrGq 5T8EUG8NWtHKJD8gs0BWpOtwKWiV2/vvYbvIE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=CbyBbjg8gyQUteF6HieSyj7KxxSHSKGjYqQSaFd6TEU=; b=lPV47yZm5Kva1tcXq7HhpKKHnM1tFB+fhAORJbXMluofcRudLHQ8cDEF8mX0kpdvY0 zbno+fIJBVlJXStHbdeK5aL2gkCV9JLqkfnuLuMEB1t4Nzq4B72EmsSbM1yr5uK6qkNO KHeZxm6VbDsArlHbvULjv6jWbMdBZxSFl14yWfN2zwSWLiTw12jc+daqliXOht5ftO+V gSdNDOjQFxFpRGAuYVHP1e+32FxhbI2m61bWpA4+tE4LZnPdBDB/4lp/F3x8whCd80Ff 6i0bBSO3ED47Mjk9Lz4n9cKqFQNYQVDjifVP+92mYGu8DQ27w0cXfnWYHXJYsPjKNhul ZvYQ== X-Gm-Message-State: AOAM533eCtJayHS9vRKNYYznBhFaRJHPNs3KhMcJaYNHMIuZxXtjBQxm AqvsNiLWUNYK0x4aQEMBofKFUQ== X-Google-Smtp-Source: ABdhPJyaED3SN66kMNUE2uFkmpidmKhbhonRfUkIPOEYVFjhxla397ZKSGrYrID4nNtyd6w2iBhLOw== X-Received: by 2002:a17:902:e98a:b0:159:5f7:49cf with SMTP id f10-20020a170902e98a00b0015905f749cfmr3763147plb.41.1650302298343; Mon, 18 Apr 2022 10:18:18 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:94f4:f90:c59f:129b]) by smtp.gmail.com with ESMTPSA id n184-20020a6227c1000000b0050a3bbd36d6sm12152126pfn.204.2022.04.18.10.18.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Apr 2022 10:18:18 -0700 (PDT) From: Douglas Anderson To: dri-devel@lists.freedesktop.org Cc: Hsin-Yi Wang , Sankeerth Billakanti , Philip Chen , Robert Foss , Stephen Boyd , Dmitry Baryshkov , Abhinav Kumar , Douglas Anderson , Daniel Vetter , David Airlie , Sam Ravnborg , Thierry Reding , linux-kernel@vger.kernel.org Subject: [PATCH v3 3/4] drm/panel: atna33xc20: Take advantage of wait_hpd_asserted() in struct drm_dp_aux Date: Mon, 18 Apr 2022 10:17:56 -0700 Message-Id: <20220418101725.v3.3.I9ee239f6b95b944c8fa030f300ad222a7af9899d@changeid> X-Mailer: git-send-email 2.36.0.rc0.470.gd361397f0d-goog In-Reply-To: <20220418171757.2282651-1-dianders@chromium.org> References: <20220418171757.2282651-1-dianders@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Let's add support for being able to read the HPD pin even if it's hooked directly to the controller. This will let us take away the waiting in the AUX transfer functions of the eDP controller drivers. Signed-off-by: Douglas Anderson --- Changes in v3: - Don't check "hpd_asserted" boolean when unset. - Handle errors from gpiod_get_value_cansleep() properly. Changes in v2: - Change is_hpd_asserted() to wait_hpd_asserted() .../gpu/drm/panel/panel-samsung-atna33xc20.c | 41 +++++++++++++------ 1 file changed, 28 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-samsung-atna33xc20.c b/drivers/gpu= /drm/panel/panel-samsung-atna33xc20.c index 20666b6217e7..5ef1b4032c56 100644 --- a/drivers/gpu/drm/panel/panel-samsung-atna33xc20.c +++ b/drivers/gpu/drm/panel/panel-samsung-atna33xc20.c @@ -19,6 +19,10 @@ #include #include =20 +/* T3 VCC to HPD high is max 200 ms */ +#define HPD_MAX_MS 200 +#define HPD_MAX_US (HPD_MAX_MS * 1000) + struct atana33xc20_panel { struct drm_panel base; bool prepared; @@ -30,6 +34,7 @@ struct atana33xc20_panel { =20 struct regulator *supply; struct gpio_desc *el_on3_gpio; + struct drm_dp_aux *aux; =20 struct edid *edid; =20 @@ -79,7 +84,7 @@ static int atana33xc20_suspend(struct device *dev) static int atana33xc20_resume(struct device *dev) { struct atana33xc20_panel *p =3D dev_get_drvdata(dev); - bool hpd_asserted =3D false; + int hpd_asserted; int ret; =20 /* T12 (Power off time) is min 500 ms */ @@ -91,20 +96,28 @@ static int atana33xc20_resume(struct device *dev) p->powered_on_time =3D ktime_get(); =20 /* - * Handle HPD. Note: if HPD is hooked up to a dedicated pin on the - * eDP controller then "no_hpd" will be false _and_ "hpd_gpio" will be - * NULL. It's up to the controller driver to wait for HPD after - * preparing the panel in that case. + * Note that it's possible that no_hpd is false, hpd_gpio is + * NULL, and wait_hpd_asserted is NULL. This is because + * wait_hpd_asserted() is optional even if HPD is hooked up to + * a dedicated pin on the eDP controller. In this case we just + * assume that the controller driver will wait for HPD at the + * right times. */ if (p->no_hpd) { - /* T3 VCC to HPD high is max 200 ms */ - msleep(200); - } else if (p->hpd_gpio) { - ret =3D readx_poll_timeout(gpiod_get_value_cansleep, p->hpd_gpio, - hpd_asserted, hpd_asserted, - 1000, 200000); - if (!hpd_asserted) - dev_warn(dev, "Timeout waiting for HPD\n"); + msleep(HPD_MAX_MS); + } else { + if (p->hpd_gpio) { + ret =3D readx_poll_timeout(gpiod_get_value_cansleep, + p->hpd_gpio, hpd_asserted, + hpd_asserted, 1000, HPD_MAX_US); + if (hpd_asserted < 0) + ret =3D hpd_asserted; + } else if (p->aux->wait_hpd_asserted) { + ret =3D p->aux->wait_hpd_asserted(p->aux, HPD_MAX_US); + } + + if (ret) + dev_warn(dev, "Error waiting for HPD: %d\n", ret); } =20 return 0; @@ -263,6 +276,8 @@ static int atana33xc20_probe(struct dp_aux_ep_device *a= ux_ep) return -ENOMEM; dev_set_drvdata(dev, panel); =20 + panel->aux =3D aux_ep->aux; + panel->supply =3D devm_regulator_get(dev, "power"); if (IS_ERR(panel->supply)) return dev_err_probe(dev, PTR_ERR(panel->supply), --=20 2.36.0.rc0.470.gd361397f0d-goog From nobody Mon May 11 02:06:56 2026 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 44900C433EF for ; Mon, 18 Apr 2022 17:18:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346956AbiDRRVN (ORCPT ); Mon, 18 Apr 2022 13:21:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38156 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346914AbiDRRVA (ORCPT ); Mon, 18 Apr 2022 13:21:00 -0400 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5163D275D3 for ; Mon, 18 Apr 2022 10:18:20 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id c23so12900472plo.0 for ; Mon, 18 Apr 2022 10:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=0L53oYHs2xpfM/0KB2PlQH0P4g81nTwUTRYFuIiNd6s=; b=SHR/KylnuOzbyVvA4+77Ue/k9IdDmAtt8aBCNSTq/nr7FLyGHwlCa/pcUhFnJei4a/ C4IkQ48bsYfYG2UcAY6qTvN8W2T6z7Jcp892r6/5IHKnnuWTdLzwNaU32cbYKmmLOKg6 nl/SrmrEI4ZhdyKfnUzjgd7rPhb20sHsFLXa4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=0L53oYHs2xpfM/0KB2PlQH0P4g81nTwUTRYFuIiNd6s=; b=EcOv4eYNBLpUMnEssIGxUdG7mDk835VC5q22X7OE/jlOX514a7RxSFtsm51WMRDmzT ZQfztues8CfNhbe1PY6YpgacnophGLlWamk82FW+wkLq/QoFn8FbrZ4WZhWXALm1eTEO Oel2q2QkDf94nkIJrNRkzvgnJfN+VBqUELDKCd1ob2dSm8UNduwZYCfRCbU72lLAkWTO XhoEc6cswMXsUcBm6rAC5RdyfCMVc1P2FKvEEIjNFNfc1MAJ/Op3J0d1WVQr9zXgT3HQ ROSn3RsmBcyauLSwf207RBOVvQ83P4xcsCbF+DyP57KaVGy+iZmijxwzlcD+d05tSLZs hPig== X-Gm-Message-State: AOAM5329/AJNI/A4bqJ26GHccazgdBWCORER55n8b7sCpEMQHE4aWTxB KJLoc9jEy5uwG5gPfCTct5emog== X-Google-Smtp-Source: ABdhPJwzp7RGoB6onpQd3C54oM0zRaPbuNYByMs7PwmxihVrPr9s2193nd4iN+vyhOXz6UgvxvB7PQ== X-Received: by 2002:a17:902:a502:b0:151:8289:b19 with SMTP id s2-20020a170902a50200b0015182890b19mr11683674plq.149.1650302299824; Mon, 18 Apr 2022 10:18:19 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:94f4:f90:c59f:129b]) by smtp.gmail.com with ESMTPSA id n184-20020a6227c1000000b0050a3bbd36d6sm12152126pfn.204.2022.04.18.10.18.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Apr 2022 10:18:19 -0700 (PDT) From: Douglas Anderson To: dri-devel@lists.freedesktop.org Cc: Hsin-Yi Wang , Sankeerth Billakanti , Philip Chen , Robert Foss , Stephen Boyd , Dmitry Baryshkov , Abhinav Kumar , Douglas Anderson , Andrzej Hajda , Daniel Vetter , David Airlie , Jernej Skrabec , Jonas Karlman , Laurent Pinchart , Neil Armstrong , linux-kernel@vger.kernel.org Subject: [PATCH v3 4/4] drm/bridge: parade-ps8640: Provide wait_hpd_asserted() in struct drm_dp_aux Date: Mon, 18 Apr 2022 10:17:57 -0700 Message-Id: <20220418101725.v3.4.Ie827321ce263be52fdb8c1276f6f8cc00d78029f@changeid> X-Mailer: git-send-email 2.36.0.rc0.470.gd361397f0d-goog In-Reply-To: <20220418171757.2282651-1-dianders@chromium.org> References: <20220418171757.2282651-1-dianders@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" This implements the callback added by the patch ("drm/dp: Add wait_hpd_asserted() callback to struct drm_dp_aux"). With this change and all the two "DP AUX Endpoint" drivers changed to use wait_hpd_asserted(), we no longer need to have an long delay in the AUX transfer function. It's up to the panel code to make sure that the panel is powered now. If someone tried to call the aux transfer function without making sure the panel is powered we'll just get a normal transfer failure. We'll still keep the wait for HPD in the pre_enable() function. Though it's probably not actually needed there, this driver is used in the old mode (pre-DP AUX Endpoints) and it may be important for those cases. If nothing else, it shouldn't cause any big problems. Signed-off-by: Douglas Anderson Reviewed-by: Dmitry Baryshkov --- (no changes since v2) Changes in v2: - Change is_hpd_asserted() to wait_hpd_asserted() drivers/gpu/drm/bridge/parade-ps8640.c | 34 ++++++++++++++++---------- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridg= e/parade-ps8640.c index 9766cbbd62ad..2f19a8c89880 100644 --- a/drivers/gpu/drm/bridge/parade-ps8640.c +++ b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -168,23 +168,30 @@ static bool ps8640_of_panel_on_aux_bus(struct device = *dev) return true; } =20 -static int ps8640_ensure_hpd(struct ps8640 *ps_bridge) +static int _ps8640_wait_hpd_asserted(struct ps8640 *ps_bridge, unsigned lo= ng wait_us) { struct regmap *map =3D ps_bridge->regmap[PAGE2_TOP_CNTL]; - struct device *dev =3D &ps_bridge->page[PAGE2_TOP_CNTL]->dev; int status; - int ret; =20 /* * Apparently something about the firmware in the chip signals that * HPD goes high by reporting GPIO9 as high (even though HPD isn't * actually connected to GPIO9). */ - ret =3D regmap_read_poll_timeout(map, PAGE2_GPIO_H, status, - status & PS_GPIO9, 20 * 1000, 200 * 1000); + return regmap_read_poll_timeout(map, PAGE2_GPIO_H, status, + status & PS_GPIO9, wait_us / 10, wait_us); +} =20 - if (ret < 0) - dev_warn(dev, "HPD didn't go high: %d\n", ret); +static int ps8640_wait_hpd_asserted(struct drm_dp_aux *aux, unsigned long = wait_us) +{ + struct ps8640 *ps_bridge =3D aux_to_ps8640(aux); + struct device *dev =3D &ps_bridge->page[PAGE0_DP_CNTL]->dev; + int ret; + + pm_runtime_get_sync(dev); + ret =3D _ps8640_wait_hpd_asserted(ps_bridge, wait_us); + pm_runtime_mark_last_busy(dev); + pm_runtime_put_autosuspend(dev); =20 return ret; } @@ -323,9 +330,7 @@ static ssize_t ps8640_aux_transfer(struct drm_dp_aux *a= ux, int ret; =20 pm_runtime_get_sync(dev); - ret =3D ps8640_ensure_hpd(ps_bridge); - if (!ret) - ret =3D ps8640_aux_transfer_msg(aux, msg); + ret =3D ps8640_aux_transfer_msg(aux, msg); pm_runtime_mark_last_busy(dev); pm_runtime_put_autosuspend(dev); =20 @@ -369,8 +374,8 @@ static int __maybe_unused ps8640_resume(struct device *= dev) * Mystery 200 ms delay for the "MCU to be ready". It's unclear if * this is truly necessary since the MCU will already signal that * things are "good to go" by signaling HPD on "gpio 9". See - * ps8640_ensure_hpd(). For now we'll keep this mystery delay just in - * case. + * _ps8640_wait_hpd_asserted(). For now we'll keep this mystery delay + * just in case. */ msleep(200); =20 @@ -406,7 +411,9 @@ static void ps8640_pre_enable(struct drm_bridge *bridge) int ret; =20 pm_runtime_get_sync(dev); - ps8640_ensure_hpd(ps_bridge); + ret =3D _ps8640_wait_hpd_asserted(ps_bridge, 200 * 1000); + if (ret < 0) + dev_warn(dev, "HPD didn't go high: %d\n", ret); =20 /* * The Manufacturer Command Set (MCS) is a device dependent interface @@ -652,6 +659,7 @@ static int ps8640_probe(struct i2c_client *client) ps_bridge->aux.name =3D "parade-ps8640-aux"; ps_bridge->aux.dev =3D dev; ps_bridge->aux.transfer =3D ps8640_aux_transfer; + ps_bridge->aux.wait_hpd_asserted =3D ps8640_wait_hpd_asserted; drm_dp_aux_init(&ps_bridge->aux); =20 pm_runtime_enable(dev); --=20 2.36.0.rc0.470.gd361397f0d-goog