From eb36f28ff721ebd5a919f4b4e3e71d5cad893a29 Mon Sep 17 00:00:00 2001 From: Kongyang Liu Date: Sun, 10 Mar 2024 01:51:55 +0800 Subject: mmc: cv1800b: Add sdhci driver support for cv1800b SoC Add sdhci driver for cv1800b SoC. Signed-off-by: Kongyang Liu Reviewed-by: Leo Yu-Chi Liang --- drivers/mmc/Kconfig | 13 +++++ drivers/mmc/Makefile | 1 + drivers/mmc/cv1800b_sdhci.c | 116 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 130 insertions(+) create mode 100644 drivers/mmc/cv1800b_sdhci.c (limited to 'drivers') diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index cef05790dd9..f7fe6d1042e 100644 --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -568,6 +568,19 @@ config MMC_SDHCI_CADENCE If unsure, say N. +config MMC_SDHCI_CV1800B + bool "SDHCI support for the CV1800B SD/SDIO/eMMC controller" + depends on BLK && DM_MMC + depends on MMC_SDHCI + depends on OF_CONTROL + help + This selects the CV1800B SD/SDIO/eMMC driver. + + If you have a controller with this interface, + say Y here. + + If unsure, say N. + config MMC_SDHCI_AM654 bool "SDHCI Controller on TI's Am654 devices" depends on ARCH_K3 diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile index e9cf1fcc640..3374321e290 100644 --- a/drivers/mmc/Makefile +++ b/drivers/mmc/Makefile @@ -60,6 +60,7 @@ obj-$(CONFIG_MMC_SDHCI_ATMEL) += atmel_sdhci.o obj-$(CONFIG_MMC_SDHCI_BCM2835) += bcm2835_sdhci.o obj-$(CONFIG_MMC_SDHCI_BCMSTB) += bcmstb_sdhci.o obj-$(CONFIG_MMC_SDHCI_CADENCE) += sdhci-cadence.o +obj-$(CONFIG_MMC_SDHCI_CV1800B) += cv1800b_sdhci.o obj-$(CONFIG_MMC_SDHCI_AM654) += am654_sdhci.o obj-$(CONFIG_MMC_SDHCI_IPROC) += iproc_sdhci.o obj-$(CONFIG_MMC_SDHCI_KONA) += kona_sdhci.o diff --git a/drivers/mmc/cv1800b_sdhci.c b/drivers/mmc/cv1800b_sdhci.c new file mode 100644 index 00000000000..2275c537772 --- /dev/null +++ b/drivers/mmc/cv1800b_sdhci.c @@ -0,0 +1,116 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (c) 2024, Kongyang Liu + */ + +#include +#include +#include +#include + +#define SDHCI_PHY_TX_RX_DLY 0x240 +#define MMC_MAX_CLOCK 375000000 +#define TUNE_MAX_PHCODE 128 + +struct cv1800b_sdhci_plat { + struct mmc_config cfg; + struct mmc mmc; +}; + +static void cv1800b_set_tap_delay(struct sdhci_host *host, u16 tap) +{ + sdhci_writel(host, tap << 16, SDHCI_PHY_TX_RX_DLY); +} + +static void cv1800b_sdhci_reset(struct sdhci_host *host, u8 mask) +{ + sdhci_writeb(host, mask, SDHCI_SOFTWARE_RESET); + while (sdhci_readb(host, SDHCI_SOFTWARE_RESET) & mask) + udelay(10); +} + +static int cv1800b_execute_tuning(struct mmc *mmc, u8 opcode) +{ + struct sdhci_host *host = dev_get_priv(mmc->dev); + + u16 tap; + + int current_size = 0; + int max_size = 0; + int max_window = 0; + + for (tap = 0; tap < TUNE_MAX_PHCODE; tap++) { + cv1800b_set_tap_delay(host, tap); + + if (mmc_send_tuning(host->mmc, opcode, NULL)) { + current_size = 0; + } else { + current_size++; + if (current_size > max_size) { + max_size = current_size; + max_window = tap; + } + } + } + + cv1800b_sdhci_reset(host, SDHCI_RESET_CMD | SDHCI_RESET_DATA); + + cv1800b_set_tap_delay(host, max_window - max_size / 2); + + return 0; +} + +const struct sdhci_ops cv1800b_sdhci_sd_ops = { + .platform_execute_tuning = cv1800b_execute_tuning, +}; + +static int cv1800b_sdhci_bind(struct udevice *dev) +{ + struct cv1800b_sdhci_plat *plat = dev_get_plat(dev); + + return sdhci_bind(dev, &plat->mmc, &plat->cfg); +} + +static int cv1800b_sdhci_probe(struct udevice *dev) +{ + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev); + struct cv1800b_sdhci_plat *plat = dev_get_plat(dev); + struct sdhci_host *host = dev_get_priv(dev); + int ret; + + host->name = dev->name; + host->ioaddr = devfdt_get_addr_ptr(dev); + + upriv->mmc = &plat->mmc; + host->mmc = &plat->mmc; + host->mmc->priv = host; + host->mmc->dev = dev; + host->ops = &cv1800b_sdhci_sd_ops; + host->max_clk = MMC_MAX_CLOCK; + + ret = mmc_of_parse(dev, &plat->cfg); + if (ret) + return ret; + + ret = sdhci_setup_cfg(&plat->cfg, host, 0, 200000); + if (ret) + return ret; + + return sdhci_probe(dev); +} + +static const struct udevice_id cv1800b_sdhci_match[] = { + { .compatible = "sophgo,cv1800b-dwcmshc" }, + { } +}; + +U_BOOT_DRIVER(cv1800b_sdhci) = { + .name = "sdhci-cv1800b", + .id = UCLASS_MMC, + .of_match = cv1800b_sdhci_match, + .bind = cv1800b_sdhci_bind, + .probe = cv1800b_sdhci_probe, + .priv_auto = sizeof(struct sdhci_host), + .plat_auto = sizeof(struct cv1800b_sdhci_plat), + .ops = &sdhci_ops, +}; -- cgit v1.3.1 From b90edde70127a824d7aa257c6a633c1a030bfb79 Mon Sep 17 00:00:00 2001 From: Conor Dooley Date: Mon, 18 Mar 2024 15:16:02 +0000 Subject: riscv: don't read riscv, isa in the riscv cpu's get_desc() cpu_get_desc() for the RISC-V CPU currently reads "riscv,isa" to get the description, but it is no longer a required property and cannot be assummed to always be present, as the new "riscv,isa-extensions" and "riscv,isa-base" properties may be present instead. On RISC-V, cpu_get_desc() has two main uses - firstly providing an informational name for the CPU for smbios or at boot with DISPLAY_CPUINFO etc and secondly it forms the basis of ISA extension detection in supports_extension() as it returns (a portion of) an ISA string. cpu_get_desc() returns a string, which aligned with "riscv,isa" but the new property is a list of strings. Rather than add support for the list of strings property, which would require creating an isa string from "riscv,isa-extensions", modify the RISC-V CPU's implementaion of cpu_get_desc() return the first compatible as the cpu description instead. This may be fine for the informational cases, but it would break extension dtection, given supports_extension() expects cpu_get_desc() to return an ISA string. Call dev_read_string() directly in supports_extension() to get the contents of "riscv,isa" so that extension detection remains functional. As a knock-on affect of this change, extension detection is no longer broken for long ISA strings. Previously if the ISA string exceeded the 32 element array that supports_extension() passed to cpu_get_desc(), it would return ENOSPC and no extensions would be detected. This bug probably had no impact as U-Boot does not currently do anything meaningful with the results of supports_extension() and most SoCs supported by U-Boot don't have anywhere near that complex of an ISA string. The QEMU virt machine's CPUs do however, so extension detection doesn't work there. Signed-off-by: Conor Dooley reviewed-by: Leo Yu-Chi Liang --- arch/riscv/cpu/cpu.c | 12 +++++++----- drivers/cpu/riscv_cpu.c | 8 ++++---- 2 files changed, 11 insertions(+), 9 deletions(-) (limited to 'drivers') diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c index ecfefa1a025..99083e11dfa 100644 --- a/arch/riscv/cpu/cpu.c +++ b/arch/riscv/cpu/cpu.c @@ -39,7 +39,7 @@ static inline bool supports_extension(char ext) return csr_read(CSR_MISA) & (1 << (ext - 'a')); #elif CONFIG_CPU struct udevice *dev; - char desc[32]; + const char *isa; int i; uclass_find_first_device(UCLASS_CPU, &dev); @@ -47,12 +47,14 @@ static inline bool supports_extension(char ext) debug("unable to find the RISC-V cpu device\n"); return false; } - if (!cpu_get_desc(dev, desc, sizeof(desc))) { + + isa = dev_read_string(dev, "riscv,isa"); + if (isa) { /* * skip the first 4 characters (rv32|rv64) */ - for (i = 4; i < sizeof(desc); i++) { - switch (desc[i]) { + for (i = 4; i < sizeof(isa); i++) { + switch (isa[i]) { case 's': case 'x': case 'z': @@ -64,7 +66,7 @@ static inline bool supports_extension(char ext) */ return false; default: - if (desc[i] == ext) + if (isa[i] == ext) return true; } } diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c index 5d1026b37da..9b1950efe05 100644 --- a/drivers/cpu/riscv_cpu.c +++ b/drivers/cpu/riscv_cpu.c @@ -21,13 +21,13 @@ DECLARE_GLOBAL_DATA_PTR; static int riscv_cpu_get_desc(const struct udevice *dev, char *buf, int size) { - const char *isa; + const char *cpu; - isa = dev_read_string(dev, "riscv,isa"); - if (size < (strlen(isa) + 1)) + cpu = dev_read_string(dev, "compatible"); + if (size < (strlen(cpu) + 1)) return -ENOSPC; - strcpy(buf, isa); + strcpy(buf, cpu); return 0; } -- cgit v1.3.1