lkml.org 
[lkml]   [1999]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.3 wish: integrate pcmcia into mainstream kernel
    On Thu, Jun 03, 1999 at 08:52:54AM -0700, Linus Torvalds wrote:
    >
    > On Thu, 3 Jun 1999, Alan Cox wrote:
    > >
    > > Some of it is. The hard questions being
    > >
    > > "What irq is really free"
    > > "What dma is really free"
    > > "Give me some physical address space that isnt used"

    And "Give me some IO address space that isn't used"

    > > 1 & 2 you can kind of work around. #3 is a pain. Its also one that needs
    > > to be addressed for the 3D work (AGP GART) and for some I2O devices.
    >
    > I agree that #2 and #3 is needed, although I disagree about it being a
    > major pain.

    Welcome to my world, Linus. These are MAJOR pains. Actually, for me,
    since DMA over PCMCIA is so hopelessly broken as to be irrelevant, I
    find that #1 is the biggest pain, followed by #4, followed by #3. On
    #3, a 32-bit address space is big enough that if you just close your
    eyes and hope for the best, things usually work out ok, sadly enough.

    > It's just that nobody ever wrote anything I found acceptable
    > (all the patches I ever saw thought they should re-create the broken MS
    > documentation about PnP).

    Support for ISA PnP hardware isn't the issue. What I need is support
    for PnP BIOS calls: the calls to retrieve PCI interrupt routing
    information and hardware resource tables, specifically.

    > #1 should be a non-issue these days, and in fact works already (and ISA
    > stuff should just use exclusive irq's, and then request_irq() will give
    > you the information - and if you are sane and don't need exclusive
    > interrupts the whole issue is moot anyway).

    It doesn't work that way. I need to allocate an interrupt for PCMCIA:
    how do I pick it? Currently, I try to probe each "free" interrupt, to
    see if it is wired to the bridge. Some bridges don't support software
    triggered interrupts, but most do. So, I exclude some irq's by hand,
    because even if they appear free, they're probably committed to things
    like serial and parallel ports. Sadly, the probe tends to hard-lock
    some systems, I don't always know why. Probing an interrupt where the
    PCI bridge is expecting pulse-mode, but the Cardbus bridge is sending
    level-mode because I don't know any better, seems bad. Using PCI
    interrupts for CardBus would be nice, but with PCI_INTERRUPT_LINE
    always uninitialized for CardBus Bridges, I'm left with more probing.

    And IO ports? I try probing for "free" IO space, because again, the
    resources known to the Linux kernel are too incomplete to be depended
    on. Usually, the probe works well enough. Sometimes, reading from a
    device will screw it up: this seems to be a common problem with sound
    cards that have blocks of ports all over the place, some of which may
    not be used or even known about by the sound drivers. Other times, a
    range of ports reads back as all 0xff's, but if I try to put a PCMCIA
    card there, the system wedges. Bummer.

    -- Dave Hinds


    -
    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:52    [W:0.027 / U:240.512 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site