Hi, On 26-08-16 10:58, Maxime Ripard wrote: > Hi, > > On Fri, Aug 26, 2016 at 10:43:55AM +0200, Hans de Goede wrote: >>>> I'm not sure we would want to remove the device at all, we >>>> certainly should not be removing the dt_node from the devicetree >>>> IMHO. Having that around to see how the bootloader set things up >>>> is really useful for debugging and normally we should never modify >>>> the devicetree as set up by the bootloader. >>>> >>>> Why not just unbind the driver from the platform device? That >>>> should be enough. >>> >>> That will leave IORESOURCE_MEM around, causing conflicts if >>> re-used/claimed by other devices/drivers. Furthermore, it is really >>> fragile leaving the device around, without any control over >>> possible future driver probing. >> >> Ah, good point. On ARM this currently typically is reserved by the bootloader >> so never touched by the kernel at all, not even when the simplefb is no >> longer >> used, actually returning this memory to the kernel after unbinding the >> simplefb / >> destroying the simplefb platform-dev would be really good to do. We should >> probably figure out how that should be done before getting rid of >> remove_conflicting_framebuffers... (sorry). > > That would be rather easy to do. The firmware could generate a > reserved-memory node instead of passing a smaller memory size to the > kernel. That way, the kernel will know that it's actual ram that it > can reclaim.
So when would the kernel reclaim the RAM then? We do not want it to reclaim before loading the simplefb / simpledrm driver. And the real drm driver will likely be a module, so if the kernel reclaims just before executing /sbin/init that would be too early, unless we can somehow manually make it do another reclaim pass when the simplefb gets disabled ... Regards, Hans
