ebus & ioremap?

ebus & ioremap?

[Meelis Roos]

While trying to see if I can cleanly fix the iomem warnings for sparc 
floppy, I came to stop ath this code at asm/floppy.5:653

                 /* XXX ioremap */
                 sun_pci_fd_ebus_dma.regs = edev->resource[1].start;

I can understand why someone did put a XXX there but why does it work 
this way?

-- 
Meelis Roos (mroos@linux.ee)

Re: ebus & ioremap?

[David S. Miller]

On Thu, 10 Mar 2005 14:42:56 +0200 (EET)
Meelis Roos <mroos@linux.ee> wrote:

> While trying to see if I can cleanly fix the iomem warnings for sparc 
> floppy, I came to stop ath this code at asm/floppy.5:653
> 
>                  /* XXX ioremap */
>                  sun_pci_fd_ebus_dma.regs = edev->resource[1].start;
> 
> I can understand why someone did put a XXX there but why does it work 
> this way?

On sparc64, we store the physical I/O address in the resources,
and that is what the I/O accessor routines take as well.

Therefore ioremap() just pass the address through unchanged, they
are just a NOP.

Re: ebus & ioremap?

[Eric Brower]

From asm/io.h:

/* On sparc64 we have the whole physical IO address space accessible
 * using physically addressed loads and stores, so this does nothing.
 */
static inline void __iomem *ioremap(unsigned long offset, unsigned long size)
{
    return (void __iomem *)offset;
}

It is nice to use ioremap to remain idiomatic with other
architectures, though, esp. in drivers and the like.

E



On Thu, 10 Mar 2005 14:42:56 +0200 (EET), Meelis Roos <mroos@linux.ee> wrote:
> While trying to see if I can cleanly fix the iomem warnings for sparc
> floppy, I came to stop ath this code at asm/floppy.5:653
> 
>                  /* XXX ioremap */
>                  sun_pci_fd_ebus_dma.regs = edev->resource[1].start;
> 
> I can understand why someone did put a XXX there but why does it work
> this way?
> 
> --
> Meelis Roos (mroos@linux.ee)
> -
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
E