Hi, On 26-08-16 14:52, Maxime Ripard wrote: > On Fri, Aug 26, 2016 at 11:02:17AM +0200, Hans de Goede wrote: >> 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? > > When we kickout the framebuffer driver?
Yes that is when we _want_ it to reclaim the RAM, my question was when it will _actually_ happen ? I'm not familiar with the reserved-memory implementation. Does your answer mean that some driver must make an explicit call to get the memory reclaimed ? Regards, Hans
