Re: [PATCH] mmc: usdhi6rol0: Remove unnecessary header files
On Sat, 20 Sep 2014, Pramod Gurav wrote: These headers are not required hence this change removes them from the driver. Cc: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com Cc: Chris Ball ch...@printf.net Cc: Ulf Hansson ulf.hans...@linaro.org Cc: linux-mmc@vger.kernel.org Signed-off-by: Pramod Gurav pramod.gu...@smartplayin.com NAK. The fact, that code builds without certain headers doesn't mean, they aren't needed. E.g. string.h is needed for memcpy(), scatterlist.h is needed for struct scatterlist etc. Thanks Guennadi --- drivers/mmc/host/usdhi6rol0.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/mmc/host/usdhi6rol0.c b/drivers/mmc/host/usdhi6rol0.c index f0a39eb..4094d8f 100644 --- a/drivers/mmc/host/usdhi6rol0.c +++ b/drivers/mmc/host/usdhi6rol0.c @@ -12,21 +12,14 @@ #include linux/device.h #include linux/dma-mapping.h #include linux/dmaengine.h -#include linux/highmem.h #include linux/interrupt.h #include linux/io.h -#include linux/log2.h #include linux/mmc/host.h #include linux/mmc/mmc.h -#include linux/mmc/sd.h #include linux/mmc/sdio.h #include linux/module.h #include linux/pagemap.h #include linux/platform_device.h -#include linux/scatterlist.h -#include linux/string.h -#include linux/time.h -#include linux/virtio.h #include linux/workqueue.h #define USDHI6_SD_CMD0x -- 1.8.3.2 -- 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: usdhi6rol0: fix compiler warnings
Hi Ulf,
On Thu, 12 Jun 2014, Ulf Hansson wrote:
On 11 June 2014 23:30, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
Fix a number of wrong print formats.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
Thanks Guennadi! Applied for fixes.
Thanks for your quick help!
Regards
Guennadi
Kind regards
Uffe
---
Chris, the possibl NULL mrq warning is bogus. It cannot be NULL in the
USDHI6_WAIT_FOR_STOP state. But if you prefer, I can fix that one too.
drivers/mmc/host/usdhi6rol0.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/usdhi6rol0.c b/drivers/mmc/host/usdhi6rol0.c
index eb2bbbe..f0a39eb 100644
--- a/drivers/mmc/host/usdhi6rol0.c
+++ b/drivers/mmc/host/usdhi6rol0.c
@@ -357,7 +357,7 @@ static void *usdhi6_sg_map(struct usdhi6_host *host)
WARN(host-pg.page, %p not properly unmapped!\n, host-pg.page);
if (WARN(sg_dma_len(sg) % data-blksz,
-SG size %zd isn't a multiple of block size %zd\n,
+SG size %u isn't a multiple of block size %u\n,
sg_dma_len(sg), data-blksz))
return NULL;
@@ -459,7 +459,7 @@ static void usdhi6_sg_advance(struct usdhi6_host *host)
done = (host-page_idx PAGE_SHIFT) + host-offset;
total = host-sg-offset + sg_dma_len(host-sg);
- dev_dbg(mmc_dev(host-mmc), %s(): %zu of %zu @ %u\n, __func__,
+ dev_dbg(mmc_dev(host-mmc), %s(): %zu of %zu @ %zu\n, __func__,
done, total, host-offset);
if (done total host-offset) {
@@ -489,7 +489,7 @@ static void usdhi6_sg_advance(struct usdhi6_host *host)
host-sg = next;
if (WARN(next sg_dma_len(next) % data-blksz,
-SG size %zd isn't a multiple of block size %zd\n,
+SG size %u isn't a multiple of block size %u\n,
sg_dma_len(next), data-blksz))
data-error = -EINVAL;
@@ -896,7 +896,7 @@ static void usdhi6_request_done(struct usdhi6_host
*host)
struct mmc_data *data = mrq-data;
if (WARN(host-pg.page || host-head_pg.page,
-Page %p or %p not unmapped: wait %u, CMD%d(%c) @ +0x%x
%ux%u in SG%u!\n,
+Page %p or %p not unmapped: wait %u, CMD%d(%c) @ +0x%zx
%ux%u in SG%u!\n,
host-pg.page, host-head_pg.page, host-wait,
mrq-cmd-opcode,
data ? (data-flags MMC_DATA_READ ? 'R' : 'W') : '-',
data ? host-offset : 0, data ? data-blocks : 0,
@@ -1666,7 +1666,7 @@ static void usdhi6_timeout_work(struct work_struct
*work)
case USDHI6_WAIT_FOR_READ:
case USDHI6_WAIT_FOR_WRITE:
dev_dbg(mmc_dev(host-mmc),
- %c: page #%u @ +0x%x %ux%u in SG%u. Current SG %u
bytes @ %u\n,
+ %c: page #%u @ +0x%zx %ux%u in SG%u. Current SG %u
bytes @ %u\n,
data-flags MMC_DATA_READ ? 'R' : 'W',
host-page_idx,
host-offset, data-blocks, data-blksz,
data-sg_len,
sg_dma_len(host-sg), host-sg-offset);
--
1.9.3
--
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 v4] mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller
On Wed, 11 Jun 2014, Chris Ball wrote: Hi Guennadi, On Sat, May 31 2014, Guennadi Liakhovetski wrote: This patch adds a driver for the Renesas usdhi6rol0 SD/SDIO host controller in both PIO and DMA modes. Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com --- v4: replaced several numerical values with macros Please send fixes for the compiler warnings, potential-null mrq, Sure, it's on my todo for Saturday, is this ok? and perhaps add an ARCH_ dependency to stop this building on x86_64. Is there a specific reason to only build it on ARM? It can be used with various architectures, but we can make it depend on COMPILE_TEST (or whatever that option is called), but I'm not sure that's required. Thanks Guennadi -- 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] mmc: usdhi6rol0: fix compiler warnings
Fix a number of wrong print formats.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
Chris, the possibl NULL mrq warning is bogus. It cannot be NULL in the
USDHI6_WAIT_FOR_STOP state. But if you prefer, I can fix that one too.
drivers/mmc/host/usdhi6rol0.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/usdhi6rol0.c b/drivers/mmc/host/usdhi6rol0.c
index eb2bbbe..f0a39eb 100644
--- a/drivers/mmc/host/usdhi6rol0.c
+++ b/drivers/mmc/host/usdhi6rol0.c
@@ -357,7 +357,7 @@ static void *usdhi6_sg_map(struct usdhi6_host *host)
WARN(host-pg.page, %p not properly unmapped!\n, host-pg.page);
if (WARN(sg_dma_len(sg) % data-blksz,
-SG size %zd isn't a multiple of block size %zd\n,
+SG size %u isn't a multiple of block size %u\n,
sg_dma_len(sg), data-blksz))
return NULL;
@@ -459,7 +459,7 @@ static void usdhi6_sg_advance(struct usdhi6_host *host)
done = (host-page_idx PAGE_SHIFT) + host-offset;
total = host-sg-offset + sg_dma_len(host-sg);
- dev_dbg(mmc_dev(host-mmc), %s(): %zu of %zu @ %u\n, __func__,
+ dev_dbg(mmc_dev(host-mmc), %s(): %zu of %zu @ %zu\n, __func__,
done, total, host-offset);
if (done total host-offset) {
@@ -489,7 +489,7 @@ static void usdhi6_sg_advance(struct usdhi6_host *host)
host-sg = next;
if (WARN(next sg_dma_len(next) % data-blksz,
-SG size %zd isn't a multiple of block size %zd\n,
+SG size %u isn't a multiple of block size %u\n,
sg_dma_len(next), data-blksz))
data-error = -EINVAL;
@@ -896,7 +896,7 @@ static void usdhi6_request_done(struct usdhi6_host *host)
struct mmc_data *data = mrq-data;
if (WARN(host-pg.page || host-head_pg.page,
-Page %p or %p not unmapped: wait %u, CMD%d(%c) @ +0x%x %ux%u
in SG%u!\n,
+Page %p or %p not unmapped: wait %u, CMD%d(%c) @ +0x%zx %ux%u
in SG%u!\n,
host-pg.page, host-head_pg.page, host-wait,
mrq-cmd-opcode,
data ? (data-flags MMC_DATA_READ ? 'R' : 'W') : '-',
data ? host-offset : 0, data ? data-blocks : 0,
@@ -1666,7 +1666,7 @@ static void usdhi6_timeout_work(struct work_struct *work)
case USDHI6_WAIT_FOR_READ:
case USDHI6_WAIT_FOR_WRITE:
dev_dbg(mmc_dev(host-mmc),
- %c: page #%u @ +0x%x %ux%u in SG%u. Current SG %u
bytes @ %u\n,
+ %c: page #%u @ +0x%zx %ux%u in SG%u. Current SG %u
bytes @ %u\n,
data-flags MMC_DATA_READ ? 'R' : 'W', host-page_idx,
host-offset, data-blocks, data-blksz, data-sg_len,
sg_dma_len(host-sg), host-sg-offset);
--
1.9.3
--
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: [GIT PULL] MMC updates for 3.16-rc1
Hi Linus, On Wed, 11 Jun 2014, Linus Torvalds wrote: On Tue, Jun 10, 2014 at 2:50 PM, Linus Torvalds torva...@linux-foundation.org wrote: Also, that new drivers/mmc/host/usdhi6rol0.c driver is one f*cking noisy compile, and knisr certainly has never been tested in a 64-bit environment. Please either fix it, or make it depend on BROKEN. Guys? Seriously, if that driver isn't fixed, I'm going to mark it broken myself. It pretty much generates as many lines of warnings as the rest of my allmodconfig build combined. It's extremely annoying, and the crazy warnings are likely to hide potential real problems elsewhere, so right now that driver has negative value. I do a lot of allmodconfig builds during the merge window, and I am not going to look at that warning much longer. Fix it promptly, or it gets disabled. I sent a patch a few hours ago: https://patchwork.kernel.org/patch/4338531/ Since it's only changing print format strings, it should be a trivial one to review, so, just waiting for Chris to pick it up and push it to you. Sorry about the trouble. Thanks Guennadi -- 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 v4] mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller
This patch adds a driver for the Renesas usdhi6rol0 SD/SDIO host controller
in both PIO and DMA modes.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
v4: replaced several numerical values with macros
.../devicetree/bindings/mmc/usdhi6rol0.txt | 33 +
drivers/mmc/host/Kconfig |6 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/usdhi6rol0.c | 1847
4 files changed, 1887 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
create mode 100644 drivers/mmc/host/usdhi6rol0.c
diff --git a/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
new file mode 100644
index 000..8babdaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
@@ -0,0 +1,33 @@
+* Renesas usdhi6rol0 SD/SDIO host controller
+
+Required properties:
+
+- compatible: must be
+ renesas,usdhi6rol0
+- interrupts: 3 interrupts, named card detect, data and SDIO must be
+ specified
+- clocks: a clock binding for the IMCLK input
+
+Optional properties:
+
+- vmmc-supply: a phandle of a regulator, supplying Vcc to the card
+- vqmmc-supply:a phandle of a regulator, supplying VccQ to the card
+
+Additionally any standard mmc bindings from mmc.txt can be used.
+
+Example:
+
+sd0: sd@ab00 {
+ compatible = renesas,usdhi6rol0;
+ reg = 0xab00 0x200;
+ interrupts = 0 23 0x4
+ 0 24 0x4
+ 0 25 0x4;
+ interrupt-names = card detect, data, SDIO;
+ bus-width = 4;
+ max-frequency = 5000;
+ cap-power-off-card;
+ clocks = imclk;
+ vmmc-supply = vcc_sd0;
+ vqmmc-supply = vccq_sd0;
+};
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index b675882..924f973 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -688,6 +688,12 @@ config MMC_WMT
To compile this driver as a module, choose M here: the
module will be called wmt-sdmmc.
+config MMC_USDHI6ROL0
+ tristate Renesas USDHI6ROL0 SD/SDIO Host Controller support
+ help
+ This selects support for the Renesas USDHI6ROL0 SD/SDIO
+ Host Controller
+
config MMC_REALTEK_PCI
tristate Realtek PCI-E SD/MMC Card Interface Driver
depends on MFD_RTSX_PCI
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 3eb48b656..793a0d6 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
obj-$(CONFIG_MMC_VUB300) += vub300.o
obj-$(CONFIG_MMC_USHC) += ushc.o
obj-$(CONFIG_MMC_WMT) += wmt-sdmmc.o
+obj-$(CONFIG_MMC_USDHI6ROL0) += usdhi6rol0.o
obj-$(CONFIG_MMC_REALTEK_PCI) += rtsx_pci_sdmmc.o
obj-$(CONFIG_MMC_REALTEK_USB) += rtsx_usb_sdmmc.o
diff --git a/drivers/mmc/host/usdhi6rol0.c b/drivers/mmc/host/usdhi6rol0.c
new file mode 100644
index 000..eb2bbbe
--- /dev/null
+++ b/drivers/mmc/host/usdhi6rol0.c
@@ -0,0 +1,1847 @@
+/*
+ * Copyright (C) 2013-2014 Renesas Electronics Europe Ltd.
+ * Author: Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/dma-mapping.h
+#include linux/dmaengine.h
+#include linux/highmem.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/log2.h
+#include linux/mmc/host.h
+#include linux/mmc/mmc.h
+#include linux/mmc/sd.h
+#include linux/mmc/sdio.h
+#include linux/module.h
+#include linux/pagemap.h
+#include linux/platform_device.h
+#include linux/scatterlist.h
+#include linux/string.h
+#include linux/time.h
+#include linux/virtio.h
+#include linux/workqueue.h
+
+#define USDHI6_SD_CMD 0x
+#define USDHI6_SD_PORT_SEL 0x0004
+#define USDHI6_SD_ARG 0x0008
+#define USDHI6_SD_STOP 0x0010
+#define USDHI6_SD_SECCNT 0x0014
+#define USDHI6_SD_RSP100x0018
+#define USDHI6_SD_RSP320x0020
+#define USDHI6_SD_RSP540x0028
+#define USDHI6_SD_RSP760x0030
+#define USDHI6_SD_INFO10x0038
+#define USDHI6_SD_INFO20x003c
+#define USDHI6_SD_INFO1_MASK 0x0040
+#define USDHI6_SD_INFO2_MASK 0x0044
+#define USDHI6_SD_CLK_CTRL 0x0048
+#define USDHI6_SD_SIZE 0x004c
+#define USDHI6_SD_OPTION 0x0050
+#define USDHI6_SD_ERR_STS1 0x0058
+#define USDHI6_SD_ERR_STS2 0x005c
+#define USDHI6_SD_BUF0 0x0060
+#define USDHI6_SDIO_MODE 0x0068
+#define USDHI6_SDIO_INFO1 0x006c
+#define USDHI6_SDIO_INFO1_MASK 0x0070
+#define USDHI6_CC_EXT_MODE 0x01b0
Re: [PATCH v2] mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller
Hi Chris,
What's the status of this patch? Would be great to get it in for 3.16.
Thanks
Guennadi
On Sat, 26 Apr 2014, Guennadi Liakhovetski wrote:
This patch adds a driver for the Renesas usdhi6rol0 SD/SDIO host controller
in both PIO and DMA modes.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
v2: copyright and Sob email changed
.../devicetree/bindings/mmc/usdhi6rol0.txt | 33 +
drivers/mmc/host/Kconfig |6 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/usdhi6rol0.c | 1834
4 files changed, 1874 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
create mode 100644 drivers/mmc/host/usdhi6rol0.c
diff --git a/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
new file mode 100644
index 000..8babdaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
@@ -0,0 +1,33 @@
+* Renesas usdhi6rol0 SD/SDIO host controller
+
+Required properties:
+
+- compatible:must be
+ renesas,usdhi6rol0
+- interrupts:3 interrupts, named card detect, data and SDIO
must be
+ specified
+- clocks:a clock binding for the IMCLK input
+
+Optional properties:
+
+- vmmc-supply: a phandle of a regulator, supplying Vcc to the card
+- vqmmc-supply: a phandle of a regulator, supplying VccQ to the card
+
+Additionally any standard mmc bindings from mmc.txt can be used.
+
+Example:
+
+sd0: sd@ab00 {
+ compatible = renesas,usdhi6rol0;
+ reg = 0xab00 0x200;
+ interrupts = 0 23 0x4
+ 0 24 0x4
+ 0 25 0x4;
+ interrupt-names = card detect, data, SDIO;
+ bus-width = 4;
+ max-frequency = 5000;
+ cap-power-off-card;
+ clocks = imclk;
+ vmmc-supply = vcc_sd0;
+ vqmmc-supply = vccq_sd0;
+};
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 8aaf8c1..a21d8b5 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -688,6 +688,12 @@ config MMC_WMT
To compile this driver as a module, choose M here: the
module will be called wmt-sdmmc.
+config MMC_USDHI6ROL0
+ tristate Renesas USDHI6ROL0 SD/SDIO Host Controller support
+ help
+ This selects support for the Renesas USDHI6ROL0 SD/SDIO
+ Host Controller
+
config MMC_REALTEK_PCI
tristate Realtek PCI-E SD/MMC Card Interface Driver
depends on MFD_RTSX_PCI
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 0c8aa5e..28d1fa0 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_MMC_JZ4740)+= jz4740_mmc.o
obj-$(CONFIG_MMC_VUB300) += vub300.o
obj-$(CONFIG_MMC_USHC) += ushc.o
obj-$(CONFIG_MMC_WMT)+= wmt-sdmmc.o
+obj-$(CONFIG_MMC_USDHI6ROL0) += usdhi6rol0.o
obj-$(CONFIG_MMC_REALTEK_PCI)+= rtsx_pci_sdmmc.o
diff --git a/drivers/mmc/host/usdhi6rol0.c b/drivers/mmc/host/usdhi6rol0.c
new file mode 100644
index 000..261b245
--- /dev/null
+++ b/drivers/mmc/host/usdhi6rol0.c
@@ -0,0 +1,1834 @@
+/*
+ * Copyright (C) 2013-2014 Renesas Electronics Europe Ltd.
+ * Author: Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/dma-mapping.h
+#include linux/dmaengine.h
+#include linux/highmem.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/log2.h
+#include linux/mmc/host.h
+#include linux/mmc/mmc.h
+#include linux/mmc/sd.h
+#include linux/mmc/sdio.h
+#include linux/module.h
+#include linux/pagemap.h
+#include linux/platform_device.h
+#include linux/scatterlist.h
+#include linux/string.h
+#include linux/time.h
+#include linux/virtio.h
+#include linux/workqueue.h
+
+#define USDHI6_SD_CMD0x
+#define USDHI6_SD_PORT_SEL 0x0004
+#define USDHI6_SD_ARG0x0008
+#define USDHI6_SD_STOP 0x0010
+#define USDHI6_SD_SECCNT 0x0014
+#define USDHI6_SD_RSP10 0x0018
+#define USDHI6_SD_RSP32 0x0020
+#define USDHI6_SD_RSP54 0x0028
+#define USDHI6_SD_RSP76 0x0030
+#define USDHI6_SD_INFO1 0x0038
+#define USDHI6_SD_INFO2 0x003c
+#define USDHI6_SD_INFO1_MASK 0x0040
+#define USDHI6_SD_INFO2_MASK 0x0044
+#define USDHI6_SD_CLK_CTRL 0x0048
+#define USDHI6_SD_SIZE 0x004c
+#define USDHI6_SD_OPTION 0x0050
+#define USDHI6_SD_ERR_STS1 0x0058
+#define USDHI6_SD_ERR_STS2
[PATCH v3] mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller
This patch adds a driver for the Renesas usdhi6rol0 SD/SDIO host controller
in both PIO and DMA modes.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
v3:
1. remove a redundant TODO
2. update the timeout to 4 seconds
.../devicetree/bindings/mmc/usdhi6rol0.txt | 33 +
drivers/mmc/host/Kconfig |6 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/usdhi6rol0.c | 1833
4 files changed, 1873 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
create mode 100644 drivers/mmc/host/usdhi6rol0.c
diff --git a/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
new file mode 100644
index 000..8babdaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
@@ -0,0 +1,33 @@
+* Renesas usdhi6rol0 SD/SDIO host controller
+
+Required properties:
+
+- compatible: must be
+ renesas,usdhi6rol0
+- interrupts: 3 interrupts, named card detect, data and SDIO must be
+ specified
+- clocks: a clock binding for the IMCLK input
+
+Optional properties:
+
+- vmmc-supply: a phandle of a regulator, supplying Vcc to the card
+- vqmmc-supply:a phandle of a regulator, supplying VccQ to the card
+
+Additionally any standard mmc bindings from mmc.txt can be used.
+
+Example:
+
+sd0: sd@ab00 {
+ compatible = renesas,usdhi6rol0;
+ reg = 0xab00 0x200;
+ interrupts = 0 23 0x4
+ 0 24 0x4
+ 0 25 0x4;
+ interrupt-names = card detect, data, SDIO;
+ bus-width = 4;
+ max-frequency = 5000;
+ cap-power-off-card;
+ clocks = imclk;
+ vmmc-supply = vcc_sd0;
+ vqmmc-supply = vccq_sd0;
+};
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index b675882..924f973 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -688,6 +688,12 @@ config MMC_WMT
To compile this driver as a module, choose M here: the
module will be called wmt-sdmmc.
+config MMC_USDHI6ROL0
+ tristate Renesas USDHI6ROL0 SD/SDIO Host Controller support
+ help
+ This selects support for the Renesas USDHI6ROL0 SD/SDIO
+ Host Controller
+
config MMC_REALTEK_PCI
tristate Realtek PCI-E SD/MMC Card Interface Driver
depends on MFD_RTSX_PCI
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 3eb48b656..793a0d6 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
obj-$(CONFIG_MMC_VUB300) += vub300.o
obj-$(CONFIG_MMC_USHC) += ushc.o
obj-$(CONFIG_MMC_WMT) += wmt-sdmmc.o
+obj-$(CONFIG_MMC_USDHI6ROL0) += usdhi6rol0.o
obj-$(CONFIG_MMC_REALTEK_PCI) += rtsx_pci_sdmmc.o
obj-$(CONFIG_MMC_REALTEK_USB) += rtsx_usb_sdmmc.o
diff --git a/drivers/mmc/host/usdhi6rol0.c b/drivers/mmc/host/usdhi6rol0.c
new file mode 100644
index 000..ea2d968
--- /dev/null
+++ b/drivers/mmc/host/usdhi6rol0.c
@@ -0,0 +1,1833 @@
+/*
+ * Copyright (C) 2013-2014 Renesas Electronics Europe Ltd.
+ * Author: Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/dma-mapping.h
+#include linux/dmaengine.h
+#include linux/highmem.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/log2.h
+#include linux/mmc/host.h
+#include linux/mmc/mmc.h
+#include linux/mmc/sd.h
+#include linux/mmc/sdio.h
+#include linux/module.h
+#include linux/pagemap.h
+#include linux/platform_device.h
+#include linux/scatterlist.h
+#include linux/string.h
+#include linux/time.h
+#include linux/virtio.h
+#include linux/workqueue.h
+
+#define USDHI6_SD_CMD 0x
+#define USDHI6_SD_PORT_SEL 0x0004
+#define USDHI6_SD_ARG 0x0008
+#define USDHI6_SD_STOP 0x0010
+#define USDHI6_SD_SECCNT 0x0014
+#define USDHI6_SD_RSP100x0018
+#define USDHI6_SD_RSP320x0020
+#define USDHI6_SD_RSP540x0028
+#define USDHI6_SD_RSP760x0030
+#define USDHI6_SD_INFO10x0038
+#define USDHI6_SD_INFO20x003c
+#define USDHI6_SD_INFO1_MASK 0x0040
+#define USDHI6_SD_INFO2_MASK 0x0044
+#define USDHI6_SD_CLK_CTRL 0x0048
+#define USDHI6_SD_SIZE 0x004c
+#define USDHI6_SD_OPTION 0x0050
+#define USDHI6_SD_ERR_STS1 0x0058
+#define USDHI6_SD_ERR_STS2 0x005c
+#define USDHI6_SD_BUF0 0x0060
+#define USDHI6_SDIO_MODE 0x0068
+#define USDHI6_SDIO_INFO1 0x006c
+#define USDHI6_SDIO_INFO1_MASK 0x0070
+#define
RE: [PATCH v2] mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller
Hi Phil,
Thanks for the comments.
On Mon, 28 Apr 2014, Phil Edworthy wrote:
Hi Guennadi,
On 26 April 2014 13:06, Guennadi wrote:
Subject: [PATCH v2] mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO
host controller
This patch adds a driver for the Renesas usdhi6rol0 SD/SDIO host controller
in both PIO and DMA modes.
...
+static void usdhi6_dma_stop_unmap(struct usdhi6_host *host)
+{
+ struct mmc_data *data = host-mrq-data;
+
+ if (!host-dma_active)
+ return;
+
+ usdhi6_write(host, USDHI6_CC_EXT_MODE, 0);
+ host-dma_active = false;
+
+ if (data-flags MMC_DATA_READ)
+ /* TODO: do we have to synchronise? */
+ dma_unmap_sg(host-chan_rx-device-dev, data-sg,
+data-sg_len, DMA_FROM_DEVICE);
Yes, you have to sync, so you can remove this TODO comment.
Why do you think so? If we really do, we'd have to add it. And I did think
synchronisation was needed, that's why I posted this patch series:
http://thread.gmane.org/gmane.linux.kernel.mmc/24969
but it never got applied, even though it got 2 acks. And actually now I
think that synchronisation isn't needed. I think dma_map_sg() /
dma_unmap_sg() do that for us already. E.g.
dma_map_sg_attrs()
arm_dma_map_page()
__dma_page_cpu_to_dev()
dmac_map_area()
cpu_cache.dma_map_area()
v7_dma_inv_range()
v7_dma_clean_range()
Similar for unmapping. So, I think it would be best to remove the comment
without adding synchronisation.
Let me do this: I'll prepare a separate patch for adding dma syncs, but I
won't submit it for now, or I can just provide it for reference.
...
+static int usdhi6_probe(struct platform_device *pdev)
+{
...
+ host= mmc_priv(mmc);
+ host-mmc = mmc;
+ host-wait = USDHI6_WAIT_FOR_REQUEST;
+ host-timeout = msecs_to_jiffies(1000);
In all places you use host-timeout, the code uses host-timeout * 4.
Wouldn't it better to just set it here to 4 seconds?
ok, I'll do that for v3.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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] mmc: add a driver for the Renesas v08r07s01e SD/SDIO host controller
This patch adds a driver for the Renesas v08r07s01e SD/SDIO host controller
in both PIO and DMA modes.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Tested on a Xilinx zc706-based board with SD, MMC and SDIO cards.
.../devicetree/bindings/mmc/v08r07s01e.txt | 33 +
drivers/mmc/host/Kconfig |6 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/v08r07s01e.c | 1835
4 files changed, 1875 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/v08r07s01e.txt
create mode 100644 drivers/mmc/host/v08r07s01e.c
diff --git a/Documentation/devicetree/bindings/mmc/v08r07s01e.txt
b/Documentation/devicetree/bindings/mmc/v08r07s01e.txt
new file mode 100644
index 000..60e6cb5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/v08r07s01e.txt
@@ -0,0 +1,33 @@
+* Renesas v08r07s01e SD/SDIO host controller
+
+Required properties:
+
+- compatible: must be
+ renesas,v08r07s01e
+- interrupts: 3 interrupts, named card detect, data and SDIO must be
+ specified
+- clocks: a clock binding for the IMCLK input
+
+Optional properties:
+
+- vmmc-supply: a phandle of a regulator, supplying Vcc to the card
+- vqmmc-supply:a phandle of a regulator, supplying VccQ to the card
+
+Additionally any standard mmc bindings from mmc.txt can be used.
+
+Example:
+
+sd0: sd@ab00 {
+ compatible = renesas,v08r07s01e;
+ reg = 0xab00 0x200;
+ interrupts = 0 23 0x4
+ 0 24 0x4
+ 0 25 0x4;
+ interrupt-names = card detect, data, SDIO;
+ bus-width = 4;
+ max-frequency = 5000;
+ cap-power-off-card;
+ clocks = imclk;
+ vmmc-supply = vcc_sd0;
+ vqmmc-supply = vccq_sd0;
+};
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 8aaf8c1..0feccd5 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -688,6 +688,12 @@ config MMC_WMT
To compile this driver as a module, choose M here: the
module will be called wmt-sdmmc.
+config MMC_V08R07S01E
+ tristate Renesas V08R07S01E SD/SDIO Host Controller support
+ help
+ This selects support for the Renesas V08R07S01E SD/SDIO
+ Host Controller
+
config MMC_REALTEK_PCI
tristate Realtek PCI-E SD/MMC Card Interface Driver
depends on MFD_RTSX_PCI
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 0c8aa5e..d7d3ee9 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
obj-$(CONFIG_MMC_VUB300) += vub300.o
obj-$(CONFIG_MMC_USHC) += ushc.o
obj-$(CONFIG_MMC_WMT) += wmt-sdmmc.o
+obj-$(CONFIG_MMC_V08R07S01E) += v08r07s01e.o
obj-$(CONFIG_MMC_REALTEK_PCI) += rtsx_pci_sdmmc.o
diff --git a/drivers/mmc/host/v08r07s01e.c b/drivers/mmc/host/v08r07s01e.c
new file mode 100644
index 000..4eb9ce1
--- /dev/null
+++ b/drivers/mmc/host/v08r07s01e.c
@@ -0,0 +1,1835 @@
+/*
+ * Copyright (C) 2013-2014 Renesas Europe Ltd.
+ * Author: Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/dma-mapping.h
+#include linux/dmaengine.h
+#include linux/highmem.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/log2.h
+#include linux/mmc/host.h
+#include linux/mmc/mmc.h
+#include linux/mmc/sd.h
+#include linux/mmc/sdio.h
+#include linux/module.h
+#include linux/pagemap.h
+#include linux/platform_device.h
+#include linux/scatterlist.h
+#include linux/string.h
+#include linux/time.h
+#include linux/virtio.h
+#include linux/workqueue.h
+
+#define V08R07_SD_CMD 0x
+#define V08R07_SD_PORT_SEL 0x0004
+#define V08R07_SD_ARG 0x0008
+#define V08R07_SD_STOP 0x0010
+#define V08R07_SD_SECCNT 0x0014
+#define V08R07_SD_RSP100x0018
+#define V08R07_SD_RSP320x0020
+#define V08R07_SD_RSP540x0028
+#define V08R07_SD_RSP760x0030
+#define V08R07_SD_INFO10x0038
+#define V08R07_SD_INFO20x003c
+#define V08R07_SD_INFO1_MASK 0x0040
+#define V08R07_SD_INFO2_MASK 0x0044
+#define V08R07_SD_CLK_CTRL 0x0048
+#define V08R07_SD_SIZE 0x004c
+#define V08R07_SD_OPTION 0x0050
+#define V08R07_SD_ERR_STS1 0x0058
+#define V08R07_SD_ERR_STS2 0x005c
+#define V08R07_SD_BUF0 0x0060
+#define V08R07_SDIO_MODE 0x0068
+#define V08R07_SDIO_INFO1 0x006c
+#define V08R07_SDIO_INFO1_MASK 0x0070
+#define V08R07_CC_EXT_MODE 0x01b0
+#define V08R07_SOFT_RST0x01c0
+#define
Re: [PATCH RFC] mmc: slot-gpio: Convert to gpiod_* API
)
+ return ret;
+ }
+
+ /*
+ * Even if gpiod_to_irq() returns a valid IRQ number, the platform might
+ * still prefer to poll, e.g., because that IRQ number is already used
+ * by another unit and cannot be shared.
+ */
+ if (!(host-caps MMC_CAP_NEEDS_POLL)) {
+ host-slot.cd_irq = gpiod_to_irq(ctx-cd_gpio);
+ ret = devm_request_threaded_irq(host-class_dev,
+ host-slot.cd_irq, NULL, mmc_gpio_cd_irq,
+ IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING |
IRQF_ONESHOT,
+ ctx-cd_label, host);
+ if (ret)
+ host-slot.cd_irq = ret;
+ } else {
+ host-slot.cd_irq = -EINVAL;
+ }
+
+ if (host-slot.cd_irq 0)
+ host-caps |= MMC_CAP_NEEDS_POLL;
+
+ return ret;
}
EXPORT_SYMBOL(mmc_gpio_request_cd);
@@ -214,18 +250,41 @@ EXPORT_SYMBOL(mmc_gpio_request_cd);
* It's provided only for cases that client drivers need to manually free
* up the write-protection gpio requested by mmc_gpio_request_ro().
*/
+void mmc_gpiod_free(struct mmc_host *host)
+{
+ struct mmc_gpio *ctx = host-slot.handler_priv;
+
+ if (!ctx)
+ return;
+
+ if (!IS_ERR_OR_NULL(ctx-ro_gpio))
+ devm_gpiod_put(host-class_dev, ctx-ro_gpio);
+
+ if (!IS_ERR_OR_NULL(ctx-cd_gpio)) {
+ if (host-slot.cd_irq = 0) {
+ devm_free_irq(host-class_dev, host-slot.cd_irq,
host);
+ host-slot.cd_irq = -EINVAL;
+ }
+
+ devm_gpiod_put(host-class_dev, ctx-cd_gpio);
+ }
+
+ devm_kfree(host-class_dev, ctx);
+
+ ctx = NULL;
+}
+EXPORT_SYMBOL(mmc_gpiod_free);
+
void mmc_gpio_free_ro(struct mmc_host *host)
{
struct mmc_gpio *ctx = host-slot.handler_priv;
- int gpio;
- if (!ctx || !gpio_is_valid(ctx-ro_gpio))
+ if (!ctx || IS_ERR_OR_NULL(ctx-ro_gpio))
return;
- gpio = ctx-ro_gpio;
- ctx-ro_gpio = -EINVAL;
+ devm_gpiod_put(host-class_dev, ctx-ro_gpio);
- devm_gpio_free(host-class_dev, gpio);
+ ctx-ro_gpio = NULL;
}
EXPORT_SYMBOL(mmc_gpio_free_ro);
@@ -239,9 +298,8 @@ EXPORT_SYMBOL(mmc_gpio_free_ro);
void mmc_gpio_free_cd(struct mmc_host *host)
{
struct mmc_gpio *ctx = host-slot.handler_priv;
- int gpio;
- if (!ctx || !gpio_is_valid(ctx-cd_gpio))
+ if (!ctx || IS_ERR_OR_NULL(ctx-cd_gpio))
return;
if (host-slot.cd_irq = 0) {
@@ -249,9 +307,8 @@ void mmc_gpio_free_cd(struct mmc_host *host)
host-slot.cd_irq = -EINVAL;
}
- gpio = ctx-cd_gpio;
- ctx-cd_gpio = -EINVAL;
+ devm_gpiod_put(host-class_dev, ctx-cd_gpio);
- devm_gpio_free(host-class_dev, gpio);
+ ctx-cd_gpio = NULL;
}
EXPORT_SYMBOL(mmc_gpio_free_cd);
diff --git a/include/linux/mmc/slot-gpio.h b/include/linux/mmc/slot-gpio.h
index b0c73e4..a31ed96 100644
--- a/include/linux/mmc/slot-gpio.h
+++ b/include/linux/mmc/slot-gpio.h
@@ -14,10 +14,18 @@
struct mmc_host;
int mmc_gpio_get_ro(struct mmc_host *host);
+#define mmc_gpiod_get_ro(host) mmc_gpio_get_ro(host)
+int mmc_gpiod_request_ro(struct mmc_host *host);
+
+int mmc_gpio_get_cd(struct mmc_host *host);
+#define mmc_gpiod_get_cd(host) mmc_gpio_get_cd(host)
+int mmc_gpiod_request_cd(struct mmc_host *host, unsigned int debounce);
+
+void mmc_gpiod_free(struct mmc_host *host);
+
int mmc_gpio_request_ro(struct mmc_host *host, unsigned int gpio);
void mmc_gpio_free_ro(struct mmc_host *host);
-int mmc_gpio_get_cd(struct mmc_host *host);
int mmc_gpio_request_cd(struct mmc_host *host, unsigned int gpio,
unsigned int debounce);
void mmc_gpio_free_cd(struct mmc_host *host);
--
1.8.3.2
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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/3] mmc: tmio-mmc: add DMA SG synchronisation
Hi Ben On Thu, 6 Feb 2014, Ben Dooks wrote: On 31/01/14 11:54, Guennadi Liakhovetski wrote: According to the DMA API data has to be synchronised before starting a DMA transfer to device and after completing a DMA transfer from device. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de I've got 1/3 and 2/3, but not 3/3 ? Unfortunately that thread didn't make it to the ALKML - all patches bounced, so, they only arrived to sh and mmc. (A day before and a couple of hours later posting to ALKML worked just fine, just that one time...). You can view the whole thread here http://thread.gmane.org/gmane.linux.kernel.mmc/24969/focus=24972 Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 0/3] mmc: add DMA SG synchronisation
Hi This is something, that seems to be missing from all mmc host drivers. At least all except sdhci and, possibly, mmc-spi, but sdhci uses its own DMA engine, and mmc-spi does DMA synchronisation in a somewhat strange way - before and after SPI synchronisation for both data transfer directions. Otherwise all other drivers map and unmap SG lists, perform DMA transfers, but never call dma_sync_*_for_*(). Apparantly, this works, but IIUC, this violates the DMA API. I'm attaching a couple of patches for a couple of those drivers for consideration. If this is confirmed to be the right thing to do, I could do more of those. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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/3] mmc: tmio-mmc: add DMA SG synchronisation
According to the DMA API data has to be synchronised before starting
a DMA transfer to device and after completing a DMA transfer from device.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/mmc/host/tmio_mmc_dma.c | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc_dma.c b/drivers/mmc/host/tmio_mmc_dma.c
index 65edb4a..a997b94 100644
--- a/drivers/mmc/host/tmio_mmc_dma.c
+++ b/drivers/mmc/host/tmio_mmc_dma.c
@@ -168,9 +168,12 @@ static void tmio_mmc_start_dma_tx(struct tmio_mmc_host
*host)
}
ret = dma_map_sg(chan-device-dev, sg, host-sg_len, DMA_TO_DEVICE);
- if (ret 0)
+ if (ret 0) {
+ dma_sync_sg_for_device(chan-device-dev, sg, host-sg_len,
+ DMA_TO_DEVICE);
desc = dmaengine_prep_slave_sg(chan, sg, ret,
DMA_MEM_TO_DEV, DMA_CTRL_ACK);
+ }
if (desc) {
cookie = dmaengine_submit(desc);
@@ -247,14 +250,14 @@ static void tmio_mmc_tasklet_fn(unsigned long arg)
if (!host-data)
goto out;
- if (host-data-flags MMC_DATA_READ)
- dma_unmap_sg(host-chan_rx-device-dev,
-host-sg_ptr, host-sg_len,
-DMA_FROM_DEVICE);
- else
- dma_unmap_sg(host-chan_tx-device-dev,
-host-sg_ptr, host-sg_len,
-DMA_TO_DEVICE);
+ if (host-data-flags MMC_DATA_READ) {
+ struct device *dev = host-chan_rx-device-dev;
+ dma_unmap_sg(dev, host-sg_ptr, host-sg_len, DMA_FROM_DEVICE);
+ dma_sync_sg_for_cpu(dev, host-sg_ptr, host-sg_len,
DMA_FROM_DEVICE);
+ } else {
+ struct device *dev = host-chan_tx-device-dev;
+ dma_unmap_sg(dev, host-sg_ptr, host-sg_len, DMA_TO_DEVICE);
+ }
tmio_mmc_do_data_irq(host);
out:
--
1.7.2.5
--
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/3] mmc: sh-mmcif: add DMA SG synchronisation
According to the DMA API data has to be synchronised before starting
a DMA transfer to device and after completing a DMA transfer from device.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/mmc/host/sh_mmcif.c | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index d032b08..902780c 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -345,6 +345,8 @@ static void sh_mmcif_start_dma_tx(struct sh_mmcif_host
*host)
DMA_TO_DEVICE);
if (ret 0) {
host-dma_active = true;
+ dma_sync_sg_for_device(chan-device-dev, sg, data-sg_len,
+ DMA_TO_DEVICE);
desc = dmaengine_prep_slave_sg(chan, sg, ret,
DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
}
@@ -1118,14 +1120,14 @@ static bool sh_mmcif_end_cmd(struct sh_mmcif_host *host)
time = wait_for_completion_interruptible_timeout(host-dma_complete,
host-timeout);
- if (data-flags MMC_DATA_READ)
- dma_unmap_sg(host-chan_rx-device-dev,
-data-sg, data-sg_len,
-DMA_FROM_DEVICE);
- else
- dma_unmap_sg(host-chan_tx-device-dev,
-data-sg, data-sg_len,
-DMA_TO_DEVICE);
+ if (data-flags MMC_DATA_READ) {
+ struct device *dev = host-chan_rx-device-dev;
+ dma_unmap_sg(dev, data-sg, data-sg_len, DMA_FROM_DEVICE);
+ dma_sync_sg_for_cpu(dev, data-sg, data-sg_len,
DMA_FROM_DEVICE);
+ } else {
+ struct device *dev = host-chan_tx-device-dev;
+ dma_unmap_sg(dev, data-sg, data-sg_len, DMA_TO_DEVICE);
+ }
if (host-sd_error) {
dev_err(host-mmc-parent,
--
1.7.2.5
--
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 3/3] mmc: mxcmmc: add DMA SG synchronisation
According to the DMA API data has to be synchronised before starting
a DMA transfer to device and after completing a DMA transfer from device.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/mmc/host/mxcmmc.c | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c
index f7199c8..31dfc7b 100644
--- a/drivers/mmc/host/mxcmmc.c
+++ b/drivers/mmc/host/mxcmmc.c
@@ -326,6 +326,7 @@ static inline void mxcmci_swap_buffers(struct mmc_data
*data) {}
static int mxcmci_setup_data(struct mxcmci_host *host, struct mmc_data *data)
{
+ struct device *dev = host-dma-device-dev;
unsigned int nob = data-blocks;
unsigned int blksz = data-blksz;
unsigned int datasize = nob * blksz;
@@ -363,18 +364,20 @@ static int mxcmci_setup_data(struct mxcmci_host *host,
struct mmc_data *data)
mxcmci_swap_buffers(data);
}
- nents = dma_map_sg(host-dma-device-dev, data-sg,
-data-sg_len, host-dma_dir);
+ nents = dma_map_sg(dev, data-sg, data-sg_len, host-dma_dir);
if (nents != data-sg_len)
return -EINVAL;
+ if (data-flags MMC_DATA_WRITE)
+ dma_sync_sg_for_device(dev, data-sg, data-sg_len,
+ host-dma_dir);
+
host-desc = dmaengine_prep_slave_sg(host-dma,
data-sg, data-sg_len, slave_dirn,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!host-desc) {
- dma_unmap_sg(host-dma-device-dev, data-sg, data-sg_len,
- host-dma_dir);
+ dma_unmap_sg(dev, data-sg, data-sg_len, host-dma_dir);
host-do_dma = 0;
return 0; /* Fall back to PIO */
}
@@ -487,8 +490,11 @@ static int mxcmci_finish_data(struct mxcmci_host *host,
unsigned int stat)
int data_error;
if (mxcmci_use_dma(host)) {
- dma_unmap_sg(host-dma-device-dev, data-sg, data-sg_len,
- host-dma_dir);
+ struct device *dev = host-dma-device-dev;
+ dma_unmap_sg(dev, data-sg, data-sg_len, host-dma_dir);
+ if (host-dma_dir == DMA_FROM_DEVICE)
+ dma_sync_sg_for_cpu(dev, data-sg, data-sg_len,
+ host-dma_dir);
mxcmci_swap_buffers(data);
}
--
1.7.2.5
--
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: [Q] block / zynq: DMA bouncing
Hi Ben, On Mon, 27 Jan 2014, Ben Dooks wrote: On Mon, Jan 27, 2014 at 04:13:56PM +0100, Guennadi Liakhovetski wrote: Hi all, I'm working on an MMC driver with a DMA capability. All has been working well, until at some point I've got a bus error, when the mmc driver had been handed in a buffer at 0x3000 physical RAM address. The reason is, that on Zynq arch bus masters cannot access RAM below 0x8. Therefore my question: how shall I configure this in software? The way I found was to use ARM-specific struct dmabounce_device_info and implement its .needs_bounce() method to return true for those addresses. Is this the right way or is there a better / more straight-forward one? To do the above I have to enable CONFIG_DMABOUNCE, which then selects CONFIG_ZONE_DMA. Having done just that I suddenly discover, that 0x3000 buffers aren't used any more, so, I cannot actually verify my implementation :) Looking at ZONE_DMA it looks like it is still covering the whole RAM range (/proc/zoneinfo shows start_pfn=0 in zone DMA), so, I don't see why 0x3000 should be excluded now. So, is using the .needs_bounce() method the correct way to support DMA on this arch or is there a better one? I have a similar issue with Renesas R8A7790 where there is a bus bridge that can only deal with transactions to one half of the available RAM. Have you tried enabling CONFIG_DMABOUNCE? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
[Q] block / zynq: DMA bouncing
Hi all, I'm working on an MMC driver with a DMA capability. All has been working well, until at some point I've got a bus error, when the mmc driver had been handed in a buffer at 0x3000 physical RAM address. The reason is, that on Zynq arch bus masters cannot access RAM below 0x8. Therefore my question: how shall I configure this in software? The way I found was to use ARM-specific struct dmabounce_device_info and implement its .needs_bounce() method to return true for those addresses. Is this the right way or is there a better / more straight-forward one? To do the above I have to enable CONFIG_DMABOUNCE, which then selects CONFIG_ZONE_DMA. Having done just that I suddenly discover, that 0x3000 buffers aren't used any more, so, I cannot actually verify my implementation :) Looking at ZONE_DMA it looks like it is still covering the whole RAM range (/proc/zoneinfo shows start_pfn=0 in zone DMA), so, I don't see why 0x3000 should be excluded now. So, is using the .needs_bounce() method the correct way to support DMA on this arch or is there a better one? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [Q] block / zynq: DMA bouncing
Hi Michal, Russell, On Mon, 27 Jan 2014, Michal Simek wrote: On 01/27/2014 06:52 PM, Russell King - ARM Linux wrote: On Mon, Jan 27, 2014 at 06:45:50PM +0100, Michal Simek wrote: Why 0x4000? IRC Linux for ARM is using space for any purpose. Russell knows this much better than I. Probably because as the kernel is loaded at 0x8000, it will place the swapper page table at 0x4000, thus covering from 0x4000 upwards. Ah yeah swapper. Thus, the majority of your un-DMA-able memory will be kernel text or swapper page tables. Yes, exactly. 0x0 - 0x4000 - reserving not to be used by DMA 0x4000 - 0x8000 swapper page table 0x8000 - 0x8 kernel text + up Good, thanks for the explanations and examples, we'll do the same then! Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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] mmc: fix a typo in a comment
This fixes an s/hand of/hand off/ typo in queue.c
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/mmc/card/queue.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index 357bbc5..91955af 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -483,7 +483,7 @@ static unsigned int mmc_queue_packed_map_sg(struct
mmc_queue *mq,
}
/*
- * Prepare the sg list(s) to be handed of to the host driver
+ * Prepare the sg list(s) to be handed off to the host driver
*/
unsigned int mmc_queue_map_sg(struct mmc_queue *mq, struct mmc_queue_req *mqrq)
{
--
1.7.2.5
--
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: *** GMX Spamverdacht *** re: mmc: sh_mmcif: remove now superfluous sh_mmcif_host::data member
Hi Dan,
On Wed, 6 Nov 2013, Dan Carpenter wrote:
Hello Guennadi Liakhovetski,
This is a semi-automatic email about new static checker warnings.
The patch 699834045f1e: mmc: sh_mmcif: remove now superfluous
sh_mmcif_host::data member from Dec 26, 2011, leads to the following
Smatch complaint:
drivers/mmc/host/sh_mmcif.c:822 sh_mmcif_set_cmd()
error: we previously assumed 'data' could be null (see line 787)
drivers/mmc/host/sh_mmcif.c
786/* WDAT / DATW */
787if (data) {
Check.
788tmp |= CMD_SET_WDAT;
789switch (host-bus_width) {
790case MMC_BUS_WIDTH_1:
791tmp |= CMD_SET_DATW_1;
792break;
793case MMC_BUS_WIDTH_4:
794tmp |= CMD_SET_DATW_4;
795break;
796case MMC_BUS_WIDTH_8:
797tmp |= CMD_SET_DATW_8;
798break;
799default:
800dev_err(host-pd-dev, Unsupported
bus width.\n);
801break;
802}
803switch (host-timing) {
804case MMC_TIMING_UHS_DDR50:
805/*
806 * MMC core will only set this timing,
if the host
807 * advertises the MMC_CAP_UHS_DDR50
capability. MMCIF
808 * implementations with this
capability, e.g. sh73a0,
809 * will have to set it in their
platform data.
810 */
811tmp |= CMD_SET_DARS;
812break;
813}
814}
815/* DWEN */
816if (opc == MMC_WRITE_BLOCK || opc ==
MMC_WRITE_MULTIPLE_BLOCK)
817tmp |= CMD_SET_DWEN;
818/* CMLTE/CMD12EN */
819if (opc == MMC_READ_MULTIPLE_BLOCK || opc ==
MMC_WRITE_MULTIPLE_BLOCK) {
820tmp |= CMD_SET_CMLTE | CMD_SET_CMD12EN;
821sh_mmcif_bitset(host, MMCIF_CE_BLOCK_SET,
822data-blocks 16);
Dereference.
We used to assume that host-data might be NULL but that mrq-data was
a valid pointer. But now they are unified into one pointer.
Yes, formally this isn't correct, but in practice this is valid, because
for those two opcodes, handled in this if data cannot be NULL.
Thanks
Guennadi
823}
824/* RIDXC[1:0] check bits */
regards,
dan carpenter
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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] mmc: tmio: remove myself as a maintainer
Since I'm currently unable to dedicate sufficient time to driver maintainership, remove myself from the maintainers list. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- MAINTAINERS |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index b5f4e68..e37e8c0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8643,7 +8643,6 @@ F:include/linux/toshiba.h F: include/uapi/linux/toshiba.h TMIO MMC DRIVER -M: Guennadi Liakhovetski g.liakhovet...@gmx.de M: Ian Molton i...@mnementh.co.uk L: linux-mmc@vger.kernel.org S: Maintained -- 1.7.2.5 -- 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 0/3] mmc: tmio: Use modern PM ops
Hi Ulf, A general question concerning this your effort just occurred to me: what if runtime PM is disabled on a system? Will the clock(s) then at all be enabled? Doesn't one need for such a case either a fall-back to statically enable clock in .probe() and disable in .remove() or should such drivers select PM_RUNTIME? Thanks Guennadi On Tue, 5 Nov 2013, Ulf Hansson wrote: This patchset converts tmio and sh_mobile_sdhi to use the modern PM ops. Ulf Hansson (3): mmc: sh_mobile_sdhi: Use modern PM macros to define pm callbacks mmc: tmio_mmc: Convert from legacy to modern PM ops mmc: tmio: Adapt to proper PM configs for exported functions drivers/mmc/host/sh_mobile_sdhi.c |8 drivers/mmc/host/tmio_mmc.c | 32 ++-- drivers/mmc/host/tmio_mmc.h |7 +++ drivers/mmc/host/tmio_mmc_pio.c |7 --- 4 files changed, 29 insertions(+), 25 deletions(-) -- 1.7.9.5 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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/8] mmc: tmio: Keep host active while SDIO irq is enabled
Hi Ulf,
On Fri, 8 Nov 2013, Ulf Hansson wrote:
The host must be kept active to be able to serve with SDIO irqs. We
prevent it from being put into in-active while the SDIO irq is enabled
by simply adding balanced calls to pm_runtime_get|put.
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/mmc/host/tmio_mmc.h |1 +
drivers/mmc/host/tmio_mmc_pio.c | 19 +++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 6c5b45a..c2c9546 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -102,6 +102,7 @@ struct tmio_mmc_host {
struct mutexios_lock; /* protect set_ios() context */
boolnative_hotplug;
boolresuming;
+ boolsdio_irq_enabled;
};
int tmio_mmc_host_probe(struct tmio_mmc_host **host,
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 472e803..377157e 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -129,15 +129,22 @@ static void tmio_mmc_enable_sdio_irq(struct mmc_host
*mmc, int enable)
{
struct tmio_mmc_host *host = mmc_priv(mmc);
- if (enable) {
+ if (enable !host-sdio_irq_enabled) {
+ /* Keep device active while SDIO irq is enabled */
+ pm_runtime_get_sync(mmc_dev(mmc));
+ host-sdio_irq_enabled = true;
+
host-sdio_irq_mask = TMIO_SDIO_MASK_ALL
~TMIO_SDIO_STAT_IOIRQ;
sd_ctrl_write16(host, CTL_TRANSACTION_CTL, 0x0001);
sd_ctrl_write16(host, CTL_SDIO_IRQ_MASK, host-sdio_irq_mask);
- } else {
+ } else if (!enable host-sdio_irq_enabled) {
host-sdio_irq_mask = TMIO_SDIO_MASK_ALL;
sd_ctrl_write16(host, CTL_SDIO_IRQ_MASK, host-sdio_irq_mask);
sd_ctrl_write16(host, CTL_TRANSACTION_CTL, 0x);
+
+ host-sdio_irq_enabled = false;
+ pm_runtime_put(mmc_dev(mmc));
}
}
@@ -1072,8 +1079,12 @@ int tmio_mmc_host_probe(struct tmio_mmc_host **host,
_host-sdcard_irq_mask = ~irq_mask;
- if (pdata-flags TMIO_MMC_SDIO_IRQ)
- tmio_mmc_enable_sdio_irq(mmc, 0);
+ _host-sdio_irq_enabled = false;
This by itself is unneeded as the data is allocated per kzalloc(). It can
be argued, that such explicit assignments make code better readable, but
we also don't initialise other boolean variables in struct tmio_mmc_host
during probe(): force_pio and resuming, so, to stay consistent it could be
better to preserve that pattern.
+ if (pdata-flags TMIO_MMC_SDIO_IRQ) {
+ _host-sdio_irq_mask = TMIO_SDIO_MASK_ALL;
+ sd_ctrl_write16(_host, CTL_SDIO_IRQ_MASK, _host-sdio_irq_mask);
+ sd_ctrl_write16(_host, CTL_TRANSACTION_CTL, 0x);
+ }
I don't think I like this open-coding a lot. I think, in
tmio_mmc_enable_sdio_irq() above it would be better to only balance calls
to pm_runtime_enable/disable() by checking and setting the
.sdio_irq_enabled flag. Then we wouldn't have to modify this location.
Thanks
Guennadi
spin_lock_init(_host-lock);
mutex_init(_host-ios_lock);
--
1.7.9.5
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 v2 2/3] mmc: tmio_mmc: Convert from legacy to modern PM ops
On Wed, 6 Nov 2013, Ulf Hansson wrote:
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Thanks
Guennadi
---
Changes in v2:
Adopted to review comments from Guennadi Liakhovetski.
---
drivers/mmc/host/tmio_mmc.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index 8860d4d..42da904 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -23,38 +23,37 @@
#include tmio_mmc.h
-#ifdef CONFIG_PM
-static int tmio_mmc_suspend(struct platform_device *dev, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int tmio_mmc_suspend(struct device *dev)
{
- const struct mfd_cell *cell = mfd_get_cell(dev);
+ struct platform_device *pdev = to_platform_device(dev);
+ const struct mfd_cell *cell = mfd_get_cell(pdev);
int ret;
- ret = tmio_mmc_host_suspend(dev-dev);
+ ret = tmio_mmc_host_suspend(dev);
/* Tell MFD core it can disable us now.*/
if (!ret cell-disable)
- cell-disable(dev);
+ cell-disable(pdev);
return ret;
}
-static int tmio_mmc_resume(struct platform_device *dev)
+static int tmio_mmc_resume(struct device *dev)
{
- const struct mfd_cell *cell = mfd_get_cell(dev);
+ struct platform_device *pdev = to_platform_device(dev);
+ const struct mfd_cell *cell = mfd_get_cell(pdev);
int ret = 0;
/* Tell the MFD core we are ready to be enabled */
if (cell-resume)
- ret = cell-resume(dev);
+ ret = cell-resume(pdev);
if (!ret)
- ret = tmio_mmc_host_resume(dev-dev);
+ ret = tmio_mmc_host_resume(dev);
return ret;
}
-#else
-#define tmio_mmc_suspend NULL
-#define tmio_mmc_resume NULL
#endif
static int tmio_mmc_probe(struct platform_device *pdev)
@@ -125,15 +124,18 @@ static int tmio_mmc_remove(struct platform_device *pdev)
/* --- device registration --- */
+static const struct dev_pm_ops tmio_mmc_dev_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(tmio_mmc_suspend, tmio_mmc_resume)
+};
+
static struct platform_driver tmio_mmc_driver = {
.driver = {
.name = tmio-mmc,
.owner = THIS_MODULE,
+ .pm = tmio_mmc_dev_pm_ops,
},
.probe = tmio_mmc_probe,
.remove = tmio_mmc_remove,
- .suspend = tmio_mmc_suspend,
- .resume = tmio_mmc_resume,
};
module_platform_driver(tmio_mmc_driver);
--
1.7.9.5
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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/3] mmc: tmio_mmc: Convert from legacy to modern PM ops
Hi Ulf,
The patch looks good to me in general, just one possible optimisation:
On Tue, 5 Nov 2013, Ulf Hansson wrote:
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/mmc/host/tmio_mmc.c | 32 ++--
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index 8860d4d..a56a3fe 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -23,38 +23,39 @@
#include tmio_mmc.h
-#ifdef CONFIG_PM
-static int tmio_mmc_suspend(struct platform_device *dev, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int tmio_mmc_suspend(struct device *dev)
{
- const struct mfd_cell *cell = mfd_get_cell(dev);
+ struct mmc_host *mmc = dev_get_drvdata(dev);
+ struct tmio_mmc_host *host = mmc_priv(mmc);
+ const struct mfd_cell *cell = mfd_get_cell(host-pdev);
Wouldn't it be better to just add
+ struct platform_device *pdev = to_platform_device(dev);
which would also simplify
int ret;
- ret = tmio_mmc_host_suspend(dev-dev);
+ ret = tmio_mmc_host_suspend(dev);
/* Tell MFD core it can disable us now.*/
if (!ret cell-disable)
- cell-disable(dev);
+ cell-disable(host-pdev);
the above line to just
+ cell-disable(pdev);
return ret;
}
-static int tmio_mmc_resume(struct platform_device *dev)
+static int tmio_mmc_resume(struct device *dev)
{
- const struct mfd_cell *cell = mfd_get_cell(dev);
+ struct mmc_host *mmc = dev_get_drvdata(dev);
+ struct tmio_mmc_host *host = mmc_priv(mmc);
+ const struct mfd_cell *cell = mfd_get_cell(host-pdev);
int ret = 0;
/* Tell the MFD core we are ready to be enabled */
if (cell-resume)
- ret = cell-resume(dev);
+ ret = cell-resume(host-pdev);
Ditto in this function.
Thanks
Guennadi
if (!ret)
- ret = tmio_mmc_host_resume(dev-dev);
+ ret = tmio_mmc_host_resume(dev);
return ret;
}
-#else
-#define tmio_mmc_suspend NULL
-#define tmio_mmc_resume NULL
#endif
static int tmio_mmc_probe(struct platform_device *pdev)
@@ -125,15 +126,18 @@ static int tmio_mmc_remove(struct platform_device *pdev)
/* --- device registration --- */
+static const struct dev_pm_ops tmio_mmc_dev_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(tmio_mmc_suspend, tmio_mmc_resume)
+};
+
static struct platform_driver tmio_mmc_driver = {
.driver = {
.name = tmio-mmc,
.owner = THIS_MODULE,
+ .pm = tmio_mmc_dev_pm_ops,
},
.probe = tmio_mmc_probe,
.remove = tmio_mmc_remove,
- .suspend = tmio_mmc_suspend,
- .resume = tmio_mmc_resume,
};
module_platform_driver(tmio_mmc_driver);
--
1.7.9.5
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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/3] mmc: sh_mobile_sdhi: Use modern PM macros to define pm callbacks
On Tue, 5 Nov 2013, Ulf Hansson wrote:
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Thanks
Guennadi
---
drivers/mmc/host/sh_mobile_sdhi.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_mobile_sdhi.c
index 87ed3fb..2227a9f 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -297,10 +297,10 @@ static int sh_mobile_sdhi_remove(struct platform_device
*pdev)
}
static const struct dev_pm_ops tmio_mmc_dev_pm_ops = {
- .suspend = tmio_mmc_host_suspend,
- .resume = tmio_mmc_host_resume,
- .runtime_suspend = tmio_mmc_host_runtime_suspend,
- .runtime_resume = tmio_mmc_host_runtime_resume,
+ SET_SYSTEM_SLEEP_PM_OPS(tmio_mmc_host_suspend, tmio_mmc_host_resume)
+ SET_RUNTIME_PM_OPS(tmio_mmc_host_runtime_suspend,
+ tmio_mmc_host_runtime_resume,
+ NULL)
};
static struct platform_driver sh_mobile_sdhi_driver = {
--
1.7.9.5
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 3/3] mmc: tmio: Adapt to proper PM configs for exported functions
On Tue, 5 Nov 2013, Ulf Hansson wrote:
Since the users of the exported PM functions are now using the modern
PM ops macros, we can convert to the proper corresponding PM configs.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Thanks
Guennadi
---
drivers/mmc/host/tmio_mmc.h |7 +++
drivers/mmc/host/tmio_mmc_pio.c |7 ---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 86fd21e..6c5b45a 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -163,16 +163,15 @@ static inline void tmio_mmc_abort_dma(struct
tmio_mmc_host *host)
}
#endif
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
int tmio_mmc_host_suspend(struct device *dev);
int tmio_mmc_host_resume(struct device *dev);
-#else
-#define tmio_mmc_host_suspend NULL
-#define tmio_mmc_host_resume NULL
#endif
+#ifdef CONFIG_PM_RUNTIME
int tmio_mmc_host_runtime_suspend(struct device *dev);
int tmio_mmc_host_runtime_resume(struct device *dev);
+#endif
static inline u16 sd_ctrl_read16(struct tmio_mmc_host *host, int addr)
{
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index f3b2d8c..472e803 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -1140,7 +1140,7 @@ void tmio_mmc_host_remove(struct tmio_mmc_host *host)
}
EXPORT_SYMBOL(tmio_mmc_host_remove);
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
int tmio_mmc_host_suspend(struct device *dev)
{
struct mmc_host *mmc = dev_get_drvdata(dev);
@@ -1163,9 +1163,9 @@ int tmio_mmc_host_resume(struct device *dev)
return 0;
}
EXPORT_SYMBOL(tmio_mmc_host_resume);
+#endif
-#endif /* CONFIG_PM */
-
+#ifdef CONFIG_PM_RUNTIME
int tmio_mmc_host_runtime_suspend(struct device *dev)
{
return 0;
@@ -1182,5 +1182,6 @@ int tmio_mmc_host_runtime_resume(struct device *dev)
return 0;
}
EXPORT_SYMBOL(tmio_mmc_host_runtime_resume);
+#endif
MODULE_LICENSE(GPL v2);
--
1.7.9.5
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 v2 2/7] mmc: sh_mmcif: Convert to PM macros when defining dev_pm_ops
Hi Ulf
On Tue, 22 Oct 2013, Ulf Hansson wrote:
Use SET_SYSTEM_SLEEP_PM_OPS to simplify code.
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/mmc/host/sh_mmcif.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 6bffebe..32bc412 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -1538,7 +1538,7 @@ static int sh_mmcif_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int sh_mmcif_suspend(struct device *dev)
{
struct sh_mmcif_host *host = dev_get_drvdata(dev);
@@ -1552,10 +1552,7 @@ static int sh_mmcif_resume(struct device *dev)
{
return 0;
}
-#else
-#define sh_mmcif_suspend NULL
-#define sh_mmcif_resume NULL
-#endif /* CONFIG_PM */
+#endif
static const struct of_device_id mmcif_of_match[] = {
{ .compatible = renesas,sh-mmcif },
@@ -1564,8 +1561,7 @@ static const struct of_device_id mmcif_of_match[] = {
MODULE_DEVICE_TABLE(of, mmcif_of_match);
static const struct dev_pm_ops sh_mmcif_dev_pm_ops = {
- .suspend = sh_mmcif_suspend,
- .resume = sh_mmcif_resume,
+ SET_SYSTEM_SLEEP_PM_OPS(sh_mmcif_suspend, sh_mmcif_resume)
};
You could then even use SIMPLE_DEV_PM_OPS().
Thanks
Guennadi
static struct platform_driver sh_mmcif_driver = {
--
1.7.9.5
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 v2 3/7] mmc: sh_mmcif: Convert to clk_prepare|unprepare
On Tue, 22 Oct 2013, Ulf Hansson wrote:
Previously only clk_enable|disable were being used. Adapt properly
to the clock API, by also using clk_prepare|unprepare.
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Note, that Laurent has later submitted a (simingly) identical patch, but
since yours was the first one, we should use this one really.
Thanks
Guennadi
---
drivers/mmc/host/sh_mmcif.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 32bc412..d032b08 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -964,7 +964,7 @@ static void sh_mmcif_request(struct mmc_host *mmc, struct
mmc_request *mrq)
static int sh_mmcif_clk_update(struct sh_mmcif_host *host)
{
- int ret = clk_enable(host-hclk);
+ int ret = clk_prepare_enable(host-hclk);
if (!ret) {
host-clk = clk_get_rate(host-hclk);
@@ -1018,7 +1018,7 @@ static void sh_mmcif_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
}
if (host-power) {
pm_runtime_put_sync(host-pd-dev);
- clk_disable(host-hclk);
+ clk_disable_unprepare(host-hclk);
host-power = false;
if (ios-power_mode == MMC_POWER_OFF)
sh_mmcif_set_power(host, ios);
@@ -1466,7 +1466,7 @@ static int sh_mmcif_probe(struct platform_device *pdev)
mutex_init(host-thread_lock);
- clk_disable(host-hclk);
+ clk_disable_unprepare(host-hclk);
ret = mmc_add_host(mmc);
if (ret 0)
goto emmcaddh;
@@ -1487,7 +1487,7 @@ ereqirq1:
ereqirq0:
pm_runtime_suspend(pdev-dev);
eresume:
- clk_disable(host-hclk);
+ clk_disable_unprepare(host-hclk);
eclkupdate:
clk_put(host-hclk);
eclkget:
@@ -1505,7 +1505,7 @@ static int sh_mmcif_remove(struct platform_device *pdev)
int irq[2];
host-dying = true;
- clk_enable(host-hclk);
+ clk_prepare_enable(host-hclk);
pm_runtime_get_sync(pdev-dev);
dev_pm_qos_hide_latency_limit(pdev-dev);
@@ -1530,7 +1530,7 @@ static int sh_mmcif_remove(struct platform_device *pdev)
if (irq[1] = 0)
free_irq(irq[1], host);
- clk_disable(host-hclk);
+ clk_disable_unprepare(host-hclk);
mmc_free_host(host-mmc);
pm_runtime_put_sync(pdev-dev);
pm_runtime_disable(pdev-dev);
--
1.7.9.5
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 07/12] mmc: sh_mmcif: Convert to clk_prepare/unprepare
On Tue, 29 Oct 2013, Guennadi Liakhovetski wrote:
On Mon, 28 Oct 2013, Laurent Pinchart wrote:
Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and
clk_disable_unprepare() to get ready for the migration to the common
clock framework.
Cc: Chris Ball c...@laptop.org
Cc: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
Cc: linux-mmc@vger.kernel.org
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Sorry, I just realised, that an identical patch
http://patches.linaro.org/21212/
has been submitted prior to this one, so, we should really take the other
one.
Thanks
Guennadi
---
drivers/mmc/host/sh_mmcif.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 36629a0..37a6c57 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -964,7 +964,7 @@ static void sh_mmcif_request(struct mmc_host *mmc,
struct mmc_request *mrq)
static int sh_mmcif_clk_update(struct sh_mmcif_host *host)
{
- int ret = clk_enable(host-hclk);
+ int ret = clk_prepare_enable(host-hclk);
if (!ret) {
host-clk = clk_get_rate(host-hclk);
@@ -1018,7 +1018,7 @@ static void sh_mmcif_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
}
if (host-power) {
pm_runtime_put_sync(host-pd-dev);
- clk_disable(host-hclk);
+ clk_disable_unprepare(host-hclk);
host-power = false;
if (ios-power_mode == MMC_POWER_OFF)
sh_mmcif_set_power(host, ios);
@@ -1466,7 +1466,7 @@ static int sh_mmcif_probe(struct platform_device
*pdev)
mutex_init(host-thread_lock);
- clk_disable(host-hclk);
+ clk_disable_unprepare(host-hclk);
ret = mmc_add_host(mmc);
if (ret 0)
goto emmcaddh;
@@ -1487,7 +1487,7 @@ ereqirq1:
ereqirq0:
pm_runtime_suspend(pdev-dev);
eresume:
- clk_disable(host-hclk);
+ clk_disable_unprepare(host-hclk);
eclkupdate:
clk_put(host-hclk);
eclkget:
@@ -1505,7 +1505,7 @@ static int sh_mmcif_remove(struct platform_device
*pdev)
int irq[2];
host-dying = true;
- clk_enable(host-hclk);
+ clk_prepare_enable(host-hclk);
pm_runtime_get_sync(pdev-dev);
dev_pm_qos_hide_latency_limit(pdev-dev);
@@ -1530,7 +1530,7 @@ static int sh_mmcif_remove(struct platform_device
*pdev)
if (irq[1] = 0)
free_irq(irq[1], host);
- clk_disable(host-hclk);
+ clk_disable_unprepare(host-hclk);
mmc_free_host(host-mmc);
pm_runtime_put_sync(pdev-dev);
pm_runtime_disable(pdev-dev);
--
1.8.1.5
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 v2 0/7] mmc: sh_mmcif: Convert to use runtime PM at request idle
Hi Ulf On Tue, 29 Oct 2013, Ulf Hansson wrote: On 22 October 2013 16:07, Ulf Hansson ulf.hans...@linaro.org wrote: In a step in removing CONFIG_MMC_CLKGATE, host drivers can implement same functionality through runtime PM. This patchset is converting the sh_mmcif accordingly. On the way, it was reasonable to include some minor cleanups to simplify code. The first patch has beend sent through an another patchset recently, but since it touches related code to this patchset, I decided to fold it in here as well. An important note, this patchset has only been compile tested. I hope someone can help out with proper testing. Changes in v2: - Adapted mmc: sh_mmcif: Move clock handling into runtime PM callbacks patch to maintain behavior of handling clk_get_rate. - Rebased patches on top of the above change. Ulf Hansson (7): mmc: sh_mmcif: Move away from using deprecated APIs mmc: sh_mmcif: Convert to PM macros when defining dev_pm_ops mmc: sh_mmcif: Convert to clk_prepare|unprepare mmc: sh_mmcif: Use runtime PM to keep resourses active during I/O mmc: sh_mmcif: Move clock handling into runtime PM callbacks mmc: sh_mmcif: Simplify clock and power setup in set_ios mmc: sh_mmcif: Extend clock gating routine for runtime suspend drivers/mmc/host/sh_mmcif.c | 138 --- 1 file changed, 76 insertions(+), 62 deletions(-) -- 1.7.9.5 Hi Guennadi. Just wanted to send you a kind ping on this. I would very much appreciate any further comments from you. Sorry for a delay. I didn't reply, because I actually don't have much to say concerning the main topic of the series - the PM conversion. Patch 1/7 is already upstream, I acked patches 2 and 3, that's about as much as I can do, sorry. Beginning with patch 4 things get complicated. And even though I did confirm, that your approach could be implemented to replace MMC aggressive clock gating, I don't think I'm able to verify correctness of those your patches by just looking at them. They really seem to change the behaviour a lot to me, and as such I personally cannot follow all the possibilities on all supported platforms in my head. I think this change, if really desired, should be done by someone with access to all or at least a few of affected SoC versions with different configurations - hot-pluggable cards, eMMC, system suspend / resume, PM domains, DMA and PIO, etc. I'm pretty sure I could begin asking questiong to your patch(es) like what if here this happens, or how will that be handled, but that would be a waste of time for both of us IMHO. I'm not maintaining the driver, so, a maintainer can just decide to pick up your patches and see if anything breaks, or they can be dropped until someone does the tests. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 08/12] mmc: sh_mobile_sdhi: Convert to clk_prepare/unprepare
On Mon, 28 Oct 2013, Laurent Pinchart wrote: Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and clk_disable_unprepare() to get ready for the migration to the common clock framework. Cc: Chris Ball c...@laptop.org Cc: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com Cc: linux-mmc@vger.kernel.org Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Thanks Guennadi --- drivers/mmc/host/sh_mobile_sdhi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c index f344659..ed1718a 100644 --- a/drivers/mmc/host/sh_mobile_sdhi.c +++ b/drivers/mmc/host/sh_mobile_sdhi.c @@ -54,7 +54,7 @@ static int sh_mobile_sdhi_clk_enable(struct platform_device *pdev, unsigned int struct mmc_host *mmc = platform_get_drvdata(pdev); struct tmio_mmc_host *host = mmc_priv(mmc); struct sh_mobile_sdhi *priv = container_of(host-pdata, struct sh_mobile_sdhi, mmc_data); - int ret = clk_enable(priv-clk); + int ret = clk_prepare_enable(priv-clk); if (ret 0) return ret; @@ -67,7 +67,7 @@ static void sh_mobile_sdhi_clk_disable(struct platform_device *pdev) struct mmc_host *mmc = platform_get_drvdata(pdev); struct tmio_mmc_host *host = mmc_priv(mmc); struct sh_mobile_sdhi *priv = container_of(host-pdata, struct sh_mobile_sdhi, mmc_data); - clk_disable(priv-clk); + clk_disable_unprepare(priv-clk); } static int sh_mobile_sdhi_wait_idle(struct tmio_mmc_host *host) -- 1.8.1.5 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 07/12] mmc: sh_mmcif: Convert to clk_prepare/unprepare
On Mon, 28 Oct 2013, Laurent Pinchart wrote:
Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and
clk_disable_unprepare() to get ready for the migration to the common
clock framework.
Cc: Chris Ball c...@laptop.org
Cc: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
Cc: linux-mmc@vger.kernel.org
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Thanks
Guennadi
---
drivers/mmc/host/sh_mmcif.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 36629a0..37a6c57 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -964,7 +964,7 @@ static void sh_mmcif_request(struct mmc_host *mmc, struct
mmc_request *mrq)
static int sh_mmcif_clk_update(struct sh_mmcif_host *host)
{
- int ret = clk_enable(host-hclk);
+ int ret = clk_prepare_enable(host-hclk);
if (!ret) {
host-clk = clk_get_rate(host-hclk);
@@ -1018,7 +1018,7 @@ static void sh_mmcif_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
}
if (host-power) {
pm_runtime_put_sync(host-pd-dev);
- clk_disable(host-hclk);
+ clk_disable_unprepare(host-hclk);
host-power = false;
if (ios-power_mode == MMC_POWER_OFF)
sh_mmcif_set_power(host, ios);
@@ -1466,7 +1466,7 @@ static int sh_mmcif_probe(struct platform_device *pdev)
mutex_init(host-thread_lock);
- clk_disable(host-hclk);
+ clk_disable_unprepare(host-hclk);
ret = mmc_add_host(mmc);
if (ret 0)
goto emmcaddh;
@@ -1487,7 +1487,7 @@ ereqirq1:
ereqirq0:
pm_runtime_suspend(pdev-dev);
eresume:
- clk_disable(host-hclk);
+ clk_disable_unprepare(host-hclk);
eclkupdate:
clk_put(host-hclk);
eclkget:
@@ -1505,7 +1505,7 @@ static int sh_mmcif_remove(struct platform_device *pdev)
int irq[2];
host-dying = true;
- clk_enable(host-hclk);
+ clk_prepare_enable(host-hclk);
pm_runtime_get_sync(pdev-dev);
dev_pm_qos_hide_latency_limit(pdev-dev);
@@ -1530,7 +1530,7 @@ static int sh_mmcif_remove(struct platform_device *pdev)
if (irq[1] = 0)
free_irq(irq[1], host);
- clk_disable(host-hclk);
+ clk_disable_unprepare(host-hclk);
mmc_free_host(host-mmc);
pm_runtime_put_sync(pdev-dev);
pm_runtime_disable(pdev-dev);
--
1.8.1.5
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 08/19] mmc: sdhi: Enable the driver on all ARM platforms
Hi Laurent On Tue, 29 Oct 2013, Laurent Pinchart wrote: Renesas ARM platforms are transitioning from single-platform to multi-platform kernels using the new ARCH_SHMOBILE_MULTI. Make the driver available on all ARM platforms to enable it on both ARCH_SHMOBILE and ARCH_SHMOBILE_MULTI and increase build testing coverage. Cc: Chris Ball c...@laptop.org Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Ian Molton i...@mnementh.co.uk Cc: linux-mmc@vger.kernel.org Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com --- drivers/mmc/host/Kconfig| 2 +- drivers/mmc/host/tmio_mmc_dma.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index 7fc5099..51957d4 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -479,7 +479,7 @@ config MMC_TMIO config MMC_SDHI tristate SH-Mobile SDHI SD/SDIO controller support - depends on SUPERH || ARCH_SHMOBILE + depends on SUPERH || ARM select MMC_TMIO_CORE help This provides support for the SDHI SD/SDIO controller found in diff --git a/drivers/mmc/host/tmio_mmc_dma.c b/drivers/mmc/host/tmio_mmc_dma.c index 65edb4a..535bc35 100644 --- a/drivers/mmc/host/tmio_mmc_dma.c +++ b/drivers/mmc/host/tmio_mmc_dma.c @@ -28,7 +28,7 @@ void tmio_mmc_enable_dma(struct tmio_mmc_host *host, bool enable) if (!host-chan_tx || !host-chan_rx) return; -#if defined(CONFIG_SUPERH) || defined(CONFIG_ARCH_SHMOBILE) +#if defined(CONFIG_SUPERH) || defined(CONFIG_ARM) I'm not sure about this one. In principle DMA so far is only used on SDHI with TMIO. But this #if was for a theoretical case, when a TMIO MMC IP inside an MFD is also used with DMA. Bus since I had no indormation about whether the CTL_DMA_ENABLE register was SDHI specific or not, I put it under an #if for the time being. In any case, I don't think making it #ifdef CONFIG_ARM makes much sense. We can either remove the #if completely, or keep it to limit the scope of this write to sh-mobile arches. Thanks Guennadi /* Switch DMA mode on or off - SuperH specific? */ sd_ctrl_write16(host, CTL_DMA_ENABLE, enable ? 2 : 0); #endif -- 1.8.1.5 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 5/7] mmc: sd_mmcif: Move clock handling into runtime PM callbacks
On Wed, 2 Oct 2013, Ulf Hansson wrote:
Implement callbacks for runtime suspend|resume and leave the clock
to be handled from there.
The .set_ios function is still capable of using the interal registers
to gate the clock when the frequency is zero, but the operations needed
towards the clk API is now handled from the runtime callbacks.
From now on, CONFIG_PM_RUNTIME is required handle power save with full
clock gating at request inactivity.
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/mmc/host/sh_mmcif.c | 47
++-
1 file changed, 29 insertions(+), 18 deletions(-)
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index f4532dc..e234856 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -964,19 +964,6 @@ static void sh_mmcif_request(struct mmc_host *mmc,
struct mmc_request *mrq)
sh_mmcif_start_cmd(host, mrq);
}
-static int sh_mmcif_clk_update(struct sh_mmcif_host *host)
-{
- int ret = clk_prepare_enable(host-hclk);
-
- if (!ret) {
- host-clk = clk_get_rate(host-hclk);
- host-mmc-f_max = host-clk / 2;
- host-mmc-f_min = host-clk / 512;
- }
-
- return ret;
-}
-
This reverts effect of this commit:
commit a6609267107ecc5598b79aa353036c1f57e7257e
Author: Guennadi Liakhovetski g.liakhovet...@gmx.de
Date: Thu Apr 19 18:02:50 2012 +0200
mmc: sh_mmcif: re-read the clock frequency every time it is turned on
Thanks
Guennadi
static void sh_mmcif_set_power(struct sh_mmcif_host *host, struct mmc_ios
*ios)
{
struct mmc_host *mmc = host-mmc;
@@ -1021,7 +1008,6 @@ static void sh_mmcif_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
}
}
if (host-power) {
- clk_disable_unprepare(host-hclk);
host-power = false;
if (ios-power_mode == MMC_POWER_OFF)
sh_mmcif_set_power(host, ios);
@@ -1032,7 +1018,6 @@ static void sh_mmcif_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
if (ios-clock) {
if (!host-power) {
- sh_mmcif_clk_update(host);
host-power = true;
sh_mmcif_sync_reset(host);
}
@@ -1440,9 +1425,16 @@ static int sh_mmcif_probe(struct platform_device *pdev)
dev_err(pdev-dev, cannot get clock: %d\n, ret);
goto eofparse;
}
- ret = sh_mmcif_clk_update(host);
- if (ret 0)
+
+ ret = clk_prepare_enable(host-hclk);
+ if (ret) {
+ dev_err(pdev-dev, cannot enable clock: %d\n, ret);
goto eclkupdate;
+ }
+
+ host-clk = clk_get_rate(host-hclk);
+ host-mmc-f_max = host-clk / 2;
+ host-mmc-f_min = host-clk / 512;
INIT_DELAYED_WORK(host-timeout_work, mmcif_timeout_work);
@@ -1478,7 +1470,6 @@ static int sh_mmcif_probe(struct platform_device *pdev)
pm_runtime_set_active(pdev-dev);
pm_runtime_enable(pdev-dev);
- clk_disable_unprepare(host-hclk);
ret = mmc_add_host(mmc);
if (ret 0)
goto emmcaddh;
@@ -1568,6 +1559,24 @@ static int sh_mmcif_resume(struct device *dev)
}
#endif
+#ifdef CONFIG_PM_RUNTIME
+static int sh_mmcif_runtime_suspend(struct device *dev)
+{
+ struct sh_mmcif_host *host = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(host-hclk);
+ return 0;
+}
+
+static int sh_mmcif_runtime_resume(struct device *dev)
+{
+ struct sh_mmcif_host *host = dev_get_drvdata(dev);
+
+ clk_prepare_enable(host-hclk);
+ return 0;
+}
+#endif
+
static const struct of_device_id mmcif_of_match[] = {
{ .compatible = renesas,sh-mmcif },
{ }
@@ -1576,6 +1585,8 @@ MODULE_DEVICE_TABLE(of, mmcif_of_match);
static const struct dev_pm_ops sh_mmcif_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(sh_mmcif_suspend, sh_mmcif_resume)
+ SET_RUNTIME_PM_OPS(sh_mmcif_runtime_suspend, sh_mmcif_runtime_resume,
+NULL)
};
static struct platform_driver sh_mmcif_driver = {
--
1.7.9.5
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 0/2] mmc: core: Remove all code related to MMC_CLKGATE
such an autosuspend. And TMIO_MMC_OFF_STOP we would be entering upon an explicit call to .set_ios() with ios-power_mode == MMC_POWER_OFF. We would also have to take care not to use autosuspend for SDIO cards similarly to how the clock gating is currently disabled for them. If that's what you mean and if indeed we're sure, that there are no clock-on requirements during long inactivity periods for memory cards, then yes, I think just combining MMC_POWER_OFF and runtime PM autosuspend could provide the same level of flexibility, that the clock gating is currently providing. And even if there are such periods, protocol drivers can always increment the card's runtime PM use-count by calling mmc_get_card(). So, at the very least, I think, we should prevent SD host controllers from autosuspending, if an SDIO card is in the slot. Does your patch [PATCH 2/2] mmc: core: Remove MMC_CLKGATE do that or do you think each SD host controller driver should do that by itself? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 0/2] mmc: core: Remove all code related to MMC_CLKGATE
Hi Ulf,
Let me try to add a bit more to your explanations below.
On Tue, 1 Oct 2013, Guennadi Liakhovetski wrote:
Hi Ulf
On Tue, 1 Oct 2013, Ulf Hansson wrote:
On 30 September 2013 23:10, Guennadi Liakhovetski g.liakhovet...@gmx.de
wrote:
Hi Ulf
On Mon, 30 Sep 2013, Ulf Hansson wrote:
This patchset is remove all code related to MMC_CLKGATE. A significant
portion of code can then be removed from the core layer which would
simplify maintainance.
At the moment it seems like only some MIPS platforms were using
MMC_CLKGATE, but at the same time the corresponding host drivers
were not taking advantage of the mechanism. This made me feel confident
in removing the feature entirely from the mmc subsystem could be done.
Also do note that for host drivers that would like to implement clock
gating as a power save operation, using runtime PM is a far easier
way to address this. Several host drivers is already fully supporting
this as well.
Ulf Hansson (2):
MIPS: db1235: Don't use MMC_CLKGATE
mmc: core: Remove MMC_CLKGATE
Do I understand correctly, that you're proposing to remove the aggressive
clock gating feature from MMC? If so, then please take into account my
NAK. At least two SD / MMC drivers, that I'm aware of, actively used and
developed on multiple platforms - sh_mmcif and tmio / sdhi implement MMC
clock gating and rely on it to save power between IO.
Guennadi, thanks for your NAK, you have understood correctly what my
intention is. :-)
Looking into your two examples, sh_mmcif and sh_mobile_sdhci (using
tmio), I realize that they use runtime PM in an awkward way.
I'm not sure what exactly you find awkward there. I know that a lot of
work has been invested in runtime PM and clock gating on those two
drivers, and the results were rather good: we were able to runtime suspend
and wake up controllers according to .power_mode as provided to drivers'
.set_ios() methods. We were able to use power domains and show, that even
when the whole domain is powered up and down as a result of our runtime
PM, we still can communicate with MMC, SD, and SDIO cards in slots. We
added support for regulators. We also added support for aggressive MMC
clock gating, which allowed us to save power by gating the clock _when_ it
was safe, as decided by higher level protocols.
E.g. look at this comment in tmio_mmc_pio.c:
/*
* We differentiate between the following 3 power states:
* 1. card slot powered off, controller stopped. This is used, when either there
*is no card in the slot, or the card really has to be powered down.
* 2. card slot powered on, controller stopped. This is used, when a card is in
*the slot, but no activity is currently taking place. This is a power-
*saving mode with card-state preserved. This state can be entered, e.g.
*when MMC clock-gating is used.
* 3. card slot powered on, controller running. This is the actual active state.
*/
enum tmio_mmc_power {
TMIO_MMC_OFF_STOP, /* card power off, controller stopped */
TMIO_MMC_ON_STOP, /* card power on, controller stopped */
TMIO_MMC_ON_RUN,/* card power on, controller running */
};
Now, if you remove clock gating, would you still be able to really support
all these modes? IIUC, the clock gating is there for higher level MMC/SD
protocols (MMC, SD, SDHC, SDXC, SDIO,...) to inform the mmc core and
controller drivers, that according to that protocol the clock can be
switched off now. It seems to me, that you're just completely removing
that functionality. Neither the mmc core nor low level controller drivers
can know when the clock can be switched off. So, I don't see how runtime
PM by itself can solve the problem. You can choose a different approach to
signal idle / power-saving states from protocol drivers, but you anyway
need to actually do that. In your patch mmc: core: Remove MMC_CLKGATE
however, you just remove those calls from sd.c and mmc.c, so, I don't see
how that functionality can be implemented after your proposed patches.
Thanks
Guennadi
I would
suggest to move parts of the clock gating from .set_ios to runtime PM
callbacks instead. Obviously proper calls to pm_runtime_get|put needs
to be adopted as well. pm_runtime_get|put should be used to make sure
your runtime resources are active while I/O operations are ongoing,
they aren't in those drivers as of today.
So to give you some more details about why I wanted to push for a
removal of MMC_CLKGATE. You have one reason above. I want host drivers
that considers power save at request inactivity, to implement proper
runtime PM support and to do clock gating as a part of runtime PM.
There are already good references, like mmci and sdhci-* for example.
MMC_CLKGATE is an old way of dealing with clock gating for power save,
runtime PM is better suited and has been there now for a long
Re: [PATCH 0/2] mmc: core: Remove all code related to MMC_CLKGATE
Hi Ulf On Tue, 1 Oct 2013, Ulf Hansson wrote: On 30 September 2013 23:10, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Ulf On Mon, 30 Sep 2013, Ulf Hansson wrote: This patchset is remove all code related to MMC_CLKGATE. A significant portion of code can then be removed from the core layer which would simplify maintainance. At the moment it seems like only some MIPS platforms were using MMC_CLKGATE, but at the same time the corresponding host drivers were not taking advantage of the mechanism. This made me feel confident in removing the feature entirely from the mmc subsystem could be done. Also do note that for host drivers that would like to implement clock gating as a power save operation, using runtime PM is a far easier way to address this. Several host drivers is already fully supporting this as well. Ulf Hansson (2): MIPS: db1235: Don't use MMC_CLKGATE mmc: core: Remove MMC_CLKGATE Do I understand correctly, that you're proposing to remove the aggressive clock gating feature from MMC? If so, then please take into account my NAK. At least two SD / MMC drivers, that I'm aware of, actively used and developed on multiple platforms - sh_mmcif and tmio / sdhi implement MMC clock gating and rely on it to save power between IO. Guennadi, thanks for your NAK, you have understood correctly what my intention is. :-) Looking into your two examples, sh_mmcif and sh_mobile_sdhci (using tmio), I realize that they use runtime PM in an awkward way. I would suggest to move parts of the clock gating from .set_ios to runtime PM callbacks instead. Obviously proper calls to pm_runtime_get|put needs to be adopted as well. pm_runtime_get|put should be used to make sure your runtime resources are active while I/O operations are ongoing, they aren't in those drivers as of today. So to give you some more details about why I wanted to push for a removal of MMC_CLKGATE. You have one reason above. I want host drivers that considers power save at request inactivity, to implement proper runtime PM support and to do clock gating as a part of runtime PM. There are already good references, like mmci and sdhci-* for example. MMC_CLKGATE is an old way of dealing with clock gating for power save, runtime PM is better suited and has been there now for a long time now. It is time to switch. I don't think mmc clock gating should be depending on a separate kernel config as MMC_CLKGATE, which likely is the reason to why there are no defconfig that has this option enabled. Instead RUNTIME_PM already has this implicit meaning of handling with power save at request inactivity. Finally, it is nice to remove code from a maintenance point of view. The MMC_CLKGATE code is being used in a lot of places around the core layer, since mmc_host_clk_hold|release needs to be called so many times. What are your thoughts on the way forward? Could we adopt fully runtime pm support for sh_mmcif sh_mobile_sdhci soon? Sorry, I don't have any information whether or when this will be done. Thanks Guennadi Kind regards Ulf Hansson Thanks Guennadi Documentation/mmc/mmc-dev-attrs.txt | 10 -- arch/mips/configs/db1235_defconfig |1 - drivers/mmc/core/Kconfig| 10 -- drivers/mmc/core/core.c | 116 + drivers/mmc/core/core.h |3 - drivers/mmc/core/debugfs.c |5 - drivers/mmc/core/host.c | 245 --- drivers/mmc/core/mmc.c |6 +- drivers/mmc/core/sd.c | 12 +- drivers/mmc/core/sdio.c |5 +- drivers/mmc/core/sdio_irq.c | 10 +- include/linux/mmc/host.h| 27 12 files changed, 12 insertions(+), 438 deletions(-) -- 1.7.9.5 -- 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 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 0/2] mmc: core: Remove all code related to MMC_CLKGATE
Hi Ulf On Mon, 30 Sep 2013, Ulf Hansson wrote: This patchset is remove all code related to MMC_CLKGATE. A significant portion of code can then be removed from the core layer which would simplify maintainance. At the moment it seems like only some MIPS platforms were using MMC_CLKGATE, but at the same time the corresponding host drivers were not taking advantage of the mechanism. This made me feel confident in removing the feature entirely from the mmc subsystem could be done. Also do note that for host drivers that would like to implement clock gating as a power save operation, using runtime PM is a far easier way to address this. Several host drivers is already fully supporting this as well. Ulf Hansson (2): MIPS: db1235: Don't use MMC_CLKGATE mmc: core: Remove MMC_CLKGATE Do I understand correctly, that you're proposing to remove the aggressive clock gating feature from MMC? If so, then please take into account my NAK. At least two SD / MMC drivers, that I'm aware of, actively used and developed on multiple platforms - sh_mmcif and tmio / sdhi implement MMC clock gating and rely on it to save power between IO. Thanks Guennadi Documentation/mmc/mmc-dev-attrs.txt | 10 -- arch/mips/configs/db1235_defconfig |1 - drivers/mmc/core/Kconfig| 10 -- drivers/mmc/core/core.c | 116 + drivers/mmc/core/core.h |3 - drivers/mmc/core/debugfs.c |5 - drivers/mmc/core/host.c | 245 --- drivers/mmc/core/mmc.c |6 +- drivers/mmc/core/sd.c | 12 +- drivers/mmc/core/sdio.c |5 +- drivers/mmc/core/sdio_irq.c | 10 +- include/linux/mmc/host.h| 27 12 files changed, 12 insertions(+), 438 deletions(-) -- 1.7.9.5 -- 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 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 0/7] mmc: core: Fixup ocr mask setup to prevent spec violation
(adding Mark to cc) On Tue, 17 Sep 2013, Ulf Hansson wrote: On 16 September 2013 22:57, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Ulf On Mon, 16 Sep 2013, Ulf Hansson wrote: According to the eMMC/SD/SDIO specs the VDD voltage level must not be changed during the initialization, without a complete power cycle of the card. Before this patchset, some host drivers were trying to change voltage level at MMC_POWER_ON state, which is also what the protocol layer advised them to. This was not correctly done and is the reason to why quite messy code in the protocol layer has been needed, to handle a re-initialization sequence, typically triggered from a power_restore or resume. I have tried to make each patch in the patchset as small and separate as possible, surely the is room for improvments. Any suggestions are appreciated. An important note; MMC_CAP2_FULL_PWR_CYCLE, will need to be set by a host to tell the protocol layer that the host is able to perform a complete power cycle. Thus the protocol layer will try to negotiate the lowest possible VDD voltage level between the card and host. Hi Guennadi, I've got a question to this one. You mean a power cycle of a card, right? Correct! What if the card power is supplied by a regulator. How do you tell whether you can power cycle it or not? Maybe you can theoretically switch that regulator - sometimes. On other occasions other users might be preventing it from really powering off. Do you really need a guarantee, that every time you issue a power down .set_ios() the card will really be switched off? I don't see how this can be possible in my example? Yes, we need a guarantee to be able to conform to the specs. In one of my cases I am also using a regulator, but from a board configuration point of view I know I am the only user on this regulator, thus I can be sure I can switch it off when I want. I see your point though, and I am not sure how to adapt to this configuration. I suggest you to not set the MMC_CAP2_FULL_PWR_CYCLE for that mmc host - unless you can find a way to make sure you can cut and restore power when needed. So, do I understand correctly, that if we get a regulator exclusively and it is capable of changing status (REGULATOR_CHANGE_STATUS) and it is not always on, then we can assume, that every call to regulator_enable() / regulator_disable() with a suitable use count _will_ switch power off or on? Maybe then we could adjust mmc_regulator_get_supply() accordingly - first try to get the regulator exclusively, if it fails, try shared. If succeeded and the conditions are satisfied - set the new PWR_CYCLE flag. Thanks Guennadi Kind regards Ulf Hansson Thanks Guennadi Ulf Hansson (7): mmc: core: Let mmc_power_up|cycle take ocr as parameter mmc: core: Let mmc_set_signal_voltage take ocr as parameter mmc: core: Remove unnecessary retry mechanism at SDIO attach mmc: core: Cleanup code for setting ocr mask for SDIO mmc: core: Move cached value of the negotiated ocr mask to card struct mmc: core: Prevent violation of specs while initializing cards mmc: core: Collect common code for card ocr validation drivers/mmc/core/core.c | 66 + drivers/mmc/core/core.h |6 ++-- drivers/mmc/core/mmc.c | 29 +--- drivers/mmc/core/sd.c| 41 +++ drivers/mmc/core/sdio.c | 82 ++ include/linux/mmc/card.h |1 + include/linux/mmc/host.h |1 - 7 files changed, 79 insertions(+), 147 deletions(-) -- 1.7.9.5 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 0/7] mmc: core: Fixup ocr mask setup to prevent spec violation
Hi Ulf On Mon, 16 Sep 2013, Ulf Hansson wrote: According to the eMMC/SD/SDIO specs the VDD voltage level must not be changed during the initialization, without a complete power cycle of the card. Before this patchset, some host drivers were trying to change voltage level at MMC_POWER_ON state, which is also what the protocol layer advised them to. This was not correctly done and is the reason to why quite messy code in the protocol layer has been needed, to handle a re-initialization sequence, typically triggered from a power_restore or resume. I have tried to make each patch in the patchset as small and separate as possible, surely the is room for improvments. Any suggestions are appreciated. An important note; MMC_CAP2_FULL_PWR_CYCLE, will need to be set by a host to tell the protocol layer that the host is able to perform a complete power cycle. Thus the protocol layer will try to negotiate the lowest possible VDD voltage level between the card and host. I've got a question to this one. You mean a power cycle of a card, right? What if the card power is supplied by a regulator. How do you tell whether you can power cycle it or not? Maybe you can theoretically switch that regulator - sometimes. On other occasions other users might be preventing it from really powering off. Do you really need a guarantee, that every time you issue a power down .set_ios() the card will really be switched off? I don't see how this can be possible in my example? Thanks Guennadi Ulf Hansson (7): mmc: core: Let mmc_power_up|cycle take ocr as parameter mmc: core: Let mmc_set_signal_voltage take ocr as parameter mmc: core: Remove unnecessary retry mechanism at SDIO attach mmc: core: Cleanup code for setting ocr mask for SDIO mmc: core: Move cached value of the negotiated ocr mask to card struct mmc: core: Prevent violation of specs while initializing cards mmc: core: Collect common code for card ocr validation drivers/mmc/core/core.c | 66 + drivers/mmc/core/core.h |6 ++-- drivers/mmc/core/mmc.c | 29 +--- drivers/mmc/core/sd.c| 41 +++ drivers/mmc/core/sdio.c | 82 ++ include/linux/mmc/card.h |1 + include/linux/mmc/host.h |1 - 7 files changed, 79 insertions(+), 147 deletions(-) -- 1.7.9.5 -- 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 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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] ARM: shmobile: update SDHI DT compatibility string to the unit-soc format
Currently DT compatibility strings of both types can be found in the kernel
sources: unit-soc and soc-unit, whereas a unique format should be
followed and the former one is preferred. This patch converts the SDHI
MMC driver and its users to the common standard. This is safe for now, since
ATM no real products are using this driver with DT.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
Ok, the no real products is an assumption, that Laurent and Simon kind
of agreed upon, so, I'm using it here to avoid having to carry old
compatibility strings with us around. If anyone has other information -
please shout. Otherwise, I think, it would be the easiest for Chris to ack
this and for Simon to pull this via the ARM tree for late 3.12 (possibly,
post -rc1) inclusion.
Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 17 ++---
arch/arm/boot/dts/r8a73a4.dtsi |6 +++---
arch/arm/boot/dts/r8a7740.dtsi |4 ++--
arch/arm/boot/dts/r8a7790.dtsi |8
arch/arm/boot/dts/sh73a0.dtsi |6 +++---
drivers/mmc/host/sh_mobile_sdhi.c | 16
6 files changed, 30 insertions(+), 27 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
index df204e1..6a2a116 100644
--- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
@@ -9,12 +9,15 @@ compulsory and any optional properties, common to all SD/MMC
drivers, as
described in mmc.txt, can be used. Additionally the following tmio_mmc-specific
optional bindings can be used.
+Required properties:
+- compatible: renesas,sdhi-shmobile - a generic sh-mobile SDHI unit
+ renesas,sdhi-sh7372 - SDHI IP on SH7372 SoC
+ renesas,sdhi-sh73a0 - SDHI IP on SH73A0 SoC
+ renesas,sdhi-r8a73a4 - SDHI IP on R8A73A4 SoC
+ renesas,sdhi-r8a7740 - SDHI IP on R8A7740 SoC
+ renesas,sdhi-r8a7778 - SDHI IP on R8A7778 SoC
+ renesas,sdhi-r8a7779 - SDHI IP on R8A7779 SoC
+ renesas,sdhi-r8a7790 - SDHI IP on R8A7790 SoC
+
Optional properties:
- toshiba,mmc-wrprotect-disable: write-protect detection is unavailable
-
-When used with Renesas SDHI hardware, the following compatibility strings
-configure various model-specific properties:
-
-renesas,sh7372-sdhi: (default) compatible with SH7372
-renesas,r8a7740-sdhi:compatible with R8A7740: certain MMC/SD
commands have to
- wait for the interface to become idle.
diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index b0511b1..cc7211b 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -236,7 +236,7 @@
};
sdhi0: sdhi@ee10 {
- compatible = renesas,r8a73a4-sdhi;
+ compatible = renesas,sdhi-r8a73a4;
reg = 0 0xee10 0 0x100;
interrupt-parent = gic;
interrupts = 0 165 4;
@@ -245,7 +245,7 @@
};
sdhi1: sdhi@ee12 {
- compatible = renesas,r8a73a4-sdhi;
+ compatible = renesas,sdhi-r8a73a4;
reg = 0 0xee12 0 0x100;
interrupt-parent = gic;
interrupts = 0 166 4;
@@ -254,7 +254,7 @@
};
sdhi2: sdhi@ee14 {
- compatible = renesas,r8a73a4-sdhi;
+ compatible = renesas,sdhi-r8a73a4;
reg = 0 0xee14 0 0x100;
interrupt-parent = gic;
interrupts = 0 167 4;
diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index 8fc4a5d..c4992b5 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -155,7 +155,7 @@
};
sdhi0: sdhi@e685 {
- compatible = renesas,r8a7740-sdhi;
+ compatible = renesas,sdhi-r8a7740;
reg = 0xe685 0x100;
interrupt-parent = gic;
interrupts = 0 117 4
@@ -167,7 +167,7 @@
};
sdhi1: sdhi@e686 {
- compatible = renesas,r8a7740-sdhi;
+ compatible = renesas,sdhi-r8a7740;
reg = 0xe686 0x100;
interrupt-parent = gic;
interrupts = 0 121 4
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 3b879e7..885f9f4 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -152,7 +152,7 @@
};
sdhi0: sdhi@ee10 {
- compatible = renesas,r8a7790-sdhi;
+ compatible = renesas,sdhi-r8a7790;
reg = 0 0xee10 0 0x100;
interrupt-parent = gic;
interrupts = 0 165 4;
@@ -161,7 +161,7
Re: [PATCH] mmc:tmio_mmc change driver to use dev_pm_ops infrastructure
Hi Shuah Khan,
On Sat, 10 Aug 2013, Shuah Khan wrote:
Change tmio_mmc platform driver to register pm ops using dev_pm_ops instead of
legacy pm_ops infrastructure.
Signed-off-by: Shuah Khan shuah...@samsung.com
This looks good to me, although I don't have access to any MFD-based TMIO
MMC systems, so, cannot test. In fact that code hasn't been touched for a
while now, so, I don't even know if anyone is still using it. With that in
mind
Acked-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
Thanks
Guennadi
---
drivers/mmc/host/tmio_mmc.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index 8860d4d..3e3c730 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -24,31 +24,33 @@
#include tmio_mmc.h
#ifdef CONFIG_PM
-static int tmio_mmc_suspend(struct platform_device *dev, pm_message_t state)
+static int tmio_mmc_suspend(struct device *dev)
{
- const struct mfd_cell *cell = mfd_get_cell(dev);
+ struct platform_device *pdev = to_platform_device(dev);
+ const struct mfd_cell *cell = mfd_get_cell(pdev);
int ret;
- ret = tmio_mmc_host_suspend(dev-dev);
+ ret = tmio_mmc_host_suspend(dev);
/* Tell MFD core it can disable us now.*/
if (!ret cell-disable)
- cell-disable(dev);
+ cell-disable(pdev);
return ret;
}
-static int tmio_mmc_resume(struct platform_device *dev)
+static int tmio_mmc_resume(struct device *dev)
{
- const struct mfd_cell *cell = mfd_get_cell(dev);
+ struct platform_device *pdev = to_platform_device(dev);
+ const struct mfd_cell *cell = mfd_get_cell(pdev);
int ret = 0;
/* Tell the MFD core we are ready to be enabled */
if (cell-resume)
- ret = cell-resume(dev);
+ ret = cell-resume(pdev);
if (!ret)
- ret = tmio_mmc_host_resume(dev-dev);
+ ret = tmio_mmc_host_resume(dev);
return ret;
}
@@ -123,17 +125,19 @@ static int tmio_mmc_remove(struct platform_device *pdev)
return 0;
}
+static SIMPLE_DEV_PM_OPS(tmio_mmc_dev_pm_ops, tmio_mmc_suspend,
+ tmio_mmc_resume);
+
/* --- device registration --- */
static struct platform_driver tmio_mmc_driver = {
.driver = {
.name = tmio-mmc,
.owner = THIS_MODULE,
+ .pm = tmio_mmc_dev_pm_ops,
},
.probe = tmio_mmc_probe,
.remove = tmio_mmc_remove,
- .suspend = tmio_mmc_suspend,
- .resume = tmio_mmc_resume,
};
module_platform_driver(tmio_mmc_driver);
--
1.7.10.4
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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
my outstanding patches for 3.12
Hi Chris There are still a number of MMC patches from me for 3.12, that still aren't in next. Unless I'm missing anything, here's the list of patches with their respective patchwork IDs: mmc: SDHI: add DT compatibility strings for further SoCs pw ID: 2828382 mmc: sh_mmcif: move header include from header into .c pw ID: 2837887 mmc: sh_mmcif: add support for Device Tree DMA bindings pw ID: 2770781 mmc: sh_mmcif: revision-specific Command Completion Signal handling pw ID: 2825876 mmc: sh_mmcif: revision-specific CLK_CTRL2 handling pw ID: 2825870 Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: change mmc_gpio_get_cd to call non-sleep gpio
On Thu, 8 Aug 2013, Christian Daudt wrote: Given that mmc_gpio_get_cd can be called in softirq context (by sdhci_tasklet_card - sdhci_card_event - sdhci_do_get_cd - mmc_gpio_get_cd ), it is necessary for it to use gpio_get_value instead of gpio_get_value_cansleep Note that at present sdhci_card_event gets called both from mmc_gpio_cd_irqt and sdhci_tasklet_card, and from both it gets called immediately while the actual cd processing is debounced to 200ms later. I think that the better solution might be to move the sdhci_card_event callback into mmc_rescan and remove it from its 2 present locations. That way the cd related callbacks are aligned with the actual cd detection code. I can submit a follow-up patch with these mods if that sounds like a better way to solve this. Signed-off-by: Christian Daudt c...@broadcom.com I don't think this is a right approach. It will Oops if the card-detect GPIO is provided by, e.g. an I2C GPIO controller. Instead the driver should be fixed to only call this function from a sleeping context. Thanks Guennadi diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c index 3242351..897b298 100644 --- a/drivers/mmc/core/slot-gpio.c +++ b/drivers/mmc/core/slot-gpio.c @@ -87,7 +87,7 @@ int mmc_gpio_get_cd(struct mmc_host *host) if (!ctx || !gpio_is_valid(ctx-cd_gpio)) return -ENOSYS; - return !gpio_get_value_cansleep(ctx-cd_gpio) ^ + return !gpio_get_value(ctx-cd_gpio) ^ !!(host-caps2 MMC_CAP2_CD_ACTIVE_HIGH); } EXPORT_SYMBOL(mmc_gpio_get_cd); -- 1.7.10.4 -- 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 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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/RFC] mmc: sh_mmcif: revision-specific configuration from Device Tree
Add compatibility strings to configure MMCIF revision-specific features.
MMCIF blocks are always integrated into SoCs, so, we use SoC model to
distinguish between MMCIF versions.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
Hi Chris,
I marked this as RFC, because having no access to the MMC standard I'm not
certain about VccQ requirements for MMC DDR. On the one hand a comment in
mmc.c says
* EXT_CSD_CARD_TYPE_DDR_1_8V means 3.3V or 1.8V vccq.
which suggests, that DDR (DDR50?) can be used with VccQ = 3.3V, 1.8V and
1.2V at least. But in mmc_init_card() DDR50 is only requested from the
driver if either MMC_CAP_1_8V_DDR or MMC_CAP_1_2V_DDR is specified in
host's capabilities. So, I'm actually not sure whether MMC_CAP_UHS_DDR50
alone without 1_8V or 1_2V makes sense. That's also what I implemented in
this patch - DDR50 is only enabled in combination with either 1.2 or 1.8V
capability. Is this correct?
Documentation/devicetree/bindings/mmc/sh_mmcif.txt | 15
drivers/mmc/host/sh_mmcif.c| 68 +--
2 files changed, 75 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/sh_mmcif.txt
diff --git a/Documentation/devicetree/bindings/mmc/sh_mmcif.txt
b/Documentation/devicetree/bindings/mmc/sh_mmcif.txt
new file mode 100644
index 000..a0e7fee
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sh_mmcif.txt
@@ -0,0 +1,15 @@
+* Renesas MMCIF MMC controller
+
+The MMCIF driver uses the standard mmc DT parser to evaluate all standard MMC
DT
+properties. Additionally the following properties must or can be used:
+
+Compulsory properties:
+- compatible: must be one of
+ renesas,sh-mmcif for generic MMCIF blocks
+ renesas,sh-mmcif-r8a73a4 for MMCIF on R8A73A4 (APE6)
+ renesas,sh-mmcif-r8a7740 for MMCIF on R8A7740 (A1)
+ renesas,sh-mmcif-r8a7790 for MMCIF on R8A7790 (H2)
+ renesas,sh-mmcif-sh73a0 for MMCIF on SH73A0 (AG5)
+ renesas,sh-mmcif-sh7372 for MMCIF on SH7372 (AP4)
+
+Further, any standard MMC DT properties from mmc.txt can be used.
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 444f83b..a4bd784 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -57,6 +57,7 @@
#include linux/mmc/slot-gpio.h
#include linux/mod_devicetable.h
#include linux/mutex.h
+#include linux/of_device.h
#include linux/pagemap.h
#include linux/platform_device.h
#include linux/pm_qos.h
@@ -257,6 +258,39 @@ struct sh_mmcif_host {
booldma_active;
};
+struct sh_mmcif_of_data {
+ unsigned intccs_enable : 1;
+ unsigned intclk_ctrl2_enable : 1;
+ unsigned intuhs_ddr_1v8 : 1;
+ unsigned intuhs_ddr_1v2 : 1;
+};
+
+enum {
+ R8A73A4,
+ R8A7740,
+ R8A7790,
+ SH7372,
+ SH73A0,
+};
+
+static const struct sh_mmcif_of_data sh_mmcif_of_cfg[] = {
+ [R8A73A4] = {
+ .uhs_ddr_1v8 = 1,
+ },
+ [R8A7740] = {
+ /* all disabled */
+ },
+ [R8A7790] = {
+ .clk_ctrl2_enable = 1,
+ },
+ [SH73A0] = {
+ .uhs_ddr_1v8 = 1,
+ },
+ [SH7372] = {
+ .ccs_enable = 1,
+ },
+};
+
static inline void sh_mmcif_bitset(struct sh_mmcif_host *host,
unsigned int reg, u32 val)
{
@@ -1362,8 +1396,21 @@ static void sh_mmcif_init_ocr(struct sh_mmcif_host *host)
dev_warn(mmc_dev(mmc), Platform OCR mask is ignored\n);
}
+static const struct of_device_id mmcif_of_match[] = {
+ {.compatible = renesas,sh-mmcif},
+ {.compatible = renesas,sh-mmcif-r8a73a4, .data =
sh_mmcif_of_cfg[R8A73A4]},
+ {.compatible = renesas,sh-mmcif-r8a7740, .data =
sh_mmcif_of_cfg[R8A7740]},
+ {.compatible = renesas,sh-mmcif-r8a7790, .data =
sh_mmcif_of_cfg[R8A7790]},
+ {.compatible = renesas,sh-mmcif-sh73a0, .data =
sh_mmcif_of_cfg[SH73A0]},
+ {.compatible = renesas,sh-mmcif-sh7372, .data =
sh_mmcif_of_cfg[SH7372]},
+ {}
+};
+MODULE_DEVICE_TABLE(of, mmcif_of_match);
+
static int sh_mmcif_probe(struct platform_device *pdev)
{
+ const struct of_device_id *of_id =
+ of_match_device(mmcif_of_match, pdev-dev);
int ret = 0, irq[2];
struct mmc_host *mmc;
struct sh_mmcif_host *host;
@@ -1403,8 +1450,19 @@ static int sh_mmcif_probe(struct platform_device *pdev)
host-mmc = mmc;
host-addr = reg;
host-timeout = msecs_to_jiffies(1000);
- host-ccs_enable = !pd || !pd-ccs_unsupported;
- host-clk_ctrl2_enable = pd pd-clk_ctrl2_present;
+
+ if (of_id of_id-data) {
+ const struct sh_mmcif_of_data *of_data = of_id-data;
+ host-ccs_enable = of_data-ccs_enable;
+ host-clk_ctrl2_enable
Re: [PATCH/RFC] mmc: sh_mmcif: revision-specific configuration from Device Tree
Hi Chris On Mon, 5 Aug 2013, Chris Ball wrote: Hi Guennadi, On Mon, Aug 05 2013, Guennadi Liakhovetski wrote: Add compatibility strings to configure MMCIF revision-specific features. MMCIF blocks are always integrated into SoCs, so, we use SoC model to distinguish between MMCIF versions. Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com --- Hi Chris, I marked this as RFC, because having no access to the MMC standard I'm not certain about VccQ requirements for MMC DDR. On the one hand a comment in mmc.c says * EXT_CSD_CARD_TYPE_DDR_1_8V means 3.3V or 1.8V vccq. which suggests, that DDR (DDR50?) can be used with VccQ = 3.3V, 1.8V and 1.2V at least. But in mmc_init_card() DDR50 is only requested from the driver if either MMC_CAP_1_8V_DDR or MMC_CAP_1_2V_DDR is specified in host's capabilities. So, I'm actually not sure whether MMC_CAP_UHS_DDR50 alone without 1_8V or 1_2V makes sense. That's also what I implemented in this patch - DDR50 is only enabled in combination with either 1.2 or 1.8V capability. Is this correct? OLPC's using DDR50 at 3.3V in production. Honestly, I don't know whether it's spec compliant (I think the spec claims that 1.8V is required) but it happens to work on these parts. The host controller does support 1.8V, there's just no hardware capable of supplying 1.8V to MMC on the board. Thanks for the example. So, I think, for now it should be ok to just act in a way, compatible with the mmc core, i.e. always set one of MMC_CAP_1_8V_DDR or MMC_CAP_1_2V_DDR, when aiming at MMC_CAP_UHS_DDR50. So, the patch should be ok then. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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] tmio_mmc_dma: fix PIO fallback on SDHI
Hi Sergei,
Thanks for your patch.
On Fri, 2 Aug 2013, Sergei Shtylyov wrote:
I'm testing SH-Mobile SDHI driver in DMA mode with a new DMA controller
using
'bonnie++' and getting DMA error after which the tmio_mmc_dma.c code falls
back
to PIO but all commands time out after that. It turned out that the fallback
code calls tmio_mmc_enable_dma() with RX/TX channels already freed and
pointers
to them cleared, so that the function bails out early instead of clearing the
DMA bit in the CTL_DMA_ENABLE register. Fixing the RX/TX channel check so
that
it takes place only when enabling DMA helps with the PIO fallback.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
The patch is against Chris Ball's 'mmc.git' repo, 'master' branch.
drivers/mmc/host/tmio_mmc_dma.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: mmc/drivers/mmc/host/tmio_mmc_dma.c
===
--- mmc.orig/drivers/mmc/host/tmio_mmc_dma.c
+++ mmc/drivers/mmc/host/tmio_mmc_dma.c
@@ -25,7 +25,7 @@
void tmio_mmc_enable_dma(struct tmio_mmc_host *host, bool enable)
{
- if (!host-chan_tx || !host-chan_rx)
+ if (enable !(host-chan_tx host-chan_rx))
return;
Ok, I see the problem and this does fix it. But it adds complexity to the
driver - one more condition to an if. Whereas, I think, it can be avoided
if we just move calls to
tmio_mmc_enable_dma(host, false);
in tmio_mmc_start_dma_rx() and tmio_mmc_start_dma_tx() a couple of lines
up - before clearing -chan_rx and -chan_tx pointers? That should work
too at no cost. I think that would be a better fix, could you, please,
try?
Thanks
Guennadi
#if defined(CONFIG_SUPERH) || defined(CONFIG_ARCH_SHMOBILE)
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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] mmc: sh_mmcif: move header include from header into .c
sh_dma.h isn't needed in sh_mmcif.h, move it into sh_mmcif.c. Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com --- drivers/mmc/host/sh_mmcif.c |1 + include/linux/mmc/sh_mmcif.h |1 - 2 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c index 6706b5e..220ee30 100644 --- a/drivers/mmc/host/sh_mmcif.c +++ b/drivers/mmc/host/sh_mmcif.c @@ -61,6 +61,7 @@ #include linux/platform_device.h #include linux/pm_qos.h #include linux/pm_runtime.h +#include linux/sh_dma.h #include linux/spinlock.h #include linux/module.h diff --git a/include/linux/mmc/sh_mmcif.h b/include/linux/mmc/sh_mmcif.h index e7d5dd6..5fcd3eb 100644 --- a/include/linux/mmc/sh_mmcif.h +++ b/include/linux/mmc/sh_mmcif.h @@ -16,7 +16,6 @@ #include linux/io.h #include linux/platform_device.h -#include linux/sh_dma.h /* * MMCIF : CE_CLK_CTRL [19:16] -- 1.7.2.5 -- 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: tmio-mmc: Check the regulator_enable() return value
Hi Laurent
On Wed, 31 Jul 2013, Laurent Pinchart wrote:
The regulator_enable() function is marked with __must_check, check its
return value and return an error in case of failure. This removes the
following warning during kernel compilation:
drivers/mmc/host/tmio_mmc_pio.c: In function ‘tmio_mmc_power_on’:
drivers/mmc/host/tmio_mmc_pio.c:795:19: warning: ignoring return value
of ‘regulator_enable’, declared with attribute warn_unused_result
[-Wunused-result]
The error isn't propagated back to the MMC core, as the .set_ios()
operation in which the regulator is enabled doesn't have a return value.
This should be fixed as well.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Should be fixed by now:
http://thread.gmane.org/gmane.linux.kernel.mmc/21294
Thanks
Guennadi
---
drivers/mmc/host/tmio_mmc_pio.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 4675513..e3e2645 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -770,15 +770,18 @@ static int tmio_mmc_clk_update(struct mmc_host *mmc)
return ret;
}
-static void tmio_mmc_power_on(struct tmio_mmc_host *host, unsigned short vdd)
+static int tmio_mmc_power_on(struct tmio_mmc_host *host, unsigned short vdd)
{
struct mmc_host *mmc = host-mmc;
- int ret = 0;
+ int ret;
/* .set_ios() is returning void, so, no chance to report an error */
if (!IS_ERR(mmc-supply.vmmc)) {
ret = mmc_regulator_set_ocr(mmc, mmc-supply.vmmc, vdd);
+ if (ret 0)
+ return ret;
+
/*
* Attention: empiric value. With a b43 WiFi SDIO card this
* delay proved necessary for reliable card-insertion probing.
@@ -791,10 +794,15 @@ static void tmio_mmc_power_on(struct tmio_mmc_host
*host, unsigned short vdd)
* It seems, VccQ should be switched on after Vcc, this is also what the
* omap_hsmmc.c driver does.
*/
- if (!IS_ERR(mmc-supply.vqmmc) !ret) {
- regulator_enable(mmc-supply.vqmmc);
+ if (!IS_ERR(mmc-supply.vqmmc)) {
+ ret = regulator_enable(mmc-supply.vqmmc);
+ if (ret 0)
+ return ret;
+
udelay(200);
}
+
+ return 0;
}
static void tmio_mmc_power_off(struct tmio_mmc_host *host)
--
1.8.1.5
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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/2] mmc: add Device Tree properties for UHS modes
Hi Stephen On Fri, 26 Jul 2013, Stephen Warren wrote: On 07/26/2013 02:23 PM, Guennadi Liakhovetski wrote: Hi Stephen On Fri, 26 Jul 2013, Stephen Warren wrote: On 07/26/2013 09:51 AM, Guennadi Liakhovetski wrote: Add DT properties for UHS SDR12, SDR25, SDR50, SDR104 and DDR50 modes and for supported by the host in DDR mode VccQ values. Adding them to DT will automatically enable respective MMC host capabilities. diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt +- uhs-sdr12: the host supports UHS SDR12 mode +- uhs-sdr25: the host supports UHS SDR25 mode +- uhs-sdr50: the host supports UHS SDR50 mode +- uhs-sdr104: the host supports UHS SDR104 mode +- uhs-ddr50: the host supports UHS DDR50 mode +- ddr-1v2: the host can support DDR, using 1.2V VccQ +- ddr-1v8: the host can support DDR, using 1.8V VccQ Surely the driver for the host controller already knows this, so there's no need to represent it in DT? Not necessarily. One driver can handle several versions of the same chip, and some versions of the chip implement some of those features, others don't. Certainly. So, your choice is really whether to specify a chip version in the compatible string or these properties. There's no choice there. The compatible property needs to specify all of the following: * A value which describes the exact chip the IP block is in. This can be matched on to enable any quirks that need to be handled due to integration of the IP into the particular chip. This value will list the chip version. An example might be tegra20-sdhci. * A value which describes the IP block version (if that IP block has a version independent of the SoC that contains it, as e.g. a Synopsis IP block might). A totally made-up example might be synopsis-dwc2-1.0.0 * Various more generic values that describe the HW, and that define a n interface to the HW that is specific and complete enough that HW can program to. An example might be usb-ehci (assuming a chip that doesn't have so many quirks that a driver has to know more than just it's an EHCI controller). Yes, all these certainly make sense. As far as I understand, we are still in the process of defining good clear rules for DTs, there is an ABI discussion currently running on ALKML and IIRC this is also going to be a topic for one of coming conferences. So, hopefully we're approaching a state of a greater clarity about DT. Further classes of compatible value might exist, but you get the idea. All of those values have to exist in the DT right from the very start, so that the first DT is usable with a future kernel, which might decide to vary the exact compatible value(s) it matches on, provided they're all documented in the DT binding ABI, in order to enable/disable new sets of quirsk. Makes sense too, sure. Now, when you consider that multiple drivers have to decide upon those, and sometimes you don't have an exact IP version of the SD/MMC controller but only the SoC version, you choice becomes: That would be a bug in the DT, given my assertions above. Sorry, what exactly would be a bug? Not having an exact IP version? But you did write above - if that IP block has a version independent of the SoC that contains it. In my case it doesn't really. Those IPs only exist within those SoCs. either _standard_ _common_ properties as above, or compatibility strings virtually in each driver for each SoC version. My preference would certainly be to derive the data from compatible strings here. I'd prefer more that DT represent board differences rather than SoC differences; drivers can encompass the SoC differences with minimal code in general. In general - yes, I fully agree. I wasn't sure about this specific case, exactly because those are standard properties, that, if implemented as DT properties, can be trivially re-used by all drivers with 0 additional code. Related, is it really true that zero driver involvement is required to enable these UHS features? I think it is, in most cases at least. If absolutely any HW can enable them without any driver support at all, then perhaps it's still reasonable to create DT properties to enable them. However, if driver support is required to make those features actually work, the driver had better be validating that support actually works on the HW it's running on before enabling the feature (and can therefore pass the validation results to the SD core rather than relying on DT properties to be set). I think it rather works the other way round. Those flags only mark hardware _capabilities_. But don't tell the driver to use them yet. Normally drivers just collect them in their .caps and .caps2 fields and pass on to the mmc core. The mmc core then card detection and querying and if a card and the host interface to it are suitable for certain features, marked
Re: [PATCH 1/2] mmc: add Device Tree properties for UHS modes
On Mon, 29 Jul 2013, Pawel Moll wrote: On Mon, 2013-07-29 at 12:27 +0100, Guennadi Liakhovetski wrote: On Mon, 29 Jul 2013, Pawel Moll wrote: On Mon, 2013-07-29 at 08:18 +0100, Guennadi Liakhovetski wrote: A short addendum. At least with Renesas SoCs I see the situation in the following way: new SoC versions appear relatively frequently. What frequency are we talking about? Once per year? Once per month? I'm not trying to be picky, it really makes a difference... Definitely not every month - not until now in the mainline at least. I currently count 9 SoCs, added since 2010, which makes about 2-3 SoCs per year. So this is actually a slower rate that I've faced in my previous life working for a silicon vendor ;-) And my experience is that the IPs were different between the SoCs indeed but: 1. Not all of them at the same time (so no extra compatible values for others). No, that's exactly the problem. We absolutely do not want to write compatible=vendor,soc-v1; in a .dts file for SoC v2 just because we currently think, that we don't have to distinguish between those SoC versions in this specific driver. I think we all know it quite well, that there are (practically) always differences - sometimes documented, sometimes undocumented. And if you later find out, that you do have to differentiate in the driver - it's too late. Even if we disregard the argument of ugliness of having to set compatibility with soc-v1, soc-v2, soc-v3 in different DT nodes on an SoC v4. Thanks Guennadi 2. When there was a change it required change in a driver as well (so adding a compatible value is not an issue). 3. The changes were *completely* unpredictable (so even comprehensive list of DT properties wouldn't help) To summarize, count this as another vote for using compatible rather then universal future-proof set of properties. Unless there is a very good rationale for it (I'm sure such cases exist) Thanks! Pawel --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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/2] mmc: add Device Tree properties for UHS modes
On Mon, 29 Jul 2013, Pawel Moll wrote: On Mon, 2013-07-29 at 13:05 +0100, Guennadi Liakhovetski wrote: No, that's exactly the problem. We absolutely do not want to write compatible=vendor,soc-v1; in a .dts file for SoC v2 just because we currently think, that we don't have to distinguish between those SoC versions in this specific driver. I think we all know it quite well, that there are (practically) always differences - sometimes documented, sometimes undocumented. And if you later find out, that you do have to differentiate in the driver - it's too late. Even if we disregard the argument of ugliness of having to set compatibility with soc-v1, soc-v2, soc-v3 in different DT nodes on an SoC v4. First of all I think your example calls for more than one compatible string - if it seems that soc,v2 is almost like soc,v1, make it compatible = soc-v2, soc-v1 and don't touch the driver (as in: keep it compatible with soc-v1 only). Then, when the realisation comes, you can simply add the soc-v2 of_device_id with .data pointing at new features. Yes, this is also a possibility, but it seems only a little bit better. Why should a DT node on SoC vN have a compatible string with SoC vK for some random for an abstract user absolutely unrelated SoC version?... And that vK would be different for different devices... So on SoC v5 MMC can be compatible with with v1, sound with v2, camera with v3... Don't you think it would look like a mess? Now the other thing - do you have a driver for a SoC at all? What I mean is that in most cases it's the components/peripherals/IPs (whatever you call them) matter, not the SoC itself, so the SoC compatible value can be unique if you wish (and, if it is a *.dtsi, it will be compatbile with simple-bus anyway ;-). Then the IP nodes can follow the rule above. Sure, I don't mean the top-level root compatibility, I mean device compatibility. Thanks Guennadi Hope it makes some sense? Pawel --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 00/12] Remove platform callbacks from mmc_spi, sh_mmcif and sh_mobile_sdhi drivers
Hi Laurent On Fri, 26 Jul 2013, Laurent Pinchart wrote: Hello, This patch set replaces callbacks to board code with regulators and GPIOs in the mmc_spi, sh_mmcif and sh_mobile_sdhi MMC drivers. Most of the required infrastructure is in place already on the drivers side, except for CD/RO GPIOs support in the mmc_spi driver. The series thus starts with patch 01/12 that adds this feature to the mmc_spi driver. Patches 02/12 to 05/12 remove the board callbacks from the ecovec24 and vision_ep9307 boards. The code has been compile-tested only as I don't have access to those boards. Patches 06/12 to 07/12 then proceed to remove the callbacks from the drivers themselves and from the platform data structures. This will be a bit messy to merge, as the series interleaves patches for drivers and board files. Given that the mmc_spi driver is marked as orphan in MAINTAINERS and that the vision_ep9307 hasn't seen any board-specific modification in the last couple of kernel versions one option would be to merge all patches (or at least patches 01/12 to 06/12) through Simon's tree if all involved maintainers agree. The series is based on tag renesas-devel-20130725 from git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git Laurent Pinchart (12): mmc: mmc_spi: Support CD/RO GPIOs ARM: ep93xx: vision_ep9307: Use MMC CD and RO GPIO sh: ecovec24: Use MMC/SDHI CD and RO GPIO sh: ecovec24: Remove mmcif .down_pwr() callback sh: ecovec24: Remove MMCIF and SDHI .set_pwr() callbacks mmc: mmc_spi: Remove platform data .get_cd() and .get_ro() callbacks mmc: sh_mmcif: Remove .down_pwr() callback from platform data mmc: sh_mmcif: Remove .set_pwr() callback from platform data mmc: sh_mobile_sdhi: Remove .get_cd() callback from platform data mmc: sh_mobile_sdhi: Remove .set_pwr() callback from platform data mmc: tmio-mmc: Remove .get_cd() callback from platform data mmc: tmio-mmc: Remove .set_pwr() callback from platform data For #3-5, 7-12 Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Thanks Guennadi arch/arm/mach-ep93xx/vision_ep9307.c | 56 ++- arch/sh/boards/mach-ecovec24/setup.c | 89 drivers/mmc/host/mmc_spi.c | 48 +-- drivers/mmc/host/of_mmc_spi.c| 46 +-- drivers/mmc/host/sh_mmcif.c | 3 -- drivers/mmc/host/sh_mobile_sdhi.c| 18 drivers/mmc/host/tmio_mmc.h | 1 - drivers/mmc/host/tmio_mmc_pio.c | 23 +- include/linux/mfd/tmio.h | 2 - include/linux/mmc/sh_mmcif.h | 2 - include/linux/mmc/sh_mobile_sdhi.h | 2 - include/linux/spi/mmc_spi.h | 18 12 files changed, 56 insertions(+), 252 deletions(-) -- Regards, Laurent Pinchart --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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/2] mmc: add Device Tree properties for UHS modes
Add DT properties for UHS SDR12, SDR25, SDR50, SDR104 and DDR50 modes and for supported by the host in DDR mode VccQ values. Adding them to DT will automatically enable respective MMC host capabilities. Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com --- Documentation/devicetree/bindings/mmc/mmc.txt |7 +++ drivers/mmc/core/host.c | 14 ++ 2 files changed, 21 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 458b57f..de4a716 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -29,6 +29,13 @@ Optional properties: - cap-power-off-card: powering off the card is safe - cap-sdio-irq: enable SDIO IRQ signalling on this interface - full-pwr-cycle: full power cycle of the card is supported +- uhs-sdr12: the host supports UHS SDR12 mode +- uhs-sdr25: the host supports UHS SDR25 mode +- uhs-sdr50: the host supports UHS SDR50 mode +- uhs-sdr104: the host supports UHS SDR104 mode +- uhs-ddr50: the host supports UHS DDR50 mode +- ddr-1v2: the host can support DDR, using 1.2V VccQ +- ddr-1v8: the host can support DDR, using 1.8V VccQ *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line polarity properties, we have to fix the meaning of the normal and inverted diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c index 6fb6f77..e12fba0 100644 --- a/drivers/mmc/core/host.c +++ b/drivers/mmc/core/host.c @@ -423,6 +423,20 @@ int mmc_of_parse(struct mmc_host *host) host-caps |= MMC_CAP_POWER_OFF_CARD; if (of_find_property(np, cap-sdio-irq, len)) host-caps |= MMC_CAP_SDIO_IRQ; + if (of_find_property(np, uhs-sdr12, len)) + host-caps |= MMC_CAP_UHS_SDR12; + if (of_find_property(np, uhs-sdr25, len)) + host-caps |= MMC_CAP_UHS_SDR25; + if (of_find_property(np, uhs-sdr50, len)) + host-caps |= MMC_CAP_UHS_SDR50; + if (of_find_property(np, uhs-sdr104, len)) + host-caps |= MMC_CAP_UHS_SDR104; + if (of_find_property(np, uhs-ddr50, len)) + host-caps |= MMC_CAP_UHS_DDR50; + if (of_find_property(np, ddr-1v2, len)) + host-caps |= MMC_CAP_1_2V_DDR; + if (of_find_property(np, ddr-1v8, len)) + host-caps |= MMC_CAP_1_8V_DDR; if (of_find_property(np, full-pwr-cycle, len)) host-caps2 |= MMC_CAP2_FULL_PWR_CYCLE; if (of_find_property(np, keep-power-in-suspend, len)) -- 1.7.2.5 -- 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/RFC 2/2] ARM: shmobile: kzm9g: support DDR50 mode with 1.8V VccQ on MMCIF
MMCIF on sh73a0 supports the UHS DDR50 mode and on the kzm9g board it can be used with MMC VccQ = 1.8V. This patch enables them. Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com --- This patch is correct AFAICS, but pointless on kzm9g, because (at least on my board) th eMMC chip, installed on the board and connected to MMCIF doesn't support DDR, so, it cannot be enabled. This patch is therefore more of an example how these flags shall be used, than a real use case. If it is decided to apply it, it can be applied even before patch 1/2, it just won't have any effect at all. arch/arm/boot/dts/sh73a0-kzm9g-reference.dts |1 + arch/arm/boot/dts/sh73a0.dtsi|1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts index b99e890..d90de01 100644 --- a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts +++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts @@ -191,6 +191,7 @@ bus-width = 8; vmmc-supply = reg_1p8v; + ddr-1v8; status = okay; }; diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi index 86e79fe..1146be8 100644 --- a/arch/arm/boot/dts/sh73a0.dtsi +++ b/arch/arm/boot/dts/sh73a0.dtsi @@ -186,6 +186,7 @@ interrupts = 0 140 0x4 0 141 0x4; reg-io-width = 4; + uhs-ddr50; status = disabled; }; -- 1.7.2.5 -- 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/2] mmc: add Device Tree properties for UHS modes
Hi Stephen On Fri, 26 Jul 2013, Stephen Warren wrote: On 07/26/2013 09:51 AM, Guennadi Liakhovetski wrote: Add DT properties for UHS SDR12, SDR25, SDR50, SDR104 and DDR50 modes and for supported by the host in DDR mode VccQ values. Adding them to DT will automatically enable respective MMC host capabilities. diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt +- uhs-sdr12: the host supports UHS SDR12 mode +- uhs-sdr25: the host supports UHS SDR25 mode +- uhs-sdr50: the host supports UHS SDR50 mode +- uhs-sdr104: the host supports UHS SDR104 mode +- uhs-ddr50: the host supports UHS DDR50 mode +- ddr-1v2: the host can support DDR, using 1.2V VccQ +- ddr-1v8: the host can support DDR, using 1.8V VccQ Surely the driver for the host controller already knows this, so there's no need to represent it in DT? Not necessarily. One driver can handle several versions of the same chip, and some versions of the chip implement some of those features, others don't. So, your choice is really whether to specify a chip version in the compatible string or these properties. Now, when you consider that multiple drivers have to decide upon those, and sometimes you don't have an exact IP version of the SD/MMC controller but only the SoC version, you choice becomes: either _standard_ _common_ properties as above, or compatibility strings virtually in each driver for each SoC version. That's why I decided to use explicit properties for those. Example: sh_mmcif driver supports MMCIF IP blocks on various Renesas sh-, r-mobile and r-car SuperH and ARM SoCs. On some of them DDR50 is supported, on others it isn't. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 6/6] ARM: shmobile: lager: disable MMCIF Command Completion Signal, add CLK_CTRL2
MMCIF on r8a7790 doesn't support Command Completion Signal, but it does
implement a CE_CLK_CTRL2 register. Platform parameters have to be added to
account for these features on lager.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
arch/arm/mach-shmobile/board-lager.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-lager.c
b/arch/arm/mach-shmobile/board-lager.c
index 3c67b2a..9b3085f 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -84,6 +84,8 @@ static struct regulator_consumer_supply
fixed3v3_power_consumers[] =
/* MMCIF */
static struct sh_mmcif_plat_data mmcif1_pdata = {
.caps = MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE,
+ .clk_ctrl2_present = true,
+ .ccs_unsupported = true,
};
static struct resource mmcif1_resources[] = {
--
1.7.2.5
--
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 0/6] mmc: sh_mmcif: revision-specific CCS and CLK_CTRL2 handling
This patch series adds version-specific support for Command Completion Signal and the CE_CLK_CTRL2 register. Presumably, the first two patches will go via the MMC tree, the rest should be applied after them. Cc: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com Guennadi Liakhovetski (6): mmc: sh_mmcif: revision-specific Command Completion Signal handling mmc: sh_mmcif: revision-specific CLK_CTRL2 handling ARM: shmobile: armadillo800eva: disable MMCIF Command Completion Signal ARM: shmobile: kzm9g: disable MMCIF Command Completion Signal ARM: shmobile: ape6evm: disable MMCIF Command Completion Signal ARM: shmobile: lager: disable MMCIF Command Completion Signal, add CLK_CTRL2 arch/arm/mach-shmobile/board-ape6evm.c |1 + arch/arm/mach-shmobile/board-armadillo800eva.c |1 + arch/arm/mach-shmobile/board-kzm9g.c |1 + arch/arm/mach-shmobile/board-lager.c |2 + drivers/mmc/host/sh_mmcif.c| 31 +++ include/linux/mmc/sh_mmcif.h |3 ++ 6 files changed, 33 insertions(+), 6 deletions(-) -- 1.7.2.5 Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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/6] mmc: sh_mmcif: revision-specific CLK_CTRL2 handling
Some newer MMCIF IP revisions contain a CE_CLK_CTRL2 register, that has to
be set for proper operation. Support for this feature is added in a way to
preserve the current behaviour by default, i.e. when it is not enabled
in platform data. Patch is based on work by Nobuyuki HIRAI.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
drivers/mmc/host/sh_mmcif.c |4
include/linux/mmc/sh_mmcif.h |2 ++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 7be20c9..dc3ce52 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -246,6 +246,7 @@ struct sh_mmcif_host {
bool power;
bool card_present;
bool ccs_enable;/* Command Completion Signal support */
+ bool clk_ctrl2_enable;
struct mutex thread_lock;
/* DMA support */
@@ -490,6 +491,8 @@ static void sh_mmcif_sync_reset(struct sh_mmcif_host *host)
sh_mmcif_writel(host-addr, MMCIF_CE_VERSION, SOFT_RST_OFF);
if (host-ccs_enable)
tmp |= SCCSTO_29;
+ if (host-clk_ctrl2_enable)
+ sh_mmcif_writel(host-addr, MMCIF_CE_CLK_CTRL2, 0x0F0F);
sh_mmcif_bitset(host, MMCIF_CE_CLK_CTRL, tmp |
SRSPTO_256 | SRBSYTO_29 | SRWDTO_29);
/* byte swap on */
@@ -1390,6 +1393,7 @@ static int sh_mmcif_probe(struct platform_device *pdev)
host-addr = reg;
host-timeout = msecs_to_jiffies(1000);
host-ccs_enable = !pd || !pd-ccs_unsupported;
+ host-clk_ctrl2_enable = pd pd-clk_ctrl2_present;
host-pd = pdev;
diff --git a/include/linux/mmc/sh_mmcif.h b/include/linux/mmc/sh_mmcif.h
index b2a22b6..d4277d9 100644
--- a/include/linux/mmc/sh_mmcif.h
+++ b/include/linux/mmc/sh_mmcif.h
@@ -40,6 +40,7 @@ struct sh_mmcif_plat_data {
unsigned intslave_id_rx;
booluse_cd_gpio : 1;
boolccs_unsupported : 1;
+ boolclk_ctrl2_present : 1;
unsigned intcd_gpio;
u8 sup_pclk; /* 1 :SH7757, 0: SH7724/SH7372
*/
unsigned long caps;
@@ -63,6 +64,7 @@ struct sh_mmcif_plat_data {
#define MMCIF_CE_INT_MASK 0x0044
#define MMCIF_CE_HOST_STS1 0x0048
#define MMCIF_CE_HOST_STS2 0x004C
+#define MMCIF_CE_CLK_CTRL2 0x0070
#define MMCIF_CE_VERSION 0x007C
/* CE_BUF_ACC */
--
1.7.2.5
--
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/6] ARM: shmobile: kzm9g: disable MMCIF Command Completion Signal
MMCIF on sh73a0 doesn't support Command Completion Signal, a platform
parameter has to be added to disable it on kzm9g.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
arch/arm/mach-shmobile/board-kzm9g.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-kzm9g.c
b/arch/arm/mach-shmobile/board-kzm9g.c
index 165483c..7ec26a5 100644
--- a/arch/arm/mach-shmobile/board-kzm9g.c
+++ b/arch/arm/mach-shmobile/board-kzm9g.c
@@ -365,6 +365,7 @@ static struct resource sh_mmcif_resources[] = {
static struct sh_mmcif_plat_data sh_mmcif_platdata = {
.ocr= MMC_VDD_165_195,
.caps = MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE,
+ .ccs_unsupported = true,
.slave_id_tx= SHDMA_SLAVE_MMCIF_TX,
.slave_id_rx= SHDMA_SLAVE_MMCIF_RX,
};
--
1.7.2.5
--
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/6] mmc: sh_mmcif: revision-specific Command Completion Signal handling
Some earlier MMCIF IP revisions contained Command Completion Signal
support, which has been dropped again in modern versions. Sopport for
this feature is added in a way to preserve the current behaviour by
default, i.e. when it is not enabled in platform data. Patch is based
on work by Nobuyuki HIRAI.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
drivers/mmc/host/sh_mmcif.c | 27 +--
include/linux/mmc/sh_mmcif.h |1 +
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 06caaae..7be20c9 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -133,6 +133,8 @@
INT_BUFWEN | INT_CMD12DRE | INT_BUFRE | \
INT_DTRANE | INT_CMD12RBE | INT_CMD12CRE)
+#define INT_CCS(INT_CCSTO | INT_CCSRCV | INT_CCSDE)
+
/* CE_INT_MASK */
#define MASK_ALL 0x
#define MASK_MCCSDE(1 29)
@@ -161,7 +163,7 @@
#define MASK_START_CMD (MASK_MCMDVIO | MASK_MBUFVIO | MASK_MWDATERR | \
MASK_MRDATERR | MASK_MRIDXERR | MASK_MRSPERR |
\
-MASK_MCCSTO | MASK_MCRCSTO | MASK_MWDATTO | \
+MASK_MCRCSTO | MASK_MWDATTO | \
MASK_MRDATTO | MASK_MRBSYTO | MASK_MRSPTO)
#define MASK_CLEAN (INT_ERR_STS | MASK_MRBSYE | MASK_MCRSPE |
\
@@ -243,6 +245,7 @@ struct sh_mmcif_host {
int sg_blkidx;
bool power;
bool card_present;
+ bool ccs_enable;/* Command Completion Signal support */
struct mutex thread_lock;
/* DMA support */
@@ -485,8 +488,10 @@ static void sh_mmcif_sync_reset(struct sh_mmcif_host *host)
sh_mmcif_writel(host-addr, MMCIF_CE_VERSION, SOFT_RST_ON);
sh_mmcif_writel(host-addr, MMCIF_CE_VERSION, SOFT_RST_OFF);
+ if (host-ccs_enable)
+ tmp |= SCCSTO_29;
sh_mmcif_bitset(host, MMCIF_CE_CLK_CTRL, tmp |
- SRSPTO_256 | SRBSYTO_29 | SRWDTO_29 | SCCSTO_29);
+ SRSPTO_256 | SRBSYTO_29 | SRWDTO_29);
/* byte swap on */
sh_mmcif_bitset(host, MMCIF_CE_BUF_ACC, BUF_ACC_ATYP);
}
@@ -866,6 +871,9 @@ static void sh_mmcif_start_cmd(struct sh_mmcif_host *host,
break;
}
+ if (host-ccs_enable)
+ mask |= MASK_MCCSTO;
+
if (mrq-data) {
sh_mmcif_writel(host-addr, MMCIF_CE_BLOCK_SET, 0);
sh_mmcif_writel(host-addr, MMCIF_CE_BLOCK_SET,
@@ -873,7 +881,10 @@ static void sh_mmcif_start_cmd(struct sh_mmcif_host *host,
}
opc = sh_mmcif_set_cmd(host, mrq);
- sh_mmcif_writel(host-addr, MMCIF_CE_INT, 0xD80430C0);
+ if (host-ccs_enable)
+ sh_mmcif_writel(host-addr, MMCIF_CE_INT, 0xD80430C0);
+ else
+ sh_mmcif_writel(host-addr, MMCIF_CE_INT, 0xD80430C0 | INT_CCS);
sh_mmcif_writel(host-addr, MMCIF_CE_INT_MASK, mask);
/* set arg */
sh_mmcif_writel(host-addr, MMCIF_CE_ARG, cmd-arg);
@@ -1241,11 +1252,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
static irqreturn_t sh_mmcif_intr(int irq, void *dev_id)
{
struct sh_mmcif_host *host = dev_id;
- u32 state;
+ u32 state, mask;
state = sh_mmcif_readl(host-addr, MMCIF_CE_INT);
- sh_mmcif_writel(host-addr, MMCIF_CE_INT,
- ~(state sh_mmcif_readl(host-addr,
MMCIF_CE_INT_MASK)));
+ mask = sh_mmcif_readl(host-addr, MMCIF_CE_INT_MASK);
+ if (host-ccs_enable)
+ sh_mmcif_writel(host-addr, MMCIF_CE_INT, ~(state mask));
+ else
+ sh_mmcif_writel(host-addr, MMCIF_CE_INT, INT_CCS | ~(state
mask));
sh_mmcif_bitclr(host, MMCIF_CE_INT_MASK, state MASK_CLEAN);
if (state ~MASK_CLEAN)
@@ -1375,6 +1389,7 @@ static int sh_mmcif_probe(struct platform_device *pdev)
host-mmc = mmc;
host-addr = reg;
host-timeout = msecs_to_jiffies(1000);
+ host-ccs_enable = !pd || !pd-ccs_unsupported;
host-pd = pdev;
diff --git a/include/linux/mmc/sh_mmcif.h b/include/linux/mmc/sh_mmcif.h
index e7d5dd6..b2a22b6 100644
--- a/include/linux/mmc/sh_mmcif.h
+++ b/include/linux/mmc/sh_mmcif.h
@@ -39,6 +39,7 @@ struct sh_mmcif_plat_data {
unsigned intslave_id_tx;/* embedded slave_id_[tr]x */
unsigned intslave_id_rx;
booluse_cd_gpio : 1;
+ boolccs_unsupported : 1;
unsigned intcd_gpio;
u8 sup_pclk; /* 1 :SH7757, 0: SH7724/SH7372
*/
unsigned long caps;
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord
[PATCH 5/6] ARM: shmobile: ape6evm: disable MMCIF Command Completion Signal
MMCIF on r8a73a4 doesn't support Command Completion Signal, a platform
parameter has to be added to disable it on ape6evm.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
arch/arm/mach-shmobile/board-ape6evm.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-ape6evm.c
b/arch/arm/mach-shmobile/board-ape6evm.c
index e9e2108e..96a6994 100644
--- a/arch/arm/mach-shmobile/board-ape6evm.c
+++ b/arch/arm/mach-shmobile/board-ape6evm.c
@@ -77,6 +77,7 @@ static struct sh_mmcif_plat_data mmcif0_pdata = {
.caps = MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE,
.slave_id_tx= SHDMA_SLAVE_MMCIF0_TX,
.slave_id_rx= SHDMA_SLAVE_MMCIF0_RX,
+ .ccs_unsupported = true,
};
static struct resource mmcif0_resources[] = {
--
1.7.2.5
--
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 v4 5/7] mmc: SDHI: add DT compatibility strings for further SoCs
Add further OF compatibility strings to the SDHI driver to be able to
precisely control driver's behaviour on each of them.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
v4:
1. added r8a7778 and r8a7779 per Morimoto-san's request
2. sh* and r8a* entries now sorted alphabetically
drivers/mmc/host/sh_mobile_sdhi.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_mobile_sdhi.c
index cc4c872..dc4f0e0 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -129,7 +129,12 @@ static const struct sh_mobile_sdhi_ops sdhi_ops = {
static const struct of_device_id sh_mobile_sdhi_of_match[] = {
{ .compatible = renesas,shmobile-sdhi },
{ .compatible = renesas,sh7372-sdhi },
+ { .compatible = renesas,sh73a0-sdhi, .data =
sh_mobile_sdhi_of_cfg[0], },
+ { .compatible = renesas,r8a73a4-sdhi, .data =
sh_mobile_sdhi_of_cfg[0], },
{ .compatible = renesas,r8a7740-sdhi, .data =
sh_mobile_sdhi_of_cfg[0], },
+ { .compatible = renesas,r8a7778-sdhi, .data =
sh_mobile_sdhi_of_cfg[0], },
+ { .compatible = renesas,r8a7779-sdhi, .data =
sh_mobile_sdhi_of_cfg[0], },
+ { .compatible = renesas,r8a7790-sdhi, .data =
sh_mobile_sdhi_of_cfg[0], },
{},
};
MODULE_DEVICE_TABLE(of, sh_mobile_sdhi_of_match);
--
1.7.2.5
--
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] mmc: TMIO: update Device Tree binding documentation
The SDHI mmc-tmio implementation has been updated to cover additional SoC types. This patch documents the changes. Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com --- Now, that the patch mmc: SDHI: add DT compatibility strings for further SoCs has been approved, it shall be accompanied by this documentation update. Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 13 + 1 files changed, 9 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt index df204e1..ec6f5bd 100644 --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt @@ -13,8 +13,13 @@ Optional properties: - toshiba,mmc-wrprotect-disable: write-protect detection is unavailable When used with Renesas SDHI hardware, the following compatibility strings -configure various model-specific properties: +configure properties, specific to the respective SoC model: -renesas,sh7372-sdhi: (default) compatible with SH7372 -renesas,r8a7740-sdhi:compatible with R8A7740: certain MMC/SD commands have to - wait for the interface to become idle. +renesas,shmobile-sdhi: generic SDHI block +renesas,sh7372-sdhi: SDHI block, used on SH7372 (SH-Mobile AP4) +renesas,sh73a0-sdhi: SDHI block, used on SH73A0 (SH-Mobile AG5) +renesas,r8a73a4-sdhi:SDHI block, used on R8A73A4 (R-Mobile APE6) +renesas,r8a7740-sdhi:SDHI block, used on R8A7740 (R-Mobile A1) +renesas,r8a7778-sdhi:SDHI block, used on R8A7778 (R-Car M1A) +renesas,r8a7779-sdhi:SDHI block, used on R8A7779 (R-Car H1) +renesas,r8a7790-sdhi:SDHI block, used on R8A7790 (R-Car H2) -- 1.7.2.5 -- 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] mmc: tmio: fix compiler warning
This patch fixes a compiler warning:
drivers/mmc/host/tmio_mmc_pio.c: In function 'tmio_mmc_power_on':
drivers/mmc/host/tmio_mmc_pio.c:798:19: warning: ignoring return value of
'regulator_enable', declared with attribute warn_unused_result [-Wunused-result]
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
This warning is present in next and in 3.10, but since it doesn't affect
functionality, I don't think it's needed for stable.
drivers/mmc/host/tmio_mmc_pio.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index f294708..84e1888 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -795,9 +795,13 @@ static void tmio_mmc_power_on(struct tmio_mmc_host *host,
unsigned short vdd)
* omap_hsmmc.c driver does.
*/
if (!IS_ERR(mmc-supply.vqmmc) !ret) {
- regulator_enable(mmc-supply.vqmmc);
+ ret = regulator_enable(mmc-supply.vqmmc);
udelay(200);
}
+
+ if (ret 0)
+ dev_dbg(host-pdev-dev, Regulators failed to power up: %d\n,
+ ret);
}
static void tmio_mmc_power_off(struct tmio_mmc_host *host)
--
1.7.2.5
--
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 v3 5/7] mmc: SDHI: add DT compatibility strings for further SoCs
Add further OF compatibility strings to the SDHI driver to be able to
precisely control driver's behaviour on each of them.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
Cc: linux-mmc@vger.kernel.org
Cc: Chris Ball c...@laptop.org
---
As explained in patch 0/7, this patch can be pushed separately via the
mmc git-tree.
drivers/mmc/host/sh_mobile_sdhi.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_mobile_sdhi.c
index cc4c872..b58c1a9 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -130,6 +130,9 @@ static const struct of_device_id sh_mobile_sdhi_of_match[]
= {
{ .compatible = renesas,shmobile-sdhi },
{ .compatible = renesas,sh7372-sdhi },
{ .compatible = renesas,r8a7740-sdhi, .data =
sh_mobile_sdhi_of_cfg[0], },
+ { .compatible = renesas,sh73a0-sdhi, .data =
sh_mobile_sdhi_of_cfg[0], },
+ { .compatible = renesas,r8a73a4-sdhi, .data =
sh_mobile_sdhi_of_cfg[0], },
+ { .compatible = renesas,r8a7790-sdhi, .data =
sh_mobile_sdhi_of_cfg[0], },
{},
};
MODULE_DEVICE_TABLE(of, sh_mobile_sdhi_of_match);
--
1.7.2.5
--
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 v3 0/7] ARM: shmobile: DMAC, MMCIF and SDHI for H2 and APE6
These patches add support for DMA, MMCIF and SDHI controllers to non-DT APE6EVM and Lager board implementations, and MMCIF and SDHI DT templates for APE6 and H2 SoCs. A note concerning SDHI OF compatibility strings. Patch 5 of this series adds OF compatibility strings for sh73a0, r8a73a4, r8a7790 to make it possible to use correct SoC names instead of a supposedly compatible one. Patches 6 and 7 then use those names in SDHI DT templates on r8a73a4 and r8a7790. This doesn't directly impose a commit order dependency, since those templates are added in a disabled state. Therefore these patches can be pushed upstream via different git-trees. Only when specific boards enable SDHI interfaces in their .dts files, only then will it be important to have both respective patches in the kernel: the drivers/mmc patch and the respective SoC .dtsi patch. It is therefore proposed to push these patches to 3.12 and to begin enabling SDHI interfaces in respective board .dtsi files from 3.13. Also note, that sh73a0 is already using renesas,r8a7740-sdhi compatibility in its .dtsi. After patch 5 this still will work, but it also will become possible to use a more obvious renesas,sh73a0-sdhi OF compatibility string. Developed and tested on top of Simon's renesas.git next snapshot of 08.07.2013. Cc: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com Cc: linux-mmc@vger.kernel.org Cc: Chris Ball c...@laptop.org Guennadi Liakhovetski (7): ARM: shmobile: r8a73a4: add a DMAC platform device and clock for it ARM: shmobile: ape6evm: add MMCIF support ARM: shmobile: ape6evm: add SDHI interfaces ARM: shmobile: lager: add MMCIF support mmc: SDHI: add DT compatibility strings for further SoCs ARM: shmobile: r8a73a4: add MMCIF and SDHI DT templates ARM: shmobile: r8a7790: add MMCIF and SDHI DT templates arch/arm/boot/dts/r8a73a4.dtsi| 45 arch/arm/boot/dts/r8a7790.dtsi| 54 +++ arch/arm/mach-shmobile/board-ape6evm.c| 81 ++ arch/arm/mach-shmobile/board-lager.c | 31 + arch/arm/mach-shmobile/clock-r8a73a4.c|4 +- arch/arm/mach-shmobile/include/mach/r8a73a4.h |9 +++ arch/arm/mach-shmobile/setup-r8a73a4.c| 90 + drivers/mmc/host/sh_mobile_sdhi.c |3 + 8 files changed, 316 insertions(+), 1 deletions(-) -- 1.7.2.5 Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 v2] mmc: sh_mmcif: add support for Device Tree DMA bindings
Hi Chris
What's the plan about this patch? Do you think you'd be able to push it
for 3.11 or rather 3.12?
Thanks
Guennadi
On Mon, 24 Jun 2013, Guennadi Liakhovetski wrote:
To use DMA in the Device Tree case the driver has to be modified
to use suitable API to obtain DMA channels.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
v2: use an else if
drivers/mmc/host/sh_mmcif.c | 26 --
1 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index ba76a53..4fff404 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -386,25 +386,29 @@ static void sh_mmcif_request_dma(struct sh_mmcif_host
*host,
host-dma_active = false;
- if (!pdata)
- return;
-
- if (pdata-slave_id_tx = 0 || pdata-slave_id_rx = 0)
+ if (pdata) {
+ if (pdata-slave_id_tx = 0 || pdata-slave_id_rx = 0)
+ return;
+ } else if (!host-pd-dev.of_node) {
return;
+ }
/* We can only either use DMA for both Tx and Rx or not use it at all */
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- host-chan_tx = dma_request_channel(mask, shdma_chan_filter,
- (void *)pdata-slave_id_tx);
+ host-chan_tx = dma_request_slave_channel_compat(mask,
shdma_chan_filter,
+ pdata ? (void *)pdata-slave_id_tx : NULL,
+ host-pd-dev, tx);
dev_dbg(host-pd-dev, %s: TX: got channel %p\n, __func__,
host-chan_tx);
if (!host-chan_tx)
return;
- cfg.slave_id = pdata-slave_id_tx;
+ /* In the OF case the driver will get the slave ID from the DT */
+ if (pdata)
+ cfg.slave_id = pdata-slave_id_tx;
cfg.direction = DMA_MEM_TO_DEV;
cfg.dst_addr = res-start + MMCIF_CE_DATA;
cfg.src_addr = 0;
@@ -412,15 +416,17 @@ static void sh_mmcif_request_dma(struct sh_mmcif_host
*host,
if (ret 0)
goto ecfgtx;
- host-chan_rx = dma_request_channel(mask, shdma_chan_filter,
- (void *)pdata-slave_id_rx);
+ host-chan_rx = dma_request_slave_channel_compat(mask,
shdma_chan_filter,
+ pdata ? (void *)pdata-slave_id_rx : NULL,
+ host-pd-dev, rx);
dev_dbg(host-pd-dev, %s: RX: got channel %p\n, __func__,
host-chan_rx);
if (!host-chan_rx)
goto erqrx;
- cfg.slave_id = pdata-slave_id_rx;
+ if (pdata)
+ cfg.slave_id = pdata-slave_id_rx;
cfg.direction = DMA_DEV_TO_MEM;
cfg.dst_addr = 0;
cfg.src_addr = res-start + MMCIF_CE_DATA;
--
1.7.2.5
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 v2] mmc: sh_mmcif: add SET_BLOCK_COUNT support
)) {
+ /* Wait for end of data phase */
+ host-wait_for = MMCIF_WAIT_FOR_WRITE_END;
+ sh_mmcif_bitset(host, MMCIF_CE_INT_MASK, MASK_MDTRANE);
+ schedule_delayed_work(host-timeout_work, host-timeout);
+ mutex_unlock(host-thread_lock);
+ return IRQ_HANDLED;
+ }
+
+ if (mrq-sbc (mrq-cmd-opcode == MMC_READ_MULTIPLE_BLOCK)
+ (host-wait_for != MMCIF_WAIT_FOR_READ_END)) {
+ /* Wait for end of data phase */
+ host-wait_for = MMCIF_WAIT_FOR_READ_END;
+ sh_mmcif_bitset(host, MMCIF_CE_INT_MASK, MASK_MBUFRE);
+ schedule_delayed_work(host-timeout_work, host-timeout);
+ mutex_unlock(host-thread_lock);
+ return IRQ_HANDLED;
+ }
Hm, this is interesting. Why do you need those? Currently we only wait for
read- and write-end conditions in single-block read- and write-operations,
but not in multi-block ones. With SBC you also want to wait for them in
the multi-block case. Is it really SBC-specific or maybe we have to do
this always? In either case I wouldn't add it here but to respective
state-handlers, called from the switch statement above. And if this is
indeed needed for all multi-block operations, this should be a separate
patch.
+
if (host-wait_for != MMCIF_WAIT_FOR_STOP) {
Currently you enter this path also after processing an SBC, which isn't
needed, but just happens to be harmless. If you use MMCIF_WAIT_FOR_SBC you
don't get here at all.
struct mmc_data *data = mrq-data;
if (!mrq-cmd-error data !data-error)
data-bytes_xfered =
data-blocks * data-blksz;
- if (mrq-stop !mrq-cmd-error (!data || !data-error)) {
+ /* If SBC, we don't use CMD12(STOP) */
+ if (mrq-stop !mrq-cmd-error (!data || !data-error)
+ !mrq-sbc) {
sh_mmcif_stop_cmd(host, mrq);
if (!mrq-stop-error) {
schedule_delayed_work(host-timeout_work,
host-timeout);
@@ -1228,6 +1274,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
}
}
+ if ((mrq-cmd-opcode == MMC_SET_BLOCK_COUNT) !mrq-cmd-error) {
This won't be needed.
+ /* Send the original .request() command */
+ host-mrq = host-mrq_orig;
+ sh_mmcif_start_cmd(host, host-mrq);
+ mutex_unlock(host-thread_lock);
+ return IRQ_HANDLED;
+ }
+
host-wait_for = MMCIF_WAIT_FOR_REQUEST;
host-state = STATE_IDLE;
host-mrq = NULL;
--
1.7.1
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: sh_mmcif: add SET_BLOCK_COUNT support
-timeout_work, host-timeout);
+ mutex_unlock(host-thread_lock);
+ return IRQ_HANDLED;
+ }
+
+ if (mrq-sbc (mrq-cmd-opcode == MMC_READ_MULTIPLE_BLOCK)
+ (host-wait_for != MMCIF_WAIT_FOR_READ_END)) {
+ /* Wait for end of data phase */
+ host-wait_for = MMCIF_WAIT_FOR_READ_END;
+ sh_mmcif_bitset(host, MMCIF_CE_INT_MASK, MASK_MBUFRE);
+ schedule_delayed_work(host-timeout_work, host-timeout);
+ mutex_unlock(host-thread_lock);
+ return IRQ_HANDLED;
+ }
+
if (host-wait_for != MMCIF_WAIT_FOR_STOP) {
struct mmc_data *data = mrq-data;
if (!mrq-cmd-error data !data-error)
data-bytes_xfered =
data-blocks * data-blksz;
- if (mrq-stop !mrq-cmd-error (!data || !data-error)) {
+ /* If SBC, we don't use CMD12(STOP) */
+ if (mrq-stop !mrq-cmd-error (!data || !data-error)
+ !mrq-sbc) {
sh_mmcif_stop_cmd(host, mrq);
if (!mrq-stop-error) {
schedule_delayed_work(host-timeout_work,
host-timeout);
@@ -1228,6 +1300,12 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
}
}
+ if ((mrq-cmd-opcode == MMC_SET_BLOCK_COUNT) !mrq-cmd-error) {
+ schedule_delayed_work(host-timeout_work, host-timeout);
+ mutex_unlock(host-thread_lock);
+ return IRQ_HANDLED;
+ }
+
host-wait_for = MMCIF_WAIT_FOR_REQUEST;
host-state = STATE_IDLE;
host-mrq = NULL;
@@ -1379,6 +1457,7 @@ static int sh_mmcif_probe(struct platform_device *pdev)
host-pd = pdev;
spin_lock_init(host-lock);
+ init_completion(host-sbc_complete);
mmc-ops = sh_mmcif_ops;
sh_mmcif_init_ocr(host);
--
1.7.1
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: tmio: postpone controller reset during resume
Hi Chris
On Mon, 22 Apr 2013, Guennadi Liakhovetski wrote:
When resuming, the tmio_mmc_host_resume() function is run when the
controller might still be powered down. Issuing a reset command to it at
that time has no effect. This patch postpones resetting the controller
until the first powering-up .set_ios() call.
Reported-by: Nguyen Viet Dung nv-d...@jinso.co.jp
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
Any reason why this hasn't been applied yet? Please, push for 3.10.
Thanks
Guennadi
---
There is some risk associated with this patch: it removes unconditional
(attempt of) controller reset from the tmio_mmc_host_resume() function.
AFAICS, this shouldn't have any negative effects. There _should_ always be
a powering-up .set_ios() call after a resume. However, if anyone sees any
(potential) problems with it, please, let me know.
drivers/mmc/host/tmio_mmc.h |1 +
drivers/mmc/host/tmio_mmc_pio.c |6 +-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index d857f5c..759d8f4 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -85,6 +85,7 @@ struct tmio_mmc_host {
unsigned long last_req_ts;
struct mutexios_lock; /* protect set_ios() context */
boolnative_hotplug;
+ boolresuming;
};
int tmio_mmc_host_probe(struct tmio_mmc_host **host,
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index f508ecb..435cc4d 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -862,6 +862,10 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
if (!host-power) {
tmio_mmc_clk_update(mmc);
pm_runtime_get_sync(dev);
+ if (host-resuming) {
+ tmio_mmc_reset(host);
+ host-resuming = false;
+ }
}
tmio_mmc_set_clock(host, ios-clock);
if (!host-power) {
@@ -1154,10 +1158,10 @@ int tmio_mmc_host_resume(struct device *dev)
struct mmc_host *mmc = dev_get_drvdata(dev);
struct tmio_mmc_host *host = mmc_priv(mmc);
- tmio_mmc_reset(host);
tmio_mmc_enable_dma(host, true);
/* The MMC core will perform the complete set up */
+ host-resuming = true;
return mmc_resume_host(mmc);
}
EXPORT_SYMBOL(tmio_mmc_host_resume);
--
1.7.2.5
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 v2] MMC: tmio: fix unbalanced power-on calls with clock-gating enabled
Hi Chris
On Tue, 23 Apr 2013, Guennadi Liakhovetski wrote:
With MMC clock gating enabled the MMC core currently calls MMC host driver's
.set_ios() method with .power_mode == MMC_POWER_ON and the clock value set
either to 0 or to the target rate. The tmio MMC driver then wrongly
translates the latter calls to card slot power-on requests, even when the
slot already was on. This patch fixes the driver to avoid needlessly
incrementing power-supplying regulator's use count.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
Can we get this one into 3.10?
Thanks
Guennadi
---
v2: Also make runtime PM handling safer and more resistant to possible
MMC core changes. V1 worked fine too, but theoretically if the core
decided to issue a sequence like
.set_ios(ios-power_mode == MMC_POWER_ON, ios-clock != 0);
.set_ios(ios-power_mode == MMC_POWER_ON, ios-clock == 0);
.set_ios(ios-power_mode == MMC_POWER_OFF, ios-clock == 0);
we would end up calling pm_runtime_put() twice in a row, which is wrong.
V2 only toggles the controller runtime PM status only when entering or
leaving the TMIO_MMC_ON_RUN state.
drivers/mmc/host/tmio_mmc.h | 20 ++--
drivers/mmc/host/tmio_mmc_pio.c | 27 +--
2 files changed, 35 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index d857f5c..3cc589a 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -40,6 +40,22 @@
struct tmio_mmc_data;
+/*
+ * We differentiate between the following 3 power states:
+ * 1. card slot powered off, controller stopped. This is used, when either
there
+ *is no card in the slot, or the card really has to be powered down.
+ * 2. card slot powered on, controller stopped. This is used, when a card is
in
+ *the slot, but no activity is currently taking place. This is a power-
+ *saving mode with card-state preserved. This state can be entered, e.g.
+ *when MMC clock-gating is used.
+ * 3. card slot powered on, controller running. This is the actual active
state.
+ */
+enum tmio_mmc_power {
+ TMIO_MMC_OFF_STOP, /* card power off, controller stopped */
+ TMIO_MMC_ON_STOP, /* card power on, controller stopped */
+ TMIO_MMC_ON_RUN,/* card power on, controller running */
+};
+
struct tmio_mmc_host {
void __iomem *ctl;
unsigned long bus_shift;
@@ -48,8 +64,8 @@ struct tmio_mmc_host {
struct mmc_data *data;
struct mmc_host *mmc;
- /* Controller power state */
- boolpower;
+ /* Controller and card power state */
+ enum tmio_mmc_power power;
/* Callbacks for clock / power control */
void (*set_pwr)(struct platform_device *host, int state);
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index f508ecb..1d5ef64 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -859,32 +859,39 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
* is kept positive, so no suspending actually takes place.
*/
if (ios-power_mode == MMC_POWER_ON ios-clock) {
- if (!host-power) {
+ if (host-power != TMIO_MMC_ON_RUN) {
tmio_mmc_clk_update(mmc);
pm_runtime_get_sync(dev);
}
tmio_mmc_set_clock(host, ios-clock);
- if (!host-power) {
+ if (host-power == TMIO_MMC_OFF_STOP)
/* power up SD card and the bus */
tmio_mmc_power_on(host, ios-vdd);
- host-power = true;
- }
+ host-power = TMIO_MMC_ON_RUN;
/* start bus clock */
tmio_mmc_clk_start(host);
} else if (ios-power_mode != MMC_POWER_UP) {
- if (host-power) {
- struct tmio_mmc_data *pdata = host-pdata;
- if (ios-power_mode == MMC_POWER_OFF)
+ struct tmio_mmc_data *pdata = host-pdata;
+ unsigned int old_power = host-power;
+
+ if (old_power != TMIO_MMC_OFF_STOP) {
+ if (ios-power_mode == MMC_POWER_OFF) {
tmio_mmc_power_off(host);
+ host-power = TMIO_MMC_OFF_STOP;
+ } else {
+ host-power = TMIO_MMC_ON_STOP;
+ }
+ }
+
+ if (old_power == TMIO_MMC_ON_RUN) {
tmio_mmc_clk_stop(host);
- host-power = false;
pm_runtime_put(dev);
if (pdata-clk_disable)
pdata-clk_disable(host-pdev);
}
}
- if (host-power
Re: [PATCH v2] mmc: tmio: reset the controller after power-up
Hi Chris On Thu, 25 Apr 2013, Guennadi Liakhovetski wrote: Hi Chris On Wed, 24 Apr 2013, Guennadi Liakhovetski wrote: This fixes two reported problems: 1. after a system resume the controller isn't functioning until a command runs on a timeout and a controller reset is performed. 2. if a card is ejected during a running write operation, its re-insertion isn't detected. Reported-by: Nguyen Viet Dung nv-d...@jinso.co.jp Reported-by: Nguyen Hong Ky nh...@jinso.co.jp Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com Please, add the following tags, when applying: Tested-by: Nguyen Viet Dung nv-d...@jinso.co.jp Tested-by: Nguyen Hong Ky nh...@jinso.co.jp This one too, please :) Thanks Guennadi --- v2: this patch supersedes the earlier mmc: tmio: postpone controller reset during resume in that it extends the number of cases, in which the reset is applied. It turned out, it is needed not only after a resume, but also for recovery after an interrupted write. It also now applies on top of [PATCH v2] MMC: tmio: fix unbalanced power-on calls with clock-gating enabled http://article.gmane.org/gmane.linux.kernel.mmc/20233. Reporters are cordially invited to add their Tested-by tags ;-) Chris, both these patches are fixes. Not sure whether it's still a good idea to push them for 3.9, maybe better get them into 3.10 and then to stable? drivers/mmc/host/tmio_mmc_pio.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c index 1d5ef64..fcb9503 100644 --- a/drivers/mmc/host/tmio_mmc_pio.c +++ b/drivers/mmc/host/tmio_mmc_pio.c @@ -863,6 +863,8 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) tmio_mmc_clk_update(mmc); pm_runtime_get_sync(dev); } + if (host-power == TMIO_MMC_OFF_STOP) + tmio_mmc_reset(host); tmio_mmc_set_clock(host, ios-clock); if (host-power == TMIO_MMC_OFF_STOP) /* power up SD card and the bus */ @@ -1161,7 +1163,6 @@ int tmio_mmc_host_resume(struct device *dev) struct mmc_host *mmc = dev_get_drvdata(dev); struct tmio_mmc_host *host = mmc_priv(mmc); - tmio_mmc_reset(host); tmio_mmc_enable_dma(host, true); /* The MMC core will perform the complete set up */ -- 1.7.2.5 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: mmcif: don't clear masked interrupts
Hi Chris On Wed, 15 May 2013, Kuninori Morimoto wrote: Hi At Wed, 15 May 2013 17:39:23 +0900, Nguyen Viet Dung wrote: On 05/15/2013 02:50 PM, Guennadi Liakhovetski wrote: Masking events on MMCIF means, an occurrence of the masked event won't raise an interrupt, but the event bit will still be set in the interrupt status register. If simultaneously a different event occurs, that was enabled, both flags will be set. However, only the unmasked event bit should be cleared in the status register in such a case. Clearing also the masked bit can lead to lost interrupts, which indeed can be observed on the armadillo800eva r8a7740 board with an eMMC chip. The problem has been introduced by the recent mmc: sh_mmcif: simplify IRQ processing patch. Fix the problem by only clearing enabled interrupts. Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com tested-by: Nguyen Viet Dungnv-d...@jinso.co.jp on Bock-W board Tested-by: Kuninori Morimoto kuninori.morimoto...@renesas.com Here's one more for you. Thanks Guennadi Best regards --- Kuninori Morimoto --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 v3 2/2] mmc: tmio: reset the controller after power-up
This fixes two reported problems: 1. after a system resume the controller isn't functioning until a command runs on a timeout and a controller reset is performed. 2. if a card is ejected during a running write operation, its re-insertion isn't detected. Reported-by: Nguyen Viet Dung nv-d...@jinso.co.jp Reported-by: Nguyen Hong Ky nh...@jinso.co.jp Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com Tested-by: Nguyen Viet Dung nv-d...@jinso.co.jp Tested-by: Nguyen Hong Ky nh...@jinso.co.jp --- v3: rebased on top of current mmc-next / 3.10-rc drivers/mmc/host/tmio_mmc_pio.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c index 67d9642..f294708 100644 --- a/drivers/mmc/host/tmio_mmc_pio.c +++ b/drivers/mmc/host/tmio_mmc_pio.c @@ -867,6 +867,8 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) host-resuming = false; } } + if (host-power == TMIO_MMC_OFF_STOP) + tmio_mmc_reset(host); tmio_mmc_set_clock(host, ios-clock); if (host-power == TMIO_MMC_OFF_STOP) /* power up SD card and the bus */ @@ -1186,7 +1188,6 @@ int tmio_mmc_host_runtime_resume(struct device *dev) struct mmc_host *mmc = dev_get_drvdata(dev); struct tmio_mmc_host *host = mmc_priv(mmc); - tmio_mmc_reset(host); tmio_mmc_enable_dma(host, true); return 0; -- 1.7.2.5 -- 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 0/4] mmc: MMCIF SDHI: DT DMA support
Also a re-send of four earlier submitted patches. This patch-series alone is not enough to support DMA in DT on these MMC host controllers, support in appropriate DMAC driver is added in a separate series. This, however, doesn't introduce a dependency, series can be applied in arbitrary order. Cc: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com Guennadi Liakhovetski (4): mmc: sh_mmcif: add support for Device Tree DMA bindings mmc: sdhi/tmio: make DMA filter implementation specific mmc: sdhi/tmio: switch to using dmaengine_slave_config() mmc: sdhi/tmio: add DT DMA support drivers/mmc/host/sh_mmcif.c | 29 ++ drivers/mmc/host/sh_mobile_sdhi.c | 24 -- drivers/mmc/host/tmio_mmc_dma.c | 48 +++-- include/linux/mfd/tmio.h |5 4 files changed, 74 insertions(+), 32 deletions(-) -- 1.7.2.5 Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 3/4] mmc: sdhi/tmio: switch to using dmaengine_slave_config()
This removes the deprecated use of the .private member of struct dma_chan
and switches the sdhi / tmio mmc driver to using the
dmaengine_slave_config() channel configuration method.
Cc: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
Acked-by: Samuel Ortiz sa...@linux.intel.com
---
drivers/mmc/host/sh_mobile_sdhi.c | 33 -
drivers/mmc/host/tmio_mmc_dma.c | 25 +
include/linux/mfd/tmio.h |2 ++
3 files changed, 43 insertions(+), 17 deletions(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_mobile_sdhi.c
index e0088d7..7f45f62 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -20,7 +20,6 @@
#include linux/kernel.h
#include linux/clk.h
-#include linux/dmaengine.h
#include linux/slab.h
#include linux/mod_devicetable.h
#include linux/module.h
@@ -47,8 +46,6 @@ static const struct sh_mobile_sdhi_of_data
sh_mobile_sdhi_of_cfg[] = {
struct sh_mobile_sdhi {
struct clk *clk;
struct tmio_mmc_data mmc_data;
- struct sh_dmae_slave param_tx;
- struct sh_dmae_slave param_rx;
struct tmio_mmc_dma dma_priv;
};
@@ -125,13 +122,6 @@ static void sh_mobile_sdhi_cd_wakeup(const struct
platform_device *pdev)
mmc_detect_change(dev_get_drvdata(pdev-dev), msecs_to_jiffies(100));
}
-static bool sh_mobile_sdhi_filter(struct dma_chan *chan, void *arg)
-{
- dev_dbg(chan-device-dev, %s: slave data %p\n, __func__, arg);
- chan-private = arg;
- return true;
-}
-
static const struct sh_mobile_sdhi_ops sdhi_ops = {
.cd_wakeup = sh_mobile_sdhi_cd_wakeup,
};
@@ -194,13 +184,22 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
mmc_data-get_cd = sh_mobile_sdhi_get_cd;
if (p-dma_slave_tx 0 p-dma_slave_rx 0) {
- priv-param_tx.shdma_slave.slave_id = p-dma_slave_tx;
- priv-param_rx.shdma_slave.slave_id = p-dma_slave_rx;
- priv-dma_priv.chan_priv_tx =
priv-param_tx.shdma_slave;
- priv-dma_priv.chan_priv_rx =
priv-param_rx.shdma_slave;
- priv-dma_priv.alignment_shift = 1; /* 2-byte alignment
*/
- priv-dma_priv.filter = sh_mobile_sdhi_filter;
- mmc_data-dma = priv-dma_priv;
+ struct tmio_mmc_dma *dma_priv = priv-dma_priv;
+
+ /*
+* Yes, we have to provide slave IDs twice to TMIO:
+* once as a filter parameter and once for channel
+* configuration as an explicit slave ID
+*/
+ dma_priv-chan_priv_tx = (void *)p-dma_slave_tx;
+ dma_priv-chan_priv_rx = (void *)p-dma_slave_rx;
+ dma_priv-slave_id_tx = p-dma_slave_tx;
+ dma_priv-slave_id_rx = p-dma_slave_rx;
+
+ dma_priv-alignment_shift = 1; /* 2-byte alignment */
+ dma_priv-filter = shdma_chan_filter;
+
+ mmc_data-dma = dma_priv;
}
}
diff --git a/drivers/mmc/host/tmio_mmc_dma.c b/drivers/mmc/host/tmio_mmc_dma.c
index dc4b10b..5fcf14f 100644
--- a/drivers/mmc/host/tmio_mmc_dma.c
+++ b/drivers/mmc/host/tmio_mmc_dma.c
@@ -268,7 +268,14 @@ void tmio_mmc_request_dma(struct tmio_mmc_host *host,
struct tmio_mmc_data *pdat
return;
if (!host-chan_tx !host-chan_rx) {
+ struct resource *res = platform_get_resource(host-pdev,
+IORESOURCE_MEM, 0);
+ struct dma_slave_config cfg = {};
dma_cap_mask_t mask;
+ int ret;
+
+ if (!res)
+ return;
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
@@ -281,6 +288,14 @@ void tmio_mmc_request_dma(struct tmio_mmc_host *host,
struct tmio_mmc_data *pdat
if (!host-chan_tx)
return;
+ cfg.slave_id = pdata-dma-slave_id_tx;
+ cfg.direction = DMA_MEM_TO_DEV;
+ cfg.dst_addr = res-start + (CTL_SD_DATA_PORT
host-bus_shift);
+ cfg.src_addr = 0;
+ ret = dmaengine_slave_config(host-chan_tx, cfg);
+ if (ret 0)
+ goto ecfgtx;
+
host-chan_rx = dma_request_channel(mask, pdata-dma-filter,
pdata-dma-chan_priv_rx);
dev_dbg(host-pdev-dev, %s: RX: got channel %p\n, __func__,
@@ -289,6 +304,14 @@ void tmio_mmc_request_dma(struct tmio_mmc_host *host,
struct tmio_mmc_data *pdat
if (!host-chan_rx)
goto ereqrx
[PATCH 2/4] mmc: sdhi/tmio: make DMA filter implementation specific
So far only the SDHI implementation uses TMIO MMC with DMA. That way a DMA
channel filter function, defined in the TMIO driver wasn't a problem.
However, such a filter function is DMA controller specific. Since the SDHI
glue is only running on systems with the SHDMA DMA controller, the filter
function can safely be provided by it. Move it into SDHI.
Cc: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
Acked-by: Samuel Ortiz sa...@linux.intel.com
---
drivers/mmc/host/sh_mobile_sdhi.c |9 +
drivers/mmc/host/tmio_mmc_dma.c | 12 ++--
include/linux/mfd/tmio.h |3 +++
3 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_mobile_sdhi.c
index fe90853..e0088d7 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -20,6 +20,7 @@
#include linux/kernel.h
#include linux/clk.h
+#include linux/dmaengine.h
#include linux/slab.h
#include linux/mod_devicetable.h
#include linux/module.h
@@ -124,6 +125,13 @@ static void sh_mobile_sdhi_cd_wakeup(const struct
platform_device *pdev)
mmc_detect_change(dev_get_drvdata(pdev-dev), msecs_to_jiffies(100));
}
+static bool sh_mobile_sdhi_filter(struct dma_chan *chan, void *arg)
+{
+ dev_dbg(chan-device-dev, %s: slave data %p\n, __func__, arg);
+ chan-private = arg;
+ return true;
+}
+
static const struct sh_mobile_sdhi_ops sdhi_ops = {
.cd_wakeup = sh_mobile_sdhi_cd_wakeup,
};
@@ -191,6 +199,7 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
priv-dma_priv.chan_priv_tx =
priv-param_tx.shdma_slave;
priv-dma_priv.chan_priv_rx =
priv-param_rx.shdma_slave;
priv-dma_priv.alignment_shift = 1; /* 2-byte alignment
*/
+ priv-dma_priv.filter = sh_mobile_sdhi_filter;
mmc_data-dma = priv-dma_priv;
}
}
diff --git a/drivers/mmc/host/tmio_mmc_dma.c b/drivers/mmc/host/tmio_mmc_dma.c
index fff9286..dc4b10b 100644
--- a/drivers/mmc/host/tmio_mmc_dma.c
+++ b/drivers/mmc/host/tmio_mmc_dma.c
@@ -261,14 +261,6 @@ out:
spin_unlock_irq(host-lock);
}
-/* It might be necessary to make filter MFD specific */
-static bool tmio_mmc_filter(struct dma_chan *chan, void *arg)
-{
- dev_dbg(chan-device-dev, %s: slave data %p\n, __func__, arg);
- chan-private = arg;
- return true;
-}
-
void tmio_mmc_request_dma(struct tmio_mmc_host *host, struct tmio_mmc_data
*pdata)
{
/* We can only either use DMA for both Tx and Rx or not use it at all */
@@ -281,7 +273,7 @@ void tmio_mmc_request_dma(struct tmio_mmc_host *host,
struct tmio_mmc_data *pdat
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- host-chan_tx = dma_request_channel(mask, tmio_mmc_filter,
+ host-chan_tx = dma_request_channel(mask, pdata-dma-filter,
pdata-dma-chan_priv_tx);
dev_dbg(host-pdev-dev, %s: TX: got channel %p\n, __func__,
host-chan_tx);
@@ -289,7 +281,7 @@ void tmio_mmc_request_dma(struct tmio_mmc_host *host,
struct tmio_mmc_data *pdat
if (!host-chan_tx)
return;
- host-chan_rx = dma_request_channel(mask, tmio_mmc_filter,
+ host-chan_rx = dma_request_channel(mask, pdata-dma-filter,
pdata-dma-chan_priv_rx);
dev_dbg(host-pdev-dev, %s: RX: got channel %p\n, __func__,
host-chan_rx);
diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
index 99bf3e66..0990d8a 100644
--- a/include/linux/mfd/tmio.h
+++ b/include/linux/mfd/tmio.h
@@ -81,10 +81,13 @@ int tmio_core_mmc_resume(void __iomem *cnf, int shift,
unsigned long base);
void tmio_core_mmc_pwr(void __iomem *cnf, int shift, int state);
void tmio_core_mmc_clk_div(void __iomem *cnf, int shift, int state);
+struct dma_chan;
+
struct tmio_mmc_dma {
void *chan_priv_tx;
void *chan_priv_rx;
int alignment_shift;
+ bool (*filter)(struct dma_chan *chan, void *arg);
};
struct tmio_mmc_host;
--
1.7.2.5
--
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: sdhi/tmio: add DT DMA support
Add support for initialising DMA from the Device Tree.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
drivers/mmc/host/sh_mobile_sdhi.c | 14 +++---
drivers/mmc/host/tmio_mmc_dma.c | 19 ---
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_mobile_sdhi.c
index 7f45f62..cc4c872 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -144,6 +144,7 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
struct tmio_mmc_host *host;
int irq, ret, i = 0;
bool multiplexed_isr = true;
+ struct tmio_mmc_dma *dma_priv;
priv = devm_kzalloc(pdev-dev, sizeof(struct sh_mobile_sdhi),
GFP_KERNEL);
if (priv == NULL) {
@@ -152,6 +153,7 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
}
mmc_data = priv-mmc_data;
+ dma_priv = priv-dma_priv;
if (p) {
if (p-init) {
@@ -184,8 +186,6 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
mmc_data-get_cd = sh_mobile_sdhi_get_cd;
if (p-dma_slave_tx 0 p-dma_slave_rx 0) {
- struct tmio_mmc_dma *dma_priv = priv-dma_priv;
-
/*
* Yes, we have to provide slave IDs twice to TMIO:
* once as a filter parameter and once for channel
@@ -195,14 +195,14 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
dma_priv-chan_priv_rx = (void *)p-dma_slave_rx;
dma_priv-slave_id_tx = p-dma_slave_tx;
dma_priv-slave_id_rx = p-dma_slave_rx;
-
- dma_priv-alignment_shift = 1; /* 2-byte alignment */
- dma_priv-filter = shdma_chan_filter;
-
- mmc_data-dma = dma_priv;
}
}
+ dma_priv-alignment_shift = 1; /* 2-byte alignment */
+ dma_priv-filter = shdma_chan_filter;
+
+ mmc_data-dma = dma_priv;
+
/*
* All SDHI blocks support 2-byte and larger block sizes in 4-bit
* bus width mode.
diff --git a/drivers/mmc/host/tmio_mmc_dma.c b/drivers/mmc/host/tmio_mmc_dma.c
index 5fcf14f..47bdb8f 100644
--- a/drivers/mmc/host/tmio_mmc_dma.c
+++ b/drivers/mmc/host/tmio_mmc_dma.c
@@ -264,7 +264,8 @@ out:
void tmio_mmc_request_dma(struct tmio_mmc_host *host, struct tmio_mmc_data
*pdata)
{
/* We can only either use DMA for both Tx and Rx or not use it at all */
- if (!pdata-dma)
+ if (!pdata-dma || (!host-pdev-dev.of_node
+ (!pdata-dma-chan_priv_tx || !pdata-dma-chan_priv_rx)))
return;
if (!host-chan_tx !host-chan_rx) {
@@ -280,15 +281,17 @@ void tmio_mmc_request_dma(struct tmio_mmc_host *host,
struct tmio_mmc_data *pdat
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- host-chan_tx = dma_request_channel(mask, pdata-dma-filter,
- pdata-dma-chan_priv_tx);
+ host-chan_tx = dma_request_slave_channel_compat(mask,
+ pdata-dma-filter,
pdata-dma-chan_priv_tx,
+ host-pdev-dev, tx);
dev_dbg(host-pdev-dev, %s: TX: got channel %p\n, __func__,
host-chan_tx);
if (!host-chan_tx)
return;
- cfg.slave_id = pdata-dma-slave_id_tx;
+ if (pdata-dma-chan_priv_tx)
+ cfg.slave_id = pdata-dma-slave_id_tx;
cfg.direction = DMA_MEM_TO_DEV;
cfg.dst_addr = res-start + (CTL_SD_DATA_PORT
host-bus_shift);
cfg.src_addr = 0;
@@ -296,15 +299,17 @@ void tmio_mmc_request_dma(struct tmio_mmc_host *host,
struct tmio_mmc_data *pdat
if (ret 0)
goto ecfgtx;
- host-chan_rx = dma_request_channel(mask, pdata-dma-filter,
- pdata-dma-chan_priv_rx);
+ host-chan_rx = dma_request_slave_channel_compat(mask,
+ pdata-dma-filter,
pdata-dma-chan_priv_rx,
+ host-pdev-dev, rx);
dev_dbg(host-pdev-dev, %s: RX: got channel %p\n, __func__,
host-chan_rx);
if (!host-chan_rx)
goto ereqrx;
- cfg.slave_id = pdata-dma-slave_id_rx;
+ if (pdata-dma-chan_priv_rx)
+ cfg.slave_id = pdata-dma-slave_id_rx;
cfg.direction = DMA_DEV_TO_MEM;
cfg.src_addr = cfg.dst_addr;
cfg.dst_addr = 0;
--
1.7.2.5
--
To unsubscribe from this list: send the line
[PATCH 1/4] mmc: sh_mmcif: add support for Device Tree DMA bindings
To use DMA in the Device Tree case the driver has to be modified
to use suitable API to obtain DMA channels.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
drivers/mmc/host/sh_mmcif.c | 29 ++---
1 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 06caaae..a0937ae 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -386,25 +386,30 @@ static void sh_mmcif_request_dma(struct sh_mmcif_host
*host,
host-dma_active = false;
- if (!pdata)
- return;
-
- if (pdata-slave_id_tx = 0 || pdata-slave_id_rx = 0)
- return;
+ if (pdata) {
+ if (pdata-slave_id_tx = 0 || pdata-slave_id_rx = 0)
+ return;
+ } else {
+ if (!host-pd-dev.of_node)
+ return;
+ }
/* We can only either use DMA for both Tx and Rx or not use it at all */
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- host-chan_tx = dma_request_channel(mask, shdma_chan_filter,
- (void *)pdata-slave_id_tx);
+ host-chan_tx = dma_request_slave_channel_compat(mask,
shdma_chan_filter,
+ pdata ? (void *)pdata-slave_id_tx : NULL,
+ host-pd-dev, tx);
dev_dbg(host-pd-dev, %s: TX: got channel %p\n, __func__,
host-chan_tx);
if (!host-chan_tx)
return;
- cfg.slave_id = pdata-slave_id_tx;
+ /* In the OF case the driver will get the slave ID from the DT */
+ if (pdata)
+ cfg.slave_id = pdata-slave_id_tx;
cfg.direction = DMA_MEM_TO_DEV;
cfg.dst_addr = res-start + MMCIF_CE_DATA;
cfg.src_addr = 0;
@@ -412,15 +417,17 @@ static void sh_mmcif_request_dma(struct sh_mmcif_host
*host,
if (ret 0)
goto ecfgtx;
- host-chan_rx = dma_request_channel(mask, shdma_chan_filter,
- (void *)pdata-slave_id_rx);
+ host-chan_rx = dma_request_slave_channel_compat(mask,
shdma_chan_filter,
+ pdata ? (void *)pdata-slave_id_rx : NULL,
+ host-pd-dev, rx);
dev_dbg(host-pd-dev, %s: RX: got channel %p\n, __func__,
host-chan_rx);
if (!host-chan_rx)
goto erqrx;
- cfg.slave_id = pdata-slave_id_rx;
+ if (pdata)
+ cfg.slave_id = pdata-slave_id_rx;
cfg.direction = DMA_DEV_TO_MEM;
cfg.dst_addr = 0;
cfg.src_addr = res-start + MMCIF_CE_DATA;
--
1.7.2.5
--
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 v2] dmaengine: shdma: fix a build failure on platforms with no DMA support
On Fri, 31 May 2013, Dan Murphy wrote:
On 05/30/2013 10:01 PM, Guennadi Liakhovetski wrote:
On platforms with no support for the shdma dmaengine driver build is
currently failing with
drivers/built-in.o: In function `sh_mobile_sdhi_probe':
drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference
to`shdma_chan_filter'
Fix the breakage by defining shdma_chan_filter to NULL in such
configurations.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
v2: in next shdma_chan_filter() is defined in shdma-base.c, which is
built if CONFIG_SH_DMAE_BASE is defined. This version uses the correct
symbol.
This is for next. Compile-tested only. I'll test it on hardware next
week, but I don't think it shall break anything.
include/linux/sh_dma.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
index b64d6be..1fd8a20 100644
--- a/include/linux/sh_dma.h
+++ b/include/linux/sh_dma.h
@@ -99,6 +99,10 @@ struct sh_dmae_pdata {
#define CHCR_TE0x0002
#define CHCR_IE0x0004
+#if IS_ENABLED(CONFIG_SH_DMAE_BASE)
bool shdma_chan_filter(struct dma_chan *chan, void *arg);
+#else
+#define shdma_chan_filter NULL
OK I did not see a reply to my previous comment
Would this not be better as a
#else
static inline bool shdma_chan_filter(struct dma_chan *chan, void *arg) {
return false; }
#endif
Otherwise runtime will call a NULL pointer
Have you looked at the code?:
if (fn !fn(chan, fn_param)) {
Have you considered, when this channel allocation at all has a chance to
get as far as to checking the filter? Have you thought about the meaning
of inline when uing a function to assign it to a pointer? Are you sure
will is the right word here?
Thanks
Guennadi
+#endif
#endif
--
--
Dan Murphy
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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] dmaengine: shdma: fix a build failure on platforms with no DMA support
On platforms with no support for the shdma dmaengine driver build is
currently failing with
drivers/built-in.o: In function `sh_mobile_sdhi_probe':
drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference to`shdma_chan_filter'
Fix the breakage by defining shdma_chan_filter to NULL in such
configurations.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
This is for next. Compile-tested only. I'll test it on hardware next
week, but I don't think it shall break anything.
include/linux/sh_dma.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
index b64d6be..1fd8a20 100644
--- a/include/linux/sh_dma.h
+++ b/include/linux/sh_dma.h
@@ -99,6 +99,10 @@ struct sh_dmae_pdata {
#define CHCR_TE0x0002
#define CHCR_IE0x0004
+#if IS_ENABLED(CONFIG_SH_DMAE)
bool shdma_chan_filter(struct dma_chan *chan, void *arg);
+#else
+#define shdma_chan_filter NULL
+#endif
#endif
--
1.7.2.5
--
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 v2] dmaengine: shdma: fix a build failure on platforms with no DMA support
On platforms with no support for the shdma dmaengine driver build is
currently failing with
drivers/built-in.o: In function `sh_mobile_sdhi_probe':
drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference to`shdma_chan_filter'
Fix the breakage by defining shdma_chan_filter to NULL in such
configurations.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
v2: in next shdma_chan_filter() is defined in shdma-base.c, which is
built if CONFIG_SH_DMAE_BASE is defined. This version uses the correct
symbol.
This is for next. Compile-tested only. I'll test it on hardware next
week, but I don't think it shall break anything.
include/linux/sh_dma.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
index b64d6be..1fd8a20 100644
--- a/include/linux/sh_dma.h
+++ b/include/linux/sh_dma.h
@@ -99,6 +99,10 @@ struct sh_dmae_pdata {
#define CHCR_TE0x0002
#define CHCR_IE0x0004
+#if IS_ENABLED(CONFIG_SH_DMAE_BASE)
bool shdma_chan_filter(struct dma_chan *chan, void *arg);
+#else
+#define shdma_chan_filter NULL
+#endif
#endif
--
1.7.2.5
--
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: sh_mobile_sdhi: fix error return code in sh_mobile_sdhi_probe()
Hi
On Tue, 28 May 2013, Wei Yongjun wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Fix to return a negative error code instead of 0 when we cannot get
IRQ source by platform_get_irq(), as done elsewhere in this function.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
Thanks for the patch. Do you think the following version would be even a
bit simpler?
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_mobile_sdhi.c
index fe90853..76661b6 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -255,18 +255,17 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
if (multiplexed_isr) {
while (1) {
irq = platform_get_irq(pdev, i);
- if (irq 0)
- break;
+ /* There must be at least one IRQ source */
+ if (irq 0) {
+ ret = irq;
+ goto eirq;
+ }
i++;
ret = devm_request_irq(pdev-dev, irq, tmio_mmc_irq, 0,
dev_name(pdev-dev), host);
if (ret)
goto eirq;
}
-
- /* There must be at least one IRQ source */
- if (!i)
- goto eirq;
}
dev_info(pdev-dev, %s base at 0x%08lx clock rate %u MHz\n,
If you agree, maybe you could send a v2 of your patch in this form, I'll
ack it then.
Thanks
Guennadi
---
drivers/mmc/host/sh_mobile_sdhi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_mobile_sdhi.c
index cc4c872..a4316b3 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -273,8 +273,10 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
}
/* There must be at least one IRQ source */
- if (!i)
+ if (!i) {
+ ret = irq;
goto eirq;
+ }
}
dev_info(pdev-dev, %s base at 0x%08lx clock rate %u MHz\n,
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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/2] mmc: sdhci: Added set_power sdhci_ops handler.
On Wed, 22 May 2013, Felipe Ferreri Tonello wrote: Hi Guennadi, On Wednesday, May 22, 2013 10:30:40 PM Guennadi Liakhovetski wrote: On Wed, 22 May 2013, Felipe F. Tonello wrote: From: Felipe F. Tonello e...@felipetonello.com This is useful for power managment purposes if a sdhci child host wants to turn off some other peripheral also. Sorry, could you elaborate a bit? In what situations is it exactly useful? And why cannot the regulator API be used there? Sorry about that. One example that I can think of is when you have a wifi module connected as a mmc card via sdio. So you can register a callback function in your machine source code to turn on/off the wifi module based on the mmc host power. Ok, understand. Your second patch in this series adds such a callback in your SDHCI host driver and there it just calls a platform callback. I don't think this is a good idea. First, we want to go away from platform callbacks, because they are incompatible with DT. Second, because the proper solution IMHO would be for your platform to export a regulator, and the SDHCI core driver already includes regulator support. I've seen this implementation in others mmc hosts, such as omap. Which, however, doesn't yet mean, it's a good idea :) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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/2] mmc: sdhci: Added set_power sdhci_ops handler.
On Wed, 22 May 2013, Felipe F. Tonello wrote:
From: Felipe F. Tonello e...@felipetonello.com
This is useful for power managment purposes if a sdhci child host wants to
turn off some other peripheral also.
Sorry, could you elaborate a bit? In what situations is it exactly useful?
And why cannot the regulator API be used there?
Thanks
Guennadi
Signed-off-by: Felipe F. Tonello e...@felipetonello.com
---
drivers/mmc/host/sdhci.c | 8
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 2ea429c..0a026c6 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1244,6 +1244,10 @@ static int sdhci_set_power(struct sdhci_host *host,
unsigned short power)
u8 pwr = 0;
if (power != (unsigned short)-1) {
+
+ if (host-ops-set_power)
+ host-ops-set_power(host, true);
+
switch (1 power) {
case MMC_VDD_165_195:
pwr = SDHCI_POWER_180;
@@ -1259,6 +1263,10 @@ static int sdhci_set_power(struct sdhci_host *host,
unsigned short power)
default:
BUG();
}
+ } else {
+
+ if (host-ops-set_power)
+ host-ops-set_power(host, false);
}
if (host-pwr == pwr)
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 379e09d..293d56d 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -294,6 +294,7 @@ struct sdhci_ops {
void(*platform_resume)(struct sdhci_host *host);
void(*adma_workaround)(struct sdhci_host *host, u32 intmask);
void(*platform_init)(struct sdhci_host *host);
+ void(*set_power)(struct sdhci_host *host, bool power);
};
#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
--
1.8.1.4
--
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
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: mmcif: don't clear masked interrupts
On Wed, 15 May 2013, Guennadi Liakhovetski wrote: Masking events on MMCIF means, an occurrence of the masked event won't raise an interrupt, but the event bit will still be set in the interrupt status register. If simultaneously a different event occurs, that was enabled, both flags will be set. However, only the unmasked event bit should be cleared in the status register in such a case. Clearing also the masked bit can lead to lost interrupts, which indeed can be observed on the armadillo800eva r8a7740 board with an eMMC chip. The problem has been introduced by the recent mmc: sh_mmcif: simplify IRQ processing patch. Fix the problem by only clearing enabled interrupts. Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com Sorry, forgot to add a Reported-by: Nguyen Viet Dung nv-d...@jinso.co.jp Thanks Guennadi --- Chris, please, push this fix to 3.10, thanks. drivers/mmc/host/sh_mmcif.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c index ba76a53..06caaae 100644 --- a/drivers/mmc/host/sh_mmcif.c +++ b/drivers/mmc/host/sh_mmcif.c @@ -1244,7 +1244,8 @@ static irqreturn_t sh_mmcif_intr(int irq, void *dev_id) u32 state; state = sh_mmcif_readl(host-addr, MMCIF_CE_INT); - sh_mmcif_writel(host-addr, MMCIF_CE_INT, ~state); + sh_mmcif_writel(host-addr, MMCIF_CE_INT, + ~(state sh_mmcif_readl(host-addr, MMCIF_CE_INT_MASK))); sh_mmcif_bitclr(host, MMCIF_CE_INT_MASK, state MASK_CLEAN); if (state ~MASK_CLEAN) -- 1.7.2.5 -- 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 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 V2 00/10] mmc_of_parse() adaptations, DT support for Sheevaplugs
Hi Simon On Mon, 13 May 2013, Simon Baatz wrote: While adding DT support for the Sheevaplugs by Globalscale Technologies (Kirkwood), it turned out that the DT binding of mvsdio lacked features to properly support the hardware (active high/low of CD and WP pins could not be described in DT). This is standard functionality provided by the mmc_of_parse() helper function. However, mmc_of_parse() may allocate GPIO lines. If the allocation fails, it outputs an error, but does not return an error to its caller. Therefore, a proposal to handle errors in mmc_of_parse() is made. Thanks for the patches. In principle I'm fine either way. It is a policy decision IMHO. E.g. consider a situation. You have a DT with an SD-card slot, where card-detection is performed by a GPIO. OTOH the same pin is used on some other (optional) interface on the same board. If that other competing interface is unused, the driver isn't loaded, you can use the GPIO for card-detection. However, if that other interface is used, your attempt to get the card-detect pin will fail, but you still can use the interface in polling mode. No, I don't think this is a good example of hardware design :) User experience would depend on driver probing order, but in principle it is imaginable. So, with the current mmc_of_parse() you're more tolerant. You get a warning in the log, but the interface might still be usable. And if you're surprised why your write protection status hasn't been properly detected - just look in the log. You're proposing a change in behaviour. After your change any failure to obtain a resource in mmc_of_parse() will fail interface probing. Personally I don't think there are any users around, who would notice this change, still, we have to be aware of it. And I don't know whether we should do that. You know, we don't break user-space ;-) So, technically I'm ok with the changes, but policy-wise I'm not sure how severe this change would be. We could go a bit slower and first add a return code as in your patch #1, but not fail drivers, like in your patches #2, 3,... but WARN_ON(mmc_of_parse() 0); and continue for now. In 3.12 we could then replace those warnings with real failures. But maybe I'm just overcautious and we can just go ahead with your patches. You can add my Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de for patches 1-3, and let's see what Chris thinks about this change. Thanks Guennadi The patch set is structured as follows: 1 Adapt mmc_of_parse() to return errors 2-6 Handle errors in current drivers using mmc_of_parse() (compile tested only) 7-8 Convert mvsdio and respective dts files to mmc_of_parse() (tested on kirkwood) 9 Add dts files for (eSATA) Sheevaplug 10 Add DT support for (eSATA) Sheevaplug I could only test on an eSATA Sheevaplug. I found patches with different LEDs for the Sheevaplug. Thus, I would highly appreciate if someone with the hardware could give this a spin on a non-eSATA version. Some additional testing of the change detect and write protect behaviour for mvsdio can't hurt either. I hope that there aren't board revisions with different CD/WP pins out there. Simon Baatz (10): mmc: return mmc_of_parse() errors to caller mmc: sh_mmcif: handle mmc_of_parse() errors during probe mmc: tmio-mmc: handle mmc_of_parse() errors during probe mmc: mxcmmc: handle mmc_of_parse() errors during probe mmc: sdhi-pxav3: handle mmc_of_parse() errors during probe mmc: tegra: handle mmc_of_parse() errors during probe ARM: mvebu: Use standard MMC binding for all users of mvsdio mmc: mvsdio: use standard MMC device-tree binding parser mmc_of_parse() ARM: Kirkwood: Add dts files for Sheevaplug and eSATA Sheevaplug ARM: Kirkwood: add DT support for Sheevaplug and Sheevaplug eSATA --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 V2 05/10] mmc: sdhi-pxav3: handle mmc_of_parse() errors during probe
There's a typo in the subject line - it's sdhci, not sdhi :)
Thanks
Guennadi
On Mon, 13 May 2013, Simon Baatz wrote:
Signed-off-by: Simon Baatz gmbno...@gmail.com
---
drivers/mmc/host/sdhci-pxav3.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 1ae358e..67ea388 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -252,7 +252,9 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
match = of_match_device(of_match_ptr(sdhci_pxav3_of_match), pdev-dev);
if (match) {
- mmc_of_parse(host-mmc);
+ ret = mmc_of_parse(host-mmc);
+ if (ret)
+ goto err_of_parse;
sdhci_get_of_property(pdev);
pdata = pxav3_get_mmc_pdata(dev);
} else if (pdata) {
@@ -313,10 +315,11 @@ static int sdhci_pxav3_probe(struct platform_device
*pdev)
return 0;
+err_of_parse:
+err_cd_req:
err_add_host:
clk_disable_unprepare(clk);
clk_put(clk);
-err_cd_req:
err_clk_get:
sdhci_pltfm_free(pdev);
kfree(pxa);
--
1.7.9.5
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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] mmc: mmcif: don't clear masked interrupts
Masking events on MMCIF means, an occurrence of the masked event won't raise an interrupt, but the event bit will still be set in the interrupt status register. If simultaneously a different event occurs, that was enabled, both flags will be set. However, only the unmasked event bit should be cleared in the status register in such a case. Clearing also the masked bit can lead to lost interrupts, which indeed can be observed on the armadillo800eva r8a7740 board with an eMMC chip. The problem has been introduced by the recent mmc: sh_mmcif: simplify IRQ processing patch. Fix the problem by only clearing enabled interrupts. Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com --- Chris, please, push this fix to 3.10, thanks. drivers/mmc/host/sh_mmcif.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c index ba76a53..06caaae 100644 --- a/drivers/mmc/host/sh_mmcif.c +++ b/drivers/mmc/host/sh_mmcif.c @@ -1244,7 +1244,8 @@ static irqreturn_t sh_mmcif_intr(int irq, void *dev_id) u32 state; state = sh_mmcif_readl(host-addr, MMCIF_CE_INT); - sh_mmcif_writel(host-addr, MMCIF_CE_INT, ~state); + sh_mmcif_writel(host-addr, MMCIF_CE_INT, + ~(state sh_mmcif_readl(host-addr, MMCIF_CE_INT_MASK))); sh_mmcif_bitclr(host, MMCIF_CE_INT_MASK, state MASK_CLEAN); if (state ~MASK_CLEAN) -- 1.7.2.5 -- 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 3/3] mmc: sdhi/tmio: add DT DMA support
Add support for initialising DMA from the Device Tree.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
drivers/mmc/host/sh_mobile_sdhi.c | 14 +++---
drivers/mmc/host/tmio_mmc_dma.c | 19 ---
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_mobile_sdhi.c
index 7f45f62..cc4c872 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -144,6 +144,7 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
struct tmio_mmc_host *host;
int irq, ret, i = 0;
bool multiplexed_isr = true;
+ struct tmio_mmc_dma *dma_priv;
priv = devm_kzalloc(pdev-dev, sizeof(struct sh_mobile_sdhi),
GFP_KERNEL);
if (priv == NULL) {
@@ -152,6 +153,7 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
}
mmc_data = priv-mmc_data;
+ dma_priv = priv-dma_priv;
if (p) {
if (p-init) {
@@ -184,8 +186,6 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
mmc_data-get_cd = sh_mobile_sdhi_get_cd;
if (p-dma_slave_tx 0 p-dma_slave_rx 0) {
- struct tmio_mmc_dma *dma_priv = priv-dma_priv;
-
/*
* Yes, we have to provide slave IDs twice to TMIO:
* once as a filter parameter and once for channel
@@ -195,14 +195,14 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
dma_priv-chan_priv_rx = (void *)p-dma_slave_rx;
dma_priv-slave_id_tx = p-dma_slave_tx;
dma_priv-slave_id_rx = p-dma_slave_rx;
-
- dma_priv-alignment_shift = 1; /* 2-byte alignment */
- dma_priv-filter = shdma_chan_filter;
-
- mmc_data-dma = dma_priv;
}
}
+ dma_priv-alignment_shift = 1; /* 2-byte alignment */
+ dma_priv-filter = shdma_chan_filter;
+
+ mmc_data-dma = dma_priv;
+
/*
* All SDHI blocks support 2-byte and larger block sizes in 4-bit
* bus width mode.
diff --git a/drivers/mmc/host/tmio_mmc_dma.c b/drivers/mmc/host/tmio_mmc_dma.c
index 5fcf14f..47bdb8f 100644
--- a/drivers/mmc/host/tmio_mmc_dma.c
+++ b/drivers/mmc/host/tmio_mmc_dma.c
@@ -264,7 +264,8 @@ out:
void tmio_mmc_request_dma(struct tmio_mmc_host *host, struct tmio_mmc_data
*pdata)
{
/* We can only either use DMA for both Tx and Rx or not use it at all */
- if (!pdata-dma)
+ if (!pdata-dma || (!host-pdev-dev.of_node
+ (!pdata-dma-chan_priv_tx || !pdata-dma-chan_priv_rx)))
return;
if (!host-chan_tx !host-chan_rx) {
@@ -280,15 +281,17 @@ void tmio_mmc_request_dma(struct tmio_mmc_host *host,
struct tmio_mmc_data *pdat
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- host-chan_tx = dma_request_channel(mask, pdata-dma-filter,
- pdata-dma-chan_priv_tx);
+ host-chan_tx = dma_request_slave_channel_compat(mask,
+ pdata-dma-filter,
pdata-dma-chan_priv_tx,
+ host-pdev-dev, tx);
dev_dbg(host-pdev-dev, %s: TX: got channel %p\n, __func__,
host-chan_tx);
if (!host-chan_tx)
return;
- cfg.slave_id = pdata-dma-slave_id_tx;
+ if (pdata-dma-chan_priv_tx)
+ cfg.slave_id = pdata-dma-slave_id_tx;
cfg.direction = DMA_MEM_TO_DEV;
cfg.dst_addr = res-start + (CTL_SD_DATA_PORT
host-bus_shift);
cfg.src_addr = 0;
@@ -296,15 +299,17 @@ void tmio_mmc_request_dma(struct tmio_mmc_host *host,
struct tmio_mmc_data *pdat
if (ret 0)
goto ecfgtx;
- host-chan_rx = dma_request_channel(mask, pdata-dma-filter,
- pdata-dma-chan_priv_rx);
+ host-chan_rx = dma_request_slave_channel_compat(mask,
+ pdata-dma-filter,
pdata-dma-chan_priv_rx,
+ host-pdev-dev, rx);
dev_dbg(host-pdev-dev, %s: RX: got channel %p\n, __func__,
host-chan_rx);
if (!host-chan_rx)
goto ereqrx;
- cfg.slave_id = pdata-dma-slave_id_rx;
+ if (pdata-dma-chan_priv_rx)
+ cfg.slave_id = pdata-dma-slave_id_rx;
cfg.direction = DMA_DEV_TO_MEM;
cfg.src_addr = cfg.dst_addr;
cfg.dst_addr = 0;
--
1.7.2.5
--
To unsubscribe from this list: send the line
[PATCH 2/3] mmc: sdhi/tmio: switch to using dmaengine_slave_config()
This removes the deprecated use of the .private member of struct dma_chan
and switches the sdhi / tmio mmc driver to using the
dmaengine_slave_config() channel configuration method.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
drivers/mmc/host/sh_mobile_sdhi.c | 33 -
drivers/mmc/host/tmio_mmc_dma.c | 25 +
include/linux/mfd/tmio.h |2 ++
3 files changed, 43 insertions(+), 17 deletions(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_mobile_sdhi.c
index e0088d7..7f45f62 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -20,7 +20,6 @@
#include linux/kernel.h
#include linux/clk.h
-#include linux/dmaengine.h
#include linux/slab.h
#include linux/mod_devicetable.h
#include linux/module.h
@@ -47,8 +46,6 @@ static const struct sh_mobile_sdhi_of_data
sh_mobile_sdhi_of_cfg[] = {
struct sh_mobile_sdhi {
struct clk *clk;
struct tmio_mmc_data mmc_data;
- struct sh_dmae_slave param_tx;
- struct sh_dmae_slave param_rx;
struct tmio_mmc_dma dma_priv;
};
@@ -125,13 +122,6 @@ static void sh_mobile_sdhi_cd_wakeup(const struct
platform_device *pdev)
mmc_detect_change(dev_get_drvdata(pdev-dev), msecs_to_jiffies(100));
}
-static bool sh_mobile_sdhi_filter(struct dma_chan *chan, void *arg)
-{
- dev_dbg(chan-device-dev, %s: slave data %p\n, __func__, arg);
- chan-private = arg;
- return true;
-}
-
static const struct sh_mobile_sdhi_ops sdhi_ops = {
.cd_wakeup = sh_mobile_sdhi_cd_wakeup,
};
@@ -194,13 +184,22 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
mmc_data-get_cd = sh_mobile_sdhi_get_cd;
if (p-dma_slave_tx 0 p-dma_slave_rx 0) {
- priv-param_tx.shdma_slave.slave_id = p-dma_slave_tx;
- priv-param_rx.shdma_slave.slave_id = p-dma_slave_rx;
- priv-dma_priv.chan_priv_tx =
priv-param_tx.shdma_slave;
- priv-dma_priv.chan_priv_rx =
priv-param_rx.shdma_slave;
- priv-dma_priv.alignment_shift = 1; /* 2-byte alignment
*/
- priv-dma_priv.filter = sh_mobile_sdhi_filter;
- mmc_data-dma = priv-dma_priv;
+ struct tmio_mmc_dma *dma_priv = priv-dma_priv;
+
+ /*
+* Yes, we have to provide slave IDs twice to TMIO:
+* once as a filter parameter and once for channel
+* configuration as an explicit slave ID
+*/
+ dma_priv-chan_priv_tx = (void *)p-dma_slave_tx;
+ dma_priv-chan_priv_rx = (void *)p-dma_slave_rx;
+ dma_priv-slave_id_tx = p-dma_slave_tx;
+ dma_priv-slave_id_rx = p-dma_slave_rx;
+
+ dma_priv-alignment_shift = 1; /* 2-byte alignment */
+ dma_priv-filter = shdma_chan_filter;
+
+ mmc_data-dma = dma_priv;
}
}
diff --git a/drivers/mmc/host/tmio_mmc_dma.c b/drivers/mmc/host/tmio_mmc_dma.c
index dc4b10b..5fcf14f 100644
--- a/drivers/mmc/host/tmio_mmc_dma.c
+++ b/drivers/mmc/host/tmio_mmc_dma.c
@@ -268,7 +268,14 @@ void tmio_mmc_request_dma(struct tmio_mmc_host *host,
struct tmio_mmc_data *pdat
return;
if (!host-chan_tx !host-chan_rx) {
+ struct resource *res = platform_get_resource(host-pdev,
+IORESOURCE_MEM, 0);
+ struct dma_slave_config cfg = {};
dma_cap_mask_t mask;
+ int ret;
+
+ if (!res)
+ return;
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
@@ -281,6 +288,14 @@ void tmio_mmc_request_dma(struct tmio_mmc_host *host,
struct tmio_mmc_data *pdat
if (!host-chan_tx)
return;
+ cfg.slave_id = pdata-dma-slave_id_tx;
+ cfg.direction = DMA_MEM_TO_DEV;
+ cfg.dst_addr = res-start + (CTL_SD_DATA_PORT
host-bus_shift);
+ cfg.src_addr = 0;
+ ret = dmaengine_slave_config(host-chan_tx, cfg);
+ if (ret 0)
+ goto ecfgtx;
+
host-chan_rx = dma_request_channel(mask, pdata-dma-filter,
pdata-dma-chan_priv_rx);
dev_dbg(host-pdev-dev, %s: RX: got channel %p\n, __func__,
@@ -289,6 +304,14 @@ void tmio_mmc_request_dma(struct tmio_mmc_host *host,
struct tmio_mmc_data *pdat
if (!host-chan_rx)
goto ereqrx;
+ cfg.slave_id = pdata-dma-slave_id_rx;
+ cfg.direction
[PATCH 0/3] mmc: sdhi / tmio: add DT DMA
These 3 patches add Device Tree DMA support to the TMIO MMC driver, when used on SDHI platforms. Samuel: these patches touch an mfd header file lightly, I think, it's better just to get your ack than to make a separate patch via your tree. Cc: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com Guennadi Liakhovetski (3): mmc: sdhi/tmio: make DMA filter implementation specific mmc: sdhi/tmio: switch to using dmaengine_slave_config() mmc: sdhi/tmio: add DT DMA support drivers/mmc/host/sh_mobile_sdhi.c | 24 -- drivers/mmc/host/tmio_mmc_dma.c | 48 +++-- include/linux/mfd/tmio.h |5 3 files changed, 56 insertions(+), 21 deletions(-) -- 1.7.2.5 Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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/3] mmc: sdhi/tmio: make DMA filter implementation specific
So far only the SDHI implementation uses TMIO MMC with DMA. That way a DMA
channel filter function, defined in the TMIO driver wasn't a problem.
However, such a filter function is DMA controller specific. Since the SDHI
glue is only running on systems with the SHDMA DMA controller, the filter
function can safely be provided by it. Move it into SDHI.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
drivers/mmc/host/sh_mobile_sdhi.c |9 +
drivers/mmc/host/tmio_mmc_dma.c | 12 ++--
include/linux/mfd/tmio.h |3 +++
3 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_mobile_sdhi.c
index fe90853..e0088d7 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -20,6 +20,7 @@
#include linux/kernel.h
#include linux/clk.h
+#include linux/dmaengine.h
#include linux/slab.h
#include linux/mod_devicetable.h
#include linux/module.h
@@ -124,6 +125,13 @@ static void sh_mobile_sdhi_cd_wakeup(const struct
platform_device *pdev)
mmc_detect_change(dev_get_drvdata(pdev-dev), msecs_to_jiffies(100));
}
+static bool sh_mobile_sdhi_filter(struct dma_chan *chan, void *arg)
+{
+ dev_dbg(chan-device-dev, %s: slave data %p\n, __func__, arg);
+ chan-private = arg;
+ return true;
+}
+
static const struct sh_mobile_sdhi_ops sdhi_ops = {
.cd_wakeup = sh_mobile_sdhi_cd_wakeup,
};
@@ -191,6 +199,7 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
priv-dma_priv.chan_priv_tx =
priv-param_tx.shdma_slave;
priv-dma_priv.chan_priv_rx =
priv-param_rx.shdma_slave;
priv-dma_priv.alignment_shift = 1; /* 2-byte alignment
*/
+ priv-dma_priv.filter = sh_mobile_sdhi_filter;
mmc_data-dma = priv-dma_priv;
}
}
diff --git a/drivers/mmc/host/tmio_mmc_dma.c b/drivers/mmc/host/tmio_mmc_dma.c
index fff9286..dc4b10b 100644
--- a/drivers/mmc/host/tmio_mmc_dma.c
+++ b/drivers/mmc/host/tmio_mmc_dma.c
@@ -261,14 +261,6 @@ out:
spin_unlock_irq(host-lock);
}
-/* It might be necessary to make filter MFD specific */
-static bool tmio_mmc_filter(struct dma_chan *chan, void *arg)
-{
- dev_dbg(chan-device-dev, %s: slave data %p\n, __func__, arg);
- chan-private = arg;
- return true;
-}
-
void tmio_mmc_request_dma(struct tmio_mmc_host *host, struct tmio_mmc_data
*pdata)
{
/* We can only either use DMA for both Tx and Rx or not use it at all */
@@ -281,7 +273,7 @@ void tmio_mmc_request_dma(struct tmio_mmc_host *host,
struct tmio_mmc_data *pdat
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- host-chan_tx = dma_request_channel(mask, tmio_mmc_filter,
+ host-chan_tx = dma_request_channel(mask, pdata-dma-filter,
pdata-dma-chan_priv_tx);
dev_dbg(host-pdev-dev, %s: TX: got channel %p\n, __func__,
host-chan_tx);
@@ -289,7 +281,7 @@ void tmio_mmc_request_dma(struct tmio_mmc_host *host,
struct tmio_mmc_data *pdat
if (!host-chan_tx)
return;
- host-chan_rx = dma_request_channel(mask, tmio_mmc_filter,
+ host-chan_rx = dma_request_channel(mask, pdata-dma-filter,
pdata-dma-chan_priv_rx);
dev_dbg(host-pdev-dev, %s: RX: got channel %p\n, __func__,
host-chan_rx);
diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
index 99bf3e66..0990d8a 100644
--- a/include/linux/mfd/tmio.h
+++ b/include/linux/mfd/tmio.h
@@ -81,10 +81,13 @@ int tmio_core_mmc_resume(void __iomem *cnf, int shift,
unsigned long base);
void tmio_core_mmc_pwr(void __iomem *cnf, int shift, int state);
void tmio_core_mmc_clk_div(void __iomem *cnf, int shift, int state);
+struct dma_chan;
+
struct tmio_mmc_dma {
void *chan_priv_tx;
void *chan_priv_rx;
int alignment_shift;
+ bool (*filter)(struct dma_chan *chan, void *arg);
};
struct tmio_mmc_host;
--
1.7.2.5
--
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 0/3] mmc: sdhi / tmio: add DT DMA
On Fri, 26 Apr 2013, Samuel Ortiz wrote: Hi Guennadi, On Fri, Apr 26, 2013 at 05:47:16PM +0200, Guennadi Liakhovetski wrote: These 3 patches add Device Tree DMA support to the TMIO MMC driver, when used on SDHI platforms. Samuel: these patches touch an mfd header file lightly, I think, it's better just to get your ack than to make a separate patch via your tree. Yes, that is fine with me. For the mfd/tmio.h part: Acked-by: Samuel Ortiz sa...@linux.intel.com Thanks! Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 v2] mmc: tmio: reset the controller after power-up
Hi Chris On Wed, 24 Apr 2013, Guennadi Liakhovetski wrote: This fixes two reported problems: 1. after a system resume the controller isn't functioning until a command runs on a timeout and a controller reset is performed. 2. if a card is ejected during a running write operation, its re-insertion isn't detected. Reported-by: Nguyen Viet Dung nv-d...@jinso.co.jp Reported-by: Nguyen Hong Ky nh...@jinso.co.jp Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com Please, add the following tags, when applying: Tested-by: Nguyen Viet Dung nv-d...@jinso.co.jp Tested-by: Nguyen Hong Ky nh...@jinso.co.jp Thanks Guennadi --- v2: this patch supersedes the earlier mmc: tmio: postpone controller reset during resume in that it extends the number of cases, in which the reset is applied. It turned out, it is needed not only after a resume, but also for recovery after an interrupted write. It also now applies on top of [PATCH v2] MMC: tmio: fix unbalanced power-on calls with clock-gating enabled http://article.gmane.org/gmane.linux.kernel.mmc/20233. Reporters are cordially invited to add their Tested-by tags ;-) Chris, both these patches are fixes. Not sure whether it's still a good idea to push them for 3.9, maybe better get them into 3.10 and then to stable? drivers/mmc/host/tmio_mmc_pio.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c index 1d5ef64..fcb9503 100644 --- a/drivers/mmc/host/tmio_mmc_pio.c +++ b/drivers/mmc/host/tmio_mmc_pio.c @@ -863,6 +863,8 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) tmio_mmc_clk_update(mmc); pm_runtime_get_sync(dev); } + if (host-power == TMIO_MMC_OFF_STOP) + tmio_mmc_reset(host); tmio_mmc_set_clock(host, ios-clock); if (host-power == TMIO_MMC_OFF_STOP) /* power up SD card and the bus */ @@ -1161,7 +1163,6 @@ int tmio_mmc_host_resume(struct device *dev) struct mmc_host *mmc = dev_get_drvdata(dev); struct tmio_mmc_host *host = mmc_priv(mmc); - tmio_mmc_reset(host); tmio_mmc_enable_dma(host, true); /* The MMC core will perform the complete set up */ -- 1.7.2.5 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 v2] mmc: tmio: reset the controller after power-up
This fixes two reported problems: 1. after a system resume the controller isn't functioning until a command runs on a timeout and a controller reset is performed. 2. if a card is ejected during a running write operation, its re-insertion isn't detected. Reported-by: Nguyen Viet Dung nv-d...@jinso.co.jp Reported-by: Nguyen Hong Ky nh...@jinso.co.jp Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com --- v2: this patch supersedes the earlier mmc: tmio: postpone controller reset during resume in that it extends the number of cases, in which the reset is applied. It turned out, it is needed not only after a resume, but also for recovery after an interrupted write. It also now applies on top of [PATCH v2] MMC: tmio: fix unbalanced power-on calls with clock-gating enabled http://article.gmane.org/gmane.linux.kernel.mmc/20233. Reporters are cordially invited to add their Tested-by tags ;-) Chris, both these patches are fixes. Not sure whether it's still a good idea to push them for 3.9, maybe better get them into 3.10 and then to stable? drivers/mmc/host/tmio_mmc_pio.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c index 1d5ef64..fcb9503 100644 --- a/drivers/mmc/host/tmio_mmc_pio.c +++ b/drivers/mmc/host/tmio_mmc_pio.c @@ -863,6 +863,8 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) tmio_mmc_clk_update(mmc); pm_runtime_get_sync(dev); } + if (host-power == TMIO_MMC_OFF_STOP) + tmio_mmc_reset(host); tmio_mmc_set_clock(host, ios-clock); if (host-power == TMIO_MMC_OFF_STOP) /* power up SD card and the bus */ @@ -1161,7 +1163,6 @@ int tmio_mmc_host_resume(struct device *dev) struct mmc_host *mmc = dev_get_drvdata(dev); struct tmio_mmc_host *host = mmc_priv(mmc); - tmio_mmc_reset(host); tmio_mmc_enable_dma(host, true); /* The MMC core will perform the complete set up */ -- 1.7.2.5 -- 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 v2] MMC: tmio: fix unbalanced power-on calls with clock-gating enabled
With MMC clock gating enabled the MMC core currently calls MMC host driver's
.set_ios() method with .power_mode == MMC_POWER_ON and the clock value set
either to 0 or to the target rate. The tmio MMC driver then wrongly
translates the latter calls to card slot power-on requests, even when the
slot already was on. This patch fixes the driver to avoid needlessly
incrementing power-supplying regulator's use count.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
v2: Also make runtime PM handling safer and more resistant to possible
MMC core changes. V1 worked fine too, but theoretically if the core
decided to issue a sequence like
.set_ios(ios-power_mode == MMC_POWER_ON, ios-clock != 0);
.set_ios(ios-power_mode == MMC_POWER_ON, ios-clock == 0);
.set_ios(ios-power_mode == MMC_POWER_OFF, ios-clock == 0);
we would end up calling pm_runtime_put() twice in a row, which is wrong.
V2 only toggles the controller runtime PM status only when entering or
leaving the TMIO_MMC_ON_RUN state.
drivers/mmc/host/tmio_mmc.h | 20 ++--
drivers/mmc/host/tmio_mmc_pio.c | 27 +--
2 files changed, 35 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index d857f5c..3cc589a 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -40,6 +40,22 @@
struct tmio_mmc_data;
+/*
+ * We differentiate between the following 3 power states:
+ * 1. card slot powered off, controller stopped. This is used, when either
there
+ *is no card in the slot, or the card really has to be powered down.
+ * 2. card slot powered on, controller stopped. This is used, when a card is in
+ *the slot, but no activity is currently taking place. This is a power-
+ *saving mode with card-state preserved. This state can be entered, e.g.
+ *when MMC clock-gating is used.
+ * 3. card slot powered on, controller running. This is the actual active
state.
+ */
+enum tmio_mmc_power {
+ TMIO_MMC_OFF_STOP, /* card power off, controller stopped */
+ TMIO_MMC_ON_STOP, /* card power on, controller stopped */
+ TMIO_MMC_ON_RUN,/* card power on, controller running */
+};
+
struct tmio_mmc_host {
void __iomem *ctl;
unsigned long bus_shift;
@@ -48,8 +64,8 @@ struct tmio_mmc_host {
struct mmc_data *data;
struct mmc_host *mmc;
- /* Controller power state */
- boolpower;
+ /* Controller and card power state */
+ enum tmio_mmc_power power;
/* Callbacks for clock / power control */
void (*set_pwr)(struct platform_device *host, int state);
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index f508ecb..1d5ef64 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -859,32 +859,39 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
* is kept positive, so no suspending actually takes place.
*/
if (ios-power_mode == MMC_POWER_ON ios-clock) {
- if (!host-power) {
+ if (host-power != TMIO_MMC_ON_RUN) {
tmio_mmc_clk_update(mmc);
pm_runtime_get_sync(dev);
}
tmio_mmc_set_clock(host, ios-clock);
- if (!host-power) {
+ if (host-power == TMIO_MMC_OFF_STOP)
/* power up SD card and the bus */
tmio_mmc_power_on(host, ios-vdd);
- host-power = true;
- }
+ host-power = TMIO_MMC_ON_RUN;
/* start bus clock */
tmio_mmc_clk_start(host);
} else if (ios-power_mode != MMC_POWER_UP) {
- if (host-power) {
- struct tmio_mmc_data *pdata = host-pdata;
- if (ios-power_mode == MMC_POWER_OFF)
+ struct tmio_mmc_data *pdata = host-pdata;
+ unsigned int old_power = host-power;
+
+ if (old_power != TMIO_MMC_OFF_STOP) {
+ if (ios-power_mode == MMC_POWER_OFF) {
tmio_mmc_power_off(host);
+ host-power = TMIO_MMC_OFF_STOP;
+ } else {
+ host-power = TMIO_MMC_ON_STOP;
+ }
+ }
+
+ if (old_power == TMIO_MMC_ON_RUN) {
tmio_mmc_clk_stop(host);
- host-power = false;
pm_runtime_put(dev);
if (pdata-clk_disable)
pdata-clk_disable(host-pdev);
}
}
- if (host-power) {
+ if (host-power != TMIO_MMC_OFF_STOP) {
switch (ios-bus_width) {
case
