From f71f6ff8c1f682a1cae4e8d7bdeed9d7f76b8f75 Mon Sep 17 00:00:00 2001 From: Tony Lindgren Date: Fri, 24 Nov 2023 10:50:56 +0200 Subject: bus: ti-sysc: Flush posted write only after srst_udelay Commit 34539b442b3b ("bus: ti-sysc: Flush posted write on enable before reset") caused a regression reproducable on omap4 duovero where the ISS target module can produce interconnect errors on boot. Turns out the registers are not accessible until after a delay for devices needing a ti,sysc-delay-us value. Let's fix this by flushing the posted write only after the reset delay. We do flushing also for ti,sysc-delay-us using devices as that should trigger an interconnect error if the delay is not properly configured. Let's also add some comments while at it. Fixes: 34539b442b3b ("bus: ti-sysc: Flush posted write on enable before reset") Cc: stable@vger.kernel.org Signed-off-by: Tony Lindgren --- drivers/bus/ti-sysc.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) (limited to 'drivers/bus') diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c index d57bc066dce6..9ed9239b1228 100644 --- a/drivers/bus/ti-sysc.c +++ b/drivers/bus/ti-sysc.c @@ -2158,13 +2158,23 @@ static int sysc_reset(struct sysc *ddata) sysc_val = sysc_read_sysconfig(ddata); sysc_val |= sysc_mask; sysc_write(ddata, sysc_offset, sysc_val); - /* Flush posted write */ + + /* + * Some devices need a delay before reading registers + * after reset. Presumably a srst_udelay is not needed + * for devices that use a rstctrl register reset. + */ + if (ddata->cfg.srst_udelay) + fsleep(ddata->cfg.srst_udelay); + + /* + * Flush posted write. For devices needing srst_udelay + * this should trigger an interconnect error if the + * srst_udelay value is needed but not configured. + */ sysc_val = sysc_read_sysconfig(ddata); } - if (ddata->cfg.srst_udelay) - fsleep(ddata->cfg.srst_udelay); - if (ddata->post_reset_quirk) ddata->post_reset_quirk(ddata); -- cgit v1.2.3