On Sun, Feb 05, 2012 at 03:37:21PM +0000, Woodruff, Richard wrote: > [x] What is acceptable depends is not black and white. Is there some > QOS mapping which can be set per channel which allows runtime PM to > pick a best chose (which may allow for loss and frame issues)?. What you're asking is whether there's anything in the kernel which can predict when the next character is to arrive. For many serial protocols, that would require a non-causal universe. So far, I'm afraid, physics hasn't managed to provably invent time travel in any useful way. Once physics has, then maybe this can be fixed. But, the fact of the matter is that deriving the UART clocks from a PLL which takes a finite time to lock, and the PLL is shut down during runtime PM _is_ _going_ _to_ _cause_ _problems_. There is absolutely no getting away from that. Let's take your modem example. Modems today would typically be used with some IP based protocol, probably PPP based. Incoming traffic on IP is entirely unpredictable. You wouldn't know when the next character would be received. One solution to this is to transmit an 0xff character before your real data to ensure that your end is awake and properly synchronized... Therefore, if you're running PPP (or, shudder, SLIP) over serial, you'd have to totally defeat the PM support for the port. No, not just for the initial negotiation, but all the time that the PPP connection was established. You can't rely on the remote end retrying, because of backoffs. You'll find that setting a PM timeout of maybe 5 seconds works, but as soon as you experience a flakey link somewhere, the TCP could backoff to 10 seconds or even minutes with its retry. At that point you're into a vicious circle because you're now putting the port into low power mode, which will drop the first character. That means that TCP's retry will get dropped on the floor, which in turn will increase the TCP backoff. And so the cycle continues with ever increasing TCP backoffs and no forward progress. ... but the problem with the 0xff character approach here is that most ISPs won't allow you to drop by and fiddle with their PPP termination to add that workaround. They'll rightfully tell you to go screw yourself and get some hardware which works. So, go ahead with having PM drop random characters if you want, but don't expect anyone in their right mind to accept broken workarounds to the kernel serial driver to try to drop maybe 16 characters or more at a time on the floor when a framing error occurs just because the PM is broken. And let's not forget the problem that current kernels have on OMAP34xx platforms. Literally minutes to get a dmesg out over a 115200 baud serial port, 16 characters at a time. I guess you're going to try to justify that as 'acceptable behaviour' from the system. Yes, of course it is. If you're dealing with a 1960s computer which processes that slowly. And I thought we were in 2012. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
