[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.025 / U:69.336 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site