[PATCH] bus: ti-sysc: mark AM62 wkup_uart0 as non deferrable

[Francesco Valla]

Hello Roger,

On Monday, 13 January 2025 at 19:08:43 Roger Quadros <rogerq at kernel.org> wrote:
> 
> On 09/01/2025 19:52, Francesco Valla wrote:
> > 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.

> > 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 <francesco at valla.it>
> > ---
> >  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 at kernel.org>
> 

Thank you

Kind regards,
Francesco