GPMI iMX6ull timeout on DMA

[Miquel Raynal]

Hi Michael,

michael at amarulasolutions.com wrote on Sat, 9 Oct 2021 07:53:26 +0200:

> Hi
> 
> On Fri, Oct 8, 2021 at 6:07 PM Miquel Raynal <miquel.raynal at bootlin.com> wrote:
> >
> > Hi Christian,
> >
> > ceggers at arri.de wrote on Fri, 8 Oct 2021 15:49:21 +0200:
> >  
> > > On Friday, 8 October 2021, 15:36:31 CEST, Miquel Raynal wrote:  
> > > >
> > > > miquel.raynal at bootlin.com wrote on Fri, 8 Oct 2021 15:29:05 +0200:
> > > >  
> > > > >
> > > > > If this clock (as I understand) does not prevent us to access the
> > > > > registers but only feeds the external NAND bus part, then there is no
> > > > > need to enable it in the probe, just acquiring it will be enough.  
> > >
> > > clocks[0] is "gpmi_io" which sounds more like i/o than registers. So lets
> > > try to remove the initial call to clk_set_rate().
> > >  
> > > > > Then, the first call for an IO operation with ->must_apply_timings
> > > > > should:
> > > > >
> > > > >   if (imx6)
> > > > >           disable_clk();
> > > > >
> > > > >   clk_set_rate();
> > > > >
> > > > >   if (imx6)
> > > > >           enable_clk();  
> > >
> > > Do you think that the need for avoiding clock glitches is i.MX6 specific?
> > > The errata I mentioned is specific for the bootloader software, but (I think)
> > > the requirement for switching off the clocks gates prior changing the dividers
> > > may apply also for other series.  
> >
> > I honestly don't know, perhaps Han have more details about it. If you
> > think it's a wider issue, then we can just do the disable/enable step
> > without any further checks.
> >  
> 
> Still don't explain why it was working on the old driver. The glitch
> was already there,
> so just a delay can do the trick. For imx28 we need to reparent to a
> different clock the
> nand driver in order to get the frequency we want in EDO mode. I'm
> still thinking that
> set the frequency without without get back and understand if in that
> edo mode is valid
> is still a bug.

There are possibly two bugs here, I am also in favor of checking
that the received frequencies match what we expect, so please provide a
patch to also cover that situation.

Thanks,
Miquèl