On Monday 02 March 2009, Linus Torvalds wrote: > > On Mon, 2 Mar 2009, Bartlomiej Zolnierkiewicz wrote: > > > > > > Could we make just the IDE driver itself enable interrupts? Sure. But that > > > > Actually it has been doing it for years (some host drivers don't do this by > > default and still need "hdparm -u" or equivalent but I was planning to change > > it for 2.6.30). > > The IDE layer has the option to enable irq's during the transfer itself, > yes. But it actually works the reverse way from what you think: the irq Hmm, I said nothing about how it is implemented in the IDE code itself. :) > layer will enable interrupts, and the IDE layer will then _not_ disable > them during the transfer if you use "hdparm -u". > > Look at ide_intr: it generally gets called with interrupts _enabled_ > (because it doesn't use IRQF_DISABLED) and then it does: > > spin_lock_irqsave(&hwif->lock, flags); > .. > spin_unlock(&hwif->lock); > .. > if (drive->dev_flags & IDE_DFLAG_UNMASK) > local_irq_enable_in_hardirq(); > ... > spin_lock_irq(&hwif->lock); > ... > spin_unlock_irqrestore(&hwif->lock, flags); > > where the magic thing is how it enables irqs again if the "irq unmask" > flag is set. > > The point I'm making is that > > - as far as the generic irq layer is concerned, IDE might as well have > interrupts enabled all the time (and disabling them is a local issue, > more to do with locking and with timing-induced hardware _bugs_ rather > than anything else) > > - .. and more importantly, that is AS IT MUST BE. Because quite frankly, > if the irq handler enables interrupts (like IDE does), the generic IRQ > layer really _must_ know about it, because it may depend on > non-reentrancy of that interrupt. Fixing this is on long-term TODO (there was just a ton of more high-prio stuff to take care of first). Thanks, Bart -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
