
Hi Jaehoon,
Thanks for your comments.
2021年4月20日(火) 7:05 Jaehoon Chung jh80.chung@samsung.com:
Hi Masami,
On 4/17/21 8:38 AM, Masami Hiramatsu wrote:
From: Jassi Brar jaswinder.singh@linaro.org
Signed-off-by: Jassi Brar jaswinder.singh@linaro.org Signed-off-by: Masami Hiramatsu masami.hiramatsu@linaro.org
drivers/mmc/Kconfig | 10 ++++++ drivers/mmc/Makefile | 1 + drivers/mmc/f_sdh30.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++ drivers/mmc/sdhci.c | 9 +++++ 4 files changed, 101 insertions(+) create mode 100644 drivers/mmc/f_sdh30.c
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index f8ca52efb6..a9ae419e41 100644 --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -549,6 +549,16 @@ config MMC_SDHCI_IPROC
If unsure, say N.
+config F_SDH30_SDHCI
MMS_SDHCI_F_SDH30 or MMC_SDHCI_xxx.
OK. I'll change it.
bool "SDHCI support for Fujitsu Semiconductor F_SDH30"
depends on BLK && DM_MMC
depends on MMC_SDHCI
help
This selects the Secure Digital Host Controller Interface (SDHCI)
Needed by some Fujitsu SoC for MMC / SD / SDIO support.
If you have a controller with this interface, say Y or M here.
If unsure, say N.
config MMC_SDHCI_KONA bool "SDHCI support on Broadcom KONA platform" depends on MMC_SDHCI diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile index 89d6af3db3..b48a76ba94 100644 --- a/drivers/mmc/Makefile +++ b/drivers/mmc/Makefile @@ -76,3 +76,4 @@ obj-$(CONFIG_MMC_UNIPHIER) += tmio-common.o uniphier-sd.o obj-$(CONFIG_RENESAS_SDHI) += tmio-common.o renesas-sdhi.o obj-$(CONFIG_MMC_BCM2835) += bcm2835_sdhost.o obj-$(CONFIG_MMC_MTK) += mtk-sd.o +obj-$(CONFIG_F_SDH30_SDHCI) += f_sdh30.o diff --git a/drivers/mmc/f_sdh30.c b/drivers/mmc/f_sdh30.c new file mode 100644 index 0000000000..44c6521bfe --- /dev/null +++ b/drivers/mmc/f_sdh30.c @@ -0,0 +1,81 @@ +// SPDX-License-Identifier: GPL-2.0+ +/*
- Socionext F_SDH30 eMMC driver
- Copyright 2021 Linaro Ltd.
- Copyright 2021 Socionext, Inc.
- */
+#include <common.h> +#include <clk.h> +#include <dm.h> +#include <malloc.h> +#include <sdhci.h>
+struct f_sdh30_plat {
struct mmc_config cfg;
struct mmc mmc;
+};
+DECLARE_GLOBAL_DATA_PTR;
+static int f_sdh30_probe(struct udevice *dev)
xxx_sdhci_probe().
Let me confirm. The controller name is F_SDH30, so it is better to be f_sdh30_sdhci_probe(), correct?
+{
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
struct f_sdh30_plat *plat = dev_get_plat(dev);
struct sdhci_host *host = dev_get_priv(dev);
int ret;
ret = mmc_of_parse(dev, &plat->cfg);
if (ret)
return ret;
host->mmc = &plat->mmc;
host->mmc->dev = dev;
host->mmc->priv = host;
ret = sdhci_setup_cfg(&plat->cfg, host, 200000000, 400000);
if (ret)
return ret;
upriv->mmc = host->mmc;
mmc_set_clock(host->mmc, host->mmc->cfg->f_min, MMC_CLK_ENABLE);
return sdhci_probe(dev);
+}
+static int f_sdh30_of_to_plat(struct udevice *dev) +{
struct sdhci_host *host = dev_get_priv(dev);
host->name = strdup(dev->name);
host->ioaddr = dev_read_addr_ptr(dev);
host->bus_width = dev_read_u32_default(dev, "bus-width", 4);
host->index = dev_read_u32_default(dev, "index", 0);
return 0;
+}
+static int f_sdh30_bind(struct udevice *dev) +{
struct f_sdh30_plat *plat = dev_get_plat(dev);
return sdhci_bind(dev, &plat->mmc, &plat->cfg);
+}
+static const struct udevice_id f_sdh30_mmc_ids[] = {
{ .compatible = "fujitsu,mb86s70-sdhci-3.0" },
{ }
+};
+U_BOOT_DRIVER(f_sdh30_drv) = {
.name = "f_sdh30_sdhci",
.id = UCLASS_MMC,
.of_match = f_sdh30_mmc_ids,
.of_to_plat = f_sdh30_of_to_plat,
.ops = &sdhci_ops,
.bind = f_sdh30_bind,
.probe = f_sdh30_probe,
.priv_auto = sizeof(struct sdhci_host),
.plat_auto = sizeof(struct f_sdh30_plat),
+}; diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index d9ab6a0a83..f038debc6c 100644 --- a/drivers/mmc/sdhci.c +++ b/drivers/mmc/sdhci.c @@ -708,6 +708,15 @@ static int sdhci_init(struct mmc *mmc)
sdhci_set_power(host, fls(mmc->cfg->voltages) - 1);
if (IS_ENABLED(CONFIG_F_SDH30_SDHCI)) {
I don't want to add specific sdhci driver configuration in sdhci.c.
According to below comment and Specification, it has to delay 1ms. Can it be removed the above condition checking?
Yes, of course!
/*
* Reference to Part1 Physical Layer Simplified Specification
* Ver 3.01, 6.4.1 Power Up
* This delay must be at least 74 clock sizes, or 1 ms.
*/
udelay(1000);
I don't have any objection about this, If possible, it needs to calculate clock-cycle with real clock value in future.
Should I split this part as an independent patch?
Thank you,