From patchwork Sat Apr 9 02:36:23 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 12807334 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 BD3D4C433FE for ; Sat, 9 Apr 2022 02:37:16 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C46B610E232; Sat, 9 Apr 2022 02:37:10 +0000 (UTC) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6875310E209 for ; Sat, 9 Apr 2022 02:37:07 +0000 (UTC) Received: by mail-pj1-x1033.google.com with SMTP id n6-20020a17090a670600b001caa71a9c4aso11409239pjj.1 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=pFY3XczwAZXbADb1sQs28ppiGOgCQIys/wrn3DBqq/stm/ZmLt/Eimqk3tw/8aEtbR jES6bLDPRN9IsDtfAZppQ+usEgYjh50IQjdCIP+2ZQBjCQoxxoJeVooBhvYliuNhjHSU JJNaw2Me96V3LD49E7rF4BbUYfHLMEoVe+8Or5mAHhWa0blpMoBLcVRpWY6DYbWpkiXq 3npnkFRq3bCyUlpYi3GcRQdbOw7CZBW30FQt8isMORINrxhYKvtz93AQ9S8FujXAoaG+ aTCfcrPf7pNbpoCaCIw8SLQ7E/NH7oyUPGJVDg/Qd0mKOEnd8Zs9aLEvAijIBvnz92Nt ocfA== X-Gm-Message-State: AOAM533iZmPCOalKX0sxp8gAwD7Xb7+lGbdFJyvlOz212iK9DLi7oMCX QxSZdRGUyf8bEGeKxP0M1ON3++ps/EjNT/HKyHSMmw== 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 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 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: Douglas Anderson , Sankeerth Billakanti , Philip Chen , Thomas Zimmermann , David Airlie , linux-kernel@vger.kernel.org, Abhinav Kumar , Robert Foss , Stephen Boyd , Hsin-Yi Wang , Dmitry Baryshkov Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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_dp_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. */ +#include #include #include #include @@ -299,6 +300,163 @@ void dp_aux_dp_driver_unregister(struct dp_aux_ep_driver *drv) } EXPORT_SYMBOL_GPL(dp_aux_dp_driver_unregister); +/* ----------------------------------------------------------------------------- + * 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 = + 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 = + 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 = + 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 = to_auxiliary_dev(dev); + struct dp_aux_ep_client_data *data = + 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 = kzalloc(sizeof(*data), GFP_KERNEL); + if (!data) + return -ENOMEM; + + data->client = client; + data->adev.name = "ep_client"; + data->adev.dev.parent = client->aux->dev; + data->adev.dev.release = dp_aux_ep_client_dev_release; + device_set_of_node_from_dev(&data->adev.dev, client->aux->dev); + + ret = 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 = auxiliary_device_add(&data->adev); + if (ret) + goto err_did_init; + + client->_opaque = 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 this + * to free resources. + */ +void dp_aux_unregister_ep_client(struct dp_aux_ep_client *client) +{ + struct dp_aux_ep_client_data *data = 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 = 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[] = { + { .name = "drm_dp_aux_bus.ep_client", }, + {}, +}; + +static struct auxiliary_driver dp_aux_ep_client_driver = { + .name = "ep_client", + .probe = dp_aux_ep_client_probe, + .remove = dp_aux_ep_client_remove, + .shutdown = dp_aux_ep_client_shutdown, + .id_table = 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; - return 0; + ret = auxiliary_driver_register(&dp_aux_ep_client_driver); + if (ret) + bus_unregister(&dp_aux_bus_type); + + return ret; } static void __exit dp_aux_bus_exit(void) { + auxiliary_driver_unregister(&dp_aux_ep_client_driver); bus_unregister(&dp_aux_bus_type); } diff --git a/include/drm/dp/drm_dp_aux_bus.h b/include/drm/dp/drm_dp_aux_bus.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); +/** + * 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 probe + * 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 might + * 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 will + * acquire the reference to the DP AUX endpoint. The first part can complete + * 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 managing + * 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_node + * 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 *client); + + /** @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_ */ From patchwork Sat Apr 9 02:36:24 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 12807333 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 88D82C433EF for ; Sat, 9 Apr 2022 02:37:13 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A979510E22D; Sat, 9 Apr 2022 02:37:10 +0000 (UTC) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) by gabe.freedesktop.org (Postfix) with ESMTPS id E94B610E209 for ; Sat, 9 Apr 2022 02:37:08 +0000 (UTC) Received: by mail-pf1-x433.google.com with SMTP id bo5so9987056pfb.4 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=eObFXH1SpjmLAp7g2X6c8Yxl6dWShz7pP7n8QzsKzGtsSTQdWJaSwI+H47Ue9TcFEw Adq4mAocABznql8zOiDCrV7p+bPhfCbj4UBNiEXaNi7yHCETf686hg5sD9/Si1seU1Vv yflOF7l2kSMCUIevIN1RzmSpt852shok7EL/uBTWv2KOyB8OsMwKnfzW4qBPEbL4H/2z 1XV3NGboIVzw9KvJyeI/XvUpe3Zics+sDwyXM5TqdKVU7igaJdrdhQ1XzQ+BzzuyY7EO xM+6rqfE6rzKmBQEjkkFIS2kFNb6nVBf1aJGgKjg64qDeMpBVmGLGuD4gS2WSPwB0VMR 9v6A== X-Gm-Message-State: AOAM530bpwEu5DUCwV/lW3J8bdAtOx9XvGhZ1jThcNmF6jHxZURa9XZO gwiULebboZ1GSnvPf/rvqxz/G+yfy+Iz5EDd9jVdGQ== 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 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 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: Douglas Anderson , Sankeerth Billakanti , Philip Chen , Jonas Karlman , David Airlie , linux-kernel@vger.kernel.org, Neil Armstrong , Abhinav Kumar , Robert Foss , Stephen Boyd , Jernej Skrabec , Andrzej Hajda , Hsin-Yi Wang , Dmitry Baryshkov , Laurent Pinchart Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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/bridge/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 { }; 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 *dev, struct ps8640 *ps_bridg return 0; } +static int ps8640_bridge_probe(struct device *clientdev, struct dp_aux_ep_client *client) +{ + struct ps8640 *ps_bridge = container_of(client, struct ps8640, ep_client); + struct device_node *np = clientdev->of_node; + int ret; + + /* port@1 is ps8640 output port */ + ps_bridge->panel_bridge = 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 = 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_ep_client *client) +{ + struct ps8640 *ps_bridge = container_of(client, struct ps8640, ep_client); + + drm_bridge_remove(&ps_bridge->bridge); +} + static int ps8640_probe(struct i2c_client *client) { struct device *dev = &client->dev; - struct device_node *np = dev->of_node; struct ps8640 *ps_bridge; int ret; u32 i; @@ -672,31 +699,17 @@ static int ps8640_probe(struct i2c_client *client) devm_of_dp_aux_populate_ep_devices(&ps_bridge->aux); - /* port@1 is ps8640 output port */ - ps_bridge->panel_bridge = 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 = 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 = 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 = ps8640_bridge_probe; + ps_bridge->ep_client.remove = ps8640_bridge_remove; + ps_bridge->ep_client.aux = &ps_bridge->aux; + return devm_dp_aux_register_ep_client(&ps_bridge->ep_client); } static const struct of_device_id ps8640_match[] = { @@ -707,7 +720,6 @@ MODULE_DEVICE_TABLE(of, ps8640_match); static struct i2c_driver ps8640_driver = { .probe_new = ps8640_probe, - .remove = ps8640_remove, .driver = { .name = "ps8640", .of_match_table = ps8640_match, From patchwork Sat Apr 9 02:36:25 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 12807336 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 D3D13C433EF for ; Sat, 9 Apr 2022 02:37:21 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6A76210E209; Sat, 9 Apr 2022 02:37:17 +0000 (UTC) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9415910E226 for ; Sat, 9 Apr 2022 02:37:10 +0000 (UTC) Received: by mail-pj1-x1033.google.com with SMTP id j20-20020a17090ae61400b001ca9553d073so11364337pjy.5 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=GfHfwaGSauLJnEcaMLd67Bv9YQciLek+K8Y3sE2hs8mvD0SbiwA/XOSoutUlcstf0T jtcHkLqJuVcJWun5rlp+WvmHYc+I3naeE6UhY5nP1vNTw5/Fmq/H2JvrZCeuRu2lQraf c0+59nrAPzWoKdgWCXKTUDanDGTyhrqgIVNQ9YGz7stZIvw3Gp63I3GcZ99tUxVcSarV 5LRM0XY9CZ4nXqoNrwN6LG6TKEsRfBbPMl1wQ8Bk9S7K9iY2VFotTggjlMIIZUMAmHfe 6R57ZY9BZx/RPA80kyyZkh5XsjDJfGBXc3CFBjAk72+gNOZUcPcXgHpbs3fyNz2UunLY cw3A== X-Gm-Message-State: AOAM532xRBH/ZxV+Ek2uKm5jx9TYYxlyMRAA/FkYuhvrkt96rBswL6Ea iKe+u1LBvwlEH1zxb55D3lBs2hUSSnxYZTcL/q/4fQ== 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 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 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: Douglas Anderson , Sankeerth Billakanti , Philip Chen , Kees Cook , David Airlie , linux-kernel@vger.kernel.org, Abhinav Kumar , Robert Foss , Stephen Boyd , Jani Nikula , Maxime Ripard , Hsin-Yi Wang , Dmitry Baryshkov Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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); + /** + * @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. */ From patchwork Sat Apr 9 02:36:26 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 12807335 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 703F5C433F5 for ; Sat, 9 Apr 2022 02:37:19 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D3DAF10E226; Sat, 9 Apr 2022 02:37:15 +0000 (UTC) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by gabe.freedesktop.org (Postfix) with ESMTPS id 18EC410E23C for ; Sat, 9 Apr 2022 02:37:12 +0000 (UTC) Received: by mail-pf1-x434.google.com with SMTP id z16so9994498pfh.3 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=2lTX15qfJvy04lNwW12DpIcmD8DBCSGm0e4aqvNbx/jxU0njEZJhDgY1ePWPMI/LbW 3vldFRv8saktzNrmG/cLVixZf6rbigH4rI6fi2K5wiOE62o/gwu+Z+Gx5VFxScZDGAfO DHJzaMIta+0QM7VU2Z+srSpWeXzC864A99F+zn9fowg+e4MX7as8f9UUFi2X40apsbcg Gz7ZjCC1ykU2PsQNAZVths4xN/nDF8ec6OOZ+M2HJTReWpkX72kF0rEfC//wzkd4iJ1H KPeLr8F6/tPQEIjP6ptUV+gaNRYvz/7mdhVa0vHlkUB4lGw4qJClOnoN6b4Y72ItO/SM 7Xwg== X-Gm-Message-State: AOAM533BwXwk+EjUJU4mElutJRbfpRNxkUBCCEw88Qg4xi7tF193V7Ul jbeTobgv7gclmUZ6mWHIL0O1JIMollu1F55Qr6PfQw== 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 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 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: Douglas Anderson , Sankeerth Billakanti , Philip Chen , David Airlie , linux-kernel@vger.kernel.org, Abhinav Kumar , Robert Foss , Stephen Boyd , Thierry Reding , Hsin-Yi Wang , Dmitry Baryshkov , Sam Ravnborg Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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/panel-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; } +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 = p->base.dev; @@ -441,13 +454,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, + /* + * 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 += 3000000; + + err = 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 = max(delay, p->desc->delay.prepare_to_enable); if (delay) From patchwork Sat Apr 9 02:36:27 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 12807338 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 2C313C433FE for ; Sat, 9 Apr 2022 02:37:25 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 13A9810E24E; Sat, 9 Apr 2022 02:37:18 +0000 (UTC) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by gabe.freedesktop.org (Postfix) with ESMTPS id 703B110E209 for ; Sat, 9 Apr 2022 02:37:13 +0000 (UTC) Received: by mail-pj1-x102e.google.com with SMTP id a16-20020a17090a6d9000b001c7d6c1bb13so11376583pjk.4 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=Jfq1jNQ0sxXbRgbUxKmoWbPVpOtA9Qju6S0f12TopokP0tW/dI7/wUWxqFUWrOhe8P KPCxzR9mOe+s8N3erwkmtS3C7JhL28j7VeFrrEIWCbpab6WKQEAtOut6/7hNnHZqwTu2 nVjabKgzfYwQmlAqPSswij9pUeZMckQ9OuZY+Rd4KY7fj5H6wwui5Et8hopgtzLeFd8F a6a+mROY6ATQHLuc9v89fCo2OW18koYGIfkTijxkHr6r3D5uzMyrfLujCRDj9oLqGyZz tbrwsNrVv3RDfKfV9U+m1kFw6dz8cNCpNoUmLYA7lf8ddBH1aN06FmVFAk7O/37XsNSe sZYA== X-Gm-Message-State: AOAM533Rmq7Bex0J1Fk7zpFD99f031c2CY+NonWhDT8yqFCQG2Z6Onzt y7TingQrTpUwhlRSWFG+ZJsl6zISClLfO0Wym7BcVQ== 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 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 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: Douglas Anderson , Sankeerth Billakanti , Philip Chen , David Airlie , linux-kernel@vger.kernel.org, Abhinav Kumar , Robert Foss , Stephen Boyd , Thierry Reding , Hsin-Yi Wang , Dmitry Baryshkov , Sam Ravnborg Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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 { struct regulator *supply; struct gpio_desc *el_on3_gpio; + struct drm_dp_aux *aux; struct edid *edid; @@ -76,6 +77,19 @@ static int atana33xc20_suspend(struct device *dev) return 0; } +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 = dev_get_drvdata(dev); @@ -92,17 +106,24 @@ static int atana33xc20_resume(struct device *dev) /* * 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 = 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 = 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 *aux_ep) return -ENOMEM; dev_set_drvdata(dev, panel); + panel->aux = aux_ep->aux; + panel->supply = devm_regulator_get(dev, "power"); if (IS_ERR(panel->supply)) return dev_err_probe(dev, PTR_ERR(panel->supply), From patchwork Sat Apr 9 02:36:28 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 12807337 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 998F4C433EF for ; Sat, 9 Apr 2022 02:37:23 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id F104210E240; Sat, 9 Apr 2022 02:37:17 +0000 (UTC) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by gabe.freedesktop.org (Postfix) with ESMTPS id 147DE10E209 for ; Sat, 9 Apr 2022 02:37:15 +0000 (UTC) Received: by mail-pj1-x102a.google.com with SMTP id e8-20020a17090a118800b001cb13402ea2so6908006pja.0 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=wQzrS/hlLHSZWPZGx8kIup+Ztf/FwjegDEY/DiGGIuvJkm+rMSf0f1P+BxZm70rupL wGDOQOLxVK26ZwaTuPoA0piqGonr1RwP8JEuHoV1DlY605Z/M5qaSDdH2seLO943rQKV bV+FuL5+BYY4eKXTjpAh2/Z5xnuXT0xlq2l9jC8cfVWB63bH9m1UTJp/TWQtKJaJUgm5 jSEl7fC4K5k3uCMHxGNc7sLcsQsWrTS29aC1XbLfHFecMWvYKkLef2b3FIewQkJbsB0w 4Fq3s57wWPpzkgVrVOzI8hAqNBM6OW30z17FBXHFhWRykby7aln2+nyoKvqg+ipJjo0V ReLQ== X-Gm-Message-State: AOAM532esFUaDl4va+F0CEY/xNjZXb/SqOaSZmYIL2bsjIchPqWV9HgI F04sh7/plaZhpAYBWs+hguLhPKPlzcJ1YZK3gIpk6g== 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 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 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: Douglas Anderson , Sankeerth Billakanti , Philip Chen , Jonas Karlman , David Airlie , linux-kernel@vger.kernel.org, Neil Armstrong , Abhinav Kumar , Robert Foss , Stephen Boyd , Jernej Skrabec , Andrzej Hajda , Hsin-Yi Wang , Dmitry Baryshkov , Laurent Pinchart Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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/bridge/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; } +static bool ps8640_is_hpd_asserted(struct drm_dp_aux *aux) +{ + struct ps8640 *ps_bridge = aux_to_ps8640(aux); + struct regmap *map = ps_bridge->regmap[PAGE2_TOP_CNTL]; + struct device *dev = &ps_bridge->page[PAGE0_DP_CNTL]->dev; + unsigned int status = 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 *aux, int ret; pm_runtime_get_sync(dev); - ret = ps8640_ensure_hpd(ps_bridge); - if (!ret) - ret = ps8640_aux_transfer_msg(aux, msg); + ret = ps8640_aux_transfer_msg(aux, msg); pm_runtime_mark_last_busy(dev); pm_runtime_put_autosuspend(dev); @@ -679,6 +693,7 @@ static int ps8640_probe(struct i2c_client *client) ps_bridge->aux.name = "parade-ps8640-aux"; ps_bridge->aux.dev = dev; ps_bridge->aux.transfer = ps8640_aux_transfer; + ps_bridge->aux.is_hpd_asserted = ps8640_is_hpd_asserted; drm_dp_aux_init(&ps_bridge->aux); pm_runtime_enable(dev);