On Tue, Jan 06, 2004 at 07:00:24PM +1100, Benjamin Herrenschmidt wrote:

On Tue, 2004-01-06 at 18:39, Sven Luther wrote:

quoted

On Tue, Jan 06, 2004 at 09:12:06AM +1100, Benjamin Herrenschmidt wrote:

quoted

quoted

Mmm, will look into this. Actually, linux should not write to those, but
read access should be ok.

If the BARs contain address ranges that will confuse linux resource
management (like RAM location), then you have to hide them completely.

Mmm, will check.

BTW, X has problems with pci config space access. It simply opens the
/proc/bus/pci/<bus>/<dev>.<func> stuff, and is not happy with the
result.

Is the above just a plain ioremap of config space or something such, or
does the reads there use the pci access functions ?

They should use the PCI access function, could be your access size
handling that is wrong (the offset masking stuff), or maybe XFree
shokes on the host bridge

Don't exactly know what happens, it dies with :

(II) Host-to-PCI bridge:
(II) Bus 16: bridge is at (0:0:0), (-1,16,0), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus 16 I/O range:
	[0] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus 16 non-prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x0) MX[B]
(II) Bus 16 prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x0) MX[B]

(full log on : http://zapek.com/misc/XFree86.0.log)

Need to install my box, and do some testing myself. X doesn't kill the
box though, which is rather nice.

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.

quoted

That said, i was a bit disapointed by 2.6. If you remember, i had some
problems with 2.4, since the second IDE bus uses a different interrupt
than the first one, so i used a kludge in the via-ide driver to make it
work. The 2.6 ide driver has per ide channel setup, but still does get
the primary ide interrupt for the second channel too.

Well, there is no clean way currently to deal with that issue. If I get
a board, I can try to hack something better :)

Will see. How long would you need the board, and you are in Australia
still, right ?

quoted

quoted

Argh ????? They don't appear on PCI ? What piece of SHIT is this bridge ?

Well, the Discovery II use a internal crossbar switch, and the ethernet
are on the same level as the pci buses. This makes for very efficient
networking i guess, but has problems. In fact, each of these ones has
the same priority as each pci bus.

I believe it should be possible to have each of these appear as an
independent pci bus or something ?

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 ?

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/