hisi: give gk7205v500/v510/v530 their own pad table

[widgetii]

Problem

The gk7205v500 family (GK7205V500/V510/V530, XMedia XM720xxx) was handed EV200regs. It shares ev200's iocfg register addresses but not its selectors, so on these chips:

• ipctool reginfo names the wrong function for many pads;
• ipchw_padmux_by_func() finds no PWM pad past PWM3. On a Zenointel SD-2N-4G (GK7205V510) the two IR lamps sit on PWM8 (pad GPIO56) and PWM9 (pad GPIO55), which the ev200 table calls LCD_DATA4 and "reserved". majestic's PWM backlight asks this table which pad carries a channel, so it could not drive either lamp.

Change

A V500regs table, selected for IS_7205V500:

• Selectors: generated from XMedia's PIN_OUT_V510.xlsx. Sheet 1 gives each pin's function numbers, which are the selector values; sheet 3 gives the register addresses.
• V530: PIN_OUT_V530.xlsx agrees on all 93 rows but one, where it adds FMC_STARTUP_DISABLE as selector 2 of UART0_TXD; that is merged in. The QFN V330/V230 pin-outs are strict subsets.
• iocfg_reg0-5: the power-sequencing pins, which have no selector.
• padmux_names: regenerated; gen_padmux_names.py --check passes.

Tests

• reginfo_test: PWM8, PWM9 and PWM11 resolve to the right pads and selectors, and pad 56 no longer offers LCD_DATA4.
• 7205V510 joins the table-integrity sweep.

Verified on hardware

On a GK7205V510, majestic built against this table finds PWM8 on pad 56 (selector 5) and PWM9 on pad 55 (selector 2). It muxes both and drives both lamps at the same duty: both channels latch the same high time, and the lamps draw about 3 W each.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Use a dedicated pad-mux table for GK7205V500-family chips

🐞 Bug fix 🕐 20-40 Minutes

AI Description

• Replace EV200 selectors with a dedicated GK7205V500-family table to report and select the correct
 pad functions.
• Expose PWM8–PWM11 and other family-specific functions so PWM consumers can find their pads.
• Add regression checks for PWM selectors, pad names, and table integrity.

Diagram

graph TD
  CHIP{"V500 family?"} --> TABLE["V500 pad table"] --> API["Padmux lookup"] --> PWM["PWM consumers"]
  NAMES["Function names"] --> API --> CLI["reginfo CLI"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Override differing EV200 selectors

• ➕ Avoids duplicating register addresses shared with EV200.
• ➖ Requires maintaining a broad set of family-specific overrides.
• ➖ Makes it harder to inspect each chip family's complete selector map.

Recommendation: Keep the dedicated table. Although sharing EV200 addresses could reduce duplication, the selectors differ across many pads; an explicit V500 map makes lookup behavior and hardware review clearer.

Files changed (4) +326 / -19

Bug fix (3) +287 / -19

padmux_names.cAdd generated V4 function-name initializers +21/-6

Add generated V4 function-name initializers

• Adds names for V500-family PWM channels and FMC_STARTUP_DISABLE, and enables GPIO9_2 and IR_IN names for V4 builds. These names allow the new table's function offsets to resolve correctly.

src/padmux_names.c

padmux_names.hExpose V500-family function offsets in generated names header +42/-12

Expose V500-family function offsets in generated names header

• Adds corresponding V4 name fields and PMX offsets for the new table's functions. Extends V4 guards for existing function names now used by that table.

src/padmux_names.h

reginfo.cSelect a dedicated GK7205V500-family register table +224/-1

Select a dedicated GK7205V500-family register table

• Adds a 93-row V500 pad table with family-specific selector values, including PWM8–PWM11 and the V530 FMC_STARTUP_DISABLE alternative. Changes IS_7205V500 dispatch to use it instead of EV200regs.

src/reginfo.c

Tests (1) +39 / -0

reginfo_test.cCover V510 PWM lookups and table integrity +39/-0

Cover V510 PWM lookups and table integrity

• Checks PWM8, PWM9, and PWM11 addresses and selectors, rejects the old LCD_DATA4 name on pad 56, and keeps SVB_PWM distinct. Adds 7205V510 to the table-integrity sweep.

src/reginfo_test.c

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. V500 and V510 offer an unsupported pad mode ✓ Resolved

Description

V500_iocfg_reg86 includes FMC_STARTUP_DISABLE even though the table comment identifies it as the
selector added by the V530 pin-out. Because all three chips use V500regs, callers on a V500 or
V510 can discover that mode and ask ipchw_padmux_set to write selector 2 to the UART0 transmit
pad.

Code

src/reginfo.c[R2265-2266]

+MUXCTRL(V500_iocfg_reg86, 0x100C0004, PMX_GPIO0_2, PMX_UART0_TXD,
+        PMX_FMC_STARTUP_DISABLE)

Evidence

The new comment says the V530 workbook adds this selector; the shared row includes it, and the
chip-selection branch returns the same table for the whole family. The setter resolves a function
name to its list index and writes that index into the selector field.

src/reginfo.c[2115-2122]
src/reginfo.c[2265-2266]
src/reginfo.c[3098-3101]
src/reginfo.c[3321-3348]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The shared V500 table exposes a selector documented only for V530 on V500 and V510 chips.
## Fix Focus Areas
- src/reginfo.c[2265-2266]
- src/reginfo.c[3098-3101]
## Recommended Fix
Use a V530-specific version of the UART0 transmit row and select it only for V530. Leave selector 2 unavailable in the V500/V510 table.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can describe a rule in plain language on the Rules page and Qodo drafts it for you

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗