[U-Boot] [PATCH] mx6: fsl_esdhc: Fix waiting for DMA operation completion

[Gabbasov, Andrew]

> From: Eric Nelson [eric.nelson at boundarydevices.com]
> Sent: Tuesday, April 02, 2013 19:49
> To: Gabbasov, Andrew
> Cc: u-boot at lists.denx.de
> Subject: Re: [U-Boot] [PATCH] mx6: fsl_esdhc: Fix waiting for DMA operation completion
> 
> Thanks Andrew,
> 
> On 04/02/2013 03:04 AM, Andrew Gabbasov wrote:
> > On iMX6 sometimes the Transfer Complete interrupt occurs earlier
> > than the DMA part completes its operation. If immediately after that
> > the read data is used for some data verification, those obtained data
> > may be incomplete, which causes intermittent verification failures.
> >
> 
> Can you describe how to repeat this?
> 
> > For example, when the default environment command tries to load and run
> > boot script from FAT partition on SD/MMC card, it sometimes fails,
> > reporting invalid partition table, or unknown partition type, or
> > something else of that kind. Such errors disappear if the build
> > configuration has CONFIG_SYS_FSL_ESDHC_USE_PIO, or if some delay
> > is added after transfer completion.
> >
> We do this on every boot on SABRE Lite and Nitrogen6x boards,
> and haven't seen an issue.
> 
> What board are you testing on?
> 
> Do you have cache enabled?
> 
> Is this with an SD card or eMMC?

Hi Eric,

Thank you for the response.

I'm using SabreLite with SD card.

For reproducing a problem I took the latest version of U-Boot from master branch and made
a couple of changes in include/configs/mx6qsabrelite.h:
- removed duplication of "mmc dev ${mmcdev};" in CONFIG_BOOTCOMMAND;
- and changed CONFIG_ENV_IS_IN_MMC to CONFIG_ENV_IS_NOWHERE
(thus disabling to try reading saved environment from mmc).
The boot.scr contains a single command "printenv". When I'm doing resets with this
configuration, I'm getting errors in MMC access approximately once per 4-5 boots.
The errors can be "Invalid partition 2" or "No partition table".

Indeed, I was unable to reproduce it with plain master version, but 2 simple changes in configuration, described above, allowed me to reproduce it.

Thanks.

Best regards,
Andrew

> 
> > Adding extra waiting for DMA completion after Transfer Complete
> > event fixes this issue.
> >
> > Signed-off-by: Andrew Gabbasov <andrew_gabbasov at mentor.com>
> > ---
> >   drivers/mmc/fsl_esdhc.c |    6 ++++++
> >   1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> > index d2a505e..806c6dd 100644
> > --- a/drivers/mmc/fsl_esdhc.c
> > +++ b/drivers/mmc/fsl_esdhc.c
> > @@ -402,6 +402,12 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct mmc_data *data)
> >                               return COMM_ERR;
> >               } while (!(irqstat & IRQSTAT_TC) &&
> >                               (esdhc_read32(&regs->prsstat) & PRSSTAT_DLA));
> > +#ifdef CONFIG_MX6
> > +             /* In imx6 TC (data end) interrupt sometimes occur earlier
> > +                than DMA completes. In this case just wait a little more. */
> > +             while (!(irqstat & (IRQSTAT_DINT | IRQSTAT_DMAE)))
> > +                     irqstat = esdhc_read32(&regs->irqstat);
> > +#endif
> >   #endif
> >       }
> >
> >