summaryrefslogtreecommitdiff
path: root/arch/arm
diff options
context:
space:
mode:
authorPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>2017-04-20 20:05:52 (GMT)
committerSimon Glass <sjg@chromium.org>2017-05-10 19:37:21 (GMT)
commit9fc354e246fe466ad634617e12d092d6053503ed (patch)
treeee92e7d2e0be2923254cb00955ee00eb1cb66f8d /arch/arm
parentbd3767143403a8e62ad29d6218ae6c7142e1898a (diff)
downloadu-boot-9fc354e246fe466ad634617e12d092d6053503ed.tar.xz
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>
Diffstat (limited to 'arch/arm')
0 files changed, 0 insertions, 0 deletions