arm: dts: hi3516a: run the SD hosts at 3.3V, without UHS-I

[widgetii]

For OpenIPC/firmware#2219.

Symptom

On a Hi3516DV100 speed dome (board id HI3516D_N81820, IMX291) whose onboard storage works under the vendor firmware, current OpenIPC probes both himci hosts, but no block device ever appears:

himci: mmc host probe
himci: mmc host probe
himci: controller 0 clock stuck; disabling it so the board can boot
mmc1: cannot verify signal voltage switch
himci: controller 1 clock stuck; disabling it so the board can boot
mmc1: error -19 whilst initialising SD card

Cause

Both nodes in hi3516a.dtsi declare sd-uhs-sdr12/25/50/104. Every UHS-I mode signals at 1.8 V, and these pads have no 1.8 V rail: himci sets ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34, and the nodes carry no vqmmc-supply. Because the caps are present, the core sets S18R in ACMD41 and sends CMD11 to any card that accepts it. The card switches its own side to 1.8 V, and the host's readback fails (cannot verify signal voltage switch). There is no power control to cycle the card back to 3.3 V, so it never recovers.

Reaching the voltage switch also means the device on mmc1 answered the SD-only ACMD41. So whatever is soldered there speaks the SD protocol (SD-NAND rather than true eMMC), which is exactly the path this breaks.

Change

• Drop sd-uhs-* from both nodes.
• Cap max-frequency at exactly 50 MHz high-speed. The MMC mux parents are 25/50/75/100 MHz and the clock framework picks the fastest one at or below the request, so 49.5 MHz would land on 25 MHz.

non-removable is deliberately not added to mmc0. Nothing in the log ties the onboard chip to mmc0, and hi3516a.dtsi is shared by every av100/dv100 board, where it would turn off card detection on any board with an SD slot there.

Tested

• cpp + dtc build hi3516a-demb.dts. The decompiled DTB shows both nodes with max-frequency = <0x2faf080> (50 MHz) and no UHS properties.
• Boots on the affected hardware; storage not yet confirmed, so this must not merge yet. The reporter in No MMC/eMMC controller support in Hi3516A DEMO Board device tree (hi3516dv100/av100) firmware#2219 flashed a test kernel built from this branch (the earlier 49.5 MHz revision). It boots normally, and the cannot verify signal voltage switch / error -19 lines are gone, but both controllers then log clock stuck and still no mmcblk appears. The chip accepted the 1.8 V switch on earlier boots and is permanently powered, so it is probably still stuck there through warm reboots. The reporter has been asked for a full power cycle on this kernel. The rebuilt test kernel (this head, 50 MHz) is the same pre-release.

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

PR Summary by Qodo

Keep Hi3516A SD hosts at 3.3 V without UHS-I

🐞 Bug fix 🕐 10-20 Minutes

AI Description

• Remove UHS-I capabilities from both Hi3516A SD hosts to avoid unsupported 1.8 V switching.
• Limit both hosts to 49.5 MHz while retaining SD high-speed support.
• Device tree compilation passed; recovery on affected hardware remains unverified.

Diagram

graph TD
  D["Hi3516A DTSI"] --> A["MMC0 node"] --> H["himci driver"] --> M["MMC core"] --> C["SD card"]
  D --> B["MMC1 node"] --> H

Loading

High-Level Assessment

Changing capabilities in the shared device tree is appropriate because both hosts advertise UHS-I without a declared 1.8 V signaling supply. Board-specific overrides would add complexity without evidence that these hosts can support UHS-I; adding non-removable would also risk disabling card detection on other boards.

Files changed (1) +11 / -10

Bug fix (1) +11 / -10

hi3516a.dtsiRestrict both Hi3516A SD hosts to 3.3 V high-speed operation +11/-10

Restrict both Hi3516A SD hosts to 3.3 V high-speed operation

• Removes four UHS-I capability properties from each host and reduces each maximum frequency from 100 MHz to 49.5 MHz. Adds a comment explaining the unsupported voltage switch and observed card-initialization failure; leaves card-detection behavior unchanged.

arch/arm/boot/dts/hi3516a.dtsi

[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. SD transfers run at 25 MHz instead of 50 ✓ Resolved

Description

The new max-frequency value requests 49.5 MHz, but the Hi3516A clock mux selects the fastest
available rate at or below that request, which is 25 MHz. When either host uses an SD high-speed
card, the MMC core passes the capped rate to himci_set_cclk, so the intended near-50-MHz clock is
never selected.

Code

arch/arm/boot/dts/hi3516a.dtsi[545]

+			max-frequency = <49500000>;

Evidence

mmc_of_parse stores max-frequency as f_max, and mmc_set_clock clamps requests to it. The
Hi3516A MMC mux offers fixed 25- and 50-MHz parents; the clock framework's non-closest mux selection
chooses the fastest parent not exceeding the request. Both changed nodes request 49.5 MHz, so 50 MHz
is excluded and 25 MHz is selected before himci_set_cclk programs the card clock.

arch/arm/boot/dts/hi3516a.dtsi[545-560]
drivers/mmc/core/host.c[213-216]
drivers/mmc/core/core.c[1148-1152]
drivers/clk/hisilicon/clk-hi3516a.c[73-73]
drivers/clk/hisilicon/clk-hi3516a.c[108-114]
drivers/clk/clk.c[340-411]
drivers/mmc/host/himci/himci.c[236-267]

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 49.5 MHz cap on both Hi3516A SD hosts makes the clock mux choose 25 MHz, reducing high-speed transfer rates.
## Fix Focus Areas
- arch/arm/boot/dts/hi3516a.dtsi[535-560]
## Recommended Fix
Set both hosts' `max-frequency` to 50000000, which matches the available clock source, and update the nearby comment accordingly. Keep the UHS properties removed.

ⓘ 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 copy the agent prompt from any finding and feed it to your IDE agent

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[widgetii]

Qodo finding ("SD transfers run at 25 MHz instead of 50") is right. The MMC mux parents are 25/50/75/100 MHz and the clock framework picks the fastest one at or below the request, so 49.5 MHz selected 25 MHz. The head is now max-frequency = <50000000> on both nodes, and the DTB in the rebuilt test kernel shows 0x2faf080.

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

Qodo finding ("SD transfers run at 25 MHz instead of 50") is right. The MMC mux parents are 25/50/75/100 MHz and the clock framework picks the fastest one at or below the request, so 49.5 MHz selected 25 MHz. The head is now max-frequency = <50000000> on both nodes, and the DTB in the rebuilt test kernel shows 0x2faf080.

That addresses the clock-rate concern: both MMC nodes now request exactly 50 MHz, which selects the 50 MHz mux parent instead of falling back to 25 MHz. The rebuilt DTB value 0x2faf080 confirms the expected 50,000,000 Hz rate.