linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ulf.hansson@linaro.org (Ulf Hansson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 2/3] mmc: dw_mmc: Support voltage changes
Date: Mon, 25 Aug 2014 10:31:14 +0200	[thread overview]
Message-ID: <CAPDyKFo4fEppn21ani_p_t2Z-hhafAFRVSA2nPr9fed3iS8Q_A@mail.gmail.com> (raw)
In-Reply-To: <CAD=FV=WAKXV4MuqybN4ypA+2tr1m6CP6=9_O+sYYe_-GYiy7SA@mail.gmail.com>

On 22 August 2014 22:38, Doug Anderson <dianders@google.com> wrote:
> Ulf,
>
> On Fri, Aug 22, 2014 at 8:35 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> On 22 August 2014 15:47, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote:
>>> From: Doug Anderson <dianders@chromium.org>
>>>
>>> For UHS cards we need the ability to switch voltages from 3.3V to
>>> 1.8V.  Add support to the dw_mmc driver to handle this.  Note that
>>> dw_mmc needs a little bit of extra code since the interface needs a
>>> special bit programmed to the CMD register while CMD11 is progressing.
>>> This means adding a few extra states to the state machine to track.
>>>
>>> Signed-off-by: Doug Anderson <dianders@chromium.org>
>>> Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com>
>>> ---
>>> changes since v1:
>>>         1. Added error message and return error in case of regulator_set_voltage() fail.
>>>         2. changed  dw_mci_cmd_interrupt(host,pending | SDMMC_INT_CMD_DONE)
>>>            to dw_mci_cmd_interrupt(host,pending).
>>>         3. Removed unnecessary comments.
>>>
>>>  drivers/mmc/host/dw_mmc.c  |  134 +++++++++++++++++++++++++++++++++++++++++---
>>>  drivers/mmc/host/dw_mmc.h  |    5 +-
>>>  include/linux/mmc/dw_mmc.h |    2 +
>>>  3 files changed, 131 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>> index aadb0d6..f20b4b8 100644
>>> --- a/drivers/mmc/host/dw_mmc.c
>>> +++ b/drivers/mmc/host/dw_mmc.c
>>> @@ -29,6 +29,7 @@
>>>  #include <linux/irq.h>
>>>  #include <linux/mmc/host.h>
>>>  #include <linux/mmc/mmc.h>
>>> +#include <linux/mmc/sd.h>
>>>  #include <linux/mmc/sdio.h>
>>>  #include <linux/mmc/dw_mmc.h>
>>>  #include <linux/bitops.h>
>>> @@ -234,10 +235,13 @@ err:
>>>  }
>>>  #endif /* defined(CONFIG_DEBUG_FS) */
>>>
>>> +static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg);
>>> +
>>>  static u32 dw_mci_prepare_command(struct mmc_host *mmc, struct mmc_command *cmd)
>>>  {
>>>         struct mmc_data *data;
>>>         struct dw_mci_slot *slot = mmc_priv(mmc);
>>> +       struct dw_mci *host = slot->host;
>>>         const struct dw_mci_drv_data *drv_data = slot->host->drv_data;
>>>         u32 cmdr;
>>>         cmd->error = -EINPROGRESS;
>>> @@ -253,6 +257,31 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc, struct mmc_command *cmd)
>>>         else if (cmd->opcode != MMC_SEND_STATUS && cmd->data)
>>>                 cmdr |= SDMMC_CMD_PRV_DAT_WAIT;
>>>
>>> +       if (cmd->opcode == SD_SWITCH_VOLTAGE) {
>>> +               u32 clk_en_a;
>>> +
>>> +               /* Special bit makes CMD11 not die */
>>> +               cmdr |= SDMMC_CMD_VOLT_SWITCH;
>>> +
>>> +               /* Change state to continue to handle CMD11 weirdness */
>>> +               WARN_ON(slot->host->state != STATE_SENDING_CMD);
>>> +               slot->host->state = STATE_SENDING_CMD11;
>>> +
>>> +               /*
>>> +                * We need to disable clock stop while doing voltage switch
>>> +                * according to Voltage Switch Normal Scenario.
>>> +                * It's assumed that by the next time the CLKENA is updated
>>> +                * (when we set the clock next) that the voltage change will
>>> +                * be over, so we don't bother setting any bits to synchronize
>>> +                * with dw_mci_setup_bus().
>>> +                */
>>
>> I don't know the details about the dw_mmc controller, but normally a
>> host driver is expected to gate the clock from it's ->set_ios
>> callback, when the clk frequency are set to 0.
>>
>> Could you elaborate on why dw_mmc can't do that, but need to handle
>> this from here?
>
> Let's see, it's been a while since I wrote this...
>
>
> So dw_mmc has a special feature where the controller itself will
> automatically stop the MMC Card clock when nothing is going on.  This
> is called "low power" mode.  I'm not super familiar with other MMC
> drivers, I get the impression that this is a special dw_mmc feature
> and not common to other controllers.  I think other drivers have
> aggressive runtime PM to get similar power savings.

I see.

I am familiar with such "low power" mode features, there are certainly
other controllers supporting such as well. My experience tells me,
it's hard to get things right for all corner cases. The voltage switch
behaviour is just one of these, then you have SDIO irq etc.

Instead of using the controller HW, yes you may implement clock gating
through runtime PM in the host driver.

>
> The dw_mmc auto clock gating can wreck total havoc on the voltage
> change procedure, since part of the way that the host and card
> communicate is that the host is supposed to stop its clock when it
> gets to a certain phase of the voltage switch sequence.  If the
> controller is stopping the clock for us then it can confuse the card.
>
> The dw_mmc manual says that before starting a voltage change you must
> turn off low power mode.  That's what we're doing here.
>
>
> The comment above refers to the fact dw_mci_setup_bus() will
> unconditionally turn low power mode back on for us when called with a
> non-zero clock.  If dw_mci_setup_bus() might be called with a non-zero
> clock during the voltage change then this would be disaster (low power
> mode would be back on!).  ...but the clock will always be zero during
> the voltage change and when it's finally non-zero then it's the last
> stage of the voltage change and we can go back to low power mode.
>
>
> Possibly the above was not super clear from the comment (even for
> those familiar with the oddities of dw_mmc).  If you want me to try to
> rewrite the comment, let me know.

I appreciate an updated comment, it's nice to know what goes on. :-)

Kind regards
Uffe

  reply	other threads:[~2014-08-25  8:31 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-22 13:47 [PATCH V2 0/3] Adding UHS support for dw_mmc driver Yuvaraj Kumar C D
2014-08-22 13:47 ` [PATCH V2 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators Yuvaraj Kumar C D
2014-08-25 12:32   ` Jaehoon Chung
2014-08-25 15:06     ` Doug Anderson
2014-08-29 11:34   ` Ulf Hansson
2014-09-29 12:31     ` Bartlomiej Zolnierkiewicz
2014-09-30  5:23       ` Jaehoon Chung
2014-10-01 13:57         ` Bartlomiej Zolnierkiewicz
2014-10-01 14:14           ` Bartlomiej Zolnierkiewicz
2014-09-30 17:22       ` Doug Anderson
2014-10-01 13:06         ` Bartlomiej Zolnierkiewicz
2014-10-01 15:38           ` Doug Anderson
2014-08-22 13:47 ` [PATCH V2 2/3] mmc: dw_mmc: Support voltage changes Yuvaraj Kumar C D
2014-08-22 15:35   ` Ulf Hansson
2014-08-22 20:38     ` Doug Anderson
2014-08-25  8:31       ` Ulf Hansson [this message]
2014-08-25 20:59         ` Doug Anderson
2014-08-29 11:43           ` Ulf Hansson
2014-09-29 12:49             ` Bartlomiej Zolnierkiewicz
2014-08-22 13:47 ` [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc Yuvaraj Kumar C D
2014-08-22 15:31   ` Ulf Hansson
2014-08-22 18:27     ` Sonny Rao
2014-08-25  8:13       ` Ulf Hansson
2014-08-25  8:50         ` Jaehoon Chung
2014-08-25 15:25           ` Doug Anderson
2014-08-27  3:48             ` Jaehoon Chung
2014-08-27  4:14               ` Doug Anderson
2014-08-27  4:47                 ` Jaehoon Chung
2014-08-27 15:49                   ` Doug Anderson
2014-08-28  4:54                     ` Yuvaraj Kumar
2014-08-28  8:43                     ` Jaehoon Chung
2014-08-28 15:52                       ` Doug Anderson
2014-08-25 15:20         ` Doug Anderson
2014-08-26  7:37           ` Ulf Hansson
2014-08-26 20:32             ` Doug Anderson
2014-08-27 11:17               ` Ulf Hansson
2014-08-27 11:20                 ` Ulf Hansson
2014-08-27 15:52                 ` Doug Anderson
2014-08-28  7:25                   ` Ulf Hansson
2014-08-28 15:50                     ` Doug Anderson
2014-08-28 17:50                       ` Sonny Rao
2014-08-29  4:08                         ` Doug Anderson
2014-08-27  3:55           ` Jaehoon Chung

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=CAPDyKFo4fEppn21ani_p_t2Z-hhafAFRVSA2nPr9fed3iS8Q_A@mail.gmail.com \
    --to=ulf.hansson@linaro.org \
    --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).