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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
