[PATCH v2 09/29] dt-bindings: clock: mediatek: Describe MT8196 peripheral clock controllers

[AngeloGioacchino Del Regno]

Il 25/06/25 13:06, Krzysztof Kozlowski ha scritto:
> On 25/06/2025 11:45, AngeloGioacchino Del Regno wrote:
>> Il 25/06/25 10:57, Krzysztof Kozlowski ha scritto:
>>> On 25/06/2025 10:20, AngeloGioacchino Del Regno wrote:
>>>> Il 24/06/25 18:02, Krzysztof Kozlowski ha scritto:
>>>>> On 24/06/2025 16:32, Laura Nao wrote:
>>>>>> +  '#reset-cells':
>>>>>> +    const: 1
>>>>>> +    description:
>>>>>> +      Reset lines for PEXTP0/1 and UFS blocks.
>>>>>> +
>>>>>> +  mediatek,hardware-voter:
>>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>>>>> +    description:
>>>>>> +      On the MT8196 SoC, a Hardware Voter (HWV) backed by a fixed-function
>>>>>> +      MCU manages clock and power domain control across the AP and other
>>>>>> +      remote processors. By aggregating their votes, it ensures clocks are
>>>>>> +      safely enabled/disabled and power domains are active before register
>>>>>> +      access.
>>>>>
>>>>> Resource voting is not via any phandle, but either interconnects or
>>>>> required opps for power domain.
>>>>
>>>> Sorry, I'm not sure who is actually misunderstanding what, here... let me try to
>>>> explain the situation:
>>>>
>>>> This is effectively used as a syscon - as in, the clock controllers need to perform
>>>> MMIO R/W on both the clock controller itself *and* has to place a vote to the clock
>>>> controller specific HWV register.
>>>
>>> syscon is not the interface to place a vote for clocks. "clocks"
>>> property is.
>>>
>>>>
>>>> This is done for MUX-GATE and GATE clocks, other than for power domains.
>>>>
>>>> Note that the HWV system is inside of the power domains controller, and it's split
>>>> on a per hardware macro-block basis (as per usual MediaTek hardware layout...).
>>>>
>>>> The HWV, therefore, does *not* vote for clock *rates* (so, modeling OPPs would be
>>>> a software quirk, I think?), does *not* manage bandwidth (and interconnect is for
>>>> voting BW only?), and is just a "switch to flip".
>>>
>>> That's still clocks. Gate is a clock.
>>>
>>>>
>>>> Is this happening because the description has to be improved and creating some
>>>> misunderstanding, or is it because we are underestimating and/or ignoring something
>>>> here?
>>>>
>>>
>>> Other vendors, at least qcom, represent it properly - clocks. Sometimes
>>> they mix up and represent it as power domains, but that's because
>>> downstream is a mess and because we actually (at upstream) don't really
>>> know what is inside there - is it a clock or power domain.
>>>
>>
>> ....but the hardware voter cannot be represented as a clock, because you use it
>> for clocks *or* power domains (but at the same time, and of course in different
>> drivers, and in different *intertwined* registers).
> 
> BTW:
> 
> git grep mediatek,hardware-voter
> 0 results
> 
> so I do not accept explanation that you use it in different drivers. Now
> is the first time this is being upstream, so now is the time when this
> is shaped.

I was simply trying to explain how I'm using it in the current design and nothing
else; and I am happy to understand what other solution could there be for this and
if there's anything cleaner.

You see what I do, and I'm *sure* that you definitely know that my goal is *not* to
just tick yet another box, but to make things right, - and with the best possible
shape and, especially, community agreement.

Cheers,
Angelo