[lkml]   [1999]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: readX/writeX semantic and ordering

On Mon, 20 Dec 1999, Gerard Roudier wrote:

> > All PPC snoop (the data and L2 cache) provided the host bridge flags the
> > accesses it performs on behalf of PCI devices as global (with the GBL bus
> > signal). Setting or not this signal is an option on some bridges but you
> > can safely assume that it will be set since it makes things much simpler
> > (otherwise you'd have to explicitly flush the caches).
> Could I suggest the kernel to be made careful about that, if detection is
> possible, and warn about misconfiguration.
> I have been reported some problem on the G3 that seems to disappear when
> the cache is set write-through. Could a bridge misconfiguration explain
> that ?

It could, but changing the cache to write through has other side effects
and potential slowdowns so I would never swear that this is the actual
cause. Note that the only bridges which I know to have programmable
processor cache snoop are the Raven and Hawk from Motorola which are only
used in boards from Motorola computer group (MVME, MTX...).

> The current readX/writeX implementation does eieio (that's full chinese to
> me, especially when I try to pronounce it;-)) after MMIOing. The
> sym53c8xx driver knows about (since I teached it about :)) and performs
> mb() = "sync" for PPC in places when ordering between MMIO and memory
> accesses has to be guaranteed. This works on paper but has been reported
> not to be enough with some G3 (cache snooping against DMA is assumed).

Try to pronounce eieio in English and not in French (being french myself,
I can appreciate how horrible it sounds) it becomes much funnier,
epscially when accompanied with the right tune ;-)

Do you have any pattern about which type of G3 (uP revision, size of
backside L2 cache, output of lspci, especially host bridge) ?

> A single micro-second (hundreds of cycles) per IO does not make difference
> with SCSI when mastering and a single interrupt per IO is possible. I (and
> user) can invest this micro-second per IO for the system to work reliably.
> I may end-up differentiating arch at driver level if needed, but this
> requires me to learn about all of them. If I add everything needed for
> PCI, SCSI and freinds, may-be I should overclock my brain in order to deal
> properly with all of that. :-)

I agree for an SCSI driver, my case was obviously completely different,
where saving a few hundred nanoseconds from a total of 3 microseconds was

> > Ok, I've put them on since it's too big
> > for email (even private, I never considered posting it to the list).
> Thanks very much. I have downloaded them, but haven't had time for now to
> look into them.

BTW: I also found yesterday a programming environment manual on but I did not have time to download to see if it is more
recent or not (I'm in a hurry leaving for Christmas holiday, a whole week
without any net connection).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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