linux-mips
[Top] [All Lists]

Re: [PATCH] enable PCI bridges in MIPS ip32

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH] enable PCI bridges in MIPS ip32
From: Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org>
Date: Fri, 5 Oct 2007 07:33:49 +0200
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>, linux-mips@linux-mips.org
In-reply-to: <20071004153217.GF6897@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <E1IdO0a-0000n7-Cg@eppesuigoccas.homedns.org> <Pine.LNX.4.64N.0710041316000.10573@blysk.ds.pg.gda.pl> <20071004130318.GC28928@linux-mips.org> <1191508413.10050.26.camel@scarafaggio> <20071004151951.GD6897@linux-mips.org> <Pine.LNX.4.64N.0710041624450.10573@blysk.ds.pg.gda.pl> <20071004153217.GF6897@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
On Thu, 4 Oct 2007 16:32:17 +0100 Ralf Baechle <ralf@linux-mips.org> wrote:
> On Thu, Oct 04, 2007 at 04:27:57PM +0100, Maciej W. Rozycki wrote:
> > On Thu, 4 Oct 2007, Ralf Baechle wrote:
> > > The entire testing done by chkslot() is probably not needed, so I suggest
> > > you try to simply dump the thing entirely and test.
> > 
> >  Exactly what I wrote too. :-)  Though I would imagine it was introduced 
> > for a reason, like a bug in the host bridge or something, as already 
> > suggested.  Otherwise what would the point have been?
> 
> I suspect cut-and-paste-o-mania, probably originally started by the
> necessity of doing so for the Galileo chips.

After removing the chkslot() call, I get these errors when booting:
[...]
SCSI subsystem initialized
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00008000 (C)
MACEPCI: Master abort at 0x00010000 (C)
MACEPCI: Master abort at 0x00020000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
MACEPCI: Master abort at 0x00000000 (C)
PCI: Bridge: 0000:00:03.0
  IO window: 1000-1fff
  MEM window: 80000000-800fffff
  PREFETCH window: 80100000-801fffff
PCI: Enabling device 0000:00:03.0 (0000 -> 0003)
[...]

It seems all probes to devfn=0 fails. There is even a call on bus=2, that I 
really don't understand. the current lspci output is:

00:01.0 SCSI storage controller: Adaptec AIC-7880U
00:02.0 SCSI storage controller: Adaptec AIC-7880U
00:03.0 PCI bridge: NetMos Technology Unknown device 9250 (rev 01)
01:08.0 USB Controller: NEC Corporation USB (rev 43)
01:08.1 USB Controller: NEC Corporation USB (rev 43)
01:08.2 USB Controller: NEC Corporation USB 2.0 (rev 04)
01:09.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 61)
01:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit 
Ethernet (rev 10)

So probably, the test was correct.  Should I restore the same check or only 
check for devfn==0?

Bye,
Giueppe

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