Hi,
On 26-08-16 10:01, David Herrmann wrote:
Hi
On Fri, Aug 26, 2016 at 9:57 AM, Hans de Goede <hdegoede@xxxxxxxxxx> 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@xxxxxxxxx>
---
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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
