[RFC] drm: implement generic firmware eviction

[Maxime Ripard]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160826/eb2e27e0/attachment.sig>