Re: [RFC] drm: implement generic firmware eviction

[Maxime Ripard <maxime.ripard@free-electrons.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2447 bytes --]

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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel