Am 30.10.2013 23:07, schrieb Frank Schäfer: > 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.westerb...@linux.intel.com> >>>>>> Signed-off-by: Frank Schäfer <fschaefer....@googlemail.com> >>>>> 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 Hmm... try to replace the whole pl2303.c from 3.12 with the one from 3.11. If it makes no difference, it's not a pl2303 issue.
Frank -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
