On Fri, Sep 23, 2022, at 3:54 PM, Linus Walleij wrote:
On Fri, Sep 23, 2022 at 3:21 PM Arnd Bergmann arnd@arndb.de wrote:
On Fri, Sep 23, 2022, at 2:56 PM, Linus Walleij wrote:
but then the vram itself is also in that address range, which would indicate that it is behind that bus.
Yep it is.
Ok.
However, using the 'reserved-memory' property indicates that this is actually just normal RAM that is carved out from what the OS manages.
The binding document Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml unfortunately does not mention anywhere that the reserved memory must be a subset of the system main RAM "carveout" or anything like that, it says that the memory should be "designed for special usage by various device drivers", and "excluded from normal usage" which it is, hence the misunderstanding.
We have used this for Vexpress like forever, but I did the change from some custom vexpress memory property to shared-dma-pool so I guess that's my fault. Incidentally this also works very well.
Is there some other mechanism we should be using for dedicated framebuffer memory on some odd address?
I think the correct way to do this would have been to have a 'reg' property in the device itself that points to the VRAM, instead of describing it as memory.
This in turn would mean that the driver would use some variant of ioremap_wc() to map the framebuffer into kernel space, rather than using dma_alloc_coherent().
I guess the author of the driver copied the code from another fbdev driver that was meant for an Arm SoC with a shared memory framebuffer rather than a dedicated VRAM...
It's probably too late to change now, and the new dma-ranges property is at least consistent with the usage.
Can you update the changelog text based on the above and send the patch again with the dma-coherent property removed?
Arnd