arm64: dts: amlogic: t7: fix UART clock and SD card recovery

Two fixes found while booting mainline on a Khadas VIM4.

The first one wires uart_a to the real UART bus clock. It was pointed at the 24MHz crystal as a placeholder, because the T7 clock controller driver did not exist when these boards were added. That leaves the real clock without a user, so the kernel turns it off when it disables unused clocks at the end of boot, and the board hangs with the console gone.

The second one drops regulator-always-on from the SD card supply. A card that refuses the 1.8V UHS switch can only be recovered by removing its power, which that property prevents, so the card never initialises and the MMC core retries forever.

Both were tested on a Khadas VIM4 booting v7.2 from the SD card.

Changes in v2:
- Update UART clocks directly in the board DTS files instead of moving them to amlogic-t7.dtsi, as &xtal is defined at the board level.

Lucas Tanure (2):
arm64: dts: amlogic: t7: use the real UART pclk
arm64: dts: amlogic: t7: khadas-vim4: allow the SD card to be power
cycled

 arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-an400.dts       | 2 +-
 arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

2.55.0

uart_a listed the 24MHz crystal for all three of its clocks because the T7 clock controller driver did not exist when these boards were added.

That leaves the real UART bus clock without a user, so the kernel turns it off when it disables unused clocks at the end of boot, and the board hangs.

Update the board DTS files to point uart_a's pclk to CLKID_SYS_UART_A instead of the dummy crystal clock.

---
 arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-an400.dts       | 2 +-
 arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

index cab2ee9ea0d3..ca7536f772ff 100644
@@ -33,7 +33,7 @@ xtal: xtal-clk {
 };
 
 &uart_a {
-	clocks = <&xtal>, <&xtal>, <&xtal>;
+	clocks = <&xtal>, <&clkc_periphs CLKID_SYS_UART_A>, <&xtal>;
 	clock-names = "xtal", "pclk", "baud";
 	status = "okay";
 };

index c41525a34b72..75d81ad6830d 100644
@@ -266,6 +266,6 @@ &sd_emmc_c {
 
 &uart_a {
 	status = "okay";
-	clocks = <&xtal>, <&xtal>, <&xtal>;
+	clocks = <&xtal>, <&clkc_periphs CLKID_SYS_UART_A>, <&xtal>;
 	clock-names = "xtal", "pclk", "baud";
 };

2.55.0

SD cards start at 3.3V and switch to 1.8V to reach UHS-I speeds. Some cards refuse that switch, and the SD specification says the only way to recover is to power the card off and start again.

SD_3V3 is marked regulator-always-on, so the supply never goes off, the card stays stuck half way through the switch, and the MMC core retries forever:

mmc1: error -95 whilst initialising SD card

Drop regulator-always-on. regulator-boot-on still turns the supply on at boot, and a card that refuses the switch now falls back to high speed instead of failing to initialise.

---
 arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 1 -
 1 file changed, 1 deletion(-)

index 75d81ad6830d..c94afaaf8826 100644
@@ -71,7 +71,6 @@ sd_3v3: regulator-sdcard-3v3 {
 		vin-supply = <&vddao_3v3>;
 		gpio = <&gpio GPIOD_11 GPIO_ACTIVE_LOW>;
 		regulator-boot-on;
-		regulator-always-on;
 	};
 
 	sdio_pwrseq: sdio-pwrseq {

2.55.0

Hi,

Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.3/fixes)

[1/2] arm64: dts: amlogic: t7: use the real UART pclk

      https://git.kernel.org/amlogic/c/882de800bf583dd15969836088789edbf035a944
[2/2] arm64: dts: amlogic: t7: khadas-vim4: allow the SD card to be power cycled
      https://git.kernel.org/amlogic/c/c793a084ab3088744516aef437b4239d0d98623f

These changes has been applied on the intermediate git tree [1].

The v7.3/fixes branch will then be sent via a formal Pull Request to the Linux SoC maintainers for inclusion in their intermediate git branches in order to be sent to Linus during the next merge window, or sooner if it's a set of fixes.

In the cases of fixes, those will be merged in the current release candidate kernel and as soon they appear on the Linux master branch they will be backported to the previous Stable and Long-Stable kernels [2].

The intermediate git branches are merged daily in the linux-next tree [3], people are encouraged testing these pre-release kernels and report issues on the relevant mailing-lists.

If problems are discovered on those changes, please submit a signed-off-by revert patch followed by a corrective changeset.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

Neil