On Mon, 22 Feb 2010 17:15:24 -0700 Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote: > On Monday 22 February 2010 04:51:43 pm Yoichi Yuasa wrote: > > Hi Bjorn, > > > > On Mon, 22 Feb 2010 13:55:28 -0700 > > Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote: > > > > > On Sunday 21 February 2010 12:45:31 am Yoichi Yuasa wrote: > > > > > I'd like to understand the PCI architecture of Cobalt better. Would you > > > > > mind turning on CONFIG_PCI_DEBUG and posting the dmesg log? > > > > > > > > If you want to know what happen, you can see my old e-mail. > > > > > > > > http://marc.info/?l=linux-kernel&m=118792430424186&w=2 > > > > > > There's not much detail there. It would save me a lot of time if > > > you could collect the complete dmesg log, /proc/iomem, and /proc/ioports. > > > > It cannot boot without old hack. > > I know; I meant that the information from a kernel with the old > hack would be useful. But I think I'm starting to understand anyway. > > The Linux I/O port number space is defined here: > > static struct resource cobalt_io_resource = { > .start = 0x1000, > .end = GT_DEF_PCI0_IO_SIZE - 1, /* 0x1ffffff */ > > [As an aside, I'm not sure 0x1000 is the correct start -- for example, > I think Linux I/O port 0x1f0 is forwarded by the host bridge.] This is the space(0x0-0xfff) for the fixed address devices(PIC, RTC, DMA(just reserved)...). $ cat /proc/ioports 00000000-0000001f : reserved 00000020-00000021 : pic1 00000060-0000006f : reserved 00000070-00000077 : rtc_cmos 00000070-00000077 : rtc0 00000080-0000008f : reserved 000000a0-000000a1 : pic2 000000c0-000000df : reserved 00000170-00000177 : pata_via 000001f0-000001f7 : pata_via 00000376-00000376 : pata_via 000003f6-000003f6 : pata_via 00001000-01ffffff : PCI I/O 00001000-0000107f : 0000:00:07.0 00001000-0000107f : tulip 00001080-000010ff : 0000:00:0c.0 00001080-000010ff : tulip 00001400-0000141f : 0000:00:09.2 00001420-0000142f : 0000:00:09.1 00001420-0000142f : pata_via > The corresponding PCI I/O port numbers are determined by the PCI > I/O decoder address, so I agree that we need the io_offset to convert > between the Linux port numbers and ports that appear on the PCI bus. > > I think the IDE device is a problem because pci_setup_device() fills > in legacy resources with ports 0x1f0-0x1f7, etc. We expect those > resources to contain PCI bus addresses at this point, but we could > never see those addresses on the Cobalt PCI bus (we would only see > things in the range 0x10000000-0x11ffffff). > > When we convert 0x1f0 with pcibios_bus_to_resource() (or with > pcibios_fixup_device_resources() without the IORESOURCE_PCI_FIXED > hack), we get 0x1f0 + 0xf0000000 == 0xf00001f0, when we want 0x1f0 > instead. > > > pata_via 0000:00:09.1: BAR 0: can't reserve [io 0xf00001f0-0xf00001f7] > > I still don't know the best way to fix this, but does this make sense > so far? That makes sense. Yoichi
