From: Sven Luther <sven.luther@wanadoo•fr>
To: Geert Uytterhoeven <geert@linux-m68k•org>
Cc: Sven Luther <sven.luther@wanadoo•fr>,
Benjamin Herrenschmidt <benh@kernel•crashing.org>,
linuxppc-dev list <linuxppc-dev@lists•linuxppc.org>,
Rob Baxter <robb@synergymicro•com>
Subject: Re: multiple separate pci bridges ...
Date: Sun, 18 Jan 2004 13:15:07 +0100 [thread overview]
Message-ID: <20040118121507.GB4603@iliana> (raw)
In-Reply-To: <Pine.GSO.4.58.0401061533510.5752@waterleaf.sonytel.be>
On Tue, Jan 06, 2004 at 03:40:30PM +0100, Geert Uytterhoeven wrote:
>
> On Tue, 6 Jan 2004, Sven Luther wrote:
> > On Tue, Jan 06, 2004 at 07:00:24PM +1100, Benjamin Herrenschmidt wrote:
> > > Type 0 is an access to the primary segment (doesn't contain a bus
> > > number), type 1 is to be forwarded to another bus segment by a P2P
> > > bridge. So for anything directly attached to the host bridge, it's a
> > > type 0 access. Anything else is type 1. Typically, if the bus number of
> > > your "target" == hose->first_busno, it's type 0, else type 1
> >
> > Yep, except we have two pci controllers, and it should be type 0 for
> > both of them.
>
> Yep, two hoses, with different hose->first_busno.
>
> > > They could have appeared as on-chip PCI devices on a "pseudo-bus", but
> > > we can eventually just match with the host's PCI device.
> >
> > Ok. but this can also be faked or something ? But, how can we match with
> > the host PCI device, if we are going to hide it ?
>
> Hide the memory BAR only, not the full PCI device.
Ok, i have done this. I have followed the recomendations of the hardware
guy, and did the following :
device 0, function 0 : read access to bytes 0-15, read returns 0 on
regs > 15. Write access fails silently.
device 0, function 1-7 : both read and writes fail with
PCIBIOS_DEVICE_NOT_FOUND.
Additionnally, i have nullified the ressources with :
dev->resource[i].flags = 0;
dev->resource[i].start = 0;
dev->resource[i].end = 0;
from the pcibios_fixup (not the right place, but i don't know where it
should be done instead).
This allows me to see the host bridge on both buses, and radeonfb works
fine :
$ lspci
00:00.0 Host bridge: Galileo Technology Ltd.: Unknown device 6460 (rev 03)
00:01.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46)
00:05.0 SCSI storage controller: LSI Logic / Symbios Logic 53c810 (rev 23)
00:0c.0 ISA bridge: VIA Technologies, Inc. VT8231 [PCI-to-ISA Bridge] (rev 10)
00:0c.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
00:0c.2 USB Controller: VIA Technologies, Inc. USB (rev 1e)
00:0c.3 USB Controller: VIA Technologies, Inc. USB (rev 1e)
00:0c.4 Non-VGA unclassified device: VIA Technologies, Inc. VT8235 ACPI (rev 10)
00:0c.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 40)
00:0c.6 Communication controller: VIA Technologies, Inc. Intel 537 [AC97 Modem] (rev 20)
00:0d.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 51)
10:00.0 Host bridge: Galileo Technology Ltd.: Unknown device 6460 (rev 03)
10:08.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5964 (rev 01)
But :
$ hexdump /proc/bus/pci/10/00.0
0000000 ab11 6064 0700 b022 0300 0006 2000 0000
0000010 20df 85cf 20df 85cf 20df 85cf 20df 85cf
*
0000040
Why in hell do i have 0x20df85cf on all four bars of the config space
addresses 0x10 to 0x1f ?
Finally, X works, altough DRI freezes after a second or two with my
radeon 9200SE, while it works for a Radeon 7500, but this is probably a
DRI issue.
What makes me wonder, is that X needs around 20 seconds to launch, which
could not be something normal. It usually takes 5-8 seconds only.
Something strange is going on.
Thanks for your help.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2004-01-18 12:15 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-01 18:11 multiple separate pci bridges Sven Luther
2004-01-02 4:03 ` Benjamin Herrenschmidt
2004-01-02 7:40 ` Sven Luther
2004-01-02 7:49 ` Benjamin Herrenschmidt
2004-01-04 21:03 ` Sven Luther
2004-01-04 21:45 ` Benjamin Herrenschmidt
2004-01-04 22:06 ` Sven Luther
2004-01-05 16:40 ` Sven Luther
2004-01-05 21:28 ` Benjamin Herrenschmidt
2004-01-05 21:42 ` Sven Luther
2004-01-05 22:12 ` Benjamin Herrenschmidt
2004-01-06 7:39 ` Sven Luther
2004-01-06 8:00 ` Benjamin Herrenschmidt
2004-01-06 8:11 ` Sven Luther
2004-01-06 14:40 ` Geert Uytterhoeven
2004-01-06 14:45 ` Sven Luther
2004-01-06 15:33 ` Rob Baxter
2004-01-06 17:44 ` Sven Luther
2004-01-06 21:37 ` Benjamin Herrenschmidt
2004-01-06 22:10 ` Marcus Barrow
2004-01-06 22:17 ` Rob Baxter
2004-01-06 22:31 ` Benjamin Herrenschmidt
2004-01-07 2:35 ` Sven Luther
2004-01-07 2:36 ` Benjamin Herrenschmidt
2004-01-07 2:40 ` Sven Luther
2004-01-07 9:02 ` Michael Schmitz
2004-01-07 9:23 ` Benjamin Herrenschmidt
2004-01-07 9:56 ` Sven Luther
2004-01-07 10:27 ` Michael Schmitz
2004-01-13 9:56 ` Sven Luther
2004-01-13 10:26 ` Sven Luther
2004-01-18 12:15 ` Sven Luther [this message]
2004-01-18 13:00 ` Michel Dänzer
2004-01-18 13:14 ` Sven Luther
2004-01-19 9:12 ` Benjamin Herrenschmidt
2004-01-18 22:27 ` Sven Luther
2004-01-18 22:59 ` Benjamin Herrenschmidt
2004-01-19 9:21 ` Sven Luther
2004-01-18 23:24 ` Benjamin Herrenschmidt
2004-01-05 21:38 ` Marcus Barrow
2004-01-06 7:14 ` Sven Luther
2004-01-06 7:56 ` Benjamin Herrenschmidt
2004-01-06 8:20 ` Sven Luther
2004-01-02 18:34 ` Geert Uytterhoeven
2004-01-02 15:18 ` Rob Baxter
2004-01-02 23:56 ` Benjamin Herrenschmidt
2004-01-03 0:27 ` Rob Baxter
2004-01-03 1:12 ` Benjamin Herrenschmidt
2004-01-05 0:52 ` Rob Baxter
2004-01-05 2:13 ` Benjamin Herrenschmidt
-- strict thread matches above, loose matches on Subject: below --
2004-01-06 20:53 Marcus Barrow
2004-01-06 21:09 Marcus Barrow
2004-01-06 22:59 ` Benjamin Herrenschmidt
2004-01-06 23:00 ` Benjamin Herrenschmidt
2004-01-18 14:44 Sven Luther
2004-01-18 16:33 ` Michel Dänzer
2004-01-18 17:28 ` Sven Luther
2004-01-18 18:24 ` Michel Dänzer
2004-01-18 22:20 ` Sven Luther
2004-01-18 23:33 ` Michel Dänzer
2004-01-19 9:55 ` Sven Luther
2004-01-19 13:48 ` Sven Luther
2004-01-19 13:54 ` Geert Uytterhoeven
2004-01-19 14:00 ` Sven Luther
2004-01-19 14:02 ` Michel Dänzer
2004-01-19 14:16 ` Sven Luther
2004-01-19 14:31 ` Michel Dänzer
2004-01-19 9:11 ` Benjamin Herrenschmidt
2004-01-18 22:33 ` Sven Luther
2004-01-18 23:23 ` Michel Dänzer
2004-01-18 23:42 ` Benjamin Herrenschmidt
2004-01-19 0:03 ` Michel Dänzer
2004-01-19 10:08 ` Geert Uytterhoeven
2004-01-19 11:41 ` Benjamin Herrenschmidt
2004-01-19 12:03 ` Sven Luther
2004-01-19 21:35 ` Benjamin Herrenschmidt
2004-01-19 22:08 ` Sven Luther
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=20040118121507.GB4603@iliana \
--to=sven.luther@wanadoo$(echo .)fr \
--cc=benh@kernel$(echo .)crashing.org \
--cc=geert@linux-m68k$(echo .)org \
--cc=linuxppc-dev@lists$(echo .)linuxppc.org \
--cc=robb@synergymicro$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox