Hi Karoly, and sorry for not getting back to you sooner on this. On Thu, Jul 05, 2018 at 04:12:17PM +0000, Karoly Pados wrote: > Hi, > > > Karoly, how did your line-speed tests with cp2102n go? > > I indeed tested this. I first built a version of the module where I skip > calling cp210x_quantise_baudrate(). Then I attached a scope to the TX > line of my UART adapter and looked at various non-standard values in both > low (<10k) and high (>2M) ranges. In all cases it looks like you can set > any custom value to the cp2102n, assuming you use the right program to > set the baudrate (most I've tried either do not allow non-standard > rates or give an IOCTL error). > > So basically I can confirm that the chip does not snap to values in > table 1 of AN205. I was able to set very odd rates, and measurements with > the scope verified that they were actually applied correctly by the > cp2102n (sometimes ofc with a few percent error here and there). That's great, thanks for verifying. > > ... I think we should > > just handle the higher cp2102n rates as we do with cp2104/8, that is by > > mapping the lower rates to the rates supported by legacy devices, while > > allowing any higher rates (up to the device maximum) to be requested > > without trying to report back the actual rate chosen (for now). > > Based on the test above, my proposal for the cp2102n only is to not do any > kind of software snapping / quantisation in the driver module, except for > capping out at the maximum of 3Mbaud. Otherwise we'd be limiting the > capabilities of the chip in the software artificially. Indeed, I was only only suggesting that we need not solve every issue at once. :) > As for reporting the actual baudrate back to userspace, the formula is > documented clearly by SiLabs, so if that's possible somehow, I'm in favor > of it. The question is, how? Right, and it's documented in the driver as well, but no one has gotten around to implementing yet. And as you already noticed, you can report back the actual rate used through tty_encode_baud_rate(). I'll be sending my 4.19 updates to Greg this week and want to have this included. To save some time, I've reworked your v2 patch on top of this series and generalised your implementation so that it can be used also for CP2104 and CP2105 (ECI). Thanks, Johan -- 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
