Re: [PATCH] pl2303: restore the old baud rate encoding for HXD (and newer) chips

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.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
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux