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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 04/08/2025 11:27, AngeloGioacchino Del Regno wrote:
> Il 04/08/25 11:16, Krzysztof Kozlowski ha scritto:
>> On 04/08/2025 10:35, Laura Nao wrote:
>>> Hi,
>>>
>>> On 8/3/25 10:17, Krzysztof Kozlowski wrote:
>>>> On 01/08/2025 15:57, Rob Herring wrote:
>>>>>> +  reg:
>>>>>> +    maxItems: 1
>>>>>> +
>>>>>> +  '#clock-cells':
>>>>>> +    const: 1
>>>>>> +
>>>>>> +  '#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.
>>>>>
>>>>> I thought this was going away based on v2 discussion?
>>>>
>>>> Yes, I asked to drop it and do not include it in v3. There was also
>>>> discussion clarifying review.
>>>>
>>>> I am really surprised that review meant nothing and code is still the same.
>>>>
>>>
>>> This has been re-submitted as-is, following the outcome of the discussion
>>> here: https://lore.kernel.org/all/242bf682-cf8f-4469-8a0b-9ec982095f04@collabora.com/
>>>
>>> We haven't found a viable alternative to the current approach so far, and
>>> the thread outlines why other options don’t apply. I'm happy to continue
>>> the discussion there if anyone has further suggestions or ideas on how
>>> to address this.
>>>
>>
>> And where is any of that resolution/new facts in the commit msg? You
>> must clearly reflect long discussions like that in the commit msg.
> 
> On that, I agree. That's a miss.
> 
>>
>> There was no objection from Chen to use clocks or power domains as I
>> requested.
> 
> Sorry Krzysztof, but now I really think that you don't understand the basics of
> MediaTek SoCs and how they're split in hardware - and I'm sorry again, but to me
> it really looks like that you're not even trying to understand it.

There is no DTS here. No diagrams or some simplified drawings to help me
understand.

> 
>> The objection was about DUPLICATING interfaces or nodes.
> 
> I don't see that duplication. The interface to each clock controller for each
> of the hardware subdomains of each controller is scattered all around the (broken
> by hardware and by concept, if you missed that in the discussion) HW Voter MMIO.
> 
> There are multiple clock controllers in the hardware.
> Each of those has its own interface to the HWV.
> 
> And there are some that require you to write to both its HWV interface and to the
> clock controller specific MMIO at the same time for the same operation. I explained
> that in the big discussion that Laura linked.

That's not what property description says. I discussed that part. Your
description says - to aggregate votes.

Above you say that control is split between two different MMIO blocks.

Aggregating votes is exactly what we discussed last time and you should
not use custom phandle for it.

Maybe it is just the name, so avoid all the confusing "votes" if this is
not voting system. If this is a voting system, then don't use custom
phandles.

Best regards,
Krzysztof