On Fri, Aug 26, 2016 at 02:58:51PM +0200, Hans de Goede wrote: > 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 ? The reserved-memory implementation is relying on memblock. I don't think there is a function yet to remove a reserved memory region, but its implementation would use memblock_free I guess. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
