On Sun, Apr 15, 2012 at 11:26:50PM +0200, Jonas Bonn wrote:
> 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'!?!
I don't think the CI bit only affects reads, where have you got that
impression from?
Looking at the spec:
"Memory accesses to memory pages designated with CI=1 are always performed
directly into the main memory, bypassing all caches."
That sounds like read _and_ write to me.
as far as or1200 goes, it looks to me that CI bypasses the fsm
and the write goes straight out to BIU:
assign biu_write = // Bus write request when:
// 1) Have a miss and dirty or store with inhibit
((state == `OR1200_DCFSM_CLOADSTORE) &
(((hitmiss_eval & tagcomp_miss & dirty) |
(store & writethrough)) |
(store & cache_inhibit_with_eval)) & dcqmem_cycstb_i) |
// 2) In the loop and storing
((state == `OR1200_DCFSM_LOOP2) & store);
cache_inhibit_with_eval is the signal indicating CI here.
> 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?
>
I don't know if the write-back cache option is broken, but
it's usually disabled (in hardware).
Julius probably knows best about the or1200 write-back option.
Stefan
_______________________________________________
Linux mailing list
[email protected]
http://lists.openrisc.net/listinfo/linux
