Re: [PATCH v3 09/27] dt-bindings: clock: mediatek: Describe MT8196 clock controllers

[Krzysztof Kozlowski <krzk@kernel.org>]

On 04/08/2025 15:58, Krzysztof Kozlowski wrote:
>>
>> So, what should we do then?
>>
>> Change it to "mediatek,clock-hw-refcounter", and adding a comment to the binding
>> saying that this is called "Hardware Voter (HWV)" in the datasheets?
>>
>> Or is using the "interconnect" property without any driver in the interconnect API
>> actually legit? - Because to me it doesn't look like being legit (and if it is, it
>> shouldn't be, as I'm sure that everyone would expect an interconnect API driver
>> when encountering an "interconnect" property in DT), and if so, we should just add
> 
> Why you would not add any interconnect driver for interconnect API?
> Look, the current phandle allows you to poke in some other MMIO space
> for the purpose of enabling the clock FOO? So interconnect or power
> domains or whatever allows you to have existing or new driver to receive
> xlate() and, when requested resources associated with clock FOO.

Something got here cut. Last sentence is supposed to be:

"So interconnect or power
domains or whatever allows you to have existing or new driver to receive
xlate() and, when requested, toggle the resources associated with clock
FOO."

> 
> Instead of the FOO clock driver poking resources, you do
> clk_prepare_enable() or pm_domain or icc_enable().

I looked now at the driver and see your clock drivers poking via regmap
to other MMIO. That's exactly usecase of syscon and exactly the pattern
*we are usually discouraging*. It's limited, non-scalable and vendor-driven.

If this was a power domain provider then:
1. Your clock drivers would only do runtime PM.
2. Your MCU would be the power domain controller doing whatever is
necessary - toggling these set/clr bits - when given clock is enabled.
And it really looks like what you described...


Best regards,
Krzysztof