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 <hswee...@visionengravers.com>
>> Cc: Ryan Mallon <rmal...@gmail.com>
>> Cc: Mika Westerberg <mika.westerb...@iki.fi>
>> Cc: Mark Brown <broo...@kernel.org>
>> Cc: Grant Likely <grant.lik...@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
N�����r��y����b�X��ǧv�^�){.n�+����{����zX����ܨ}���Ơz�&j:+v�������zZ+��+zf���h���~����i���z� �w���?�����&�)ߢf��^jǫy�m��@A�a���
0��h���i
