mach/io.h cleanup and removal question
andrew at lunn.ch
Mon Jun 18 03:59:45 EDT 2012
On Fri, Jun 08, 2012 at 09:10:17AM -0500, Rob Herring wrote:
> On 06/08/2012 06:43 AM, Russell King - ARM Linux wrote:
> > On Fri, Jun 08, 2012 at 12:20:40PM +0200, Andrew Lunn wrote:
> >> Your patchset for mach/io.h cleanup and remove, causes problems on
> >> Orion5x.
> >> mach/io.h for orion5x had a:
> >> #define IO_SPACE_LIMIT 0xffffffff
> >> which got removed. This results in a panic at boot:
> >> /*
> >> * IORESOURCE_IO
> >> */
> >> sys->io_offset = 0;
> >> res.name = "PCIe I/O Space";
> >> res.flags = IORESOURCE_IO;
> >> res.start = ORION5X_PCIE_IO_BUS_BASE;
> >> res.end = res.start + ORION5X_PCIE_IO_SIZE - 1;
> >> if (request_resource(&ioport_resource, &res))
> >> panic("Request PCIe IO resource failed\n");
> >> ORION5X_PCIE_IO_SIZE is 1MB, so the allocation fails because of the
> >> 64K default.
> >> arch/arm/include/asm/io.h has the comment:
> >> /*
> >> * This is the limit of PC card/PCI/ISA IO space, which is by default
> >> * 64K if we have PC card, PCI or ISA support. Otherwise, default to
> >> * zero to prevent ISA/PCI drivers claiming IO space (and potentially
> >> * oopsing.)
> >> *
> >> * Only set this larger if you really need inb() et.al. to operate over
> >> * a larger address space. Note that SOC_COMMON ioremaps each sockets
> >> * IO space area, and so inb() et.al. must be defined to operate as per
> >> * readb() et.al. on such platforms.
> >> */
> >> Now, i know nothing about how PCI works... So i have a question:
> >> Which is better, put back parts of io.h so allowing the 1MB
> >> request_resource, or reduce ORION5X_PCIE_IO_SIZE to 64KB, since from
> >> the comment it is unlikely an PCI card needs more than 64KB?
> > Well, the comment about SOC_COMMON doesn't apply as you're not using that.
> > Probably shrinking ORION5X_PCIE_IO_SIZE to 64K, unless we really have a
> > requirement to support a larger IO space.
> Agreed. The next step is moving all i/o space to a fixed virtual address
> and for this we want to make i/o windows 64K.
Reducing the window size to 64K stops the panic at boot, as expected.
> However, I think you may also have a problem with
> ORION5X_PCIE_IO_BUS_BASE and the resource start. The i/o resource start
> should really be 0 and then the __io() macro should add the virtual i/o
> base address. However, Russell has mentioned previously that some chips
> may not work correctly with i/o space at 0 (PCI bus addresses, not host).
> Do you have cards with i/o that you can test or know what devices are
> used with this platform?
I don't have any cards. I've also no idea what cards are used with
these devices. I guess they are mostly WiFi cards, since Orion5x is
normally used in NAS boxes, and there is one box supported which is an
Since the panic kills all orion5x systems, i want to at least fix
that. So i will post the patch to reduce the window size to 64K. I
guess for the moment we have to leave PCI potentially broken, and see
if anybody complains.
Is this O.K?
More information about the linux-arm-kernel