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?
Maxime