On 2/18/07, Paul Mundt <[email protected]> wrote:
Given that, this would have to be something that's dealt with at the
subsystem level rather than in individual drivers, hence the desire to
see something like this more generically visible.
Hi Peter, Paul, fbdev folk,
Ok. Here's what I'm thinking for abstracting this:
fbdev drivers would setup fb_mmap with their own_mmap as usual. In
own_mmap, they would do what they normally do and setup a vm_ops. They
are free to have their own nopage handler but would set the
page_mkwrite handler to be fbdev_deferred_io_mkwrite().
fbdev_deferred_io_mkwrite would build up the list of touched pages and
pass it to a delayed workqueue which would then mkclean on each page
and then pass a copy of that page list down to a driver's callback
function. The fbdev driver's callback function can then do the actual
IO to the framebuffer or coalesce DMA based on the provided page list.
I would like to add something like the following to struct fb_info:
#ifdef CONFIG_FB_DEFERRED_IO
struct fb_deferred_io *defio;
#endif
to store the mutex (to protect the page list), the touched page list,
and the driver's callback function.
I hope this sounds sufficiently generic to meet everyone's (the two of
us? :) needs.
Thanks,
jaya
ps: I've added James and Geert to the CC list. I would appreciate any
advice on whether this is a suitable approach.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
