Running X on my Orange Pi PC2 results in some interesting artifacts
that are clearly cache-related. That made me realize that we're
mapping the framebuffer as device memory in our kernel and as normal
WB-cachable memory in X. That is a seriously bad idea.
The diff below switches the userland mappings to non-cachable. That
is still not perfect as mapping the same memory with different memory
attributes is discouraged. But at least the architecture treats this
as a seperate case with well-defined semantics. It certainly is an
improvement over the current situation and removes the artifacts I'm
seeing.
ok?
Ultimately we want to fix this and use the "right" memory attributes
for both the kernel and userland mappings. I'm not entirely sure yet
what those are. We certainly don't want WB-cachable, and I don't
think there is a benefit in using WT-cachable as X uses shadowing to
avoid reading from the framebuffer. If possible, we want to be able
to use "Gathering" which I believe is ARM speak for write-combining.
But whether we need "normal" or "device" memory isn't clear to me.
Currently all framebuffers I've seen are living in normal DRAM.
Index: dev/fdt/simplefb.c
===================================================================
RCS file: /cvs/src/sys/dev/fdt/simplefb.c,v
retrieving revision 1.2
diff -u -p -r1.2 simplefb.c
--- dev/fdt/simplefb.c 27 Aug 2017 12:42:22 -0000 1.2
+++ dev/fdt/simplefb.c 17 Dec 2017 14:04:34 -0000
@@ -19,6 +19,8 @@
#include <sys/systm.h>
#include <sys/device.h>
+#include <uvm/uvm_extern.h>
+
#include <machine/bus.h>
#include <machine/fdt.h>
@@ -276,7 +278,7 @@ simplefb_wsmmap(void *v, off_t off, int
if (off < 0 || off >= sc->sc_psize)
return -1;
- return sc->sc_paddr + off;
+ return ((sc->sc_paddr + off) | PMAP_NOCACHE);
}
int
