lkml.org 
[lkml]   [2000]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PCMCIA still doesn't work for 2.3.46-pre2
> > I have some questions.  I noticed when I boot, my 2 slots have pre-allocated
> > IRQs (one time I got both cards on the same irq and every other time, the
> > top slot is always IRQ5 which is already allocated by the PCI bios to pci
> > sound card. my 3c575 doesn't work very well being on IRQ5 when transfering
> > files)
>
> This is the PCI interrupt that gets allocated for the controller itself.
>
> That interrupt also gets used for all true cardbus cards.

Understood, but the way PCs (pronounced PissCz <g>) are going, there's
practically NO irqs free. If I enable apci (or is it acpi?), It uses irq 9.
Lesse, if we don't want irq conflicts (most pc hardware I've worked with do
not use IRQs above 15) I have 10 and 11 available. I have 3 if I disable
the irport (which is disabled currently). Lets assume I want to use 2
pcmcia adapters. Cardbus slot 1 has 10 and 2 has 11. The first inserted
card could get irq 3. The 2nd gets what irq?

Does yenta/pci_socket allocate the irq to the controller, or does this come
from the bios (I'm going to assume that it's set since I was able to load
the modules after loading the one for my sound card and they both had the
same irq).

> The allocation logic is probably slightly off, though. The code tries to
> avoid allocating an interrupt that is not used for anything else, but the
> code in question is new and might have problems. This particular irq
> selection is handled by the generic PCI interrupt code, see
> pcibios_lookup_irq() in arch/i386/kernel/pci-pc.c..

Oops. According to lspci -v, the maestro card already has irq5 before the
cardbus slots get allocated an irq.

> > Since the IRQs are preallocated, inserting an 8-bit or 16-bit card causes
> > another IRQ to be allocated. I'm not sure if the cardmgr (pcmcia-cs 3.1.8)
> > needs to understand how to do this, or the cards should be allocated on the
> > fly by another program. cardmgr would assign irq 3 to one of the cards
> > (irq3 is not used on this box, IRport disabled)
>
> A 16-bit PCMCIA card gets an ISA interrupt, and here the logic is
> completely different - it's not the same irq pin as the PCI interrupt, and
> we just search for a completely unused irq that matches the irq list that
> we know the controller can generate.

Seems a little harry. The hardware that is. pcmcia and cardbus cards would
be the equivilant of ISA and PCI cards having the same connector.

If pcmcia card is inserted, it gets an ISA irq. The same slot has another
IRQ assigned to it but not being used.

> > One more question. Was there a reason for having a seperate (modules here)
> > pci_socket.o and yenta.o? ATM, the debian /etc/pcmcia.conf wants a single
> > module for the controller. /etc/init.d/pcmcia uses insmod to load it,
> > obviously, telling it yenta won't allow ds.o to load, using pci_socket won't
> > load.
>
> The only real reason is that pci_socket.c can handle any kind of PCI
> PCCARD controller, while yenta.c just implements one specific class of
> controllers (namely the true cardbus ones). Right now any non-cardbus
> controller (whether it is PCI or ISA) just falls back on the i82365 code.

Interesting.

> In the future, there might be non-cardbus PCI PCCARD controllers. Although
> the way things are looking, that kind of hardware is getting pretty
> scarce..

Actually, not for me, but that laptop (a kiwi opennote 680t, piece of shit I
might add. Its the one I use at work) uses an older kernel 2.3.3x. It has
an omega micro pci-to-pcmcia controller.

By the way, in yenta_init(), I tried commenting out pci_set_power_state()
once and it never activated the cardbus card (At that time, that was the
only card I was testing) I'll try making yenta_init a nothing call and see
if it still locks up.

Another BTW. After removing the card (physically or logically doesn't
matter) and re-inserting it causes the system to lockup a little bit later
for no reason, keyboard will respond to sysrq-p.

--
Lab tests show that use of micro$oft causes cancer in lab animals

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.055 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site