On Sun, Aug 03, 2014 at 02:18:13PM +0200, Maxime Ripard wrote: > Hi, > > Thanks for working on this > > On Sat, Aug 02, 2014 at 04:06:09PM +0200, Luc Verhaegen wrote: > > +#define CONFIG_SYS_MEM_TOP_HIDE ((CONFIG_SUNXI_FB_SIZE + 0xFFF) & ~0xFFF) > > I'm not too fond of this approach. I'd rather see this code generates > a reserved-memory node in the DT, as described here: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > There's still a few patches pending that are not too far off and > should be merged soon to be able to use it at will: > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/272071.html > > But that should provide Linux a way to not touch the memory at all, > while doing a proper memory allocation, and without having to cheat > like you're currently doing. > > Maxime
Thanks for the heads up on this, as i was not aware of this upcoming code. This "cheating" works for everyone else today. x86 BIOSes on IGP machines have always worked that way, and that's how it was implemented for unichrome in coreboot as well. Iirc, the intel driver goes and reclaims the boot fb separately as well, i remember some code flying by on that. This to me means that today, intel IGPs no longer reserve the full FB from ram beforehand, but rather reserve a small area instead, which then needs to be reclaimed in a more special way than before (where it was just in a PCI BAR). So this "cheating" is the norm. One big open question mark with the dt solution is... What is this memory that we reserved compatible with? At which point can this memory be added to the cma pool? The answer to that is: * when simplefb is not in use at all. * when simplefb has been superseded by a proper display driver. It does not seem that the above can be cleanly handled by just general DT code. We will always lose that memory until the kms driver, which has the knowledge to match up registers and the simple-framebuffer dt info, and which knows how to correctly disable/reconfigure the display engines used for simple fb, goes and corrects the situation. Also, the example shown is a bit awkward for our hardware. There's framebuffers, scalers, media decoding... Our display engine (and probably g2d and cedar) at most need contiguous memory. They do not care where exactly it lives, it just needs to be contiguous. We only need to reserve memory here because there is no way that we can change anything about our simplefb setup afterwards. We need specialized platform specific knowledge, and a very clueful platform specific display driver, to be able to pull that off. So yes, in future the way in which this memory is reserved could be improved. But the above solution is quite solid, and very acceptable, one would even call it established. Furthermore, this upcoming dt solution does not bring us any immediate benefits, apart from fitting more completely in DT thinking. Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
