Messages in this thread | | | From | H Hartley Sweeten <> | Date | Fri, 28 Jun 2013 18:42:59 -0500 | Subject | RE: [PATCH 3/8] spi: spi-ep93xx: always handle transfer specific settings |
| |
On Friday, June 28, 2013 4:18 PM, Ryan Mallon wrote: > On 29/06/13 04:43, H Hartley Sweeten wrote: >> __spi_async(), which starts every SPI message transfer, initializes >> the bits_per_word and max speed for every transfer in the message. >> Since the conditional test in ep93xx_spi_process_transfer() will >> always succeed just remove it and always call ep93xx_spi_chip_setup() >> to configure the hardware for each transfer in the message. >> >> Remove the redundant ep93xx_spi_chp_setup() in ep93xx_spi_process_transfer() >> which just initializes the hardware to the "default" based on the SPI >> device. >> >> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> >> Cc: Ryan Mallon <rmallon@gmail.com> >> Cc: Mika Westerberg <mika.westerberg@iki.fi> >> Cc: Mark Brown <broonie@kernel.org> >> Cc: Grant Likely <grant.likely@linaro.org> >> --- > > >> + err = ep93xx_spi_calc_divisors(espi, chip, t->speed_hz); >> + if (err) { >> + dev_err(&espi->pdev->dev, "failed to adjust speed\n"); > > > Printing out the speed it was trying to set might be useful here?
Technically I don't think this can ever happen.
The minimum and maximum possible speeds are determined during the probe.
espi->max_rate = clk_get_rate(espi->clk) / 2; espi->min_rate = clk_get_rate(espi->clk) / (254 * 256);
Each transfer is validated to make sure the speed is greater than the minimum.
if (t->speed_hz < espi->min_rate) return -EINVAL;
Then the rate is clamped to the min/max rates.
rate = clamp(rate, espi->min_rate, espi->max_rate);
The calculations for the div_csr and div_cpsr values needed to produce the desired rate should always succeed.
Patch 7/8 actually replaces that dev_err() message with a more generic one. In reality, even the new message, and the error checking, could probably be removed.
Regards, Hartley
| |