[PATCH v6 0/7] MT8196 GPU Frequency/Power Control Support

[PATCH v6 0/7] MT8196 GPU Frequency/Power Control Support

[Nicolas Frattaroli]

This series introduces two new drivers to accomplish controlling the
frequency and power of the Mali GPU on MediaTek MT8196 SoCs.

The reason why it's not as straightforward as with other SoCs is that
the MT8196 has quite complex glue logic in order to squeeze the maximum
amount of performance possible out of the silicon. There's an additional
MCU running a specialised firmware, which communicates with the
application processor through a mailbox and some reserved memory, and is
in charge of controlling the regulators, the PLL clocks, and the power
gating of the GPU, all while also being in charge of any DVFS control.

This set of drivers is enough to communicate desired OPP index limits to
the aforementioned MCU, referred to as "GPUEB" from here on out. The
GPUEB is still free to lower the effective frequency if the GPU has no
jobs going on at all, even when a higher OPP is set.

The power- and frequency control driver, mtk-mfg-pmdomain, is now
implemented as a power domain driver, with a set_performance_state
operation. It also exposes itself as a clock provider, so that panthor
can read the actual achieved DVFS clock rate as per the GPUEB firmware.

This power domain approach means that panthor does not need to know
about how the frequency control works on this SoC, as the OPP core
framework already takes care of it. The only exception is that panthor
needs to not register OPPs from DT itself if there already is an OPP
table present.

The mailbox driver is a fairly bog-standard common mailbox framework
driver, just specific to the firmware that runs on the GPUEB.

Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Changes in v6:
- mailbox: move buf definition into if condition, as per Chia-I Wu
- panthor: remove the redundant NULL checks in panthor_devfreq_get_freq
- mtk-mfg-pmdomain: adjust return style consistency
- mtk-mfg-pmdomain: add docstring for mtk_mfg_send_ipi to explain it's
  blocking
- mtk-mfg-pmdomain: use CMD_FIX_DUAL_TARGET_OPPIDX instead of
  CMD_FIX_TARGET_OPPIDX.
- mtk-mfg-pmdomain: reword code comments to not be in the "we" style
- mtk-mfg-pmdomain: shuffle around mbox allocations as per Angelo
- mtk-mfg-pmdomain: don't pointlessly turn on EB clock in probe,
  reducing the need for a comment explaining the bookkeeping
- mtk-mfg-pmdomain: consistently use dev_err_probe and Capitalise first
  letter of error string
- mtk-mfg-pmdomain: get rid of redundant ret = dev_err_probe assignment
- mtk-mfg-pmdomain: reintroduce stack OPP table, choose min(gpu, stack)
  when adding frequencies. Fixes gaps in OPP levels where only stack
  changed, but gpu had duplicates, which resulted in choosing a too slow
  OPP
- mtk-mfg-pmdomain: stub round_rate clk op to opt out of CCF always
  "rounding" a devfreq rate request to the current rate
- Link to v5: https://lore.kernel.org/r/20250929-mt8196-gpufreq-v5-0-3056e5ecf765@collabora.com

Changes in v5:
- mtk-mfg-pmdomain binding: add memory-regions property, remove shmem
  property, as we now correctly describe the shared memory as a regular
  memory region
- mtk-mfg-pmdomain binding: get rid of redundant |
- drop "dt-bindings: sram: Add compatible for
  mediatek,mt8196-gpufreq-sram" as part of the move to reserved memory
- mtk-mfg-pmdomain: move to using reserved-memory for GPUEB shared
  memory
- mtk-mfg-pmdomain: demote some types to smaller sizes in struct
  mtk_mfg, as per Angelo's suggestions
- mtk-mfg-pmdomain: use units.h for Hz-to-KHz
- mtk-mfg-pmdomain: change for loop in attach_dev to reduce indentation
- mtk-mfg-pmdomain: simplify return in mtk_mfg_power_off
- mtk-mfg-pmdomain: move of_device_id after probe
- mtk_mfg_pmdomain: map mmio by index
- mtk_mfg_pmdomain: add error checking to pm_genpd_init()
- mtk_mfg_pmdomain: add remove function
- mtk_mfg_pmdomain: remove last_opp member and logic, since OPP core
  already does that for us
- mtk_mfg_pmdomain: adjust comment in mtk_mfg_set_performance to explain
  why we're doing what we're doing
- mtk_mfg_pmdomain: call mtk_mfg_set_oppidx in mtk_mfg_power_on with
  the performance_state we deferred setting while it was powered off
- mtk_mfg_pmdomain: add inline function for PWR_ACK checking, as it's
  now used twice with the added remove function
- mtk-mfg-pmdomain: add suppress_bind_attrs so people don't play with
  that
- mtk-mfg-pmdomain: change KConfig from tristate to bool, as module
  unloading results in strange likely firmware-induced hardware state
  woes in the mali GPU
- mtk-mfg-pmdomain: read IPI magic in power_on, don't zero it after
  confirming that seemingly had no purpose
- mtk-mfg-pmdomain: misc style changes
- Link to v4: https://lore.kernel.org/r/20250923-mt8196-gpufreq-v4-0-6cd63ade73d6@collabora.com

Changes in v4:
- rebase onto next-20250922, which includes Laura Nao's clock patches
- refactor mediatek_mfg into a pmdomain driver called "mtk-mfg-pmdomain"
- move mt8196-gpufreq binding to the power subdirectory
- mali-valhall-csf binding: adjust for power-domains usage
- mali-valhall-csf binding: use clocks on mt8196
- mailbox: prefix defines with "GPUEB_"
- mailbox: get rid of custom of_xlate
- mailbox: rename "CLOGGED" to "BLOCKED"
- mailbox: adjust send_data comment to include more technical info
- mailbox: misc style improvements
- panthor: drop "drm/panthor: devfreq: make get_dev_status use
  get_cur_freq", as it is now not necessary and makes the code worse
- panthor: drop "drm/panthor: devfreq: add pluggable devfreq providers"
- panthor: drop "drm/panthor: add no_clocks soc_data member for MT8196",
  as we now have clocks courtesy of gpufreq
- panthor: check for existing opp table before registering a new one
- mtk-mfg-pmdomain: add turbo_below variant data, which marks OPPs below
  a certain index as turbo for the OPP subsystem
- mtk-mfg-pmdomain: no longer read stack OPPs, as they weren't used
- mtk-mfg-pmdomain: get rid of num gpu opp != num stack opp check.
  That's the firmware's problem should it ever happen, not ours
- mtk-mfg-pmdomain: some small name and whitespace changes on the defines
- Link to v3: https://lore.kernel.org/r/20250917-mt8196-gpufreq-v3-0-c4ede4b4399e@collabora.com

Changes in v3:
- mali-valhall-csf binding: get rid of clocks for MT8196, rebase onto
  Chia-I Wu's patch
- mt8196-gpufreq binding: rename hw_revision to hw-revision
- mt8196-gpufreq binding: rename clocks
- mt8196-gpufreq binding: drop pointless label in example
- mailbox binding: drop pointless label in example
- mailbox: whitespace changes on defines
- mailbox: remove rx_buf member from channel struct, use stack buffer
- mailbox: check in probe that no rx_len exceeds MBOX_MAX_RX_SIZE
- panthor: add no_clocks SoC data patch, also rebase onto Chia-I Wu's
  series
- panthor: refactor devfreq provider functionality to do allocation and
  initialisation of panthor_devfreq struct in panthor in all cases
- panthor: drop the patch that moves struct panthor_devfreq to a header
  file, as it no longer needs to be exposed to devfreq providers
- mediatek_mfg: refactor devfreq provider functionality to decouple it
  more from panthor itself
- mediatek_mfg: move SRAM magic to a #define
- mediatek_mfg: begrudgingly rename member "padding_lol" to "reserved"
- mediatek_mfg: use local struct device pointer var in more places
- mediatek_mfg: change wording of sleep command failure error message,
  but keep the format specifier because I don't want to throw bare
  errnos at users
- mediatek_mfg: remove unnecessary braces around dev_err EB power off
  timeout message
- mediatek_mfg: allocate rx_data for channels that expect a response
- mediatek_mfg: memcpy the rx buffer from the common mailbox framework
  in the rx callback to rx_data, as mssg now points to stack memory
- mediatek_mfg: make SRAM clearing message dev_dbg
- mediatek_mfg: no longer print physical address of SRAM
- mediatek_mfg: expand on the GF_REG_OPP_TABLE_STK comment, toning down
  its defeatist attitude in the process
- mediatek_mfg: style fixes in mtk_mfg_get_closest_opp_idx
- mediatek_mfg: rename clocks and hw-revision reg as per binding
- Link to v2: https://lore.kernel.org/r/20250912-mt8196-gpufreq-v2-0-779a8a3729d9@collabora.com

Changes in v2:
- mali-valhall-csf binding: move from performance-controller to
  performance-domains property
- mali-valhall-csf binding: fix vendor name oopsie in compatible of if
  condition
- mt8196-gpufreq binding: move from performance-controller to
  performance-domains by adding the cells property
- mt8196-gpufreq binding: rename e2_id to hw_revision
- mt8196-gpufreq binding: add description that mentions "MediaTek
  Flexible Graphics"
- mt8196-gpufreq binding: get rid of mailbox channels we're unlikely to
  use any time soon, if ever
- mt8196-gpufreq binding: change name of mailbox channels to use -
  instead of _
- mailbox binding: change reg-names to "data" and "ctl"
- drm/panthor: mediatek_mfg: rename e2_id to hw_revision
- drm/panthor: devfreq: switch from performance-controller to
  performance-domains
- drm/panthor: devfreq: get rid of the accidental get_cur_freq function
  move
- mailbox: rename mtk_gpueb_mbox_ch to mtk_gpueb_mbox_chan_desc
- mailbox: use smaller types in mtk_gpueb_mbox_chan_desc where possible
- mailbox: add per-channel runtime data struct
- mailbox: request one threaded IRQ per channel, pass channel struct as
  data
- mailbox: make num_channels in variant struct u8
- mailbox: get rid of no_response, as it was redundant
- mailbox: enable and disable clock in mailbox startup/shutdown
- mailbox: point con_priv of mailbox framework channel struct to this
  driver's channel struct
- mailbox: request and free the threaded IRQ in startup/shutdown
- mailbox: only clear IRQ bit flag once RX data has been read from MMIO
- mailbox: reduce needlessly large receive buffer size
- mailbox: handle allocation errors wherever they could pop up
- mailbox: style cleanups in mtk_gpueb_mbox_read_rx
- mailbox: call platform_get_irq earlier on in probe
- mailbox: set drvdata later on in probe
- mailbox: ioremap resources by index, not name
- mailbox: handle devm_mbox_controller_register errors
- mailbox: rename channels to correspond to bindings
- mailbox: document a few of the private driver structs to be kind to
  the next person who will look at this code
- Link to v1: https://lore.kernel.org/r/20250905-mt8196-gpufreq-v1-0-7b6c2d6be221@collabora.com

---
Nicolas Frattaroli (7):
      dt-bindings: gpu: mali-valhall-csf: add mediatek,mt8196-mali variant
      dt-bindings: power: Add MT8196 GPU frequency control binding
      dt-bindings: mailbox: Add MT8196 GPUEB Mailbox
      mailbox: add MediaTek GPUEB IPI mailbox
      drm/panthor: call into devfreq for current frequency
      drm/panthor: Use existing OPP table if present
      pmdomain: mediatek: Add support for MFlexGraphics

 .../bindings/gpu/arm,mali-valhall-csf.yaml         |   40 +-
 .../mailbox/mediatek,mt8196-gpueb-mbox.yaml        |   64 ++
 .../bindings/power/mediatek,mt8196-gpufreq.yaml    |  117 +++
 drivers/gpu/drm/panthor/panthor_devfreq.c          |   56 +-
 drivers/gpu/drm/panthor/panthor_devfreq.h          |    2 +
 drivers/gpu/drm/panthor/panthor_device.h           |    3 -
 drivers/gpu/drm/panthor/panthor_drv.c              |    4 +-
 drivers/mailbox/Kconfig                            |   10 +
 drivers/mailbox/Makefile                           |    2 +
 drivers/mailbox/mtk-gpueb-mailbox.c                |  319 ++++++
 drivers/pmdomain/mediatek/Kconfig                  |   16 +
 drivers/pmdomain/mediatek/Makefile                 |    1 +
 drivers/pmdomain/mediatek/mtk-mfg-pmdomain.c       | 1027 ++++++++++++++++++++
 13 files changed, 1641 insertions(+), 20 deletions(-)
---
base-commit: 4a7bcf9e0158d9976525370ff84401a1e955bbee
change-id: 20250829-mt8196-gpufreq-a7645670d182
prerequisite-message-id: <20250913002155.1163908-1-olvaffe@gmail.com>
prerequisite-patch-id: a769ebe04bd74f45a3a5b9c1d1396f4b33b7783f
prerequisite-patch-id: 9d71426f40b702e975f2a672509fcd20180ac36c

Best regards,
-- 
Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

[PATCH v6 1/7] dt-bindings: gpu: mali-valhall-csf: add mediatek,mt8196-mali variant

[Nicolas Frattaroli]

The Mali-based GPU on the MediaTek MT8196 SoC uses a separate MCU to
control the power and frequency of the GPU. This is modelled as a power
domain and clock provider.

It lets us omit the OPP tables from the device tree, as those can now be
enumerated at runtime from the MCU.

Add the necessary schema logic to handle what this SoC expects in terms
of clocks and power-domains.

Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 .../bindings/gpu/arm,mali-valhall-csf.yaml         | 40 ++++++++++++++++++++--
 1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
index 7ad5a3ffc5f5c753322eda9e74cc65de89d11c73..860691ce985e560536b6c515b82441ba6d367c46 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
@@ -45,7 +45,9 @@ properties:
     minItems: 1
     items:
       - const: core
-      - const: coregroup
+      - enum:
+          - coregroup
+          - stacks
       - const: stacks
 
   mali-supply: true
@@ -92,7 +94,6 @@ required:
   - interrupts
   - interrupt-names
   - clocks
-  - mali-supply
 
 additionalProperties: false
 
@@ -109,6 +110,29 @@ allOf:
         power-domains:
           maxItems: 1
         power-domain-names: false
+      required:
+        - mali-supply
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: mediatek,mt8196-mali
+    then:
+      properties:
+        mali-supply: false
+        sram-supply: false
+        operating-points-v2: false
+        power-domains:
+          maxItems: 1
+        power-domain-names: false
+        clocks:
+          maxItems: 2
+        clock-names:
+          items:
+            - const: core
+            - const: stacks
+      required:
+        - power-domains
 
 examples:
   - |
@@ -144,5 +168,17 @@ examples:
             };
         };
     };
+  - |
+    gpu@48000000 {
+        compatible = "mediatek,mt8196-mali", "arm,mali-valhall-csf";
+        reg = <0x48000000 0x480000>;
+        clocks = <&gpufreq 0>, <&gpufreq 1>;
+        clock-names = "core", "stacks";
+        interrupts = <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH 0>,
+                     <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH 0>,
+                     <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH 0>;
+        interrupt-names = "job", "mmu", "gpu";
+        power-domains = <&gpufreq>;
+    };
 
 ...

-- 
2.51.0

[PATCH v6 2/7] dt-bindings: power: Add MT8196 GPU frequency control binding

[Nicolas Frattaroli]

On the MT8196 and MT6991 SoCs, the GPU power and frequency is controlled
by some integration logic, referred to as "MFlexGraphics" by MediaTek,
which comes in the form of an embedded controller running
special-purpose firmware.

This controller takes care of the regulators and PLL clock frequencies
to squeeze the maximum amount of power out of the silicon.

Add a binding which models it as a power domain.

Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 .../bindings/power/mediatek,mt8196-gpufreq.yaml    | 117 +++++++++++++++++++++
 1 file changed, 117 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/mediatek,mt8196-gpufreq.yaml b/Documentation/devicetree/bindings/power/mediatek,mt8196-gpufreq.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..b9e43abaf8a42ce981ce16648fb3350b9c262015
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/mediatek,mt8196-gpufreq.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/mediatek,mt8196-gpufreq.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MFlexGraphics Power and Frequency Controller
+
+maintainers:
+  - Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
+
+description:
+  A special-purpose embedded MCU to control power and frequency of GPU devices
+  using MediaTek Flexible Graphics integration hardware.
+
+properties:
+  $nodename:
+    pattern: '^power-controller@[a-f0-9]+$'
+
+  compatible:
+    enum:
+      - mediatek,mt8196-gpufreq
+
+  reg:
+    items:
+      - description: GPR memory area
+      - description: RPC memory area
+      - description: SoC variant ID register
+
+  reg-names:
+    items:
+      - const: gpr
+      - const: rpc
+      - const: hw-revision
+
+  clocks:
+    items:
+      - description: main clock of the embedded controller (EB)
+      - description: core PLL
+      - description: stack 0 PLL
+      - description: stack 1 PLL
+
+  clock-names:
+    items:
+      - const: eb
+      - const: core
+      - const: stack0
+      - const: stack1
+
+  mboxes:
+    items:
+      - description: FastDVFS events
+      - description: frequency control
+      - description: sleep control
+      - description: timer control
+      - description: frequency hopping control
+      - description: hardware voter control
+      - description: FastDVFS control
+
+  mbox-names:
+    items:
+      - const: fast-dvfs-event
+      - const: gpufreq
+      - const: sleep
+      - const: timer
+      - const: fhctl
+      - const: ccf
+      - const: fast-dvfs
+
+  memory-region:
+    items:
+      - description: phandle to the GPUEB shared memory
+
+  "#clock-cells":
+    const: 1
+
+  "#power-domain-cells":
+    const: 0
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - clock-names
+  - mboxes
+  - mbox-names
+  - memory-region
+  - "#clock-cells"
+  - "#power-domain-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mediatek,mt8196-clock.h>
+
+    power-controller@4b09fd00 {
+        compatible = "mediatek,mt8196-gpufreq";
+        reg = <0x4b09fd00 0x80>,
+              <0x4b800000 0x1000>,
+              <0x4b860128 0x4>;
+        reg-names = "gpr", "rpc", "hw-revision";
+        clocks = <&topckgen CLK_TOP_MFG_EB>,
+                 <&mfgpll CLK_MFG_AO_MFGPLL>,
+                 <&mfgpll_sc0 CLK_MFGSC0_AO_MFGPLL_SC0>,
+                 <&mfgpll_sc1 CLK_MFGSC1_AO_MFGPLL_SC1>;
+        clock-names = "eb", "core", "stack0", "stack1";
+        mboxes = <&gpueb_mbox 0>, <&gpueb_mbox 1>, <&gpueb_mbox 2>,
+                 <&gpueb_mbox 3>, <&gpueb_mbox 4>, <&gpueb_mbox 5>,
+                 <&gpueb_mbox 7>;
+        mbox-names = "fast-dvfs-event", "gpufreq", "sleep", "timer", "fhctl",
+                     "ccf", "fast-dvfs";
+        memory-region = <&gpueb_shared_memory>;
+        #clock-cells = <1>;
+        #power-domain-cells = <0>;
+    };

-- 
2.51.0

[PATCH v6 3/7] dt-bindings: mailbox: Add MT8196 GPUEB Mailbox

[Nicolas Frattaroli]

The MediaTek MT8196 SoC includes an embedded MCU referred to as "GPUEB",
acting as glue logic to control power and frequency of the Mali GPU.
This MCU runs special-purpose firmware for this use, and the main
application processor communicates with it through a mailbox.

Add a binding that describes this mailbox.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 .../mailbox/mediatek,mt8196-gpueb-mbox.yaml        | 64 ++++++++++++++++++++++
 1 file changed, 64 insertions(+)

diff --git a/Documentation/devicetree/bindings/mailbox/mediatek,mt8196-gpueb-mbox.yaml b/Documentation/devicetree/bindings/mailbox/mediatek,mt8196-gpueb-mbox.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..ab5b780cb83a708a3897ca1a440131d97b56c3a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/mediatek,mt8196-gpueb-mbox.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/mediatek,mt8196-gpueb-mbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MFlexGraphics GPUEB Mailbox Controller
+
+maintainers:
+  - Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
+
+properties:
+  compatible:
+    enum:
+      - mediatek,mt8196-gpueb-mbox
+
+  reg:
+    items:
+      - description: mailbox data registers
+      - description: mailbox control registers
+
+  reg-names:
+    items:
+      - const: data
+      - const: ctl
+
+  clocks:
+    items:
+      - description: main clock of the GPUEB MCU
+
+  interrupts:
+    items:
+      - description: fires when a new message is received
+
+  "#mbox-cells":
+    const: 1
+    description:
+      The number of the mailbox channel.
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - interrupts
+  - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mediatek,mt8196-clock.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    mailbox@4b09fd80 {
+        compatible = "mediatek,mt8196-gpueb-mbox";
+        reg = <0x4b09fd80 0x280>,
+              <0x4b170000 0x7c>;
+        reg-names = "data", "ctl";
+        clocks = <&topckgen CLK_TOP_MFG_EB>;
+        interrupts = <GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH 0>;
+        #mbox-cells = <1>;
+    };

-- 
2.51.0

[PATCH v6 4/7] mailbox: add MediaTek GPUEB IPI mailbox

[Nicolas Frattaroli]

The MT8196 SoC uses an embedded MCU to control frequencies and power of
the GPU. This controller is referred to as "GPUEB".

It communicates to the application processor, among other ways, through
a mailbox.

The mailbox exposes one interrupt, which appears to only be fired when a
response is received, rather than a transaction is completed. For us,
this means we unfortunately need to poll for txdone.

The mailbox also requires the EB clock to be on when touching any of the
mailbox registers.

Add a simple driver for it based on the common mailbox framework.

Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 drivers/mailbox/Kconfig             |  10 ++
 drivers/mailbox/Makefile            |   2 +
 drivers/mailbox/mtk-gpueb-mailbox.c | 319 ++++++++++++++++++++++++++++++++++++
 3 files changed, 331 insertions(+)

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index c488725aa2a5d4b079c3284acc2d0e143c5ab08d..29f16f220384fc23fc735f827415f30f5cedb888 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -294,6 +294,16 @@ config MTK_CMDQ_MBOX
 	  critical time limitation, such as updating display configuration
 	  during the vblank.
 
+config MTK_GPUEB_MBOX
+	tristate "MediaTek GPUEB Mailbox Support"
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	help
+	  The MediaTek GPUEB mailbox is used to communicate with the embedded
+	  controller in charge of GPU frequency and power management on some
+	  MediaTek SoCs, such as the MT8196.
+	  Say Y or m here if you want to support the MT8196 SoC in your kernel
+	  build.
+
 config ZYNQMP_IPI_MBOX
 	tristate "Xilinx ZynqMP IPI Mailbox"
 	depends on ARCH_ZYNQMP && OF
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index f9a11f5639aaf0faab254584ab23f00146ba7aa0..81820a4f55285580dcc4acdc713a50d94d6f16c0 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -63,6 +63,8 @@ obj-$(CONFIG_MTK_ADSP_MBOX)	+= mtk-adsp-mailbox.o
 
 obj-$(CONFIG_MTK_CMDQ_MBOX)	+= mtk-cmdq-mailbox.o
 
+obj-$(CONFIG_MTK_GPUEB_MBOX)	+= mtk-gpueb-mailbox.o
+
 obj-$(CONFIG_ZYNQMP_IPI_MBOX)	+= zynqmp-ipi-mailbox.o
 
 obj-$(CONFIG_SUN6I_MSGBOX)	+= sun6i-msgbox.o
diff --git a/drivers/mailbox/mtk-gpueb-mailbox.c b/drivers/mailbox/mtk-gpueb-mailbox.c
new file mode 100644
index 0000000000000000000000000000000000000000..925bcf21f650decdb6abd4c07e61b72bc6c3c94e
--- /dev/null
+++ b/drivers/mailbox/mtk-gpueb-mailbox.c
@@ -0,0 +1,319 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * MediaTek GPUEB mailbox driver for SoCs such as the MT8196
+ *
+ * Copyright (C) 2025, Collabora Ltd.
+ *
+ * Developers harmed in the making of this driver:
+ *  - Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
+ */
+
+#include <linux/atomic.h>
+#include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#define GPUEB_MBOX_CTL_TX_STS		0x00
+#define GPUEB_MBOX_CTL_IRQ_SET		0x04
+#define GPUEB_MBOX_CTL_IRQ_CLR		0x74
+#define GPUEB_MBOX_CTL_RX_STS		0x78
+
+#define GPUEB_MBOX_FULL			BIT(0) /* i.e. we've received data */
+#define GPUEB_MBOX_BLOCKED		BIT(1) /* i.e. the channel is shutdown */
+
+#define GPUEB_MBOX_MAX_RX_SIZE		32 /* in bytes */
+
+struct mtk_gpueb_mbox {
+	struct device *dev;
+	struct clk *clk;
+	void __iomem *mbox_mmio;
+	void __iomem *mbox_ctl;
+	struct mbox_controller mbox;
+	struct mtk_gpueb_mbox_chan *ch;
+	int irq;
+	const struct mtk_gpueb_mbox_variant *v;
+};
+
+/**
+ * struct mtk_gpueb_mbox_chan - per-channel runtime data
+ * @ebm: pointer to the parent &struct mtk_gpueb_mbox mailbox
+ * @full_name: descriptive name of channel for IRQ subsystem
+ * @num: channel number, starting at 0
+ * @rx_status: signifies whether channel reception is turned off, or full
+ * @c: pointer to the constant &struct mtk_gpueb_mbox_chan_desc channel data
+ */
+struct mtk_gpueb_mbox_chan {
+	struct mtk_gpueb_mbox *ebm;
+	char *full_name;
+	u8 num;
+	atomic_t rx_status;
+	const struct mtk_gpueb_mbox_chan_desc *c;
+};
+
+/**
+ * struct mtk_gpueb_mbox_chan_desc - per-channel constant data
+ * @name: name of this channel
+ * @num: index of this channel, starting at 0
+ * @tx_offset: byte offset measured from mmio base for outgoing data
+ * @tx_len: size, in bytes, of the outgoing data on this channel
+ * @rx_offset: bytes offset measured from mmio base for incoming data
+ * @rx_len: size, in bytes, of the incoming data on this channel
+ */
+struct mtk_gpueb_mbox_chan_desc {
+	const char *name;
+	const u8 num;
+	const u16 tx_offset;
+	const u8 tx_len;
+	const u16 rx_offset;
+	const u8 rx_len;
+};
+
+struct mtk_gpueb_mbox_variant {
+	const u8 num_channels;
+	const struct mtk_gpueb_mbox_chan_desc channels[] __counted_by(num_channels);
+};
+
+/**
+ * mtk_gpueb_mbox_read_rx - read RX buffer from MMIO into channel's RX buffer
+ * @buf: buffer to read into
+ * @chan: pointer to the channel to read
+ */
+static void mtk_gpueb_mbox_read_rx(void *buf, struct mtk_gpueb_mbox_chan *chan)
+{
+	memcpy_fromio(buf, chan->ebm->mbox_mmio + chan->c->rx_offset, chan->c->rx_len);
+}
+
+static irqreturn_t mtk_gpueb_mbox_isr(int irq, void *data)
+{
+	struct mtk_gpueb_mbox_chan *ch = data;
+	u32 rx_sts;
+
+	rx_sts = readl(ch->ebm->mbox_ctl + GPUEB_MBOX_CTL_RX_STS);
+
+	if (rx_sts & BIT(ch->num)) {
+		if (!atomic_cmpxchg(&ch->rx_status, 0, GPUEB_MBOX_FULL | GPUEB_MBOX_BLOCKED))
+			return IRQ_WAKE_THREAD;
+	}
+
+	return IRQ_NONE;
+}
+
+static irqreturn_t mtk_gpueb_mbox_thread(int irq, void *data)
+{
+	struct mtk_gpueb_mbox_chan *ch = data;
+	int status;
+
+	status = atomic_cmpxchg(&ch->rx_status, GPUEB_MBOX_FULL | GPUEB_MBOX_BLOCKED,
+				GPUEB_MBOX_FULL);
+	if (status == (GPUEB_MBOX_FULL | GPUEB_MBOX_BLOCKED)) {
+		u8 buf[GPUEB_MBOX_MAX_RX_SIZE] = {};
+
+		mtk_gpueb_mbox_read_rx(buf, ch);
+		writel(BIT(ch->num), ch->ebm->mbox_ctl + GPUEB_MBOX_CTL_IRQ_CLR);
+		mbox_chan_received_data(&ch->ebm->mbox.chans[ch->num], buf);
+		atomic_set(&ch->rx_status, 0);
+		return IRQ_HANDLED;
+	}
+
+	return IRQ_NONE;
+}
+
+static int mtk_gpueb_mbox_send_data(struct mbox_chan *chan, void *data)
+{
+	struct mtk_gpueb_mbox_chan *ch = chan->con_priv;
+	u32 *values = data;
+	int i;
+
+	if (atomic_read(&ch->rx_status))
+		return -EBUSY;
+
+	/*
+	 * We don't want any fancy nonsense, just write the 32-bit values in
+	 * order. memcpy_toio/__iowrite32_copy don't work here, as they may use
+	 * writes of different sizes or memory ordering characteristics depending
+	 * on the architecture, alignment and the current phase of the moon.
+	 */
+	for (i = 0; i < ch->c->tx_len; i += 4)
+		writel(values[i / 4], ch->ebm->mbox_mmio + ch->c->tx_offset + i);
+
+	writel(BIT(ch->num), ch->ebm->mbox_ctl + GPUEB_MBOX_CTL_IRQ_SET);
+
+	return 0;
+}
+
+static int mtk_gpueb_mbox_startup(struct mbox_chan *chan)
+{
+	struct mtk_gpueb_mbox_chan *ch = chan->con_priv;
+	int ret;
+
+	atomic_set(&ch->rx_status, 0);
+
+	ret = clk_enable(ch->ebm->clk);
+	if (ret) {
+		dev_err(ch->ebm->dev, "Failed to enable EB clock: %pe\n",
+			ERR_PTR(ret));
+		goto err_block;
+	}
+
+	writel(BIT(ch->num), ch->ebm->mbox_ctl + GPUEB_MBOX_CTL_IRQ_CLR);
+
+	ret = devm_request_threaded_irq(ch->ebm->dev, ch->ebm->irq, mtk_gpueb_mbox_isr,
+					mtk_gpueb_mbox_thread, IRQF_SHARED | IRQF_ONESHOT,
+					ch->full_name, ch);
+	if (ret) {
+		dev_err(ch->ebm->dev, "Failed to request IRQ: %pe\n",
+			ERR_PTR(ret));
+		goto err_unclk;
+	}
+
+	return 0;
+
+err_unclk:
+	clk_disable(ch->ebm->clk);
+err_block:
+	atomic_set(&ch->rx_status, GPUEB_MBOX_BLOCKED);
+
+	return ret;
+}
+
+static void mtk_gpueb_mbox_shutdown(struct mbox_chan *chan)
+{
+	struct mtk_gpueb_mbox_chan *ch = chan->con_priv;
+
+	atomic_set(&ch->rx_status, GPUEB_MBOX_BLOCKED);
+
+	devm_free_irq(ch->ebm->dev, ch->ebm->irq, ch);
+
+	clk_disable(ch->ebm->clk);
+}
+
+static bool mtk_gpueb_mbox_last_tx_done(struct mbox_chan *chan)
+{
+	struct mtk_gpueb_mbox_chan *ch = chan->con_priv;
+
+	return !(readl(ch->ebm->mbox_ctl + GPUEB_MBOX_CTL_TX_STS) & BIT(ch->num));
+}
+
+const struct mbox_chan_ops mtk_gpueb_mbox_ops = {
+	.send_data = mtk_gpueb_mbox_send_data,
+	.startup = mtk_gpueb_mbox_startup,
+	.shutdown = mtk_gpueb_mbox_shutdown,
+	.last_tx_done = mtk_gpueb_mbox_last_tx_done,
+};
+
+static int mtk_gpueb_mbox_probe(struct platform_device *pdev)
+{
+	struct mtk_gpueb_mbox_chan *ch;
+	struct mtk_gpueb_mbox *ebm;
+	unsigned int i;
+
+	ebm = devm_kzalloc(&pdev->dev, sizeof(*ebm), GFP_KERNEL);
+	if (!ebm)
+		return -ENOMEM;
+
+	ebm->dev = &pdev->dev;
+	ebm->v = of_device_get_match_data(ebm->dev);
+
+	ebm->irq = platform_get_irq(pdev, 0);
+	if (ebm->irq < 0)
+		return ebm->irq;
+
+	ebm->clk = devm_clk_get_prepared(ebm->dev, NULL);
+	if (IS_ERR(ebm->clk))
+		return dev_err_probe(ebm->dev, PTR_ERR(ebm->clk),
+				     "Failed to get 'eb' clock\n");
+
+	ebm->mbox_mmio = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(ebm->mbox_mmio))
+		return dev_err_probe(ebm->dev, PTR_ERR(ebm->mbox_mmio),
+				     "Couldn't map mailbox data registers\n");
+
+	ebm->mbox_ctl = devm_platform_ioremap_resource(pdev, 1);
+	if (IS_ERR(ebm->mbox_ctl))
+		return dev_err_probe(
+			ebm->dev, PTR_ERR(ebm->mbox_ctl),
+			"Couldn't map mailbox control registers\n");
+
+	ebm->ch = devm_kmalloc_array(ebm->dev, ebm->v->num_channels,
+				     sizeof(*ebm->ch), GFP_KERNEL);
+	if (!ebm->ch)
+		return -ENOMEM;
+
+	ebm->mbox.chans = devm_kcalloc(ebm->dev, ebm->v->num_channels,
+				       sizeof(struct mbox_chan), GFP_KERNEL);
+	if (!ebm->mbox.chans)
+		return -ENOMEM;
+
+	for (i = 0; i < ebm->v->num_channels; i++) {
+		ch = &ebm->ch[i];
+		ch->c = &ebm->v->channels[i];
+		if (ch->c->rx_len > GPUEB_MBOX_MAX_RX_SIZE) {
+			dev_err(ebm->dev, "Channel %s RX size (%d) too large\n",
+				ch->c->name, ch->c->rx_len);
+			return -EINVAL;
+		}
+		ch->full_name = devm_kasprintf(ebm->dev, GFP_KERNEL, "%s:%s",
+					       dev_name(ebm->dev), ch->c->name);
+		if (!ch->full_name)
+			return -ENOMEM;
+
+		ch->ebm = ebm;
+		ch->num = i;
+		spin_lock_init(&ebm->mbox.chans[i].lock);
+		ebm->mbox.chans[i].con_priv = ch;
+		atomic_set(&ch->rx_status, GPUEB_MBOX_BLOCKED);
+	}
+
+	ebm->mbox.dev = ebm->dev;
+	ebm->mbox.num_chans = ebm->v->num_channels;
+	ebm->mbox.txdone_poll = true;
+	ebm->mbox.txpoll_period = 0; /* minimum hrtimer interval */
+	ebm->mbox.ops = &mtk_gpueb_mbox_ops;
+
+	dev_set_drvdata(ebm->dev, ebm);
+
+	return devm_mbox_controller_register(ebm->dev, &ebm->mbox);
+}
+
+static const struct mtk_gpueb_mbox_variant mtk_gpueb_mbox_mt8196 = {
+	.num_channels = 12,
+	.channels = {
+		{ "fast-dvfs-event", 0, 0x0000, 16, 0x00e0, 16 },
+		{ "gpufreq",         1, 0x0010, 32, 0x00f0, 32 },
+		{ "sleep",           2, 0x0030, 12, 0x0110,  4 },
+		{ "timer",           3, 0x003c, 24, 0x0114,  4 },
+		{ "fhctl",           4, 0x0054, 36, 0x0118,  4 },
+		{ "ccf",             5, 0x0078, 16, 0x011c, 16 },
+		{ "gpumpu",          6, 0x0088, 24, 0x012c,  4 },
+		{ "fast-dvfs",       7, 0x00a0, 24, 0x0130, 24 },
+		{ "ipir-c-met",      8, 0x00b8,  4, 0x0148, 16 },
+		{ "ipis-c-met",      9, 0x00bc, 16, 0x0158,  4 },
+		{ "brisket",        10, 0x00cc, 16, 0x015c, 16 },
+		{ "ppb",            11, 0x00dc,  4, 0x016c,  4 },
+	},
+};
+
+static const struct of_device_id mtk_gpueb_mbox_of_ids[] = {
+	{ .compatible = "mediatek,mt8196-gpueb-mbox", .data = &mtk_gpueb_mbox_mt8196 },
+	{ /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mtk_gpueb_mbox_of_ids);
+
+static struct platform_driver mtk_gpueb_mbox_drv = {
+	.probe = mtk_gpueb_mbox_probe,
+	.driver = {
+		.name = "mtk-gpueb-mbox",
+		.of_match_table = mtk_gpueb_mbox_of_ids,
+	}
+};
+module_platform_driver(mtk_gpueb_mbox_drv);
+
+MODULE_AUTHOR("Nicolas Frattaroli <nicolas.frattaroli@collabora.com>");
+MODULE_DESCRIPTION("MediaTek GPUEB mailbox driver");
+MODULE_LICENSE("GPL");

-- 
2.51.0

[PATCH v6 5/7] drm/panthor: call into devfreq for current frequency

[Nicolas Frattaroli]

As it stands, panthor keeps a cached current frequency value for when it
wants to retrieve it. This doesn't work well for when things might
switch frequency without panthor's knowledge.

Instead, implement the get_cur_freq operation, and expose it through a
helper function to the rest of panthor.

Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 drivers/gpu/drm/panthor/panthor_devfreq.c | 30 ++++++++++++++++++++++++++----
 drivers/gpu/drm/panthor/panthor_devfreq.h |  2 ++
 drivers/gpu/drm/panthor/panthor_device.h  |  3 ---
 drivers/gpu/drm/panthor/panthor_drv.c     |  4 +++-
 4 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/panthor/panthor_devfreq.c b/drivers/gpu/drm/panthor/panthor_devfreq.c
index 3686515d368db5bb329f4858d4a7247a4957cc24..978f193a2aee561fadd9a976e9b1417118260889 100644
--- a/drivers/gpu/drm/panthor/panthor_devfreq.c
+++ b/drivers/gpu/drm/panthor/panthor_devfreq.c
@@ -62,7 +62,6 @@ static void panthor_devfreq_update_utilization(struct panthor_devfreq *pdevfreq)
 static int panthor_devfreq_target(struct device *dev, unsigned long *freq,
 				  u32 flags)
 {
-	struct panthor_device *ptdev = dev_get_drvdata(dev);
 	struct dev_pm_opp *opp;
 	int err;
 
@@ -72,8 +71,6 @@ static int panthor_devfreq_target(struct device *dev, unsigned long *freq,
 	dev_pm_opp_put(opp);
 
 	err = dev_pm_opp_set_rate(dev, *freq);
-	if (!err)
-		ptdev->current_frequency = *freq;
 
 	return err;
 }
@@ -115,11 +112,21 @@ static int panthor_devfreq_get_dev_status(struct device *dev,
 	return 0;
 }
 
+static int panthor_devfreq_get_cur_freq(struct device *dev, unsigned long *freq)
+{
+	struct panthor_device *ptdev = dev_get_drvdata(dev);
+
+	*freq = clk_get_rate(ptdev->clks.core);
+
+	return 0;
+}
+
 static struct devfreq_dev_profile panthor_devfreq_profile = {
 	.timer = DEVFREQ_TIMER_DELAYED,
 	.polling_ms = 50, /* ~3 frames */
 	.target = panthor_devfreq_target,
 	.get_dev_status = panthor_devfreq_get_dev_status,
+	.get_cur_freq = panthor_devfreq_get_cur_freq,
 };
 
 int panthor_devfreq_init(struct panthor_device *ptdev)
@@ -198,7 +205,6 @@ int panthor_devfreq_init(struct panthor_device *ptdev)
 		return PTR_ERR(opp);
 
 	panthor_devfreq_profile.initial_freq = cur_freq;
-	ptdev->current_frequency = cur_freq;
 
 	/*
 	 * Set the recommend OPP this will enable and configure the regulator
@@ -296,3 +302,19 @@ void panthor_devfreq_record_idle(struct panthor_device *ptdev)
 
 	spin_unlock_irqrestore(&pdevfreq->lock, irqflags);
 }
+
+unsigned long panthor_devfreq_get_freq(struct panthor_device *ptdev)
+{
+	struct panthor_devfreq *pdevfreq = ptdev->devfreq;
+	unsigned long freq = 0;
+	int ret;
+
+	if (!pdevfreq->devfreq)
+		return 0;
+
+	ret = pdevfreq->devfreq->profile->get_cur_freq(ptdev->base.dev, &freq);
+	if (ret)
+		return 0;
+
+	return freq;
+}
diff --git a/drivers/gpu/drm/panthor/panthor_devfreq.h b/drivers/gpu/drm/panthor/panthor_devfreq.h
index b7631de695f7d79456478c87e8af5dc47673cd1d..f8e29e02f66cb3281ed4bb4c75cda9bd4df82b92 100644
--- a/drivers/gpu/drm/panthor/panthor_devfreq.h
+++ b/drivers/gpu/drm/panthor/panthor_devfreq.h
@@ -18,4 +18,6 @@ void panthor_devfreq_suspend(struct panthor_device *ptdev);
 void panthor_devfreq_record_busy(struct panthor_device *ptdev);
 void panthor_devfreq_record_idle(struct panthor_device *ptdev);
 
+unsigned long panthor_devfreq_get_freq(struct panthor_device *ptdev);
+
 #endif /* __PANTHOR_DEVFREQ_H__ */
diff --git a/drivers/gpu/drm/panthor/panthor_device.h b/drivers/gpu/drm/panthor/panthor_device.h
index 9f0649ecfc4fc697a21a8b2fc4dd89c8ecf298df..f32c1868bf6d782d99df9dbd0babcea049c917e0 100644
--- a/drivers/gpu/drm/panthor/panthor_device.h
+++ b/drivers/gpu/drm/panthor/panthor_device.h
@@ -214,9 +214,6 @@ struct panthor_device {
 	/** @profile_mask: User-set profiling flags for job accounting. */
 	u32 profile_mask;
 
-	/** @current_frequency: Device clock frequency at present. Set by DVFS*/
-	unsigned long current_frequency;
-
 	/** @fast_rate: Maximum device clock frequency. Set by DVFS */
 	unsigned long fast_rate;
 
diff --git a/drivers/gpu/drm/panthor/panthor_drv.c b/drivers/gpu/drm/panthor/panthor_drv.c
index ea4a37b566a8b215f2b7a09c333a696f1dcdb58f..4d59d94c353c3ca76f4b98a411c8f8284efafd08 100644
--- a/drivers/gpu/drm/panthor/panthor_drv.c
+++ b/drivers/gpu/drm/panthor/panthor_drv.c
@@ -25,6 +25,7 @@
 #include <drm/gpu_scheduler.h>
 #include <drm/panthor_drm.h>
 
+#include "panthor_devfreq.h"
 #include "panthor_device.h"
 #include "panthor_fw.h"
 #include "panthor_gem.h"
@@ -1519,7 +1520,8 @@ static void panthor_gpu_show_fdinfo(struct panthor_device *ptdev,
 		drm_printf(p, "drm-cycles-panthor:\t%llu\n", pfile->stats.cycles);
 
 	drm_printf(p, "drm-maxfreq-panthor:\t%lu Hz\n", ptdev->fast_rate);
-	drm_printf(p, "drm-curfreq-panthor:\t%lu Hz\n", ptdev->current_frequency);
+	drm_printf(p, "drm-curfreq-panthor:\t%lu Hz\n",
+		   panthor_devfreq_get_freq(ptdev));
 }
 
 static void panthor_show_internal_memory_stats(struct drm_printer *p, struct drm_file *file)

-- 
2.51.0

[PATCH v6 6/7] drm/panthor: Use existing OPP table if present

[Nicolas Frattaroli]

On SoCs where the GPU's power-domain is in charge of setting performance
levels, the OPP table of the GPU node will have already been populated
during said power-domain's attach_dev operation.

To avoid initialising an OPP table twice, only set the OPP regulator and
the OPPs from DT if there's no OPP table present.

Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 drivers/gpu/drm/panthor/panthor_devfreq.c | 26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/panthor/panthor_devfreq.c b/drivers/gpu/drm/panthor/panthor_devfreq.c
index 978f193a2aee561fadd9a976e9b1417118260889..6beb6170d6eea3dd65880dfe64a61abbdd5f08da 100644
--- a/drivers/gpu/drm/panthor/panthor_devfreq.c
+++ b/drivers/gpu/drm/panthor/panthor_devfreq.c
@@ -143,6 +143,7 @@ int panthor_devfreq_init(struct panthor_device *ptdev)
 	struct panthor_devfreq *pdevfreq;
 	struct dev_pm_opp *opp;
 	unsigned long cur_freq;
+	struct opp_table *t;
 	unsigned long freq = ULONG_MAX;
 	int ret;
 
@@ -152,18 +153,23 @@ int panthor_devfreq_init(struct panthor_device *ptdev)
 
 	ptdev->devfreq = pdevfreq;
 
-	ret = devm_pm_opp_set_regulators(dev, reg_names);
-	if (ret) {
-		if (ret != -EPROBE_DEFER)
-			DRM_DEV_ERROR(dev, "Couldn't set OPP regulators\n");
-
-		return ret;
+	t = dev_pm_opp_get_opp_table(dev);
+	if (IS_ERR_OR_NULL(t)) {
+		ret = devm_pm_opp_set_regulators(dev, reg_names);
+		if (ret) {
+			if (ret != -EPROBE_DEFER)
+				DRM_DEV_ERROR(dev, "Couldn't set OPP regulators\n");
+
+			return ret;
+		}
+
+		ret = devm_pm_opp_of_add_table(dev);
+		if (ret)
+			return ret;
+	} else {
+		dev_pm_opp_put_opp_table(t);
 	}
 
-	ret = devm_pm_opp_of_add_table(dev);
-	if (ret)
-		return ret;
-
 	spin_lock_init(&pdevfreq->lock);
 
 	panthor_devfreq_reset(pdevfreq);

-- 
2.51.0

[PATCH v6 7/7] pmdomain: mediatek: Add support for MFlexGraphics

[Nicolas Frattaroli]

Various MediaTek SoCs use GPU integration silicon named "MFlexGraphics"
by MediaTek. On the MT8196 and MT6991 SoCs, interacting with this
integration silicon is required to power on the GPU.

This glue silicon is in the form of an embedded microcontroller running
special-purpose firmware, which autonomously adjusts clocks and
regulators.

Implement a driver, modelled as a pmdomain driver with a
set_performance_state operation, to support these SoCs.

The driver also exposes the actual achieved clock rate, as read back
from the MCU, as common clock framework clocks, by acting as a clock
provider as well.

Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 drivers/pmdomain/mediatek/Kconfig            |   16 +
 drivers/pmdomain/mediatek/Makefile           |    1 +
 drivers/pmdomain/mediatek/mtk-mfg-pmdomain.c | 1027 ++++++++++++++++++++++++++
 3 files changed, 1044 insertions(+)

diff --git a/drivers/pmdomain/mediatek/Kconfig b/drivers/pmdomain/mediatek/Kconfig
index 0e34a517ab7d5a867bebaab11c0d866282a15e45..b06aaa9690f08f33519595916b8ea3ad9035fc55 100644
--- a/drivers/pmdomain/mediatek/Kconfig
+++ b/drivers/pmdomain/mediatek/Kconfig
@@ -26,6 +26,22 @@ config MTK_SCPSYS_PM_DOMAINS
 	  Control Processor System (SCPSYS) has several power management related
 	  tasks in the system.
 
+config MTK_MFG_PM_DOMAIN
+	bool "MediaTek MFlexGraphics power domain"
+	default ARCH_MEDIATEK
+	depends on PM
+	depends on OF
+	depends on COMMON_CLK
+	select PM_GENERIC_DOMAINS
+	imply MTK_GPUEB_MBOX
+	help
+	  Say y or m here to enable the power domains driver for MediaTek
+	  MFlexGraphics. This driver allows for power and frequency control of
+	  GPUs on MediaTek SoCs such as the MT8196 or MT6991.
+
+	  This driver is required for the Mali GPU to work at all on MT8196 and
+	  MT6991.
+
 config AIROHA_CPU_PM_DOMAIN
 	tristate "Airoha CPU power domain"
 	default ARCH_AIROHA
diff --git a/drivers/pmdomain/mediatek/Makefile b/drivers/pmdomain/mediatek/Makefile
index 18ba92e3c418154e1d428dbc6b59b97b26056d98..b424f1ed867604393b3ff96364855363aedaa40c 100644
--- a/drivers/pmdomain/mediatek/Makefile
+++ b/drivers/pmdomain/mediatek/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_MTK_MFG_PM_DOMAIN)		+= mtk-mfg-pmdomain.o
 obj-$(CONFIG_MTK_SCPSYS)		+= mtk-scpsys.o
 obj-$(CONFIG_MTK_SCPSYS_PM_DOMAINS) 	+= mtk-pm-domains.o
 obj-$(CONFIG_AIROHA_CPU_PM_DOMAIN) 	+= airoha-cpu-pmdomain.o
diff --git a/drivers/pmdomain/mediatek/mtk-mfg-pmdomain.c b/drivers/pmdomain/mediatek/mtk-mfg-pmdomain.c
new file mode 100644
index 0000000000000000000000000000000000000000..3137c270603fad9cca964582a6f700ddf9ac2c18
--- /dev/null
+++ b/drivers/pmdomain/mediatek/mtk-mfg-pmdomain.c
@@ -0,0 +1,1027 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Driver for MediaTek MFlexGraphics Devices
+ *
+ * Copyright (C) 2025, Collabora Ltd.
+ */
+
+#include <linux/completion.h>
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/container_of.h>
+#include <linux/iopoll.h>
+#include <linux/mailbox_client.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/of_reserved_mem.h>
+#include <linux/overflow.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/pm_opp.h>
+#include <linux/regulator/consumer.h>
+#include <linux/units.h>
+
+#define GPR_LP_STATE		0x0028
+#define   EB_ON_SUSPEND		0x0
+#define   EB_ON_RESUME		0x1
+#define GPR_IPI_MAGIC		0x34
+
+#define RPC_PWR_CON		0x0504
+#define   PWR_ACK_M		GENMASK(31, 30)
+#define RPC_DUMMY_REG_2		0x0658
+#define RPC_GHPM_CFG0_CON	0x0800
+#define   GHPM_ENABLE_M		BIT(0)
+#define   GHPM_ON_SEQ_M		BIT(2)
+#define RPC_GHPM_RO0_CON	0x09A4
+#define   GHPM_STATE_M		GENMASK(7, 0)
+#define   GHPM_PWR_STATE_M	BIT(16)
+
+#define GF_REG_MAGIC			0x0000
+#define GF_REG_GPU_OPP_IDX		0x0004
+#define GF_REG_STK_OPP_IDX		0x0008
+#define GF_REG_GPU_OPP_NUM		0x000c
+#define GF_REG_STK_OPP_NUM		0x0010
+#define GF_REG_GPU_OPP_SNUM		0x0014
+#define GF_REG_STK_OPP_SNUM		0x0018
+#define GF_REG_POWER_COUNT		0x001c
+#define GF_REG_BUCK_COUNT		0x0020
+#define GF_REG_MTCMOS_COUNT		0x0024
+#define GF_REG_CG_COUNT			0x0028 /* CG = Clock Gate? */
+#define GF_REG_ACTIVE_COUNT		0x002C
+#define GF_REG_TEMP_RAW			0x0030
+#define GF_REG_TEMP_NORM_GPU		0x0034
+#define GF_REG_TEMP_HIGH_GPU		0x0038
+#define GF_REG_TEMP_NORM_STK		0x003C
+#define GF_REG_TEMP_HIGH_STK		0x0040
+#define GF_REG_FREQ_CUR_GPU		0x0044
+#define GF_REG_FREQ_CUR_STK		0x0048
+#define GF_REG_FREQ_OUT_GPU		0x004C /* Guess: actual achieved freq */
+#define GF_REG_FREQ_OUT_STK		0x0050 /* Guess: actual achieved freq */
+#define GF_REG_FREQ_METER_GPU		0x0054 /* Seems unused, always 0 */
+#define GF_REG_FREQ_METER_STK		0x0058 /* Seems unused, always 0 */
+#define GF_REG_VOLT_CUR_GPU		0x005C /* in tens of microvolts */
+#define GF_REG_VOLT_CUR_STK		0x0060 /* in tens of microvolts */
+#define GF_REG_VOLT_CUR_GPU_SRAM	0x0064
+#define GF_REG_VOLT_CUR_STK_SRAM	0x0068
+#define GF_REG_VOLT_CUR_GPU_REG		0x006C /* Seems unused, always 0 */
+#define GF_REG_VOLT_CUR_STK_REG		0x0070 /* Seems unused, always 0 */
+#define GF_REG_VOLT_CUR_GPU_REG_SRAM	0x0074
+#define GF_REG_VOLT_CUR_STK_REG_SRAM	0x0078
+#define GF_REG_PWR_CUR_GPU		0x007C /* in milliwatts */
+#define GF_REG_PWR_CUR_STK		0x0080 /* in milliwatts */
+#define GF_REG_PWR_MAX_GPU		0x0084 /* in milliwatts */
+#define GF_REG_PWR_MAX_STK		0x0088 /* in milliwatts */
+#define GF_REG_PWR_MIN_GPU		0x008C /* in milliwatts */
+#define GF_REG_PWR_MIN_STK		0x0090 /* in milliwatts */
+#define GF_REG_LEAKAGE_RT_GPU		0x0094 /* Unknown */
+#define GF_REG_LEAKAGE_RT_STK		0x0098 /* Unknown */
+#define GF_REG_LEAKAGE_RT_SRAM		0x009C /* Unknown */
+#define GF_REG_LEAKAGE_HT_GPU		0x00A0 /* Unknown */
+#define GF_REG_LEAKAGE_HT_STK		0x00A4 /* Unknown */
+#define GF_REG_LEAKAGE_HT_SRAM		0x00A8 /* Unknown */
+#define GF_REG_VOLT_DAC_LOW_GPU		0x00AC /* Seems unused, always 0 */
+#define GF_REG_VOLT_DAC_LOW_STK		0x00B0 /* Seems unused, always 0 */
+#define GF_REG_OPP_CUR_CEIL		0x00B4
+#define GF_REG_OPP_CUR_FLOOR		0x00B8
+#define GF_REG_OPP_CUR_LIMITER_CEIL	0x00BC
+#define GF_REG_OPP_CUR_LIMITER_FLOOR	0x00C0
+#define GF_REG_OPP_PRIORITY_CEIL	0x00C4
+#define GF_REG_OPP_PRIORITY_FLOOR	0x00C8
+#define GF_REG_PWR_CTL			0x00CC
+#define GF_REG_ACTIVE_SLEEP_CTL		0x00D0
+#define GF_REG_DVFS_STATE		0x00D4
+#define GF_REG_SHADER_PRESENT		0x00D8
+#define GF_REG_ASENSOR_ENABLE		0x00DC
+#define GF_REG_AGING_LOAD		0x00E0
+#define GF_REG_AGING_MARGIN		0x00E4
+#define GF_REG_AVS_ENABLE		0x00E8
+#define GF_REG_AVS_MARGIN		0x00EC
+#define GF_REG_CHIP_TYPE		0x00F0
+#define GF_REG_SB_VERSION		0x00F4
+#define GF_REG_PTP_VERSION		0x00F8
+#define GF_REG_DBG_VERSION		0x00FC
+#define GF_REG_KDBG_VERSION		0x0100
+#define GF_REG_GPM1_MODE		0x0104
+#define GF_REG_GPM3_MODE		0x0108
+#define GF_REG_DFD_MODE			0x010C
+#define GF_REG_DUAL_BUCK		0x0110
+#define GF_REG_SEGMENT_ID		0x0114
+#define GF_REG_POWER_TIME_H		0x0118
+#define GF_REG_POWER_TIME_L		0x011C
+#define GF_REG_PWR_STATUS		0x0120
+#define GF_REG_STRESS_TEST		0x0124
+#define GF_REG_TEST_MODE		0x0128
+#define GF_REG_IPS_MODE			0x012C
+#define GF_REG_TEMP_COMP_MODE		0x0130
+#define GF_REG_HT_TEMP_COMP_MODE	0x0134
+#define GF_REG_PWR_TRACKER_MODE		0x0138
+#define GF_REG_OPP_TABLE_GPU		0x0314
+#define GF_REG_OPP_TABLE_STK		0x09A4
+#define GF_REG_OPP_TABLE_GPU_S		0x1034
+#define GF_REG_OPP_TABLE_STK_S		0x16c4
+#define GF_REG_LIMIT_TABLE		0x1d54
+#define GF_REG_GPM3_TABLE		0x223C
+
+#define MFG_MT8196_E2_ID		0x101
+#define GPUEB_SLEEP_MAGIC		0x55667788UL
+#define GPUEB_MEM_MAGIC			0xBABADADAUL
+
+#define GPUEB_TIMEOUT_US		10000UL
+#define GPUEB_POLL_US			50
+
+#define MAX_OPP_NUM			70
+
+#define GPUEB_MBOX_MAX_RX_SIZE		32 /* in bytes */
+
+/*
+ * This enum is part of the ABI of the GPUEB firmware. Don't change the
+ * numbering, as you would wreak havoc.
+ */
+enum mtk_mfg_ipi_cmd {
+	CMD_INIT_SHARED_MEM		= 0,
+	CMD_GET_FREQ_BY_IDX		= 1,
+	CMD_GET_POWER_BY_IDX		= 2,
+	CMD_GET_OPPIDX_BY_FREQ		= 3,
+	CMD_GET_LEAKAGE_POWER		= 4,
+	CMD_SET_LIMIT			= 5,
+	CMD_POWER_CONTROL		= 6,
+	CMD_ACTIVE_SLEEP_CONTROL	= 7,
+	CMD_COMMIT			= 8,
+	CMD_DUAL_COMMIT			= 9,
+	CMD_PDCA_CONFIG			= 10,
+	CMD_UPDATE_DEBUG_OPP_INFO	= 11,
+	CMD_SWITCH_LIMIT		= 12,
+	CMD_FIX_TARGET_OPPIDX		= 13,
+	CMD_FIX_DUAL_TARGET_OPPIDX	= 14,
+	CMD_FIX_CUSTOM_FREQ_VOLT	= 15,
+	CMD_FIX_DUAL_CUSTOM_FREQ_VOLT	= 16,
+	CMD_SET_MFGSYS_CONFIG		= 17,
+	CMD_MSSV_COMMIT			= 18,
+	CMD_NUM				= 19,
+};
+
+/*
+ * This struct is part of the ABI of the GPUEB firmware. Changing it, or
+ * reordering fields in it, will break things, so don't do it. Thank you.
+ */
+struct __packed mtk_mfg_ipi_msg {
+	__le32 magic;
+	__le32 cmd;
+	__le32 target;
+	/*
+	 * Downstream relies on the compiler to implicitly add the following
+	 * padding, as it declares the struct as non-packed.
+	 */
+	__le32 reserved;
+	union {
+		s32 __bitwise oppidx;
+		s32 __bitwise return_value;
+		__le32 freq;
+		__le32 volt;
+		__le32 power;
+		__le32 power_state;
+		__le32 mode;
+		__le32 value;
+		struct {
+			__le64 base;
+			__le32 size;
+		} shared_mem;
+		struct {
+			__le32 freq;
+			__le32 volt;
+		} custom;
+		struct {
+			__le32 limiter;
+			s32 __bitwise ceiling_info;
+			s32 __bitwise floor_info;
+		} set_limit;
+		struct {
+			__le32 target;
+			__le32 val;
+		} mfg_cfg;
+		struct {
+			__le32 target;
+			__le32 val;
+		} mssv;
+		struct {
+			s32 __bitwise gpu_oppidx;
+			s32 __bitwise stack_oppidx;
+		} dual_commit;
+		struct {
+			__le32 fgpu;
+			__le32 vgpu;
+			__le32 fstack;
+			__le32 vstack;
+		} dual_custom;
+	} u;
+};
+
+struct __packed mtk_mfg_ipi_sleep_msg {
+	__le32 event;
+	__le32 state;
+	__le32 magic;
+};
+
+/**
+ * struct mtk_mfg_opp_entry - OPP table entry from firmware
+ * @freq_khz: The operating point's frequency in kilohertz
+ * @voltage_core: The operating point's core voltage in tens of microvolts
+ * @voltage_sram: The operating point's SRAM voltage in tens of microvolts
+ * @posdiv: exponent of base 2 for PLL frequency divisor used for this OPP
+ * @voltage_margin: Number of tens of microvolts the voltage can be undershot
+ * @power_mw: estimate of power usage at this operating point, in milliwatts
+ *
+ * This struct is part of the ABI with the EB firmware. Do not change it.
+ */
+struct __packed mtk_mfg_opp_entry {
+	__le32 freq_khz;
+	__le32 voltage_core;
+	__le32 voltage_sram;
+	__le32 posdiv;
+	__le32 voltage_margin;
+	__le32 power_mw;
+};
+
+struct mtk_mfg_mbox {
+	struct mbox_client cl;
+	struct completion rx_done;
+	struct mtk_mfg *mfg;
+	struct mbox_chan *ch;
+	void *rx_data;
+};
+
+struct mtk_mfg {
+	struct generic_pm_domain pd;
+	struct platform_device *pdev;
+	struct clk *clk_eb;
+	struct clk_bulk_data *gpu_clks;
+	struct clk_hw clk_core_hw;
+	struct clk_hw clk_stack_hw;
+	struct regulator_bulk_data *gpu_regs;
+	void __iomem *rpc;
+	void __iomem *gpr;
+	void __iomem *shared_mem;
+	phys_addr_t shared_mem_phys;
+	unsigned int shared_mem_size;
+	u16 ghpm_en_reg;
+	u32 ipi_magic;
+	unsigned short num_gpu_opps;
+	unsigned short num_stack_opps;
+	struct dev_pm_opp_data *gpu_opps;
+	struct dev_pm_opp_data *stack_opps;
+	struct mtk_mfg_mbox *gf_mbox;
+	struct mtk_mfg_mbox *slp_mbox;
+	const struct mtk_mfg_variant *variant;
+};
+
+struct mtk_mfg_variant {
+	const char *const *clk_names;
+	unsigned int num_clks;
+	const char *const *regulator_names;
+	unsigned int num_regulators;
+	/** @turbo_below: opp indices below this value are considered turbo */
+	unsigned int turbo_below;
+	int (*init)(struct mtk_mfg *mfg);
+};
+
+static inline struct mtk_mfg *mtk_mfg_from_genpd(struct generic_pm_domain *pd)
+{
+	return container_of(pd, struct mtk_mfg, pd);
+}
+
+static inline void mtk_mfg_update_reg_bits(void __iomem *addr, u32 mask, u32 val)
+{
+	writel((readl(addr) & ~mask) | (val & mask), addr);
+}
+
+static inline bool mtk_mfg_is_powered_on(struct mtk_mfg *mfg)
+{
+	return (readl(mfg->rpc + RPC_PWR_CON) & PWR_ACK_M) == PWR_ACK_M;
+}
+
+static unsigned long mtk_mfg_recalc_rate_gpu(struct clk_hw *hw,
+					     unsigned long parent_rate)
+{
+	struct mtk_mfg *mfg = container_of(hw, struct mtk_mfg, clk_core_hw);
+
+	return readl(mfg->shared_mem + GF_REG_FREQ_OUT_GPU) * HZ_PER_KHZ;
+}
+
+static long mtk_mfg_round_rate(struct clk_hw *hw, unsigned long rate,
+			       unsigned long *parent_rate)
+{
+	/*
+	 * The round_rate callback needs to be implemented to avoid returning
+	 * the current clock frequency, rather than something even remotely
+	 * close to the frequency that was asked for.
+	 *
+	 * Instead of writing considerable amounts of possibly slow code just to
+	 * somehow figure out which of the three PLLs to round for, or even to
+	 * do a search through one of two OPP tables in order to find the closest
+	 * OPP of a frequency, just return the rate as-is. This avoids devfreq
+	 * "rounding" a request for the lowest frequency to the possibly very
+	 * high current frequency, breaking the powersave governor in the process.
+	 */
+
+	return rate;
+}
+
+static unsigned long mtk_mfg_recalc_rate_stack(struct clk_hw *hw,
+					       unsigned long parent_rate)
+{
+	struct mtk_mfg *mfg = container_of(hw, struct mtk_mfg, clk_stack_hw);
+
+	return readl(mfg->shared_mem + GF_REG_FREQ_OUT_STK) * HZ_PER_KHZ;
+}
+
+static const struct clk_ops mtk_mfg_clk_gpu_ops = {
+	.recalc_rate = mtk_mfg_recalc_rate_gpu,
+	.round_rate = mtk_mfg_round_rate,
+};
+
+static const struct clk_ops mtk_mfg_clk_stack_ops = {
+	.recalc_rate = mtk_mfg_recalc_rate_stack,
+	.round_rate = mtk_mfg_round_rate,
+};
+
+static const struct clk_init_data mtk_mfg_clk_gpu_init = {
+	.name = "gpu-core",
+	.ops = &mtk_mfg_clk_gpu_ops,
+	.flags = CLK_GET_RATE_NOCACHE,
+};
+
+static const struct clk_init_data mtk_mfg_clk_stack_init = {
+	.name = "gpu-stack",
+	.ops = &mtk_mfg_clk_stack_ops,
+	.flags = CLK_GET_RATE_NOCACHE,
+};
+
+static int mtk_mfg_eb_on(struct mtk_mfg *mfg)
+{
+	struct device *dev = &mfg->pdev->dev;
+	u32 val;
+	int ret;
+
+	/*
+	 * If MFG is already on from e.g. the bootloader, skip doing the
+	 * power-on sequence, as it wouldn't work without powering it off first.
+	 */
+	if (mtk_mfg_is_powered_on(mfg))
+		return 0;
+
+	ret = readl_poll_timeout(mfg->rpc + RPC_GHPM_RO0_CON, val,
+				 !(val & (GHPM_PWR_STATE_M | GHPM_STATE_M)),
+				 GPUEB_POLL_US, GPUEB_TIMEOUT_US);
+	if (ret) {
+		dev_err(dev, "timed out waiting for EB to power on\n");
+		return ret;
+	}
+
+	mtk_mfg_update_reg_bits(mfg->rpc + mfg->ghpm_en_reg, GHPM_ENABLE_M,
+				GHPM_ENABLE_M);
+
+	mtk_mfg_update_reg_bits(mfg->rpc + RPC_GHPM_CFG0_CON, GHPM_ON_SEQ_M, 0);
+	mtk_mfg_update_reg_bits(mfg->rpc + RPC_GHPM_CFG0_CON, GHPM_ON_SEQ_M,
+				GHPM_ON_SEQ_M);
+
+	mtk_mfg_update_reg_bits(mfg->rpc + mfg->ghpm_en_reg, GHPM_ENABLE_M, 0);
+
+
+	ret = readl_poll_timeout(mfg->rpc + RPC_PWR_CON, val,
+				 (val & PWR_ACK_M) == PWR_ACK_M,
+				 GPUEB_POLL_US, GPUEB_TIMEOUT_US);
+	if (ret) {
+		dev_err(dev, "timed out waiting for EB power ack, val = 0x%X\n",
+			val);
+		return ret;
+	}
+
+	ret = readl_poll_timeout(mfg->gpr + GPR_LP_STATE, val,
+				 (val == EB_ON_RESUME),
+				 GPUEB_POLL_US, GPUEB_TIMEOUT_US);
+	if (ret) {
+		dev_err(dev, "timed out waiting for EB to resume, status = 0x%X\n", val);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int mtk_mfg_eb_off(struct mtk_mfg *mfg)
+{
+	struct device *dev = &mfg->pdev->dev;
+	struct mtk_mfg_ipi_sleep_msg msg = {
+		.event = 0,
+		.state = 0,
+		.magic = GPUEB_SLEEP_MAGIC
+	};
+	u32 val;
+	int ret;
+
+	ret = mbox_send_message(mfg->slp_mbox->ch, &msg);
+	if (ret < 0) {
+		dev_err(dev, "Cannot send sleep command: %pe\n", ERR_PTR(ret));
+		return ret;
+	}
+
+	ret = readl_poll_timeout(mfg->rpc + RPC_PWR_CON, val,
+				 !(val & PWR_ACK_M), GPUEB_POLL_US,
+				 GPUEB_TIMEOUT_US);
+
+	if (ret) {
+		dev_err(dev, "Timed out waiting for EB to power off, val=0x%08X\n", val);
+		return ret;
+	}
+
+	return 0;
+}
+
+/**
+ * mtk_mfg_send_ipi - synchronously send an IPI message on the gpufreq channel
+ * @mfg: pointer to this driver instance's private &struct mtk_mfg
+ * @msg: pointer to a message to send; will have magic filled and response assigned
+ *
+ * Send an IPI message on the gpufreq channel, and wait for a response. Once a
+ * response is received, assign a pointer to the response buffer (valid until
+ * next response is received) to @msg.
+ *
+ * Returns 0 on success, negative errno on failure.
+ */
+static int mtk_mfg_send_ipi(struct mtk_mfg *mfg, struct mtk_mfg_ipi_msg *msg)
+{
+	struct device *dev = &mfg->pdev->dev;
+	unsigned long wait;
+	int ret;
+
+	msg->magic = mfg->ipi_magic;
+
+	ret = mbox_send_message(mfg->gf_mbox->ch, msg);
+	if (ret < 0) {
+		dev_err(dev, "Cannot send GPUFreq IPI command: %pe\n", ERR_PTR(ret));
+		return ret;
+	}
+
+	wait = wait_for_completion_timeout(&mfg->gf_mbox->rx_done, msecs_to_jiffies(500));
+	if (!wait)
+		return -ETIMEDOUT;
+
+	msg = mfg->gf_mbox->rx_data;
+
+	if (msg->u.return_value < 0) {
+		dev_err(dev, "IPI return: %d\n", msg->u.return_value);
+		return -EPROTO;
+	}
+
+	return 0;
+}
+
+static int mtk_mfg_init_shared_mem(struct mtk_mfg *mfg)
+{
+	struct device *dev = &mfg->pdev->dev;
+	struct mtk_mfg_ipi_msg msg = {};
+	int ret;
+
+	dev_dbg(dev, "clearing GPUEB shared memory, 0x%X bytes\n", mfg->shared_mem_size);
+	memset_io(mfg->shared_mem, 0, mfg->shared_mem_size);
+
+	msg.cmd = CMD_INIT_SHARED_MEM;
+	msg.u.shared_mem.base = mfg->shared_mem_phys;
+	msg.u.shared_mem.size = mfg->shared_mem_size;
+
+	ret = mtk_mfg_send_ipi(mfg, &msg);
+	if (ret)
+		return ret;
+
+	if (readl(mfg->shared_mem) != GPUEB_MEM_MAGIC) {
+		dev_err(dev, "EB did not initialise shared memory correctly\n");
+		return -EIO;
+	}
+
+	return 0;
+}
+
+static int mtk_mfg_power_control(struct mtk_mfg *mfg, bool enabled)
+{
+	struct mtk_mfg_ipi_msg msg = {};
+
+	msg.cmd = CMD_POWER_CONTROL;
+	msg.u.power_state = enabled ? 1 : 0;
+
+	return mtk_mfg_send_ipi(mfg, &msg);
+}
+
+static int mtk_mfg_set_oppidx(struct mtk_mfg *mfg, unsigned int opp_idx)
+{
+	struct mtk_mfg_ipi_msg msg = {};
+	int ret;
+
+	if (opp_idx >= mfg->num_gpu_opps)
+		return -EINVAL;
+
+	msg.cmd = CMD_FIX_DUAL_TARGET_OPPIDX;
+	msg.u.dual_commit.gpu_oppidx = opp_idx;
+	msg.u.dual_commit.stack_oppidx = opp_idx;
+
+	ret = mtk_mfg_send_ipi(mfg, &msg);
+	if (ret) {
+		dev_err(&mfg->pdev->dev, "Failed to set OPP %u: %pe\n",
+			opp_idx, ERR_PTR(ret));
+		return ret;
+	}
+
+	return 0;
+}
+
+static int mtk_mfg_read_opp_tables(struct mtk_mfg *mfg)
+{
+	struct device *dev = &mfg->pdev->dev;
+	struct mtk_mfg_opp_entry e = {};
+	unsigned int i;
+
+	mfg->num_gpu_opps = readl(mfg->shared_mem + GF_REG_GPU_OPP_NUM);
+	mfg->num_stack_opps = readl(mfg->shared_mem + GF_REG_STK_OPP_NUM);
+
+	if (mfg->num_gpu_opps > MAX_OPP_NUM || mfg->num_gpu_opps == 0) {
+		dev_err(dev, "GPU OPP count (%u) out of range %u >= count > 0\n",
+			mfg->num_gpu_opps, MAX_OPP_NUM);
+		return -EINVAL;
+	}
+
+	if (mfg->num_stack_opps && mfg->num_stack_opps > MAX_OPP_NUM) {
+		dev_err(dev, "Stack OPP count (%u) out of range %u >= count >= 0\n",
+			mfg->num_stack_opps, MAX_OPP_NUM);
+		return -EINVAL;
+	}
+
+	mfg->gpu_opps = devm_kcalloc(dev, mfg->num_gpu_opps,
+				     sizeof(struct dev_pm_opp_data), GFP_KERNEL);
+	if (!mfg->gpu_opps)
+		return -ENOMEM;
+
+	if (mfg->num_stack_opps) {
+		mfg->stack_opps = devm_kcalloc(dev, mfg->num_stack_opps,
+					       sizeof(struct dev_pm_opp_data), GFP_KERNEL);
+		if (!mfg->stack_opps)
+			return -ENOMEM;
+	}
+
+	for (i = 0; i < mfg->num_gpu_opps; i++) {
+		memcpy_fromio(&e, mfg->shared_mem + GF_REG_OPP_TABLE_GPU + i * sizeof(e),
+			      sizeof(e));
+		if (mem_is_zero(&e, sizeof(e))) {
+			dev_err(dev, "ran into an empty GPU OPP at index %u\n",
+				i);
+			return -EINVAL;
+		}
+		mfg->gpu_opps[i].freq = e.freq_khz * HZ_PER_KHZ;
+		mfg->gpu_opps[i].u_volt = e.voltage_core * 10;
+		mfg->gpu_opps[i].level = i;
+		if (i < mfg->variant->turbo_below)
+			mfg->gpu_opps[i].turbo = true;
+	}
+
+	for (i = 0; i < mfg->num_stack_opps; i++) {
+		memcpy_fromio(&e, mfg->shared_mem + GF_REG_OPP_TABLE_STK + i * sizeof(e),
+			      sizeof(e));
+		if (mem_is_zero(&e, sizeof(e))) {
+			dev_err(dev, "ran into an empty Stack OPP at index %u\n",
+				i);
+			return -EINVAL;
+		}
+		mfg->stack_opps[i].freq = e.freq_khz * HZ_PER_KHZ;
+		mfg->stack_opps[i].u_volt = e.voltage_core * 10;
+		mfg->stack_opps[i].level = i;
+		if (i < mfg->variant->turbo_below)
+			mfg->stack_opps[i].turbo = true;
+	}
+
+	return 0;
+}
+
+static const char *const mtk_mfg_mt8196_clk_names[] = {
+	"core",
+	"stack0",
+	"stack1",
+};
+
+static const char *const mtk_mfg_mt8196_regulators[] = {
+	"core",
+	"stack",
+	"sram",
+};
+
+static int mtk_mfg_mt8196_init(struct mtk_mfg *mfg)
+{
+	void __iomem *e2_base;
+
+	e2_base = devm_platform_ioremap_resource_byname(mfg->pdev, "hw-revision");
+	if (IS_ERR(e2_base))
+		return dev_err_probe(&mfg->pdev->dev, PTR_ERR(e2_base),
+				     "Couldn't get hw-revision register\n");
+
+	if (readl(e2_base) == MFG_MT8196_E2_ID)
+		mfg->ghpm_en_reg = RPC_DUMMY_REG_2;
+	else
+		mfg->ghpm_en_reg = RPC_GHPM_CFG0_CON;
+
+	return 0;
+};
+
+static const struct mtk_mfg_variant mtk_mfg_mt8196_variant = {
+	.clk_names = mtk_mfg_mt8196_clk_names,
+	.num_clks = ARRAY_SIZE(mtk_mfg_mt8196_clk_names),
+	.regulator_names = mtk_mfg_mt8196_regulators,
+	.num_regulators = ARRAY_SIZE(mtk_mfg_mt8196_regulators),
+	.turbo_below = 7,
+	.init = mtk_mfg_mt8196_init,
+};
+
+static void mtk_mfg_mbox_rx_callback(struct mbox_client *cl, void *mssg)
+{
+	struct mtk_mfg_mbox *mb = container_of(cl, struct mtk_mfg_mbox, cl);
+
+	if (mb->rx_data)
+		mb->rx_data = memcpy(mb->rx_data, mssg, GPUEB_MBOX_MAX_RX_SIZE);
+	complete(&mb->rx_done);
+}
+
+static int mtk_mfg_attach_dev(struct generic_pm_domain *pd, struct device *dev)
+{
+	struct mtk_mfg *mfg = mtk_mfg_from_genpd(pd);
+	struct dev_pm_opp_data *so = mfg->stack_opps;
+	struct dev_pm_opp_data *go = mfg->gpu_opps;
+	struct dev_pm_opp_data *prev_o;
+	struct dev_pm_opp_data *o;
+	int i, ret;
+
+	for (i = mfg->num_gpu_opps - 1; i >= 0; i--) {
+		/*
+		 * Adding the lower of the two OPPs avoids gaps of indices in
+		 * situations where the GPU OPPs are duplicated a couple of
+		 * times when only the Stack OPP is being lowered at that index.
+		 */
+		if (i >= mfg->num_stack_opps || go[i].freq < so[i].freq)
+			o = &go[i];
+		else
+			o = &so[i];
+
+		/*
+		 * Skip indices where both GPU and Stack OPPs are equal. Nominally,
+		 * OPP core shouldn't care about dupes, but not doing so will cause
+		 * dev_pm_opp_find_freq_ceil_indexed to -ERANGE later down the line.
+		 */
+		if (prev_o && prev_o->freq == o->freq)
+			continue;
+
+		ret = dev_pm_opp_add_dynamic(dev, o);
+		if (ret) {
+			dev_err(dev, "Failed to add OPP level %u from PD %s: %pe\n",
+				o->level, pd->name, ERR_PTR(ret));
+			dev_pm_opp_remove_all_dynamic(dev);
+			return ret;
+		}
+		prev_o = o;
+	}
+
+	return 0;
+}
+
+static void mtk_mfg_detach_dev(struct generic_pm_domain *pd, struct device *dev)
+{
+	dev_pm_opp_remove_all_dynamic(dev);
+}
+
+static int mtk_mfg_set_performance(struct generic_pm_domain *pd,
+				   unsigned int state)
+{
+	struct mtk_mfg *mfg = mtk_mfg_from_genpd(pd);
+
+	/*
+	 * pmdomain core intentionally sets a performance state before turning
+	 * a domain on, and after turning it off. For the GPUEB however, it's
+	 * only possible to act on performance requests when the GPUEB is
+	 * powered on. To do this, return cleanly without taking action, and
+	 * defer setting what pmdomain core set in mtk_mfg_power_on.
+	 */
+	if (mfg->pd.status != GENPD_STATE_ON)
+		return 0;
+
+	return mtk_mfg_set_oppidx(mfg, state);
+}
+
+static int mtk_mfg_power_on(struct generic_pm_domain *pd)
+{
+	struct mtk_mfg *mfg = mtk_mfg_from_genpd(pd);
+	int ret;
+
+	ret = regulator_bulk_enable(mfg->variant->num_regulators,
+				    mfg->gpu_regs);
+	if (ret)
+		return ret;
+
+	ret = clk_prepare_enable(mfg->clk_eb);
+	if (ret)
+		goto err_disable_regulators;
+
+	ret = clk_bulk_prepare_enable(mfg->variant->num_clks, mfg->gpu_clks);
+	if (ret)
+		goto err_disable_eb_clk;
+
+	ret = mtk_mfg_eb_on(mfg);
+	if (ret)
+		goto err_disable_clks;
+
+	mfg->ipi_magic = readl(mfg->gpr + GPR_IPI_MAGIC);
+
+	ret = mtk_mfg_power_control(mfg, true);
+	if (ret)
+		goto err_eb_off;
+
+	/* Don't try to set a OPP in probe before OPPs have been read from EB */
+	if (mfg->gpu_opps) {
+		/* The aforementioned deferred setting of pmdomain's state */
+		ret = mtk_mfg_set_oppidx(mfg, pd->performance_state);
+		if (ret)
+			dev_warn(&mfg->pdev->dev, "Failed to set oppidx in %s\n", __func__);
+	}
+
+	return 0;
+
+err_eb_off:
+	mtk_mfg_eb_off(mfg);
+err_disable_clks:
+	clk_bulk_disable_unprepare(mfg->variant->num_clks, mfg->gpu_clks);
+err_disable_eb_clk:
+	clk_disable_unprepare(mfg->clk_eb);
+err_disable_regulators:
+	regulator_bulk_disable(mfg->variant->num_regulators, mfg->gpu_regs);
+
+	return ret;
+}
+
+static int mtk_mfg_power_off(struct generic_pm_domain *pd)
+{
+	struct mtk_mfg *mfg = mtk_mfg_from_genpd(pd);
+	struct device *dev = &mfg->pdev->dev;
+	int ret;
+
+	ret = mtk_mfg_power_control(mfg, false);
+	if (ret) {
+		dev_err(dev, "power_control failed: %pe\n", ERR_PTR(ret));
+		return ret;
+	}
+
+	ret = mtk_mfg_eb_off(mfg);
+	if (ret) {
+		dev_err(dev, "eb_off failed: %pe\n", ERR_PTR(ret));
+		return ret;
+	}
+
+	clk_bulk_disable_unprepare(mfg->variant->num_clks, mfg->gpu_clks);
+	clk_disable_unprepare(mfg->clk_eb);
+	ret = regulator_bulk_disable(mfg->variant->num_regulators, mfg->gpu_regs);
+	if (ret) {
+		dev_err(dev, "Disabling regulators failed: %pe\n", ERR_PTR(ret));
+		return ret;
+	}
+
+	return 0;
+}
+
+static int mtk_mfg_init_mbox(struct mtk_mfg *mfg)
+{
+	struct device *dev = &mfg->pdev->dev;
+	struct mtk_mfg_mbox *gf;
+	struct mtk_mfg_mbox *slp;
+
+	gf = devm_kzalloc(dev, sizeof(*gf), GFP_KERNEL);
+	if (!gf)
+		return -ENOMEM;
+
+	gf->rx_data = devm_kzalloc(dev, GPUEB_MBOX_MAX_RX_SIZE, GFP_KERNEL);
+	if (!gf->rx_data)
+		return -ENOMEM;
+
+	gf->mfg = mfg;
+	init_completion(&gf->rx_done);
+	gf->cl.dev = dev;
+	gf->cl.rx_callback = mtk_mfg_mbox_rx_callback;
+	gf->cl.tx_tout = GPUEB_TIMEOUT_US / USEC_PER_MSEC;
+	gf->ch = mbox_request_channel_byname(&gf->cl, "gpufreq");
+	if (IS_ERR(gf->ch))
+		return PTR_ERR(gf->ch);
+
+	mfg->gf_mbox = gf;
+
+	slp = devm_kzalloc(dev, sizeof(*slp), GFP_KERNEL);
+	if (!slp)
+		return -ENOMEM;
+
+	slp->mfg = mfg;
+	init_completion(&slp->rx_done);
+	slp->cl.dev = dev;
+	slp->cl.tx_tout = GPUEB_TIMEOUT_US / USEC_PER_MSEC;
+	slp->cl.tx_block = true;
+	slp->ch = mbox_request_channel_byname(&slp->cl, "sleep");
+	if (IS_ERR(slp->ch))
+		return PTR_ERR(slp->ch);
+
+	mfg->slp_mbox = slp;
+
+	return 0;
+}
+
+static int mtk_mfg_init_clk_provider(struct mtk_mfg *mfg)
+{
+	struct device *dev = &mfg->pdev->dev;
+	struct clk_hw_onecell_data *clk_data;
+	int ret;
+
+	clk_data = devm_kzalloc(dev, struct_size(clk_data, hws, 2), GFP_KERNEL);
+	if (!clk_data)
+		return -ENOMEM;
+
+	clk_data->num = 2;
+
+	mfg->clk_core_hw.init = &mtk_mfg_clk_gpu_init;
+	mfg->clk_stack_hw.init = &mtk_mfg_clk_stack_init;
+
+	ret = devm_clk_hw_register(dev, &mfg->clk_core_hw);
+	if (ret)
+		return dev_err_probe(dev, ret, "Couldn't register GPU core clock\n");
+
+	ret = devm_clk_hw_register(dev, &mfg->clk_stack_hw);
+	if (ret)
+		return dev_err_probe(dev, ret, "Couldn't register GPU stack clock\n");
+
+	clk_data->hws[0] = &mfg->clk_core_hw;
+	clk_data->hws[1] = &mfg->clk_stack_hw;
+
+	ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get, clk_data);
+	if (ret)
+		return dev_err_probe(dev, ret, "Couldn't register clock provider\n");
+
+	return 0;
+}
+
+static int mtk_mfg_probe(struct platform_device *pdev)
+{
+	struct device_node *shmem __free(device_node);
+	struct mtk_mfg *mfg;
+	struct device *dev = &pdev->dev;
+	const struct mtk_mfg_variant *data = of_device_get_match_data(dev);
+	struct resource res;
+	int ret, i;
+
+	mfg = devm_kzalloc(dev, sizeof(*mfg), GFP_KERNEL);
+	if (!mfg)
+		return -ENOMEM;
+
+	mfg->pdev = pdev;
+	mfg->variant = data;
+
+	dev_set_drvdata(dev, mfg);
+
+	mfg->gpr = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(mfg->gpr))
+		return dev_err_probe(dev, PTR_ERR(mfg->gpr),
+				     "Couldn't retrieve GPR MMIO registers\n");
+
+	mfg->rpc = devm_platform_ioremap_resource(pdev, 1);
+	if (IS_ERR(mfg->rpc))
+		return dev_err_probe(dev, PTR_ERR(mfg->rpc),
+				     "Couldn't retrieve RPC MMIO registers\n");
+
+	mfg->clk_eb = devm_clk_get(dev, "eb");
+	if (IS_ERR(mfg->clk_eb))
+		return dev_err_probe(dev, PTR_ERR(mfg->clk_eb),
+				     "Couldn't get 'eb' clock\n");
+
+	mfg->gpu_clks = devm_kcalloc(dev, data->num_clks, sizeof(*mfg->gpu_clks),
+				     GFP_KERNEL);
+	if (!mfg->gpu_clks)
+		return -ENOMEM;
+
+	for (i = 0; i < data->num_clks; i++)
+		mfg->gpu_clks[i].id = data->clk_names[i];
+
+	ret = devm_clk_bulk_get(dev, data->num_clks, mfg->gpu_clks);
+	if (ret)
+		return dev_err_probe(dev, ret, "Couldn't get GPU clocks\n");
+
+	mfg->gpu_regs = devm_kcalloc(dev, data->num_regulators,
+				     sizeof(*mfg->gpu_regs), GFP_KERNEL);
+	if (!mfg->gpu_regs)
+		return -ENOMEM;
+
+	for (i = 0; i < data->num_regulators; i++)
+		mfg->gpu_regs[i].supply = data->regulator_names[i];
+
+	ret = devm_regulator_bulk_get(dev, data->num_regulators, mfg->gpu_regs);
+	if (ret)
+		return dev_err_probe(dev, ret, "Couldn't get GPU regulators\n");
+
+	ret = of_reserved_mem_region_to_resource(dev->of_node, 0, &res);
+	if (ret)
+		return dev_err_probe(dev, ret, "Couldn't get GPUEB shared memory\n");
+
+	mfg->shared_mem = devm_ioremap(dev, res.start, resource_size(&res));
+	if (!mfg->shared_mem)
+		return dev_err_probe(dev, -ENOMEM, "Can't ioremap GPUEB shared memory\n");
+	mfg->shared_mem_size = resource_size(&res);
+	mfg->shared_mem_phys = res.start;
+
+	if (data->init) {
+		ret = data->init(mfg);
+		if (ret)
+			return dev_err_probe(dev, ret, "Variant init failed\n");
+	}
+
+	mfg->pd.name = dev_name(dev);
+	mfg->pd.attach_dev = mtk_mfg_attach_dev;
+	mfg->pd.detach_dev = mtk_mfg_detach_dev;
+	mfg->pd.power_off = mtk_mfg_power_off;
+	mfg->pd.power_on = mtk_mfg_power_on;
+	mfg->pd.set_performance_state = mtk_mfg_set_performance;
+	mfg->pd.flags = GENPD_FLAG_OPP_TABLE_FW;
+
+	ret = pm_genpd_init(&mfg->pd, NULL, false);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to initialise power domain\n");
+
+	ret = mtk_mfg_init_mbox(mfg);
+	if (ret)
+		return dev_err_probe(dev, ret, "Couldn't initialise mailbox\n");
+
+	ret = mtk_mfg_power_on(&mfg->pd);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to power on MFG\n");
+
+	ret = mtk_mfg_init_shared_mem(mfg);
+	if (ret) {
+		dev_err_probe(dev, ret, "Couldn't initialize EB shared memory\n");
+		goto out;
+	}
+
+	ret = mtk_mfg_read_opp_tables(mfg);
+	if (ret) {
+		dev_err_probe(dev, ret, "Error reading OPP tables from EB\n");
+		goto out;
+	}
+
+	ret = mtk_mfg_init_clk_provider(mfg);
+	if (ret)
+		goto out;
+
+	ret = of_genpd_add_provider_simple(dev->of_node, &mfg->pd);
+	if (ret) {
+		dev_err_probe(dev, ret, "Failed to add pmdomain provider\n");
+		goto out;
+	}
+
+	return 0;
+
+out:
+	mtk_mfg_power_off(&mfg->pd);
+	return ret;
+}
+
+static const struct of_device_id mtk_mfg_of_match[] = {
+	{ .compatible = "mediatek,mt8196-gpufreq", .data = &mtk_mfg_mt8196_variant },
+	{}
+};
+MODULE_DEVICE_TABLE(of, mtk_mfg_of_match);
+
+static void mtk_mfg_remove(struct platform_device *pdev)
+{
+	struct mtk_mfg *mfg = dev_get_drvdata(&pdev->dev);
+
+	if (mtk_mfg_is_powered_on(mfg))
+		mtk_mfg_power_off(&mfg->pd);
+
+	of_genpd_del_provider(pdev->dev.of_node);
+	pm_genpd_remove(&mfg->pd);
+
+	mbox_free_channel(mfg->gf_mbox->ch);
+	mfg->gf_mbox->ch = NULL;
+
+	mbox_free_channel(mfg->slp_mbox->ch);
+	mfg->slp_mbox->ch = NULL;
+}
+
+static struct platform_driver mtk_mfg_driver = {
+	.driver = {
+		.name = "mtk-mfg-pmdomain",
+		.of_match_table = mtk_mfg_of_match,
+		.suppress_bind_attrs = true,
+	},
+	.probe = mtk_mfg_probe,
+	.remove = mtk_mfg_remove,
+};
+module_platform_driver(mtk_mfg_driver);
+
+MODULE_AUTHOR("Nicolas Frattaroli <nicolas.frattaroli@collabora.com>");
+MODULE_DESCRIPTION("MediaTek MFlexGraphics Power Domain Driver");
+MODULE_LICENSE("GPL");

-- 
2.51.0

Re: [PATCH v6 6/7] drm/panthor: Use existing OPP table if present

[Chia-I Wu]

On Fri, Oct 3, 2025 at 1:16 PM Nicolas Frattaroli
<nicolas.frattaroli@collabora.com> wrote:
>
> On SoCs where the GPU's power-domain is in charge of setting performance
> levels, the OPP table of the GPU node will have already been populated
> during said power-domain's attach_dev operation.
>
> To avoid initialising an OPP table twice, only set the OPP regulator and
> the OPPs from DT if there's no OPP table present.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
>  drivers/gpu/drm/panthor/panthor_devfreq.c | 26 ++++++++++++++++----------
>  1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_devfreq.c b/drivers/gpu/drm/panthor/panthor_devfreq.c
> index 978f193a2aee561fadd9a976e9b1417118260889..6beb6170d6eea3dd65880dfe64a61abbdd5f08da 100644
> --- a/drivers/gpu/drm/panthor/panthor_devfreq.c
> +++ b/drivers/gpu/drm/panthor/panthor_devfreq.c
> @@ -143,6 +143,7 @@ int panthor_devfreq_init(struct panthor_device *ptdev)
>         struct panthor_devfreq *pdevfreq;
>         struct dev_pm_opp *opp;
>         unsigned long cur_freq;
> +       struct opp_table *t;
>         unsigned long freq = ULONG_MAX;
>         int ret;
>
> @@ -152,18 +153,23 @@ int panthor_devfreq_init(struct panthor_device *ptdev)
>
>         ptdev->devfreq = pdevfreq;
>
> -       ret = devm_pm_opp_set_regulators(dev, reg_names);
> -       if (ret) {
> -               if (ret != -EPROBE_DEFER)
> -                       DRM_DEV_ERROR(dev, "Couldn't set OPP regulators\n");
> -
> -               return ret;
> +       t = dev_pm_opp_get_opp_table(dev);
"t" is too short for a long function like this one. We should either
rename it to "opp_table" or refactor this out to a shorter function.

dev_pm_domain_set_performance_state is new to me. It might just be me,
but a short comment explaining that the opp table might have been set
up by the pmdomain can be helpful.

With that, Reviewed-by: Chia-I Wu <olvaffe@gmail.com>.

> +       if (IS_ERR_OR_NULL(t)) {
> +               ret = devm_pm_opp_set_regulators(dev, reg_names);
> +               if (ret) {
> +                       if (ret != -EPROBE_DEFER)
> +                               DRM_DEV_ERROR(dev, "Couldn't set OPP regulators\n");
> +
> +                       return ret;
> +               }
> +
> +               ret = devm_pm_opp_of_add_table(dev);
> +               if (ret)
> +                       return ret;
> +       } else {
> +               dev_pm_opp_put_opp_table(t);
>         }
>
> -       ret = devm_pm_opp_of_add_table(dev);
> -       if (ret)
> -               return ret;
> -
>         spin_lock_init(&pdevfreq->lock);
>
>         panthor_devfreq_reset(pdevfreq);
>
> --
> 2.51.0
>

Re: [PATCH v6 7/7] pmdomain: mediatek: Add support for MFlexGraphics

[Chia-I Wu]

On Fri, Oct 3, 2025 at 1:16 PM Nicolas Frattaroli
<nicolas.frattaroli@collabora.com> wrote:
>
> Various MediaTek SoCs use GPU integration silicon named "MFlexGraphics"
> by MediaTek. On the MT8196 and MT6991 SoCs, interacting with this
> integration silicon is required to power on the GPU.
>
> This glue silicon is in the form of an embedded microcontroller running
> special-purpose firmware, which autonomously adjusts clocks and
> regulators.
>
> Implement a driver, modelled as a pmdomain driver with a
> set_performance_state operation, to support these SoCs.
I like this model a lot. Thanks!

panthor might potentially need to interact with this driver beyond
what pmdomain provides. I am thinking about querying
GF_REG_SHADER_PRESENT. Not sure if we've heard back from the vendor.
Have you considered moving this to drivers/soc/mediatek such that we
can provide include/linux/mtk-mfg.h to panthor?

>
> The driver also exposes the actual achieved clock rate, as read back
> from the MCU, as common clock framework clocks, by acting as a clock
> provider as well.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
>  drivers/pmdomain/mediatek/Kconfig            |   16 +
>  drivers/pmdomain/mediatek/Makefile           |    1 +
>  drivers/pmdomain/mediatek/mtk-mfg-pmdomain.c | 1027 ++++++++++++++++++++++++++
>  3 files changed, 1044 insertions(+)
[...]
> +static int mtk_mfg_init_shared_mem(struct mtk_mfg *mfg)
> +{
> +       struct device *dev = &mfg->pdev->dev;
> +       struct mtk_mfg_ipi_msg msg = {};
> +       int ret;
> +
> +       dev_dbg(dev, "clearing GPUEB shared memory, 0x%X bytes\n", mfg->shared_mem_size);
> +       memset_io(mfg->shared_mem, 0, mfg->shared_mem_size);
> +
> +       msg.cmd = CMD_INIT_SHARED_MEM;
> +       msg.u.shared_mem.base = mfg->shared_mem_phys;
> +       msg.u.shared_mem.size = mfg->shared_mem_size;
> +
> +       ret = mtk_mfg_send_ipi(mfg, &msg);
> +       if (ret)
> +               return ret;
> +
> +       if (readl(mfg->shared_mem) != GPUEB_MEM_MAGIC) {
Add the offset GF_REG_MAGIC, even though it is 0.

> +               dev_err(dev, "EB did not initialise shared memory correctly\n");
> +               return -EIO;
> +       }
> +
> +       return 0;
> +}
[...]
> +static int mtk_mfg_mt8196_init(struct mtk_mfg *mfg)
> +{
> +       void __iomem *e2_base;
> +
> +       e2_base = devm_platform_ioremap_resource_byname(mfg->pdev, "hw-revision");
> +       if (IS_ERR(e2_base))
> +               return dev_err_probe(&mfg->pdev->dev, PTR_ERR(e2_base),
> +                                    "Couldn't get hw-revision register\n");
> +
> +       if (readl(e2_base) == MFG_MT8196_E2_ID)
> +               mfg->ghpm_en_reg = RPC_DUMMY_REG_2;
> +       else
> +               mfg->ghpm_en_reg = RPC_GHPM_CFG0_CON;
> +
> +       return 0;
> +};
Extraneous semicolon.

> +static int mtk_mfg_init_mbox(struct mtk_mfg *mfg)
> +{
> +       struct device *dev = &mfg->pdev->dev;
> +       struct mtk_mfg_mbox *gf;
> +       struct mtk_mfg_mbox *slp;
> +
> +       gf = devm_kzalloc(dev, sizeof(*gf), GFP_KERNEL);
> +       if (!gf)
> +               return -ENOMEM;
> +
> +       gf->rx_data = devm_kzalloc(dev, GPUEB_MBOX_MAX_RX_SIZE, GFP_KERNEL);
It looks like gfx->rx_data can simply be "struct mtk_mfg_ipi_msg rx_data;".

> +       if (!gf->rx_data)
> +               return -ENOMEM;
> +
> +       gf->mfg = mfg;
> +       init_completion(&gf->rx_done);
> +       gf->cl.dev = dev;
> +       gf->cl.rx_callback = mtk_mfg_mbox_rx_callback;
> +       gf->cl.tx_tout = GPUEB_TIMEOUT_US / USEC_PER_MSEC;
> +       gf->ch = mbox_request_channel_byname(&gf->cl, "gpufreq");
> +       if (IS_ERR(gf->ch))
> +               return PTR_ERR(gf->ch);
> +
> +       mfg->gf_mbox = gf;
> +
> +       slp = devm_kzalloc(dev, sizeof(*slp), GFP_KERNEL);
> +       if (!slp)
> +               return -ENOMEM;
> +
> +       slp->mfg = mfg;
> +       init_completion(&slp->rx_done);
> +       slp->cl.dev = dev;
> +       slp->cl.tx_tout = GPUEB_TIMEOUT_US / USEC_PER_MSEC;
> +       slp->cl.tx_block = true;
> +       slp->ch = mbox_request_channel_byname(&slp->cl, "sleep");
> +       if (IS_ERR(slp->ch))
> +               return PTR_ERR(slp->ch);
Free gf->ch.
> +
> +       mfg->slp_mbox = slp;
> +
> +       return 0;
> +}
> +
> +static int mtk_mfg_init_clk_provider(struct mtk_mfg *mfg)
> +{
> +       struct device *dev = &mfg->pdev->dev;
> +       struct clk_hw_onecell_data *clk_data;
> +       int ret;
> +
> +       clk_data = devm_kzalloc(dev, struct_size(clk_data, hws, 2), GFP_KERNEL);
> +       if (!clk_data)
> +               return -ENOMEM;
> +
> +       clk_data->num = 2;
> +
> +       mfg->clk_core_hw.init = &mtk_mfg_clk_gpu_init;
> +       mfg->clk_stack_hw.init = &mtk_mfg_clk_stack_init;
> +
> +       ret = devm_clk_hw_register(dev, &mfg->clk_core_hw);
> +       if (ret)
> +               return dev_err_probe(dev, ret, "Couldn't register GPU core clock\n");
> +
> +       ret = devm_clk_hw_register(dev, &mfg->clk_stack_hw);
> +       if (ret)
> +               return dev_err_probe(dev, ret, "Couldn't register GPU stack clock\n");
> +
> +       clk_data->hws[0] = &mfg->clk_core_hw;
> +       clk_data->hws[1] = &mfg->clk_stack_hw;
> +
> +       ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get, clk_data);
> +       if (ret)
> +               return dev_err_probe(dev, ret, "Couldn't register clock provider\n");
> +
> +       return 0;
> +}
> +
> +static int mtk_mfg_probe(struct platform_device *pdev)
> +{
> +       struct device_node *shmem __free(device_node);
> +       struct mtk_mfg *mfg;
> +       struct device *dev = &pdev->dev;
> +       const struct mtk_mfg_variant *data = of_device_get_match_data(dev);
> +       struct resource res;
> +       int ret, i;
> +
> +       mfg = devm_kzalloc(dev, sizeof(*mfg), GFP_KERNEL);
> +       if (!mfg)
> +               return -ENOMEM;
> +
> +       mfg->pdev = pdev;
> +       mfg->variant = data;
> +
> +       dev_set_drvdata(dev, mfg);
> +
> +       mfg->gpr = devm_platform_ioremap_resource(pdev, 0);
> +       if (IS_ERR(mfg->gpr))
> +               return dev_err_probe(dev, PTR_ERR(mfg->gpr),
> +                                    "Couldn't retrieve GPR MMIO registers\n");
> +
> +       mfg->rpc = devm_platform_ioremap_resource(pdev, 1);
> +       if (IS_ERR(mfg->rpc))
> +               return dev_err_probe(dev, PTR_ERR(mfg->rpc),
> +                                    "Couldn't retrieve RPC MMIO registers\n");
> +
> +       mfg->clk_eb = devm_clk_get(dev, "eb");
> +       if (IS_ERR(mfg->clk_eb))
> +               return dev_err_probe(dev, PTR_ERR(mfg->clk_eb),
> +                                    "Couldn't get 'eb' clock\n");
> +
> +       mfg->gpu_clks = devm_kcalloc(dev, data->num_clks, sizeof(*mfg->gpu_clks),
> +                                    GFP_KERNEL);
> +       if (!mfg->gpu_clks)
> +               return -ENOMEM;
> +
> +       for (i = 0; i < data->num_clks; i++)
> +               mfg->gpu_clks[i].id = data->clk_names[i];
> +
> +       ret = devm_clk_bulk_get(dev, data->num_clks, mfg->gpu_clks);
> +       if (ret)
> +               return dev_err_probe(dev, ret, "Couldn't get GPU clocks\n");
> +
> +       mfg->gpu_regs = devm_kcalloc(dev, data->num_regulators,
> +                                    sizeof(*mfg->gpu_regs), GFP_KERNEL);
> +       if (!mfg->gpu_regs)
> +               return -ENOMEM;
> +
> +       for (i = 0; i < data->num_regulators; i++)
> +               mfg->gpu_regs[i].supply = data->regulator_names[i];
> +
> +       ret = devm_regulator_bulk_get(dev, data->num_regulators, mfg->gpu_regs);
> +       if (ret)
> +               return dev_err_probe(dev, ret, "Couldn't get GPU regulators\n");
> +
> +       ret = of_reserved_mem_region_to_resource(dev->of_node, 0, &res);
> +       if (ret)
> +               return dev_err_probe(dev, ret, "Couldn't get GPUEB shared memory\n");
> +
> +       mfg->shared_mem = devm_ioremap(dev, res.start, resource_size(&res));
> +       if (!mfg->shared_mem)
> +               return dev_err_probe(dev, -ENOMEM, "Can't ioremap GPUEB shared memory\n");
> +       mfg->shared_mem_size = resource_size(&res);
> +       mfg->shared_mem_phys = res.start;
> +
> +       if (data->init) {
> +               ret = data->init(mfg);
> +               if (ret)
> +                       return dev_err_probe(dev, ret, "Variant init failed\n");
> +       }
> +
> +       mfg->pd.name = dev_name(dev);
> +       mfg->pd.attach_dev = mtk_mfg_attach_dev;
> +       mfg->pd.detach_dev = mtk_mfg_detach_dev;
> +       mfg->pd.power_off = mtk_mfg_power_off;
> +       mfg->pd.power_on = mtk_mfg_power_on;
> +       mfg->pd.set_performance_state = mtk_mfg_set_performance;
> +       mfg->pd.flags = GENPD_FLAG_OPP_TABLE_FW;
> +
> +       ret = pm_genpd_init(&mfg->pd, NULL, false);
> +       if (ret)
> +               return dev_err_probe(dev, ret, "Failed to initialise power domain\n");
We need to clean up mgf->md on errors from this point on. Maybe we can
move this to a later point?

> +
> +       ret = mtk_mfg_init_mbox(mfg);
> +       if (ret)
> +               return dev_err_probe(dev, ret, "Couldn't initialise mailbox\n");
We need to free the mboxes from this point on.

> +       ret = mtk_mfg_power_on(&mfg->pd);
> +       if (ret)
> +               return dev_err_probe(dev, ret, "Failed to power on MFG\n");
> +
> +       ret = mtk_mfg_init_shared_mem(mfg);
> +       if (ret) {
> +               dev_err_probe(dev, ret, "Couldn't initialize EB shared memory\n");
> +               goto out;
> +       }
> +
> +       ret = mtk_mfg_read_opp_tables(mfg);
> +       if (ret) {
> +               dev_err_probe(dev, ret, "Error reading OPP tables from EB\n");
> +               goto out;
> +       }
> +
> +       ret = mtk_mfg_init_clk_provider(mfg);
> +       if (ret)
> +               goto out;
> +
> +       ret = of_genpd_add_provider_simple(dev->of_node, &mfg->pd);
> +       if (ret) {
> +               dev_err_probe(dev, ret, "Failed to add pmdomain provider\n");
> +               goto out;
> +       }
> +
> +       return 0;
> +
> +out:
> +       mtk_mfg_power_off(&mfg->pd);
> +       return ret;
> +}

Re: [PATCH v6 7/7] pmdomain: mediatek: Add support for MFlexGraphics

[Chia-I Wu]

On Fri, Oct 3, 2025 at 2:41 PM Chia-I Wu <olvaffe@gmail.com> wrote:
>
> On Fri, Oct 3, 2025 at 1:16 PM Nicolas Frattaroli
> <nicolas.frattaroli@collabora.com> wrote:
> >
> > Various MediaTek SoCs use GPU integration silicon named "MFlexGraphics"
> > by MediaTek. On the MT8196 and MT6991 SoCs, interacting with this
> > integration silicon is required to power on the GPU.
> >
> > This glue silicon is in the form of an embedded microcontroller running
> > special-purpose firmware, which autonomously adjusts clocks and
> > regulators.
> >
> > Implement a driver, modelled as a pmdomain driver with a
> > set_performance_state operation, to support these SoCs.
> I like this model a lot. Thanks!
>
> panthor might potentially need to interact with this driver beyond
> what pmdomain provides. I am thinking about querying
> GF_REG_SHADER_PRESENT. Not sure if we've heard back from the vendor.
> Have you considered moving this to drivers/soc/mediatek such that we
> can provide include/linux/mtk-mfg.h to panthor?
I meant to say include/linux/soc/mediatek/mtk-mfg.h.

Re: [PATCH v6 1/7] dt-bindings: gpu: mali-valhall-csf: add mediatek,mt8196-mali variant

[AngeloGioacchino Del Regno]

Il 03/10/25 22:15, Nicolas Frattaroli ha scritto:
> The Mali-based GPU on the MediaTek MT8196 SoC uses a separate MCU to
> control the power and frequency of the GPU. This is modelled as a power
> domain and clock provider.
> 
> It lets us omit the OPP tables from the device tree, as those can now be
> enumerated at runtime from the MCU.
> 
> Add the necessary schema logic to handle what this SoC expects in terms
> of clocks and power-domains.
> 
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

Re: [PATCH v6 2/7] dt-bindings: power: Add MT8196 GPU frequency control binding

[AngeloGioacchino Del Regno]

Il 03/10/25 22:15, Nicolas Frattaroli ha scritto:
> On the MT8196 and MT6991 SoCs, the GPU power and frequency is controlled
> by some integration logic, referred to as "MFlexGraphics" by MediaTek,
> which comes in the form of an embedded controller running
> special-purpose firmware.
> 
> This controller takes care of the regulators and PLL clock frequencies
> to squeeze the maximum amount of power out of the silicon.
> 
> Add a binding which models it as a power domain.
> 
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

Re: [PATCH v6 7/7] pmdomain: mediatek: Add support for MFlexGraphics

[Nicolas Frattaroli]

On Friday, 3 October 2025 23:41:16 Central European Summer Time Chia-I Wu wrote:
> On Fri, Oct 3, 2025 at 1:16 PM Nicolas Frattaroli
> <nicolas.frattaroli@collabora.com> wrote:
> >
> > Various MediaTek SoCs use GPU integration silicon named "MFlexGraphics"
> > by MediaTek. On the MT8196 and MT6991 SoCs, interacting with this
> > integration silicon is required to power on the GPU.
> >
> > This glue silicon is in the form of an embedded microcontroller running
> > special-purpose firmware, which autonomously adjusts clocks and
> > regulators.
> >
> > Implement a driver, modelled as a pmdomain driver with a
> > set_performance_state operation, to support these SoCs.
> I like this model a lot. Thanks!
> 
> panthor might potentially need to interact with this driver beyond
> what pmdomain provides. I am thinking about querying
> GF_REG_SHADER_PRESENT. Not sure if we've heard back from the vendor.

We did. The vendor confirmed this value is read by the EB firmware
from an efuse, but considers the efuse address to be confidential.
Consequently, we are not allowed to know the efuse address, or any
of the other information required to read the efuse ourselves
directly, such as what clocks and power domains it depends on.

We therefore likely need to pass GF_REG_SHADER_PRESENT onward, but
I do have an idea for that: struct generic_pm_domain has a member
"cpumask_var_t cpus", which is there to communicate a mask of which
CPUs are attached to a power domain if the power domain has the flag
GENPD_FLAG_CPU_DOMAIN set. If the flag isn't set, the member is
unused.

This means we could overload its meaning, e.g. with a new flag, to
communicate such masks for other purposes, since it's already the
right type and all. This would be quite a generic way for hardware
other than cpus to communicate such core masks. I was planning to
develop and send out an RFC series for this, to gauge how much Ulf
Hansson hates that approach.

A different solution could be that mtk-mfg-pmdomain could act as an
nvmem provider, and then we integrate generic "shader_present is
stored in nvmem" support in panthor, and adjust the DT binding for
this.

This approach would again be generic across vendors from panthor's
perspective. It would, however, leak into DT the fact that we have
to implement this in the gpufreq device, rather than having the
efuse read directly.

> Have you considered moving this to drivers/soc/mediatek such that we
> can provide include/linux/mtk-mfg.h to panthor?

Having panthor read data structures from mtk-mfg-pmdomain would be a
last resort for me if none of the other approaches work out, as I'm
not super keen on adding vendor-specific code paths to panthor
itself. A new generic code path in panthor that is only used by one
vendor for now is different in that it has the potential to be used
by a different vendor's integration logic in the future as well.

So for now I'd like to keep it out of public includes and panthor as
much as possible, unless the two other approaches don't work out for
us.

> >
> > The driver also exposes the actual achieved clock rate, as read back
> > from the MCU, as common clock framework clocks, by acting as a clock
> > provider as well.
> >
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> >  drivers/pmdomain/mediatek/Kconfig            |   16 +
> >  drivers/pmdomain/mediatek/Makefile           |    1 +
> >  drivers/pmdomain/mediatek/mtk-mfg-pmdomain.c | 1027 ++++++++++++++++++++++++++
> >  3 files changed, 1044 insertions(+)
> [...]
> > +static int mtk_mfg_init_shared_mem(struct mtk_mfg *mfg)
> > +{
> > +       struct device *dev = &mfg->pdev->dev;
> > +       struct mtk_mfg_ipi_msg msg = {};
> > +       int ret;
> > +
> > +       dev_dbg(dev, "clearing GPUEB shared memory, 0x%X bytes\n", mfg->shared_mem_size);
> > +       memset_io(mfg->shared_mem, 0, mfg->shared_mem_size);
> > +
> > +       msg.cmd = CMD_INIT_SHARED_MEM;
> > +       msg.u.shared_mem.base = mfg->shared_mem_phys;
> > +       msg.u.shared_mem.size = mfg->shared_mem_size;
> > +
> > +       ret = mtk_mfg_send_ipi(mfg, &msg);
> > +       if (ret)
> > +               return ret;
> > +
> > +       if (readl(mfg->shared_mem) != GPUEB_MEM_MAGIC) {
> Add the offset GF_REG_MAGIC, even though it is 0.

Good catch, will do!

> 
> > +               dev_err(dev, "EB did not initialise shared memory correctly\n");
> > +               return -EIO;
> > +       }
> > +
> > +       return 0;
> > +}
> [...]
> > +static int mtk_mfg_mt8196_init(struct mtk_mfg *mfg)
> > +{
> > +       void __iomem *e2_base;
> > +
> > +       e2_base = devm_platform_ioremap_resource_byname(mfg->pdev, "hw-revision");
> > +       if (IS_ERR(e2_base))
> > +               return dev_err_probe(&mfg->pdev->dev, PTR_ERR(e2_base),
> > +                                    "Couldn't get hw-revision register\n");
> > +
> > +       if (readl(e2_base) == MFG_MT8196_E2_ID)
> > +               mfg->ghpm_en_reg = RPC_DUMMY_REG_2;
> > +       else
> > +               mfg->ghpm_en_reg = RPC_GHPM_CFG0_CON;
> > +
> > +       return 0;
> > +};
> Extraneous semicolon.

Good catch, will fix!

> 
> > +static int mtk_mfg_init_mbox(struct mtk_mfg *mfg)
> > +{
> > +       struct device *dev = &mfg->pdev->dev;
> > +       struct mtk_mfg_mbox *gf;
> > +       struct mtk_mfg_mbox *slp;
> > +
> > +       gf = devm_kzalloc(dev, sizeof(*gf), GFP_KERNEL);
> > +       if (!gf)
> > +               return -ENOMEM;
> > +
> > +       gf->rx_data = devm_kzalloc(dev, GPUEB_MBOX_MAX_RX_SIZE, GFP_KERNEL);
> It looks like gfx->rx_data can simply be "struct mtk_mfg_ipi_msg rx_data;".

Hmmm, good point. I'll change it to that.

> 
> > +       if (!gf->rx_data)
> > +               return -ENOMEM;
> > +
> > +       gf->mfg = mfg;
> > +       init_completion(&gf->rx_done);
> > +       gf->cl.dev = dev;
> > +       gf->cl.rx_callback = mtk_mfg_mbox_rx_callback;
> > +       gf->cl.tx_tout = GPUEB_TIMEOUT_US / USEC_PER_MSEC;
> > +       gf->ch = mbox_request_channel_byname(&gf->cl, "gpufreq");
> > +       if (IS_ERR(gf->ch))
> > +               return PTR_ERR(gf->ch);
> > +
> > +       mfg->gf_mbox = gf;
> > +
> > +       slp = devm_kzalloc(dev, sizeof(*slp), GFP_KERNEL);
> > +       if (!slp)
> > +               return -ENOMEM;
> > +
> > +       slp->mfg = mfg;
> > +       init_completion(&slp->rx_done);
> > +       slp->cl.dev = dev;
> > +       slp->cl.tx_tout = GPUEB_TIMEOUT_US / USEC_PER_MSEC;
> > +       slp->cl.tx_block = true;
> > +       slp->ch = mbox_request_channel_byname(&slp->cl, "sleep");
> > +       if (IS_ERR(slp->ch))
> > +               return PTR_ERR(slp->ch);
> Free gf->ch.

Good catch! Will do.

> > +
> > +       mfg->slp_mbox = slp;
> > +
> > +       return 0;
> > +}
> > +
> > +static int mtk_mfg_init_clk_provider(struct mtk_mfg *mfg)
> > +{
> > +       struct device *dev = &mfg->pdev->dev;
> > +       struct clk_hw_onecell_data *clk_data;
> > +       int ret;
> > +
> > +       clk_data = devm_kzalloc(dev, struct_size(clk_data, hws, 2), GFP_KERNEL);
> > +       if (!clk_data)
> > +               return -ENOMEM;
> > +
> > +       clk_data->num = 2;
> > +
> > +       mfg->clk_core_hw.init = &mtk_mfg_clk_gpu_init;
> > +       mfg->clk_stack_hw.init = &mtk_mfg_clk_stack_init;
> > +
> > +       ret = devm_clk_hw_register(dev, &mfg->clk_core_hw);
> > +       if (ret)
> > +               return dev_err_probe(dev, ret, "Couldn't register GPU core clock\n");
> > +
> > +       ret = devm_clk_hw_register(dev, &mfg->clk_stack_hw);
> > +       if (ret)
> > +               return dev_err_probe(dev, ret, "Couldn't register GPU stack clock\n");
> > +
> > +       clk_data->hws[0] = &mfg->clk_core_hw;
> > +       clk_data->hws[1] = &mfg->clk_stack_hw;
> > +
> > +       ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get, clk_data);
> > +       if (ret)
> > +               return dev_err_probe(dev, ret, "Couldn't register clock provider\n");
> > +
> > +       return 0;
> > +}
> > +
> > +static int mtk_mfg_probe(struct platform_device *pdev)
> > +{
> > +       struct device_node *shmem __free(device_node);
> > +       struct mtk_mfg *mfg;
> > +       struct device *dev = &pdev->dev;
> > +       const struct mtk_mfg_variant *data = of_device_get_match_data(dev);
> > +       struct resource res;
> > +       int ret, i;
> > +
> > +       mfg = devm_kzalloc(dev, sizeof(*mfg), GFP_KERNEL);
> > +       if (!mfg)
> > +               return -ENOMEM;
> > +
> > +       mfg->pdev = pdev;
> > +       mfg->variant = data;
> > +
> > +       dev_set_drvdata(dev, mfg);
> > +
> > +       mfg->gpr = devm_platform_ioremap_resource(pdev, 0);
> > +       if (IS_ERR(mfg->gpr))
> > +               return dev_err_probe(dev, PTR_ERR(mfg->gpr),
> > +                                    "Couldn't retrieve GPR MMIO registers\n");
> > +
> > +       mfg->rpc = devm_platform_ioremap_resource(pdev, 1);
> > +       if (IS_ERR(mfg->rpc))
> > +               return dev_err_probe(dev, PTR_ERR(mfg->rpc),
> > +                                    "Couldn't retrieve RPC MMIO registers\n");
> > +
> > +       mfg->clk_eb = devm_clk_get(dev, "eb");
> > +       if (IS_ERR(mfg->clk_eb))
> > +               return dev_err_probe(dev, PTR_ERR(mfg->clk_eb),
> > +                                    "Couldn't get 'eb' clock\n");
> > +
> > +       mfg->gpu_clks = devm_kcalloc(dev, data->num_clks, sizeof(*mfg->gpu_clks),
> > +                                    GFP_KERNEL);
> > +       if (!mfg->gpu_clks)
> > +               return -ENOMEM;
> > +
> > +       for (i = 0; i < data->num_clks; i++)
> > +               mfg->gpu_clks[i].id = data->clk_names[i];
> > +
> > +       ret = devm_clk_bulk_get(dev, data->num_clks, mfg->gpu_clks);
> > +       if (ret)
> > +               return dev_err_probe(dev, ret, "Couldn't get GPU clocks\n");
> > +
> > +       mfg->gpu_regs = devm_kcalloc(dev, data->num_regulators,
> > +                                    sizeof(*mfg->gpu_regs), GFP_KERNEL);
> > +       if (!mfg->gpu_regs)
> > +               return -ENOMEM;
> > +
> > +       for (i = 0; i < data->num_regulators; i++)
> > +               mfg->gpu_regs[i].supply = data->regulator_names[i];
> > +
> > +       ret = devm_regulator_bulk_get(dev, data->num_regulators, mfg->gpu_regs);
> > +       if (ret)
> > +               return dev_err_probe(dev, ret, "Couldn't get GPU regulators\n");
> > +
> > +       ret = of_reserved_mem_region_to_resource(dev->of_node, 0, &res);
> > +       if (ret)
> > +               return dev_err_probe(dev, ret, "Couldn't get GPUEB shared memory\n");
> > +
> > +       mfg->shared_mem = devm_ioremap(dev, res.start, resource_size(&res));
> > +       if (!mfg->shared_mem)
> > +               return dev_err_probe(dev, -ENOMEM, "Can't ioremap GPUEB shared memory\n");
> > +       mfg->shared_mem_size = resource_size(&res);
> > +       mfg->shared_mem_phys = res.start;
> > +
> > +       if (data->init) {
> > +               ret = data->init(mfg);
> > +               if (ret)
> > +                       return dev_err_probe(dev, ret, "Variant init failed\n");
> > +       }
> > +
> > +       mfg->pd.name = dev_name(dev);
> > +       mfg->pd.attach_dev = mtk_mfg_attach_dev;
> > +       mfg->pd.detach_dev = mtk_mfg_detach_dev;
> > +       mfg->pd.power_off = mtk_mfg_power_off;
> > +       mfg->pd.power_on = mtk_mfg_power_on;
> > +       mfg->pd.set_performance_state = mtk_mfg_set_performance;
> > +       mfg->pd.flags = GENPD_FLAG_OPP_TABLE_FW;
> > +
> > +       ret = pm_genpd_init(&mfg->pd, NULL, false);
> > +       if (ret)
> > +               return dev_err_probe(dev, ret, "Failed to initialise power domain\n");
> We need to clean up mgf->md on errors from this point on. Maybe we can
> move this to a later point?
> 
> > +
> > +       ret = mtk_mfg_init_mbox(mfg);
> > +       if (ret)
> > +               return dev_err_probe(dev, ret, "Couldn't initialise mailbox\n");
> We need to free the mboxes from this point on.
> 

For this and the one above, does .remove not get called on probe failure? If not,
I'll definitely do this. Otherwise it seems redundant, though with the added
concern that .remove does not check before calling those functions.

> > +       ret = mtk_mfg_power_on(&mfg->pd);
> > +       if (ret)
> > +               return dev_err_probe(dev, ret, "Failed to power on MFG\n");
> > +
> > +       ret = mtk_mfg_init_shared_mem(mfg);
> > +       if (ret) {
> > +               dev_err_probe(dev, ret, "Couldn't initialize EB shared memory\n");
> > +               goto out;
> > +       }
> > +
> > +       ret = mtk_mfg_read_opp_tables(mfg);
> > +       if (ret) {
> > +               dev_err_probe(dev, ret, "Error reading OPP tables from EB\n");
> > +               goto out;
> > +       }
> > +
> > +       ret = mtk_mfg_init_clk_provider(mfg);
> > +       if (ret)
> > +               goto out;
> > +
> > +       ret = of_genpd_add_provider_simple(dev->of_node, &mfg->pd);
> > +       if (ret) {
> > +               dev_err_probe(dev, ret, "Failed to add pmdomain provider\n");
> > +               goto out;
> > +       }
> > +
> > +       return 0;
> > +
> > +out:
> > +       mtk_mfg_power_off(&mfg->pd);
> > +       return ret;
> > +}
> 

Thanks for the review!

Kind regards,
Nicolas Frattaroli

Re: [PATCH v6 7/7] pmdomain: mediatek: Add support for MFlexGraphics

[AngeloGioacchino Del Regno]

Il 06/10/25 12:58, Nicolas Frattaroli ha scritto:
> On Friday, 3 October 2025 23:41:16 Central European Summer Time Chia-I Wu wrote:
>> On Fri, Oct 3, 2025 at 1:16 PM Nicolas Frattaroli
>> <nicolas.frattaroli@collabora.com> wrote:
>>>
>>> Various MediaTek SoCs use GPU integration silicon named "MFlexGraphics"
>>> by MediaTek. On the MT8196 and MT6991 SoCs, interacting with this
>>> integration silicon is required to power on the GPU.
>>>
>>> This glue silicon is in the form of an embedded microcontroller running
>>> special-purpose firmware, which autonomously adjusts clocks and
>>> regulators.
>>>
>>> Implement a driver, modelled as a pmdomain driver with a
>>> set_performance_state operation, to support these SoCs.
>> I like this model a lot. Thanks!
>>
>> panthor might potentially need to interact with this driver beyond
>> what pmdomain provides. I am thinking about querying
>> GF_REG_SHADER_PRESENT. Not sure if we've heard back from the vendor.
> 
> We did. The vendor confirmed this value is read by the EB firmware
> from an efuse, but considers the efuse address to be confidential.
> Consequently, we are not allowed to know the efuse address, or any
> of the other information required to read the efuse ourselves
> directly, such as what clocks and power domains it depends on.
> 
> We therefore likely need to pass GF_REG_SHADER_PRESENT onward, but
> I do have an idea for that: struct generic_pm_domain has a member
> "cpumask_var_t cpus", which is there to communicate a mask of which
> CPUs are attached to a power domain if the power domain has the flag
> GENPD_FLAG_CPU_DOMAIN set. If the flag isn't set, the member is
> unused.

cpumask_var_t is not going to be the right type for anything else that is
not a cpumask, as that is limited by NR_CPUS.

You'd have to declare a new bitmap, suitable for generic devices, which may
get a little complicated on deciding how many bits would be enough... and
if we look at GPUs... AMD and nV have lots of cores, so that becomes a bit
unfeasible to put in a bitmap.

Not sure then how generic that would be.

> 
> This means we could overload its meaning, e.g. with a new flag, to
> communicate such masks for other purposes, since it's already the
> right type and all. This would be quite a generic way for hardware
> other than cpus to communicate such core masks. I was planning to
> develop and send out an RFC series for this, to gauge how much Ulf
> Hansson hates that approach.
> 
> A different solution could be that mtk-mfg-pmdomain could act as an
> nvmem provider, and then we integrate generic "shader_present is
> stored in nvmem" support in panthor, and adjust the DT binding for
> this.
> 
> This approach would again be generic across vendors from panthor's
> perspective. It would, however, leak into DT the fact that we have
> to implement this in the gpufreq device, rather than having the
> efuse read directly.
> 
>> Have you considered moving this to drivers/soc/mediatek such that we
>> can provide include/linux/mtk-mfg.h to panthor?
> 
> Having panthor read data structures from mtk-mfg-pmdomain would be a
> last resort for me if none of the other approaches work out, as I'm
> not super keen on adding vendor-specific code paths to panthor
> itself. A new generic code path in panthor that is only used by one
> vendor for now is different in that it has the potential to be used
> by a different vendor's integration logic in the future as well.
> 
> So for now I'd like to keep it out of public includes and panthor as
> much as possible, unless the two other approaches don't work out for
> us.
> 

I don't really like seeing more and more vendor specific APIs: MediaTek does
suffer quite a lot from that, with cmdq being one of the examples - and the
fact that it's not just MediaTek having those, but also others like Qualcomm,
Rockchip, etc, is not an excuse to keep adding new ones when there are other
alternatives.

Also another fact there is that I don't think that panthor should get any
vendor specific "things" added (I mean, that should be avoided as much as
possible).

That said - what you will be trying to pass is really a value that is read
from eFuse, with the EB firmware being a wrapper over that: if we want, we
could see that yet-another-way of interfacing ourselves with reading nvmem
where, instead of a direct MMIO read, we're asking a firmware to give us a
readout.

This leads me to think that one of the possible options could be to actually
register (perhaps as a new platform device, because I'm not sure that it could
be feasible to register a pmdomain driver as a nvmem provider, but ultimately
that is Ulf and Srinivas' call I guess) a nvmem driver that makes an IPI call
to GPUEB and gives back the value to panthor through generic bindings.

>>>
>>> The driver also exposes the actual achieved clock rate, as read back
>>> from the MCU, as common clock framework clocks, by acting as a clock
>>> provider as well.
>>>
>>> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>>> ---
>>>   drivers/pmdomain/mediatek/Kconfig            |   16 +
>>>   drivers/pmdomain/mediatek/Makefile           |    1 +
>>>   drivers/pmdomain/mediatek/mtk-mfg-pmdomain.c | 1027 ++++++++++++++++++++++++++
>>>   3 files changed, 1044 insertions(+)
>> [...]
>>> +static int mtk_mfg_init_shared_mem(struct mtk_mfg *mfg)
>>> +{
>>> +       struct device *dev = &mfg->pdev->dev;
>>> +       struct mtk_mfg_ipi_msg msg = {};
>>> +       int ret;
>>> +
>>> +       dev_dbg(dev, "clearing GPUEB shared memory, 0x%X bytes\n", mfg->shared_mem_size);
>>> +       memset_io(mfg->shared_mem, 0, mfg->shared_mem_size);
>>> +
>>> +       msg.cmd = CMD_INIT_SHARED_MEM;
>>> +       msg.u.shared_mem.base = mfg->shared_mem_phys;
>>> +       msg.u.shared_mem.size = mfg->shared_mem_size;
>>> +
>>> +       ret = mtk_mfg_send_ipi(mfg, &msg);
>>> +       if (ret)
>>> +               return ret;
>>> +
>>> +       if (readl(mfg->shared_mem) != GPUEB_MEM_MAGIC) {
>> Add the offset GF_REG_MAGIC, even though it is 0.
> 
> Good catch, will do!
> 
>>
>>> +               dev_err(dev, "EB did not initialise shared memory correctly\n");
>>> +               return -EIO;
>>> +       }
>>> +
>>> +       return 0;
>>> +}
>> [...]
>>> +static int mtk_mfg_mt8196_init(struct mtk_mfg *mfg)
>>> +{
>>> +       void __iomem *e2_base;
>>> +
>>> +       e2_base = devm_platform_ioremap_resource_byname(mfg->pdev, "hw-revision");
>>> +       if (IS_ERR(e2_base))
>>> +               return dev_err_probe(&mfg->pdev->dev, PTR_ERR(e2_base),
>>> +                                    "Couldn't get hw-revision register\n");
>>> +
>>> +       if (readl(e2_base) == MFG_MT8196_E2_ID)
>>> +               mfg->ghpm_en_reg = RPC_DUMMY_REG_2;
>>> +       else
>>> +               mfg->ghpm_en_reg = RPC_GHPM_CFG0_CON;
>>> +
>>> +       return 0;
>>> +};
>> Extraneous semicolon.
> 
> Good catch, will fix!
> 
>>
>>> +static int mtk_mfg_init_mbox(struct mtk_mfg *mfg)
>>> +{
>>> +       struct device *dev = &mfg->pdev->dev;
>>> +       struct mtk_mfg_mbox *gf;
>>> +       struct mtk_mfg_mbox *slp;
>>> +
>>> +       gf = devm_kzalloc(dev, sizeof(*gf), GFP_KERNEL);
>>> +       if (!gf)
>>> +               return -ENOMEM;
>>> +
>>> +       gf->rx_data = devm_kzalloc(dev, GPUEB_MBOX_MAX_RX_SIZE, GFP_KERNEL);
>> It looks like gfx->rx_data can simply be "struct mtk_mfg_ipi_msg rx_data;".
> 
> Hmmm, good point. I'll change it to that.
> 

Honestly, I prefer the current version. No strong opinions though.

>>
>>> +       if (!gf->rx_data)
>>> +               return -ENOMEM;
>>> +
>>> +       gf->mfg = mfg;
>>> +       init_completion(&gf->rx_done);
>>> +       gf->cl.dev = dev;
>>> +       gf->cl.rx_callback = mtk_mfg_mbox_rx_callback;
>>> +       gf->cl.tx_tout = GPUEB_TIMEOUT_US / USEC_PER_MSEC;
>>> +       gf->ch = mbox_request_channel_byname(&gf->cl, "gpufreq");
>>> +       if (IS_ERR(gf->ch))
>>> +               return PTR_ERR(gf->ch);
>>> +
>>> +       mfg->gf_mbox = gf;
>>> +
>>> +       slp = devm_kzalloc(dev, sizeof(*slp), GFP_KERNEL);
>>> +       if (!slp)
>>> +               return -ENOMEM;
>>> +
>>> +       slp->mfg = mfg;
>>> +       init_completion(&slp->rx_done);
>>> +       slp->cl.dev = dev;
>>> +       slp->cl.tx_tout = GPUEB_TIMEOUT_US / USEC_PER_MSEC;
>>> +       slp->cl.tx_block = true;
>>> +       slp->ch = mbox_request_channel_byname(&slp->cl, "sleep");
>>> +       if (IS_ERR(slp->ch))
>>> +               return PTR_ERR(slp->ch);
>> Free gf->ch.
> 
> Good catch! Will do.
> 
>>> +
>>> +       mfg->slp_mbox = slp;
>>> +
>>> +       return 0;
>>> +}
>>> +
>>> +static int mtk_mfg_init_clk_provider(struct mtk_mfg *mfg)
>>> +{
>>> +       struct device *dev = &mfg->pdev->dev;
>>> +       struct clk_hw_onecell_data *clk_data;
>>> +       int ret;
>>> +
>>> +       clk_data = devm_kzalloc(dev, struct_size(clk_data, hws, 2), GFP_KERNEL);
>>> +       if (!clk_data)
>>> +               return -ENOMEM;
>>> +
>>> +       clk_data->num = 2;
>>> +
>>> +       mfg->clk_core_hw.init = &mtk_mfg_clk_gpu_init;
>>> +       mfg->clk_stack_hw.init = &mtk_mfg_clk_stack_init;
>>> +
>>> +       ret = devm_clk_hw_register(dev, &mfg->clk_core_hw);
>>> +       if (ret)
>>> +               return dev_err_probe(dev, ret, "Couldn't register GPU core clock\n");
>>> +
>>> +       ret = devm_clk_hw_register(dev, &mfg->clk_stack_hw);
>>> +       if (ret)
>>> +               return dev_err_probe(dev, ret, "Couldn't register GPU stack clock\n");
>>> +
>>> +       clk_data->hws[0] = &mfg->clk_core_hw;
>>> +       clk_data->hws[1] = &mfg->clk_stack_hw;
>>> +
>>> +       ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get, clk_data);
>>> +       if (ret)
>>> +               return dev_err_probe(dev, ret, "Couldn't register clock provider\n");
>>> +
>>> +       return 0;
>>> +}
>>> +
>>> +static int mtk_mfg_probe(struct platform_device *pdev)
>>> +{
>>> +       struct device_node *shmem __free(device_node);
>>> +       struct mtk_mfg *mfg;
>>> +       struct device *dev = &pdev->dev;
>>> +       const struct mtk_mfg_variant *data = of_device_get_match_data(dev);
>>> +       struct resource res;
>>> +       int ret, i;
>>> +
>>> +       mfg = devm_kzalloc(dev, sizeof(*mfg), GFP_KERNEL);
>>> +       if (!mfg)
>>> +               return -ENOMEM;
>>> +
>>> +       mfg->pdev = pdev;
>>> +       mfg->variant = data;
>>> +
>>> +       dev_set_drvdata(dev, mfg);
>>> +
>>> +       mfg->gpr = devm_platform_ioremap_resource(pdev, 0);
>>> +       if (IS_ERR(mfg->gpr))
>>> +               return dev_err_probe(dev, PTR_ERR(mfg->gpr),
>>> +                                    "Couldn't retrieve GPR MMIO registers\n");
>>> +
>>> +       mfg->rpc = devm_platform_ioremap_resource(pdev, 1);
>>> +       if (IS_ERR(mfg->rpc))
>>> +               return dev_err_probe(dev, PTR_ERR(mfg->rpc),
>>> +                                    "Couldn't retrieve RPC MMIO registers\n");
>>> +
>>> +       mfg->clk_eb = devm_clk_get(dev, "eb");
>>> +       if (IS_ERR(mfg->clk_eb))
>>> +               return dev_err_probe(dev, PTR_ERR(mfg->clk_eb),
>>> +                                    "Couldn't get 'eb' clock\n");
>>> +
>>> +       mfg->gpu_clks = devm_kcalloc(dev, data->num_clks, sizeof(*mfg->gpu_clks),
>>> +                                    GFP_KERNEL);
>>> +       if (!mfg->gpu_clks)
>>> +               return -ENOMEM;
>>> +
>>> +       for (i = 0; i < data->num_clks; i++)
>>> +               mfg->gpu_clks[i].id = data->clk_names[i];
>>> +
>>> +       ret = devm_clk_bulk_get(dev, data->num_clks, mfg->gpu_clks);
>>> +       if (ret)
>>> +               return dev_err_probe(dev, ret, "Couldn't get GPU clocks\n");
>>> +
>>> +       mfg->gpu_regs = devm_kcalloc(dev, data->num_regulators,
>>> +                                    sizeof(*mfg->gpu_regs), GFP_KERNEL);
>>> +       if (!mfg->gpu_regs)
>>> +               return -ENOMEM;
>>> +
>>> +       for (i = 0; i < data->num_regulators; i++)
>>> +               mfg->gpu_regs[i].supply = data->regulator_names[i];
>>> +
>>> +       ret = devm_regulator_bulk_get(dev, data->num_regulators, mfg->gpu_regs);
>>> +       if (ret)
>>> +               return dev_err_probe(dev, ret, "Couldn't get GPU regulators\n");
>>> +
>>> +       ret = of_reserved_mem_region_to_resource(dev->of_node, 0, &res);
>>> +       if (ret)
>>> +               return dev_err_probe(dev, ret, "Couldn't get GPUEB shared memory\n");
>>> +
>>> +       mfg->shared_mem = devm_ioremap(dev, res.start, resource_size(&res));
>>> +       if (!mfg->shared_mem)
>>> +               return dev_err_probe(dev, -ENOMEM, "Can't ioremap GPUEB shared memory\n");
>>> +       mfg->shared_mem_size = resource_size(&res);
>>> +       mfg->shared_mem_phys = res.start;
>>> +
>>> +       if (data->init) {
>>> +               ret = data->init(mfg);
>>> +               if (ret)
>>> +                       return dev_err_probe(dev, ret, "Variant init failed\n");
>>> +       }
>>> +
>>> +       mfg->pd.name = dev_name(dev);
>>> +       mfg->pd.attach_dev = mtk_mfg_attach_dev;
>>> +       mfg->pd.detach_dev = mtk_mfg_detach_dev;
>>> +       mfg->pd.power_off = mtk_mfg_power_off;
>>> +       mfg->pd.power_on = mtk_mfg_power_on;
>>> +       mfg->pd.set_performance_state = mtk_mfg_set_performance;
>>> +       mfg->pd.flags = GENPD_FLAG_OPP_TABLE_FW;
>>> +
>>> +       ret = pm_genpd_init(&mfg->pd, NULL, false);
>>> +       if (ret)
>>> +               return dev_err_probe(dev, ret, "Failed to initialise power domain\n");
>> We need to clean up mgf->md on errors from this point on. Maybe we can
>> move this to a later point?
>>
>>> +
>>> +       ret = mtk_mfg_init_mbox(mfg);
>>> +       if (ret)
>>> +               return dev_err_probe(dev, ret, "Couldn't initialise mailbox\n");
>> We need to free the mboxes from this point on.
>>
> 
> For this and the one above, does .remove not get called on probe failure? If not,
> I'll definitely do this. Otherwise it seems redundant, though with the added
> concern that .remove does not check before calling those functions.
> 

Failing during probe doesn't make this much of a working (probed -> bound) device,
so no, .remove() is not going to get called upon probe failure.

Cheers,
Angelo

Re: [PATCH v6 7/7] pmdomain: mediatek: Add support for MFlexGraphics

[Nicolas Frattaroli]

On Monday, 6 October 2025 12:58:55 Central European Summer Time Nicolas Frattaroli wrote:
> On Friday, 3 October 2025 23:41:16 Central European Summer Time Chia-I Wu wrote:
> > On Fri, Oct 3, 2025 at 1:16 PM Nicolas Frattaroli
> > <nicolas.frattaroli@collabora.com> wrote:
> > >
> > > Various MediaTek SoCs use GPU integration silicon named "MFlexGraphics"
> > > by MediaTek. On the MT8196 and MT6991 SoCs, interacting with this
> > > integration silicon is required to power on the GPU.
> > >
> > > This glue silicon is in the form of an embedded microcontroller running
> > > special-purpose firmware, which autonomously adjusts clocks and
> > > regulators.
> > >
> > > Implement a driver, modelled as a pmdomain driver with a
> > > set_performance_state operation, to support these SoCs.
> [...]
> > > +static int mtk_mfg_probe(struct platform_device *pdev)
> > > +{
> > > +       struct device_node *shmem __free(device_node);
> > > +       struct mtk_mfg *mfg;
> > > +       struct device *dev = &pdev->dev;
> > > +       const struct mtk_mfg_variant *data = of_device_get_match_data(dev);
> > > +       struct resource res;
> > > +       int ret, i;
> > > +
> > > +       mfg = devm_kzalloc(dev, sizeof(*mfg), GFP_KERNEL);
> > > +       if (!mfg)
> > > +               return -ENOMEM;
> > > +
> > > +       mfg->pdev = pdev;
> > > +       mfg->variant = data;
> > > +
> > > +       dev_set_drvdata(dev, mfg);
> > > +
> > > +       mfg->gpr = devm_platform_ioremap_resource(pdev, 0);
> > > +       if (IS_ERR(mfg->gpr))
> > > +               return dev_err_probe(dev, PTR_ERR(mfg->gpr),
> > > +                                    "Couldn't retrieve GPR MMIO registers\n");
> > > +
> > > +       mfg->rpc = devm_platform_ioremap_resource(pdev, 1);
> > > +       if (IS_ERR(mfg->rpc))
> > > +               return dev_err_probe(dev, PTR_ERR(mfg->rpc),
> > > +                                    "Couldn't retrieve RPC MMIO registers\n");
> > > +
> > > +       mfg->clk_eb = devm_clk_get(dev, "eb");
> > > +       if (IS_ERR(mfg->clk_eb))
> > > +               return dev_err_probe(dev, PTR_ERR(mfg->clk_eb),
> > > +                                    "Couldn't get 'eb' clock\n");
> > > +
> > > +       mfg->gpu_clks = devm_kcalloc(dev, data->num_clks, sizeof(*mfg->gpu_clks),
> > > +                                    GFP_KERNEL);
> > > +       if (!mfg->gpu_clks)
> > > +               return -ENOMEM;
> > > +
> > > +       for (i = 0; i < data->num_clks; i++)
> > > +               mfg->gpu_clks[i].id = data->clk_names[i];
> > > +
> > > +       ret = devm_clk_bulk_get(dev, data->num_clks, mfg->gpu_clks);
> > > +       if (ret)
> > > +               return dev_err_probe(dev, ret, "Couldn't get GPU clocks\n");
> > > +
> > > +       mfg->gpu_regs = devm_kcalloc(dev, data->num_regulators,
> > > +                                    sizeof(*mfg->gpu_regs), GFP_KERNEL);
> > > +       if (!mfg->gpu_regs)
> > > +               return -ENOMEM;
> > > +
> > > +       for (i = 0; i < data->num_regulators; i++)
> > > +               mfg->gpu_regs[i].supply = data->regulator_names[i];
> > > +
> > > +       ret = devm_regulator_bulk_get(dev, data->num_regulators, mfg->gpu_regs);
> > > +       if (ret)
> > > +               return dev_err_probe(dev, ret, "Couldn't get GPU regulators\n");
> > > +
> > > +       ret = of_reserved_mem_region_to_resource(dev->of_node, 0, &res);
> > > +       if (ret)
> > > +               return dev_err_probe(dev, ret, "Couldn't get GPUEB shared memory\n");
> > > +
> > > +       mfg->shared_mem = devm_ioremap(dev, res.start, resource_size(&res));
> > > +       if (!mfg->shared_mem)
> > > +               return dev_err_probe(dev, -ENOMEM, "Can't ioremap GPUEB shared memory\n");
> > > +       mfg->shared_mem_size = resource_size(&res);
> > > +       mfg->shared_mem_phys = res.start;
> > > +
> > > +       if (data->init) {
> > > +               ret = data->init(mfg);
> > > +               if (ret)
> > > +                       return dev_err_probe(dev, ret, "Variant init failed\n");
> > > +       }
> > > +
> > > +       mfg->pd.name = dev_name(dev);
> > > +       mfg->pd.attach_dev = mtk_mfg_attach_dev;
> > > +       mfg->pd.detach_dev = mtk_mfg_detach_dev;
> > > +       mfg->pd.power_off = mtk_mfg_power_off;
> > > +       mfg->pd.power_on = mtk_mfg_power_on;
> > > +       mfg->pd.set_performance_state = mtk_mfg_set_performance;
> > > +       mfg->pd.flags = GENPD_FLAG_OPP_TABLE_FW;
> > > +
> > > +       ret = pm_genpd_init(&mfg->pd, NULL, false);
> > > +       if (ret)
> > > +               return dev_err_probe(dev, ret, "Failed to initialise power domain\n");
> > We need to clean up mgf->md on errors from this point on. Maybe we can
> > move this to a later point?
> > 
> > > +
> > > +       ret = mtk_mfg_init_mbox(mfg);
> > > +       if (ret)
> > > +               return dev_err_probe(dev, ret, "Couldn't initialise mailbox\n");
> > We need to free the mboxes from this point on.
> > 
> 
> For this and the one above, does .remove not get called on probe failure? If not,
> I'll definitely do this. Otherwise it seems redundant, though with the added
> concern that .remove does not check before calling those functions.
> 

Alright nevermind, I'm being confused by devres vs. remove callback.

.remove does not get called if the probe function fails, but devres
handlers still do get called.

Sorry for the confusion, will fix things accordingly.

Re: [PATCH v6 7/7] pmdomain: mediatek: Add support for MFlexGraphics

[Nicolas Frattaroli]

On Monday, 6 October 2025 13:37:28 Central European Summer Time AngeloGioacchino Del Regno wrote:
> Il 06/10/25 12:58, Nicolas Frattaroli ha scritto:
> > On Friday, 3 October 2025 23:41:16 Central European Summer Time Chia-I Wu wrote:
> >> On Fri, Oct 3, 2025 at 1:16 PM Nicolas Frattaroli
> >> <nicolas.frattaroli@collabora.com> wrote:
> >>>
> >>> Various MediaTek SoCs use GPU integration silicon named "MFlexGraphics"
> >>> by MediaTek. On the MT8196 and MT6991 SoCs, interacting with this
> >>> integration silicon is required to power on the GPU.
> >>>
> >>> This glue silicon is in the form of an embedded microcontroller running
> >>> special-purpose firmware, which autonomously adjusts clocks and
> >>> regulators.
> >>>
> >>> Implement a driver, modelled as a pmdomain driver with a
> >>> set_performance_state operation, to support these SoCs.
> >> I like this model a lot. Thanks!
> >>
> >> panthor might potentially need to interact with this driver beyond
> >> what pmdomain provides. I am thinking about querying
> >> GF_REG_SHADER_PRESENT. Not sure if we've heard back from the vendor.
> > 
> > We did. The vendor confirmed this value is read by the EB firmware
> > from an efuse, but considers the efuse address to be confidential.
> > Consequently, we are not allowed to know the efuse address, or any
> > of the other information required to read the efuse ourselves
> > directly, such as what clocks and power domains it depends on.
> > 
> > We therefore likely need to pass GF_REG_SHADER_PRESENT onward, but
> > I do have an idea for that: struct generic_pm_domain has a member
> > "cpumask_var_t cpus", which is there to communicate a mask of which
> > CPUs are attached to a power domain if the power domain has the flag
> > GENPD_FLAG_CPU_DOMAIN set. If the flag isn't set, the member is
> > unused.
> 
> cpumask_var_t is not going to be the right type for anything else that is
> not a cpumask, as that is limited by NR_CPUS.

Hmmm, good point, I thought that would be done by the allocation
but nope.
 
> You'd have to declare a new bitmap, suitable for generic devices, which may
> get a little complicated on deciding how many bits would be enough... and
> if we look at GPUs... AMD and nV have lots of cores, so that becomes a bit
> unfeasible to put in a bitmap.
> 
> Not sure then how generic that would be.

Yeah, at this point I'm rapidly approaching "shove stuff into pmdomain
for no obvious pmdomain reason" territory, because we're not really
communicating that this pmdomain is only tied to these cores, but
rather that only these cores are present. Subtle difference that
could come bite us in the rear once some other chip has several power
domains that tie to different GPU shader cores.

> 
> > 
> > This means we could overload its meaning, e.g. with a new flag, to
> > communicate such masks for other purposes, since it's already the
> > right type and all. This would be quite a generic way for hardware
> > other than cpus to communicate such core masks. I was planning to
> > develop and send out an RFC series for this, to gauge how much Ulf
> > Hansson hates that approach.
> > 
> > A different solution could be that mtk-mfg-pmdomain could act as an
> > nvmem provider, and then we integrate generic "shader_present is
> > stored in nvmem" support in panthor, and adjust the DT binding for
> > this.
> > 
> > This approach would again be generic across vendors from panthor's
> > perspective. It would, however, leak into DT the fact that we have
> > to implement this in the gpufreq device, rather than having the
> > efuse read directly.
> > 
> >> Have you considered moving this to drivers/soc/mediatek such that we
> >> can provide include/linux/mtk-mfg.h to panthor?
> > 
> > Having panthor read data structures from mtk-mfg-pmdomain would be a
> > last resort for me if none of the other approaches work out, as I'm
> > not super keen on adding vendor-specific code paths to panthor
> > itself. A new generic code path in panthor that is only used by one
> > vendor for now is different in that it has the potential to be used
> > by a different vendor's integration logic in the future as well.
> > 
> > So for now I'd like to keep it out of public includes and panthor as
> > much as possible, unless the two other approaches don't work out for
> > us.
> > 
> 
> I don't really like seeing more and more vendor specific APIs: MediaTek does
> suffer quite a lot from that, with cmdq being one of the examples - and the
> fact that it's not just MediaTek having those, but also others like Qualcomm,
> Rockchip, etc, is not an excuse to keep adding new ones when there are other
> alternatives.
> 
> Also another fact there is that I don't think that panthor should get any
> vendor specific "things" added (I mean, that should be avoided as much as
> possible).

The big issue to me is that vendors will always prefer to shoehorn
more vendor specific hacks into panthor, because the alternative is
to tell us how the hardware actually works. Which they all hate
doing. I definitely agree that we should work from the assumption
that panthor can support a Mali implementation without adding too
much special code for it, because in 10 years there will still be
new devices that use panthor as a driver, but few people will still
be testing MT8196 codepaths within panthor, which makes refactoring
prone to subtle breakage.

Not to mention that we don't want to rewrite all the vendor specific
code for Tyr.

> That said - what you will be trying to pass is really a value that is read
> from eFuse, with the EB firmware being a wrapper over that: if we want, we
> could see that yet-another-way of interfacing ourselves with reading nvmem
> where, instead of a direct MMIO read, we're asking a firmware to give us a
> readout.
> 
> This leads me to think that one of the possible options could be to actually
> register (perhaps as a new platform device, because I'm not sure that it could
> be feasible to register a pmdomain driver as a nvmem provider, but ultimately
> that is Ulf and Srinivas' call I guess) a nvmem driver that makes an IPI call
> to GPUEB and gives back the value to panthor through generic bindings.

Lee Jones will probably tell me to use MFD instead and that I'm silly
for not using MFD, so we might as well. Should I do that for v7 or
should v7 be less disruptive? Also, would I fillet out the clock
provider stuff into an MFD cell as well, or is that too much?

Also, nb: there is no IPI call for getting the SHADER_PRESENT value
that we know of. It's a location in the reserved shared memory
populated by the EB during the shared mem init, which ideally isn't
done multiple times by multiple drivers because that's dumb.

On the other hand, I don't really know what we get out of splitting
this up into several drivers, other than a more pleasing directory
structure and get_maintainers picking up the right subsystem people.

> >>>
> >>> The driver also exposes the actual achieved clock rate, as read back
> >>> from the MCU, as common clock framework clocks, by acting as a clock
> >>> provider as well.
> >>>
> >>> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> >>> ---
> >>>   drivers/pmdomain/mediatek/Kconfig            |   16 +
> >>>   drivers/pmdomain/mediatek/Makefile           |    1 +
> >>>   drivers/pmdomain/mediatek/mtk-mfg-pmdomain.c | 1027 ++++++++++++++++++++++++++
> >>>   3 files changed, 1044 insertions(+)
> >> [...]
> >>> +static int mtk_mfg_init_shared_mem(struct mtk_mfg *mfg)
> >>> +{
> >>> +       struct device *dev = &mfg->pdev->dev;
> >>> +       struct mtk_mfg_ipi_msg msg = {};
> >>> +       int ret;
> >>> +
> >>> +       dev_dbg(dev, "clearing GPUEB shared memory, 0x%X bytes\n", mfg->shared_mem_size);
> >>> +       memset_io(mfg->shared_mem, 0, mfg->shared_mem_size);
> >>> +
> >>> +       msg.cmd = CMD_INIT_SHARED_MEM;
> >>> +       msg.u.shared_mem.base = mfg->shared_mem_phys;
> >>> +       msg.u.shared_mem.size = mfg->shared_mem_size;
> >>> +
> >>> +       ret = mtk_mfg_send_ipi(mfg, &msg);
> >>> +       if (ret)
> >>> +               return ret;
> >>> +
> >>> +       if (readl(mfg->shared_mem) != GPUEB_MEM_MAGIC) {
> >> Add the offset GF_REG_MAGIC, even though it is 0.
> > 
> > Good catch, will do!
> > 
> >>
> >>> +               dev_err(dev, "EB did not initialise shared memory correctly\n");
> >>> +               return -EIO;
> >>> +       }
> >>> +
> >>> +       return 0;
> >>> +}
> >> [...]
> >>> +static int mtk_mfg_mt8196_init(struct mtk_mfg *mfg)
> >>> +{
> >>> +       void __iomem *e2_base;
> >>> +
> >>> +       e2_base = devm_platform_ioremap_resource_byname(mfg->pdev, "hw-revision");
> >>> +       if (IS_ERR(e2_base))
> >>> +               return dev_err_probe(&mfg->pdev->dev, PTR_ERR(e2_base),
> >>> +                                    "Couldn't get hw-revision register\n");
> >>> +
> >>> +       if (readl(e2_base) == MFG_MT8196_E2_ID)
> >>> +               mfg->ghpm_en_reg = RPC_DUMMY_REG_2;
> >>> +       else
> >>> +               mfg->ghpm_en_reg = RPC_GHPM_CFG0_CON;
> >>> +
> >>> +       return 0;
> >>> +};
> >> Extraneous semicolon.
> > 
> > Good catch, will fix!
> > 
> >>
> >>> +static int mtk_mfg_init_mbox(struct mtk_mfg *mfg)
> >>> +{
> >>> +       struct device *dev = &mfg->pdev->dev;
> >>> +       struct mtk_mfg_mbox *gf;
> >>> +       struct mtk_mfg_mbox *slp;
> >>> +
> >>> +       gf = devm_kzalloc(dev, sizeof(*gf), GFP_KERNEL);
> >>> +       if (!gf)
> >>> +               return -ENOMEM;
> >>> +
> >>> +       gf->rx_data = devm_kzalloc(dev, GPUEB_MBOX_MAX_RX_SIZE, GFP_KERNEL);
> >> It looks like gfx->rx_data can simply be "struct mtk_mfg_ipi_msg rx_data;".
> > 
> > Hmmm, good point. I'll change it to that.
> > 
> 
> Honestly, I prefer the current version. No strong opinions though.

And I just realised you're sorta right in that; struct mtk_mfg_mbox is
a type used by both the gpufreq mbox and the sleep mbox. The struct
mtk_mfg_ipi_msg type is only the right type to use for the gpufreq
mbox. By making rx_data a `struct mtk_mfg_ipi_msg` type, we're
allocating it for both channels, and in the case of the sleep mailbox,
it's the wrong type to boot (though not like sleep replies).

So yeah I think I'll keep the current construct. If this driver grows
another limb in the future that talks to yet another mailbox channel,
we'll appreciate not having to untangle that.

> [...]

Kind regards,
Nicolas Frattaroli

Re: [PATCH v6 7/7] pmdomain: mediatek: Add support for MFlexGraphics

[AngeloGioacchino Del Regno]

Il 06/10/25 14:16, Nicolas Frattaroli ha scritto:
> On Monday, 6 October 2025 13:37:28 Central European Summer Time AngeloGioacchino Del Regno wrote:
>> Il 06/10/25 12:58, Nicolas Frattaroli ha scritto:
>>> On Friday, 3 October 2025 23:41:16 Central European Summer Time Chia-I Wu wrote:
>>>> On Fri, Oct 3, 2025 at 1:16 PM Nicolas Frattaroli
>>>> <nicolas.frattaroli@collabora.com> wrote:
>>>>>
>>>>> Various MediaTek SoCs use GPU integration silicon named "MFlexGraphics"
>>>>> by MediaTek. On the MT8196 and MT6991 SoCs, interacting with this
>>>>> integration silicon is required to power on the GPU.
>>>>>
>>>>> This glue silicon is in the form of an embedded microcontroller running
>>>>> special-purpose firmware, which autonomously adjusts clocks and
>>>>> regulators.
>>>>>
>>>>> Implement a driver, modelled as a pmdomain driver with a
>>>>> set_performance_state operation, to support these SoCs.
>>>> I like this model a lot. Thanks!
>>>>
>>>> panthor might potentially need to interact with this driver beyond
>>>> what pmdomain provides. I am thinking about querying
>>>> GF_REG_SHADER_PRESENT. Not sure if we've heard back from the vendor.
>>>
>>> We did. The vendor confirmed this value is read by the EB firmware
>>> from an efuse, but considers the efuse address to be confidential.
>>> Consequently, we are not allowed to know the efuse address, or any
>>> of the other information required to read the efuse ourselves
>>> directly, such as what clocks and power domains it depends on.
>>>
>>> We therefore likely need to pass GF_REG_SHADER_PRESENT onward, but
>>> I do have an idea for that: struct generic_pm_domain has a member
>>> "cpumask_var_t cpus", which is there to communicate a mask of which
>>> CPUs are attached to a power domain if the power domain has the flag
>>> GENPD_FLAG_CPU_DOMAIN set. If the flag isn't set, the member is
>>> unused.
>>
>> cpumask_var_t is not going to be the right type for anything else that is
>> not a cpumask, as that is limited by NR_CPUS.
> 
> Hmmm, good point, I thought that would be done by the allocation
> but nope.
>   
>> You'd have to declare a new bitmap, suitable for generic devices, which may
>> get a little complicated on deciding how many bits would be enough... and
>> if we look at GPUs... AMD and nV have lots of cores, so that becomes a bit
>> unfeasible to put in a bitmap.
>>
>> Not sure then how generic that would be.
> 
> Yeah, at this point I'm rapidly approaching "shove stuff into pmdomain
> for no obvious pmdomain reason" territory, because we're not really
> communicating that this pmdomain is only tied to these cores, but
> rather that only these cores are present. Subtle difference that
> could come bite us in the rear once some other chip has several power
> domains that tie to different GPU shader cores.
> 

I think that the only thing that we might see at some point in the future is one
power domain per "set of shader cores", but not even sure that's really going to
ever be a thing, as it might just not be worth implementing from a firmware
perspective.

I am guessing here - we won't ever see one power domain per core.

Besides, also remember that many GPUs do have internal power management (as in,
per-core or per-core-set shutdown) so there already is such a power saving way.
That makes a vendor-specific implementation of that way less likely to see, even
though.. being cautious, never say never.

In any case, we can't predict the future, we can only guess - and evaluate things
that could or could not realistically make sense.

(anyway if you find a magic ball, please share, I need it for some other stuff :P)

>>
>>>
>>> This means we could overload its meaning, e.g. with a new flag, to
>>> communicate such masks for other purposes, since it's already the
>>> right type and all. This would be quite a generic way for hardware
>>> other than cpus to communicate such core masks. I was planning to
>>> develop and send out an RFC series for this, to gauge how much Ulf
>>> Hansson hates that approach.
>>>
>>> A different solution could be that mtk-mfg-pmdomain could act as an
>>> nvmem provider, and then we integrate generic "shader_present is
>>> stored in nvmem" support in panthor, and adjust the DT binding for
>>> this.
>>>
>>> This approach would again be generic across vendors from panthor's
>>> perspective. It would, however, leak into DT the fact that we have
>>> to implement this in the gpufreq device, rather than having the
>>> efuse read directly.
>>>
>>>> Have you considered moving this to drivers/soc/mediatek such that we
>>>> can provide include/linux/mtk-mfg.h to panthor?
>>>
>>> Having panthor read data structures from mtk-mfg-pmdomain would be a
>>> last resort for me if none of the other approaches work out, as I'm
>>> not super keen on adding vendor-specific code paths to panthor
>>> itself. A new generic code path in panthor that is only used by one
>>> vendor for now is different in that it has the potential to be used
>>> by a different vendor's integration logic in the future as well.
>>>
>>> So for now I'd like to keep it out of public includes and panthor as
>>> much as possible, unless the two other approaches don't work out for
>>> us.
>>>
>>
>> I don't really like seeing more and more vendor specific APIs: MediaTek does
>> suffer quite a lot from that, with cmdq being one of the examples - and the
>> fact that it's not just MediaTek having those, but also others like Qualcomm,
>> Rockchip, etc, is not an excuse to keep adding new ones when there are other
>> alternatives.
>>
>> Also another fact there is that I don't think that panthor should get any
>> vendor specific "things" added (I mean, that should be avoided as much as
>> possible).
> 
> The big issue to me is that vendors will always prefer to shoehorn
> more vendor specific hacks into panthor, because the alternative is
> to tell us how the hardware actually works. Which they all hate
> doing.

That's a bit too much pessimistic... I hope.

> I definitely agree that we should work from the assumption
> that panthor can support a Mali implementation without adding too
> much special code for it, because in 10 years there will still be
> new devices that use panthor as a driver, but few people will still
> be testing MT8196 codepaths within panthor, which makes refactoring
> prone to subtle breakage.

I had no doubt that you were thinking alike, but happy to see that confirmed.

> 
> Not to mention that we don't want to rewrite all the vendor specific
> code for Tyr.
> 
>> That said - what you will be trying to pass is really a value that is read
>> from eFuse, with the EB firmware being a wrapper over that: if we want, we
>> could see that yet-another-way of interfacing ourselves with reading nvmem
>> where, instead of a direct MMIO read, we're asking a firmware to give us a
>> readout.
>>
>> This leads me to think that one of the possible options could be to actually
>> register (perhaps as a new platform device, because I'm not sure that it could
>> be feasible to register a pmdomain driver as a nvmem provider, but ultimately
>> that is Ulf and Srinivas' call I guess) a nvmem driver that makes an IPI call
>> to GPUEB and gives back the value to panthor through generic bindings.
> 
> Lee Jones will probably tell me to use MFD instead and that I'm silly
> for not using MFD, so we might as well. Should I do that for v7 or
> should v7 be less disruptive? Also, would I fillet out the clock
> provider stuff into an MFD cell as well, or is that too much?
> 
> Also, nb: there is no IPI call for getting the SHADER_PRESENT value
> that we know of. It's a location in the reserved shared memory
> populated by the EB during the shared mem init, which ideally isn't
> done multiple times by multiple drivers because that's dumb.
> 
> On the other hand, I don't really know what we get out of splitting
> this up into several drivers, other than a more pleasing directory
> structure and get_maintainers picking up the right subsystem people.
> 

I'm not sure. A power controller being also a clock provider isn't entirely
uncommon (look at i.MX8 MP), but then think about it: if you add a MFD, you
are still introducing vendor APIs around... as you'd need a way to do your
piece of communication with the EB.

The benefit, then, is only what you just said.

There are literally too many alternatives to do the very same as what you're
doing here, including having a (firmware|soc)/mediatek-gpueb.c driver managing
only the communication part, and the rest all in small different drivers, or...

...you could share the reserved-memory between the two drivers, and have the efuse
driver getting a power domain from mtk-mfg-pmdomain (to check and call mfg power
on), then reading the byte(s) that you need from GF_REG_SHADER_PRESENT from there.

Not sure then what's the best option.

One thing I'm sure about is that you're setting how everything works *now*, and
changing that later is going to cause lots of pain and lots of suffering, so a
decision must be taken right now.

>>>>>
>>>>> The driver also exposes the actual achieved clock rate, as read back
>>>>> from the MCU, as common clock framework clocks, by acting as a clock
>>>>> provider as well.
>>>>>
>>>>> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>>>>> ---
>>>>>    drivers/pmdomain/mediatek/Kconfig            |   16 +
>>>>>    drivers/pmdomain/mediatek/Makefile           |    1 +
>>>>>    drivers/pmdomain/mediatek/mtk-mfg-pmdomain.c | 1027 ++++++++++++++++++++++++++
>>>>>    3 files changed, 1044 insertions(+)
>>>> [...]
>>>>> +static int mtk_mfg_init_shared_mem(struct mtk_mfg *mfg)
>>>>> +{
>>>>> +       struct device *dev = &mfg->pdev->dev;
>>>>> +       struct mtk_mfg_ipi_msg msg = {};
>>>>> +       int ret;
>>>>> +
>>>>> +       dev_dbg(dev, "clearing GPUEB shared memory, 0x%X bytes\n", mfg->shared_mem_size);
>>>>> +       memset_io(mfg->shared_mem, 0, mfg->shared_mem_size);
>>>>> +
>>>>> +       msg.cmd = CMD_INIT_SHARED_MEM;
>>>>> +       msg.u.shared_mem.base = mfg->shared_mem_phys;
>>>>> +       msg.u.shared_mem.size = mfg->shared_mem_size;
>>>>> +
>>>>> +       ret = mtk_mfg_send_ipi(mfg, &msg);
>>>>> +       if (ret)
>>>>> +               return ret;
>>>>> +
>>>>> +       if (readl(mfg->shared_mem) != GPUEB_MEM_MAGIC) {
>>>> Add the offset GF_REG_MAGIC, even though it is 0.
>>>
>>> Good catch, will do!
>>>
>>>>
>>>>> +               dev_err(dev, "EB did not initialise shared memory correctly\n");
>>>>> +               return -EIO;
>>>>> +       }
>>>>> +
>>>>> +       return 0;
>>>>> +}
>>>> [...]
>>>>> +static int mtk_mfg_mt8196_init(struct mtk_mfg *mfg)
>>>>> +{
>>>>> +       void __iomem *e2_base;
>>>>> +
>>>>> +       e2_base = devm_platform_ioremap_resource_byname(mfg->pdev, "hw-revision");
>>>>> +       if (IS_ERR(e2_base))
>>>>> +               return dev_err_probe(&mfg->pdev->dev, PTR_ERR(e2_base),
>>>>> +                                    "Couldn't get hw-revision register\n");
>>>>> +
>>>>> +       if (readl(e2_base) == MFG_MT8196_E2_ID)
>>>>> +               mfg->ghpm_en_reg = RPC_DUMMY_REG_2;
>>>>> +       else
>>>>> +               mfg->ghpm_en_reg = RPC_GHPM_CFG0_CON;
>>>>> +
>>>>> +       return 0;
>>>>> +};
>>>> Extraneous semicolon.
>>>
>>> Good catch, will fix!
>>>
>>>>
>>>>> +static int mtk_mfg_init_mbox(struct mtk_mfg *mfg)
>>>>> +{
>>>>> +       struct device *dev = &mfg->pdev->dev;
>>>>> +       struct mtk_mfg_mbox *gf;
>>>>> +       struct mtk_mfg_mbox *slp;
>>>>> +
>>>>> +       gf = devm_kzalloc(dev, sizeof(*gf), GFP_KERNEL);
>>>>> +       if (!gf)
>>>>> +               return -ENOMEM;
>>>>> +
>>>>> +       gf->rx_data = devm_kzalloc(dev, GPUEB_MBOX_MAX_RX_SIZE, GFP_KERNEL);
>>>> It looks like gfx->rx_data can simply be "struct mtk_mfg_ipi_msg rx_data;".
>>>
>>> Hmmm, good point. I'll change it to that.
>>>
>>
>> Honestly, I prefer the current version. No strong opinions though.
> 
> And I just realised you're sorta right in that; struct mtk_mfg_mbox is
> a type used by both the gpufreq mbox and the sleep mbox. The struct
> mtk_mfg_ipi_msg type is only the right type to use for the gpufreq
> mbox. By making rx_data a `struct mtk_mfg_ipi_msg` type, we're
> allocating it for both channels, and in the case of the sleep mailbox,
> it's the wrong type to boot (though not like sleep replies).
> 
> So yeah I think I'll keep the current construct. If this driver grows
> another limb in the future that talks to yet another mailbox channel,
> we'll appreciate not having to untangle that.

...that was the implicit reasoning around my statement, yes.

Cheers,
Angelo

> 
>> [...]
> 
> Kind regards,
> Nicolas Frattaroli
> 
> 

Re: [PATCH v6 7/7] pmdomain: mediatek: Add support for MFlexGraphics

[Chia-I Wu]

On Mon, Oct 6, 2025 at 7:28 AM AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> Il 06/10/25 14:16, Nicolas Frattaroli ha scritto:
> > On Monday, 6 October 2025 13:37:28 Central European Summer Time AngeloGioacchino Del Regno wrote:
> >> Il 06/10/25 12:58, Nicolas Frattaroli ha scritto:
> >>> On Friday, 3 October 2025 23:41:16 Central European Summer Time Chia-I Wu wrote:
> >>>> On Fri, Oct 3, 2025 at 1:16 PM Nicolas Frattaroli
> >>>> <nicolas.frattaroli@collabora.com> wrote:
> >>>>>
> >>>>> Various MediaTek SoCs use GPU integration silicon named "MFlexGraphics"
> >>>>> by MediaTek. On the MT8196 and MT6991 SoCs, interacting with this
> >>>>> integration silicon is required to power on the GPU.
> >>>>>
> >>>>> This glue silicon is in the form of an embedded microcontroller running
> >>>>> special-purpose firmware, which autonomously adjusts clocks and
> >>>>> regulators.
> >>>>>
> >>>>> Implement a driver, modelled as a pmdomain driver with a
> >>>>> set_performance_state operation, to support these SoCs.
> >>>> I like this model a lot. Thanks!
> >>>>
> >>>> panthor might potentially need to interact with this driver beyond
> >>>> what pmdomain provides. I am thinking about querying
> >>>> GF_REG_SHADER_PRESENT. Not sure if we've heard back from the vendor.
> >>>
> >>> We did. The vendor confirmed this value is read by the EB firmware
> >>> from an efuse, but considers the efuse address to be confidential.
> >>> Consequently, we are not allowed to know the efuse address, or any
> >>> of the other information required to read the efuse ourselves
> >>> directly, such as what clocks and power domains it depends on.
> >>>
> >>> We therefore likely need to pass GF_REG_SHADER_PRESENT onward, but
> >>> I do have an idea for that: struct generic_pm_domain has a member
> >>> "cpumask_var_t cpus", which is there to communicate a mask of which
> >>> CPUs are attached to a power domain if the power domain has the flag
> >>> GENPD_FLAG_CPU_DOMAIN set. If the flag isn't set, the member is
> >>> unused.
> >>
> >> cpumask_var_t is not going to be the right type for anything else that is
> >> not a cpumask, as that is limited by NR_CPUS.
> >
> > Hmmm, good point, I thought that would be done by the allocation
> > but nope.
> >
> >> You'd have to declare a new bitmap, suitable for generic devices, which may
> >> get a little complicated on deciding how many bits would be enough... and
> >> if we look at GPUs... AMD and nV have lots of cores, so that becomes a bit
> >> unfeasible to put in a bitmap.
> >>
> >> Not sure then how generic that would be.
> >
> > Yeah, at this point I'm rapidly approaching "shove stuff into pmdomain
> > for no obvious pmdomain reason" territory, because we're not really
> > communicating that this pmdomain is only tied to these cores, but
> > rather that only these cores are present. Subtle difference that
> > could come bite us in the rear once some other chip has several power
> > domains that tie to different GPU shader cores.
> >
>
> I think that the only thing that we might see at some point in the future is one
> power domain per "set of shader cores", but not even sure that's really going to
> ever be a thing, as it might just not be worth implementing from a firmware
> perspective.
>
> I am guessing here - we won't ever see one power domain per core.
>
> Besides, also remember that many GPUs do have internal power management (as in,
> per-core or per-core-set shutdown) so there already is such a power saving way.
> That makes a vendor-specific implementation of that way less likely to see, even
> though.. being cautious, never say never.
>
> In any case, we can't predict the future, we can only guess - and evaluate things
> that could or could not realistically make sense.
>
> (anyway if you find a magic ball, please share, I need it for some other stuff :P)
>
> >>
> >>>
> >>> This means we could overload its meaning, e.g. with a new flag, to
> >>> communicate such masks for other purposes, since it's already the
> >>> right type and all. This would be quite a generic way for hardware
> >>> other than cpus to communicate such core masks. I was planning to
> >>> develop and send out an RFC series for this, to gauge how much Ulf
> >>> Hansson hates that approach.
> >>>
> >>> A different solution could be that mtk-mfg-pmdomain could act as an
> >>> nvmem provider, and then we integrate generic "shader_present is
> >>> stored in nvmem" support in panthor, and adjust the DT binding for
> >>> this.
> >>>
> >>> This approach would again be generic across vendors from panthor's
> >>> perspective. It would, however, leak into DT the fact that we have
> >>> to implement this in the gpufreq device, rather than having the
> >>> efuse read directly.
> >>>
> >>>> Have you considered moving this to drivers/soc/mediatek such that we
> >>>> can provide include/linux/mtk-mfg.h to panthor?
> >>>
> >>> Having panthor read data structures from mtk-mfg-pmdomain would be a
> >>> last resort for me if none of the other approaches work out, as I'm
> >>> not super keen on adding vendor-specific code paths to panthor
> >>> itself. A new generic code path in panthor that is only used by one
> >>> vendor for now is different in that it has the potential to be used
> >>> by a different vendor's integration logic in the future as well.
> >>>
> >>> So for now I'd like to keep it out of public includes and panthor as
> >>> much as possible, unless the two other approaches don't work out for
> >>> us.
> >>>
> >>
> >> I don't really like seeing more and more vendor specific APIs: MediaTek does
> >> suffer quite a lot from that, with cmdq being one of the examples - and the
> >> fact that it's not just MediaTek having those, but also others like Qualcomm,
> >> Rockchip, etc, is not an excuse to keep adding new ones when there are other
> >> alternatives.
> >>
> >> Also another fact there is that I don't think that panthor should get any
> >> vendor specific "things" added (I mean, that should be avoided as much as
> >> possible).
> >
> > The big issue to me is that vendors will always prefer to shoehorn
> > more vendor specific hacks into panthor, because the alternative is
> > to tell us how the hardware actually works. Which they all hate
> > doing.
>
> That's a bit too much pessimistic... I hope.
>
> > I definitely agree that we should work from the assumption
> > that panthor can support a Mali implementation without adding too
> > much special code for it, because in 10 years there will still be
> > new devices that use panthor as a driver, but few people will still
> > be testing MT8196 codepaths within panthor, which makes refactoring
> > prone to subtle breakage.
>
> I had no doubt that you were thinking alike, but happy to see that confirmed.
>
> >
> > Not to mention that we don't want to rewrite all the vendor specific
> > code for Tyr.
> >
> >> That said - what you will be trying to pass is really a value that is read
> >> from eFuse, with the EB firmware being a wrapper over that: if we want, we
> >> could see that yet-another-way of interfacing ourselves with reading nvmem
> >> where, instead of a direct MMIO read, we're asking a firmware to give us a
> >> readout.
> >>
> >> This leads me to think that one of the possible options could be to actually
> >> register (perhaps as a new platform device, because I'm not sure that it could
> >> be feasible to register a pmdomain driver as a nvmem provider, but ultimately
> >> that is Ulf and Srinivas' call I guess) a nvmem driver that makes an IPI call
> >> to GPUEB and gives back the value to panthor through generic bindings.
> >
> > Lee Jones will probably tell me to use MFD instead and that I'm silly
> > for not using MFD, so we might as well. Should I do that for v7 or
> > should v7 be less disruptive? Also, would I fillet out the clock
> > provider stuff into an MFD cell as well, or is that too much?
> >
> > Also, nb: there is no IPI call for getting the SHADER_PRESENT value
> > that we know of. It's a location in the reserved shared memory
> > populated by the EB during the shared mem init, which ideally isn't
> > done multiple times by multiple drivers because that's dumb.
> >
> > On the other hand, I don't really know what we get out of splitting
> > this up into several drivers, other than a more pleasing directory
> > structure and get_maintainers picking up the right subsystem people.
> >
>
> I'm not sure. A power controller being also a clock provider isn't entirely
> uncommon (look at i.MX8 MP), but then think about it: if you add a MFD, you
> are still introducing vendor APIs around... as you'd need a way to do your
> piece of communication with the EB.
>
> The benefit, then, is only what you just said.
>
> There are literally too many alternatives to do the very same as what you're
> doing here, including having a (firmware|soc)/mediatek-gpueb.c driver managing
> only the communication part, and the rest all in small different drivers, or...
>
> ...you could share the reserved-memory between the two drivers, and have the efuse
> driver getting a power domain from mtk-mfg-pmdomain (to check and call mfg power
> on), then reading the byte(s) that you need from GF_REG_SHADER_PRESENT from there.
>
> Not sure then what's the best option.
>
> One thing I'm sure about is that you're setting how everything works *now*, and
> changing that later is going to cause lots of pain and lots of suffering, so a
> decision must be taken right now.
If mtk-mfg registers a nvmem cell, I guess all panthor needs to do is
to handle something like:

  nvmem-cells = <&gpueb_shmem_shader_present>;
  nvmem-cell-names = "shader-present";

That sounds like a reasonable generalization from panthor's point of view.

>
> >>>>>
> >>>>> The driver also exposes the actual achieved clock rate, as read back
> >>>>> from the MCU, as common clock framework clocks, by acting as a clock
> >>>>> provider as well.
> >>>>>
> >>>>> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> >>>>> ---
> >>>>>    drivers/pmdomain/mediatek/Kconfig            |   16 +
> >>>>>    drivers/pmdomain/mediatek/Makefile           |    1 +
> >>>>>    drivers/pmdomain/mediatek/mtk-mfg-pmdomain.c | 1027 ++++++++++++++++++++++++++
> >>>>>    3 files changed, 1044 insertions(+)
> >>>> [...]
> >>>>> +static int mtk_mfg_init_shared_mem(struct mtk_mfg *mfg)
> >>>>> +{
> >>>>> +       struct device *dev = &mfg->pdev->dev;
> >>>>> +       struct mtk_mfg_ipi_msg msg = {};
> >>>>> +       int ret;
> >>>>> +
> >>>>> +       dev_dbg(dev, "clearing GPUEB shared memory, 0x%X bytes\n", mfg->shared_mem_size);
> >>>>> +       memset_io(mfg->shared_mem, 0, mfg->shared_mem_size);
> >>>>> +
> >>>>> +       msg.cmd = CMD_INIT_SHARED_MEM;
> >>>>> +       msg.u.shared_mem.base = mfg->shared_mem_phys;
> >>>>> +       msg.u.shared_mem.size = mfg->shared_mem_size;
> >>>>> +
> >>>>> +       ret = mtk_mfg_send_ipi(mfg, &msg);
> >>>>> +       if (ret)
> >>>>> +               return ret;
> >>>>> +
> >>>>> +       if (readl(mfg->shared_mem) != GPUEB_MEM_MAGIC) {
> >>>> Add the offset GF_REG_MAGIC, even though it is 0.
> >>>
> >>> Good catch, will do!
> >>>
> >>>>
> >>>>> +               dev_err(dev, "EB did not initialise shared memory correctly\n");
> >>>>> +               return -EIO;
> >>>>> +       }
> >>>>> +
> >>>>> +       return 0;
> >>>>> +}
> >>>> [...]
> >>>>> +static int mtk_mfg_mt8196_init(struct mtk_mfg *mfg)
> >>>>> +{
> >>>>> +       void __iomem *e2_base;
> >>>>> +
> >>>>> +       e2_base = devm_platform_ioremap_resource_byname(mfg->pdev, "hw-revision");
> >>>>> +       if (IS_ERR(e2_base))
> >>>>> +               return dev_err_probe(&mfg->pdev->dev, PTR_ERR(e2_base),
> >>>>> +                                    "Couldn't get hw-revision register\n");
> >>>>> +
> >>>>> +       if (readl(e2_base) == MFG_MT8196_E2_ID)
> >>>>> +               mfg->ghpm_en_reg = RPC_DUMMY_REG_2;
> >>>>> +       else
> >>>>> +               mfg->ghpm_en_reg = RPC_GHPM_CFG0_CON;
> >>>>> +
> >>>>> +       return 0;
> >>>>> +};
> >>>> Extraneous semicolon.
> >>>
> >>> Good catch, will fix!
> >>>
> >>>>
> >>>>> +static int mtk_mfg_init_mbox(struct mtk_mfg *mfg)
> >>>>> +{
> >>>>> +       struct device *dev = &mfg->pdev->dev;
> >>>>> +       struct mtk_mfg_mbox *gf;
> >>>>> +       struct mtk_mfg_mbox *slp;
> >>>>> +
> >>>>> +       gf = devm_kzalloc(dev, sizeof(*gf), GFP_KERNEL);
> >>>>> +       if (!gf)
> >>>>> +               return -ENOMEM;
> >>>>> +
> >>>>> +       gf->rx_data = devm_kzalloc(dev, GPUEB_MBOX_MAX_RX_SIZE, GFP_KERNEL);
> >>>> It looks like gfx->rx_data can simply be "struct mtk_mfg_ipi_msg rx_data;".
> >>>
> >>> Hmmm, good point. I'll change it to that.
> >>>
> >>
> >> Honestly, I prefer the current version. No strong opinions though.
> >
> > And I just realised you're sorta right in that; struct mtk_mfg_mbox is
> > a type used by both the gpufreq mbox and the sleep mbox. The struct
> > mtk_mfg_ipi_msg type is only the right type to use for the gpufreq
> > mbox. By making rx_data a `struct mtk_mfg_ipi_msg` type, we're
> > allocating it for both channels, and in the case of the sleep mailbox,
> > it's the wrong type to boot (though not like sleep replies).
> >
> > So yeah I think I'll keep the current construct. If this driver grows
> > another limb in the future that talks to yet another mailbox channel,
> > we'll appreciate not having to untangle that.
>
> ...that was the implicit reasoning around my statement, yes.
Sounds good.
>
> Cheers,
> Angelo
>
> >
> >> [...]
> >
> > Kind regards,
> > Nicolas Frattaroli
> >
> >
>
>

Re: [PATCH v6 1/7] dt-bindings: gpu: mali-valhall-csf: add mediatek,mt8196-mali variant

[Rob Herring (Arm)]

On Fri, 03 Oct 2025 22:15:03 +0200, Nicolas Frattaroli wrote:
> The Mali-based GPU on the MediaTek MT8196 SoC uses a separate MCU to
> control the power and frequency of the GPU. This is modelled as a power
> domain and clock provider.
> 
> It lets us omit the OPP tables from the device tree, as those can now be
> enumerated at runtime from the MCU.
> 
> Add the necessary schema logic to handle what this SoC expects in terms
> of clocks and power-domains.
> 
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
>  .../bindings/gpu/arm,mali-valhall-csf.yaml         | 40 ++++++++++++++++++++--
>  1 file changed, 38 insertions(+), 2 deletions(-)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

Re: [PATCH v6 2/7] dt-bindings: power: Add MT8196 GPU frequency control binding

[Rob Herring (Arm)]

On Fri, 03 Oct 2025 22:15:04 +0200, Nicolas Frattaroli wrote:
> On the MT8196 and MT6991 SoCs, the GPU power and frequency is controlled
> by some integration logic, referred to as "MFlexGraphics" by MediaTek,
> which comes in the form of an embedded controller running
> special-purpose firmware.
> 
> This controller takes care of the regulators and PLL clock frequencies
> to squeeze the maximum amount of power out of the silicon.
> 
> Add a binding which models it as a power domain.
> 
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
>  .../bindings/power/mediatek,mt8196-gpufreq.yaml    | 117 +++++++++++++++++++++
>  1 file changed, 117 insertions(+)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>