On Fri, Sep 23, 2022, at 3:54 PM, Linus Walleij wrote:
> On Fri, Sep 23, 2022 at 3:21 PM Arnd Bergmann <arnd@xxxxxxxx> 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
