Den 04.09.2018 08.18, skrev Daniel Vetter:
On Tue, Sep 4, 2018 at 1:41 AM, Dave Airlie <airlied@xxxxxxxxx> wrote:
I've seen that you dropped this patch:
https://patchwork.kernel.org/patch/10445393/
Is that patch correct or incorrect? In case it is incorrect, do you have
an idea how should fbdefio be used properly on KMS drivers?
I suppose I was wondering what use fbdefio really has, modern code
should be using KMS interface and the KMS dirty handling should be
able to cover those cases.
I don't really like the maintainability decrease moving to in-driver
page handling causes vs using shmem.
I think tinydrm has the same problem of shmem+fbdefio, could be worth
it to chat with Noralf. Adding him.
fbdev deferred I/O is used to catch page faults when fbdev has been
mmap'ed. The faults are queued up and a worker runs after a certain time.
The problem as mentioned is that both shmem and defio use page->lru
(and page->mapping).
In the generic fbdev emulation, drm_fb_helper.c:drm_fbdev_generic_setup(),
I solved this by using a shadow vmalloc buffer that is blitted on the
real one and then dirtyfb is called. The driver needs to support
drm_driver->gem_prime_vmap and ->gem_prime_mmap to use it though and udl
has it's own dma-buf handling.
I've just posted a shmem library that maybe udl could use:
https://patchwork.freedesktop.org/series/27184/
With that udl could use the generic fbdev emulation.
Noralf.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
