]> git.sur5r.net Git - u-boot/commit
rockchip: spi: rewrite rkspi_set_clk for a more conservative baudrate setting
authorPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Thu, 20 Apr 2017 20:05:52 +0000 (22:05 +0200)
committerSimon Glass <sjg@chromium.org>
Wed, 10 May 2017 19:37:21 +0000 (13:37 -0600)
commit9fc354e246fe466ad634617e12d092d6053503ed
treeee92e7d2e0be2923254cb00955ee00eb1cb66f8d
parentbd3767143403a8e62ad29d6218ae6c7142e1898a
rockchip: spi: rewrite rkspi_set_clk for a more conservative baudrate setting

The baudrate in rkspi was calculated by using an integer division
(which implicitly discarded any fractional result), then rounding to
an even number and finally clamping to 0xfffe using a bitwise AND
operator.  This introduced two issues:
1) for very small baudrates (overflowing the 0xfffe range), the
   bitwise-AND generates rather random-looking (wildly varying)
   actual output bitrates
2) for higher baudrates, the calculation tends to 'err towards a
   higher baudrate' with the actual error increasing as the dividers
   become very small. E.g., with a 99MHz input clock, a request
   for a 20MBit baudrate (99/20 = 4.95), a 24.75 MBit would be use
   (which amounts to a 23.75% error)... for a 34 MBit request this
   would be an actual outbout of 49.5 Mbit (i.e. a 45% error).

This change rewrites the divider selection (i.e. baudrate calculation)
by making sure that
a) for the normal case: the largest representable baudrate below the
   requested rate will be chosen;
b) for the denormal case (i.e. when the divider can no longer be
   represented), the lowest representable baudrate is chosen.

Even though the denormal case (b) may be of little concern in real
world applications (even with a 198MHz input clock, this will only
happen at below approx. 3kHz/3kBit), our board-verification team kept
complaining.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
drivers/spi/rk_spi.c