[lkml]   [2001]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Question about IRQ_PENDING/IRQ_REPLAY
    >We have about 12 interrupt controllers we end up using on PPC.  I'm
    >suspicious of any effort to base Linux/PPC generic interrupt control code
    >paths on a software architecture that's been tested with 3. More to the
    >point, we get ASIC's that roll in a standard interrupt controller and add
    >some "improvements" at the same time.

    Well, I personally don't see what would be a problem... Of course, the
    current i386 irq.c cannot be re-used completel "as is". The bit of code
    that gets the actual irq number has to be arch specific. But most of the
    locking issues are completely platform neutral.

    I personally see that code as a good framework that provides many features
    that may or may not be neccessary depending on the level of brokenness of
    a given interrupt controller.

    >As for SMP, I'm sure x86 has seen a lot more testing. I'm not going to
    >sacrifice time-tested stability so we can look just like x86 and get clean
    >SMP locking. We've lost stability already because of some PPC folks'
    >excitement at getting us to behave like x86 in irq.c.

    We lost stability ? Hrm... If we had ever a problem with SMP, it was in the
    openpic code, and apparently, due to a HW bug. I don't think the new irq.c
    code in itself caused us to lose stability. I actually do think it improved
    the locking, and so, stability.

    >As for a generic irq.c, as a guiding light, I'm all for it. It'll
    >certainly help work with RTLinux. It'll also help new architectures by
    >giving them a snap-together port construction kit. I'm still not going to
    >sacrifice stability in the short-term for this nice feature in the
    >long-run. I'm pretty sure we agree on this.

    Well, we have been running this new irq.c which I partially based on
    i386 for some monthes now, and had enough time to iron out most problems.
    Again, all the stability problems we had so far were related to the openpic
    implementation, I don't remember seeing one stability problem reported so
    far that was related to irq.c. And I've been running a couple of dual
    G4s without much trouble for some time now.
    We do (did ?) have a problem with irq distribution on SMP with openpic. I'm
    not sure we yet know exactly why, according to both you and IBM people, we
    are running over an HW bug of the openpic core. I see nothing in irq.c
    that can cause this.

    On the other hand, the new irq.c brings the irq depth handling, the ability
    to call enable/disable from within the handler (I've been wanting that for
    some time for the PMU driver), proper spinlock'ing, etc...
    And last, but not least, consistent semantics of enable/disable irq
    exposed to drivers (especially things like disable_irq() actually waiting
    for that irq to be completed on any other CPU).

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:29    [W:0.031 / U:10.280 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site