Re: [PATCH/RFC 2.6.20-rc4 1/1] fbdev,mm: hecuba/E-Ink fbdev driver

Jaya Kumar wrote:

On 1/11/07, Andrew Morton [off-list ref] wrote:

quoted

That's all very interesting.

Please don't dump a bunch of new implementation concepts like this on us
with no description of what it does, why it does it and why it does it in
this particular manner.

Hi Andrew,

Actually, I didn't dump without description. :-) I had posted an RFC
and an explanation of the design to the lists. Here's an archive link
to that post. 
http://marc.theaimsgroup.com/?l=linux-kernel&m=116583546411423&w=2
I wasn't sure whether to include that description with the patch email
because it was long.

quoted

From that email:

---
This is there in order to hide the latency
associated with updating the display (500ms to 800ms). The method used
is to fake a framebuffer in memory. Then use pagefaults followed by delayed
unmaping and only then do the actual framebuffer update. To explain this
better, the usage scenario is like this:

- userspace app like Xfbdev mmaps framebuffer
- driver handles and sets up nopage and page_mkwrite handlers
- app tries to write to mmaped vaddress
- get pagefault and reaches driver's nopage handler
- driver's nopage handler finds and returns physical page ( no
 actual framebuffer )
- write so get page_mkwrite where we add this page to a list
- also schedules a workqueue task to be run after a delay
- app continues writing to that page with no additional cost
- the workqueue task comes in and unmaps the pages on the list, then
 completes the work associated with updating the framebuffer

Have you thought about implementing a traditional write-back cache using
the dirty bits, rather than unmapping the page?

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com