[lkml]   [1998]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: ncr53c8xx + tulip IRQ sharing
    Jon Lewis wrote:
    > On Mon, 16 Feb 1998, Rogier Wolff wrote:
    > > No. Linux guarantees that YOUR interrupt will not occur. This means
    > > that you have free reign about your own device (the ncr8xx). However
    > > if you cannot tolerate being interrupted for a few microseconds, (e.g.
    > > if the device has a microsecond timeout after writing a "low word")
    > > you can opt for running the whole interrupt routine with interrupts
    > > off to keep things "consistent".
    > I didn't realize my question and lame BIOS would spark such a lively
    > debate. Anyone care to guess which is the best way to procede? Make the
    > NCR driver use slow interrupts? Make the Tulip driver use fast ones? Try
    > to somehow force them onto different IRQ's without the BIOS's help?
    > Note...I'm looking for a solution usable with 2.0.x. A possible solution
    > requiring 2.1.x has already been suggested, but I'd rather not go there
    > yet.

    I'm not sure about Rogier's comments in regards to 2.1.z, but in regards to
    2.0.x, your interrupt handler will never get called more than once
    regardless of the flags in use. The difference is that with the
    SA_INTERRUPT flag, your handler is called with global interrupts disabled
    (cli() state) and upon return the sti() state is restored and the irq is
    ended without any further activity. This means that there is no bottom half
    handler run after an SA_INTERRUPT interrupt completes. This isn't a problem
    for SCSI devices because the SCSI subsystem in 2.0.x doesn't have a bottom
    half handler. For network cards however, the story is different. Since
    network cards make extensive use of the net_bh for packet completion
    (essentially it can be called that), I could see performance problems if you
    set the SA_INTERRUPT flag on NIC drivers. In that case, the bottom half
    couldn't get run at the end of the interrupt, it would always have to wait
    for the scheduler to run the net_bh, which would increase latencies.
    Typically, there isn't a problem with running a SCSI interrupt handler
    without the SA_INTERRUPT flag, and by default the aic7xxx driver doesn't use
    that flag anyway. The trick then is that if your interrupt handler needs
    protection from other things, such as timer interrupts that could trigger a
    packet queue at the same time as your interrupt handler, then you need the
    global cli() protection in your interrupt handler. The aic7xxx driver in
    2.0.33 is written to accomodate either protection mechanism. If we are
    registered with SA_INTERRUPT, then interrupts will be off the whole time we
    are running. If we are registered without SA_INTERRUPT, then we turn
    interrupts off. However, note that there isn't any real need to test for
    which way you are registered, just use the save_flags(); cli();
    restore_flags(); functions around critical areas and then if you are called
    with interrupts enabled, this will disable then where they need to be, and
    if you are called with interrupts disabled(SA_INTERRUPT) then this will not
    unset that state when you call restore_flags(). Check the aic7xxx_isr()
    function and it should be fairly easy to adopt the same mechanism into the
    ncr driver's isr funciton and then change the flags it requests the
    interrupt with.


    Doug Ledford <>
    Opinions expressed are my own, but
    they should be everybody's.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:41    [W:0.021 / U:67.412 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site