This has been bubbling on my brain for a while. I blathered on about
this on IRC to Tejun, but figured I might as well post it here and get
it archived.
In general, I think we should adopt a flexible or "loose" model for
acking interrupts on SFF controllers.
(a) whenever we are in bus-idle
Jeff Garzik wrote:
This has been bubbling on my brain for a while. I blathered on about
this on IRC to Tejun, but figured I might as well post it here and get
it archived.
In general, I think we should adopt a flexible or "loose" model for
acking interrupts on SFF controllers.
(a) whenever
> In general, I think we should adopt a flexible or "loose" model for
> acking interrupts on SFF controllers.
Agreed - especially as the IRQ is often essentially the drive output not
under any kind of sane control of ours.
> (a) whenever we are in bus-idle (qc == NULL), and get an interrupt, go
Mark Lord wrote:
Jeff Garzik wrote:
This has been bubbling on my brain for a while. I blathered on about
this on IRC to Tejun, but figured I might as well post it here and get
it archived.
In general, I think we should adopt a flexible or "loose" model for
acking interrupts on SFF controlle
Alan Cox wrote:
In general, I think we should adopt a flexible or "loose" model for
acking interrupts on SFF controllers.
Agreed - especially as the IRQ is often essentially the drive output not
under any kind of sane control of ours.
Good point (I had not thought of looking at it that way).
Jeff Garzik wrote:
Mark Lord wrote:
Jeff Garzik wrote:
This has been bubbling on my brain for a while. I blathered on about
this on IRC to Tejun, but figured I might as well post it here and
get it archived.
In general, I think we should adopt a flexible or "loose" model for
acking interru
Mark Lord wrote:
Jeff Garzik wrote:
Mark Lord wrote:
Jeff Garzik wrote:
...
The only question is, under which conditions do we return IRQ
"handled=1",
and which times should we return 0 ?
Definitely when a real IRQ wakes us up and we see (qc != NULL &&
drive_ready),
essentially exactly as
Tejun Heo wrote:
> And when reading off Status when idle, we'll need to return 0 from
> irq_handler. That will prevent IRQ screaming IRQ lock and nobody cared
That sentence was "That will prevent IRQ screaming from causing IRQ live
lock..." in my mind. Some packets were lost while transmitting i
Jeff Garzik wrote:
> Actually no, and that is a key benefit of this scheme: if we ensure
> that the polling paths are resilient even in case where interrupts are
> being delivered -- as we must do anyway -- then we don't have to worry
> about interrupt masking, either on the interrupt controller o
