[PATCH] pmdomain: bcm: bcm2835-power: Raise ASB poll timeout to 100us

[Florian Fainelli]

On 6/19/2026 2:57 PM, Maíra Canal wrote:
> Hi,
> 
> On 31/05/26 09:18, Maíra Canal wrote:
>> Hi Stefan,
>>
>> On 31/05/26 07:41, Stefan Wahren wrote:
>>> Hi Maíra,
>>>
>>> Am 30.05.26 um 22:46 schrieb Maíra Canal:
>>>> Commit 18605b1b936b ("pmdomain: bcm: bcm2835-power: Increase ASB 
>>>> control
>>>> timeout") raised the ASB handshake polling budget from 1us to 5us.
>>>> Surveying the pmdomain subsystem, 5us is still one of the smallest 
>>>> polling
>>>> budgets by a wide margin. Comparable handshakes in other drivers use:
>>>>
>>>>    - 100us : starfive jh71xx-pmu, apple pmgr-pwrstate
>>>>    - 1ms   : renesas rcar-sysc, rmobile-sysc (power-on)
>>>>    - 10ms  : renesas rcar-gen4-sysc, sunxi sun55i-pck600
>>>>    - 1s    : mediatek mtk-pm-domains, mtk-scpsys
>>>>
>>>> Raise the BCM2835 timeout to 100us, matching analogous drivers. 
>>>> 100us is
>>>> still negligible relative to a power-domain transition and gives the 
>>>> V3D
>>>> master ASB substantially more headroom to drain under heavy workloads,
>>>> assuring us that the timeout is enough for any scenario.
>>> tbh I'm not convinced by this explanation. Starting with a timeout 
>>> comparison across different pmdomain driver looks strange to me.
>>>
>>> My expectation that the reason for such a patch is that there is some 
>>> kind of scenario to trigger unexpected timeouts.
>>> If this is the case, please provide more information about the 
>>> scenario (specific platform, scenario, link to the bug report).
>>
>> The context: I was debugging this issue [1] and initially I had the
>> intuition that it could be related to a timeout in the ASB polling loop.
>> As I don't have access to the BCM2835 SoC datasheet (the public one
>> doesn't have PM information), I started to check other driver's
>> handshake timeout to see if ours was comparable to similar drivers. As
>> you can see, our timeout is much smaller.
>>
>> In the end, issue [1] wasn't related to the pmdomain driver, so I don't
>> have a specific scenario to trigger this issue. Even though, I sent this
>> patch considering the comparison to other drivers with the goal to be
>> conservative and use a larger timeout that could accommodate an extreme
>> scenario. However, if you believe it's unreasonable, I'm okay dropping
>> this patch.
>>
>> Ideally, it would be great to have information from Broadcom on what's
>> the largest possible time required to perform a power transition. Maybe
>> Florian could help us with that?
>>
> 
> Gentle ping, any ideas about this?

I think it's reasonable in the sense that if there is a lot of traffic 
posted on the AXI asynchronous bridge it will take longer for the 
acknowledgement to come, I asked the designers whether 100us is 
reasonable or not and will get back to you as soon as I get an answer.
-- 
Florian