All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <swboyd@chromium.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Douglas Anderson <dianders@chromium.org>
Cc: Saravana Kannan <saravanak@google.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Russell King <rmk+kernel@arm.linux.org.uk>,
	freedreno@lists.freedesktop.org
Subject: [PATCH v5 06/32] drm/msm: Migrate to aggregate driver
Date: Thu,  6 Jan 2022 13:45:29 -0800	[thread overview]
Message-ID: <20220106214556.2461363-7-swboyd@chromium.org> (raw)
In-Reply-To: <20220106214556.2461363-1-swboyd@chromium.org>

The device lists are poorly ordered when the component device code is
used. This is because component_master_add_with_match() returns 0
regardless of component devices calling component_add() first. It can
really only fail if an allocation fails, in which case everything is
going bad and we're out of memory. The driver that registers the
aggregate driver, can succeed at probe and put the attached device on
the DPM lists before any of the component devices are probed and put on
the lists.

Within the component device framework this usually isn't that bad
because the real driver work is done at bind time via
component{,master}_ops::bind(). It becomes a problem when the driver
core, or host driver, wants to operate on the component device outside
of the bind/unbind functions, e.g. via 'remove' or 'shutdown'. The
driver core doesn't understand the relationship between the host device
and the component devices and could possibly try to operate on component
devices when they're already removed from the system or shut down.

Normally, device links or probe defer would reorder the lists and put
devices that depend on other devices in the lists at the correct
location, but with component devices this doesn't happen because this
information isn't expressed anywhere. Drivers simply succeed at
registering their component or the aggregate driver with the component
framework and wait for their bind() callback to be called once the other
components are ready. In summary, the drivers that make up the aggregate
driver can probe in any order.

This ordering problem becomes fairly obvious when shutting down the
device with a DSI controller connected to a DSI bridge that is
controlled via i2c. In this case, the msm display driver wants to tear
down the display pipeline on shutdown via msm_pdev_shutdown() by calling
drm_atomic_helper_shutdown(), and it can't do that unless the whole
display chain is still probed and active in the system. When a display
bridge is on i2c, the i2c device for the bridge will be created whenever
the i2c controller probes, which could be before or after the msm
display driver probes. If the i2c controller probes after the display
driver, then the i2c controller will be shutdown before the display
controller during system wide shutdown and thus i2c transactions will
stop working before the display pipeline is shut down. This means we'll
have the display bridge trying to access an i2c bus that's shut down
because drm_atomic_helper_shutdown() is trying to disable the bridge
after the bridge is off.

The solution is to make the aggregate driver into a real struct driver
that is bound to a device when the other component devices have all
probed. Now that the component driver code is a proper bus, we can
simply register an aggregate driver with that bus via
component_aggregate_register() and then attach the shutdown hook to that
driver to be sure that the shutdown for the display pipeline is called
before any of the component device driver shutdown hooks are called.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Saravana Kannan <saravanak@google.com>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
 drivers/gpu/drm/msm/msm_drv.c | 46 +++++++++++++++++++----------------
 1 file changed, 25 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 7936e8d498dd..f6e9b0d318f5 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1360,19 +1360,35 @@ static int add_gpu_components(struct device *dev,
 	return 0;
 }
 
-static int msm_drm_bind(struct device *dev)
+static int msm_drm_bind(struct aggregate_device *adev)
 {
-	return msm_drm_init(dev, &msm_driver);
+	return msm_drm_init(adev->parent, &msm_driver);
 }
 
-static void msm_drm_unbind(struct device *dev)
+static void msm_drm_unbind(struct aggregate_device *adev)
 {
-	msm_drm_uninit(dev);
+	msm_drm_uninit(adev->parent);
+}
+
+static void msm_drm_shutdown(struct aggregate_device *adev)
+{
+	struct drm_device *drm = platform_get_drvdata(to_platform_device(adev->parent));
+	struct msm_drm_private *priv = drm ? drm->dev_private : NULL;
+
+	if (!priv || !priv->kms)
+		return;
+
+	drm_atomic_helper_shutdown(drm);
 }
 
-static const struct component_master_ops msm_drm_ops = {
-	.bind = msm_drm_bind,
-	.unbind = msm_drm_unbind,
+static struct aggregate_driver msm_drm_aggregate_driver = {
+	.probe = msm_drm_bind,
+	.remove = msm_drm_unbind,
+	.shutdown = msm_drm_shutdown,
+	.driver = {
+		.name	= "msm_drm",
+		.owner	= THIS_MODULE,
+	},
 };
 
 /*
@@ -1401,7 +1417,7 @@ static int msm_pdev_probe(struct platform_device *pdev)
 	if (ret)
 		goto fail;
 
-	ret = component_master_add_with_match(&pdev->dev, &msm_drm_ops, match);
+	ret = component_aggregate_register(&pdev->dev, &msm_drm_aggregate_driver, match);
 	if (ret)
 		goto fail;
 
@@ -1414,23 +1430,12 @@ static int msm_pdev_probe(struct platform_device *pdev)
 
 static int msm_pdev_remove(struct platform_device *pdev)
 {
-	component_master_del(&pdev->dev, &msm_drm_ops);
+	component_aggregate_unregister(&pdev->dev, &msm_drm_aggregate_driver);
 	of_platform_depopulate(&pdev->dev);
 
 	return 0;
 }
 
-static void msm_pdev_shutdown(struct platform_device *pdev)
-{
-	struct drm_device *drm = platform_get_drvdata(pdev);
-	struct msm_drm_private *priv = drm ? drm->dev_private : NULL;
-
-	if (!priv || !priv->kms)
-		return;
-
-	drm_atomic_helper_shutdown(drm);
-}
-
 static const struct of_device_id dt_match[] = {
 	{ .compatible = "qcom,mdp4", .data = (void *)KMS_MDP4 },
 	{ .compatible = "qcom,mdss", .data = (void *)KMS_MDP5 },
@@ -1446,7 +1451,6 @@ MODULE_DEVICE_TABLE(of, dt_match);
 static struct platform_driver msm_platform_driver = {
 	.probe      = msm_pdev_probe,
 	.remove     = msm_pdev_remove,
-	.shutdown   = msm_pdev_shutdown,
 	.driver     = {
 		.name   = "msm",
 		.of_match_table = dt_match,
-- 
https://chromeos.dev


WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <swboyd@chromium.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Douglas Anderson <dianders@chromium.org>
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Rob Clark <robdclark@gmail.com>,
	Russell King <rmk+kernel@arm.linux.org.uk>,
	Saravana Kannan <saravanak@google.com>
Subject: [PATCH v5 06/32] drm/msm: Migrate to aggregate driver
Date: Thu,  6 Jan 2022 13:45:29 -0800	[thread overview]
Message-ID: <20220106214556.2461363-7-swboyd@chromium.org> (raw)
In-Reply-To: <20220106214556.2461363-1-swboyd@chromium.org>

The device lists are poorly ordered when the component device code is
used. This is because component_master_add_with_match() returns 0
regardless of component devices calling component_add() first. It can
really only fail if an allocation fails, in which case everything is
going bad and we're out of memory. The driver that registers the
aggregate driver, can succeed at probe and put the attached device on
the DPM lists before any of the component devices are probed and put on
the lists.

Within the component device framework this usually isn't that bad
because the real driver work is done at bind time via
component{,master}_ops::bind(). It becomes a problem when the driver
core, or host driver, wants to operate on the component device outside
of the bind/unbind functions, e.g. via 'remove' or 'shutdown'. The
driver core doesn't understand the relationship between the host device
and the component devices and could possibly try to operate on component
devices when they're already removed from the system or shut down.

Normally, device links or probe defer would reorder the lists and put
devices that depend on other devices in the lists at the correct
location, but with component devices this doesn't happen because this
information isn't expressed anywhere. Drivers simply succeed at
registering their component or the aggregate driver with the component
framework and wait for their bind() callback to be called once the other
components are ready. In summary, the drivers that make up the aggregate
driver can probe in any order.

This ordering problem becomes fairly obvious when shutting down the
device with a DSI controller connected to a DSI bridge that is
controlled via i2c. In this case, the msm display driver wants to tear
down the display pipeline on shutdown via msm_pdev_shutdown() by calling
drm_atomic_helper_shutdown(), and it can't do that unless the whole
display chain is still probed and active in the system. When a display
bridge is on i2c, the i2c device for the bridge will be created whenever
the i2c controller probes, which could be before or after the msm
display driver probes. If the i2c controller probes after the display
driver, then the i2c controller will be shutdown before the display
controller during system wide shutdown and thus i2c transactions will
stop working before the display pipeline is shut down. This means we'll
have the display bridge trying to access an i2c bus that's shut down
because drm_atomic_helper_shutdown() is trying to disable the bridge
after the bridge is off.

The solution is to make the aggregate driver into a real struct driver
that is bound to a device when the other component devices have all
probed. Now that the component driver code is a proper bus, we can
simply register an aggregate driver with that bus via
component_aggregate_register() and then attach the shutdown hook to that
driver to be sure that the shutdown for the display pipeline is called
before any of the component device driver shutdown hooks are called.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Saravana Kannan <saravanak@google.com>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
 drivers/gpu/drm/msm/msm_drv.c | 46 +++++++++++++++++++----------------
 1 file changed, 25 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 7936e8d498dd..f6e9b0d318f5 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1360,19 +1360,35 @@ static int add_gpu_components(struct device *dev,
 	return 0;
 }
 
-static int msm_drm_bind(struct device *dev)
+static int msm_drm_bind(struct aggregate_device *adev)
 {
-	return msm_drm_init(dev, &msm_driver);
+	return msm_drm_init(adev->parent, &msm_driver);
 }
 
-static void msm_drm_unbind(struct device *dev)
+static void msm_drm_unbind(struct aggregate_device *adev)
 {
-	msm_drm_uninit(dev);
+	msm_drm_uninit(adev->parent);
+}
+
+static void msm_drm_shutdown(struct aggregate_device *adev)
+{
+	struct drm_device *drm = platform_get_drvdata(to_platform_device(adev->parent));
+	struct msm_drm_private *priv = drm ? drm->dev_private : NULL;
+
+	if (!priv || !priv->kms)
+		return;
+
+	drm_atomic_helper_shutdown(drm);
 }
 
-static const struct component_master_ops msm_drm_ops = {
-	.bind = msm_drm_bind,
-	.unbind = msm_drm_unbind,
+static struct aggregate_driver msm_drm_aggregate_driver = {
+	.probe = msm_drm_bind,
+	.remove = msm_drm_unbind,
+	.shutdown = msm_drm_shutdown,
+	.driver = {
+		.name	= "msm_drm",
+		.owner	= THIS_MODULE,
+	},
 };
 
 /*
@@ -1401,7 +1417,7 @@ static int msm_pdev_probe(struct platform_device *pdev)
 	if (ret)
 		goto fail;
 
-	ret = component_master_add_with_match(&pdev->dev, &msm_drm_ops, match);
+	ret = component_aggregate_register(&pdev->dev, &msm_drm_aggregate_driver, match);
 	if (ret)
 		goto fail;
 
@@ -1414,23 +1430,12 @@ static int msm_pdev_probe(struct platform_device *pdev)
 
 static int msm_pdev_remove(struct platform_device *pdev)
 {
-	component_master_del(&pdev->dev, &msm_drm_ops);
+	component_aggregate_unregister(&pdev->dev, &msm_drm_aggregate_driver);
 	of_platform_depopulate(&pdev->dev);
 
 	return 0;
 }
 
-static void msm_pdev_shutdown(struct platform_device *pdev)
-{
-	struct drm_device *drm = platform_get_drvdata(pdev);
-	struct msm_drm_private *priv = drm ? drm->dev_private : NULL;
-
-	if (!priv || !priv->kms)
-		return;
-
-	drm_atomic_helper_shutdown(drm);
-}
-
 static const struct of_device_id dt_match[] = {
 	{ .compatible = "qcom,mdp4", .data = (void *)KMS_MDP4 },
 	{ .compatible = "qcom,mdss", .data = (void *)KMS_MDP5 },
@@ -1446,7 +1451,6 @@ MODULE_DEVICE_TABLE(of, dt_match);
 static struct platform_driver msm_platform_driver = {
 	.probe      = msm_pdev_probe,
 	.remove     = msm_pdev_remove,
-	.shutdown   = msm_pdev_shutdown,
 	.driver     = {
 		.name   = "msm",
 		.of_match_table = dt_match,
-- 
https://chromeos.dev


  parent reply	other threads:[~2022-01-06 21:46 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-06 21:45 [PATCH v5 00/32] component: Make into an aggregate bus Stephen Boyd
2022-01-06 21:45 ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 01/32] component: Replace most references to 'master' with 'aggregate device' Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 02/32] component: Introduce the aggregate bus_type Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 03/32] component: Move struct aggregate_device out to header file Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-07 13:07   ` Jani Nikula
2022-01-07 20:12     ` Stephen Boyd
2022-01-10 11:23       ` Jani Nikula
2022-01-06 21:45 ` [PATCH v5 04/32] component: Add {bind, unbind}_component() ops that take aggregate device Stephen Boyd
2022-01-06 21:45   ` [PATCH v5 04/32] component: Add {bind,unbind}_component() " Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 05/32] drm/of: Add a drm_of_aggregate_probe() API Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` Stephen Boyd [this message]
2022-01-06 21:45   ` [PATCH v5 06/32] drm/msm: Migrate to aggregate driver Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 07/32] drm/komeda: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 08/32] drm/arm/hdlcd: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 09/32] drm/malidp: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 10/32] drm/armada: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 11/32] drm/etnaviv: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 12/32] drm/kirin: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 13/32] drm/exynos: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 14/32] drm/imx: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 15/32] drm/ingenic: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 16/32] drm/mcde: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 17/32] drm/mediatek: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 18/32] drm/meson: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 19/32] drm/omap: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 20/32] drm/rockchip: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 21/32] drm/sti: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 22/32] drm/sun4i: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 23/32] drm/tilcdc: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 24/32] drm/vc4: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 25/32] iommu/mtk: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-11 12:22   ` Yong Wu
2022-01-11 12:22     ` Yong Wu
2022-01-11 12:22     ` Yong Wu
2022-01-12  0:27     ` Stephen Boyd
2022-01-12  0:27       ` Stephen Boyd
2022-01-12  0:27       ` Stephen Boyd
2022-01-12  9:09       ` Yong Wu
2022-01-12  9:09         ` Yong Wu
2022-01-12  9:09         ` Yong Wu
2022-01-12  9:09         ` Yong Wu
2022-01-13  4:25         ` Stephen Boyd
2022-01-13  4:25           ` Stephen Boyd
2022-01-13  4:25           ` Stephen Boyd
2022-01-13  4:25           ` Stephen Boyd
2022-01-14  9:06           ` Yong Wu
2022-01-14  9:06             ` Yong Wu
2022-01-14  9:06             ` Yong Wu
2022-01-14  9:06             ` Yong Wu
2022-01-14 21:30             ` Stephen Boyd
2022-01-14 21:30               ` Stephen Boyd
2022-01-14 21:30               ` Stephen Boyd
2022-01-14 21:30               ` Stephen Boyd
2022-01-15  7:39               ` Yong Wu
2022-01-15  7:39                 ` Yong Wu
2022-01-15  7:39                 ` Yong Wu
2022-01-15  7:39                 ` Yong Wu
2022-01-15  7:50                 ` Stephen Boyd
2022-01-15  7:50                   ` Stephen Boyd
2022-01-15  7:50                   ` Stephen Boyd
2022-01-15  7:50                   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 26/32] mei: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 27/32] power: supply: ab8500: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 28/32] fbdev: omap2: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 29/32] sound: hdac: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 30/32] ASoC: codecs: wcd938x: " Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 31/32] component: Get rid of drm_of_component_probe() Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd
2022-01-06 21:45 ` [PATCH v5 32/32] component: Remove component_master_ops and friends Stephen Boyd
2022-01-06 21:45   ` Stephen Boyd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220106214556.2461363-7-swboyd@chromium.org \
    --to=swboyd@chromium.org \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=rmk+kernel@arm.linux.org.uk \
    --cc=saravanak@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.