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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/17/06, Jaya Kumar <[email protected]> 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 [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]
  Powered by Linux