Re: [PATCH] clk: mxs: ensure that i.MX28's ref_io clks are not operated too fast

["Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>]

Hello,

On Fri, Mar 22, 2019 at 10:51:32PM +0100, Uwe Kleine-König wrote:
> On Wed, May 03, 2017 at 08:56:25PM +0200, Uwe Kleine-König wrote:
> > Since commits 7d81397cd93d ("clk: mxs: add clock support for imx28") and
> > 64e2bc413047 ("clk: mxs: imx28: decrease the frequency of ref_io1 for
> > SSP2 and SSP3") the frequencies for ref_io0 and ref_io1 are initialized
> > to 288 MHz because the initial frequency "seems too high to be ssp clock
> > source directly". However this isn't enough to ensure that the frequency
> > isn't increased later again. In fact this happens on my machine as the
> > mxs-spi driver calls clk_set_rate(ssp->clk, 160000000) with ssp being
> > ssp2 which is resolved to
> > 
> > 	ref_io1.rate = 320 MHz
> > 	ssp2_sel.parent = ref_io1
> > 	ssp2_div.divider = 2
> > 
> > . The observed effect is that reading MISO reliably fails: Instead of
> > the least significant bit the second least significant bit is reported
> > twice. This is probably related to the reports
> > 
> > 	https://community.nxp.com/thread/290209
> > 	https://community.nxp.com/thread/310434
> > 	https://community.nxp.com/thread/385546
> > 
> > So additionally to initializing ref_io0 and ref_io1 to 288 MHz ensure
> > that their frequency is never set to something bigger later on. This is
> > done by adding a parameter min_frac to clk-ref and use that instead of
> > the hard coded 18 to limit the valid values for FRAC. For all ref clocks
> > but ref_io0 and ref_io1 18 is used and so there is no functional change
> > for those.
> > 
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> > Hello,
> > 
> > I'd expect this to go in as a fix as it repairs reading from an EEPROM which
> > should be a fairly common task.
> > 
> > It would be nice to get confirmation from NXP that this is a right fix and
> > that spi transfers are supposed to be reliable with ref_ioX <= 288 MHz.
> 
> I spend some time on this problem once more. I examined a machine that
> showed no issues with CLKCTRL_FRAC0.IO1FRAC >= 19, but reliably reported
> more than 32000 read errors with CLKCTRL_FRAC0.IO1FRAC == 18 when
> dumping an EEPROM that contains 32768 bytes that can show the error.
> 
> The boring to find insights are, that the error is independent of the
> other dividers in the clock tree that affect the spi clk frequency and
> hbus.
> 
> A more interesting insight is that applying coolant spray nearly
> halves the read rate (as reported by dd) but also the error rate drops
> to 0. After some time the machine reheats again and the error rate
> raises to nearly 100% as before.
> 
> I just shared that information with NXP's tech support and will keep you
> updated on their reactions.

The gist of their response is that this CPU is too old and so they don't
have much resources to spend time debugging things there any more. The
supporter suggested to upgrade to i.MX6 or i.MX7 instead ...

So we're living with the work around suggested in this thread and pray
it will continue to work for us even tough it doesn't seem to be robust
enough to fix the same problem for Stefan.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |