GPMI iMX6ull timeout on DMA

[Michael Nazzareno Trimarchi]

Hi

On Mon, Feb 1, 2021 at 3:32 PM Michael Nazzareno Trimarchi
<michael at amarulasolutions.com> wrote:
>
> Hi
>
> On Mon, Feb 1, 2021 at 3:13 PM Miquel Raynal <miquel.raynal at bootlin.com> wrote:
> >
> > Hi Michael,
> >
> > Michael Nazzareno Trimarchi <michael at amarulasolutions.com> wrote on
> > Sat, 30 Jan 2021 10:41:29 +0100:
> >
> > > Hi Miquel
> > >
> > > commit f8e6ad14388067f91b26d044185d95623fbc9535
> > > Author: Michael Trimarchi <michael at amarulasolutions.com>
> > > Date:   Fri Jan 29 08:46:53 2021 +0100
> > >
> > >     mtd: nand: Calculate the clock before enable it
> > >
> > >     Signed-off-by: Michael Trimarchi <michael at amarulasolutions.com>
> > >     Change-Id: I79b0da39de0a9b32ea0b002fa200d7f44d4f8ce7
> > >
> > > diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > index 322a008290e5..0bca52b3bc8f 100644
> > > --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > @@ -377,6 +377,7 @@ static void gpmi_nfc_compute_timings(struct
> > > gpmi_nand_data *this,
> > >                                      const struct nand_sdr_timings *sdr)
> > >  {
> > >         struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > > +       struct resources *r = &this->resources;
> > >         unsigned int dll_threshold_ps = this->devdata->max_chain_delay;
> > >         unsigned int period_ps, reference_period_ps;
> > >         unsigned int data_setup_cycles, data_hold_cycles, addr_setup_cycles;
> > > @@ -440,6 +441,8 @@ static void gpmi_nfc_compute_timings(struct
> > > gpmi_nand_data *this,
> > >                 hw->ctrl1n |= BF_GPMI_CTRL1_RDN_DELAY(sample_delay_factor) |
> > >                               BM_GPMI_CTRL1_DLL_ENABLE |
> > >                               (use_half_period ? BM_GPMI_CTRL1_HALF_PERIOD : 0);
> > > +
> > > +       clk_set_rate(r->clock[0], hw->clk_rate);
> > >  }
> > >
> > >  void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > @@ -449,8 +452,6 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > >         void __iomem *gpmi_regs = r->gpmi_regs;
> > >         unsigned int dll_wait_time_us;
> > >
> > > -       clk_set_rate(r->clock[0], hw->clk_rate);
> > > -
> > >         writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
> > >         writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
> > >
> > > Right now I have this change applied and seems fine. That is the only
> > > difference I get. Clock is apply a bit earlier that when is enabled
> > > it.
> >
> > This is very interesting. So this would mean the issue you are
> > experiencing comes from the clock driver which kind of returns too
> > early from clk_set_rate()? Could you report this to the clk ML/NXP clk
> > maintainers and keep us in copy? If it is as global as it sounds, we
> > might not be the only ones affected.
> >
>
> The imx28 is broken too, so it's a general problem. I need to trace it down
> I have a reverting for lts but it\s not the way to go
>

For imx28 you ask to set the rate to 22Mhz but you don't care about the clock
that you get back. You get back 12Mhz because the base clock is 24 Mhz and seems
that it can not get the point. You need to check if the clock
requested is in range or ask
for set_rate_clk_min to avoid to have somenthing lower. Then for
imx6ull because is sporadic
I think that is more connected to the clk_set_rate and when you change
the register. Can not be a
setting time?

Michael

> Michael
>
> > Thanks,
> > Miquèl
>
>
>
> --
> Michael Nazzareno Trimarchi
> Amarula Solutions BV
> COO Co-Founder
> Cruquiuskade 47 Amsterdam 1018 AM NL
> T. +31(0)851119172
> M. +39(0)3479132170
> [`as] https://www.amarulasolutions.com



-- 
Michael Nazzareno Trimarchi
Amarula Solutions BV
COO Co-Founder
Cruquiuskade 47 Amsterdam 1018 AM NL
T. +31(0)851119172
M. +39(0)3479132170
[`as] https://www.amarulasolutions.com