[PATCH v3] clk: spacemit: mark K1 pll1_d8 as critical

[Alex Elder]

On 7/7/25 9:28 AM, Yixun Lan wrote:
> Hi Alex,
> 
> On 07:19 Mon 07 Jul     , Alex Elder wrote:
>> On 6/12/25 5:48 PM, Alex Elder wrote:
>>> The pll1_d8 clock is enabled by the boot loader, and is ultimately a
>>> parent for numerous clocks, including those used by APB and AXI buses.
>>> Guodong Xu discovered that this clock got disabled while responding to
>>> getting -EPROBE_DEFER when requesting a reset controller.
>>>
>>> The needed clock (CLK_DMA, along with its parents) had already been
>>> enabled.  To respond to the probe deferral return, the CLK_DMA clock
>>> was disabled, and this led to parent clocks also reducing their enable
>>> count.  When the enable count for pll1_d8 was decremented it became 0,
>>> which caused it to be disabled.  This led to a system hang.
>>>
>>> Marking that clock critical resolves this by preventing it from being
>>> disabled.
>>>
>>> Define a new macro CCU_FACTOR_GATE_DEFINE() to allow clock flags to
>>> be supplied for a CCU_FACTOR_GATE clock.
>>
>> Is there any reason this bug fix cannot be merged?  It was
>> first posted a month ago, and although there was some initial
>> discussion that led to revisions, this version has been waiting
>> for over three weeks.
>>
> Ok, let me explain..
> 
> I've queued it at for-next but haven't sent out the "Applied" reply email,
> it should be eventually merged for version v6.17 if things goes well..
> 
> the reason that I haven't pushed it hard for fixes branch is that only DMA
> is affected for now, but DMA isn't fully activated in current mainline
> (No DT, No config merged), so I think it's fine if we target for-next..

OK, thanks for the explanation Yixun.  I've been working in the
networking subsystem for a long time and they tend to push bug
fixes out right away (once reviewed).  But you're right, this
particular bug fix does not affect any currently upstream code.

					-Alex