On 03/17/2017 07:13 AM, Ulf Hansson wrote:
On 10 March 2017 at 14:25, Jan Glauber <jglauber@xxxxxxxxxx> wrote:
Prevent data corruption on cn6xxx and cnf7xxx.
Due to an imperfection in the design of the MMC bus hardware,
the 2nd to last cache block of a DMA read must be locked into the L2
cache.
[...]
+/**
+ * Unlock a memory region in the L2 cache
+ *
+ * @start - start address to unlock
+ * @len - length to unlock in bytes
+ */
+void l2c_unlock_mem_region(u64 start, u64 len)
+{
+ u64 end;
+
+ /* Round start/end to cache line boundaries */
+ end = ALIGN(start + len - 1, CVMX_CACHE_LINE_SIZE);
+ start = ALIGN(start, CVMX_CACHE_LINE_SIZE);
+
+ while (start <= end) {
+ l2c_unlock_line(start);
+ start += CVMX_CACHE_LINE_SIZE;
+ }
+}
+EXPORT_SYMBOL_GPL(l2c_unlock_mem_region);
It seems like we should be able to implement these functions in the
octeon mmc driver, instead of having to export some SoC specific APIs.
You only need to figure out how to find the correct CACHE_LINE_SIZE,
but that should be possible to fix.
It doesn't matter which source file the code lives in. If you are happy
having it in drivers/mmc/host/cavium-pltfm-octeon.c (or whatever we end
up calling the file), it could be put there.
CVMX_CACHE_LINE_SIZE == 128. It will never change.
My point is really that we should avoid exporting SoC specific APIs
which shall be called from drivers. This is old fashion.
Some people find it objectionable to see 1-off architecture specific
in-line asm in a driver file, but I agree that putting it as close to
the user as possible makes sense.
David Daney
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
