linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tgih.jun@samsung.com (Seungwon Jeon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mmc: dw_mmc: change to use recommended reset procedure
Date: Fri, 11 Jul 2014 19:20:48 +0900	[thread overview]
Message-ID: <001301cf9cf1$c91c7310$5b555930$%jun@samsung.com> (raw)
In-Reply-To: <CAPz6YkXgoKPSQEdNOwAQDhEnFGFVArr_0obbVR_okAEOvLxtzA@mail.gmail.com>

On Fri, July 11, 2014, Sonny Rao wrote:
> On Thu, Jul 10, 2014 at 5:28 AM, Seungwon Jeon <tgih.jun@samsung.com> wrote:
> > Hi Sonny,
> >
> > I have missed this patch.
> >
> > You finally choose to take extra interrupt handling.
> > If it is not harm, it's fine.
> 
> Hi, thanks for coming back to it.  Based on my tracing, the interrupt
> seems to be okay and is just ignored.
> 
> >> -static inline bool dw_mci_fifo_reset(struct dw_mci *host)
> >> +static inline bool dw_mci_reset(struct dw_mci *host)
"inline" is no needed anymore.

> >>  {
> >> +     u32 flags = SDMMC_CTRL_RESET | SDMMC_CTRL_FIFO_RESET;
> >> +     bool ret = false;
> >> +
> >>       /*
> >>        * Reseting generates a block interrupt, hence setting
> >>        * the scatter-gather pointer to NULL.
> >> @@ -2334,15 +2330,59 @@ static inline bool dw_mci_fifo_reset(struct dw_mci *host)
> >>               host->sg = NULL;
> >>       }
> >>
> >> -     return dw_mci_ctrl_reset(host, SDMMC_CTRL_FIFO_RESET);
> >> -}
> >> +     if (host->use_dma)
> >> +             flags |= SDMMC_CTRL_DMA_RESET;
> >>
> >> -static inline bool dw_mci_ctrl_all_reset(struct dw_mci *host)
> >> -{
> >> -     return dw_mci_ctrl_reset(host,
> >> -                              SDMMC_CTRL_FIFO_RESET |
> >> -                              SDMMC_CTRL_RESET |
> >> -                              SDMMC_CTRL_DMA_RESET);
> >> +     if (dw_mci_ctrl_reset(host, flags)) {
> >> +             /*
> >> +              * In all cases we clear the RAWINTS register to clear any
> >> +              * interrupts.
> >> +              */
> >> +             mci_writel(host, RINTSTS, 0xFFFFFFFF);
> >> +
> >> +             /* if using dma we wait for dma_req to clear */
> >> +             if (host->use_dma) {
> >> +                     unsigned long timeout = jiffies + msecs_to_jiffies(500);
> >> +                     u32 status;
> >> +                     do {
> >> +                             status = mci_readl(host, STATUS);
> >> +                             if (!(status & SDMMC_STATUS_DMA_REQ))
> >> +                                     break;
> >> +                             cpu_relax();
> >> +                     } while (time_before(jiffies, timeout));
> >> +
> >> +                     if (status & SDMMC_STATUS_DMA_REQ) {
> >> +                             dev_err(host->dev,
> >> +                                     "%s: Timeout waiting for dma_req to "
> >> +                                     "clear during reset", __func__);
> >> +                             goto ciu_out;
> >> +                     }
> >> +
> >> +                     /* when using DMA next we reset the fifo again */
> >> +                     if (!dw_mci_ctrl_reset(host, SDMMC_CTRL_FIFO_RESET))
> >> +                             goto ciu_out;
> >> +             }
> >> +     } else {
> >> +             /* if the controller reset bit did clear, then set clock regs */
> >> +             if (!(mci_readl(host, CTRL) & SDMMC_CTRL_RESET)) {
> >> +                     dev_err(host->dev, "%s: fifo/dma reset bits didn't "
> >> +                             "clear but ciu was reset, doing clock update.",
> >> +                             __func__);
> >> +                     goto ciu_out;
> >> +             }
> >> +     }
> >> +
> >> +     if (IS_ENABLED(CONFIG_MMC_DW_IDMAC))
> >> +             /* It is also recommended that we reset and reprogram idmac */
> >> +             dw_mci_idmac_reset(host);
> >> +
> >> +     ret = true;
> >> +
> >> +ciu_out:
> >> +     /* After a CTRL reset we need to have CIU set clock registers  */
> >> +     mci_send_cmd(host->cur_slot, SDMMC_CMD_UPD_CLK, 0);
> >> +
> >> +     return ret;
> >>  }
> >>
> >>  #ifdef CONFIG_OF
> >> @@ -2555,7 +2595,7 @@ int dw_mci_probe(struct dw_mci *host)
> >>       }
> >>
> >>       /* Reset all blocks */
> >> -     if (!dw_mci_ctrl_all_reset(host))
> >> +     if (!dw_mci_ctrl_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS))
> >>               return -ENODEV;
> >>
> >>       host->dma_ops = host->pdata->dma_ops;
> >> @@ -2744,7 +2784,7 @@ int dw_mci_resume(struct dw_mci *host)
> >>               }
> >>       }
> >>
> >> -     if (!dw_mci_ctrl_all_reset(host)) {
> >> +     if (!dw_mci_reset(host)) {
> > Do you have any reason to use dw_mci_reset() unlike doing on probing?
> 
> I really wanted to use dw_mci_reset() everwhere, including probe,
> because that would be simplest, where there is just one reset function
> always, but the host structure is not completely set up at probe time,
> so the code in dw_mci_reset() where we try to send a command to update
> clock fails, so that's why I had to just do a reset.

Yes, if we can keep one interface, it would be good.
But can you check below?
Did you see the kernel panic on probing with "host->cur_slot" is NULL?
If right, resume seems not different from probe in case of removable type.
And dw_mci_idmac_reset() is redundant when dw_mci_reset() is used at resume.

I think dw_mci_ctrl_reset() can be also used at resume like at probe for simple way.
For safety's sake, "host->cur_slot" should be guaranteed it's not NULL.

Thanks,
Seungwon Jeon

  reply	other threads:[~2014-07-11 10:20 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-13  1:38 [PATCHv2] mmc: dw_mmc: change to use recommended reset procedure Sonny Rao
2014-05-13  5:02 ` Seungwon Jeon
2014-05-13  7:16   ` Sonny Rao
2014-05-13 11:09     ` Seungwon Jeon
2014-05-17  0:36       ` Sonny Rao
2014-05-20  1:49         ` Seungwon Jeon
2014-05-22 18:54           ` Sonny Rao
2014-05-29  0:35             ` [PATCH] " Sonny Rao
2014-05-29  5:17               ` Jaehoon Chung
2014-06-09 21:35                 ` Sonny Rao
2014-06-09 22:00                   ` Sonny Rao
2014-07-10 12:28                     ` Seungwon Jeon
2014-07-10 22:35                       ` Sonny Rao
2014-07-11 10:20                         ` Seungwon Jeon [this message]
2014-07-11 19:48                           ` Sonny Rao
2014-07-11 20:53                             ` [PATCHv5] " Sonny Rao
2014-07-14  5:52                               ` Jaehoon Chung
2014-07-14 22:06                                 ` [PATCHv6] " Sonny Rao
2014-07-18 13:37                                   ` Seungwon Jeon
2014-07-26  9:55                                   ` Ulf Hansson
2014-05-13  5:19 ` [PATCHv2] " Kukjin Kim
2014-05-13  8:46 ` Arnd Bergmann
     [not found] <CAPDyKFq2isO+DKMuLT9Ud8B9reFZiVYKG6LL8ysF0ZTNGfY8Nw@mail.gmail.com>
2014-08-05  1:19 ` [PATCH] " Sonny Rao
2014-08-07  8:40   ` Jaehoon Chung
2014-08-11  7:55   ` Ulf Hansson
  -- strict thread matches above, loose matches on Subject: below --
2014-03-26 11:46 Yuvaraj Kumar C D
2014-05-08  9:40 ` Yuvaraj Kumar
2014-05-09  1:15   ` Jaehoon Chung
2014-05-09  1:34     ` Sonny Rao
2014-05-09  4:27       ` Jaehoon Chung
2014-05-09  7:32         ` Jaehoon Chung
2014-05-10  3:36           ` Sonny Rao
2014-05-10 14:08             ` Seungwon Jeon
2014-05-12 21:14               ` Sonny Rao
2014-05-12 21:44             ` Sonny Rao
2014-05-13  0:40               ` Sonny Rao
2014-05-13 10:13               ` James Hogan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='001301cf9cf1$c91c7310$5b555930$%jun@samsung.com' \
    --to=tgih.jun@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).