Messages in this thread | | | Date | Wed, 21 Feb 2007 11:46:21 -0500 | From | "Jaya Kumar" <> | Subject | Re: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver |
| |
On 2/20/07, Jaya Kumar <jayakumar.lkml@gmail.com> wrote: > On 2/19/07, Paul Mundt <lethal@linux-sh.org> wrote: > > That works for me, though I'd prefer for struct page_list to be done with > > a scatterlist, then it's trivial to setup from the workqueue context > > without having to shuffle things around. > > > > Ok. Will check out when implementing. >
Took a quick look. If I used scatterlist, I'd still need to build a list of scatterlist to pass to the driver callback. The alternative being a preallocated array of scatterlist based on the page count of the framebuffer, which seems expensive since scatterlist has page, offset, dma and length.
On a separate note, Peter pointed out that it may be possible to reuse page->lru instead of using a struct page_list. This would enable something like:
in mkwrite: mutex_lock list_add(page->lru, defio->pagelist) mutex_unlock
in deferred handler: mutex_lock for_each page { lock_page mkclean unlock_page } callback(fb_info, pagelist) for_each page { list_del } mutex_unlock
The advantage of reusing page->lru is that avoids needing the struct page_list and allocation in mkwrite. Is the above exploitation of ->lru ok with mm folk?
In above, we're iterating over the page list twice. I have to mkclean before calling the callback to avoid the situation where a touched page is missed by the callback. I don't see a way around that part.
Thanks, jaya - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |