[RFC PATCH 1/3] amba-clcd: Add Device Tree support to amba-clcd driver

[Pawel Moll]

On Fri, 2012-09-21 at 11:35 +0100, Ryan Harkin wrote:
> Good point.  Sorry for my ignorance, but is there a place I should put
> such documentation?

Documentation/devicetree/bindings/fb/amba-clcd.txt :-)

> When the A9 CoreTile uses the on-tile CLCD controller, it can use DMA
> to handle the framebuffer.  DMA is not available to the motherboard
> CLCD controller.

Uh, you probably mean that the motherboard CLCD must use the specialised
video memory, while the one in the test chip would normally use a buffer
allocated via the DMA API...

> I was trying to keep the properties simple, but they are more complex
> than just the two settings: use_dma and framebuffer.  If use_dma is
> specified, the framebuffer property is not used; in this case, the
> framebuffer is allocated by the DMA framework and the framebuffer
> property is ignored.  If use_dma is not present or is set to <0>, the
> code uses the framebuffer property to specify the address.

I'm not sure if the "framebuffer" property is really needed, at least in
the form you have it there now. I think I know you where you get it from
- HDLCD driver, right? It was sort-of-needed there, because we had to
reserve memory for the framebuffer, because you couldn't allocate big
enough (8MB if I remember correctly) area using the DMA alloc function.
But now, with the CMA in place it should be possible, so I believe it's
not even necessary in that case. Simply speaking - if the driver is not
told what address to use, it should get the memory on its own.

Now, as to the motherboard CLCD... That's where you actually could use
this property in the way you have there, to enforce the address of the
video RAM as the framebuffer. But maybe it would be better to have a
phandle to the video RAM node?

Cheers!

Paweł