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

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 ?

quoted

Well, i tried ioremapping 0x10000, but without much success
(cfg_addr/data is at cf8/cfc, and this magic stuff is at f118/f11c). I
just got a sig 11 OOPS, so ...

I don't fully understand... If you are doing IO cycles, there's no
ioremapping needed at all at this point, just use the one that is done
once for the bridge IO space. neither cf8/cfc not f118 look like
addresses that can be ioremap'ed anyway...

Well, it is f1000cf8/cfc and f100f118/f11c naturally, and the second is
needed to enable a hardware kludge to make the second pci bus look like
agp. I don't really have the details of such, but i need to write to the
f118/f11c before/after each pci access to the second pci bus, as well as
disable the CPU interrupts for doing the access.

quoted

quoted

just ioremap that in a global once... I do that for a few things in
pmac_feature.c, like the northbridge registers.

Yeah, i have seen.

quoted

quoted

Also, i had to manually set hose->bus_offset = 0x10, since that didn't
seem to be set automatically. I don't know why though.

Why do you need hose->bus_offset ? For indirect_pci ? Well... that's

Nope, i checked, and it was trying to read the bus 0x10, while the bus
is in reallity 0. That said, if i understood stuff correctly, it should
be ok, since type 0 config ignores bus and device, right ?

Yes. And for type 1, just issue a cycle to (bus - hose->first_busno)

How are the config access functions told that they shall do a type 0 or
1 access ? I have seen there is something in the pci_indirect functions
that do this, but not sure i can do it here.

quoted

quoted

a kludge, you should rather fix indirect_pci to use first_busno
instead... I don't know where this bus_offset comes from in the first
place, it's defined in pci_controller but not used at all in 2.6...

Yeah, nor in 2.4, if my grep is correct. I can't use indirect_pci for
the second bus though.

quoted

(BTW. You should really work on 2.6, not 2.4...)

Ah, yes, but 2.4 means suppoprt for debian-installer. Once that works, i
will work on 2.6.x. Also, 2.4 provides me a known working base.

I still don't like the idea of new dev. beeing done on 2.4...

Well, once i get it working, i will go on to 2.6, promised :))

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.

quoted

This is which bewilders me, the bridge spec speak about type 0 and type
1, and using the last 2 bits for this.

Yes. Usually, you don't put the last 2 bits of the offsets in cfg_addr,
you crop that value to the closest 32 bits boundary (or 64 bits in some
chips), and then you "offset" the cfg_data access.

For example, for a 8 bits access at an offset of 7, you would use 4
as the offset in cfg_addr, and then do a 8 bits access at cfg_data + 3

Ok, understand better now.

quoted

The Marvell Discovery II has (one, two or three) gigabit ethernets
included, these do not appear on the pci bus, but need to be programmed
directly with the NB registers. On the other hand, the sk98 driver
provides driver for various Marvell gigabit ethernet.

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 ?

Really totally insane.

Well, i am no hardware guy, so i cannot make judgement on this, but i
guess there are worse hardware out there.

I strongly suggest you still match them as PCI devices, eventually using
the bridge device itself as the match for the driver.... The DMA mapping
ops are designed to work with PCI anyway.

Mmm. Will have to look into that.

Again, thanks for your help,

Friendly,

Sven Luther

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