On 9/12/06, Benjamin Herrenschmidt <[email protected]> wrote:
> Oops, I forgot about store-store ordering being automatic.
> Pretend I had some loads in my example.
Well, in 99% of the cases, you want MMIO loads to be orderd vs. MMIO
stores and thus you can use __writel and __readl (which will only do an
eieio in __readl). If you are really that picky, then, of course you can
go use the __raw_* versions.
If I could get the __raw_* versions for every arch, and there
wouldn't be any endianness troubles, it'd do.
I think a single or double "_" is enough warning to enable
full foot-shooting ability though.
> A proper interface would be more explicit about what the
> fence does, so that driver authors shouldn't need to know
> this detail.
What detail ? Isn't my document explicit enough ? If not, please let me
know what is not clear in the definition of the 4 ordering rules and the
matching fences.
The driver code is not very self-documenting this way.
If I see an io_to_io_barrier(), how am I to tell if it is
read to read, write to write, read to write, write to read,
read/write to read, read/write to write, read to read/write,
write to read/write, or read/write to read/write?
Considering just reads and writes to MMIO, there are
9 possible types of fence. SPARC seems to cover a
decent number of these distinctly; the instruction takes
an immediate value as flags.
> So you say: never mix strict mappings with loose operations,
> and never mix loose mappings with strict operations.
I don't want the concept of "lose mappings" in the generic driver
interface for now anyway :)
It's too implementation specific and I want to know that a given access
is strictly ordered or relaxed just by looking at the accessor used, not
having to go look for where the driver did the ioremap. We can still
provide arch specific things where we feel it's useful but let's move
one step at a time with the generic accessors.
I suppose the "sparse" tool could match up mapping type
with accessor type. That'd let you rely on the accessor to
be doing what you expect when you read the code.
Loose mappings are only arch-specific in implementation.
Generic non-arch driver code ought to be able to take
advantage of the performance benefits of loose mappings.
(that is: full any-any reordering)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
