On Mon, Aug 06, 2007 at 12:36:09PM +0200, Ingo Molnar wrote: > * Paul Mundt <[EMAIL PROTECTED]> wrote: > > This is a simple patch for adding trivial interrupt priority support. > > > > I've added a ->set_prio() to the irq_chip which is implemented > > effectively the same way as ->set_type(), it's an optional component > > for those that really care about it. > > i have no fundamental objections but it would be nice to actually > prototype this by implementing real priority support in the hardware: > both the i8259A and the IO-APIC/local-apic has such IRQ prioritization > features. > I would not have written the patch if I did not have hardware that supported it. I suppose I can start with interfacing the x86 PICs if that makes it easier to swallow, though ;-)
> > + * IRQF_PRIO_HIGH - Give IRQ a high priority > > + * IRQF_PRIO_LOW - Give IRQ a low priority > > this should be a numeric scale. (Preferably in the 1-99 range (the > hardware can then do a lower-resolution thing out of it), so that we can > directly map this to IRQ threads and SCHED_FIFO priorities in -rt.) > I don't disagree with that, but that makes it a little hard to pass in a priority at request_irq() time. These IRQF_PRIO_HIGH/LOW are only for such usage, the intent is to have a numeric value that's more meaningful to the underlying hardware passed on to set_irq_prio() otherwise. In any event, there's no problem with doing that anyways, both IRQF_PRIO_HIGH and IRQF_PRIO_LOW are substantially above the 1-99 range that the mask can be tested for if the underlying controller isn't interested in mapping the 1-99 range to its own view of priorities. Presumably you want this numeric range also reflected in the irq_desc for -rt? If so, I'll start hacking something up. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
