Re: [PATCH RFC 0/2] interconnect: qcom: sdm845: Drop the bootloader vote on ALC

[Michael Auer]

On 10/19/26 2:22 PM, Konrad Dybcio wrote:
> ALC essentially translates into "prevent DDR from sleeping to reduce
> latency", I don't know what a good framework for that func would be,
> but interconnect (even though it has the plumbing for BCMs) doesn't
> seem like it.

Thanks, that explains why the vote is so expensive in suspend.

I don't really want to add a consumer API for that.
I only want to get rid of the vote the bootloader leaves behind.

> On msm-4.9, the downstream kernel for sdm845, the driver unconditionally
> writes a (x, y) = (12, 0) on the active-only context and (0, 0) on the
> remaining ones and that seems to be the right set of values. I don't
> know how secret their meaning is, maybe +Mike can help.

That fits what I measured: the cost is the vote in the sleep set. With
the boot value kept in the wake set and 0 only in the sleep set, the
SoC also reached CX collapse.

I could only find the (12, 0) write for clients marked with
qcom,msm-bus,alc-voter (update_client_alc()), and I found no such client
in the sdm845 DTs (CAF LA.UM.7.3 and 10.3, and the OnePlus tree). Did I
miss something? If not, the only ALC write I see is the handoff removal
at late_initcall_sync, which writes 0, so downstream would end up with
ALC off, like this RFC.

Would it be acceptable for v2 to drop the dummy node and the binding
change, and instead let sdm845 list ALC as a BCM without nodes, which
icc-rpmh votes off once at probe? Or is there a better place for this?

Mike, is off the right state for ALC when nothing asks for low latency?
Or should Linux vote (12, 0) on the active-only set, the way msm_bus
does for an ALC client?

Thanks,
Michael