Re: [RFC] MMIO accessors & barriers documentation

Ar Llu, 2006-09-11 am 19:17 +1000, ysgrifennodd Benjamin Herrenschmidt:
3- memcpy_to_io, memcpy_from_io: #1 semantics apply (all MMIO loads or
stores are performed in order to each other). #2+#4 (stores) or #3

What is "in order" here. "In ascending order of address" would be
tighter.

In program order. Every time I say "in order", I mean "in program
order". I agree that this is not enough precision as it's not obvious
that memcpy will copy in ascending order of addresses (it doesn't have
to), I'll add that precision... or not. THat could be another question.
What do we want here ? I would rather have those strongly ordered for
Class 1.

I'd rather memcpy_to/from_io only made guarantees about the start/end of
the transfer and not order of read/writes or size of read/writes. The
reason being that a more restrictive sequence can be efficiently
expressed using read/writefoo but the reverse is not true.

"Except where the underlying device is marked as cachable or
prefetchable"

You aren't supposed to use MMIO accessors on cacheable memory, are you ?

Why not. Providing it is in MMIO space, consider ROMs for example or
write path consider frame buffers.

with cacheable mappings of anything behind HT... I'd keep use of
cacheable mapping as an arch specific special case for now, and that
definitely doesn't allow for MMIO accessors ...

I'm describing existing semantics 8)


-
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/