Re: No PCI_AUTO in 2.6...

[Ralf Baechle <ralf@linux-mips.org>]

On Wed, Dec 15, 2004 at 03:25:13PM +0000, Maciej W. Rozycki 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.

In the above case, the I/O port resource is starting at 0x1000 because
the range of 0x0 - 0xfff contains a few legacy devices.  The way the SNI
code is initializing sni_io_resource ensures all the legacy devices
are properly listed in the iomem_resource and /proc/ioports and the kernel
will never place any I/O resource for a PCI card in the legacy port range.
As the result we'll get:

[root@tbird root]# cat /proc/ioports
00000000-0000001f : dma1
00000020-0000003f : pic1
00000040-0000005f : timer
00000060-0000006f : keyboard
00000070-00000077 : rtc
00000080-0000008f : dma page reg
000000a0-000000bf : pic2
000000c0-000000df : dma2
000002f8-000002ff : serial
000003c0-000003df : vga+
000003f8-000003ff : serial
00000cfc-00000cff : PCI config data
00001000-03bfffff : PCIMT IO MEM
  00001000-000010ff : 0000:00:01.0
    00001000-000010ff : sym53c8xx
  00001400-0000141f : 0000:00:02.0
    00001400-0000141f : pcnet32_probe_pci
[root@tbird root]#

This makes it look like the legacy ports are not behind the PCI bus
which actually they are but that's a minor nit, it gets the address
space allocation to work right.

> > 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...

True, but that's dealt with elsewhere.  And I never claimed the mess that
PCI used to be in 2.4 has yet been fully cleaned up yet, more work to do.

  Ralf