From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Brice Subject: Re: [PATCH v1 0/2] spi: fsl-dspi: better approximation for baudrate Date: Fri, 03 Apr 2015 15:44:01 -0700 Message-ID: <551F17B1.3010109@datasoft.com> References: <1427965907-28125-1-git-send-email-andy.shevchenko@gmail.com> <551ED2F6.8020701@datasoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Brown To: Andy Shevchenko Return-path: In-Reply-To: Sender: linux-spi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: On 04/03/2015 01:59 PM, Andy Shevchenko wrote: > On Fri, Apr 3, 2015 at 8:50 PM, Aaron Brice 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html