On Sun, Aug 03, 2014 at 10:36:43PM +0200, Luc Verhaegen wrote: > 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.
Depending on what you call runtime. I was thinking about when you generate the DT nodes in u-boot. > > 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. And yet, as an embedded linux consultant, it's something that is asked from us quite regurlarly. So there's definitely a need for this, and nullifying this need because some users might not know what they do might be a bit of an overreaction. > > 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), Yep. > set the simplefb status to disabled (todo), That's actually useless, for two reasons. First the DTB is only looked up once to create the internal list of devices on the platform. Unless told otherwise (for example to parse a custom property), Linux will no longer look anything up in the DT. Once that device list is created, Linux will try to match these devices to drivers. If no drivers is present, then Linux won't try to look this up again (in our case at least). So if you have no matching driver, nothing will happen. You don't have to disable anything in the DT. > and try give the memory back. Perhaps this upcoming dt reserved > memory infrastructure makes that easy. Yep, there's a todo on this too, but I guess it would make sense. > 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. I'd prefer to have this right in the first place. That could even be part of a larger, generic implementation in u-boot that would register this in the DT by itself, but anyway... Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
signature.asc
Description: Digital signature
