[PATCH 0/3] [ARM] tegra: PCI Express support

Arnd Bergmann arnd at arndb.de
Sun Sep 19 10:39:44 EDT 2010


On Sunday 19 September 2010 16:07:02 Mike Rapoport wrote:
> > diff --git a/arch/arm/mach-tegra/include/mach/io.h b/arch/arm/mach-tegra/include/mach/io.h
> > index 35edfc3..d54e384 100644
> > --- a/arch/arm/mach-tegra/include/mach/io.h
> > +++ b/arch/arm/mach-tegra/include/mach/io.h
> > @@ -21,7 +21,8 @@
> >  #ifndef __MACH_TEGRA_IO_H
> >  #define __MACH_TEGRA_IO_H
> >  
> > -#define IO_SPACE_LIMIT 0xffffffff
> > +/* Two 1MB windows */
> > +#define IO_SPACE_LIMIT (SZ_1M + SZ_1M - 1)
> 
> This would limit ioport_resource to 2M, and request_resource(&ioport_resource, 
> &res) will fail because ioport_resource does not take into account that IO can 
> start somewhere else than at 0.

Normally, the ioport_resource is limited to 65536 bytes in practice,
because that's the most that many PCI cards decode.

The only reason to let the I/O window start at something other than 0 is
to leave space for legacy ISA devices, so typically the available range
is between 0x1000 and 0xffff.

I don't see that as a limitation here.

> >  /* On TEGRA, many peripherals are very closely packed in
> >   * two 256MB io windows (that actually only use about 64KB
> > @@ -69,7 +70,7 @@ void tegra_iounmap(volatile void __iomem *addr);
> >  
> >  static inline void __iomem *__io(unsigned long addr)
> >  {
> > -     return (void __iomem *)addr;
> > +     return addr + tegra_pcie.regs + SZ_4M;
> 
> I wish things were that simple :)
> As far as I understand, the IO space should be mapped prior to use and __io 
> should return the virtual address.

That's right. You already map all the PCI registers including the I/O port
mapping at initialization time, but you must not attempt to access these
during boot before that time.

You should probably mask the size as above, which I forgot:

static inline void __iomem *__io(unsigned long addr)
{
     return (addr & IO_SPACE_LIMIT) + (tegra_pcie.regs + SZ_4M);
}

Hopefully it's clearer that way, and certainly safer in case someone
passes the physical address of the I/O window into __io rather than
the offset.

	Arnd



More information about the linux-arm-kernel mailing list