On Sat, 11 Mar 2000, Wakko Warner wrote:
> > I don't use modules. As a result, I haven't been all that interested
> > in making them work - at worst I will just not allow the "m"odule answer
> > in configure as nobody seems to be interested in fixing this.
>
> I can tell, but the way I've always seen it, if you don't need it to boot,
> you don't need it in the kernel.
Well, I personally think I need it to boot - not the way I have things set
up right now, but that's partly because ofit not being historically
possible.
There are some important devices behind the cardbus bridge - CD-ROM's,
network, stuff like that that can all be rather important for booting.
> > PCCARD really has two differentkinds of interrupts: the PCI interrupts and
> > the legacy ISA interrupts. The legacy ISA interrupts are dynamic, the PCI
> > interrupts are wired.
>
> So are you saying that my cardbus controller is hard wired to irq's 5 and
> 10 which the bios has no control over?
I'm saying that your _PCI_ interrupts are hardwired (*). Which is not to
say that the cardbus controller doesn't have other interrupts. The ISA
interrupts are usually handled with a generic serial protocol to the
southbridge, and have no hard routing at all.
(*) Technical details to follow, feel free to ignore.
The "hardwired" is actually not entirely true. What happens is that the
PCI interrupts are hardwired to the southbridge, and the southbridge is
able to do routing inside itself to actually specify where the PCI
interrupts go.
That wiring is fairly static, though - it is usually set up either by
the BIOS, or later changed at boot-time by the OS. And it should be
noted that some of the wiring decisions really are pure hardware. It may
be, for example, that your sound chip and your cardbus controller are
both wired to the same physical pin at the southbridge - at which point
it doesn't matter that the southbridge can route that to different IRQ
numbers, because whatever the routing is they will always go to the same
IRQ (it can just have a different number depending on the southbridge
setup).
Sometimes the PCI interrupts are actually physically routed over the
same serial interrupt protocol that the ISA interrupts use, and the
cardbus controller can be set up to use one of four different PCI
interrupts (INTA-INTD) in software.
However, the TI1225 in particular is fairly strange in this regard:
what the TI1225 chipd does is that the so-called "functional interrupts"
from the cardbus card seem to be always routed through the physical PCI
interrupt lines to the southbridge, while the "card status change"
interrupts are routed through the serial interface even if they are set
up to be PCI.
What does this all mean?
On a TI1225, as far as I can tell, the interrupts that the PCCARD card
sends are either 16-bit legacy interrupts for 16-bit PCMCIA cards
(routed through the serial interface to the southbridge) or PCI
interrupts wired directly to the southbridge for 32-bit CardBus cards.
In contrast, the card status change (CSC) interrupt that is used to
inform about newly inserted cards is always over the serial interface,
regardless of whether it is PCI or ISA.
Which means that even though the serial interface can be configured by
software on the TI1225, the PCI configuration really HAS to match the
physical wiring of the INTA/INTB interrupt lines from the cardbus
controller to the southbridge. In effect, the software configuration is
really a firmware configuration thing.
Anyway, back to the actual practical problem at hand:
What may be problematic is that when Linux changes the interrupt routing
when enabling a new PCI device, the kernel _tries_ to avoid re-using an
interrupt that is used by another PCI card. The fact that you get the same
interrupt for both sound and CardBus can mean either:
- they really are wired to the same physical chip (or firmware setup is
such that they end up virtually wired that way anyway)
OR
- the Linux southbridge PCI interrupt routing code isn't trying hard
enough.
The latter is definitely a possible problem. Linux does know how to route
various interrupts in the southbridge (at least to a limited degree), but
that code may not be quite good enough in trying to distribute interrupts
well.
Even if that could be improved upon, however, the fact remains that if the
sound driver has problems with shared PCI interrupts, then that is a bug
in itself. As I've tried to explain above, it is not guaranteed that it is
at all possible to avoid sharing the interrupt, and a good driver should
not be unhappy about the sharing.
[ more asides: sharing a PCI interrupt results in extra "spurious"
interrupts as far as a driver is concerned: the sound driver sees not
only its own interrupts, but also those of the other devices that share
the same interrupt line. It's usually very easy to handle spurious
interrupts: just ignore them if there doesn't seem to be anything to do.
But sometimes drivers are set up in a way that they will ignore status
reports etc, and do something unconditionally just because an interrupt
happened - even if that interrupt was not generated by the device that
the driver is there for.. ]
> Well if I decide to insert a pcmcia card, does this mean it will use that
> "yenta irq" or will it assign a new one?
That depends on the card. A 32-bit cardbus card will always use the PCI
interrupt (the "yenta interrupt"). A 16-bit PCMCIA card will use a legacy
ISA interrupt that is assigned at that time (ISA interrupts cannot be
shared).
Finally, regardless of the card the yenta driver itself will always use
the PCI interrupt (if available) for card status change information (ie
for when cards are inserted, removed, lose power etc etc).
Note that sometimes a PCI interrupt is not available at all, at which
point the yenta driver falls back on trying to use a legacy interrupt even
for 32-bit CardBus cards (and will not use a CSC interrupt at all, instead
just using a timeout to check whether cards have been added or removed).
This =usually= works.
> Sony. Never cared for them, and I've never had a sony product that didn't
> quit working. This was a sony tape deck (quit after 6 months), a cd player
> (wasn't sony brand, but had mostly sony chips), logic failure 1 year later.
> 2 sony Qic-Wide, well they required formatting quite a few times.
Actually, as far as I can tell, on the laptop side Sony makes some of the
best laptops available. I'm biased, because I like my laptops _small_, and
the Japanese laptop vendors tend to be more aggressive in the size
department (and many of the japanese models never make it to the US).
The problem with the Sony VAIO (and many other thin-and-lights) is that
because it tries to be so small, it tends to rely much more on cardbus
than a bigger laptop that has a CD-ROM and network built in. That meant
that when my new 100Mbps CardBus card did not work for me, I ended up
deciding that I really have to fix it up ;)
> Well, I must say the system worked better under 2.2.14 with david hinds
> pcmcia (3.1.11 I believe). My nic is a 3com 3cxfe575ct (I hate these
> numbers now).
Ok. I'll probably buy one of those cards, because it's fairly common too.
It may be that the driver just makes tons of assumptions that used to be
true... What are the console spam messages?
For example, one of the whole points of the new CardBus code is that a
cardbus card (like the 3c575) is supposed to look like a normal PCI card
that just supports hot-plug. This is what we did to the tulip driver:
instead of having one "tulip_cb.c" and one "tulip.c" - one for cardbus
devices and one for "regular" Tulip PCI cards, 2.3.x has one unified
driver that doesn't even care whether the card is in a PCI slot or behind
a CardBus bridge.
The same is not true of the 3c575 driver. There _should_ be just one
vortex driver (drivers/net/3c59x.c) that handles all of this, and some of
your problems may simply be due to old drivers.. The cardbus version of
the driver doesn't use the new PCI DMA interfaces, for example.
This is something where Jeff Garzik has been very good at making these
cleanups. Maybe I should buy him a 3c575 card too ;)
> The biggest problem I have with this thing is why it's always grabbing IRQs
> that are already inuse as opposed to ones that are available. I currently
> have USB disabled for 2 reasons, last time I tried the driver, it just
> didn't work (timeout errors), and 2, I don't have any usb devices. So I
> have irq 9 and irq 11 free. Maybe you could have something like
> yentairqlist= and list irqs that I want to use there. I'm not sure how
> windoze handles irq allocation, but I'll find out when I get to work monday.
Having a "yentairqlist=" thing is probably a good idea regardless. I'd be
even happier if all the drivers happily shared interrupts, though.
I agree that right now not all drivers do, but both ACPI and USB tend to
really require it because once they get enabled (something that is very
useful on a laptop), as you mention the free irq's tend to be fairly hard
to find. Which means that any driver that doesn't gracefully handle the
shared irq case is going to be a problem eventually..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:20 EST