Hi Philipp, On Wed, Jul 13, 2022 at 12:32 PM Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> wrote: > On Wed, Jul 13, 2022 at 11:27:56AM +0200, Geert Uytterhoeven wrote: > [...] > > Actually I suggested handling this in the VSP driver, as VSP seems > > to be "special". > > > > > > > > [1] > > > https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220504184406.93788-1-biju.das.jz@xxxxxxxxxxxxxx/ > > So reset_control_status never actually returns 1 and the polling loop is > not necessary at all? > > If it's just the status register read that fixes things for VSP, could > it be that the deasserting register write to the reset controller > and the following register writes to VSP are not ordered somewhere at > the interconnect and the read issued to the reset controller just > guarantees that order? The udelay() also works. While the reset may be deasserted immediately (at the reset controller level), the VSP may need some additional time to settle/initialize (at the VSP level). Reset is known to work on other blocks on the same SoC, so that's why I suggested handling this in the VSP driver instead, like we already do for i2c. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
