Message-ID: <00a12553-b248-4193-8017-22fea07ee196@collabora.com>
Date: Mon, 4 Aug 2025 15:27:07 +0200
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: Krzysztof Kozlowski <krzk@...nel.org>, Laura Nao
 <laura.nao@...labora.com>, wenst@...omium.org
Cc: conor+dt@...nel.org, devicetree@...r.kernel.org,
 guangjie.song@...iatek.com, kernel@...labora.com, krzk+dt@...nel.org,
 linux-arm-kernel@...ts.infradead.org, linux-clk@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-mediatek@...ts.infradead.org,
 matthias.bgg@...il.com, mturquette@...libre.com, netdev@...r.kernel.org,
 nfraprado@...labora.com, p.zabel@...gutronix.de, richardcochran@...il.com,
 robh@...nel.org, sboyd@...nel.org
Subject: Re: [PATCH v3 09/27] dt-bindings: clock: mediatek: Describe MT8196
 clock controllers

Il 04/08/25 13:01, Krzysztof Kozlowski ha scritto:
> 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.
> 

Yes. That is what the datasheets say, but read down there.

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

Also yes.

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

We discussed about aggregating votes, yes, in software - this instead is a
*broken* hardware that does the aggregation internally and does not require
nor want external drivers to do the aggregation.

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

Being it fundamentally *broken*, this being a voting system is what the hardware
initially wanted to be - but effectively, since it requires YOU to:
  - Make sure that power supplies are turned on, if not, turn them on by "touching"
    HW registers (so, without any assistance from the voter MCU), if any;
  - Turn on parent clocks manually, if any, before using the "voter mcu" to try
    to ungate that clock; and
    - Enable the "FENC" manually, after the mcu says that the clock was ungated.

in the current state, it is just an hardware managed refcounting system and
nothing else, because the MCU seems to be unfinished, hence, again, b r o k e n.

Note that by "manually" I always mean "with direct writes to a clock controller's
registerS, and without any automation/assistance from the HWV MCU".

We're using the "hardware-voter" name because this is how MediaTek calls it in the
datasheets, and no it doesn't really *deserve* that name for what it is exactly in
MT8196 and MT6991.

And mind you - if using the "interconnect" property for this means that we have to
add an interconnect driver for it, no, we will not do that, as placing a software
vote that votes clocks in a a voter MCU that does exactly what the interconnect
driver would do - then requiring virtual/fake clocks - is not a good solution.

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
a new "hw-interconnect" or "interconnect-hw" instead to not create confusion.

Regards,
Angelo

> 
> Best regards,
> Krzysztof

Powered by blists - more mailing lists