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>]

On Wed, Aug 08, 2018 at 10:23:37AM +0200, Stefan Wahren wrote:
> Hi,
> 
> > > On Thu, Jul 26, 2018 at 11:50 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> > > 
> > > > I only want to note that we are using this ugly hack for Duckbill to avoid
> > > > this issue:
> > > >
> > > > https://github.com/I2SE/linux/commit/e457d5e0309c07e30e8dd8b17c32f7b3cbdd9547
> > > 
> > > Do you see the problem on TQMa28L with Stefan's hack applied?
> > 
> > With this change by Stefan the bug is not reproducible. Your change to
> > set the bypass bits only later doesn't help though.
> 
> i can confirm that Fabio's patch doesn't fix the clock issue on
> Duckbill. But the idea seems to be right. If i remove all write access
> to CLKSEQ and FRAC0 in clk_misc_init() instead of swap them, i don't
> need the ref_xtal hack anymore. I think Fabio's patch doesn't work
> because the bootloader (U-Boot in my case) is already feeding SSP from
> ref_io.

I spend some time with this problem again and found out that it also
depends on hclk. If that runs quicker than 2x sspX I couldn't reproduce
the issue. When slowing down hclk to 1x sspX the issue reappeared with
all stuff related to sspX keeping the same.

Probably a problem when the value crosses the clock domain from sspX to
hclk?!

Best regards
Uwe

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