[Top] [All Lists]

Re: No PCI_AUTO in 2.6...

To: Ralf Baechle <>
Subject: Re: No PCI_AUTO in 2.6...
From: "Maciej W. Rozycki" <>
Date: Wed, 15 Dec 2004 15:25:13 +0000 (GMT)
Cc: wlacey <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <>
On Wed, 15 Dec 2004, Ralf Baechle wrote:

> Here's a simplified example from arch/mips/sni/setup.c:
> static struct resource sni_io_resource = {
>         "PCIMT IO MEM", 0x00001000UL, 0x03bfffffUL, IORESOURCE_IO,
> };
> static struct resource sni_mem_resource = {
>         "PCIMT PCI MEM", 0x10000000UL, 0xffffffffUL, IORESOURCE_MEM
> };

 I think it's more descriptive to call them "<foo> PCI I/O" and "<foo> PCI
MEM", respectively, to make it clearer the former expresses I/O port
addresses (not the associated memory address range for accesses to be
forwarded as PCI I/O cycles) and that both are PCI bus spaces.

 Also for most PCI systems I/O port space should really start at 0 (for
"legacy" devices being decoded by the PCI-ISA bridge if there's one in the
system), but generic code braindamage prevents it currently.  I think
there was only about a single PCI chipset that had a "reversed"
architecture and sort-of bridged PCI over ISA -- the Intel i82420EX for
the i486 processor.  It would need a separate ISA I/O resource for a
correct view of the system.

> That is PCI memory is in the address range of 0x10000000UL - 0xffffffffUL
> and I/O ports in the range 0x00001000UL - 0x03bfffffUL.  The io_offset
> rsp. mem_offset values say how much needs to be added rsp. subtracted
> when converting a PCI bus address into a physical address.  Often these
> values are either the same a the resource's start address or zero.

 Things start being tricky once you have to use such an offset for DMA
transfers as well...


<Prev in Thread] Current Thread [Next in Thread>