On Sat, Feb 04, 2012 at 12:37:06PM -0700, Paul Walmsley wrote: > On Sat, 4 Feb 2012, Russell King - ARM Linux wrote: > > > On Sat, Feb 04, 2012 at 10:32:16AM -0700, Paul Walmsley wrote: > > > On Sat, 4 Feb 2012, Russell King - ARM Linux wrote: > > > > > > > [detailed discussion of framing errors] > > > > > > Thanks for the detailed description. If the driver is in fact discarding > > > characters with framing errors -- which I have not personally verified -- > > > then taking further action there is pointless. > > > > Paul, I know you don't particularly like me getting involved with OMAP > > issues, but tough. You don't seem to understand some of these issues so > > you're going to get more explanation. > > Hehe. Oh, hurt me again with more explanation, please ;-) I can't take > it ;-) I happen to enjoy many of your technical explanations. Doesn't > necessarily mean that we're always in agreement, though. > > As for the part about not wanting you involved with OMAP, that's an > interesting perspective, considering I mentioned to you at ELC-E last year > my appreciation of your technical review on the lists. And you'll > probably note, if you care to review the lists, that many of my E-mail > responses express gratitude for your comments... including the one you > quoted. > > Of course the snarky, personal bits can be unnecessarily irritating, but > anyone who's in this line of work just has to deal with them, it seems. Paul, you're being two faced. You can see the reaction that your message below gained: "On Sat, 4 Feb 2012, Russell King - ARM Linux wrote: "> [detailed discussion of framing errors] " "Thanks for the detailed description. If the driver is in fact discarding "characters with framing errors -- which I have not personally verified -- "then taking further action there is pointless." which, _to_ _me_, looks like you're trying to get rid of my input from this problem, and _that_ is extremely irritating. You talk of irritating, but maybe you don't realise that you're _just_ as irritating too at times - and that's not the first time you've attempted to cut off my input in that way. Especially when you start making suggestions like throwing away an entire FIFO load of data when you get a framing error. I think you have a fundamental misunderstanding about UARTs or what's required from them. Now, the fact is that POSIX allows user programs to tell the TTY drivers what behaviour they want, and it's essentially one of the following: 1. Ignore errors and receive all characters from the UART whether they be in error or not. 2. Receive characters in the FIFO and mark characters in error. 3. Receive all properly received characters. Which errors cause this behaviour can be controlled individually. Here's the extract straight from POSIX: If IGNBRK is set, a break condition detected on input shall be ignored; that is, not put on the input queue and therefore not read by any process. If IGNBRK is not set and BRKINT is set, the break condition shall flush the input and output queues, and if the terminal is the controlling terminal of a foreground process group, the break condition shall generate a single SIGINT signal to that foreground process group. If neither IGNBRK nor BRKINT is set, a break condition shall be read as a single 0x00, or if PARMRK is set, as 0xff 0x00 0x00. If IGNPAR is set, a byte with a framing or parity error (other than break) shall be ignored. If PARMRK is set, and IGNPAR is not set, a byte with a framing or parity error (other than break) shall be given to the application as the three-byte sequence 0xff 0x00 X, where 0xff 0x00 is a two-byte flag preceding each sequence and X is the data of the byte received in error. To avoid ambiguity in this case, if ISTRIP is not set, a valid byte of 0xff is given to the application as 0xff 0xff. If neither PARMRK nor IGNPAR is set, a framing or parity error (other than break) shall be given to the application as a single byte 0x00. So, as you can see, the serial driver does not have the option of throwing characters away just because an error bit is set - the behaviour required is left to userspace to decide, and are partly implemented by the tty layers and partly the serial driver. The requirements are well defined, and 8250 follows them - and I've just checked omap-serial against 8250 and it does the same. The fact is that the way OMAP implements the power management around UARTs is broken, because it results in corrupted characters being received. It's as plain and simple as that. And there's nothing you can to do solve the problem of the broken PM causing a badly received character which _may_ have a framing error being passed to userspace. If the termios settings are correct, the badly framed character shouldn't be passed to a shell - but that doesn't stop characters which don't have framing errors but still aren't received as they were transmitted being passed. And there's absolutely _nothing_ you can do about that as long as the broken PM is enabled on the port. As I illustrated in my 'detailed discussion of framing errors'. -- 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
