Skip to contentSkip to conversation

Add __ioread32_copy() and use it

PATCH Superseded Stephen Boyd 4 participants 8 messages Sep 17, 2015 – Sep 22, 2015

Subsystems (5)

v2 of 3 Superseded Latest is v3 →

lore
Share & tools
lore
#0 lore raw

v2 cover Add __ioread32_copy() and use it

The SMD driver is reading and writing chunks of data to iomem, and there's an __iowrite32_copy() function for the writing part, but no __ioread32_copy() function for the reading part. This series adds __ioread32_copy() and uses it in two places. Andrew is on Cc in case this should go through the -mm tree. Otherwise the target of this patch series is SMD, so I've sent it to Andy.

Note this patch series relies on a previous patch on the list that changes the readl() to __raw_readl() in the smd driver[1].

Changes since v1:
* Dropped weak from __ioread32_copy()

Stephen Boyd (3):
lib: iomap_copy: Add __ioread32_copy()
soc: qcom: smd: Use __ioread32_copy() instead of open-coding it
FIRMWARE: bcm47xx_nvram: Use __ioread32_copy() instead of open-coding

 drivers/firmware/broadcom/bcm47xx_nvram.c | 11 +++--------
 drivers/soc/qcom/smd.c                    | 13 ++++---------
 include/linux/io.h                        |  1 +
 lib/iomap_copy.c                          | 21 +++++++++++++++++++++
 4 files changed, 29 insertions(+), 17 deletions(-)

[1] http://lkml.kernel.org/g/1441234011-4259-7-git-send-email-sboyd at codeaurora.org

Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
#1 lore raw

PATCH v2 1/3 lib: iomap_copy: Add __ioread32_copy()

Some drivers need to read data out of iomem areas 32-bits at a time. Add an API to do this.

Cc Bjorn Andersson <[email protected]>
---
 include/linux/io.h |  1 +
 lib/iomap_copy.c   | 21 +++++++++++++++++++++
 2 files changed, 22 insertions(+)
include/linux/io.h +1 -0
index de64c1e53612..72c35e0a41d1 100644
@@ -29,6 +29,7 @@ struct device;
 struct resource;
 
 __visible void __iowrite32_copy(void __iomem *to, const void *from, size_t count);
+void __ioread32_copy(void *to, const void __iomem *from, size_t count);
 void __iowrite64_copy(void __iomem *to, const void *from, size_t count);
 
 #ifdef CONFIG_MMU
lib/iomap_copy.c +21 -0
index 4527e751b5e0..b8f1d6cbb200 100644
@@ -42,6 +42,27 @@ void __attribute__((weak)) __iowrite32_copy(void __iomem *to,
 EXPORT_SYMBOL_GPL(__iowrite32_copy);
 
 /**
+ * __ioread32_copy - copy data from MMIO space, in 32-bit units
+ * @to: destination (must be 32-bit aligned)
+ * @from: source, in MMIO space (must be 32-bit aligned)
+ * @count: number of 32-bit quantities to copy
+ *
+ * Copy data from MMIO space to kernel space, in units of 32 bits at a
+ * time.  Order of access is not guaranteed, nor is a memory barrier
+ * performed afterwards.
+ */
+void __ioread32_copy(void *to, const void __iomem *from, size_t count)
+{
+	u32 *dst = to;
+	const u32 __iomem *src = from;
+	const u32 __iomem *end = src + count;
+
+	while (src < end)
+		*dst++ = __raw_readl(src++);
+}
+EXPORT_SYMBOL_GPL(__ioread32_copy);
+
+/**
  * __iowrite64_copy - copy data to MMIO space, in 64-bit or 32-bit units
  * @to: destination, in MMIO space (must be 64-bit aligned)
  * @from: source (must be 64-bit aligned)
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
#2 lore raw

PATCH v2 2/3 soc: qcom: smd: Use __ioread32_copy() instead of open-coding it

In reply to Stephen Boyd

Now that we have a generic library function for this, replace the open-coded instance.

Cc Bjorn Andersson <[email protected]>
---
 drivers/soc/qcom/smd.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)
drivers/soc/qcom/smd.c +4 -9
index e2f85a714243..e81eac28b5ce 100644
@@ -434,20 +434,15 @@ static void smd_copy_to_fifo(void __iomem *dst,
 /*
  * Copy count bytes of data using 32bit accesses, if that is required.
  */
-static void smd_copy_from_fifo(void *_dst,
-			       const void __iomem *_src,
+static void smd_copy_from_fifo(void *dst,
+			       const void __iomem *src,
 			       size_t count,
 			       bool word_aligned)
 {
-	u32 *dst = (u32 *)_dst;
-	u32 *src = (u32 *)_src;
-
 	if (word_aligned) {
-		count /= sizeof(u32);
-		while (count--)
-			*dst++ = __raw_readl(src++);
+		__ioread32_copy(dst, src, count / sizeof(u32));
 	} else {
-		memcpy_fromio(_dst, _src, count);
+		memcpy_fromio(dst, src, count);
 	}
 }
 
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
#3 lore raw

PATCH v2 3/3 FIRMWARE: bcm47xx_nvram: Use __ioread32_copy() instead of open-coding

In reply to Stephen Boyd

Now that we have a generic library function for this, replace the open-coded instance.

Cc Hauke Mehrtens <[email protected]>
Cc Rafa? Mi?ecki <[email protected]>
Cc Paul Walmsley <[email protected]>
Cc linux-mips at linux-mips.org
---
 drivers/firmware/broadcom/bcm47xx_nvram.c | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)
drivers/firmware/broadcom/bcm47xx_nvram.c +3 -8
index e41594510b97..8f46e6e394b1 100644
@@ -56,9 +56,7 @@ static u32 find_nvram_size(void __iomem *end)
 static int nvram_find_and_copy(void __iomem *iobase, u32 lim)
 {
 	struct nvram_header __iomem *header;
-	int i;
 	u32 off;
-	u32 *src, *dst;
 	u32 size;
 
 	if (nvram_len) {
@@ -95,10 +93,7 @@ static int nvram_find_and_copy(void __iomem *iobase, u32 lim)
 	return -ENXIO;
 
 found:
-	src = (u32 *)header;
-	dst = (u32 *)nvram_buf;
-	for (i = 0; i < sizeof(struct nvram_header); i += 4)
-		*dst++ = __raw_readl(src++);
+	__ioread32_copy(nvram_buf, header, sizeof(*header) / 4);
 	header = (struct nvram_header *)nvram_buf;
 	nvram_len = header->len;
 	if (nvram_len > size) {
@@ -111,8 +106,8 @@ found:
 		nvram_len = NVRAM_SPACE - 1;
 	}
 	/* proceed reading data after header */
-	for (; i < nvram_len; i += 4)
-		*dst++ = readl(src++);
+	__ioread32_copy(nvram_buf + sizeof(*header), header + 1,
+			DIV_ROUND_UP(nvram_len / 4));
 	nvram_buf[NVRAM_SPACE - 1] = '\0';
 
 	return 0;
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Acked-by on v2 3/3
#4 lore raw

Re: [PATCH v2 3/3] FIRMWARE: bcm47xx_nvram: Use __ioread32_copy() instead of open-coding

Quoted 8 lines · Stephen Boyd

Now that we have a generic library function for this, replace the open-coded instance.

Cc Hauke Mehrtens <[email protected]>
Cc Rafa? Mi?ecki <[email protected]>
Cc Paul Walmsley <[email protected]>
Cc linux-mips at linux-mips.org

Looking good.

Ralf

maintainer
#5 lore raw
In reply to Stephen Boyd
Quoted 9 lines · On Thu, 17 Sep 2015 12:02:08 -0700 Stephen Boyd <[email protected]> wrote:

The SMD driver is reading and writing chunks of data to iomem, and there's an __iowrite32_copy() function for the writing part, but no __ioread32_copy() function for the reading part. This series adds __ioread32_copy() and uses it in two places. Andrew is on Cc in case this should go through the -mm tree. Otherwise the target of this patch series is SMD, so I've sent it to Andy.

Note this patch series relies on a previous patch on the list that changes the readl() to __raw_readl() in the smd driver[1].

Well that's awkward.

"[PATCH v2 6/8] soc: qcom: smd: Handle big endian CPUs" is one patch in an eight-patch series. My usual approach would be to suck in the whole series, stage it behind linux-next, drop patches if/when others merge them into subsystem trees and thus retain all the dependencies for this patch series in a maintainable-by-me fashion.

But that 8-patch series doesn't apply:

checking file drivers/soc/qcom/smd.c
Hunk #6 FAILED at 360.
Hunk #15 FAILED at 733.
Hunk #16 FAILED at 741.
3 out of 19 hunks FAILED
Failed to apply soc-qcom-smd-handle-big-endian-cpus

ho hum. I think I'll go with plan B: merge just "lib: iomap_copy: Add __ioread32_copy()" and send that into Linus promptly. That way you guys can sort out the driver patches in the usual fashion.

#6 lore raw
Quoted 30 lines · Andrew Morton
Quoted 9 lines · On Thu, 17 Sep 2015 12:02:08 -0700 Stephen Boyd <[email protected]> wrote:

The SMD driver is reading and writing chunks of data to iomem, and there's an __iowrite32_copy() function for the writing part, but no __ioread32_copy() function for the reading part. This series adds __ioread32_copy() and uses it in two places. Andrew is on Cc in case this should go through the -mm tree. Otherwise the target of this patch series is SMD, so I've sent it to Andy.

Note this patch series relies on a previous patch on the list that changes the readl() to __raw_readl() in the smd driver[1].

Well that's awkward.

"[PATCH v2 6/8] soc: qcom: smd: Handle big endian CPUs" is one patch in an eight-patch series. My usual approach would be to suck in the whole series, stage it behind linux-next, drop patches if/when others merge them into subsystem trees and thus retain all the dependencies for this patch series in a maintainable-by-me fashion.

But that 8-patch series doesn't apply:

checking file drivers/soc/qcom/smd.c
Hunk #6 FAILED at 360.
Hunk #15 FAILED at 733.
Hunk #16 FAILED at 741.
3 out of 19 hunks FAILED
Failed to apply soc-qcom-smd-handle-big-endian-cpus

Quoted 4 lines

ho hum. I think I'll go with plan B: merge just "lib: iomap_copy: Add __ioread32_copy()" and send that into Linus promptly. That way you guys can sort out the driver patches in the usual fashion.

I just pulled in the original 8 patches and rebased. My plans were to stage those in linux-next through my for-next. Then add those on top just like you specified. But i could go either way.

Signature · 3 lines
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
maintainer
#7 lore raw
Quoted 8 lines · On Thu, 17 Sep 2015 16:42:18 -0500 Andy Gross <[email protected]> wrote:
Quoted 4 lines

ho hum. I think I'll go with plan B: merge just "lib: iomap_copy: Add __ioread32_copy()" and send that into Linus promptly. That way you guys can sort out the driver patches in the usual fashion.

I just pulled in the original 8 patches and rebased. My plans were to stage those in linux-next through my for-next. Then add those on top just like you specified. But i could go either way.

OK, please do that.