On Mon, 22 Feb 2010 17:15:24 -0700
Bjorn Helgaas <bjorn.helgaas@hp.com> 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@hp.com> 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
|