Re: [PATCH] mmc: dw_mmc: Fixes timeout issue for FIFO mode

["gtXfined H." <hmz007@gmail.com>]

Hi,

The modification in the last email is just to debug the timeout error and
get a clearer understanding of
the timeout error, it doesn't solve the problem.

But the patch in my first email (sent by git), from what I've tested, does
solve the timeout error.


BR,
Jensen, Huang


On Wed, Jan 12, 2022 at 7:14 PM Jaehoon Chung <jh80.chung@samsung.com>
wrote:

> Hi,
>
> On 1/12/22 3:17 PM, gtXfined H. wrote:
> > Hi,
> >
> > I switched back to master branch and only made the following changes.
> >
> > --- a/drivers/mmc/dw_mmc.c
> > +++ b/drivers/mmc/dw_mmc.c
> > @@ -167,6 +167,10 @@ static int dwmci_data_transfer(struct dwmci_host
> > *host, struct mmc_data *data)
> >                         len = 0;
> >                         if (data->flags == MMC_DATA_READ &&
> >                             (mask & (DWMCI_INTMSK_RXDR |
> > DWMCI_INTMSK_DTO))) {
> > +                               if (!(mask & DWMCI_INTMSK_DTO) &&
> > +                                    (dwmci_readl(host, DWMCI_RINTSTS) &
> > DWMCI_INTMSK_DTO)) {
> > +                                       printf("warn: DTO changed to
> 1\n");
> > +                               }
> >                                 dwmci_writel(host, DWMCI_RINTSTS,
> >                                              DWMCI_INTMSK_RXDR |
>
> You need to set your email-client environment.
>
> https://www.kernel.org/doc/html/v5.16/process/email-clients.html?highlight=email
>
>
>
> > DWMCI_INTMSK_DTO);
> >                                 while (size) {
> > @@ -224,6 +228,11 @@ static int dwmci_data_transfer(struct dwmci_host
> > *host, struct mmc_data *data)
> >
> >         dwmci_writel(host, DWMCI_RINTSTS, mask);
> >
> > +#ifdef CONFIG_SPL_BUILD
> > +       printf("mmc: transfer %8p, %5d, in %4ld  (%d, %02x)\n",
> > +                       buf, data->blocks, get_timer(start), size, mask);
> > +#endif
> > +
> >         return ret;
> >  }
> >
> > Then tried the same test and reproduced the timeout issue with the
> > following logs.
> >
> > U-Boot SPL 2022.01-00373-gfe04d885fb-dirty (Jan 12 2022 - 13:52:15 +0800)
> > Trying to boot from MMC1
> > mmc: transfer  3fffac8,     1, in    0  (0, 0c)
> > mmc: transfer  3fffb80,     1, in    2  (0, 0c)
> > mmc: transfer  3fffd00,     1, in    1  (0, 0c)
> > warn: DTO changed to 1
> > mmc: transfer   2001c0,     1, in 1001  (0, 04)
> > mmc_load_image_raw_sector: mmc block read error
> > Trying to boot from MMC1
> > warn: DTO changed to 1
> > mmc: transfer   2001c0,     1, in 1001  (0, 04)
> > mmc_load_image_raw_sector: mmc block read error
> > SPL: failed to boot from all boot devices
> > ### ERROR ### Please RESET the board ###
> >
> > According to the logs, you can see that the DTO interrupt was
> > unintentionally cleared
>
> I had been tested after set the fifo-mode. It's occurred timeout error.
> But your patch doesn't work, too. It's not solution to solve this problem.
>
> Well, I have checked some code. It seems that there are some bugs about
> fifo-mode.
>
> Best Regards,
> Jaehoon Chung
>
> >
> >
> > BR,
> > Jensen, Huang
> >
> >
> > On Wed, Jan 12, 2022 at 7:04 AM Jaehoon Chung <jh80.chung@samsung.com>
> > wrote:
> >
> >> On 1/11/22 8:05 PM, gtXfined H. wrote:
> >>> Hi,
> >>>
> >>>>  Which board did you test? When you do power-on, is it reproduced
> every
> >>> time?
> >>>
> >>> I am using Rockchip RK3399 based board - NanoPi R4S for this test.
> >>> It doesn't appear every time, but it should be encountered once about
> 20
> >>> times.
> >>> I have run "setenv bootcmd reset; saveenv; reset" for automated
> testing.
> >>
> >> This patch doesn't clarify.
> >>
> >> The below commit had been fixed that doesn't work when data read.
> >> "mmc: dw_mmc: Fixes data read when receiving DTO interrupt in FIFO mode"
> >>
> >> It seems that not clearing during reset card.
> >> (power glitch or other problem..?)
> >>
> >> Best Regards,
> >> Jaehoon Chung
> >>
> >>>
> >>>
> >>>> Could you change from your ID to your name?
> >>>
> >>> This is my first time sending a patch, sorry I didn't notice this, do I
> >>> need to resend this patch?
> >>>
> >>>
> >>> BR,
> >>> Jensen, Huang
> >>>
> >>>
> >>> On Tue, Jan 11, 2022 at 6:38 PM Jaehoon Chung <jh80.chung@samsung.com>
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> On 1/11/22 7:24 PM, hmz007 wrote:
> >>>>> Clearing the DTO interrupt should be unnecessary, and it would
> >>>>> potentially result in never receiving this interrupt again.
> >>>>>
> >>>>> Do power-on or reset from uboot for a while can reproduce the issue:
> >>>>>   dwmci_data_transfer: Timeout waiting for data!
> >>>>>   mmc_load_image_raw_sector: mmc block read error
> >>>>
> >>>> Which board did you test? When you do power-on, is it reproduced every
> >>>> time?
> >>>>
> >>>>>
> >>>>> Tested on NanoPi R4S with SanDisk Extreme PRO 32GB.
> >>>>>
> >>>>> Fixes: 8cb9d3ed3a ("mmc: dw_mmc: Fixes data read when receiving DTO
> >>>> interrupt in FIFO mode")
> >>>>> Signed-off-by: hmz007 <hmz007@gmail.com>
> >>>>
> >>>> Could you change from your ID to your name?
> >>>>
> >>>> Best Regards,
> >>>> Jaehoon Chung
> >>>>
> >>>>> ---
> >>>>>  drivers/mmc/dw_mmc.c | 2 +-
> >>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> >>>>> index a949dad574..8fa26b340b 100644
> >>>>> --- a/drivers/mmc/dw_mmc.c
> >>>>> +++ b/drivers/mmc/dw_mmc.c
> >>>>> @@ -168,7 +168,7 @@ static int dwmci_data_transfer(struct dwmci_host
> >>>> *host, struct mmc_data *data)
> >>>>>                       if (data->flags == MMC_DATA_READ &&
> >>>>>                           (mask & (DWMCI_INTMSK_RXDR |
> >>>> DWMCI_INTMSK_DTO))) {
> >>>>>                               dwmci_writel(host, DWMCI_RINTSTS,
> >>>>> -                                          DWMCI_INTMSK_RXDR |
> >>>> DWMCI_INTMSK_DTO);
> >>>>> +                                          DWMCI_INTMSK_RXDR);
> >>>>>                               while (size) {
> >>>>>                                       ret = dwmci_fifo_ready(host,
> >>>>>
>  DWMCI_FIFO_EMPTY,
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>
>