On Sun, 5 Nov 2006, Benjamin Herrenschmidt wrote:
>
> The -only- problem I'm talking about is that in order to implement the
> above, this IOCOND does something around the line of:
>
> if (pio)
> use_pio_accessor()
> else
> use_mmio_accessor()
>
> It does that, by using the existing, arch provided, accessors for PIO
> and MMIO (inX, outX, readX, writeX), which are doing the right thing vs.
> barriers etc, so again, all is good and well.... until you hit cases
> where such accessors don't exist !
Right. Your first email seemed to make sense. However, you then said (in
the second email, the one I responded to), and THAT didn't make any sense
at all:
Versions that would transparently use MMIO or PIO would make sense. A
pure MMIO implementation doesn't, that has to be arch specific. It makes
the generic iomap suddently non-portable in some ways.
This is the part I claim says that you don't seem to make any sense. You
seemed to be missing the point about the whole "repeat" instructions,
since the WHOLE POINT there was that it would _not_ transparently use MMIO
or PIO, it would very much _nontransparently_ use one or the other,
exactly because the choice has already very much been made.
> - "be" versions of MMIO accesses. Example:
Now, this one we should probably just drop, because nobody uses it.
Big-endian IO devices basically don't exist any more, and if they do, they
wouldn't use any generic structures.
> - repeat versions of MMIO accessors. Example:
So this one is the only one that makes sense. But it DOES NOT MAKE SENSE
in light of your second email that talked about "transparently use MMIO or
PIO". That's what made me think that you were just blathering.
But I also don't want to add _yet_another_ bogus IO accessor function to
all architectures that nobody actually uses except for this one little
thing. Quite frankly, I'd rather just add something like
#ifndef iobarrier_w
# define iobarrier_w() do { } while (0)
#endif
and then use iobarrier_w()" in the "mmio" version of the __raw_writel loop
(and same for iobarrier_r() for the __raw_readl).
Linus
-
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]
