linux-mips
[Top] [All Lists]

Re: Reverting old hack

To: Yoichi Yuasa <yuasa@linux-mips.org>
Subject: Re: Reverting old hack
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
Date: Mon, 22 Feb 2010 17:15:24 -0700
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
In-reply-to: <20100223085143.aeb1fa53.yuasa@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20100220113134.GA27194@linux-mips.org> <201002221355.28939.bjorn.helgaas@hp.com> <20100223085143.aeb1fa53.yuasa@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: KMail/1.9.10
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.]

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?

Bjorn

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