Am 30.10.2013 09:45, schrieb Mika Westerberg: > On Tue, Oct 29, 2013 at 06:42:49PM +0100, Frank Schäfer wrote: >> Am 29.10.2013 18:12, schrieb Frank Schäfer: >>> Am 29.10.2013 10:07, schrieb Mika Westerberg: >>>> On Mon, Oct 28, 2013 at 07:50:44PM +0100, Frank Schäfer wrote: >>>>> Mika Westerberg has reported that the fixed+improved divisor based baud rate >>>>> encoding method doesn't work anymore with his HXD device. >>>>> So until we've found out what's going on, reintroduce the old encoding algorithm >>>>> and use it for this and all newer chips for baud rates > 115200 baud. >>>>> Also switch back to the direct encoding method for baud rates <= 115200, because >>>>> it's unclear if the old divisor based encoding algorithm works for them. >>>>> >>>>> Reported-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> >>>>> Signed-off-by: Frank Schäfer <fschaefer.oss@xxxxxxxxxxxxxx> >>>> Tried this and with 115200 it works and fixes the problem. However, with >>>> speeds like 230400 and 460800 it still corrupts data. >>> Well, with this patch we go back to what we did since kernel 3.1 (since >>> commit 8d48fdf689fe "USB: PL2303: correctly handle baudrates above >>> 115200"), so you should face the same problems with these kernels, too. >> I've double checked that. With this patch applied to 3.12-rc the baud >> rate encoding is exactly the same as in 3.11 (for HXD chips). >> >> Are you sure your test setup is reliable / comparable ? Could you please >> re-check your results ? > I re-tested with 3.11 and 3.12-rc7 with this patch applied. With 3.11 all > tried speeds (115200, 230400 and 460800) work fine. With 3.12-rc7 + this > patch, 115200 works but 230400 and 460800 corrupt data. > > My test setup is such that I just start getty on ttyUSB0 with given speed > and then connect to it using picocom. Once logged in, command like 'ls' > will return listing that is corrupted somehow: > > [root@tbt02 /]# ls > NH$�j�I[0m/ init* linuxrc@ opt/ run@ tmp/r/ > etc/ lib/ media/ proc/ sbin/ usr/ > > It is supposed to look like: > > [root@tbt02 /]# ls > bin/ home/ lib32@ mnt/ root/ sys/ var/ > dev/ init* linuxrc@ opt/ run@ tmp/ > etc/ lib/ media/ proc/ sbin/ usr/ I tried to reproduce your problems (with a HX device) and got some data corruption, too. It seem that I have to wait ~30-60 seconds after the device(s) have been plugged in before the devices can be used. During this time, I can see the Rx/Tx LED of my FTDI device (which I'm using as communication partner) blinking. If I start getty + picocom earlier, I get data corruption. If I wait a minute, everthing works perfectly. But in both cases, there is no difference between kernel 3.11 and 3.12. At the moment, I'm not sure what to do. If your problems (with baud rates > 115200) are really a 3.11-> 3.12 regression, than going back to the old baud rate encoding should fix it. If it doesn't, then the conclusion would be that the problem must be something else. Let me sleep a night on this... Regards, Frank Schäfer -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
