On 20 April 2017 at 14:05, Philipp Tomsich <philipp.toms...@theobroma-systems.com> wrote: > 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.toms...@theobroma-systems.com> > Tested-by: Klaus Goger <klaus.go...@theobroma-systems.com> > --- > > Changes in v4: > - added in v4 after receiving complaints from the board-verification > team > > Changes in v3: None > Changes in v2: None > > drivers/spi/rk_spi.c | 25 ++++++++++++++++++++++--- > 1 file changed, 22 insertions(+), 3 deletions(-)
Applied to u-boot-rockchip/next, thanks! _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
