Re: [PATCH 02/13] dt-bindings: clock: qcom,sm8550-dispcc: Add display CESTA support on SM8750

[Krzysztof Kozlowski <krzk@kernel.org>]

On 22/04/2026 09:41, Krzysztof Kozlowski wrote:
> On Mon, Apr 20, 2026 at 09:58:55PM +0530, Jagadeesh Kona wrote:
>> On SM8750, a subset of DISPCC clocks is controlled by the display CESTA
>> (Client State Aggregator) hardware. These clocks can be scaled to the
>> desired frequency by sending votes to the display CRM(CESTA Resource
>> manager) instead of programming DISPCC registers directly.
> 
> This looks like completely new, vendor clock API, so no.
> 
> Resource voting or clock scaling is nothing new and you do not get a
> vendor phandle to do it. That's like basic upstreaming 101: we do not
> want another vendor re-implementation of common or typical solutions.

I'll provide a bit more context, what I am looking for:
Are CESTA and CRMC truly separate blocks? Do they have their own
resources or maybe something is shared with clock controller, e.g. parts
of address space?

If they manage clocks, they should receive some of the clocks as inputs,
because I don't imagine a block which gates clock somewhere else, to
which it has no access (IOW, that gate to manage clock is part of the
clock). Or maybe it's some shadow registers? Or display clock controller
does not have direct clock access in the first place?

Best regards,
Krzysztof