| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20220614145327.v4.4.Ie827321ce263be52fdb8c1276f6f8cc00d78029f@changeid>
Date: Tue, 14 Jun 2022 14:54:18 -0700
From: Douglas Anderson <dianders@...omium.org>
To: dri-devel@...ts.freedesktop.org
Cc: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Stephen Boyd <swboyd@...omium.org>,
Robert Foss <robert.foss@...aro.org>,
Philip Chen <philipchen@...omium.org>,
Sankeerth Billakanti <quic_sbillaka@...cinc.com>,
Hsin-Yi Wang <hsinyi@...omium.org>,
Abhinav Kumar <quic_abhinavk@...cinc.com>,
Douglas Anderson <dianders@...omium.org>,
Andrzej Hajda <andrzej.hajda@...el.com>,
Daniel Vetter <daniel@...ll.ch>,
David Airlie <airlied@...ux.ie>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Jonas Karlman <jonas@...boo.se>,
Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
Neil Armstrong <narmstrong@...libre.com>,
linux-kernel@...r.kernel.org
Subject: [PATCH v4 4/4] drm/bridge: parade-ps8640: Provide wait_hpd_asserted() in struct drm_dp_aux
This implements the callback added by the patch ("drm/dp: Add
wait_hpd_asserted() callback to struct drm_dp_aux").
With this change and all the two "DP AUX Endpoint" drivers changed to
use wait_hpd_asserted(), we no longer need to have an long delay in
the AUX transfer function. It's up to the panel code to make sure that
the panel is powered now. If someone tried to call the aux transfer
function without making sure the panel is powered we'll just get a
normal transfer failure.
We'll still keep the wait for HPD in the pre_enable() function. Though
it's probably not actually needed there, this driver is used in the
old mode (pre-DP AUX Endpoints) and it may be important for those
cases. If nothing else, it shouldn't cause any big problems.
NOTE: When handling the timeout for HPD we start the timer _after_
we've runtime resumed the device. This is definitely important for the
panel on my homestar which comes up 170 ms after we start timing (the
panel specifies 200 ms max). It's a little unclear how much of this
extra time is due to some internal state machine in the parade
firmware vs. debouncing but it seems to work for the two test cases I
have to do it this way.
Signed-off-by: Douglas Anderson <dianders@...omium.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
---
Changes in v4:
- Add comment that caller powered up the panel.
- Mention in commit message debouncing vs. powering on timing.
Changes in v2:
- Change is_hpd_asserted() to wait_hpd_asserted()
drivers/gpu/drm/bridge/parade-ps8640.c | 39 +++++++++++++++++---------
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c
index ff4227f6d800..e880eee55822 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -168,23 +168,35 @@ static bool ps8640_of_panel_on_aux_bus(struct device *dev)
return true;
}
-static int ps8640_ensure_hpd(struct ps8640 *ps_bridge)
+static int _ps8640_wait_hpd_asserted(struct ps8640 *ps_bridge, unsigned long wait_us)
{
struct regmap *map = ps_bridge->regmap[PAGE2_TOP_CNTL];
- struct device *dev = &ps_bridge->page[PAGE2_TOP_CNTL]->dev;
int status;
- int ret;
/*
* Apparently something about the firmware in the chip signals that
* HPD goes high by reporting GPIO9 as high (even though HPD isn't
* actually connected to GPIO9).
*/
- ret = regmap_read_poll_timeout(map, PAGE2_GPIO_H, status,
- status & PS_GPIO9, 20 * 1000, 200 * 1000);
+ return regmap_read_poll_timeout(map, PAGE2_GPIO_H, status,
+ status & PS_GPIO9, wait_us / 10, wait_us);
+}
- if (ret < 0)
- dev_warn(dev, "HPD didn't go high: %d\n", ret);
+static int ps8640_wait_hpd_asserted(struct drm_dp_aux *aux, unsigned long wait_us)
+{
+ struct ps8640 *ps_bridge = aux_to_ps8640(aux);
+ struct device *dev = &ps_bridge->page[PAGE0_DP_CNTL]->dev;
+ int ret;
+
+ /*
+ * Note that this function is called by code that has already powered
+ * the panel. We have to power ourselves up but we don't need to worry
+ * about powering the panel.
+ */
+ pm_runtime_get_sync(dev);
+ ret = _ps8640_wait_hpd_asserted(ps_bridge, wait_us);
+ pm_runtime_mark_last_busy(dev);
+ pm_runtime_put_autosuspend(dev);
return ret;
}
@@ -323,9 +335,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);
@@ -369,8 +379,8 @@ static int __maybe_unused ps8640_resume(struct device *dev)
* Mystery 200 ms delay for the "MCU to be ready". It's unclear if
* this is truly necessary since the MCU will already signal that
* things are "good to go" by signaling HPD on "gpio 9". See
- * ps8640_ensure_hpd(). For now we'll keep this mystery delay just in
- * case.
+ * _ps8640_wait_hpd_asserted(). For now we'll keep this mystery delay
+ * just in case.
*/
msleep(200);
@@ -406,7 +416,9 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
int ret;
pm_runtime_get_sync(dev);
- ps8640_ensure_hpd(ps_bridge);
+ ret = _ps8640_wait_hpd_asserted(ps_bridge, 200 * 1000);
+ if (ret < 0)
+ dev_warn(dev, "HPD didn't go high: %d\n", ret);
/*
* The Manufacturer Command Set (MCS) is a device dependent interface
@@ -682,6 +694,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.wait_hpd_asserted = ps8640_wait_hpd_asserted;
drm_dp_aux_init(&ps_bridge->aux);
pm_runtime_enable(dev);
--
2.36.1.476.g0c4daa206d-goog
Powered by blists - more mailing lists