drm/amd/pm: refactor PPT limits by controller and power source

The scalar PPT model has several structural limitations:

- Controller identity, power source, capability, and PMFW state share
  the same fields.
- Combined callbacks cannot address PPT0 and PPT1 independently.
- Cached current limits can become stale after PMFW reset.

Refactor the model around these rules:

- Index ranges by AC/DC source and PPT0/PPT1 controller.
- Store normal and overdrive capabilities separately.
- Pass the controller to get and set callbacks.
- Keep slow and fast names as semantic aliases.

Assign each value to a single owner:

- PPTable or platform initialization supplies constant capabilities.
- PMFW supplies runtime state.
- Common code selects the active source and overdrive range.

Van Gogh defaults are initialized once, while firmware without PPT query
support remains usable. Capable SMU 13.0.6 and SMU 15.0.8 platforms
expose PPT1 through the same interface. A writable controller must also
provide a setter callback.

Signed-off-by: Yang Wang <kevinyang.wang@amd.com>
Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

0 files changed, 0 insertions, 0 deletions