On May 3, 2011, at 7:17 PM, Donald Lee wrote: > I no longer use serial on my production machine (PPC), because although I > could make it work, serial ports were always either a tad flaky, or required > a custom kernel somewhere or other. Maintaining the custom kernel was > only fun for the first little while. > > I modified the Cyclades driver to "hammer" the interrupt register sometimes > when it missed interrupts, and tweaked "soft_intr" machinery to reduce > (though apparently not eliminate) the misses. Yeah, I'd say that if you have to make the software poll the interrupt register in case you missed it, you really actually just want level sensitive interrupts (i.e. if an interrupt happens and you service it and there's still an interrupt, the ISR just fires again). In my experience designing both hardware and software, there are very few cases where you truly want an edge triggered interrupt (internally to hardware, I always latch high on a rising edge in case the source only has a single-clock pulse, but you still want to assert the interrupt if the source remains asserted). If you genuinely have a card that fires short pulses instead of holding #IRQ low (like most ISA cards), it's necessary. I'm posting a patch against -current, in case anyone wants to test it and/or commit it. If someone knows a good reason to keep the status quo, let me know, but I've hammered the serial ports pretty hard with no problems so far and no interference with other drivers. > P.S. I believe that the "lost interrupt" behavior may be relevant to ATA > errors and problems, and also to USB anomalies I have seen on the list. > This is purely speculation, though. I would be surprised if it's responsible for USB, at least, since USB is almost always implemented in PCI (where pretty much everything is level-sensitive). For oddball hardware like the original iMac, though, it might be a bit different. wdc_obio.c, for one, tries to determine from OF if the interrupt is edge or level triggered, but my knowledge of OF interrupt designations is pretty spotty, so I assume it's probably doing it right. - Dave
Attachment:
zs_interrupt_patch.diff
Description: Binary data