Hello Roger,

On Monday, 13 January 2025 at 19:08:43 Roger Quadros [off-list ref] wrote:

On 09/01/2025 19:52, Francesco Valla wrote:

quoted

The ti-sysc driver implements a probe deferral logic to be sure to probe
the parent interconnects before their children, postponing the probe of
interconnects not marked as "early" instances until one of these is
found.

Since the driver is alse used for the wkup_uart0 block found on the AM62

alse/also

Noted.

quoted

SoC, but not for other devices on the same platform, this logic forces
the probe for it to be artificially deferred 10 times and can lead to
the device not being probed at all. The missed probe was seen on a
BeaglePlay with the kernel configuration stripped to bare minimum and
no module support.

Add the ranges for wkup_uart0 to the list of "early" interconnect
instances, forcing the driver to skip the defer logic entirely for this
device.

Signed-off-by: Francesco Valla <redacted>
---
 drivers/bus/ti-sysc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
index f67b927ae4ca..917b7168fbd0 100644
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c

@@ -687,6 +687,8 @@ static struct resource early_bus_ranges[] = {
 	{ .start = 0x4a300000, .end = 0x4a300000 + 0x30000,  },
 	/* omap5 and dra7 l4_wkup without dra7 dcan segment */
 	{ .start = 0x4ae00000, .end = 0x4ae00000 + 0x30000,  },
+	/* am62 wkup_uart0 */
+	{ .start = 0x2b300000, .end = 0x2b300000 + 0x100000, },
 };
 
 static atomic_t sysc_defer = ATOMIC_INIT(10);

While this is probably OK for now, we need to ensure that sysc_defer_non_critical()
is not called for such devices that don't have an interconnect managed by
the sysc driver (i.e. non OMAP based systems).

Maybe this calls for a new compatible for AM62 sysc?

A new compatible would be better in my opinion, but I didn't want to introduce
too much change at once. However, if you also see it more appropriate, I'll send
a different patch set with the new compatible plus the required devicetree
modifications. 

Reviewed-by: Roger Quadros <rogerq@kernel.org>

Thank you

Kind regards,
Francesco