On Fri, 21 Sep 2012 19:52:04 +0200 Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > On Fri, Sep 21, 2012 at 5:25 PM, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote: > > > Untested but I suspect the following may help > > Nope it doesn't, it's not this part that goes wrong, it's the call to > tty_termios_encode_baud_rate() that is the problem, not how it > gets called. It's that function that fuzzes and "snaps" the baudrate > to some rough-fit speed and screws things up for me. It should only snap the baud rate if your caller didn't ask for a specific speed. With the older uart_get_baud_rate code it mangled the encoding because BOTHER got mangled by uart_get_baud_rate. The intended behaviour at tty layer is Caller passes BOTHER and actual bit rate - we return BOTHER and a bit rate Caller does not pass BOTHER (may not be TCGETS2 aware) we snap to the nearest Bfoo rate if within 5% otherwise we return BOTHER based rates. If you are calling TCSETS2 passing BOTHER and an actual specific speed you should always be getting handed back the speed requested as it'll see the BOTHER flag is present and assume the caller is smart. So how are you setting the speed and can you see at which point it is getting mushed ? Alan -- 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
