On Mon, Oct 10, 2005 at 08:58:27PM -0700, David S. Miller wrote:
> From: Al Viro <[email protected]>
> Date: Tue, 11 Oct 2005 04:41:27 +0100
>
> > On Mon, Oct 10, 2005 at 06:31:12PM -0700, Linus Torvalds wrote:
> > > Tom 'spot' Callaway:
> > > [SPARC32]: Enable generic IOMAP.
> >
> > ... breaks non-PCI builds (aka the absolute majority of sparc32 boxen).
> > On sparc32 insl() et.al. are defined only if CONFIG_PCI is set.
> >
> > Moreover, I really doubt that generic_iomap is the right thing to do
> > there - all these guys end up as memory dereferences anyway, so ioread...()
> > et.al. have no reason to care about the origin of iomem pointer they get.
>
> Also, Tom never answered my query about the driver he stated
> this was needed for (sym53c8xx) which appears on no sparc32
> PCI box in the world :-)
>
> I'll revert this for now, push that to Linus, and we can hash it out
> better in 2.6.15
For sparc32 ioread*/iowrite* are _trivial_. Look, the only defining
properties are
* if p is ioremap(whatever, len), then for any q from p to p + len - 1
we have ioread8(q) == readb(q), etc.
* if p is ioport_map(whatever, len), then for any q from p to p + len - 1
we have ioread8(q) == inb(whatever + q - p), etc.
ioread8 readb inb
iowrite8 writeb outb
ioread16 readw inw
iowrite16 writew outw
ioread32 readl inl
iowrite32 writel outl
ioread.._rep loop of raw_read... ins...
iowrite.._rep loop of raw_write... outs...
And that's it. On sparc32 we can just have ioport_map() cast to void __iomem *
and be done with that. And have io...() do corresponding memory access;
the only thing to keep in mind is that _rep variants do native-endian
access.
lib/iomap.c versions assume that PIO space needs different low-level
primitives for access and can be shifted outside of iomem space.
There we have ioport_map() add offset to port number and io{read,write}...
check the address and either do iomem access or subtract that offset and
do PIO one. Nothing of that kind makes sense on sparc32 - the only
use for similar mechanism would be to try and encode AST into pointer.
But we are mapping them all into kernel context anyway, so there's no
need to bother with that...
-
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]
