[RFC PATCH 0/2] drm/nouveau: select GT21x performance levels by load through devfreq

[Hamin Sung]

On GT21x (GT215, GT216, GT218, MCP89), nouveau can reclock by hand, and
booting with nouveau.config=NvClkMode=auto selects the clock subdev's
automatic mode.  Nothing adjusts the automatic pstate on these GPUs, so
automatic mode means the highest pstate.

This series measures graphics engine load with the PDAEMON idle counters
(patch 1) and lets the devfreq simple_ondemand governor choose the pstate
from it while automatic mode is selected (patch 2), along the lines of
the Tegra devfreq support from commit 6ca1701cecdb ("drm/nouveau: Support
devfreq for Tegra").  Nothing changes unless NvClkMode=auto is given at
load time, and a fixed pstate written to debugfs still wins.

The devfreq device lives in the DRM layer rather than next to
gk20a_devfreq.c, because PCI suspend, resume, runtime PM and unbind are
handled in nouveau_drm.c, while nvkm subdev init runs again on every
resume.

On GT21x boards that need memory link training, the first pstate change
runs into the "scheduling while atomic" bug fixed by "drm/nouveau/fb/gt215:
don't sleep with PFIFO paused during link training", which I sent
separately for drm-misc-fixes.  This series makes that first change happen
automatically, so it should go in after that fix.

Testing:

  - built with W=1 and sparse, with and without CONFIG_PM_DEVFREQ, and the
    Kconfig change checked on x86 and on an arm64 defconfig with Tegra
  - GeForce 310M (GT218), 6.18.54 backport: its VBIOS has a single usable
    performance level (the 135 and 405 MHz entries are marked 0xff), so the
    series as posted does not register a devfreq device there.  With a
    local change allowing a single level, devfreq registered
    (simple_ondemand, one OPP at 625 MHz, delayed 100 ms timer) and the
    load samples read 0% when idle, 3-4% while kmscube rendered at 60 fps,
    and 0% again afterwards.

So the counters and the sampling path work, but pstate changes driven by
the governor are untested: I have no GT21x board with several performance
levels.  Reports from anyone whose debugfs pstate file lists more than one
level would help, which is why this is an RFC.

Questions:

  - Is the DRM-layer placement fine, or should this move into nvkm and
    share code with gk20a_devfreq.c?
  - Selecting DEVFREQ_GOV_SIMPLE_ONDEMAND from DRM_NOUVEAU when PM_DEVFREQ
    is enabled: acceptable, or should it be left to the configuration?
  - The 100 ms polling interval and the 50%/20% thresholds were chosen to
    keep the costly GT21x pstate changes infrequent; better defaults are
    welcome.

These patches were written with an AI coding assistant (see the
Assisted-by tags) at my direction, from a session that read the nouveau
clk, pmu and devfreq code and the envytools PDAEMON counter
documentation; the assistant also ran the builds and the hardware test
above on my machine.  I have reviewed the code and take responsibility
for it.

Hamin Sung (2):
  drm/nouveau/pmu/gt215: add graphics engine load counters
  drm/nouveau: select GT21x performance levels by load through devfreq

 drivers/gpu/drm/nouveau/Kbuild                |   1 +
 drivers/gpu/drm/nouveau/Kconfig               |   1 +
 .../gpu/drm/nouveau/include/nvkm/subdev/pmu.h |   2 +
 drivers/gpu/drm/nouveau/nouveau_devfreq.c     | 328 ++++++++++++++++++
 drivers/gpu/drm/nouveau/nouveau_devfreq.h     |  19 +
 drivers/gpu/drm/nouveau/nouveau_drm.c         |   7 +
 drivers/gpu/drm/nouveau/nouveau_drv.h         |   1 +
 .../gpu/drm/nouveau/nvkm/subdev/pmu/base.c    |  29 ++
 .../gpu/drm/nouveau/nvkm/subdev/pmu/gt215.c   |  40 +++
 .../gpu/drm/nouveau/nvkm/subdev/pmu/priv.h    |   5 +
 10 files changed, 433 insertions(+)
 create mode 100644 drivers/gpu/drm/nouveau/nouveau_devfreq.c
 create mode 100644 drivers/gpu/drm/nouveau/nouveau_devfreq.h


base-commit: 70456f05d4b6396b22048c4b8cd3cb98ecf9f9e3
-- 
2.55.0