Long ago I've noticed (but didn't pay much attention) that
spi_mpc83xx using PM calculations that differs from what
specs describe. I.e.
u8 pm = mpc83xx_spi->spibrg / (spi->max_speed_hz * 4);
While specs says: "The SPI baud rate generator clock source (either
system clock or system clock divided by 16, depending on DIV16 bit) is
divided by 4 * ([PM] + 1), a range from 4 to 64.".
Thus " - 1" is missing in the spi_mpc83xx's formula.
Why nobody noticed that bug? Probably because sysclk usually less then
user expects, e.g. you expect 200 MHz, but real clock is 198 MHz,
and integer rounding helps when this formula is used.
Suppose it's SPI in QE, SYSCLK at 198 MHz, thus SPIBRG at 99MHz, 25 MHz
requested.
PM = (99MHz / ( 25 MHz * 4 )), PM == 0, output SPICLK will be 24.75 MHz
At lower frequencies this bug is more noticeable, though.
And this bug shows itself in all its beauty if SYSCLK is equal or a bit
more than you expect (200 MHz SYSCLK, 100 MHz SPIBRG):
PM = (100MHz / ( 25 MHz * 4 )), PM == 1, output SPICLK will be 12.625 MHz!
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
if (value == BITBANG_CS_ACTIVE) {
u32 regval = mpc83xx_spi_read_reg(&mpc83xx_spi->base->mode);
u32 len = spi->bits_per_word;
+ u8 pm;
+
if (len == 32)
len = 0;
else
regval |= SPMODE_LEN(len);
if ((mpc83xx_spi->spibrg / spi->max_speed_hz) >= 64) {
- u8 pm = mpc83xx_spi->spibrg / (spi->max_speed_hz * 64);
+ pm = mpc83xx_spi->spibrg / (spi->max_speed_hz * 64) - 1;
if (pm > 0x0f) {
dev_err(&spi->dev, "Requested speed is too "
"low: %d Hz. Will use %d Hz instead.\n",
}
regval |= SPMODE_PM(pm) | SPMODE_DIV16;
} else {
- u8 pm = mpc83xx_spi->spibrg / (spi->max_speed_hz * 4);
+ pm = mpc83xx_spi->spibrg / (spi->max_speed_hz * 4);
+ if (pm)
+ pm--;
regval |= SPMODE_PM(pm);
}