* Re: [PATCH] clk: ti: clkctrl: Fix failed to enable error with double udelay timeout
[not found] ` <20191010140519.GV5610@atomide.com>
@ 2019-10-24 8:00 ` Tero Kristo
0 siblings, 0 replies; 2+ messages in thread
From: Tero Kristo @ 2019-10-24 8:00 UTC (permalink / raw)
To: Tony Lindgren, Keerthy
Cc: Michael Turquette, Stephen Boyd, devicetree, linux-clk,
linux-omap
On 10/10/2019 17:05, Tony Lindgren wrote:
> * Keerthy <j-keerthy@ti.com> [191007 00:57]:
>>
>>
>> On 30/09/19 9:10 PM, Tony Lindgren wrote:
>>> Commit 3d8598fb9c5a ("clk: ti: clkctrl: use fallback udelay approach if
>>> timekeeping is suspended") added handling for cases when timekeeping is
>>> suspended. But looks like we can still get occasional "failed to enable"
>>> errors on the PM runtime resume path with udelay() returning faster than
>>> expected.
>>>
>>> With ti-sysc interconnect target module driver this leads into device
>>> failure with PM runtime failing with "failed to enable" clkctrl error.
>>>
>>> Let's fix the issue with a delay of two times the desired delay as in
>>> often done for udelay() to account for the inaccuracy.
>>
>> Tested for DS0 and rtc+ddr modes on am43 and ds0 on am33.
>>
>> Tested-by: Keerthy <j-keerthy@ti.com>
>
> Thanks for testing. This one should be applied into v5.4-rc series
> please if no more comments.
Queued up for 5.4 fixes, thanks.
-Tero
>
> Regards,
>
> Tony
>
>>> Fixes: 3d8598fb9c5a ("clk: ti: clkctrl: use fallback udelay approach if timekeeping is suspended")
>>> Cc: Keerthy <j-keerthy@ti.com>
>>> Cc: Tero Kristo <t-kristo@ti.com>
>>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>>> ---
>>> drivers/clk/ti/clkctrl.c | 5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/clk/ti/clkctrl.c b/drivers/clk/ti/clkctrl.c
>>> --- a/drivers/clk/ti/clkctrl.c
>>> +++ b/drivers/clk/ti/clkctrl.c
>>> @@ -100,11 +100,12 @@ static bool _omap4_is_timeout(union omap4_timeout *time, u32 timeout)
>>> * can be from a timer that requires pm_runtime access, which
>>> * will eventually bring us here with timekeeping_suspended,
>>> * during both suspend entry and resume paths. This happens
>>> - * at least on am43xx platform.
>>> + * at least on am43xx platform. Account for flakeyness
>>> + * with udelay() by multiplying the timeout value by 2.
>>> */
>>> if (unlikely(_early_timeout || timekeeping_suspended)) {
>>> if (time->cycles++ < timeout) {
>>> - udelay(1);
>>> + udelay(1 * 2);
>>> return false;
>>> }
>>> } else {
>>>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply [flat|nested] 2+ messages in thread