On Thu, Jan 19, 2012 at 10:59:01AM -0800, Matt Thomas wrote:
For prefetchable regions (like framebuffers) mapped by bus_space_map,
there is a need to able force the contents out of the cache back into
memory (especially when the cache is a writeback cache).
Don't some ethernet drivers
On Jan 21, 2012, at 3:06 AM, David Laight wrote:
On Thu, Jan 19, 2012 at 10:59:01AM -0800, Matt Thomas wrote:
For prefetchable regions (like framebuffers) mapped by bus_space_map,
there is a need to able force the contents out of the cache back into
memory (especially when the cache is a
On Fri, Jan 20, 2012 at 05:19:01PM -0500, Michael wrote:
As Matt said, completely different problem. One is about enforcing
order, the other is about writing stuff out NOW ( which in a way
also enforces order but with a lot more baggage ).
and I'll stick my oar in to note that (IMO anyway)
On Thu, Jan 19, 2012 at 08:45:41PM +0100, Martin Husemann wrote:
Even if originally intended for something else, like Matt says, wouldn't it
Why do you think BUS_SPACE_BARRIER_SYNC was intended for something else ?
I can't see how a write barrier that doesn't ensure the write has
reached the
On Thu, Jan 19, 2012 at 11:57:05AM -0800, Matt Thomas wrote:
On Jan 19, 2012, at 11:45 AM, Martin Husemann wrote:
Even if originally intended for something else, like Matt says, wouldn't it
be easier to just define two new flags for it like
BUS_SPACE_BARRIER_WB
On Thu 19 Jan 2012 at 11:16:01 -0800, Matt Thomas wrote:
No. Since framebuffers can be considered memory, there is a definite
advantage to mapping them cached.
Given some gfx cards' gargantuan frame buffers, far bigger than needed
for the actual screen contents, isn't there some driver to
On Thu, 19 Jan 2012, Matt Thomas wrote:
For prefetchable regions (like framebuffers) mapped by bus_space_map, there
is a need to able force the contents out of the cache back into memory
(especially when the cache is a writeback cache).
There is no MI way to do this with the bus_space
On Fri, Jan 20, 2012 at 11:18:38AM +0100, Manuel Bouyer wrote:
On Thu, Jan 19, 2012 at 08:45:41PM +0100, Martin Husemann wrote:
Even if originally intended for something else, like Matt says, wouldn't it
Why do you think BUS_SPACE_BARRIER_SYNC was intended for something else ?
I can't see
Even if originally intended for something else, [...]
Why do you think BUS_SPACE_BARRIER_SYNC was intended for something
else ? I can't see how a write barrier that doesn't ensure the write
has reached the target (main or device memory) can be usefull.
I can't comment on why someone else
On Fri, 20 Jan 2012, Mouse wrote:
Even if originally intended for something else, [...]
Why do you think BUS_SPACE_BARRIER_SYNC was intended for something
else ? I can't see how a write barrier that doesn't ensure the write
has reached the target (main or device memory) can be usefull.
On Fri, Jan 20, 2012 at 06:57:59PM +, Eduardo Horvath wrote:
The semantics seem pretty clear to me. Now we may have a bunch of buggy
implementations, but the man page seems pretty clear to me.
Eduardo,
Oh, good grief.
I realize that is what it SAYS, what I am saying is that perhaps that
I can't see how a write barrier that doesn't ensure the write has
reached the target (main or device memory) can be usefull.
[...]. But barriers that have nothing to do with write completion
to the target can still be useful. [...]
That's not what the manpage documenting
Hello,
On Fri, 20 Jan 2012 13:53:23 -0500 (EST)
Mouse mo...@rodents-montreal.org wrote:
Even if originally intended for something else, [...]
Why do you think BUS_SPACE_BARRIER_SYNC was intended for something
else ? I can't see how a write barrier that doesn't ensure the write
has
For prefetchable regions (like framebuffers) mapped by bus_space_map, there is
a need to able force the contents out of the cache back into memory (especially
when the cache is a writeback cache).
There is no MI way to do this with the bus_space framework so I'm proposing we
add a:
Matt,
Aren't frame buffers generally mapped using bus_space_map() with cache
disabled?
On Jan 19, 2012, at 12:59 PM, Matt Thomas wrote:
For prefetchable regions (like framebuffers) mapped by bus_space_map, there
is a need to able force the contents out of the cache back into memory
On Thu, Jan 19, 2012 at 10:59:01AM -0800, Matt Thomas wrote:
For prefetchable regions (like framebuffers) mapped by bus_space_map, there
is a need to able force the contents out of the cache back into memory
(especially when the cache is a writeback cache).
There is no MI way to do this
On Thu, Jan 19, 2012 at 11:32:46AM -0800, Matt Thomas wrote:
On Jan 19, 2012, at 11:28 AM, Manuel Bouyer wrote:
On Thu, Jan 19, 2012 at 10:59:01AM -0800, Matt Thomas wrote:
For prefetchable regions (like framebuffers) mapped by bus_space_map,
there is a need to able force the
Even if originally intended for something else, like Matt says, wouldn't it
be easier to just define two new flags for it like
BUS_SPACE_BARRIER_WB
BUS_SPACE_BARRIER_WBINV
and leave the rest of the API untouched?
Martin
On Jan 19, 2012, at 11:45 AM, Martin Husemann wrote:
Even if originally intended for something else, like Matt says, wouldn't it
be easier to just define two new flags for it like
BUS_SPACE_BARRIER_WB
BUS_SPACE_BARRIER_WBINV
and leave the rest of the API untouched?
I thought about
On Jan 19, 2012, at 11:28 AM, Manuel Bouyer wrote:
On Thu, Jan 19, 2012 at 10:59:01AM -0800, Matt Thomas wrote:
For prefetchable regions (like framebuffers) mapped by bus_space_map, there
is a need to able force the contents out of the cache back into memory
(especially when the cache is
On Jan 19, 2012, at 11:09 AM, Frank Zerangue wrote:
Matt,
Aren't frame buffers generally mapped using bus_space_map() with cache
disabled?
No. Since framebuffers can be considered memory, there is a definite advantage
to mapping them cached.
21 matches
Mail list logo
