On Sun, Aug 03, 2014 at 05:51:49PM +0200, Luc Verhaegen wrote: > 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.
If you set the reusable property, it will be used to store volatile and cache data, that can easily be reclaimed if some driver might come and claim it. That would prove to be quite ineffective in our case, since in the case where we would have simplefb in use, that might introduce a glitch on the screen between the time where the kernel starts and simplefb claims the memory. I guess we could easily add an optional "garbage collection" mechanism to deal with unclaimed reserved memory region. > * 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. Keep the reserved-memory region, but instead of putting the memory-region property in the simplefb node, put it in the relevant node of the KMS IPs. And losing it is actually good if we want to have to have a glitch-less transition from u-boot to linux. But Linux should have a clue about the lost region. > 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. AFAIK, the reserved-memory region, if set and that another device points at it, will only be used by this device. CMA allocation by other devices will just be made in the generic CMA pool, which pretty much fits the "we don't care where it should be as long as its contiguous", pool that has a size you can define through Kconfig. > 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. Yeah, plus making Linux actually aware of these pages, being either able to reclaim them back if they're not used or to give it back to your KMS driver. So it's not really just about it being shiny. -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
signature.asc
Description: Digital signature
