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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 28/04/2026 19:25, Jagadeesh Kona wrote:
> 
> 
> On 4/24/2026 2:39 PM, Krzysztof Kozlowski wrote:
>> 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?
>>
> 
> Thanks Krzysztof for your review
> 
> CRMC is sub-block within the CESTA block. CRMC block contains the clocks frequency lookup tables
> information for CESTA controlled RCGs, which clock driver needs to read and populate the RCG's
> frequency tables. DISPCC block is outside of CESTA block, so CRMC block is mapped as syscon device
> and is used in DISPCC node only to read & populate the CESTA controlled RCGs frequency lookup tables.
> The actual clock scaling is done later by converting the frequency into a perf level & sending it
> to CESTA HW via CRM APIs.

Perf levels should use proper bindings and Linux abstractions, not
custom APIs.

But what's more important, I don't get the hardware here - clocks are
fully within clock controller (DISPCC), but somehow their interface is
exposed to CESTA as well, yet CESTA is not a consumer or provider of
these clocks.

Usually the provider of some resource is in control of that resource,
e.g. clock gates or dividers. If some other block (not provider)
controls the resource, does that mean that other block is basically part
of the provider?

Well, you claim not, but how otherwise does it work?

> 
>> 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?

Heh, I basically repeated myself here... but your answer here:

>>
> 
> Yes, there are few dispcc clocks required for accessing the display CRM/CRMC register
> blocks but those clocks are already kept ON from bootloader and they will stay ON as
> long as MMCX rail is voted. So if MMCX is ON, we can access CRM/CRMC blocks.

is not really answering the problem.

Please figure out how a non-provider block can act as provider on some
other provider, without access to any of its resources.


Best regards,
Krzysztof