Re: [RFC] drm: implement generic firmware eviction

From: Hans de Goede <hdegoede@redhat.com>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: devicetree <devicetree@vger.kernel.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Rob Herring <robh+dt@kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	Maxime Ripard <maxime.ripard@free-electrons.com>
Subject: Re: [RFC] drm: implement generic firmware eviction
Date: Fri, 26 Aug 2016 10:43:55 +0200	[thread overview]
Message-ID: <345e23d3-b55b-4d4d-e585-0ec8b243feb8@redhat.com> (raw)
In-Reply-To: <CANq1E4QFB4k+8C4eZUuUwO7mYDDYrKx2wbPJfAKe_GoOLOHv=A@mail.gmail.com>

Hi,

On 26-08-16 10:01, David Herrmann wrote:
> Hi
>
> On Fri, Aug 26, 2016 at 9:57 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 26-08-16 02:00, David Herrmann wrote:
>>>
>>> Provide a generic DRM helper that evicts all conflicting firmware
>>> framebuffers, devices, and drivers. The new helper is called
>>> drm_evict_firmware(), and takes a flagset controlling which firmware to
>>> kick out.
>>>
>>> This is meant to be used by drivers in their ->probe() callbacks of their
>>> parent bus, before calling into drm_dev_register().
>>>
>>> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>>> ---
>>> Hey
>>>
>>> This is just compile-tested for now. I just want to get some comments on
>>> the
>>> design. I decided to drop the sysfb infrastructure and rather just use
>>> this
>>> generic helper. It keeps things simple and should work just fine for all
>>> reasonable use-cases.
>>>
>>> This will work with SimpleDRM out-of-the-box on x86.
>>>
>>> Architectures with dynamic simple-framebuffer devices are not supported
>>> yet. I
>>> actually have no idea what the strategy there is? Can the DeviceTree
>>> people come
>>> up with something? Am I supposed to call of_platform_depopulate()? Or
>>> of_detach_node()? Or what?
>>
>>
>> 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).

Regards,

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