[RFC] drm: implement generic firmware eviction

Hans de Goede hdegoede at redhat.com
Fri Aug 26 09:02:17 UTC 2016


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? We do not want it
to reclaim before loading the simplefb / simpledrm driver.

And the real drm driver will likely be a module, so if the kernel
reclaims just before executing /sbin/init that would be too
early, unless we can somehow manually make it do another reclaim
pass when the simplefb gets disabled ...

Regards,

Hans


More information about the dri-devel mailing list