All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@parisc-linux.org>
To: linux-parisc@vger.kernel.org
Cc: Helge Deller <deller@gmx.de>
Subject: Re: pci 0000:01:04.0: BAR 0: no parent found for of device
Date: Fri, 6 Nov 2009 16:55:25 -0700	[thread overview]
Message-ID: <20091106235525.GD5262@lackof.org> (raw)
In-Reply-To: <20091106235405.GC5262@lackof.org>

[ sorry - didn't realize I hit "reply" instead of "reply-all" ]

On Fri, Nov 06, 2009 at 04:54:05PM -0700, Grant Grundler wrote:
> On Fri, Nov 06, 2009 at 09:37:31PM +0100, Helge Deller wrote:
> > Hi Grant,
> >
> > Thanks for your answers!!!
> ...
> >> IIRC, the graphics frame buffers are routed by every Elroy ELMMIO register
> >> on all 4 Elroys. If you can get the machine to NOT HPMC,
> >> ELMMIO resources should be listed in /proc/iomem for workstations.
> >
> > Ok, the good thing is, that it doesn't HPMCs.
> > But sadly I have no clue about what you write above :-(
> 
> Heh...Here is a short and probably inadequate explanation.
> 
> Elroy has 3 MMIO range registers that determine which physical
> addresses will get routed down to the PCI bus:
>    LMMIO  32-bit MMIO address range
>    ELMMIO "Extra" 32-bit MMIO address range
>    GMMIO  64-bit MMIO address range
> 
> The Astro that is upstream (via ropes) is also programmed to route
> specific addresses to specific Elroy devices. Including the ELMMIO
> and GMMIO ranges.
> 
> The upstream routing is essentially the negative decoding of the
> downstream routing. So if f9000000-f9ffffff is routed down to
> elroy with PCI01, then any addresses generated by the PCI devices
> OUTSIDE of that range will get routed upstream since Elroy
> is designed to believe there is no device on that bus that will
> respond to addresses outside that range.
> 
> It might be easiest to think of each MMIO transaction (read or write)
> as a network packet traversing a fabric and the MMIO address is
> the equivalent to an IP address. Each component in the path has
> a "routing table" (one or more MMIO range registers) to decide
> what to do with the packet.
> 
> >
> > Syslog says:
> > SBA found Astro 2.1 at 0xfed00000
> > Elroy version TR4.0 (0x5) found at 0xfed30000
> > PCI: Enabled native mode for NS87415 (pif=0x8f)
> > Elroy version TR4.0 (0x5) found at 0xfed32000
> > pci 0000:01:04.0: BAR 0: no parent found for of device [0xfa000000-0xfbffffff]
> > iosapic: hpa not registered for 0000:01:04.0
> > iosapic: hpa not registered for 0000:01:05.0
> > Elroy version TR4.0 (0x5) found at 0xfed38000
> > Elroy version TR4.0 (0x5) found at 0xfed3c000
> > iosapic: hpa not registered for 0000:03:02.0
> > powersw: Soft power switch at 0xf0400804 enabled.
> >
> >
> > Maybe it's important, that 2 Elroys are detected before the BAR0 message and 2 afterwards?
> 
> Yes, I think it is. There are two ELMMIO ranges being routed to PCI01 and
> PCI03.  Need to determine if those are the right PCI busses (ergo Elroy)
> for those devices and that the same resources are available in the kernel
> that is failing to boot. Just hack lba_pci.c to dump more info about
> the address routing while it's booting.
> 
> 
> >
> > and here is /proc/iomem:
> > root@c3000:~# cat /proc/iomem
> > 00000000-7fffffff : System RAM
> >   00000000-000009ff : PDC data (Page Zero)
> >   00100000-00602fff : Kernel code
> >   00603000-0073bfff : Kernel data
> > f05d0000-f05d0000 : lcd_data
> > f05d0008-f05d0008 : lcd_cmd
> > f2000000-f23fffff : PCI00 LMMIO
> >   f2000000-f2001fff : 0000:00:0f.1
> >     f2000000-f2001fff : sym53c8xx
> >   f2002000-f2003fff : 0000:00:0f.0
> >     f2002000-f2003fff : sym53c8xx
> >   f2004000-f20043ff : 0000:00:0f.1
> >     f2004000-f20043ff : sym53c8xx
> >   f2005000-f20053ff : 0000:00:0f.0
> >     f2005000-f20053ff : sym53c8xx
> >   f2006000-f2006fff : 0000:00:0e.2
> >   f2007000-f2007fff : 0000:00:0e.2
> >     f2007000-f2007fff : ohci_hcd
> >   f2008000-f20083ff : 0000:00:0c.0
> >     f2008000-f20083ff : tulip
> >   f2009000-f200900f : 0000:00:0d.0
> >   f200a000-f200a00f : 0000:00:0d.0
> >   f200b000-f200b00f : 0000:00:0d.0
> >   f200c000-f200c1ff : 0000:00:0d.0
> >   f2040000-f207ffff : 0000:00:0c.0
> > f2400000-f27fffff : PCI01 LMMIO
> >   f2400000-f240ffff : 0000:01:04.0
> > f3000000-f33fffff : PCI02 LMMIO
> >   f3000000-f3003fff : 0000:02:01.0
> >   f3004000-f300407f : 0000:02:03.0
> >     f3004000-f300407f : tulip
> >   f3040000-f307ffff : 0000:02:03.0
> > f3800000-f3bfffff : PCI03 LMMIO
> >   f3800000-f39fffff : 0000:03:02.0
> > f6000000-f7ffffff : PCI03 ELMMIO
> >   f6000000-f7ffffff : 0000:03:02.0
> > f9000000-f9ffffff : PCI01 ELMMIO
> >   f9000000-f9ffffff : 0000:01:05.0
> 
> I suspect how these are parented has changed.
> IIRC, Astro already "owns" this resource - but they aren't PCI devices.
> I don't recall offhand how the resource is (if at all) advertised and
> which Elroy's can even claim specific MMIO ranges.
> 
> If the "fb at f6000000 (32 MB)" is coming from the PCI03 Elroy, then
> you can be sure the MMIO resource is not being advertised correctly.
> But the output below suggests its from PCI bus 1 (== PCI01 ? need to check).
> 
> hth,
> grant
> 
> > fed00000-fed00fff : 10
> > fed30000-fed30fff : 10:0
> > fed32000-fed32fff : 10:1
> > fed38000-fed38fff : 10:4
> > fed3c000-fed3cfff : 10:6
> > fef00000-feffffff : Astro Intr Ack
> > fff80000-fffaffff : Central Bus
> >   fffa0000-fffa0fff : 32
> > fffb0000-fffdffff : Local Broadcast
> > fffe0000-ffffffff : Global Broadcast
> >
> >
> >
> >>> ...
> >>> STI GSC/PCI core graphics driver Version 0.9a
> >>> sti 0000:01:04.0: device not available because of BAR 0 [0xfa000000-0xfbffffff] collisions
> >>> sti 0000:01:04.0: Cannot enable PCI device
> >>> 			^^^ HERE
> >>> sti: probe of 0000:01:04.0 failed with error -22
> >>> STI PCI graphic ROM found at f3800000 (2048 kB), fb at f6000000 (32 MB)
> >>>      id 35acda30-9a02587, conforms to spec rev. 8.0d
> >>>      graphics card name: A1262A
> >>> sticon: Initializing STI text console.
> >>> Console: switching to colour STI console 128x48
> >>> stifb: 'A1262A' (id: 0x35acda30) not supported.
> >>> Linux agpgart interface v0.103
> >>> ....
> >>>
> >>> Hopefully someone of you has an idea what caused this change?
> >>
> >> The automatic resource parenting code has changed a few times back
> >> and forth over the last 2-3 major releases. I've lost track
> >> but suspect it's probably easier to just look at what the
> >> LBA range registers say (set up by PDC) and then get the PCI subsystem
> >> to advertise those resources in a reasonable way.
> >
> > How can I see/check the LBA range registers?
> > Where is the advertising done?
> > Sorry, but I have no clue about PCI/LBA/Elroy/... ?
> >
> >> TBH, I'd rather spent a few hours this weekend debugging the PCI-PCI bridge
> >> support on PAT machines.
> >
> > Understood.
> > Any hints or untested patches would be great though...
> >
> >> hth,
> >> grant
> >
> > Thanks,
> > Helge
> >
> >
> >>
> >>>
> >>> lspci reports:
> >>> 01:04.0 Display controller: Hewlett-Packard Company A4977A Visualize EG (rev 03)
> >>>          Flags: 66MHz, medium devsel
> >>>          Memory at fa000000 (32-bit, non-prefetchable) [size=32M]
> >>>          Expansion ROM at f2400000 [disabled] [size=64K]

  parent reply	other threads:[~2009-11-06 23:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-03 21:00 pci 0000:01:04.0: BAR 0: no parent found for of device Helge Deller
     [not found] ` <20091106062234.GC4574@lackof.org>
     [not found]   ` <4AF4890B.4050700@gmx.de>
     [not found]     ` <20091106235405.GC5262@lackof.org>
2009-11-06 23:55       ` Grant Grundler [this message]
2009-11-10 21:55         ` Helge Deller
2009-11-10 16:56 ` Domenico Andreoli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091106235525.GD5262@lackof.org \
    --to=grundler@parisc-linux.org \
    --cc=deller@gmx.de \
    --cc=linux-parisc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.