Re: [PATCH resend 5/9] MIPS: sync after cacheflush

From: Maciej W. Rozycki
Date: Tue Oct 19 2010 - 16:11:59 EST


On Tue, 19 Oct 2010, Ralf Baechle wrote:

> See R4000 User's Manual Version 2, page 326, "Uncached Loads and Stores".
> Of course this can only happen on cache coherent or multiprocessor systems.
> I guess none of the supported DEC MIPS systems is affected.

Since none of the R4k DECstations is coherent or MP, I have not
considered these implications. The only MP DECsystem (there was no
workstation variation), that is the 5800, was built with R3k chips in the
first place and the chance we ever come across one, let alone support it,
is epsilon.

That said, R4k DECstations seem to perform aggressive write buffering in
the chipset and to make sure a write has propagated to an MMIO register a
SYNC and an uncached read operation are necessary. The read may be from
elsewhere apparently -- RAM at 0 seems just fine -- so the chipset seems
to obey the SYNC semantics.

I haven't investigated DMA dependencies and I think we currently only
have one TURBOchannel device/driver only (that is the DEFTA/defxx FDDI
thingy) making use of the generic DMA API on DECstations. It seemed to
work correctly the last time I tried; presumably either because the API
Does The Right Thing, or by pure luck and right timings. Note that the
DEC/Motorola CAMEL FDDI chipset was quite an aggressive DMA agent for its
time, certainly capable of saturating some lower-clocked implementations
of the I/O bus.

Then I think the onboard devices that do third-party DMA via the IOASIC
such as the LANCE Ethernet are too obscure/arcane to consider them here
and get any useful results -- any inconsistencies may well be masked by
the odd sequences used to access the respective chips. There were some
hardly documented chipset errata too, making the whole thing yet more
complicated and causing some "impossible" error scenarios.

Maciej
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/