Re: [PATCH 2.6.19-rc1 full] drivers: add LCD support

[Paulo Marques <pmarques@grupopie.com>]

Miguel Ojeda wrote:
>[...]
>> In this case, if nothing was ever written to the display, the CPU usage
>> would be _zero_ (as it should), and it would work nicely with dynticks
>> and such.
> 
> Hum, interesting. But what happens if...
> 
> 1. For example, the userspace app maps the fb (nopage is called, dirty
> flag set, timer created), and then the app doesn't use the fb. The
> timer will refresh the LCD, without anything new to refresh, so we are
> wasting CPU time. After refreshing, the driver clears the dirty flag
> and unmap the buffer.
> 
> 2. After some seconds, the userspace app decides to write the buffer.
> As it is not mmaped anymore, it will simply get a segmentation fault,
> right? AFAIK nopage() is not called again because we have destroyed
> the mmapping information, and Linux can't know what are the nopage()
> ops to call to.

No, this is not the sequence I thought of at all. I don't remember the 
exact API functions you need to call (I have to read LDD3 again ;), but 
if the hardware supports it, there must be a way. The plan is something 
like:

  - at mmap time you return a pointer to something that is not actually 
mapped, and do nothing else

  - when userspace actually writes to that area, you get a page fault, 
and nopage is called. At this point you map the page, and set the dirty 
state. All other writes from userspace until the timer completes are 
done without faulting.

  - when the timer completes, you unmap the page so that the next access 
will generate a fault again

As I said, I don't remember the exact details, but this should be doable.

-- 
Paulo Marques - www.grupopie.com

"The face of a child can say it all, especially the
mouth part of the face."