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 -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Attachment:
signature.asc
Description: PGP signature
