Re: [RFC] drm: implement generic firmware eviction

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux