AMD BC-250 (Cyan Skillfish, gfx1013): can the VCN 2.0.3 power domain be brought up?

Subject: AMD BC-250 (Cyan Skillfish, gfx1013): can the VCN 2.0.3 power
domain be brought up?

Hi,

I'm working with an AMD BC-250 (ASRock mining blade, PCI 1002:13FE, Cyan
Skillfish / gfx1013, GC 10.1.3) on Fedora 44 with the stock 6.19.10 kernel.
Hardware video decode is unavailable, and I would like to ask whether that is a
firmware limitation or just an untested configuration.

The short version: in amdgpu_discovery_set_mm_ip_blocks(), UVD_HWIP
IP_VERSION(2, 0, 3) has an explicitly empty case, so neither vcn_v2_0_ip_block
nor jpeg_v2_0_ip_block is ever registered. Is that intentional because the
SMU 11.8 PMFW has no VCN power management, or is it simply that this ASIC was
never validated for video?

What I measured, in case it is useful:

- The IP discovery table does report the block.
  /sys/class/drm/card1/device/ip_discovery/die/0/12/0/ gives
  major.minor.rev = 2.0.3, harvest = 0x0, base_addr = 0x00007800. The
  HARVEST_INFO table in the discovery binary is empty.

- The whole UVD register aperture is unreadable. Through debugfs amdgpu_regs,
  both segments return 0xFFFFFFFF: mmCC_UVD_HARVESTING, mmUVD_POWER_STATUS,
  mmUVD_PGFSM_CONFIG, mmUVD_PGFSM_STATUS, mmUVD_STATUS, and the JPEG registers
  in the 0x7800 segment. mmGRBM_STATUS through the same read path returns
  0x00003028, so the access method itself is fine.

- Writing the value that vcn_v2_0_disable_static_power_gating() would write
  with pg_flags == 0 (0x00055555 to mmUVD_PGFSM_CONFIG) is accepted but has no
  effect; PGFSM_STATUS stays 0xFFFFFFFF. The PGFSM itself therefore appears to
  sit inside the unpowered domain.

- nv_common_early_init() sets cg_flags = 0 and pg_flags = 0 for GC 10.1.3, and
  cyan_skillfish_ppt_funcs implements no .dpm_set_vcn_enable, so nothing ever
  requests a VCN power-up. smu_v11_8_ppsmc.h has no VCN-related message, and
  smu_v11_8_pmfw.h has no VCN feature bit; the clock level fields cover
  LCLK / MP0CLK / FCLK / SOCCLK / DCEFCLK only.

- From the platform firmware (AGESA!V9 RBNBDK-BL5 46.1.2.220426): the PMFW is
  PSP directory entry type 0x08 / 0x12, version 0.58.7.1, and it contains the
  string "AMD BC-250", so it looks board-specific. I could not find any VCN,
  UVD or JPEG reference anywhere in the UEFI image.

My questions:

1. Is IP_VERSION(2, 0, 3) deliberately unhandled because the PMFW on this SOC
   cannot power up the VCN domain?

2. If a power-up path does exist -- an SMU message, or something the ABL /
   AGESA is expected to do -- could you point at it? I am happy to test
   patches.

3. Could the block be disabled in a way the harvest table would not reflect?

I am not asking for support on an unsupported product. A factual answer either
way would help: the community documentation for this board currently attributes
the missing decode to a signed-firmware restriction, which does not match what
I see -- the VCN 2.x ucode is present in linux-firmware and this ASIC uses
AMDGPU_FW_LOAD_DIRECT -- and I would rather correct that than let people keep
chasing it.

Thanks for any pointer,
Daniel