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). > ... 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. 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? Karoly -- 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
