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

On 04/08/2025 11:27, AngeloGioacchino Del Regno wrote:

Il 04/08/25 11:16, Krzysztof Kozlowski ha scritto:

quoted

On 04/08/2025 10:35, Laura Nao wrote:

quoted

Hi,

On 8/3/25 10:17, Krzysztof Kozlowski wrote:

quoted

On 01/08/2025 15:57, Rob Herring wrote:

quoted

quoted

+  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/ (local)

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.

quoted

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.

quoted

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