Message-ID: <1db77784-a59a-49bd-89b5-9e81e6d3bafc@collabora.com>
Date: Mon, 4 Aug 2025 11:27:56 +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 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.

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

> 
> And what was the resolution:
> 
> "Regarding that to be a single clock controller,"
> 
> So where is the clock controller? I still see HW voter!

"especially the mux-gate clocks can't really be put in one single clock controller
because to manage those we have to write to the HWV *and* to the clock controller
MMIO"

Clarifying that, "the clock controller" -> "each clock controller of each hardware
subdomain" (not a single clock controller, excuse my bad wording).

Regards,
Angelo

Powered by blists - more mailing lists