Hello,
Le 14/02/2022 à 14:08, Tony Lindgren a écrit :
> * Tony Lindgren <tony@xxxxxxxxxxx> [220214 07:43]:
>> Looks like the following script to just toggle the module state locks
>> up things for me on beagle-x15 very fast. So yeah now I'm able to
>> reproduce the issue. Seems like the module is not ready right after
>> enabling it live we've seen for dra7 iva for example.
>
> Looks like the following patch is also needed for uarts to avoid unbind
> clock_unprepare warnings. But even with this patch dra7 uarts won't behave.
> On unbind, there will be a clock "l4per-clkctrl:0128:0: failed to disable"
> warning. Looks like after that any following clock enable does not seem to
> work and that will cause the register access errors.
>
> Looks like this is a dra7 specific issue as a similar test script on omap4
> duovero keeps on going instead.
Thanks for the help and the patch!
I removed my patch removing the quirk and applied you patch but I can still
reproduce the issue.
Do you need some info about the kernel configuration?
Best regards,
Romain
>
> Regards,
>
> Tony
>
> 8< --------------
> diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
> --- a/drivers/bus/ti-sysc.c
> +++ b/drivers/bus/ti-sysc.c
> @@ -3381,7 +3381,9 @@ static int sysc_remove(struct platform_device *pdev)
> struct sysc *ddata = platform_get_drvdata(pdev);
> int error;
>
> - cancel_delayed_work_sync(&ddata->idle_work);
> + /* Device can still be enabled, see deferred idle quirk in probe */
> + if (cancel_delayed_work_sync(&ddata->idle_work))
> + ti_sysc_idle(&ddata->idle_work.work);
>
> error = pm_runtime_resume_and_get(ddata->dev);
> if (error < 0) {
