<div dir="ltr">ah, yeah have to agree it was pretty tough figuring that out at first, I was pretty green with kernel space. But considering i just wrote a working linux DRM kernel driver with minimal knowledge of kernels or even really how embedded devices share memory resources... good job is all I have to say.<div><br></div><div>anyway, what's one small layer of code abstraction when we're doing it all in the name of abstracting our code to non-existance at run-time? These DRM modules are all just directing each other where to find the resources, and since everyone knows what an image is made up of, it's a fairly small overhead to encapsulate across each barrier.  I'd say split it up even more... for example there could be one module that directs the interface between SPI transport layers and graphic buffers/ux, and one that directs instructions/buffers/ux back and forth from userspace to the proper transport layer and proper rendering layer (which we seem to be missing... i'm sure it could be reused in any case where two devices on a separate bus need to communicate either directly to each other or to the rendering layers).  I could have been pretty happy not even having to know what DMA was to code what was missing, which was just the spi transmission instructions.</div></div>