Re: [PATCH] sdhci: allow for eMMC 74 clock generation by controller
On 21/09/10 08:43, ext Philip Rakity wrote:
Wolfram,
I generated the patch for eMMC 74 clocks. I do not know if you want to
incorporate into your submission or let it stand on its own.
Wouldn't it be better to fix it in MMC core rather than duplicate it in every
driver?
regards,
Philip
From: Philip Rakityprak...@marvell.com
Subject: [PATCH] sdhci: allow for eMMC 74 clock generation by controller
Signed-off-by: Philip Rakityprak...@marvell.com
Patch is below and sample usage in sdhci-.c adaption code is below.
/*
* eMMC spec calls for the host to send 74 clocks to the card
* during initialization, right after voltage stabilization.
* create the clocks manually right here.
*/
void generate_init_clocks_A0(struct sdhci_host *host, u8 power_mode)
{
struct sdhci_mmc_slot *slot = sdhci_priv(host);
DBG (%s: ENTER %s: slot-power_mode = %d, ios-power_mode = %d\n,
__func__,
mmc_hostname(host-mmc),
slot-power_mode,
power_mode);
if (slot-power_mode == MMC_POWER_UP
power_mode == MMC_POWER_ON) {
/* controller specific code here */
/* slot-power_mode holds previous power setting */
}
slot-power_mode = power_mode;
}
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 401527d..6aadd0f 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1168,6 +1168,9 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
else
sdhci_set_power(host, ios-vdd);
+ if (host-ops-platform_generate_initial_74_clocks)
+ host-ops-platform_generate_initial_74_clocks(host,
ios-power_mode);
+
ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
if (ios-bus_width == MMC_BUS_WIDTH_8)
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index d316bc7..70c5806 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -323,6 +323,8 @@ struct sdhci_ops {
unsigned int(*get_max_clock)(struct sdhci_host *host);
unsigned int(*get_min_clock)(struct sdhci_host *host);
unsigned int(*get_timeout_clock)(struct sdhci_host *host);
+ void(*platform_generate_initial_74_clocks)(struct
sdhci_host *host,
+ u8 power_mode);
};
#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sdhci: allow for eMMC 74 clock generation by controller
Hi Philip, I generated the patch for eMMC 74 clocks. I do not know if you want to incorporate into your submission or let it stand on its own. I won't pick it up as I am missing the technical details for this issue. I only jumped in because adding quirk bits should be handled very carefully at the moment IMHO. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH v2 3/4] omap4 hsmmc: Register offset handling
Hi Benoit, On Tue, Sep 21, 2010 at 2:26 AM, Cousson, Benoit b-cous...@ti.com wrote: Hi Kishore On 9/18/2010 6:34 PM, Kadiyala, Kishore wrote: The offset handling implementation of omap4 mmc registers which was already present can't be reused once hwmod modifications are done for mmc driver. Since hwmod data file for OMAP4 is an auto generated the base address for MMC will remain same as OMAP3 and thus the offset deviation of registers should be updated in the hsmmc driver. That explanation does not sound very accurate to me. The fact that the hwmods are auto-generated has nothing to do with your offset problem. Agree the change log needs to be updated as said but when coming to implementation this how it is: With current mainline kernel, offset appending is already implemented in mach-omap2/devices.c and works fine [here bases are updated with 0x100 and then passed to driver which has same register offset's as OMAP3]. When hwmod modifications are done to the MMC driver, the base address are picked from omap_hwmod_44xx_data.c and omap_device is build. Coming to the driver it still has the same old register offset's as OMAP3 and there should be a way to add 0x100 some where. The current patch moves the offset appending to the driver file which is updated in mach-omap2/hsmmc.c which will fit for current implementation and even hwmod adaptation. The real cause is due to the update of the IP to support the new PM programming model. Because of that, and to keep a certain level of compatibility, the legacy registers were all shifted by 0x100 and the new one were added from offset 0 to 0x10. Regards, Benoit snip Regards, Kishore -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add support PXA168/PXA910/MMP2 SD Host Controller
On Mon, Sep 20, 2010 at 9:10 AM, Wolfram Sang w.s...@pengutronix.de wrote: On Mon, Sep 20, 2010 at 08:09:26AM -0400, zhangfei gao wrote: On Mon, Sep 20, 2010 at 5:50 AM, Wolfram Sang w.s...@pengutronix.de wrote: On Mon, Sep 20, 2010 at 05:46:02PM +0800, zhangfei gao wrote: diff --git a/drivers/mmc/host/sdhci-pxa.c b/drivers/mmc/host/sdhci-pxa.c new file mode 100644 index 000..3e091c1 --- /dev/null +++ b/drivers/mmc/host/sdhci-pxa.c @@ -0,0 +1,253 @@ +/* linux/drivers/mmc/host/sdhci-pxa.c + * + * Copyright 2010 Marvell + * Zhangfei Gao zhangfei@marvell.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +/* Supports: + * SDHCI support for MMP2/PXA910/PXA168 + * + * Based on sdhci-platfm.c + */ Why is it only based on and not directly using it? Thanks for your suggestion. This is the first stage, already implement sd card function, we will have some patches later to enhance the driver. We have to access many private registers to enable specific control. Besides some sdio device need some specific control, like marvell 8787 host sleep, it is much reasonable to implement inside the driver. Hmm, which hooks are missing for you to implement this as an extension of the pltfm-driver? Maybe it makes sense to simply add this hook? We refered several mmc host drivers, such as sdhci-s3c.c, sdhci-spear.c, and we want to align with others, which also meet pxa requirement and low risk to transfer from the existing driver. We have three or four device in one soc with the same driver, for example one for sd, one for wifi, one for emmc, etc. Each device have specific clock provider, which should be opened at start, and closed when no operation to same power. Specific quirk is needed for different device, which should be transfered from platform data, for example on-chip wifi alwayes stay on chip and emmc may require sd_clk free running to init. The max_speed also may be different for board issue though controller support max is 50M, which could get from capability. -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkyXXV8ACgkQD27XaX1/VRtAxQCfafH+k4+HhWiDxM+cRqDn8KYC Mq0AnRrh3v5192K7LdpIlLIxVBQI4ljW =RPet -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: add SDHCI driver for STM platforms (V2)
On 09/20/2010 10:38 AM, Wolfram Sang wrote: On Mon, Sep 20, 2010 at 10:20:17AM +0200, Giuseppe CAVALLARO wrote: This patch adds the Arasan MMC/SD/SDIO driver for the STM ST40 platforms. It is based on the SDHCI driver. It has been tested on the STx7106/STx7108/STx5289 platforms. Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com Looks to me that you could just use the sdhci-pltfm driver? Hello Wolfram, some weeks ago I discussed about this driver and I reworked it according to the changes required. This is the meaning of this patch. At any rate, I can look at the sdhci-pltfm driver: at first glance, it could actually help on our platforms. This could take a while. Regards Peppe -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add support PXA168/PXA910/MMP2 SD Host Controller
Hi , I had worked with MMP2 platform several weeks. The mmc/sdio interface have constraint about transfer size. The transfer size must be 8-byte alignment. If any transfer size is 4 byte alignment and not 8-byte alignment. This peripheral ip can't support(miss dma end interrupt or bad transmission) even DMA mode or PIO mode. Claud Yu -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: add SDHCI driver for STM platforms (V2)
On Tue, Sep 21, 2010 at 11:21:48AM +0200, Peppe CAVALLARO wrote: On 09/20/2010 10:38 AM, Wolfram Sang wrote: On Mon, Sep 20, 2010 at 10:20:17AM +0200, Giuseppe CAVALLARO wrote: This patch adds the Arasan MMC/SD/SDIO driver for the STM ST40 platforms. It is based on the SDHCI driver. It has been tested on the STx7106/STx7108/STx5289 platforms. Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com Looks to me that you could just use the sdhci-pltfm driver? Hello Wolfram, some weeks ago I discussed about this driver and I reworked it according to the changes required. This is the meaning of this patch. At any rate, I can look at the sdhci-pltfm driver: at first glance, it could actually help on our platforms. This could take a while. Sorry, I didn't spot the first version of your patch. I would have said the same then, simply to avoid the code duplication. Oh, and no need to hurry from my side :) Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH] add support PXA168/PXA910/MMP2 SD Host Controller
diff --git a/drivers/mmc/host/sdhci-pxa.c b/drivers/mmc/host/sdhci-pxa.c new file mode 100644 index 000..3e091c1 --- /dev/null +++ b/drivers/mmc/host/sdhci-pxa.c @@ -0,0 +1,253 @@ +/* linux/drivers/mmc/host/sdhci-pxa.c + * + * Copyright 2010 Marvell + * Zhangfei Gao zhangfei@marvell.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +/* Supports: + * SDHCI support for MMP2/PXA910/PXA168 + * + * Based on sdhci-platfm.c + */ Why is it only based on and not directly using it? Thanks for your suggestion. This is the first stage, already implement sd card function, we will have some patches later to enhance the driver. We have to access many private registers to enable specific control. Besides some sdio device need some specific control, like marvell 8787 host sleep, it is much reasonable to implement inside the driver. Hmm, which hooks are missing for you to implement this as an extension of the pltfm-driver? Maybe it makes sense to simply add this hook? We refered several mmc host drivers, such as sdhci-s3c.c, sdhci-spear.c, and we want to align with others, which also meet pxa requirement and low risk to transfer from the existing driver. I see. It is true that the pltfm-part is not widely used up to now. The question is if it might be a good idea to change this? There have been voices asking to merge the s3c-driver into the pltfm one. If you look at sdhci-cns3xxx.c, it looks clearer and reduces code duplication. The current state of the pltfm-driver might not cover all cases (yet), true, but those should be at least identified IMHO. This will help us for similar decisions in the future. We have three or four device in one soc with the same driver, for example one for sd, one for wifi, one for emmc, etc. Each device have specific clock provider, which should be opened at start, and closed when no operation to same power. Specific quirk is needed for different device, which should be transfered from platform data, for example on-chip wifi alwayes stay on chip and emmc may require sd_clk free running to init. The max_speed also may be different for board issue though controller support max is 50M, which could get from capability. I guess to fully understand all constraints, one must really working with your platform, what I don't do. I agree that a nicely working driver is better than no driver; however, I fear once a driver hit the mainline being non-pltfm, it will hardly be converted later, even if it was considered to be worthwhile. So this is why I ask initially if it couldn't be done. Chris, do you see a rule of thumb here? Or what are your preferences? Kind regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [RFC] Mobile Storage Host support
Are there anyone who interest in Mobile Storage Host? On Fri, Sep 17, 2010 at 1:45 PM, Kyungmin Park kmp...@infradead.org wrote: Hi, Now we implemented the mobile storage and want to posting it to mmc. But during code review I know that it's almost similar with sdhci core except register offset and fifo support. So I wonder what's the better way to implement it. 1) create the mstorage.[ch] 2) override the existing sdhci using io accessors function. Basic Mobile Storage Host controller register is following. CTRL: 0x PWREN: 0x0004 CLKDIV: 0x0008 CLKSRC: 0x000C CLKENA: 0x0010 TMOUT: 0x0014 CTYPE: 0x0018 BLKSIZ: 0x001C BYTCNT: 0x0020 INTMASK: 0x0024 CMDARG: 0x0028 CMD: 0x002C ... Any comments are welcome. Thank you, Kyungmin Park -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] mmc: sdhci-pltfm: Add structure for host-specific data
We need to carry some information per host, e.g. the clock. Add a
structure for it and initialize it in the generic part.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
---
drivers/mmc/host/sdhci-pltfm.c |7 +--
drivers/mmc/host/sdhci-pltfm.h |5 +
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index e045e3c..bf522a1 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -55,6 +55,7 @@ static int __devinit sdhci_pltfm_probe(struct platform_device
*pdev)
struct sdhci_pltfm_data *pdata = pdev-dev.platform_data;
const struct platform_device_id *platid = platform_get_device_id(pdev);
struct sdhci_host *host;
+ struct sdhci_pltfm_host *pltfm_host;
struct resource *iomem;
int ret;
@@ -72,15 +73,17 @@ static int __devinit sdhci_pltfm_probe(struct
platform_device *pdev)
experience problems.\n);
if (pdev-dev.parent)
- host = sdhci_alloc_host(pdev-dev.parent, 0);
+ host = sdhci_alloc_host(pdev-dev.parent, sizeof(*pltfm_host));
else
- host = sdhci_alloc_host(pdev-dev, 0);
+ host = sdhci_alloc_host(pdev-dev, sizeof(*pltfm_host));
if (IS_ERR(host)) {
ret = PTR_ERR(host);
goto err;
}
+ pltfm_host = sdhci_priv(host);
+
host-hw_name = platform;
if (pdata pdata-ops)
host-ops = pdata-ops;
diff --git a/drivers/mmc/host/sdhci-pltfm.h b/drivers/mmc/host/sdhci-pltfm.h
index 900f329..c393289 100644
--- a/drivers/mmc/host/sdhci-pltfm.h
+++ b/drivers/mmc/host/sdhci-pltfm.h
@@ -13,6 +13,11 @@
#include linux/sdhci-pltfm.h
+struct sdhci_pltfm_host {
+ struct clk *clk;
+ u32 scratchpad; /* to handle quirks across io-accessor calls */
+};
+
extern struct sdhci_pltfm_data sdhci_cns3xxx_pdata;
#endif /* _DRIVERS_MMC_SDHCI_PLTFM_H */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] mmc: sdhci-pltfm: move .h-file into apropriate subdir
Make use of the mmc-directory.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
---
drivers/mmc/host/sdhci-cns3xxx.c |2 +-
drivers/mmc/host/sdhci-pltfm.c |2 +-
drivers/mmc/host/sdhci-pltfm.h |2 +-
include/linux/mmc/sdhci-pltfm.h | 35 +++
include/linux/sdhci-pltfm.h | 35 ---
5 files changed, 38 insertions(+), 38 deletions(-)
create mode 100644 include/linux/mmc/sdhci-pltfm.h
delete mode 100644 include/linux/sdhci-pltfm.h
diff --git a/drivers/mmc/host/sdhci-cns3xxx.c b/drivers/mmc/host/sdhci-cns3xxx.c
index b7050b3..9ebd1d7 100644
--- a/drivers/mmc/host/sdhci-cns3xxx.c
+++ b/drivers/mmc/host/sdhci-cns3xxx.c
@@ -15,7 +15,7 @@
#include linux/delay.h
#include linux/device.h
#include linux/mmc/host.h
-#include linux/sdhci-pltfm.h
+#include linux/mmc/sdhci-pltfm.h
#include mach/cns3xxx.h
#include sdhci.h
#include sdhci-pltfm.h
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index bf522a1..ff0271c 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -30,7 +30,7 @@
#include linux/mmc/host.h
#include linux/io.h
-#include linux/sdhci-pltfm.h
+#include linux/mmc/sdhci-pltfm.h
#include sdhci.h
#include sdhci-pltfm.h
diff --git a/drivers/mmc/host/sdhci-pltfm.h b/drivers/mmc/host/sdhci-pltfm.h
index c393289..2b43ed5 100644
--- a/drivers/mmc/host/sdhci-pltfm.h
+++ b/drivers/mmc/host/sdhci-pltfm.h
@@ -11,7 +11,7 @@
#ifndef _DRIVERS_MMC_SDHCI_PLTFM_H
#define _DRIVERS_MMC_SDHCI_PLTFM_H
-#include linux/sdhci-pltfm.h
+#include linux/mmc/sdhci-pltfm.h
struct sdhci_pltfm_host {
struct clk *clk;
diff --git a/include/linux/mmc/sdhci-pltfm.h b/include/linux/mmc/sdhci-pltfm.h
new file mode 100644
index 000..0239bd7
--- /dev/null
+++ b/include/linux/mmc/sdhci-pltfm.h
@@ -0,0 +1,35 @@
+/*
+ * Platform data declarations for the sdhci-pltfm driver.
+ *
+ * Copyright (c) 2010 MontaVista Software, LLC.
+ *
+ * Author: Anton Vorontsov avoront...@ru.mvista.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or (at
+ * your option) any later version.
+ */
+
+#ifndef _SDHCI_PLTFM_H
+#define _SDHCI_PLTFM_H
+
+struct sdhci_ops;
+struct sdhci_host;
+
+/**
+ * struct sdhci_pltfm_data - SDHCI platform-specific information hooks
+ * @ops: optional pointer to the platform-provided SDHCI ops
+ * @quirks: optional SDHCI quirks
+ * @init: optional hook that is called during device probe, before the
+ *driver tries to access any SDHCI registers
+ * @exit: optional hook that is called during device removal
+ */
+struct sdhci_pltfm_data {
+ struct sdhci_ops *ops;
+ unsigned int quirks;
+ int (*init)(struct sdhci_host *host);
+ void (*exit)(struct sdhci_host *host);
+};
+
+#endif /* _SDHCI_PLTFM_H */
diff --git a/include/linux/sdhci-pltfm.h b/include/linux/sdhci-pltfm.h
deleted file mode 100644
index 0239bd7..000
--- a/include/linux/sdhci-pltfm.h
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * Platform data declarations for the sdhci-pltfm driver.
- *
- * Copyright (c) 2010 MontaVista Software, LLC.
- *
- * Author: Anton Vorontsov avoront...@ru.mvista.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or (at
- * your option) any later version.
- */
-
-#ifndef _SDHCI_PLTFM_H
-#define _SDHCI_PLTFM_H
-
-struct sdhci_ops;
-struct sdhci_host;
-
-/**
- * struct sdhci_pltfm_data - SDHCI platform-specific information hooks
- * @ops: optional pointer to the platform-provided SDHCI ops
- * @quirks: optional SDHCI quirks
- * @init: optional hook that is called during device probe, before the
- *driver tries to access any SDHCI registers
- * @exit: optional hook that is called during device removal
- */
-struct sdhci_pltfm_data {
- struct sdhci_ops *ops;
- unsigned int quirks;
- int (*init)(struct sdhci_host *host);
- void (*exit)(struct sdhci_host *host);
-};
-
-#endif /* _SDHCI_PLTFM_H */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] mmc: sdhci-pltfm: add pltfm-driver for imx35/51
This driver adds basic support for the esdhc-core found on e.g.
imx35/51. It adds up to the pltfm-core.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
---
drivers/mmc/host/Kconfig |9 +++
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/sdhci-esdhc.c | 141
drivers/mmc/host/sdhci-pltfm.c |3 +
drivers/mmc/host/sdhci-pltfm.h |1 +
5 files changed, 155 insertions(+), 0 deletions(-)
create mode 100644 drivers/mmc/host/sdhci-esdhc.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 6f12d5d..20d03f5 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -143,6 +143,15 @@ config MMC_SDHCI_MV
If unsure, say N.
+config MMC_SDHCI_ESDHC
+ bool SDHCI platform support for the Freescale eSDHC controller
+ depends on MMC_SDHCI_PLTFM
+ select MMC_SDHCI_IO_ACCESSORS
+ help
+ This selects the Freescale eSDHC controller support.
+
+ If unsure, say N.
+
config MMC_SDHCI_S3C
tristate SDHCI support on Samsung S3C SoC
depends on MMC_SDHCI PLAT_SAMSUNG
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 697bbfe..445d1e5 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_MMC_USHC)+= ushc.o
obj-$(CONFIG_MMC_SDHCI_PLTFM) += sdhci-platform.o
sdhci-platform-y := sdhci-pltfm.o
sdhci-platform-$(CONFIG_MMC_SDHCI_CNS3XXX) += sdhci-cns3xxx.o
+sdhci-platform-$(CONFIG_MMC_SDHCI_ESDHC) += sdhci-esdhc.o
obj-$(CONFIG_MMC_SDHCI_OF) += sdhci-of.o
sdhci-of-y := sdhci-of-core.o
diff --git a/drivers/mmc/host/sdhci-esdhc.c b/drivers/mmc/host/sdhci-esdhc.c
new file mode 100644
index 000..132e9c9
--- /dev/null
+++ b/drivers/mmc/host/sdhci-esdhc.c
@@ -0,0 +1,141 @@
+/*
+ * Freescale eSDHC controller driver for the platform bus.
+ *
+ * derived from the OF-version.
+ *
+ * Copyright (c) 2010 Pengutronix e.K.
+ * Author: Wolfram Sang w.s...@pengutronix.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include linux/io.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/mmc/host.h
+#include linux/mmc/sdhci-pltfm.h
+#include sdhci.h
+#include sdhci-esdhc.h
+#include sdhci-pltfm.h
+
+static inline void esdhc_clrset_le(struct sdhci_host *host, u32 mask, u32 val,
int reg)
+{
+ void __iomem *base = host-ioaddr + (reg ~0x3);
+ u32 shift = (reg 0x3) * 8;
+
+ writel(((readl(base) ~(mask shift)) | (val shift)), base);
+}
+
+static u16 esdhc_readw_le(struct sdhci_host *host, int reg)
+{
+ if (unlikely(reg == SDHCI_HOST_VERSION))
+ reg ^= 2;
+
+ return readw(host-ioaddr + reg);
+}
+
+static void esdhc_writew_le(struct sdhci_host *host, u16 val, int reg)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+
+ switch (reg) {
+ case SDHCI_TRANSFER_MODE:
+ /*
+* Postpone this write, we must do it together with a
+* command write that is down below.
+*/
+ pltfm_host-scratchpad = val;
+ return;
+ case SDHCI_COMMAND:
+ writel(val 16 | pltfm_host-scratchpad,
+ host-ioaddr + SDHCI_TRANSFER_MODE);
+ return;
+ case SDHCI_BLOCK_SIZE:
+ val = ~SDHCI_MAKE_BLKSZ(0x7, 0);
+ break;
+ }
+ esdhc_clrset_le(host, 0x, val, reg);
+}
+
+static void esdhc_writeb_le(struct sdhci_host *host, u8 val, int reg)
+{
+ u32 new_val;
+
+ switch (reg) {
+ case SDHCI_POWER_CONTROL:
+ /*
+* FSL put some DMA bits here
+* If your board has a regulator, code should be here
+*/
+ return;
+ case SDHCI_HOST_CONTROL:
+ /* FSL messed up here, so we can just keep those two */
+ new_val = val (SDHCI_CTRL_LED | SDHCI_CTRL_4BITBUS);
+ /* ensure the endianess */
+ new_val |= ESDHC_HOST_CONTROL_LE;
+ /* DMA mode bits are shifted */
+ new_val |= (val SDHCI_CTRL_DMA_MASK) 5;
+
+ esdhc_clrset_le(host, 0x, new_val, reg);
+ return;
+ }
+ esdhc_clrset_le(host, 0xff, val, reg);
+}
+
+static unsigned int esdhc_pltfm_get_max_clock(struct sdhci_host *host)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ return clk_get_rate(pltfm_host-clk);
+}
+
+static unsigned int esdhc_pltfm_get_min_clock(struct sdhci_host *host)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ return clk_get_rate(pltfm_host-clk) /
[RFC] sdhci_pltfm: pass platform_data on custom init-call
The custom init call may need more data to perform its job, so we pass it a
pointer to the platform_data, too. Now, for drivers extending sdhci-pltfm (like
sdhci-cns3xxx), a fixed platform_data is used according to the platform device
id. Because that one does not contain board specific information, we simply
name the board specific information information priv_pdata and pass it to the
init routine as well. (Note: the old behaviour was that you could override the
platform id specific data with your own. However, one can still do this by
using the sdhci id instead of sdhci-something.)
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
---
This approach has its issues, but all I tried had some. So, let's start arguing
over code ;)
drivers/mmc/host/sdhci-esdhc.c |3 ++-
drivers/mmc/host/sdhci-pltfm.c | 11 ---
include/linux/mmc/sdhci-pltfm.h |2 +-
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sdhci-esdhc.c b/drivers/mmc/host/sdhci-esdhc.c
index 132e9c9..ccdafd9 100644
--- a/drivers/mmc/host/sdhci-esdhc.c
+++ b/drivers/mmc/host/sdhci-esdhc.c
@@ -97,7 +97,8 @@ static unsigned int esdhc_pltfm_get_min_clock(struct
sdhci_host *host)
return clk_get_rate(pltfm_host-clk) / 256 / 16;
}
-static int esdhc_pltfm_init(struct sdhci_host *host)
+static int esdhc_pltfm_init(struct sdhci_host *host,
+ struct sdhci_pltfm_data *pdata, void *priv_pdata)
{
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct clk *clk;
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index 6ba3f3d..04f3117 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -52,15 +52,20 @@ static struct sdhci_ops sdhci_pltfm_ops = {
static int __devinit sdhci_pltfm_probe(struct platform_device *pdev)
{
- struct sdhci_pltfm_data *pdata = pdev-dev.platform_data;
const struct platform_device_id *platid = platform_get_device_id(pdev);
+ struct sdhci_pltfm_data *pdata;
+ void *priv_pdata = NULL;
struct sdhci_host *host;
struct sdhci_pltfm_host *pltfm_host;
struct resource *iomem;
int ret;
- if (!pdata platid platid-driver_data)
+ if (platid platid-driver_data) {
pdata = (void *)platid-driver_data;
+ priv_pdata = pdev-dev.platform_data;
+ } else {
+ pdata = pdev-dev.platform_data;
+ }
iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!iomem) {
@@ -108,7 +113,7 @@ static int __devinit sdhci_pltfm_probe(struct
platform_device *pdev)
}
if (pdata pdata-init) {
- ret = pdata-init(host);
+ ret = pdata-init(host, pdata, priv_pdata);
if (ret)
goto err_plat_init;
}
diff --git a/include/linux/mmc/sdhci-pltfm.h b/include/linux/mmc/sdhci-pltfm.h
index 0239bd7..e14fce3 100644
--- a/include/linux/mmc/sdhci-pltfm.h
+++ b/include/linux/mmc/sdhci-pltfm.h
@@ -28,7 +28,7 @@ struct sdhci_host;
struct sdhci_pltfm_data {
struct sdhci_ops *ops;
unsigned int quirks;
- int (*init)(struct sdhci_host *host);
+ int (*init)(struct sdhci_host *host, struct sdhci_pltfm_data *pdata,
void* priv_pdata);
void (*exit)(struct sdhci_host *host);
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] mmc: sdhci-pltfm: move .h-file into apropriate subdir
On Tue, Sep 21, 2010 at 02:30:08PM +0200, Wolfram Sang wrote: Make use of the mmc-directory. Signed-off-by: Wolfram Sang w.s...@pengutronix.de Acked-by: Anton Vorontsov cbouatmai...@gmail.com -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mmc: sdhci-pltfm: add pltfm-driver for imx35/51
On Tue, Sep 21, 2010 at 02:30:10PM +0200, Wolfram Sang wrote:
This driver adds basic support for the esdhc-core found on e.g.
imx35/51. It adds up to the pltfm-core.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
---
drivers/mmc/host/Kconfig |9 +++
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/sdhci-esdhc.c | 141
I'd reserve that file for esdhc common code, and move IMX
specific bits to sdhci-esdhc-imx.c.
drivers/mmc/host/sdhci-pltfm.c |3 +
drivers/mmc/host/sdhci-pltfm.h |1 +
5 files changed, 155 insertions(+), 0 deletions(-)
create mode 100644 drivers/mmc/host/sdhci-esdhc.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 6f12d5d..20d03f5 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -143,6 +143,15 @@ config MMC_SDHCI_MV
If unsure, say N.
+config MMC_SDHCI_ESDHC
+ bool SDHCI platform support for the Freescale eSDHC controller
Maybe Freescale IMX eSDHC? Let's keep MPC and IMX eSDHC
separate as it's quite possible that they may have different
bugs and limitations.
[...]
+#include linux/io.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/mmc/host.h
+#include linux/mmc/sdhci-pltfm.h
+#include sdhci.h
+#include sdhci-esdhc.h
+#include sdhci-pltfm.h
+
+static inline void esdhc_clrset_le(struct sdhci_host *host, u32 mask, u32
val, int reg)
+{
+ void __iomem *base = host-ioaddr + (reg ~0x3);
#include linux/compiler.h is needed for __iomem.
[...]
+static unsigned int esdhc_pltfm_get_max_clock(struct sdhci_host *host)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
Please put an empty line here.
+ return clk_get_rate(pltfm_host-clk);
+}
+
+static unsigned int esdhc_pltfm_get_min_clock(struct sdhci_host *host)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
Ditto.
+ return clk_get_rate(pltfm_host-clk) / 256 / 16;
+}
[...]
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -164,6 +164,9 @@ static const struct platform_device_id sdhci_pltfm_ids[]
= {
#ifdef CONFIG_MMC_SDHCI_CNS3XXX
{ sdhci-cns3xxx, (kernel_ulong_t)sdhci_cns3xxx_pdata },
#endif
+#ifdef CONFIG_MMC_SDHCI_ESDHC
+ { sdhci-esdhc, (kernel_ulong_t)sdhci_esdhc_pdata },
sdhci-esdhc-imx, sdhci_esdhc_imx_pdata.
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mmc: sdhci-pltfm: Add structure for host-specific data
On Tue, Sep 21, 2010 at 02:30:07PM +0200, Wolfram Sang wrote:
We need to carry some information per host, e.g. the clock. Add a
structure for it and initialize it in the generic part.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
---
[...]
diff --git a/drivers/mmc/host/sdhci-pltfm.h b/drivers/mmc/host/sdhci-pltfm.h
index 900f329..c393289 100644
--- a/drivers/mmc/host/sdhci-pltfm.h
+++ b/drivers/mmc/host/sdhci-pltfm.h
@@ -13,6 +13,11 @@
#include linux/sdhci-pltfm.h
+struct sdhci_pltfm_host {
+ struct clk *clk;
Forward decl for struct clk is needed.
+ u32 scratchpad; /* to handle quirks across io-accessor calls */
#include linux/types.h is needed for u32.
Thanks,
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: HSMMC cmd line reset change
* Madhusudhan madhu...@ti.com [100920 09:06]: Please don't use cpu_is_omap tests in the drivers, drivers should be generic. Instead, just pass a feature flag in the platform_data for this feature like HSMMC_REVERSE_RESET_LOGIC or similar. This is not a feature. It is like an ERRATA fix. I am yet to receive an errata number though. How about dealing with this like an errata fix similar to the way in arch/mach-omap2/serial.c done for the uart case? Yes setting some HSMMC_ERRATA_XYZ flag works too. The mmc ip revision will not help because it really does not change to distinguish such issues. OK. Then I guess your only option is to pass the errata flag in the platform_data. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add support PXA168/PXA910/MMP2 SD Host Controller
Hi Wolfram, On Tue, Sep 21, 2010 at 12:11:16PM +0200, Wolfram Sang wrote: I guess to fully understand all constraints, one must really working with your platform, what I don't do. I agree that a nicely working driver is better than no driver; however, I fear once a driver hit the mainline being non-pltfm, it will hardly be converted later, even if it was considered to be worthwhile. So this is why I ask initially if it couldn't be done. Chris, do you see a rule of thumb here? Or what are your preferences? I agree with you entirely: even if we end up deciding not to use -pltfm here (which looks like it's probably going to be the case), we should at least specify what's stopping us from doing so and look into extending -pltfm so that it might be useful next time around. So, thank you for asking those questions! - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sdhci: allow for eMMC 74 clock generation by controller
On Tue, Sep 21, 2010 at 08:06:20AM -0700, Philip Rakity wrote: Our hardware needs to be programmed to handle this case. The host-ops option is only needed from h/w that does not handle this. If you can suggest a way to do this in the mmc layer I would welcome implementing it. I looked and the solution requires a call into the driver from the mmc layer after the all setting POWER_ON call. This was more intrusive than doing it in the driver but if you think this makes sense I can do a patch for that. Do you have a draft patch for this intrusive way (can be quick'n'dirty)? It is usually easier to think about such issues if there is some code... -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH] add support PXA168/PXA910/MMP2 SD Host Controller
Hi, On Mon, Sep 20, 2010 at 11:16:18PM -0400, zhangfei gao wrote: We have considered using the same driver with dove once saeed push the driver, but at last we decide to use seperate driver to easy maintaince and further extension. There are different IP developed by different group between Dove and pxa168/pxa910/mmp2, and would be more and more different. The pxa serious ip is follow sdh spec 3.0, and support sd 3.0 and emmc 4.4, which need ddr50 and 1.8v requirement, the limitation is adma still has some issue and in fixing. Still some private register with differnt address, such as power control, clock timming tunning and etc. The dove ip is follow sdh spec 2.0, and it has own limitation, such as 1.8v may not be supported. In a word, they are differnt ip, and it is reasonable to use seprate driver. Okay. If we're going to have two different MV_SDHCI drivers, please coordinate to have different Kconfig entries for the Dove/MMP and MMP2 drivers that correctly identify which SoCs are supported by each, and resend. Neither driver should be called CONFIG_MV_SDHCI, since there will be no one driver for all MV_SDHCIs. Thanks, - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
