Re: [PATCH 1/4] clk: qcom: dispcc-sdm845: set GENPD_FLAG_NO_STAY_ON flag for MDSS domain
From: Jagadeesh Kona
Date: Thu Apr 30 2026 - 01:51:58 EST
On 4/29/2026 8:52 PM, David Heidelberg wrote:
> On 23/02/2026 02:27, Dmitry Baryshkov wrote:
>> On Thu, Feb 19, 2026 at 11:41:06PM +0530, Jagadeesh Kona wrote:
>>>
>>>
>>> On 2/18/2026 9:28 PM, Dmitry Baryshkov wrote:
>>>> On Wed, Feb 18, 2026 at 08:49:34AM -0600, Bjorn Andersson wrote:
>>>>> On Tue, Feb 17, 2026 at 11:20:42PM +0200, Dmitry Baryshkov wrote:
>>>>>> Since the commit 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds
>>>>>> on until late_initcall_sync") setting of the display clocks is partially
>>>>>> broken. For example, when on SDM845-HDK the bootloader leaves display
>>>>>> enabled, later the kernel can't set up DSI clocks, ending up with the
>>>>>> broken display, blinking blue.
>>>>>
>>>>> This describes how the problem manifest itself. Can you please document
>>>>> why clocks are partially broken and how that relate to the GDSC state,
>>>>> and why setting GENPD_FLAG_NO_STAY_ON solves this?
>>>>
>>>> Probably the best answer (for the second part of the question): I don't
>>>> know (yet).
>>>>
>>>
>>> RCG update typically gets stuck if the new/old source is OFF while the RCG is ON; but
>>> if the RCG is already OFF, the update proceeds safely even if new/old source is OFF.
>>>
>>> A possible theory is that if the GDSC is in OFF state, the branch clocks will be OFF,
>>> due to this RCG also will be in OFF state, preventing the update stuck issue even if
>>> the new/old source is OFF. But, if the GDSC remains on until sync_state, the branches
>>> and RCG likely stays ON, leading to update stuck issue if the new/old source is OFF.
>>>
>>> Ideally, if both old and new RCG sources are ON during the update configuration, the
>>> update should succeed regardless of the GDSC status.
>>
>> Both pclkN_clk_src clocks have CLK_OPS_PARENT_ENABLE set, so the parents
>> must be on.
>
> Should this patch go in as is then?
Yes, this change keeps the display GDSC behavior similar to earlier code(i.e prior to
commit 13a4b7fb6260), so can be mainlined.
Thanks,
Jagadeesh