Re: [RFC 2.6.19 1/1] fbdev,mm: hecuba/E-Ink fbdev driver v2

["Franck Bui-Huu" <vagabon.xyz@gmail.com>]

On 12/17/06, Jaya Kumar <jayakumar.lkml@gmail.com> wrote:
> Ok. I now see what you mean. In typical cases, only one path is used
> to write. Meaning an app will decide to use the mmap path or the slow
> write path and the kernel only ever reads from its pte entry (unless
> fbcon is used which is not suited for this type of display).

Even if the kernel does only reads, you can be in trouble. For
example, the kernel access (by reading) to a data A through the cache
line 1. The application access (by writing a new value) data A through
the cahe line 5. Now it's time to update your frame buffer, so the
kernel access to data A through the cache line 1 which still contains
the _stall_ value.

Note that flushing data  before the kernel access it does not solve
any problems. If the kernel is allowed to write into the frame buffer,
the kernel don't know which line stores the up to date data...

> But you
> are right that it is possible for a situation to arise where one app
> does mmap and another is doing write.

I would say that should be a safe case. Nornally the kernel takes care
to flush caches between context switches (depending on your cache
architecture). But it's only a guess, I haven't checked the code...

> My hope is that something takes
> care of flushing the data cache for me in this case. Do you recommend
> I add something to force that?

Well I'm not the right person to answer this question. I haven't
looked at how Linux handles cache consistency yet. Knowing that I can
give you only 2 recommandations:

   - disable the cache when accessing your frame buffer (kernel and
applications).

   - when mmaping your frame buffer , be sure that the virtual
address returned by
     mmap() to the application shares the same cache lines than the
ones the kernel
     is using.

Hoping it helps,
--
              Franck
-
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/