Re: [PATCH v2] soc: imx8m: Probe the SoC driver as platform driver

From: Marek Vasut
Date: Thu Sep 26 2024 - 17:37:02 EST


On 9/26/24 1:03 AM, Saravana Kannan wrote:
On Wed, Sep 25, 2024 at 3:06 PM Marek Vasut <marex@xxxxxxx> wrote:

With driver_async_probe=* on kernel command line, the following trace is
produced because on i.MX8M Plus hardware because the soc-imx8m.c driver
calls of_clk_get_by_name() which returns -EPROBE_DEFER because the clock
driver is not yet probed. This was not detected during regular testing
without driver_async_probe.

Convert the SoC code to platform driver and instantiate a platform device
in its current device_initcall() to probe the platform driver. Rework
.soc_revision callback to always return valid error code and return SoC
revision via parameter. This way, if anything in the .soc_revision callback
return -EPROBE_DEFER, it gets propagated to .probe and the .probe will get
retried later.

I'm assuming you tested this patch and it works?

I tested it both with and without driver_async_probe=*

Did you see any other
issues with driver_async_probe=* ?

Nope, just this one.

Does this improve your probe/boot time? Some stats on that would be nice.

It does improve the boot time from 4.5 to 2.9 seconds (measured by looking at the kernel log, so imprecise, but noticeable). With 'quiet' on kernel command line, boot time drops from 2.99s to 2.34s .

"
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1 at drivers/soc/imx/soc-imx8m.c:115 imx8mm_soc_revision+0xdc/0x180
CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-next-20240924-00002-g2062bb554dea #603
Hardware name: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3) (DT)
pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : imx8mm_soc_revision+0xdc/0x180
lr : imx8mm_soc_revision+0xd0/0x180
sp : ffff8000821fbcc0
x29: ffff8000821fbce0 x28: 0000000000000000 x27: ffff800081810120
x26: ffff8000818a9970 x25: 0000000000000006 x24: 0000000000824311
x23: ffff8000817f42c8 x22: ffff0000df8be210 x21: fffffffffffffdfb
x20: ffff800082780000 x19: 0000000000000001 x18: ffffffffffffffff
x17: ffff800081fff418 x16: ffff8000823e1000 x15: ffff0000c03b65e8
x14: ffff0000c00051b0 x13: ffff800082790000 x12: 0000000000000801
x11: ffff80008278ffff x10: ffff80008209d3a6 x9 : ffff80008062e95c
x8 : ffff8000821fb9a0 x7 : 0000000000000000 x6 : 00000000000080e3
x5 : ffff0000df8c03d8 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : fffffffffffffdfb x0 : fffffffffffffdfb
Call trace:
imx8mm_soc_revision+0xdc/0x180
imx8_soc_init+0xb0/0x1e0
do_one_initcall+0x94/0x1a8
kernel_init_freeable+0x240/0x2a8
kernel_init+0x28/0x140
ret_from_fork+0x10/0x20
---[ end trace 0000000000000000 ]---
SoC: i.MX8MP revision 1.1
"

[...]

+static struct platform_driver imx8m_soc_driver = {
+ .probe = imx8m_soc_probe,
+ .driver = {
+ .name = "imx8m-soc",
+ },
+};
+module_platform_driver(imx8m_soc_driver);

This just translates to a module_init() when compiled as a module.


+
+static int __init imx8_soc_init(void)
+{
+ struct platform_device *pdev;
+
+ pdev = platform_device_register_simple("imx8m-soc", -1, NULL, 0);
+
+ return IS_ERR(pdev) ? PTR_ERR(pdev) : 0;
+}
device_initcall(imx8_soc_init);

This also translates to a module_init() when compiled as a module.

I've never seen a module with two module_init()s and I'm pretty sure
that doesn't work. I'm guessing this driver doesn't support tristate
in its current state. But with this patch, it should work as a module
too. Why not add support for that too?

I am not entirely sure whether there are no dependencies on this soc driver, so let's start with builtin .

Why not just do both of these things in one initcall?
platform_create_bundle() doesn't work with deferred probing though. So
just do one initcall that adds the device and registers the platform
driver.

Fixed in V3.

[...]