summaryrefslogtreecommitdiff
path: root/drivers/pinctrl
diff options
context:
space:
mode:
authorSerge Semin <fancer.lancer@gmail.com>2019-05-14 13:14:12 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2019-08-04 09:34:56 +0200
commitd11053e3cd96727628200fd124396fa3160c3074 (patch)
tree98aa8b7dc65167b9d9bbb31600310baf53c67587 /drivers/pinctrl
parentd04ba4c317ae6ed84f7b93455a1031fa5ee5f02b (diff)
tty: max310x: Fix invalid baudrate divisors calculator
[ Upstream commit 35240ba26a932b279a513f66fa4cabfd7af55221 ] Current calculator doesn't do it' job quite correct. First of all the max310x baud-rates generator supports the divisor being less than 16. In this case the x2/x4 modes can be used to double or quadruple the reference frequency. But the current baud-rate setter function just filters all these modes out by the first condition and setups these modes only if there is a clocks-baud division remainder. The former doesn't seem right at all, since enabling the x2/x4 modes causes the line noise tolerance reduction and should be only used as a last resort to enable a requested too high baud-rate. Finally the fraction is supposed to be calculated from D = Fref/(c*baud) formulae, but not from D % 16, which causes the precision loss. So to speak the current baud-rate calculator code works well only if the baud perfectly fits to the uart reference input frequency. Lets fix the calculator by implementing the algo fully compliant with the fractional baud-rate generator described in the datasheet: D = Fref / (c*baud), where c={16,8,4} is the x1/x2/x4 rate mode respectively, Fref - reference input frequency. The divisor fraction is calculated from the same formulae, but making sure it is found with a resolution of 0.0625 (four bits). Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'drivers/pinctrl')
0 files changed, 0 insertions, 0 deletions