On Sun, Aug 03, 2014 at 09:39:23PM +0200, Maxime Ripard wrote: > On Sun, Aug 03, 2014 at 05:51:49PM +0200, Luc Verhaegen wrote: > > > > 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. > > 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.
Ah, at runtime. Yeah, sure. Disable the simplefb node, null the memory prop there, claim it in a kms node so that future driver reloads will pick up on it. > And losing it is actually good if we want to have to have a > glitch-less transition from u-boot to linux. I do not care about this. Over my many years as a display driver developer, i have heard many people idly talk about this, but then, at the same time, they'd fail to set a working mode at all, or end up showing garbage memory content for 20s. > But Linux should have a clue about the lost region. > > 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. > > 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. Ah, now i think i understand what you are on about. If simplefb is not enabled in the kernel, I should go and disable the engine (automatic, by not infrastructure enabling the clocks), set the simplefb status to disabled (todo), and try give the memory back. Perhaps this upcoming dt reserved memory infrastructure makes that easy. But for now, let's just consider this memory lost. For now, people will have to make do with simplefb. I will dig deeper into this when i make my kms code smarter with memory. 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.
