Re: [PATCH v1 0/2] spi: fsl-dspi: better approximation for baudrate

[Aaron Brice <aaron.brice@xxxxxxxxxxxx>]

On 04/03/2015 01:59 PM, Andy Shevchenko wrote:
> On Fri, Apr 3, 2015 at 8:50 PM, Aaron Brice <aaron.brice@xxxxxxxxxxxx> wrote:
>> On 04/02/2015 02:11 AM, Andy Shevchenko wrote:
>>>
>>> This series makes better approximation when baud rate divisor parameters
>>> are
>>> calculated.
>>>
>>> The algorithm is represent as Python script here [1]. First parameter is
>>> algorithm (0 - original, 1 - after patch 1/2, 2 - after patch 2/2, 3 -
>>> memory
>>> vs. performance: use precalculated scales).
>>>
>>> I played with let's say standard baud rates (which I used for Quark) and
>>> separately run algorithms 0 and 1 for range 100-5000 baud. Input frequency
>>> is
>>> 64MHz. It seems my algo shows better results in all cases. Here is a diff
>>> for
>>> 'standard' baud rates
>>> (speed_hz, DBR, i, BR, j, PBR, real baud rate, difference):
> 
> []
> 
>>>   3140500  0 1  4     2 5 3200000 59500
>>>   3125000  0 1  4     2 5 3200000 75000
>>>   3109500  0 1  4     2 5 3200000 90500
>>> -2500000  0 1  4     3 7 2285714 214286
>>> +2500000  0 3  8     1 3 2666666 166666
>>
>> The rest of these I'm not sure about.  The property is called
>> "spi-max-frequency" and the description in the bindings document is:
>>
>> - spi-max-frequency - (required) Maximum SPI clocking speed of device in Hz
> 
> I think we are talking about real world and real hardware. As far as I
> understand the problem with SPI (or any other) clocking is a
> consistent error.
> 
> If you have that error is a big enough the data might be corrupted.
> How big? Each difference between clocking is for hardware the shifted
> phase.  When phase is deviated your consumer might missed change of
> the signal and inverted a bit.
> 
> Thus, if the delta for clocking is small the hardware will still catch
> the change of the signal.
> 
> So, in practice it is quite unlikely to happen since usual devices
> have enough frequency margin.
> 

You're probably right that the extra Hz are "unlikely" to break
anything.  I think they're also unlikely to improve anything noticeably,
what systems do you have where the transfer speed of a SPI device is the
bottleneck?  In my case [1], I'm 1000% more concerned about reliability
than throughput for the SPI devices.

If I had one that was a bottleneck I could always bump up the
spi-max-frequency to a value that exceeded the spec to see if it would
work, but at least I'd be explicitly exceeding the spec instead of
having the driver silently do it for me..

> Can you test on real hardware? I'm pretty sure it's quite hard to find
> something that will not work.
> 

Shouldn't the burden be on you to prove that setting the frequency 8%
higher than the max frequency is safe on all hardware?

[1] http://datasoft.com/products/sidebridge/index.html

Aaron

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html