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