"Tosoni" <jp.tosoni@xxxxxxxxx> wrote: > I am talking about serial ports sharing the same interrupt. > Here are more details. > > Let's say that you have N ports sharing the same interrupt. When the data > rate is very high, or the processor is slow, the following may happen > depending on how you prioritize the ports: > > say that high-speed frames of 150 chars arrive on ports X and Y. > > 1/ enter ISR > 2/ test port X => process reception of a char, put it ahead of list > 3/ during processing of 2/ another char arrived on X ; goto 2 > 4/ during processing of loop 2/ and 3/ many chars arrived on port Y, some > were lost > 4/ process Y and other ports > 5/ All N ports are now quiet; exit ISR > > Now you have lost data on port Y because you prioritized X over Y. > > Got it ? I see how some port has to be checked first, so if others share the same interrupt, they have to be checked second. I don't see how this means that "one of them gets served much more often than the others"; both get served equally often. I also don't understand how the above can be a serious problem. Although slow relative to CPU speeds, the I/O port accesses are extremely fast relative to serial data transmission rates. Even at 115,200 baud, characters arrive every 86.8 us. Once the interrupt handler is executing, bytes are removed from the serial FIFO at around 1 per us. So not even a full character can arrive at port Y in the time it takes to completely empty 64 bytes out of port X's FIFO. In other words, your step 4/ cannot actually happen. If one more character is enough to cause port Y to overflow, it's perilously close to overflowing without port X. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
