From nobody Thu May 14 06:30:20 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 E41F4C433EF for ; Sat, 9 Apr 2022 02:37:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240642AbiDICjT (ORCPT ); Fri, 8 Apr 2022 22:39:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47764 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230244AbiDICjN (ORCPT ); Fri, 8 Apr 2022 22:39:13 -0400 Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 572F8BC1E for ; Fri, 8 Apr 2022 19:37:07 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id b2-20020a17090a010200b001cb0c78db57so8181296pjb.2 for ; Fri, 08 Apr 2022 19:37:07 -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=I1/DzlPFjUFk0MjYzMHo2z03FD2uR6K2mx8XfQf0a9U=; b=XZtT8yrKepRFfhERhZAp5oo71XA263KXjL3Qjv4XAAbSeNPB3UhOKJeeKBXJF4YOU4 1NFNl4bRllbgKNxIicQhhlurTGU2TU0TCRwrC8X6a08sifilyZXq2XdCQCJ9yfMxLYNn ISCVmEx57U/sDoC5QIJ2q6HqSZrdUq1JRkehM= 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=I1/DzlPFjUFk0MjYzMHo2z03FD2uR6K2mx8XfQf0a9U=; b=OVS29d5ioDS7+5KnvMOki5kdZnA8Z/rgL+U2juxJ/9tcuElORPE2HShjhlVRMO41Nn sAJun/nLHzoQanUR/fePT1HvRpYbbelHEZGnQBwExGYXKiO9W6CKqnK22zaba9733Jtx KnaHi/jCFMvCXyr9rDHLhsokDDU1kiAICVUcvaj7Cv2HQ1yuutVn7veeogrAp2U7Mnhf oH8KIdQDaAboBeCnFwvoy672oHdv3Pbirfhg3ocg9pscXlamoS8G3zFHTGW19TjvnCMo wQ7ikuQIaBiDKyDgNozJ/r9AgnIV5+DVN/rF+E4Ue4sEmJn4GhnGj1JXnnN3RgzNktp7 BzJQ== X-Gm-Message-State: AOAM531QjqSabroZADXAzgA+nTL/PqL05XjJyjgG6Bj/5F8ZvOQAufUr N556zHkUt4ehKcKzrPZBcpcUTPsjsyjyDTWEDYjOOQ== X-Google-Smtp-Source: ABdhPJwZdt51lsk3c3IHjJBxHYM5wDmVdwq7Z2csXBU3FBLf+eGZyutknjA9bakiNcf6U0m+VMVpcg== X-Received: by 2002:a17:902:7e0d:b0:156:47a4:a7c4 with SMTP id b13-20020a1709027e0d00b0015647a4a7c4mr22687102plm.141.1649471826788; Fri, 08 Apr 2022 19:37:06 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:17db:64e:48d4:a4e]) by smtp.gmail.com with ESMTPSA id 188-20020a6215c5000000b0050597294893sm759999pfv.124.2022.04.08.19.37.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Apr 2022 19:37:06 -0700 (PDT) From: Douglas Anderson To: dri-devel@lists.freedesktop.org Cc: Robert Foss , Hsin-Yi Wang , Dmitry Baryshkov , Abhinav Kumar , Sankeerth Billakanti , Philip Chen , Stephen Boyd , Douglas Anderson , Daniel Vetter , David Airlie , Linus Walleij , Lyude Paul , Thomas Zimmermann , linux-kernel@vger.kernel.org Subject: [RFC PATCH 1/6] drm/dp: Helpers to make it easier for drivers to use DP AUX bus properly Date: Fri, 8 Apr 2022 19:36:23 -0700 Message-Id: <20220408193536.RFC.1.I4182ae27e00792842cb86f1433990a0ef9c0a073@changeid> X-Mailer: git-send-email 2.35.1.1178.g4f1659d476-goog In-Reply-To: <20220409023628.2104952-1-dianders@chromium.org> References: <20220409023628.2104952-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" As talked about in the kerneldoc for "struct dp_aux_ep_client" in this patch and also in the past in commit a1e3667a9835 ("drm/bridge: ti-sn65dsi86: Promote the AUX channel to its own sub-dev"), to use the DP AUX bus properly we really need two "struct device"s. One "struct device" is in charge of providing the DP AUX bus and the other is where we'll try to get a reference to the newly probed endpoint devices. In ti-sn65dsi86 this wasn't too difficult to accomplish. That driver is already broken up into several "struct devices" anyway because it also provides a PWM and some GPIOs. Adding one more wasn't that difficult / ugly. When I tried to do the same solution in parade-ps8640, it felt like I was copying too much boilerplate code. I made the realization that I didn't _really_ need a separate "driver" for each person that wanted to do the same thing. By putting all the "driver" related code in a common place then we could save a bit of hassle. This change effectively adds a new "ep_client" driver that can be used by anyone. The devices instantiated by this driver will just call through to the probe/remove/shutdown calls provided. At the moment, the "ep_client" driver is backed by the Linux auxiliary bus (unfortunate naming--this has nothing to do with DP AUX). I didn't want to expose this to clients, though, so as far as clients are concerned they get a vanilla "struct device". Signed-off-by: Douglas Anderson --- drivers/gpu/drm/dp/drm_dp_aux_bus.c | 165 +++++++++++++++++++++++++++- include/drm/dp/drm_dp_aux_bus.h | 58 ++++++++++ 2 files changed, 222 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/dp/drm_dp_aux_bus.c b/drivers/gpu/drm/dp/drm_d= p_aux_bus.c index 415afce3cf96..5386ceacf133 100644 --- a/drivers/gpu/drm/dp/drm_dp_aux_bus.c +++ b/drivers/gpu/drm/dp/drm_dp_aux_bus.c @@ -12,6 +12,7 @@ * to perform transactions on that bus. */ =20 +#include #include #include #include @@ -299,6 +300,163 @@ void dp_aux_dp_driver_unregister(struct dp_aux_ep_dri= ver *drv) } EXPORT_SYMBOL_GPL(dp_aux_dp_driver_unregister); =20 +/* -----------------------------------------------------------------------= ------ + * DP AUX EP Client + */ + +struct dp_aux_ep_client_data { + struct dp_aux_ep_client *client; + struct auxiliary_device adev; +}; + +static int dp_aux_ep_client_probe(struct auxiliary_device *adev, + const struct auxiliary_device_id *id) +{ + struct dp_aux_ep_client_data *data =3D + container_of(adev, struct dp_aux_ep_client_data, adev); + + if (!data->client->probe) + return 0; + + return data->client->probe(&adev->dev, data->client); +} + +static void dp_aux_ep_client_remove(struct auxiliary_device *adev) +{ + struct dp_aux_ep_client_data *data =3D + container_of(adev, struct dp_aux_ep_client_data, adev); + + if (data->client->remove) + data->client->remove(&adev->dev, data->client); +} + +static void dp_aux_ep_client_shutdown(struct auxiliary_device *adev) +{ + struct dp_aux_ep_client_data *data =3D + container_of(adev, struct dp_aux_ep_client_data, adev); + + if (data->client->shutdown) + data->client->shutdown(&adev->dev, data->client); +} + +static void dp_aux_ep_client_dev_release(struct device *dev) +{ + struct auxiliary_device *adev =3D to_auxiliary_dev(dev); + struct dp_aux_ep_client_data *data =3D + container_of(adev, struct dp_aux_ep_client_data, adev); + + kfree(data); +} + +/** + * dp_aux_register_ep_client() - Register an DP AUX EP client + * @client: The structure describing the client. It's the client's + * responsibility to keep this memory around until + * dp_aux_unregister_ep_client() is called, either explicitly or + * implicitly via devm. + * + * See the description of "struct dp_aux_ep_client" for a full explanation + * of when you should use this and why. + * + * Return: 0 if no error or negative error code. + */ +int dp_aux_register_ep_client(struct dp_aux_ep_client *client) +{ + struct dp_aux_ep_client_data *data; + int ret; + + data =3D kzalloc(sizeof(*data), GFP_KERNEL); + if (!data) + return -ENOMEM; + + data->client =3D client; + data->adev.name =3D "ep_client"; + data->adev.dev.parent =3D client->aux->dev; + data->adev.dev.release =3D dp_aux_ep_client_dev_release; + device_set_of_node_from_dev(&data->adev.dev, client->aux->dev); + + ret =3D auxiliary_device_init(&data->adev); + if (ret) { + /* + * NOTE: if init doesn't fail then it takes ownership + * of memory and this kfree() is magically part of + * auxiliary_device_uninit(). + */ + kfree(data); + return ret; + } + + ret =3D auxiliary_device_add(&data->adev); + if (ret) + goto err_did_init; + + client->_opaque =3D data; + + return 0; + +err_did_init: + auxiliary_device_uninit(&data->adev); + return ret; +} + +/** + * dp_aux_unregister_ep_client() - Inverse of dp_aux_register_ep_client() + * @client: The structure describing the client. + * + * If dp_aux_register_ep_client() returns no error then you should call th= is + * to free resources. + */ +void dp_aux_unregister_ep_client(struct dp_aux_ep_client *client) +{ + struct dp_aux_ep_client_data *data =3D client->_opaque; + + auxiliary_device_delete(&data->adev); + auxiliary_device_uninit(&data->adev); +} + +static void dp_aux_unregister_ep_client_void(void *data) +{ + dp_aux_unregister_ep_client(data); +} + +/** + * devm_dp_aux_register_ep_client() - devm wrapper for dp_aux_register_ep_= client() + * @client: The structure describing the client. + * + * Handles freeing w/ devm on the device "client->aux->dev". + * + * Return: 0 if no error or negative error code. + */ +int devm_dp_aux_register_ep_client(struct dp_aux_ep_client *client) +{ + int ret; + + ret =3D dp_aux_register_ep_client(client); + if (ret) + return ret; + + return devm_add_action_or_reset(client->aux->dev, + dp_aux_unregister_ep_client_void, + client); +} + +static const struct auxiliary_device_id dp_aux_ep_client_id_table[] =3D { + { .name =3D "drm_dp_aux_bus.ep_client", }, + {}, +}; + +static struct auxiliary_driver dp_aux_ep_client_driver =3D { + .name =3D "ep_client", + .probe =3D dp_aux_ep_client_probe, + .remove =3D dp_aux_ep_client_remove, + .shutdown =3D dp_aux_ep_client_shutdown, + .id_table =3D dp_aux_ep_client_id_table, +}; + +/* -----------------------------------------------------------------------= ------ + * Module init + */ + static int __init dp_aux_bus_init(void) { int ret; @@ -307,11 +465,16 @@ static int __init dp_aux_bus_init(void) if (ret) return ret; =20 - return 0; + ret =3D auxiliary_driver_register(&dp_aux_ep_client_driver); + if (ret) + bus_unregister(&dp_aux_bus_type); + + return ret; } =20 static void __exit dp_aux_bus_exit(void) { + auxiliary_driver_unregister(&dp_aux_ep_client_driver); bus_unregister(&dp_aux_bus_type); } =20 diff --git a/include/drm/dp/drm_dp_aux_bus.h b/include/drm/dp/drm_dp_aux_bu= s.h index 4f19b20b1dd6..ecf68b6873bd 100644 --- a/include/drm/dp/drm_dp_aux_bus.h +++ b/include/drm/dp/drm_dp_aux_bus.h @@ -54,4 +54,62 @@ int __dp_aux_dp_driver_register(struct dp_aux_ep_driver = *aux_ep_drv, struct module *owner); void dp_aux_dp_driver_unregister(struct dp_aux_ep_driver *aux_ep_drv); =20 +/** + * struct dp_aux_ep_device - Helper for clients of DP AUX EP devices + * + * The DP AUX bus can be a bit tricky to use properly. Usually, the way + * things work is that: + * - The DP controller driver provides the DP AUX bus and would like to pr= obe + * the endpoints on the DP AUX bus (AKA the panel) as part of its probe + * routine. + * - The DP controller driver would also like to acquire a reference to the + * DP AUX endpoints (AKA the panel) as part of its probe. + * + * The problem is that the DP AUX endpoints aren't guaranteed to complete = their + * probe right away. They could be probing asynchronously or they simply m= ight + * fail to acquire some resource and return -EPROBE_DEFER. + * + * The best way to solve this is to break the DP controller's probe into + * two parts. The first part will create the DP AUX bus. The second part w= ill + * acquire the reference to the DP AUX endpoint. The first part can comple= te + * finish with no problems and be "done" even if the second part ends up + * deferring while waiting for the DP AUX endpoint. + * + * The dp_aux_ep_client structure and associated functions help with manag= ing + * this common case. They will create/add a second "struct device" for you. + * In the probe for this second "struct device" (known as the "clientdev" = here) + * you can acquire references to the AUX DP endpoints and can freely return + * -EPROBE_DEFER if they're not ready yet. + * + * A few notes: + * - The parent of the clientdev is guaranteed to be aux->dev + * - The of_node of the clientdev is guaranteed to be the same as the of_n= ode + * of aux->dev, copied with device_set_of_node_from_dev(). + * - If you're doing "devm" type things in the clientdev's probe you should + * use the clientdev. This makes lifetimes be managed properly. + * + * NOTE: there's no requirement to use these helpers if you have solved the + * problem described above in some other way. + */ +struct dp_aux_ep_client { + /** @probe: The second half of the probe */ + int (*probe)(struct device *clientdev, struct dp_aux_ep_client *client); + + /** @remove: Remove function corresponding to the probe */ + void (*remove)(struct device *clientdev, struct dp_aux_ep_client *client); + + /** @shutdown: Shutdown function corresponding to the probe */ + void (*shutdown)(struct device *clientdev, struct dp_aux_ep_client *clien= t); + + /** @aux: The AUX bus */ + struct drm_dp_aux *aux; + + /** @_opaque: Used by the implementation */ + void *_opaque; +}; + +int dp_aux_register_ep_client(struct dp_aux_ep_client *client); +void dp_aux_unregister_ep_client(struct dp_aux_ep_client *client); +int devm_dp_aux_register_ep_client(struct dp_aux_ep_client *client); + #endif /* _DP_AUX_BUS_H_ */ --=20 2.35.1.1178.g4f1659d476-goog From nobody Thu May 14 06:30:20 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 C3A83C433EF for ; Sat, 9 Apr 2022 02:37:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240653AbiDICjX (ORCPT ); Fri, 8 Apr 2022 22:39:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47952 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240631AbiDICjP (ORCPT ); Fri, 8 Apr 2022 22:39:15 -0400 Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E11D72B9 for ; Fri, 8 Apr 2022 19:37:08 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id h19so10009121pfv.1 for ; Fri, 08 Apr 2022 19:37:08 -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=P+4B9VZqL5jIvczk1CaOVWkNfySt1cT6osyGLgTnwSY=; b=k7QxZ7tjs5d7WytyQLNKCOlmID1fy4+B+8Baj1jZuvNY8qkePxZvPREuL644WYZR+U wDo3DKUgXhvJmvzbHG92cLUN0jrjwCLMQ2oPrxjjT2YSCclVvUziw8quzLYHRbwg6C8B 6grIU4ndH8qWUq/EmX7U3IC4Tgu2WR1x0IkfM= 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=P+4B9VZqL5jIvczk1CaOVWkNfySt1cT6osyGLgTnwSY=; b=Qps8BGiKAyCc+/ZLNl4ZmTjd16Z+ud26MrLRFgXQvUdjDdjvacM1lyAW89iX/AcNl3 vQdLPu0gsH47/Zs8soXalnefFbRF/zv2xsotej3Ndz9yQ1bzFoowXmwwD50nm1Z7nG+t CBlu/EmtztiF61Olwc8nTSRENPgp5JpY1XBSn3eF2ZCgnEHoQz+oUUlaL92JReuJYkEk liKc+/UDXK2hprdGV6vo00xJvzN+FmLQDAxv+fNRuQuOdZ18lRhIcYoKG1nWviBOW6s7 kdqS4Kr5I/s6GWRlHMTwEnytrVXnKaQSusL66v8UirOEov6fUAtF77DRTEt4EKt3HXnp glfw== X-Gm-Message-State: AOAM5311IKFamRTa9VxXExTHLJBiJL+Edcjytda+cj7+pBhmmoy6KLgQ 19W8uNwXqYeXAnrNbXwCePJ6VQ== X-Google-Smtp-Source: ABdhPJx2Qn55vuhb0i/A319oTIt5Xlsg2IJgX6xY7+/M+P1CNWVeQFfa1aJkz+iCeezxOeyYVl5MUQ== X-Received: by 2002:a63:214b:0:b0:39c:c451:be39 with SMTP id s11-20020a63214b000000b0039cc451be39mr10102090pgm.391.1649471828391; Fri, 08 Apr 2022 19:37:08 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:17db:64e:48d4:a4e]) by smtp.gmail.com with ESMTPSA id 188-20020a6215c5000000b0050597294893sm759999pfv.124.2022.04.08.19.37.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Apr 2022 19:37:08 -0700 (PDT) From: Douglas Anderson To: dri-devel@lists.freedesktop.org Cc: Robert Foss , Hsin-Yi Wang , Dmitry Baryshkov , Abhinav Kumar , Sankeerth Billakanti , Philip Chen , Stephen Boyd , Douglas Anderson , Andrzej Hajda , Daniel Vetter , David Airlie , Jernej Skrabec , Jonas Karlman , Laurent Pinchart , Neil Armstrong , linux-kernel@vger.kernel.org Subject: [RFC PATCH 2/6] drm/bridge: parade-ps8640: Break probe in two to handle DP AUX better Date: Fri, 8 Apr 2022 19:36:24 -0700 Message-Id: <20220408193536.RFC.2.Ia6324ebc848cd40b4dbd3ad3289a7ffb5c197779@changeid> X-Mailer: git-send-email 2.35.1.1178.g4f1659d476-goog In-Reply-To: <20220409023628.2104952-1-dianders@chromium.org> References: <20220409023628.2104952-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" While it works, for the most part, to assume that the panel has finished probing when devm_of_dp_aux_populate_ep_devices() returns, it's a bit fragile. This is talked about at length in commit a1e3667a9835 ("drm/bridge: ti-sn65dsi86: Promote the AUX channel to its own sub-dev"). When reviewing the ps8640 code, I managed to convince myself that it was OK not to worry about it there and that maybe it wasn't really _that_ fragile. However, it turns out that it really is. Simply hardcoding panel_edp_probe() to return -EPROBE_DEFER was enough to put the boot process into an infinite loop. I believe this manages to trip the same issues that we used to trip with the main MSM code where something about our actions trigger Linux to re-probe previously deferred devices right away and each time we try again we re-trigger Linux to re-probe. It's really not that crazy to just break the probe up. Let's use the new helpers introduced in the patch ("drm/dp: Helpers to make it easier for drivers to use DP AUX bus properly") to break the driver into two. With this change, the device still boots (though obviously the panel doesn't come up) if I force panel-edp to always return -EPROBE_DEFER. Signed-off-by: Douglas Anderson --- drivers/gpu/drm/bridge/parade-ps8640.c | 66 +++++++++++++++----------- 1 file changed, 39 insertions(+), 27 deletions(-) diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridg= e/parade-ps8640.c index 9766cbbd62ad..96e883985608 100644 --- a/drivers/gpu/drm/bridge/parade-ps8640.c +++ b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -93,6 +93,7 @@ enum ps8640_vdo_control { }; =20 struct ps8640 { + struct dp_aux_ep_client ep_client; struct drm_bridge bridge; struct drm_bridge *panel_bridge; struct drm_dp_aux aux; @@ -584,10 +585,36 @@ static int ps8640_bridge_host_attach(struct device *d= ev, struct ps8640 *ps_bridg return 0; } =20 +static int ps8640_bridge_probe(struct device *clientdev, struct dp_aux_ep_= client *client) +{ + struct ps8640 *ps_bridge =3D container_of(client, struct ps8640, ep_clien= t); + struct device_node *np =3D clientdev->of_node; + int ret; + + /* port@1 is ps8640 output port */ + ps_bridge->panel_bridge =3D devm_drm_of_get_bridge(clientdev, np, 1, 0); + if (IS_ERR(ps_bridge->panel_bridge)) + return PTR_ERR(ps_bridge->panel_bridge); + + drm_bridge_add(&ps_bridge->bridge); + + ret =3D ps8640_bridge_host_attach(clientdev, ps_bridge); + if (ret) + drm_bridge_remove(&ps_bridge->bridge); + + return ret; +} + +static void ps8640_bridge_remove(struct device *clientdev, struct dp_aux_e= p_client *client) +{ + struct ps8640 *ps_bridge =3D container_of(client, struct ps8640, ep_clien= t); + + drm_bridge_remove(&ps_bridge->bridge); +} + static int ps8640_probe(struct i2c_client *client) { struct device *dev =3D &client->dev; - struct device_node *np =3D dev->of_node; struct ps8640 *ps_bridge; int ret; u32 i; @@ -672,31 +699,17 @@ static int ps8640_probe(struct i2c_client *client) =20 devm_of_dp_aux_populate_ep_devices(&ps_bridge->aux); =20 - /* port@1 is ps8640 output port */ - ps_bridge->panel_bridge =3D devm_drm_of_get_bridge(dev, np, 1, 0); - if (IS_ERR(ps_bridge->panel_bridge)) - return PTR_ERR(ps_bridge->panel_bridge); - - drm_bridge_add(&ps_bridge->bridge); - - ret =3D ps8640_bridge_host_attach(dev, ps_bridge); - if (ret) - goto err_bridge_remove; - - return 0; - -err_bridge_remove: - drm_bridge_remove(&ps_bridge->bridge); - return ret; -} - -static int ps8640_remove(struct i2c_client *client) -{ - struct ps8640 *ps_bridge =3D i2c_get_clientdata(client); - - drm_bridge_remove(&ps_bridge->bridge); - - return 0; + /* + * Create a sub-device and kick off a probe to it. This effectively + * breaks our probe in two and lets the first half complete even if + * the second half might return -EPROBE_DEFER. If we didn't do this + * then if a panel isn't immediately ready we'd delete it right away + * and never give it a chance to finish. + */ + ps_bridge->ep_client.probe =3D ps8640_bridge_probe; + ps_bridge->ep_client.remove =3D ps8640_bridge_remove; + ps_bridge->ep_client.aux =3D &ps_bridge->aux; + return devm_dp_aux_register_ep_client(&ps_bridge->ep_client); } =20 static const struct of_device_id ps8640_match[] =3D { @@ -707,7 +720,6 @@ MODULE_DEVICE_TABLE(of, ps8640_match); =20 static struct i2c_driver ps8640_driver =3D { .probe_new =3D ps8640_probe, - .remove =3D ps8640_remove, .driver =3D { .name =3D "ps8640", .of_match_table =3D ps8640_match, --=20 2.35.1.1178.g4f1659d476-goog From nobody Thu May 14 06:30:20 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 D54A5C433F5 for ; Sat, 9 Apr 2022 02:37:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240659AbiDICj1 (ORCPT ); Fri, 8 Apr 2022 22:39:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240633AbiDICjP (ORCPT ); Fri, 8 Apr 2022 22:39:15 -0400 Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A89E7C31F9 for ; Fri, 8 Apr 2022 19:37:10 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id s14-20020a17090a880e00b001caaf6d3dd1so13461447pjn.3 for ; Fri, 08 Apr 2022 19:37:10 -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=fymhEmFv/O8Tuh2GeqHqqsiXL5aZG/ohxN9zZ7IUhcE=; b=i+Scf6wXGKJdppgcWPtk6/VxfqcDhX6IxbHqkMo9S9/gnqJfZJZ/jFMAnhpL7M2Qx0 eVfB4+aLpgVl0JDgirYwZ4r2JL2A6MM6//5/GgcKMkp63LMC3g2r6AxLsfiILIhWsl4P HA7k1MrDAfJlFt/ATY9UBfp4U4kxIIca89fAI= 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=fymhEmFv/O8Tuh2GeqHqqsiXL5aZG/ohxN9zZ7IUhcE=; b=QxbNzOJvUlDPY+CAtjFHsifChantDT6MhzuQl6G9YLrTveuNifmpqOriwzkINAPoGg ifIVhyVbSjQN2IvYdSKGdY5WnWxOycWKXrNr1HBSeVF57qyeN2ExLHwuCCGZzNNQ9MyK RqpfkIww/a9ludSDNY//pK1b5/IOXAmYf9EgsgymXT2hJBamGC2uYzOv4H7RKxnbqrUX +OqO1SCoWOfvvcAt0/aYzq5bTK7ASNlvinY68QT0RvKkgqO11Jrjr0mUMrUKUeELTa4d 4OSEgdWnCBox30QW9o9Il1R+F6W/USTNVx7puuDveN3IhAXRaTN2Kc9dlaoTmG6prxT5 btgA== X-Gm-Message-State: AOAM532mtDsUdVHuXy7aJuDa1VAlp5X/B+KDC+BTLBC/y3WUnJfVH7eB tp30MgLzd0YQFw12NwiTtxKSLg== X-Google-Smtp-Source: ABdhPJy7nNxWCXeW3m5jAZNd2k2Rh17DkzCXweSCpmeLDWahQW5YDzra5ADMhXthsjGqsE/I0/FyMQ== X-Received: by 2002:a17:902:f652:b0:156:701b:9a2a with SMTP id m18-20020a170902f65200b00156701b9a2amr22122893plg.14.1649471830116; Fri, 08 Apr 2022 19:37:10 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:17db:64e:48d4:a4e]) by smtp.gmail.com with ESMTPSA id 188-20020a6215c5000000b0050597294893sm759999pfv.124.2022.04.08.19.37.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Apr 2022 19:37:09 -0700 (PDT) From: Douglas Anderson To: dri-devel@lists.freedesktop.org Cc: Robert Foss , Hsin-Yi Wang , Dmitry Baryshkov , Abhinav Kumar , Sankeerth Billakanti , Philip Chen , Stephen Boyd , Douglas Anderson , Daniel Vetter , David Airlie , Jani Nikula , Kees Cook , Lyude Paul , Maxime Ripard , linux-kernel@vger.kernel.org Subject: [RFC PATCH 3/6] drm/dp: Add is_hpd_asserted() callback to struct drm_dp_aux Date: Fri, 8 Apr 2022 19:36:25 -0700 Message-Id: <20220408193536.RFC.3.Icf57bb12233a47727013c6ab69eebf803e22ebc1@changeid> X-Mailer: git-send-email 2.35.1.1178.g4f1659d476-goog In-Reply-To: <20220409023628.2104952-1-dianders@chromium.org> References: <20220409023628.2104952-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 --- include/drm/dp/drm_dp_helper.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/include/drm/dp/drm_dp_helper.h b/include/drm/dp/drm_dp_helper.h index dad1442c91df..a12951319573 100644 --- a/include/drm/dp/drm_dp_helper.h +++ b/include/drm/dp/drm_dp_helper.h @@ -2021,6 +2021,20 @@ struct drm_dp_aux { ssize_t (*transfer)(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg); =20 + /** + * @is_hpd_asserted: returns true if HPD is asserted + * + * This is mainly useful for eDP panels drivers to query whether + * an eDP panel has finished powering on. This is an optional function. + * + * 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. + */ + bool (*is_hpd_asserted)(struct drm_dp_aux *aux); + /** * @i2c_nack_count: Counts I2C NACKs, used for DP validation. */ --=20 2.35.1.1178.g4f1659d476-goog From nobody Thu May 14 06:30:20 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 CE1A8C433F5 for ; Sat, 9 Apr 2022 02:37:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240665AbiDICja (ORCPT ); Fri, 8 Apr 2022 22:39:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240635AbiDICjR (ORCPT ); Fri, 8 Apr 2022 22:39:17 -0400 Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0D691C4E15 for ; Fri, 8 Apr 2022 19:37:12 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id p8so9977705pfh.8 for ; Fri, 08 Apr 2022 19:37:12 -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=ZDP/lJqtEdsKUlwpXtXIqsxtNFEIRvU/nqKyMYfCeeY=; b=D9xgfrkeaFJUttYqewJ3vg74R8RrnGjCc9t/rG3o/W8tbtcZ7piUxYK6PHbP091tO+ vaCyQaSP6r/rmRV3BTIGMKkXQMz8pEbSndzZ7jnkvXd0GyoSNBRi2NgJFijT6uqrz/cf axYPLd1dIhWccm0BHMMRxIB5MmvJgq+RFE12k= 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=ZDP/lJqtEdsKUlwpXtXIqsxtNFEIRvU/nqKyMYfCeeY=; b=cRHijBi9m6xebqSSRjduhi/rdIatHAesS2xMYrhH5mVbSv68IrwHmFHH77PYDX3J7/ 1/60fEiTkwzTS5RUtJUoNHaDxa4ySXm9cQUum2OLKOmvfEbcaWEOoolSlqli7clGX0Xs ssc+srSD8QLhOvg87tRW+/4hzKje3dmIitPx3K1EsucLdl4mHn5Gnh2rL2DsQvknnY3b Ju7wcd9eYsE1ULl6MsSmrgY3zkcPI0NA7QDs4y1hcQVxp+aEoT2skNwezHS5/PZ52P0T fImiGpkXlURjZrGUQarIbc4rF9fsCvjoHiEHdXokg7RAO5OlhIvfoCMJRBq7FwU4Rjkd he8w== X-Gm-Message-State: AOAM532Q1rZLaBh7Ml7itI+S/bzM8A/FzH+sWmPjcRkBSeRytLi6cAap k2aA6+FAaKFPUQcM6hGs+XIdVg== X-Google-Smtp-Source: ABdhPJwxPfmW0ePcA69JOxNFOhRcSLAhhpuGo+Rx7NZf6f0QcfjSNo1IkMxnNcI43azKHsIKyYsFnw== X-Received: by 2002:a63:dc4e:0:b0:39c:c5b2:94d6 with SMTP id f14-20020a63dc4e000000b0039cc5b294d6mr9820589pgj.365.1649471831563; Fri, 08 Apr 2022 19:37:11 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:17db:64e:48d4:a4e]) by smtp.gmail.com with ESMTPSA id 188-20020a6215c5000000b0050597294893sm759999pfv.124.2022.04.08.19.37.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Apr 2022 19:37:11 -0700 (PDT) From: Douglas Anderson To: dri-devel@lists.freedesktop.org Cc: Robert Foss , Hsin-Yi Wang , Dmitry Baryshkov , Abhinav Kumar , Sankeerth Billakanti , Philip Chen , Stephen Boyd , Douglas Anderson , Daniel Vetter , David Airlie , Sam Ravnborg , Thierry Reding , linux-kernel@vger.kernel.org Subject: [RFC PATCH 4/6] drm/panel-edp: Take advantage of is_hpd_asserted() in struct drm_dp_aux Date: Fri, 8 Apr 2022 19:36:26 -0700 Message-Id: <20220408193536.RFC.4.Icea616f57331fbaa3d48c529f300c9a8ebd37fb5@changeid> X-Mailer: git-send-email 2.35.1.1178.g4f1659d476-goog In-Reply-To: <20220409023628.2104952-1-dianders@chromium.org> References: <20220409023628.2104952-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 --- drivers/gpu/drm/panel/panel-edp.c | 37 ++++++++++++++++++++++++++----- 1 file changed, 31 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/pane= l-edp.c index 1732b4f56e38..4a143eb9544b 100644 --- a/drivers/gpu/drm/panel/panel-edp.c +++ b/drivers/gpu/drm/panel/panel-edp.c @@ -417,6 +417,19 @@ 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->is_hpd_asserted)); +} + +static bool panel_edp_read_hpd(struct panel_edp *p) +{ + if (p->hpd_gpio) + return gpiod_get_value_cansleep(p->hpd_gpio); + + return p->aux->is_hpd_asserted(p->aux); +} + static int panel_edp_prepare_once(struct panel_edp *p) { struct device *dev =3D p->base.dev; @@ -441,13 +454,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, + /* + * Extra max delay, mostly to account for ps8640. ps8640 + * is crazy and the bridge chip driver itself has over 200 ms + * of delay if it needs to do the pm_runtime resume of the + * bridge chip to read the HPD. + */ + hpd_wait_us +=3D 3000000; + + err =3D readx_poll_timeout(panel_edp_read_hpd, p, hpd_asserted, hpd_asserted, 1000, hpd_wait_us); if (hpd_asserted < 0) @@ -532,18 +553,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.35.1.1178.g4f1659d476-goog From nobody Thu May 14 06:30:20 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 C7C3FC433F5 for ; Sat, 9 Apr 2022 02:37:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240669AbiDICje (ORCPT ); Fri, 8 Apr 2022 22:39:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48218 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240643AbiDICjT (ORCPT ); Fri, 8 Apr 2022 22:39:19 -0400 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B5DF7C4E30 for ; Fri, 8 Apr 2022 19:37:13 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id s14-20020a17090a880e00b001caaf6d3dd1so13461512pjn.3 for ; Fri, 08 Apr 2022 19:37:13 -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=X0vkhOKP2WO4l+2v+2Aab0a42a4DeGq9/d4Qga0dGC0=; b=hThmm8Tk9cX40rfcqSsr2lGFlhGgxb2P8Eetaye5fzRTF/IFvfQeF1jvqlMQZgfHUQ SrTeTmXH5D3Gj21g9TkpAnQhB+IQn+V46EgcKgNjb4t/g01DIAFFOW7mb0jVTMq2IfXG ykMvJusi6OBpqfOLef7rb1cFe2KYgZ0Zl7Frw= 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=X0vkhOKP2WO4l+2v+2Aab0a42a4DeGq9/d4Qga0dGC0=; b=8DJKray6KXjuHjvRg/RQRcoR70QlsPLnsHYbMTeMVcV+3utAaKMN+/UrY3ngPHOW7M tuQd5QUplVNYQybErI0fk5r8LdWV8VthwPznTgCXQTjNtIpSJ1e0bOXS4R0R9SGyeRbH r8EWwIgMOLMepSeuM9uHp7tnmiU3j8EdULUFWaXc3eg2O8EoSuN8l0BtM0kkmA6kZ/FS UeOvWXSxozYYsinxeZbD+GJqhZBva0Rk4d6TA8mJ3TC5fwLm/OgyvQ1pIEZ/COHBJGi5 CKEKoiFfdz1Az28JoS4XNIhmnax9kuEVH0lFLX5MnApoQrTZFWpYR1PYIoxXf8EUjlby 7Ktw== X-Gm-Message-State: AOAM531HlFFI7jbNAhL1ElIZXAtQdYuxRT218aL/FBcWKLZVZM4j6hgR E6JLGlMl8SttYNGE8y66VHXISw== X-Google-Smtp-Source: ABdhPJxKvoKVhufhkWMurahdK3NmXOgJqw5lH1XIAJAyg/5vhbrKM2A8tweygpDFe/vJs9KLnxJWtw== X-Received: by 2002:a17:902:e74a:b0:153:f956:1cf5 with SMTP id p10-20020a170902e74a00b00153f9561cf5mr21563664plf.138.1649471832923; Fri, 08 Apr 2022 19:37:12 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:17db:64e:48d4:a4e]) by smtp.gmail.com with ESMTPSA id 188-20020a6215c5000000b0050597294893sm759999pfv.124.2022.04.08.19.37.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Apr 2022 19:37:12 -0700 (PDT) From: Douglas Anderson To: dri-devel@lists.freedesktop.org Cc: Robert Foss , Hsin-Yi Wang , Dmitry Baryshkov , Abhinav Kumar , Sankeerth Billakanti , Philip Chen , Stephen Boyd , Douglas Anderson , Daniel Vetter , David Airlie , Sam Ravnborg , Thierry Reding , linux-kernel@vger.kernel.org Subject: [RFC PATCH 5/6] drm/panel: atna33xc20: Take advantage of is_hpd_asserted() in struct drm_dp_aux Date: Fri, 8 Apr 2022 19:36:27 -0700 Message-Id: <20220408193536.RFC.5.I9ee239f6b95b944c8fa030f300ad222a7af9899d@changeid> X-Mailer: git-send-email 2.35.1.1178.g4f1659d476-goog In-Reply-To: <20220409023628.2104952-1-dianders@chromium.org> References: <20220409023628.2104952-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 --- .../gpu/drm/panel/panel-samsung-atna33xc20.c | 35 +++++++++++++++---- 1 file changed, 29 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-samsung-atna33xc20.c b/drivers/gpu= /drm/panel/panel-samsung-atna33xc20.c index 20666b6217e7..f72bdd7ff7a1 100644 --- a/drivers/gpu/drm/panel/panel-samsung-atna33xc20.c +++ b/drivers/gpu/drm/panel/panel-samsung-atna33xc20.c @@ -30,6 +30,7 @@ struct atana33xc20_panel { =20 struct regulator *supply; struct gpio_desc *el_on3_gpio; + struct drm_dp_aux *aux; =20 struct edid *edid; =20 @@ -76,6 +77,19 @@ static int atana33xc20_suspend(struct device *dev) return 0; } =20 +static bool atana33xc20_can_read_hpd(struct atana33xc20_panel *p) +{ + return !p->no_hpd && (p->hpd_gpio || p->aux->is_hpd_asserted); +} + +static bool panel_edp_read_hpd(struct atana33xc20_panel *p) +{ + if (p->hpd_gpio) + return gpiod_get_value_cansleep(p->hpd_gpio); + + return p->aux->is_hpd_asserted(p->aux); +} + static int atana33xc20_resume(struct device *dev) { struct atana33xc20_panel *p =3D dev_get_drvdata(dev); @@ -92,17 +106,24 @@ static int atana33xc20_resume(struct device *dev) =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. + * eDP controller then it's possible that "no_hpd" will be false _and_ + * atana33xc20_can_read_hpd() will return false. It's up to the + * controller driver to wait for HPD after preparing the panel in that + * case. */ 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, + } else if (atana33xc20_can_read_hpd(p)) { + /* + * Even though max HPD is 200 ms, we give an extra long timeout + * of 500 ms here. Why? ps8640 is crazy and the bridge chip + * driver itself has over 200 ms of delay if it needs to + * do the pm_runtime resume of the bridge chip to read the HPD. + */ + ret =3D readx_poll_timeout(panel_edp_read_hpd, p, hpd_asserted, hpd_asserted, - 1000, 200000); + 1000, 500000); if (!hpd_asserted) dev_warn(dev, "Timeout waiting for HPD\n"); } @@ -263,6 +284,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.35.1.1178.g4f1659d476-goog From nobody Thu May 14 06:30:20 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 1C384C433EF for ; Sat, 9 Apr 2022 02:37:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240692AbiDICjo (ORCPT ); Fri, 8 Apr 2022 22:39:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48368 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230244AbiDICjU (ORCPT ); Fri, 8 Apr 2022 22:39:20 -0400 Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1EE05C4E0E for ; Fri, 8 Apr 2022 19:37:15 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id md4so1977849pjb.4 for ; Fri, 08 Apr 2022 19:37: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=GRUl59HS+3kIJaHkhNRsC+uDBDA3ykeO3cGjaLdlqT4=; b=CauMoP36hw/My6kTj0xHbH3I/vgeGoE5r6qOsDM1oBALiaD5VgEqwKzw3bc5b1e6xv xsBdzDpI5v56V2lc31/4fXcJ5iSKsi5n/sZDErwdJ+Dlgnkua6nKFC+riYU8jXpNfuI6 njExO59mFknKxVM1+EcREmTxf9rf5f6RtRVJM= 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=GRUl59HS+3kIJaHkhNRsC+uDBDA3ykeO3cGjaLdlqT4=; b=aE+/VBqdKXMtEcv2K9K278ES8m55uccLyNkMwEeuc4kYg6kIZNcVKsHHcQncwQm5IA wqCBgLMwgmS4UG8GWBPPQ3Y4PXCnqPfQcjYoCoynmRfxkO02VHXrLToiIq18L3iBl/ke //7LAkWqUWwdDNdfkSSexcMcEYkVV8ibjw1JOk9u36cRz8dEzMr7+BTkLf30dFK9RojJ /EnMSoNwH9+bzLdMTjOHt0xBeCgPXGqRoFSR/MKoL0ALlEIHFv9qAdv3jAxKtLfUsRVJ f9UCn/FU8Ehtkx4rS01WaUNHeV72X0UrOYdrvRv65IdbaS3L7NxTgGyFdUGHOgWkgibo B9mQ== X-Gm-Message-State: AOAM533u3RBnOt9eVxoTjY3taB1L7nButShKCeFBDozdqFGvWoblEAvs WZz8DkE57qENPsla/o6WUpZl+g== X-Google-Smtp-Source: ABdhPJxZ7Pqlo45QY22NAolHTEUTLzi46MpCGEQydMm3iAjUaV6osMVmGoBxIwb2Ikn3JQsXaigMug== X-Received: by 2002:a17:903:1206:b0:151:7d67:2924 with SMTP id l6-20020a170903120600b001517d672924mr21812991plh.45.1649471834502; Fri, 08 Apr 2022 19:37:14 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:17db:64e:48d4:a4e]) by smtp.gmail.com with ESMTPSA id 188-20020a6215c5000000b0050597294893sm759999pfv.124.2022.04.08.19.37.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Apr 2022 19:37:14 -0700 (PDT) From: Douglas Anderson To: dri-devel@lists.freedesktop.org Cc: Robert Foss , Hsin-Yi Wang , Dmitry Baryshkov , Abhinav Kumar , Sankeerth Billakanti , Philip Chen , Stephen Boyd , Douglas Anderson , Andrzej Hajda , Daniel Vetter , David Airlie , Jernej Skrabec , Jonas Karlman , Laurent Pinchart , Neil Armstrong , linux-kernel@vger.kernel.org Subject: [RFC PATCH 6/6] drm/bridge: parade-ps8640: Provide is_hpd_asserted() in struct drm_dp_aux Date: Fri, 8 Apr 2022 19:36:28 -0700 Message-Id: <20220408193536.RFC.6.Ie827321ce263be52fdb8c1276f6f8cc00d78029f@changeid> X-Mailer: git-send-email 2.35.1.1178.g4f1659d476-goog In-Reply-To: <20220409023628.2104952-1-dianders@chromium.org> References: <20220409023628.2104952-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 is_hpd_asserted() callback to struct drm_dp_aux"). With this change and all the two "DP AUX Endpoint" drivers changed to use is_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 "ensure" 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 --- drivers/gpu/drm/bridge/parade-ps8640.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridg= e/parade-ps8640.c index 96e883985608..13c3cb5d34f3 100644 --- a/drivers/gpu/drm/bridge/parade-ps8640.c +++ b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -190,6 +190,22 @@ static int ps8640_ensure_hpd(struct ps8640 *ps_bridge) return ret; } =20 +static bool ps8640_is_hpd_asserted(struct drm_dp_aux *aux) +{ + struct ps8640 *ps_bridge =3D aux_to_ps8640(aux); + struct regmap *map =3D ps_bridge->regmap[PAGE2_TOP_CNTL]; + struct device *dev =3D &ps_bridge->page[PAGE0_DP_CNTL]->dev; + unsigned int status =3D 0; + + pm_runtime_get_sync(dev); + regmap_read(map, PAGE2_GPIO_H, &status); + pm_runtime_mark_last_busy(dev); + pm_runtime_put_autosuspend(dev); + + /* GPIO9 signals HPD. See ps8640_ensure_hpd() */ + return status & PS_GPIO9; +} + static ssize_t ps8640_aux_transfer_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) { @@ -324,9 +340,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 @@ -679,6 +693,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.is_hpd_asserted =3D ps8640_is_hpd_asserted; drm_dp_aux_init(&ps_bridge->aux); =20 pm_runtime_enable(dev); --=20 2.35.1.1178.g4f1659d476-goog