[PATCH v7 07/10] drm/bridge: ti-sn65dsi86: Promote the AUX channel to its own sub-dev
Douglas Anderson
dianders at chromium.org
Mon May 17 20:09:04 UTC 2021
On its own, this change looks a little strange and doesn't do too much
useful. To understand why we're doing this we need to look forward to
future patches where we're going to probe our panel using the new DP
AUX bus. See the patch ("drm/bridge: ti-sn65dsi86: Add support for the
DP AUX bus").
Let's think about the set of steps we'll want to happen when we have
the DP AUX bus:
1. We'll create the DP AUX bus.
2. We'll populate the devices on the DP AUX bus (AKA our panel).
3. For setting up the bridge-related functions of ti-sn65dsi86 we'll
need to get a reference to the panel.
If we do #1 - #3 in a single probe call things _mostly_ will work, but
it won't be massively robust. Let's explore.
First let's think of the easy case of no -EPROBE_DEFER. In that case
in step #2 when we populate the devices on the DP AUX bus it will
actually try probing the panel right away. Since the panel probe
doesn't defer then in step #3 we'll get a reference to the panel and
we're golden.
Second, let's think of the case when the panel returns
-EPROBE_DEFER. In that case step #2 won't synchronously create the
panel (it'll just add the device to the defer list to do it
later). Step #3 will fail to get the panel and the bridge sub-device
will return -EPROBE_DEFER. We'll depopulate the DP AUX bus. Later
we'll try the whole sequence again. Presumably the panel will
eventually stop returning -EPROBE_DEFER and we'll go back to the first
case where things were golden. So this case is OK too even if it's a
bit ugly that we have to keep creating / deleting the AUX bus over and
over.
So where is the problem? As I said, it's mostly about robustness. I
don't believe that step #2 (creating the sub-devices) is really
guaranteed to be synchronous. This is evidenced by the fact that it's
allowed to "succeed" by just sticking the device on the deferred
list. If anything about the process changes in Linux as a whole and
step #2 just kicks off the probe of the DP AUX endpoints (our panel)
in the background then we'd be in trouble because we might never get
the panel in step #3.
Adding an extra sub-device means we just don't need to worry about
it. We'll create the sub-device for the DP AUX bus and it won't go
away until the whole ti-sn65dsi86 driver goes away. If the bridge
sub-device defers (maybe because it can't find the panel) that won't
depopulate the DP AUX bus and so we don't need to worry about it.
NOTE: there's a little bit of a trick here. Though the AUX channel can
run without the MIPI-to-eDP bits of the code, the MIPI-to-eDP bits
can't run without the AUX channel. We could come up a complicated
signaling scheme (have the MIPI-to-eDP bits return EPROBE_DEFER for a
while or wait on some sort of completion), but it seems simple enough
to just not even bother creating the bridge device until the AUX
channel probes. That's what we'll do.
Signed-off-by: Douglas Anderson <dianders at chromium.org>
---
Changes in v7:
- Remove use of now-dropped drm_dp_aux_register_ddc() call.
- Beefed up commit message in context of the DP AUX bus.
- Set the proper sub-device "dev" pointer in the AUX structure.
Changes in v6:
- Use new drm_dp_aux_register_ddc() calls.
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 80 +++++++++++++++++++++++----
1 file changed, 69 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index bb0a0e1c6341..42a55d13864b 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -116,6 +116,7 @@
* struct ti_sn65dsi86 - Platform data for ti-sn65dsi86 driver.
* @bridge_aux: AUX-bus sub device for MIPI-to-eDP bridge functionality.
* @gpio_aux: AUX-bus sub device for GPIO controller functionality.
+ * @aux_aux: AUX-bus sub device for eDP AUX channel functionality.
*
* @dev: Pointer to the top level (i2c) device.
* @regmap: Regmap for accessing i2c.
@@ -148,6 +149,7 @@
struct ti_sn65dsi86 {
struct auxiliary_device bridge_aux;
struct auxiliary_device gpio_aux;
+ struct auxiliary_device aux_aux;
struct device *dev;
struct regmap *regmap;
@@ -1331,11 +1333,6 @@ static int ti_sn_bridge_probe(struct auxiliary_device *adev,
if (ret)
return ret;
- pdata->aux.name = "ti-sn65dsi86-aux";
- pdata->aux.dev = pdata->dev;
- pdata->aux.transfer = ti_sn_aux_transfer;
- drm_dp_aux_init(&pdata->aux);
-
pdata->bridge.funcs = &ti_sn_bridge_funcs;
pdata->bridge.of_node = np;
@@ -1430,6 +1427,53 @@ static int ti_sn65dsi86_add_aux_device(struct ti_sn65dsi86 *pdata,
return ret;
}
+static int ti_sn_aux_probe(struct auxiliary_device *adev,
+ const struct auxiliary_device_id *id)
+{
+ struct ti_sn65dsi86 *pdata = dev_get_drvdata(adev->dev.parent);
+ int ret;
+
+ /*
+ * We couldn't do this pre-probe because it would confuse pinctrl.
+ * It would have tried to grab the same pins that the main device had.
+ * Set it now so that we can put the proper (sub) device in the aux
+ * structure and it will have the right node.
+ */
+ adev->dev.of_node = pdata->dev->of_node;
+
+ pdata->aux.name = "ti-sn65dsi86-aux";
+ pdata->aux.dev = &adev->dev;
+ pdata->aux.transfer = ti_sn_aux_transfer;
+ drm_dp_aux_init(&pdata->aux);
+
+ /*
+ * The eDP to MIPI bridge parts don't work until the AUX channel is
+ * setup so we don't add it in the main driver probe, we add it now.
+ */
+ ret = ti_sn65dsi86_add_aux_device(pdata, &pdata->bridge_aux, "bridge");
+
+ /*
+ * Clear of_node on any errors. Really this only matters if the error
+ * is -EPROBE_DEFER to avoid (again) keep pinctrl from claiming when
+ * it tries the probe again, but it shouldn't hurt on any error.
+ */
+ if (ret)
+ adev->dev.of_node = NULL;
+
+ return ret;
+}
+
+static const struct auxiliary_device_id ti_sn_aux_id_table[] = {
+ { .name = "ti_sn65dsi86.aux", },
+ {},
+};
+
+static struct auxiliary_driver ti_sn_aux_driver = {
+ .name = "aux",
+ .probe = ti_sn_aux_probe,
+ .id_table = ti_sn_aux_id_table,
+};
+
static int ti_sn65dsi86_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -1488,10 +1532,11 @@ static int ti_sn65dsi86_probe(struct i2c_client *client,
* motiviation here is to solve the chicken-and-egg problem of probe
* ordering. The bridge wants the panel to be there when it probes.
* The panel wants its HPD GPIO (provided by sn65dsi86 on some boards)
- * when it probes. There will soon be other devices (DDC I2C bus, PWM)
- * that have the same problem. Having sub-devices allows the some sub
- * devices to finish probing even if others return -EPROBE_DEFER and
- * gets us around the problems.
+ * when it probes. The panel and maybe backlight might want the DDC
+ * bus. Soon the PWM provided by the bridge chip will have the same
+ * problem. Having sub-devices allows the some sub devices to finish
+ * probing even if others return -EPROBE_DEFER and gets us around the
+ * problems.
*/
if (IS_ENABLED(CONFIG_OF_GPIO)) {
@@ -1500,7 +1545,13 @@ static int ti_sn65dsi86_probe(struct i2c_client *client,
return ret;
}
- return ti_sn65dsi86_add_aux_device(pdata, &pdata->bridge_aux, "bridge");
+ /*
+ * NOTE: At the end of the AUX channel probe we'll add the aux device
+ * for the bridge. This is because the bridge can't be used until the
+ * AUX channel is there and this is a very simple solution to the
+ * dependency problem.
+ */
+ return ti_sn65dsi86_add_aux_device(pdata, &pdata->aux_aux, "aux");
}
static struct i2c_device_id ti_sn65dsi86_id[] = {
@@ -1537,12 +1588,18 @@ static int __init ti_sn65dsi86_init(void)
if (ret)
goto err_main_was_registered;
- ret = auxiliary_driver_register(&ti_sn_bridge_driver);
+ ret = auxiliary_driver_register(&ti_sn_aux_driver);
if (ret)
goto err_gpio_was_registered;
+ ret = auxiliary_driver_register(&ti_sn_bridge_driver);
+ if (ret)
+ goto err_aux_was_registered;
+
return 0;
+err_aux_was_registered:
+ auxiliary_driver_unregister(&ti_sn_aux_driver);
err_gpio_was_registered:
ti_sn_gpio_unregister();
err_main_was_registered:
@@ -1555,6 +1612,7 @@ module_init(ti_sn65dsi86_init);
static void __exit ti_sn65dsi86_exit(void)
{
auxiliary_driver_unregister(&ti_sn_bridge_driver);
+ auxiliary_driver_unregister(&ti_sn_aux_driver);
ti_sn_gpio_unregister();
i2c_del_driver(&ti_sn65dsi86_driver);
}
--
2.31.1.751.gd2f1c929bd-goog
More information about the dri-devel
mailing list