05.06.2019 11:28, Thierry Reding пишет:
On Tue, Jun 04, 2019 at 07:07:42PM +0300, Dmitry Osipenko wrote:
04.06.2019 18:31, Thierry Reding пишет:
From: Thierry Reding treding@nvidia.com
When deferring probe, avoid logging a confusing error message. While at it, make the error message more informational.
Signed-off-by: Thierry Reding treding@nvidia.com
drivers/gpu/host1x/dev.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c index c55e2d634887..5a3f797240d4 100644 --- a/drivers/gpu/host1x/dev.c +++ b/drivers/gpu/host1x/dev.c @@ -247,8 +247,11 @@ static int host1x_probe(struct platform_device *pdev)
host->clk = devm_clk_get(&pdev->dev, NULL); if (IS_ERR(host->clk)) {
dev_err(&pdev->dev, "failed to get clock\n");
if (err != -EPROBE_DEFER)dev_err(&pdev->dev, "failed to get clock: %d\n", err);- return err; }
The clock driver should be available at the time of host1x's probing on all Tegra's because it is one of essential core drivers that become available early during boot.
That's the currently baked-in assumption. However, there can be any number of reasons for why the clocks may not show up as early as expected, as evidenced in the case of Tegra186.
I guess you're making this change for T186, is it because the BPMP driver's probe getting deferred? If yes, won't it be possible to fix the defer of the clock driver instead of making such changes in the affected drivers?
The reason why this is now happening on Tegra186 is because the BPMP is bound to an IOMMU to avoid getting faults from the new no-bypass policy that the ARM SMMU driver is implementing as of v5.2-rc1.
As a result of binding to an IOMMU, the first probe of the BPMP driver will get deferred, so any driver trying to request a clock after that and before BPMP gets probed successfully the next time, any clk_get() calls will fail with -EPROBE_DEFER.
This is a bit unfortunate, but like I said, these kinds of things can happen, and probe deferral was designed specifically to deal with that kind of situation so that we wouldn't have to rely on all of these built-in assumptions that occasionally break.
The driver also already handles deferred probe properly. The only thing that this patch really changes is to no longer consider -EPROBE_DEFER an error. It's in fact a pretty common situation in many drivers and should not warrant a kernel log message.
You're trying to mask symptoms instead of curing the decease and it looks like the decease could be cured.
Won't something like this work for you?
From fbeabba5f1151e96edc38620db67593585558ca0 Mon Sep 17 00:00:00 2001
From: Dmitry Osipenko digetx@gmail.com Date: Wed, 5 Jun 2019 14:02:00 +0300 Subject: [PATCH 1/2] iommu/arm-smmu: Move driver registration to subsys level
On some platforms there is a dependency on the IOMMU availability that comes up early during of the boot process. One example is NVIDIA Tegra186 which uses firmware, called BPMP, which manages lots of core functions like system clocks for example. That firmware driver require IOMMU functionality and hence the driver's probing is getting deferred because the ARM's SMMU driver is probed later, thus all the drivers that depend on the BPMP availability are also getting deferred on Tegra186. Let's move SMMU driver's registration to an earlier boot stage, allowing drivers like BPMP to probe successfully without the defer.
Signed-off-by: Dmitry Osipenko digetx@gmail.com --- drivers/iommu/arm-smmu.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index 5e54cc0a28b3..08919f2fdf04 100644 --- a/drivers/iommu/arm-smmu.c +++ b/drivers/iommu/arm-smmu.c @@ -2410,4 +2410,9 @@ static struct platform_driver arm_smmu_driver = { .probe = arm_smmu_device_probe, .shutdown = arm_smmu_device_shutdown, }; -builtin_platform_driver(arm_smmu_driver); + +static int __init arm_smmu_init(void) +{ + return platform_driver_register(&arm_smmu_driver); +} +subsys_initcall(arm_smmu_init);