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 D761DC43334 for ; Tue, 14 Jun 2022 21:58:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358442AbiFNV6r (ORCPT ); Tue, 14 Jun 2022 17:58:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52786 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237959AbiFNV6Q (ORCPT ); Tue, 14 Jun 2022 17:58:16 -0400 Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8621B1D322 for ; Tue, 14 Jun 2022 14:58:15 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id z11so7576220ilq.6 for ; Tue, 14 Jun 2022 14:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dh0EwzPz3kqagP+w6qwTm8phrVMK+QxhIfwoboe697M=; b=OYiWPsiSfA672A8Ec/CxKQHsYFYdfR8PBm9YnzByfBJE63ZFeEC4Wkh1leHLQaPk0c qrwPp9Royg8qntCuq7K3zRL3/P5RF3CLDXgzwYexeyFSPsGRR24wDzWc4kPDt57PybJe 7+G8/Jty/jyysvXv5N5jjYXx2xw5seJMd5LsM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Dh0EwzPz3kqagP+w6qwTm8phrVMK+QxhIfwoboe697M=; b=ObVS34rxVYskdGDshrvur+2itqHg9tKgVjU25tPcsvnXoxE95bYBgLyK1PdgD+C2Fr fGwiIUojG9BC5mFBEtCEKjtqlsjIN/vj/RMpSQJ4taHKfTW8PHiM2lcF5nGidcUwmhwR tuewKB4TlTZQCBmvxdiE/3+IZjmcf60Igbn/HUIkfi9JWB0SPnH1yYnYFTW+qeoa3Y5P 1N6XOHuLDcRHfrW96XoqRsWur4lPQXeKGJ3sSDEU8FPOHegmkh8/nhuRguvmu/+1zefI QiUk886QBLBL/481CVZeaFXxwSRGAiLzTyX7qoEO7pADdqa36bNjacOdNOkti+19rX+T ILMg== X-Gm-Message-State: AJIora+5GYtuz2fTnqMELCaxEfCbNvbWzbtURERW1coUxt1/S1OKmKny jum68NJ0PeQuClUjHeHgpcpdOlvziv75Ql3r X-Google-Smtp-Source: AGRyM1sGjUxp65904RW0tCUaTsQXZuT4aEDA8TKbI6vENpyQQxwqz+h+WTayFhQxIZhV3MTyv2zHtw== X-Received: by 2002:a92:c567:0:b0:2d1:c3df:eff8 with SMTP id b7-20020a92c567000000b002d1c3dfeff8mr4152153ilj.84.1655243894759; Tue, 14 Jun 2022 14:58:14 -0700 (PDT) Received: from mail-il1-f177.google.com (mail-il1-f177.google.com. [209.85.166.177]) by smtp.gmail.com with ESMTPSA id g18-20020a02c552000000b00332122c106dsm5393218jaj.152.2022.06.14.14.58.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Jun 2022 14:58:13 -0700 (PDT) Received: by mail-il1-f177.google.com with SMTP id d6so7584546ilm.4 for ; Tue, 14 Jun 2022 14:58:13 -0700 (PDT) X-Received: by 2002:a05:6e02:1a6f:b0:2d3:ada4:2f11 with SMTP id w15-20020a056e021a6f00b002d3ada42f11mr4211456ilv.256.1655243893406; Tue, 14 Jun 2022 14:58:13 -0700 (PDT) MIME-Version: 1.0 References: <20220418171757.2282651-1-dianders@chromium.org> <20220418101725.v3.2.Icea616f57331fbaa3d48c529f300c9a8ebd37fb5@changeid> In-Reply-To: From: Doug Anderson Date: Tue, 14 Jun 2022 14:57:52 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 2/4] drm/panel-edp: Take advantage of wait_hpd_asserted() in struct drm_dp_aux To: Dmitry Baryshkov Cc: dri-devel , Hsin-Yi Wang , Sankeerth Billakanti , Philip Chen , Robert Foss , Stephen Boyd , Abhinav Kumar , Daniel Vetter , David Airlie , Sam Ravnborg , Thierry Reding , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Thu, Jun 2, 2022 at 8:12 AM Dmitry Baryshkov wrote: > > On 18/04/2022 20:17, Douglas Anderson wrote: > > 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/panel-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; > > } > > > > +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 = p->base.dev; > > @@ -441,17 +446,21 @@ static int panel_edp_prepare_once(struct panel_edp *p) > > if (delay) > > msleep(delay); > > > > - if (p->hpd_gpio) { > > + if (panel_edp_can_read_hpd(p)) { > > if (p->desc->delay.hpd_absent) > > hpd_wait_us = p->desc->delay.hpd_absent * 1000UL; > > else > > hpd_wait_us = 2000000; > > > > - err = readx_poll_timeout(gpiod_get_value_cansleep, p->hpd_gpio, > > - hpd_asserted, hpd_asserted, > > - 1000, hpd_wait_us); > > - if (hpd_asserted < 0) > > - err = hpd_asserted; > > + if (p->hpd_gpio) { > > + err = readx_poll_timeout(gpiod_get_value_cansleep, > > + p->hpd_gpio, hpd_asserted, > > + hpd_asserted, 1000, hpd_wait_us); > > + if (hpd_asserted < 0) > > + err = hpd_asserted; > > + } else { > > + err = p->aux->wait_hpd_asserted(p->aux, hpd_wait_us); > > + } > > I'm close to thinking that this construct deserves a separate helper. Just to close the loop: I didn't try to create a helper for v5. I'm not completely convinced that this will be common. I would tend to expect that having HPD handled by a GPIO is somewhat rare. It's also fairly rare to have a panel that's not handled by the generic panel-edp. We ended up with the GPIO on trogdor because of the weird debouncing on sn85dsi86 and we ended up with one case of not using edp-panel on trogdor because of the weird power sequencing of the Samsung OLED panel that's on homestar. I'd also note that the generic eDP panel has a special case for "timeout" which we don't have on the Samsung panel to handle at least one panel I found that sometimes simply didn't come up but then _would_ come up on a retry... That doesn't mean we couldn't abstract it out later, of course. ;-) -Doug -Doug 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 211A1C433EF for ; Tue, 14 Jun 2022 21:58:17 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7B369112D4F; Tue, 14 Jun 2022 21:58:16 +0000 (UTC) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) by gabe.freedesktop.org (Postfix) with ESMTPS id F4060112D4F for ; Tue, 14 Jun 2022 21:58:15 +0000 (UTC) Received: by mail-il1-x12b.google.com with SMTP id u2so7594137iln.2 for ; Tue, 14 Jun 2022 14:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dh0EwzPz3kqagP+w6qwTm8phrVMK+QxhIfwoboe697M=; b=OYiWPsiSfA672A8Ec/CxKQHsYFYdfR8PBm9YnzByfBJE63ZFeEC4Wkh1leHLQaPk0c qrwPp9Royg8qntCuq7K3zRL3/P5RF3CLDXgzwYexeyFSPsGRR24wDzWc4kPDt57PybJe 7+G8/Jty/jyysvXv5N5jjYXx2xw5seJMd5LsM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Dh0EwzPz3kqagP+w6qwTm8phrVMK+QxhIfwoboe697M=; b=5YBkhsofMEzYFSEx0Ism19QVcbxFi6MELRIGyCAyJ/oLjAdwbT1xErZiMWuMKN1slL XLhDmpdzSe5FVkZH/NIsdQQ9/57IZin2/5axgX1lOc2ZSRC0RmNbshDeJHjuwVx/JFrW axCrv8++24BChpBOZWxhAsz5k8Gh0MVtD56qi/m8mSWq6x7gKX5djN5C2O3gnUu0LOn5 DrpysxXAO8HBDTO0cAavJZ/JWoc3ikE0PgrJYeJnzNpdi9nLQxte5XxpW0v5wiNyPcl8 trzyfkmFCRxRy8nN580MvunEXfyBMmY6tft2qVEEhm5MjWGkaZaFsiLJPE2bRpEXtSyG ezEA== X-Gm-Message-State: AJIora8ZBSg2atvFoOILaCJVoqX6SD2htRyo2LFcR39wq+IHofmCdYae K+cobTJKmM98r8Axaeup3slsQLk9Xs6ulM+p X-Google-Smtp-Source: AGRyM1vrilosioNAwOBIAR5JSLFkcH5zxSw6LHzZWYWEasIh9l0OwRBj4yyRuxmxbW62nJo7bKl93Q== X-Received: by 2002:a05:6e02:168f:b0:2d3:c51d:7f69 with SMTP id f15-20020a056e02168f00b002d3c51d7f69mr4222643ila.64.1655243895181; Tue, 14 Jun 2022 14:58:15 -0700 (PDT) Received: from mail-il1-f173.google.com (mail-il1-f173.google.com. [209.85.166.173]) by smtp.gmail.com with ESMTPSA id r6-20020a924406000000b002cde6e352f8sm6020760ila.66.2022.06.14.14.58.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Jun 2022 14:58:14 -0700 (PDT) Received: by mail-il1-f173.google.com with SMTP id h18so7577164ilj.7 for ; Tue, 14 Jun 2022 14:58:13 -0700 (PDT) X-Received: by 2002:a05:6e02:1a6f:b0:2d3:ada4:2f11 with SMTP id w15-20020a056e021a6f00b002d3ada42f11mr4211456ilv.256.1655243893406; Tue, 14 Jun 2022 14:58:13 -0700 (PDT) MIME-Version: 1.0 References: <20220418171757.2282651-1-dianders@chromium.org> <20220418101725.v3.2.Icea616f57331fbaa3d48c529f300c9a8ebd37fb5@changeid> In-Reply-To: From: Doug Anderson Date: Tue, 14 Jun 2022 14:57:52 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 2/4] drm/panel-edp: Take advantage of wait_hpd_asserted() in struct drm_dp_aux To: Dmitry Baryshkov Content-Type: text/plain; charset="UTF-8" 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: Sankeerth Billakanti , Philip Chen , David Airlie , LKML , Abhinav Kumar , Robert Foss , Stephen Boyd , Thierry Reding , dri-devel , Hsin-Yi Wang , Sam Ravnborg Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi, On Thu, Jun 2, 2022 at 8:12 AM Dmitry Baryshkov wrote: > > On 18/04/2022 20:17, Douglas Anderson wrote: > > 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/panel-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; > > } > > > > +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 = p->base.dev; > > @@ -441,17 +446,21 @@ static int panel_edp_prepare_once(struct panel_edp *p) > > if (delay) > > msleep(delay); > > > > - if (p->hpd_gpio) { > > + if (panel_edp_can_read_hpd(p)) { > > if (p->desc->delay.hpd_absent) > > hpd_wait_us = p->desc->delay.hpd_absent * 1000UL; > > else > > hpd_wait_us = 2000000; > > > > - err = readx_poll_timeout(gpiod_get_value_cansleep, p->hpd_gpio, > > - hpd_asserted, hpd_asserted, > > - 1000, hpd_wait_us); > > - if (hpd_asserted < 0) > > - err = hpd_asserted; > > + if (p->hpd_gpio) { > > + err = readx_poll_timeout(gpiod_get_value_cansleep, > > + p->hpd_gpio, hpd_asserted, > > + hpd_asserted, 1000, hpd_wait_us); > > + if (hpd_asserted < 0) > > + err = hpd_asserted; > > + } else { > > + err = p->aux->wait_hpd_asserted(p->aux, hpd_wait_us); > > + } > > I'm close to thinking that this construct deserves a separate helper. Just to close the loop: I didn't try to create a helper for v5. I'm not completely convinced that this will be common. I would tend to expect that having HPD handled by a GPIO is somewhat rare. It's also fairly rare to have a panel that's not handled by the generic panel-edp. We ended up with the GPIO on trogdor because of the weird debouncing on sn85dsi86 and we ended up with one case of not using edp-panel on trogdor because of the weird power sequencing of the Samsung OLED panel that's on homestar. I'd also note that the generic eDP panel has a special case for "timeout" which we don't have on the Samsung panel to handle at least one panel I found that sometimes simply didn't come up but then _would_ come up on a retry... That doesn't mean we couldn't abstract it out later, of course. ;-) -Doug -Doug