public inbox for linux-mmc@vger.kernel.org
 help / color / mirror / Atom feed
From: Jaehoon Chung <jh80.chung@samsung.com>
To: Doug Anderson <dianders@chromium.org>,
	Yuvaraj Kumar C D <yuvaraj.cd@gmail.com>
Cc: linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Jaehoon Chung <jh80.chung@samsung.com>,
	Chris Ball <cjb@laptop.org>, Seungwon Jeon <tgih.jun@samsung.com>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Sonny Rao <sonnyrao@chromium.org>,
	Tomasz Figa <t.figa@samsung.com>,
	Kukjin Kim <kgene.kim@samsung.com>,
	sunil joshi <joshi@samsung.com>,
	ks.giri@samsung.com, Prashanth G <prashanth.g@samsung.com>,
	Alim Akhtar <alim.akhtar@samsung.com>,
	Yuvaraj Kumar C D <yuvaraj.cd@samsung.com>
Subject: Re: [PATCH 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
Date: Wed, 25 Jun 2014 12:18:16 +0900	[thread overview]
Message-ID: <53AA3F78.3080804@samsung.com> (raw)
In-Reply-To: <CAD=FV=UGjm9y3XoBgWKjw9kp9W=ZrwB-S6Lh7T_LBUgCQZn1ag@mail.gmail.com>

On 06/25/2014 03:00 AM, Doug Anderson wrote:
> Yuvaraj,
> 
> On Mon, Jun 23, 2014 at 3:45 AM, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote:
>> This patch makes use of mmc_regulator_get_supply() to handle
>> the vmmc and vqmmc regulators.Also it moves the code handling
>> the these regulators to dw_mci_set_ios().It turned on the vmmc
>> and vqmmc during MMC_POWER_UP and MMC_POWER_ON,and turned off
>> during MMC_POWER_OFF.
>>
>> Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com>
>> ---
>>  drivers/mmc/host/dw_mmc.c |   71 ++++++++++++++++++++++-----------------------
>>  drivers/mmc/host/dw_mmc.h |    2 ++
>>  2 files changed, 36 insertions(+), 37 deletions(-)
> 
> Perhaps you could CC me on the whole series for the next version since
> I was involved in privately reviewing previous versions?
> 
> Overall caveat for my review is that I'm nowhere near an SD/MMC expert.
> 
> 
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 1ac227c..f5cabce 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -937,6 +937,7 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>>         struct dw_mci_slot *slot = mmc_priv(mmc);
>>         const struct dw_mci_drv_data *drv_data = slot->host->drv_data;
>>         u32 regs;
>> +       int ret;
>>
>>         switch (ios->bus_width) {
>>         case MMC_BUS_WIDTH_4:
>> @@ -975,16 +976,41 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>>
>>         switch (ios->power_mode) {
>>         case MMC_POWER_UP:
>> +               if ((!IS_ERR(mmc->supply.vmmc)) &&
>> +                               !test_bit(DW_MMC_CARD_POWERED, &slot->flags)) {
>> +                       ret = regulator_enable(mmc->supply.vmmc);
>> +                       if (!ret)
>> +                               set_bit(DW_MMC_CARD_POWERED, &slot->flags);

MMC_CARD_POWERED? I didn't know why it needs.

>> +               }
> 
> As per below, I'm not sure why you'd want to turn on vqmmc and vmmc at
> different times.
In my case, in order to prevent the H/W mis-operation, it turns on vqmmc and vmmc at different times.

> 
> Also: if you fail to turn on either of the regulators it feels like
> you should print a pretty nasty error message since your device will
> almost certainly not work.
> 
> 
>>                 set_bit(DW_MMC_CARD_NEED_INIT, &slot->flags);
>>                 regs = mci_readl(slot->host, PWREN);
>>                 regs |= (1 << slot->id);
>>                 mci_writel(slot->host, PWREN, regs);
>>                 break;
>>         case MMC_POWER_OFF:
>> +               if (!IS_ERR(mmc->supply.vqmmc) &&
>> +                               test_bit(DW_MMC_IO_POWERED, &slot->flags)) {
>> +                       ret = regulator_disable(mmc->supply.vqmmc);
>> +                       if (!ret)
>> +                               clear_bit(DW_MMC_IO_POWERED, &slot->flags);
>> +               }
>> +               if (!IS_ERR(mmc->supply.vmmc) &&
>> +                               test_bit(DW_MMC_CARD_POWERED, &slot->flags)) {
>> +                       ret = regulator_disable(mmc->supply.vmmc);
>> +                       if (!ret)
>> +                               clear_bit(DW_MMC_CARD_POWERED, &slot->flags);
>> +               }
>>                 regs = mci_readl(slot->host, PWREN);
>>                 regs &= ~(1 << slot->id);
>>                 mci_writel(slot->host, PWREN, regs);
>>                 break;
>> +       case MMC_POWER_ON:
>> +               if (!IS_ERR(mmc->supply.vqmmc) &&
>> +                               !test_bit(DW_MMC_IO_POWERED, &slot->flags)) {
>> +                       ret = regulator_enable(mmc->supply.vqmmc);
>> +                       if (!ret)
>> +                               set_bit(DW_MMC_IO_POWERED, &slot->flags);
>> +               }
>>         default:
>>                 break;
>>         }
>> @@ -2067,7 +2093,13 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
>>                 mmc->f_max = freq[1];
>>         }
>>
>> -       mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
>> +       /*if there are external regulators, get them*/
>> +       ret = mmc_regulator_get_supply(mmc);
>> +       if (ret == -EPROBE_DEFER)
>> +               goto err_setup_bus;
>> +
>> +       if (!mmc->ocr_avail)
>> +               mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
>>
>>         if (host->pdata->caps)
>>                 mmc->caps = host->pdata->caps;
>> @@ -2133,7 +2165,7 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
>>
>>  err_setup_bus:
>>         mmc_free_host(mmc);
>> -       return -EINVAL;
>> +       return ret;
>>  }
>>
>>  static void dw_mci_cleanup_slot(struct dw_mci_slot *slot, unsigned int id)
>> @@ -2375,24 +2407,6 @@ int dw_mci_probe(struct dw_mci *host)
>>                 }
>>         }
>>
>> -       host->vmmc = devm_regulator_get_optional(host->dev, "vmmc");
>> -       if (IS_ERR(host->vmmc)) {
>> -               ret = PTR_ERR(host->vmmc);
>> -               if (ret == -EPROBE_DEFER)
>> -                       goto err_clk_ciu;
>> -
>> -               dev_info(host->dev, "no vmmc regulator found: %d\n", ret);
>> -               host->vmmc = NULL;
>> -       } else {
>> -               ret = regulator_enable(host->vmmc);
>> -               if (ret) {
>> -                       if (ret != -EPROBE_DEFER)
>> -                               dev_err(host->dev,
>> -                                       "regulator_enable fail: %d\n", ret);
>> -                       goto err_clk_ciu;
>> -               }
>> -       }
>> -
>>         host->quirks = host->pdata->quirks;
>>
>>         spin_lock_init(&host->lock);
>> @@ -2536,8 +2550,6 @@ err_workqueue:
>>  err_dmaunmap:
>>         if (host->use_dma && host->dma_ops->exit)
>>                 host->dma_ops->exit(host);
>> -       if (host->vmmc)
>> -               regulator_disable(host->vmmc);
>>
>>  err_clk_ciu:
>>         if (!IS_ERR(host->ciu_clk))
>> @@ -2573,9 +2585,6 @@ void dw_mci_remove(struct dw_mci *host)
>>         if (host->use_dma && host->dma_ops->exit)
>>                 host->dma_ops->exit(host);
>>
>> -       if (host->vmmc)
>> -               regulator_disable(host->vmmc);
>> -
>>         if (!IS_ERR(host->ciu_clk))
>>                 clk_disable_unprepare(host->ciu_clk);
>>
>> @@ -2592,9 +2601,6 @@ EXPORT_SYMBOL(dw_mci_remove);
>>   */
>>  int dw_mci_suspend(struct dw_mci *host)
>>  {
>> -       if (host->vmmc)
>> -               regulator_disable(host->vmmc);
>> -
> 
> Just to check: have you tested suspend/resume with the various
> combinations of "keep-power-in-suspend" and "non-removable" with your
> patch.  I remember some of the logic being a bit complicated...
> 
> 
>>         return 0;
>>  }
>>  EXPORT_SYMBOL(dw_mci_suspend);
>> @@ -2603,15 +2609,6 @@ int dw_mci_resume(struct dw_mci *host)
>>  {
>>         int i, ret;
>>
>> -       if (host->vmmc) {
>> -               ret = regulator_enable(host->vmmc);
>> -               if (ret) {
>> -                       dev_err(host->dev,
>> -                               "failed to enable regulator: %d\n", ret);
>> -                       return ret;
>> -               }
>> -       }
>> -
>>         if (!dw_mci_ctrl_all_reset(host)) {
>>                 ret = -ENODEV;
>>                 return ret;
>> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
>> index 738fa24..5c95d00 100644
>> --- a/drivers/mmc/host/dw_mmc.h
>> +++ b/drivers/mmc/host/dw_mmc.h
> 
> As I mentioned in my previous review, you should be removing "struct
> regulator *vmmc; /* Power regulator */" from "struct dw_mci" since
> you're no longer populating it.
> 
> 
>> @@ -225,6 +225,8 @@ struct dw_mci_slot {
>>         unsigned long           flags;
>>  #define DW_MMC_CARD_PRESENT    0
>>  #define DW_MMC_CARD_NEED_INIT  1
>> +#define DW_MMC_CARD_POWERED    2
>> +#define DW_MMC_IO_POWERED      3
> 
> I don't really think you should have two bits here.  From my
> understanding of SD cards there should be very little reason to have
> vqmmc and vmmc not powered at the same time.
> 
> If vqmmc is powered but vmmc is not powered then you'll get leakage
> and the card can pull power through the IO lines which is bad for the
> card.
> 
> I don't think that powering vmmc without vqmmc for a short time is
> terribly bad but I can't quite see a good use case.  Essentially
> you're powering the card but not able to talk to it, right?  I'm not
> sure what the state of the IO lines would be (either driven low or
> floating) since presumably the pullups on the lines are powered by
> vqmmc too.
> 
> 
>>         int                     id;
>>         int                     last_detect_state;
>>  };
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2014-06-25  3:18 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-23 10:45 [PATCH 0/3] Adding UHS support for dw_mmc driver Yuvaraj Kumar C D
2014-06-23 10:45 ` [PATCH 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators Yuvaraj Kumar C D
2014-06-24 18:00   ` Doug Anderson
2014-06-25  3:18     ` Jaehoon Chung [this message]
2014-06-25  4:00       ` Doug Anderson
2014-06-25 11:18       ` Seungwon Jeon
2014-06-25 17:28         ` Doug Anderson
2014-06-26 10:30           ` Seungwon Jeon
2014-06-26 16:20             ` Doug Anderson
2014-06-27 11:19               ` Seungwon Jeon
2014-06-26 11:21     ` Yuvaraj Kumar
2014-06-26 16:18       ` Doug Anderson
2014-06-27 10:59         ` Yuvaraj Kumar
2014-06-27 22:47           ` Doug Anderson
2014-07-22 19:31             ` Javier Martinez Canillas
2014-06-30 12:13         ` Jaehoon Chung
2014-06-30 15:06           ` Doug Anderson
2014-07-01  4:25             ` Jaehoon Chung
2014-06-23 10:45 ` [PATCH 2/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc Yuvaraj Kumar C D
2014-06-24 18:10   ` Doug Anderson
2014-06-23 10:45 ` [PATCH 3/3] mmc: dw_mmc: Support voltage changes Yuvaraj Kumar C D
2014-06-24 18:17   ` Doug Anderson
2014-06-25 13:08   ` Seungwon Jeon
2014-06-25 17:46     ` Doug Anderson
2014-06-26 10:41       ` Seungwon Jeon
2014-06-26 16:50         ` Doug Anderson
2014-06-27  6:35           ` Yuvaraj Kumar
2014-06-27 11:18             ` Seungwon Jeon
2014-06-30 12:18               ` Jaehoon Chung
2014-07-01 11:17               ` Yuvaraj Kumar
2014-07-04 10:08                 ` Seungwon Jeon
2014-07-07  5:23                   ` Seungwon Jeon
2014-07-08  4:34                     ` Yuvaraj Kumar
2014-07-08  9:56                       ` Seungwon Jeon
2014-06-26 11:38       ` Yuvaraj Kumar

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=53AA3F78.3080804@samsung.com \
    --to=jh80.chung@samsung.com \
    --cc=alim.akhtar@samsung.com \
    --cc=cjb@laptop.org \
    --cc=dianders@chromium.org \
    --cc=joshi@samsung.com \
    --cc=kgene.kim@samsung.com \
    --cc=ks.giri@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=prashanth.g@samsung.com \
    --cc=sonnyrao@chromium.org \
    --cc=t.figa@samsung.com \
    --cc=tgih.jun@samsung.com \
    --cc=ulf.hansson@linaro.org \
    --cc=yuvaraj.cd@gmail.com \
    --cc=yuvaraj.cd@samsung.com \
    /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