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ł -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
