On Wed, 01 Jan 2003 00:05:48 -0500 (MET), Veit Kannegieser wrote:
>>BTW. why do you need to assign a PCI-bus to the cardbus controller device then?
>This should be the job of the BIOS, but i seem to have
>some especially bad (SystemSoft) BIOS.
I don't really understand:
There is one Cardbus-devic
Hi!
I just changed a bit in the accessing scheme. Previously I would have needed to
disable interrupts as soon as
I read or modified a BASE or SUB-Block. I have now implemented a usage field, so this
odd behaviour is not
needed anymore.
This also means that I can offer an API for direct acces
On Tue, 31 Dec 2002 21:07:45 +0100 (CET), Jimi wrote:
>Well, I assumed there would be only 1 bridge at all and that resource window would
>need to get used for all
>devices on cardbus.
Well, there may be only one bridge chip but usually it has two PCI
functions implemented - one for each PCCard
On Wed, 01 Jan 2003 11:33:23 +0100 (CET), Daniela Engert wrote:
>>I won't configure anything at all in that case and leave it to the cardbus
>>driver.
>Exactly. Don't try to solve things which are already solved.
I didn't know that it was solved already, because I assumed it would work different
On Wed, 01 Jan 2003 11:51:14 +0100 (CET), Jimi wrote:
>>Remember this scheme relies on a strong ordering of PCI bus numbers!
The above is paramount!
>My current enumeration logic is as follows:
>1) enumerate bus 0 and all already assigned buses (PCI2PCI bridges)
>2) now check, if there were any
On Wed, 01 Jan 2003 18:09:41 +0100 (CET), Daniela Engert wrote:
>>Or should I work through all unassigned bridges in the whole making: 1st bridge ->
>bus 1. Bridge with NIC
to
>>bus 2. 2nd bridge on bus 0 -> bus 3 and bridge with soundcard to bus 4?
>Now, this is ok. Do a depth-first tree walk.
