lkml.org 
[lkml]   [1997]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: pre2.0.31-2
Date
> > > 1)	The memory mapped by 'vremap' is marked cacheable. This
> > > is (almost certainly) incorrect as it is memory that is
> > > actually device memory. Note that the mmap call used by
> > > X servers marks the memory as uncached.
> >
> > The PC architecture is supposed to handle this for you. It could well
> > be an issue on MIPS and friends. The X one is hack and shouldnt be needed

The problem of handling caches for I/O also hit Sparc and 68k. Since they
however don´t share drivers with the mainstream hardware this has so far
not been solved.

> what shouldn't be needed? turning off caching for a mapped frame buffer ?
> or did I miss your point ?

Check the code that disables caching. It´s a real #ifdef hack for certain
chipsets. The other

> how would you guarantee data/display integrity (esp. for WB cache) if you're
> changing the frame buffer sometimes by direct access to the frame buffer by the CPU
> and sometimes by using the graphics engine ? otherwise you'd have to flush the cache
> for very cpu <-> graphics engine tansition

You have two options:

Writeback the caches whenever you want to synchronize the device memory
and the caches. This is preferable because it´s fastest.
Or disable caching by hardware or pagetables. This may be slow because
you loose the cache advantage of write combining.

Actually the right thing to do is configuration dependand but almost
always #1 is the right thing to do.

What we need is some kind of extension to the Linux device driver interface
for handling the caches correctly. I´ll try to present something
as soon as I find the time ...

Ralf

\
 
 \ /
  Last update: 2005-03-22 13:39    [W:1.044 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site