Hi,

I thought I'd just bring this comment from a patch to the OpenRISC Linux
list to the attention of the openrisc list:

On Sun, 2012-04-15 at 22:06 +0200, Jonas Bonn wrote:
> + *
> + * There are additional flags WEAK_ORDERING and WRITE_COMBINE to take
> + * into consideration here, too.  All current known implementations of
> + * the OR1K support only strongly ordered memory accesses, so that flag
> + * is being ignored for now; uncached but write-combined memory is a
> + * missing feature of the OR1K.
>   */

Could somebody comment on:

i) weakly ordered memory accesses: is there any implementation of this?
is it doable?  does the WOM bit on the page do anything in any of the
implementations today?

ii)  uncached memory with write-combining:  reading through the spec is
just confusing here:

a)  CI bit affects memory reads only(?).  Multiple accesses may be
combined into a single access:  what defines "multiple accesses"?  If
these accesses are sufficiently spread out temporally, that starts to
sound like 'cached memory'!?!
b)  For memory writes, there's no way to get uncached memory:
write-through pages get written to cache and memory, write-back pages
only to cache.  So for uncached memory I need CI + write-through cache.
c)  It seems there's no way to know if write-combining is in use or not;
and there's no way to turn it off.

d)  The CC bit (cache coherency) has this: "To improve performance of
uniprocessor systems, memory pages should not be designated as CC=1"
What's the cost on a uniprocessor system of setting this bit?

The Linux implementation currently maps device registers to virtual
pages with the CI bit set but as write-back cache.  This probably only
works today because the write-back cache option is broken on the OR1200
and all caches are actually write-through.  Correct?

Thanks,
Jonas


Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Linux mailing list
[email protected]
http://lists.openrisc.net/listinfo/linux

Reply via email to