arm: vf610: add NAND flash support

This adds initial support for Freescale NFC (NAND Flash Controller) found in ARM Vybrid SoC's, Power Architecture MPC5125 and others. However, this driver is only tested on Vybrid.

Signed-off-by Stefan Agner <[email protected]>

---
 drivers/mtd/nand/Makefile    |   1 +
 drivers/mtd/nand/vf610_nfc.c | 706
++++++++++++++++++++++++++++++++++++++++++> +
 2 files changed, 707 insertions(+)
 create mode 100644 drivers/mtd/nand/vf610_nfc.c

drivers/mtd/nand/vf610_nfc.c new file +3 -0

new file mode 100644
index 0000000..3150ac1
@@ -0,0 +1,706 @@
+/*
+ * Copyright 2009-2014 Freescale Semiconductor, Inc. and others
+ *

drivers/mtd/nand/vf610_nfc.c new file +4 -0

+/* Count the number of 0's in buff upto max_bits */
+static inline int count_written_bits(uint8_t *buff, int size, int max_bits)
+{
+	uint32_t *buff32 = (uint32_t *)buff;

drivers/mtd/nand/vf610_nfc.c new file +8 -0

+static inline int vf610_nfc_correct_data(struct mtd_info *mtd, u_char *dat)
+{
+	struct vf610_nfc *nfc = mtd_to_nfc(mtd);
+	u8 ecc_status;
+	u8 ecc_count;
+	int flip;
+
+	ecc_status = __raw_readb(nfc->regs + ECC_SRAM_ADDR * 8 + ECC_OFFSET);

if (flip > ecc_count)

+#define DRV_NAME "fsl_nfc"

+static int vf610_nfc_nand_init(int devnum, u8 *addr)

This adds initial support for Freescale NFC (NAND Flash Controller) found in ARM Vybrid SoC's, Power Architecture MPC5125 and others. However, this driver is only tested on Vybrid.

drivers/mtd/nand/vf610_nfc.c new file +0 -0

new file mode 100644
index 0000000..3150ac1

drivers/mtd/nand/vf610_nfc.c new file +23 -0

+
+static inline void vf610_nfc_set(struct mtd_info *mtd, uint reg, u32 bits)
+{
+	vf610_nfc_write(mtd, reg, vf610_nfc_read(mtd, reg) | bits);
+}
+
+static inline void vf610_nfc_clear(struct mtd_info *mtd, uint reg, u32 bits)
+{
+	vf610_nfc_write(mtd, reg, vf610_nfc_read(mtd, reg) & ~bits);
+}
+
+static inline void vf610_nfc_set_field(struct mtd_info *mtd, u32 reg,
+				       u32 mask, u32 shift, u32 val)
+{
+	vf610_nfc_write(mtd, reg,
+			(vf610_nfc_read(mtd, reg) & (~mask)) | val << shift);
+}
+
+/* Clear flags for upcoming command */
+static inline void vf610_nfc_clear_status(struct mtd_info *mtd)
+{
+	u32 tmp = vf610_nfc_read(mtd, NFC_IRQ_STATUS);
+	tmp |= CMD_DONE_CLEAR_BIT | IDLE_CLEAR_BIT;

drivers/mtd/nand/vf610_nfc.c new file +7 -0

+}
+
+/* Read data from NFC buffers */
+static void vf610_nfc_read_buf(struct mtd_info *mtd, u_char *buf, int len)
+{
+	struct vf610_nfc *nfc = mtd_to_nfc(mtd);
+	uint c = nfc->column;

drivers/mtd/nand/vf610_nfc.c new file +18 -0

+		else
+			if (nfc->alt_buf & ALT_BUF_ID)
+				*buf = vf610_nfc_get_id(mtd, c);
+			else
+				*buf = vf610_nfc_get_status(mtd);
+
+		buf += l;
+		len -= l;
+	}
+
+	/* Handle spare area access */
+	if (len) {
+		nfc->column += len;
+		vf610_nfc_read_spare(mtd, buf, len);
+	}
+}
+
+/* Write data to NFC buffers */

Quoted 5 lines · stefan at agner.ch

This adds initial support for Freescale NFC (NAND Flash Controller) found in ARM Vybrid SoC's, Power Architecture MPC5125 and others. However, this driver is only tested on Vybrid.

This is only to expand on the nand controller register and SRAM use.

[snip]

Quoted 5 lines

drivers/mtd/nand/vf610_nfc.c new file +0 -0

new file mode 100644
index 0000000..3150ac1

[snip]

Quoted 10 lines

drivers/mtd/nand/vf610_nfc.c new file +10 -0

+static inline u32 vf610_nfc_read(struct mtd_info *mtd, uint reg)
+{
+	struct vf610_nfc *nfc = mtd_to_nfc(mtd);
+
+	return readl(nfc->regs + reg);
+}
+
+static inline void vf610_nfc_write(struct mtd_info *mtd, uint reg, u32 val)
+{
+	struct vf610_nfc *nfc = mtd_to_nfc(mtd);

drivers/mtd/nand/vf610_nfc.c line 211

Quoted 3 lines

drivers/mtd/nand/vf610_nfc.c new file +3 -0

+
+	writel(val, nfc->regs + reg);
+}

Ok, we always use readl/writel. This is fine, but a little slower and bigger. I may try a register cache if I resubmit to the Linux MTD as per Scott's suggestion. Especially, this version is good for an incremental patch.

I think these are in 'arch/arm/include/asm/io.h' of U-Boot.

#define dmb()           __asm__ __volatile__ ("" : : : "memory")
#define __iormb()       dmb()
#define __iowmb()       dmb()

#define readl(c) ({ u32 __v = __arch_getl(c); __iormb(); __v; })
#define writel(v,c) ({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v; })

Currently, these look like compiler barriers to me. Fine so far.

Quoted 28 lines

drivers/mtd/nand/vf610_nfc.c new file +28 -0

+
+static inline void vf610_nfc_set(struct mtd_info *mtd, uint reg, u32 bits)
+{
+	vf610_nfc_write(mtd, reg, vf610_nfc_read(mtd, reg) | bits);
+}
+
+static inline void vf610_nfc_clear(struct mtd_info *mtd, uint reg, u32 bits)
+{
+	vf610_nfc_write(mtd, reg, vf610_nfc_read(mtd, reg) & ~bits);
+}
+
+static inline void vf610_nfc_set_field(struct mtd_info *mtd, u32 reg,
+				       u32 mask, u32 shift, u32 val)
+{
+	vf610_nfc_write(mtd, reg,
+			(vf610_nfc_read(mtd, reg) & (~mask)) | val << shift);
+}
+
+/* Clear flags for upcoming command */
+static inline void vf610_nfc_clear_status(struct mtd_info *mtd)
+{
+	u32 tmp = vf610_nfc_read(mtd, NFC_IRQ_STATUS);
+	tmp |= CMD_DONE_CLEAR_BIT | IDLE_CLEAR_BIT;
+	vf610_nfc_write(mtd, NFC_IRQ_STATUS, tmp);
+}
+
+/* Wait for complete operation */
+static inline void vf610_nfc_done(struct mtd_info *mtd)

drivers/mtd/nand/vf610_nfc.c line 244

Quoted 5 lines

drivers/mtd/nand/vf610_nfc.c new file +5 -0

+{
+	uint start;
+
+	vf610_nfc_set(mtd, NFC_FLASH_CMD2, START_BIT);
+	barrier();

This barrier() is not needed then. The vf610_nfc_set() should have done it twice already, plus everything is volatile.

[snip]

drivers/mtd/nand/vf610_nfc.c line 386

Quoted 8 lines

drivers/mtd/nand/vf610_nfc.c new file +8 -0

+static inline void vf610_nfc_read_spare(struct mtd_info *mtd, void *buf,
+					int len)
+{
+	struct vf610_nfc *nfc = mtd_to_nfc(mtd);
+
+	len = min(mtd->oobsize, (uint)len);
+	if (len > 0)
+		memcpy(buf, nfc->regs + mtd->writesize, len);

Notice the 'memcpy(.. nfc->regs);'...

Quoted 7 lines

drivers/mtd/nand/vf610_nfc.c new file +7 -0

+}
+
+/* Read data from NFC buffers */
+static void vf610_nfc_read_buf(struct mtd_info *mtd, u_char *buf, int len)
+{
+	struct vf610_nfc *nfc = mtd_to_nfc(mtd);
+	uint c = nfc->column;

drivers/mtd/nand/vf610_nfc.c line 403

Quoted 10 lines

drivers/mtd/nand/vf610_nfc.c new file +10 -0

+	uint l;
+
+	/* Handle main area */
+	if (!nfc->spareonly) {
+
+		l = min((uint)len, mtd->writesize - c);
+		nfc->column += l;
+
+		if (!nfc->alt_buf)
+			memcpy(buf, nfc->regs + NFC_MAIN_AREA(0) + c, l);

Another 'memcpy(.. nfc->regs);'...

Quoted 18 lines

drivers/mtd/nand/vf610_nfc.c new file +18 -0

+		else
+			if (nfc->alt_buf & ALT_BUF_ID)
+				*buf = vf610_nfc_get_id(mtd, c);
+			else
+				*buf = vf610_nfc_get_status(mtd);
+
+		buf += l;
+		len -= l;
+	}
+
+	/* Handle spare area access */
+	if (len) {
+		nfc->column += len;
+		vf610_nfc_read_spare(mtd, buf, len);
+	}
+}
+
+/* Write data to NFC buffers */

drivers/mtd/nand/vf610_nfc.c line 431

Quoted 10 lines

drivers/mtd/nand/vf610_nfc.c new file +10 -0

+static void vf610_nfc_write_buf(struct mtd_info *mtd, const u_char *buf,
+				int len)
+{
+	struct vf610_nfc *nfc = mtd_to_nfc(mtd);
+	uint c = nfc->column;
+	uint l;
+
+	l = min((uint)len, mtd->writesize + mtd->oobsize - c);
+	nfc->column += l;
+	memcpy(nfc->regs + NFC_MAIN_AREA(0) + c, buf, l);

Another 'memcpy(.. nfc->regs);'...

[snip]

These memcpy's are the same 'bus' interface as the registers. We should be just as worried about this SRAM buffer memory as the memory mapped registers, shouldn't we? Is a barrier() before reading and a barrier() after writing fine for U-Boot? Personally, I think they are safe as only the 'vf610_nfc_set(mtd, NFC_FLASH_CMD2, START_BIT)' needs some

raw_writel() is itself something that should only be used for hand-optimized sections. For non-performance-critical code you should use normal writel() so that you don't need to worry about manually adding I/O barriers.

care. Maybe a comment is fine? It seems the Vybrid is safe for different access sizes, but it is possible that some other CPU might not be able to access this memory via 32/16/8 bit accesses and 'memcpy()' may not be appropriate. It seems that 'natural' size of the NFC controller itself is 32bits and the CPU interface does lane masking. Ie, boot mode documentation talks about remapping 'sram_physical_addr[13:3] = {cpu_addr[11:3],cpu_addr[13:12]}' saying that bits 2,1 are not used (hopefully one based numbers). This is just my guess...

The VF6xx page has a documentation tab,
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=VF6xx

There is an app note, AN4947 'Understanding Vybrid Architecture', which describes some timing details for the AHB bus (where this flash controller is connected). Pg21 Table 7 of that document gives some measurements. The QSPI is a similar peripheral on the AHB. The first and second lines give accesses of 4408 and subsequent accesses are 2770 Cortex-A5 clocks. Normal SDRAM is 258 and 8 clocks. Ie, it is quite important in places to minimize accesses and try to make them sequential.

However, it looks like most U-Boot NAND drivers use the memcpy()? With
the exceptions of fsl_elbc_nand.c, fsl_ifc_nand.c, and mpc5121_nfc.c. Maybe it doesn't matter...

Am 2014-08-14 23:12, schrieb Bill Pringlemeir:

Quoted 16 lines

Quoted 5 lines · stefan at agner.ch

This adds initial support for Freescale NFC (NAND Flash Controller) found in ARM Vybrid SoC's, Power Architecture MPC5125 and others. However, this driver is only tested on Vybrid.

This is only to expand on the nand controller register and SRAM use.

[snip]

Quoted 3 lines

(quoted diff) +0 -0

b/drivers/mtd/nand/vf610_nfc.c new file mode 100644 index 0000000..3150ac1 --- /dev/null +++ b/drivers/mtd/nand/vf610_nfc.c

[snip]

Quoted 6 lines

Quoted 1 line

+static inline u32 vf610_nfc_read(struct mtd_info *mtd, uint reg) +{

Ok, we always use readl/writel. This is fine, but a little slower and bigger. I may try a register cache if I resubmit to the Linux MTD as per Scott's suggestion. Especially, this version is good for an incremental patch.

I measured the difference and get 1MB/s Full pages, readl/writel:
NAND read: device 0 offset 0x200000, size 0x800000 8388608 bytes read in 772 ms (10.4 MiB/s): OK

Full pages, __raw_readl/__raw_writel
NAND read: device 0 offset 0x200000, size 0x800000 8388608 bytes read in 696 ms (11.5 MiB/s): OK

Ok, this is actually quite a lot. Especially since I already optimized the C code (by not using the helper functions like nfc_set/nfc_clear in vf610_nfc_send_command), one would think there is now almost no optimization potential. I looked into the disassembled code and could narrow down the issue. Due to the memory barriers, all offsets were calculated on each register access (nfc base to reg base, and add reg offset), multiple instances of:

20: e59cc120 ldr ip, [ip, #288] ; 0x120
24: e59cc134 ldr ip, [ip, #308] ; 0x134

I optimized the code again and calculate the offsets manually and access __raw_readl/__raw_writel rather then vf610_nfc_read/write in the vf610_nfc_send_command(s) function, I get the full speed again:

NAND read: device 0 offset 0x200000, size 0x800000 8388608 bytes read in 687 ms (11.6 MiB/s): OK

Quoted 4 lines

raw_writel() is itself something that should only be used for hand-optimized sections. For non-performance-critical code you should use normal writel() so that you don't need to worry about manually adding I/O barriers.

The reason I choosed readl/writel instead of the raw variants is to preserve align with other drivers...

Quoted 9 lines

care. Maybe a comment is fine? It seems the Vybrid is safe for different access sizes, but it is possible that some other CPU might not be able to access this memory via 32/16/8 bit accesses and 'memcpy()' may not be appropriate. It seems that 'natural' size of the NFC controller itself is 32bits and the CPU interface does lane masking. Ie, boot mode documentation talks about remapping 'sram_physical_addr[13:3] = {cpu_addr[11:3],cpu_addr[13:12]}' saying that bits 2,1 are not used (hopefully one based numbers). This is just my guess...

What assumptions do you make how memcpy accesses memory? This latest patch now uses the optimized versions from the kernel... Maybe they even try to access 64-bit width (the NIC interconnect supports 64-bit access)

Quoted 45 lines

Am 2014-08-14 23:12, schrieb Bill Pringlemeir:

Quoted 16 lines

Quoted 5 lines · stefan at agner.ch

This adds initial support for Freescale NFC (NAND Flash Controller) found in ARM Vybrid SoC's, Power Architecture MPC5125 and others. However, this driver is only tested on Vybrid.

This is only to expand on the nand controller register and SRAM use.

[snip]

Quoted 3 lines

(quoted diff) +0 -0

b/drivers/mtd/nand/vf610_nfc.c new file mode 100644 index 0000000..3150ac1 --- /dev/null +++ b/drivers/mtd/nand/vf610_nfc.c

[snip]

Quoted 6 lines

Quoted 1 line

+static inline u32 vf610_nfc_read(struct mtd_info *mtd, uint reg) +{

Ok, we always use readl/writel. This is fine, but a little slower and bigger. I may try a register cache if I resubmit to the Linux MTD as per Scott's suggestion. Especially, this version is good for an incremental patch.

I measured the difference and get 1MB/s Full pages, readl/writel:
NAND read: device 0 offset 0x200000, size 0x800000 8388608 bytes read in 772 ms (10.4 MiB/s): OK

Full pages, __raw_readl/__raw_writel
NAND read: device 0 offset 0x200000, size 0x800000 8388608 bytes read in 696 ms (11.5 MiB/s): OK

Ok, this is actually quite a lot. Especially since I already optimized the C code (by not using the helper functions like nfc_set/nfc_clear in vf610_nfc_send_command), one would think there is now almost no optimization potential. I looked into the disassembled code and could narrow down the issue. Due to the memory barriers, all offsets were calculated on each register access (nfc base to reg base, and add reg offset), multiple instances of:

20: e59cc120 ldr ip, [ip, #288] ; 0x120
24: e59cc134 ldr ip, [ip, #308] ; 0x134

Quoted 6 lines

I optimized the code again and calculate the offsets manually and access __raw_readl/__raw_writel rather then vf610_nfc_read/write in the vf610_nfc_send_command(s) function, I get the full speed again:

NAND read: device 0 offset 0x200000, size 0x800000 8388608 bytes read in 687 ms (11.6 MiB/s): OK

I think what you have is fine. The 10BM/s versus 11MB/s is not insignificant, but it is not a huge difference. I expect that the driver is already better than the others; especially the Imx-25 was only 7.7MB/s read and 4.6Mb/s write from Linux mtd tests. Although the end user might like to wait 10% less for an image to load.

Also, probably a lot of people care about code size. This is not so much a case for U-Boot as it is usually machine specific and doesn't support several SOCs afaik.

However, the more specific you make the optimization to the platform, the less likely it is to extend well. We also wish to have this work well with different gcc versions and CPUs (PowerPC, etc). The 'readl/writel' handicap the compiler. Although they are more likely to work with a wide variety of buses.

[snip]

Quoted 19 lines · Scott Wood

Quoted 4 lines

raw_writel() is itself something that should only be used for hand-optimized sections. For non-performance-critical code you should use normal writel() so that you don't need to worry about manually adding I/O barriers.

The reason I choosed readl/writel instead of the raw variants is to preserve align with other drivers...

Quoted 9 lines

care. Maybe a comment is fine? It seems the Vybrid is safe for different access sizes, but it is possible that some other CPU might not be able to access this memory via 32/16/8 bit accesses and 'memcpy()' may not be appropriate. It seems that 'natural' size of the NFC controller itself is 32bits and the CPU interface does lane masking. Ie, boot mode documentation talks about remapping 'sram_physical_addr[13:3] = {cpu_addr[11:3],cpu_addr[13:12]}' saying that bits 2,1 are not used (hopefully one based numbers). This is just my guess...

Quoted 4 lines

What assumptions do you make how memcpy accesses memory? This latest patch now uses the optimized versions from the kernel... Maybe they even try to access 64-bit width (the NIC interconnect supports 64-bit access)

The memcpy() itself could use anything. 64bits is possible on AXI/NIC. The 'PBRIDGE' is 64bit, but I think the AIPS/IPS (apparently AIPS means 'AHB-lite to IPS) are 32bit. At least that is the case on the Imx25 which has a different AIPS version. I assumed the 'memcpy()' was using 32bits but this certainly isn't explicit in the code.

The majority of the register banks are non-volatile with this controller. Instead of running multiple NAND programming sequences, the controller runs them all for us. Most registers are are mainly like SRAM.

My only point is that the SRAM buffers use the same interface as the main Nand controller register banks. So using 'readl/writel' for the register, but not the SRAM buffers seems inconsistent.

So to address this inconsistency, I was thinking that we should at least have a comment?

/* BUS: This assumes the BUS is 32 bit accessible. If you are porting
to other systems, this may not be the case.
*/
memcpy(nfc->regs + NFC_MAIN_AREA(0) + c, buf, l);

Or we could implement our own version of memcpy that did 32bit aligned transfers with a similar comment. In theory, we need a barrier after the memcpy(), in case anyone modified the code to touch the NFC_FLASH_CMD2's START_BIT directly after the memcpy() or custom function. But all the paranoia adds some code and has potential to slow things down.

Doing a barrier after every single byte read as the ARM Linux's memcpy_fromio() does will surely make significant performance differences. Instead of being double the Imx25, it was half. A user waiting 400% longer won't be too happy.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines · stefan at agner.ch

This adds initial support for Freescale NFC (NAND Flash Controller) found in ARM Vybrid SoC's, Power Architecture MPC5125 and others. However, this driver is only tested on Vybrid.

Quoted 8 lines

Quoted 8 lines · Scott Wood

Quoted 5 lines

raw_writel() is itself something that should only be used for hand-optimized sections. For non-performance-critical code you should use normal writel() so that you don't need to worry about manually adding I/O barriers.

Am 2014-08-14 23:12, schrieb Bill Pringlemeir:

Quoted 15 lines

Quoted 9 lines

Quoted 9 lines

Maybe a comment is fine? It seems the Vybrid is safe for different access sizes, but it is possible that some other CPU might not be able to access this memory via 32/16/8 bit accesses and 'memcpy()' may not be appropriate. It seems that 'natural' size of the NFC controller itself is 32bits and the CPU interface does lane masking. Ie, boot mode documentation talks about remapping 'sram_physical_addr[13:3] = {cpu_addr[11:3],cpu_addr[13:12]}' saying that bits 2,1 are not used (hopefully one based numbers). This is just my guess...

Quoted 4 lines · stefan at agner.ch

What assumptions do you make how memcpy accesses memory? This latest patch now uses the optimized versions from the kernel... Maybe they even try to access 64-bit width (the NIC interconnect supports 64-bit access)

Am 2014-08-18 18:38, schrieb Bill Pringlemeir:

Quoted 6 lines

My only point is that the SRAM buffers use the same interface as the main Nand controller register banks. So using 'readl/writel' for the register, but not the SRAM buffers seems inconsistent.

So to address this inconsistency, I was thinking that we should at least have a comment?

IMHO, we just treat this as if its memory and I guess this is fine for a buffer. memcpy knows how to copy data, and takes care if the architecture needs aligned access when reading 32-bit width, or similar requirements. We do not know whether memcpy really uses 32-bit accesses, hence this comment might even be wrong. In a short test, I could also access the buffer in byte/word length (tested using md.b/md.w).

Also, I assume this just works for a different architecture too. If not, the one using this driver the first time on a different architecture would see this pretty quickly I guess :-)

In our case, a barrier just after the memcpy would be sufficient.

Quoted 7 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines · stefan at agner.ch

This adds initial support for Freescale NFC (NAND Flash Controller) found in ARM Vybrid SoC's, Power Architecture MPC5125 and others. However, this driver is only tested on Vybrid.

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines · Scott Wood

Quoted 5 lines

raw_writel() is itself something that should only be used for hand-optimized sections. For non-performance-critical code you should use normal writel() so that you don't need to worry about manually adding I/O barriers.

Am 2014-08-14 23:12, schrieb Bill Pringlemeir:

[regarding memcpy() in the driver]

Quoted 15 lines

Quoted 15 lines

Quoted 9 lines

Quoted 9 lines

Maybe a comment is fine? It seems the Vybrid is safe for different access sizes, but it is possible that some other CPU might not be able to access this memory via 32/16/8 bit accesses and 'memcpy()' may not be appropriate. It seems that 'natural' size of the NFC controller itself is 32bits and the CPU interface does lane masking. Ie, boot mode documentation talks about remapping 'sram_physical_addr[13:3] = {cpu_addr[11:3],cpu_addr[13:12]}' saying that bits 2,1 are not used (hopefully one based numbers). This is just my guess...

Quoted 4 lines · stefan at agner.ch

What assumptions do you make how memcpy accesses memory? This latest patch now uses the optimized versions from the kernel... Maybe they even try to access 64-bit width (the NIC interconnect supports 64-bit access)

[snip]

Quoted 8 lines

Am 2014-08-18 18:38, schrieb Bill Pringlemeir:

Quoted 6 lines

My only point is that the SRAM buffers use the same interface as the main Nand controller register banks. So using 'readl/writel' for the register, but not the SRAM buffers seems inconsistent.

So to address this inconsistency, I was thinking that we should at least have a comment?

Quoted 11 lines · stefan at agner.ch

IMHO, we just treat this as if its memory and I guess this is fine for a buffer. memcpy knows how to copy data, and takes care if the architecture needs aligned access when reading 32-bit width, or similar requirements. We do not know whether memcpy really uses 32-bit accesses, hence this comment might even be wrong. In a short test, I could also access the buffer in byte/word length (tested using md.b/md.w).

Also, I assume this just works for a different architecture too. If not, the one using this driver the first time on a different architecture would see this pretty quickly I guess :-)

[snip]

Quoted 1 line

In our case, a barrier just after the memcpy would be sufficient.

I would suggest you make a 'vf610_nfc_memcpy()' [or even from/to variants if you are pendantic] which can be a wrapper function of just 'memcpy'. Just the like the readl/writel wrappers this will collect the BUS accesses into one place. So they are documented for people porting the code. Trying to accommodate some future insane hardware hookup seems futile beyond this?

Otherwise, I will add an 'Ack' or 'Reviewed-By' from me if you like. I am sorry, I don't know what if anything is appropriate.