* [PATCH V2 0/3] Adding UHS support for dw_mmc driver
@ 2014-08-22 13:47 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
` (2 more replies)
0 siblings, 3 replies; 43+ messages in thread
From: Yuvaraj Kumar C D @ 2014-08-22 13:47 UTC (permalink / raw)
To: linux-arm-kernel
This series adds UHS support for dw_mmc driver.
Patch[1] reworks the handling of vmmc and vqmmc regulators by mmc core
regulator API's.
Patch[2] was taken from chrome tree originally developed by Doug Anderson.
Comments recieved for this patch to remove extra state machine for CMD11
handling is dropped since it's very much required to set the
SDMMC_CMD_VOLT_SWITCH bit(28) for the proper working of clock update after
the first VOLT_SWITCH interrupt occurs during the voltage switch scenario.
Though its not mentioned in Synopsys data book, its essential to complete
the voltage switchingi sequence.
Patch[3] handles the case where in some boards uses built-in CD line for
card detection and connected to a same voltage domain as of the IO rails.
This version adds the changes for the concerned expressed by Doug Anderson
in prevoius version.
Doug Anderson (1):
[2].mmc: dw_mmc: Support voltage changes
Yuvaraj Kumar C D (2):
[1]. mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
[3]. mmc: dw_mmc: Dont cut off vqmmc and vmmc
drivers/mmc/core/core.c | 16 ++-
drivers/mmc/core/debugfs.c | 3 +
drivers/mmc/host/dw_mmc-exynos.c | 12 ++
drivers/mmc/host/dw_mmc.c | 231 ++++++++++++++++++++++++++++++--------
drivers/mmc/host/dw_mmc.h | 7 +-
include/linux/mmc/dw_mmc.h | 4 +-
include/linux/mmc/host.h | 2 +
7 files changed, 225 insertions(+), 50 deletions(-)
--
1.7.10.4
^ permalink raw reply [flat|nested] 43+ messages in thread* [PATCH V2 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators 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 ` Yuvaraj Kumar C D 2014-08-25 12:32 ` Jaehoon Chung 2014-08-29 11:34 ` Ulf Hansson 2014-08-22 13:47 ` [PATCH V2 2/3] mmc: dw_mmc: Support voltage changes Yuvaraj Kumar C D 2014-08-22 13:47 ` [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc Yuvaraj Kumar C D 2 siblings, 2 replies; 43+ messages in thread From: Yuvaraj Kumar C D @ 2014-08-22 13:47 UTC (permalink / raw) To: linux-arm-kernel 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> --- changes from v1: 1.Used mmc_regulator_set_ocr() instead of regulator_enable() for vmmc. 2.Turned on vmmc and vqmmc during MMC_POWER_UP. 3. Removed the flags DW_MMC_CARD_POWERED and DW_MMC_IO_POWERED which added during the initial version of this patch. 4. Added error message, if it failed to turn on regulator's. drivers/mmc/host/dw_mmc.c | 72 +++++++++++++++++++++----------------------- include/linux/mmc/dw_mmc.h | 2 +- 2 files changed, 36 insertions(+), 38 deletions(-) diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index 7f227e9..aadb0d6 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -936,6 +936,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: @@ -974,12 +975,38 @@ 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)) { + ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, + ios->vdd); + if (ret) { + dev_err(slot->host->dev, + "failed to enable vmmc regulator\n"); + /*return, if failed turn on vmmc*/ + return; + } + } + if (!IS_ERR(mmc->supply.vqmmc) && !slot->host->vqmmc_enabled) { + ret = regulator_enable(mmc->supply.vqmmc); + if (ret < 0) + dev_err(slot->host->dev, + "failed to enable vqmmc regulator\n"); + else + slot->host->vqmmc_enabled = true; + } 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.vmmc)) + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0); + + if (!IS_ERR(mmc->supply.vqmmc) && slot->host->vqmmc_enabled) { + regulator_disable(mmc->supply.vqmmc); + slot->host->vqmmc_enabled = false; + } + regs = mci_readl(slot->host, PWREN); regs &= ~(1 << slot->id); mci_writel(slot->host, PWREN, regs); @@ -2110,7 +2137,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; @@ -2176,7 +2209,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) @@ -2469,24 +2502,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); @@ -2630,8 +2645,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)) @@ -2667,9 +2680,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); @@ -2686,9 +2696,6 @@ EXPORT_SYMBOL(dw_mci_remove); */ int dw_mci_suspend(struct dw_mci *host) { - if (host->vmmc) - regulator_disable(host->vmmc); - return 0; } EXPORT_SYMBOL(dw_mci_suspend); @@ -2697,15 +2704,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_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS)) { ret = -ENODEV; return ret; diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h index 29ce014..84e2827 100644 --- a/include/linux/mmc/dw_mmc.h +++ b/include/linux/mmc/dw_mmc.h @@ -188,7 +188,7 @@ struct dw_mci { /* Workaround flags */ u32 quirks; - struct regulator *vmmc; /* Power regulator */ + bool vqmmc_enabled; unsigned long irq_flags; /* IRQ flags */ int irq; }; -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH V2 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators 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 1 sibling, 1 reply; 43+ messages in thread From: Jaehoon Chung @ 2014-08-25 12:32 UTC (permalink / raw) To: linux-arm-kernel On 08/22/2014 10:47 PM, Yuvaraj Kumar C D 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> > --- > changes from v1: > 1.Used mmc_regulator_set_ocr() instead of regulator_enable() for vmmc. > 2.Turned on vmmc and vqmmc during MMC_POWER_UP. > 3. Removed the flags DW_MMC_CARD_POWERED and DW_MMC_IO_POWERED which > added during the initial version of this patch. > 4. Added error message, if it failed to turn on regulator's. > > drivers/mmc/host/dw_mmc.c | 72 +++++++++++++++++++++----------------------- > include/linux/mmc/dw_mmc.h | 2 +- > 2 files changed, 36 insertions(+), 38 deletions(-) > > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c > index 7f227e9..aadb0d6 100644 > --- a/drivers/mmc/host/dw_mmc.c > +++ b/drivers/mmc/host/dw_mmc.c > @@ -936,6 +936,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: > @@ -974,12 +975,38 @@ 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)) { > + ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, > + ios->vdd); > + if (ret) { > + dev_err(slot->host->dev, > + "failed to enable vmmc regulator\n"); > + /*return, if failed turn on vmmc*/ > + return; > + } > + } > + if (!IS_ERR(mmc->supply.vqmmc) && !slot->host->vqmmc_enabled) { Can't use the regulator_is_enabled() instead of "slot->host->vqmmc_enabled"? Best Regards, Jaehoon Chung > + ret = regulator_enable(mmc->supply.vqmmc); > + if (ret < 0) > + dev_err(slot->host->dev, > + "failed to enable vqmmc regulator\n"); > + else > + slot->host->vqmmc_enabled = true; > + } > 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.vmmc)) > + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0); > + > + if (!IS_ERR(mmc->supply.vqmmc) && slot->host->vqmmc_enabled) { > + regulator_disable(mmc->supply.vqmmc); > + slot->host->vqmmc_enabled = false; > + } > + > regs = mci_readl(slot->host, PWREN); > regs &= ~(1 << slot->id); > mci_writel(slot->host, PWREN, regs); > @@ -2110,7 +2137,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; > @@ -2176,7 +2209,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) > @@ -2469,24 +2502,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); > @@ -2630,8 +2645,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)) > @@ -2667,9 +2680,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); > > @@ -2686,9 +2696,6 @@ EXPORT_SYMBOL(dw_mci_remove); > */ > int dw_mci_suspend(struct dw_mci *host) > { > - if (host->vmmc) > - regulator_disable(host->vmmc); > - > return 0; > } > EXPORT_SYMBOL(dw_mci_suspend); > @@ -2697,15 +2704,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_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS)) { > ret = -ENODEV; > return ret; > diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h > index 29ce014..84e2827 100644 > --- a/include/linux/mmc/dw_mmc.h > +++ b/include/linux/mmc/dw_mmc.h > @@ -188,7 +188,7 @@ struct dw_mci { > /* Workaround flags */ > u32 quirks; > > - struct regulator *vmmc; /* Power regulator */ > + bool vqmmc_enabled; > unsigned long irq_flags; /* IRQ flags */ > int irq; > }; > ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators 2014-08-25 12:32 ` Jaehoon Chung @ 2014-08-25 15:06 ` Doug Anderson 0 siblings, 0 replies; 43+ messages in thread From: Doug Anderson @ 2014-08-25 15:06 UTC (permalink / raw) To: linux-arm-kernel Jaehoon, On Mon, Aug 25, 2014 at 5:32 AM, Jaehoon Chung <jh80.chung@samsung.com> wrote: > On 08/22/2014 10:47 PM, Yuvaraj Kumar C D 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> >> --- >> changes from v1: >> 1.Used mmc_regulator_set_ocr() instead of regulator_enable() for vmmc. >> 2.Turned on vmmc and vqmmc during MMC_POWER_UP. >> 3. Removed the flags DW_MMC_CARD_POWERED and DW_MMC_IO_POWERED which >> added during the initial version of this patch. >> 4. Added error message, if it failed to turn on regulator's. >> >> drivers/mmc/host/dw_mmc.c | 72 +++++++++++++++++++++----------------------- >> include/linux/mmc/dw_mmc.h | 2 +- >> 2 files changed, 36 insertions(+), 38 deletions(-) >> >> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c >> index 7f227e9..aadb0d6 100644 >> --- a/drivers/mmc/host/dw_mmc.c >> +++ b/drivers/mmc/host/dw_mmc.c >> @@ -936,6 +936,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: >> @@ -974,12 +975,38 @@ 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)) { >> + ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, >> + ios->vdd); >> + if (ret) { >> + dev_err(slot->host->dev, >> + "failed to enable vmmc regulator\n"); >> + /*return, if failed turn on vmmc*/ >> + return; >> + } >> + } >> + if (!IS_ERR(mmc->supply.vqmmc) && !slot->host->vqmmc_enabled) { > > Can't use the regulator_is_enabled() instead of "slot->host->vqmmc_enabled"? I think we mentioned this before, but regulator_is_enabled() won't do what you want with shared regulators since they are refcounted. You need to keep track of whether you've enabled the regulator yourself. -Doug ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators 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-29 11:34 ` Ulf Hansson 2014-09-29 12:31 ` Bartlomiej Zolnierkiewicz 1 sibling, 1 reply; 43+ messages in thread From: Ulf Hansson @ 2014-08-29 11:34 UTC (permalink / raw) To: linux-arm-kernel On 22 August 2014 15:47, 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> Thanks! Applied for next. Kind regards Uffe > --- > changes from v1: > 1.Used mmc_regulator_set_ocr() instead of regulator_enable() for vmmc. > 2.Turned on vmmc and vqmmc during MMC_POWER_UP. > 3. Removed the flags DW_MMC_CARD_POWERED and DW_MMC_IO_POWERED which > added during the initial version of this patch. > 4. Added error message, if it failed to turn on regulator's. > > drivers/mmc/host/dw_mmc.c | 72 +++++++++++++++++++++----------------------- > include/linux/mmc/dw_mmc.h | 2 +- > 2 files changed, 36 insertions(+), 38 deletions(-) > > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c > index 7f227e9..aadb0d6 100644 > --- a/drivers/mmc/host/dw_mmc.c > +++ b/drivers/mmc/host/dw_mmc.c > @@ -936,6 +936,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: > @@ -974,12 +975,38 @@ 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)) { > + ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, > + ios->vdd); > + if (ret) { > + dev_err(slot->host->dev, > + "failed to enable vmmc regulator\n"); > + /*return, if failed turn on vmmc*/ > + return; > + } > + } > + if (!IS_ERR(mmc->supply.vqmmc) && !slot->host->vqmmc_enabled) { > + ret = regulator_enable(mmc->supply.vqmmc); > + if (ret < 0) > + dev_err(slot->host->dev, > + "failed to enable vqmmc regulator\n"); > + else > + slot->host->vqmmc_enabled = true; > + } > 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.vmmc)) > + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0); > + > + if (!IS_ERR(mmc->supply.vqmmc) && slot->host->vqmmc_enabled) { > + regulator_disable(mmc->supply.vqmmc); > + slot->host->vqmmc_enabled = false; > + } > + > regs = mci_readl(slot->host, PWREN); > regs &= ~(1 << slot->id); > mci_writel(slot->host, PWREN, regs); > @@ -2110,7 +2137,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; > @@ -2176,7 +2209,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) > @@ -2469,24 +2502,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); > @@ -2630,8 +2645,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)) > @@ -2667,9 +2680,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); > > @@ -2686,9 +2696,6 @@ EXPORT_SYMBOL(dw_mci_remove); > */ > int dw_mci_suspend(struct dw_mci *host) > { > - if (host->vmmc) > - regulator_disable(host->vmmc); > - > return 0; > } > EXPORT_SYMBOL(dw_mci_suspend); > @@ -2697,15 +2704,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_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS)) { > ret = -ENODEV; > return ret; > diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h > index 29ce014..84e2827 100644 > --- a/include/linux/mmc/dw_mmc.h > +++ b/include/linux/mmc/dw_mmc.h > @@ -188,7 +188,7 @@ struct dw_mci { > /* Workaround flags */ > u32 quirks; > > - struct regulator *vmmc; /* Power regulator */ > + bool vqmmc_enabled; > unsigned long irq_flags; /* IRQ flags */ > int irq; > }; > -- > 1.7.10.4 > ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators 2014-08-29 11:34 ` Ulf Hansson @ 2014-09-29 12:31 ` Bartlomiej Zolnierkiewicz 2014-09-30 5:23 ` Jaehoon Chung 2014-09-30 17:22 ` Doug Anderson 0 siblings, 2 replies; 43+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2014-09-29 12:31 UTC (permalink / raw) To: linux-arm-kernel Hi, On Friday, August 29, 2014 01:34:44 PM Ulf Hansson wrote: > On 22 August 2014 15:47, 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> > > Thanks! Applied for next. Unfortunately this patch breaks mmc1 card (Kingston 32GB micro SDHC) detection on Exynos5420 Arndale Octa for me: [ 10.797979] dwmmc_exynos 12220000.mmc: no support for card's volts [ 10.797998] mmc1: error -22 whilst initialising SD card Without the patch: [ 10.866926] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0) [ 10.866977] mmc1: new high speed SDHC card at address 1234 [ 10.868730] mmcblk1: mmc1:1234 SA32G 29.3 GiB [ 10.915054] mmcblk1: p1 p2 p3 The config is attached (exynos_defconfig doesn't work correctly for this board yet). Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > Kind regards > Uffe > > > --- > > changes from v1: > > 1.Used mmc_regulator_set_ocr() instead of regulator_enable() for vmmc. > > 2.Turned on vmmc and vqmmc during MMC_POWER_UP. > > 3. Removed the flags DW_MMC_CARD_POWERED and DW_MMC_IO_POWERED which > > added during the initial version of this patch. > > 4. Added error message, if it failed to turn on regulator's. > > > > drivers/mmc/host/dw_mmc.c | 72 +++++++++++++++++++++----------------------- > > include/linux/mmc/dw_mmc.h | 2 +- > > 2 files changed, 36 insertions(+), 38 deletions(-) > > > > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c > > index 7f227e9..aadb0d6 100644 > > --- a/drivers/mmc/host/dw_mmc.c > > +++ b/drivers/mmc/host/dw_mmc.c > > @@ -936,6 +936,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: > > @@ -974,12 +975,38 @@ 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)) { > > + ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, > > + ios->vdd); > > + if (ret) { > > + dev_err(slot->host->dev, > > + "failed to enable vmmc regulator\n"); > > + /*return, if failed turn on vmmc*/ > > + return; > > + } > > + } > > + if (!IS_ERR(mmc->supply.vqmmc) && !slot->host->vqmmc_enabled) { > > + ret = regulator_enable(mmc->supply.vqmmc); > > + if (ret < 0) > > + dev_err(slot->host->dev, > > + "failed to enable vqmmc regulator\n"); > > + else > > + slot->host->vqmmc_enabled = true; > > + } > > 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.vmmc)) > > + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0); > > + > > + if (!IS_ERR(mmc->supply.vqmmc) && slot->host->vqmmc_enabled) { > > + regulator_disable(mmc->supply.vqmmc); > > + slot->host->vqmmc_enabled = false; > > + } > > + > > regs = mci_readl(slot->host, PWREN); > > regs &= ~(1 << slot->id); > > mci_writel(slot->host, PWREN, regs); > > @@ -2110,7 +2137,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; > > @@ -2176,7 +2209,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) > > @@ -2469,24 +2502,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); > > @@ -2630,8 +2645,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)) > > @@ -2667,9 +2680,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); > > > > @@ -2686,9 +2696,6 @@ EXPORT_SYMBOL(dw_mci_remove); > > */ > > int dw_mci_suspend(struct dw_mci *host) > > { > > - if (host->vmmc) > > - regulator_disable(host->vmmc); > > - > > return 0; > > } > > EXPORT_SYMBOL(dw_mci_suspend); > > @@ -2697,15 +2704,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_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS)) { > > ret = -ENODEV; > > return ret; > > diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h > > index 29ce014..84e2827 100644 > > --- a/include/linux/mmc/dw_mmc.h > > +++ b/include/linux/mmc/dw_mmc.h > > @@ -188,7 +188,7 @@ struct dw_mci { > > /* Workaround flags */ > > u32 quirks; > > > > - struct regulator *vmmc; /* Power regulator */ > > + bool vqmmc_enabled; > > unsigned long irq_flags; /* IRQ flags */ > > int irq; > > }; > > -- > > 1.7.10.4 -------------- next part -------------- # # Common config options automatically generated by splitconfig.pl # # CONFIG_ABX500_CORE is not set # CONFIG_ACCESSIBILITY is not set # CONFIG_ACORN_PARTITION is not set # CONFIG_AD525X_DPOT is not set # CONFIG_ADFS_FS is not set CONFIG_AEABI=y # CONFIG_AFFS_FS is not set # CONFIG_AFS_FS is not set # CONFIG_AF_RXRPC is not set CONFIG_AIO=y # CONFIG_AIX_PARTITION is not set CONFIG_ALIGNMENT_TRAP=y # CONFIG_ALTERA_STAPL is not set # CONFIG_AM335X_PHY_USB is not set # CONFIG_AMBA_PL08X is not set # CONFIG_AMD_PHY is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ANDROID_PARANOID_NETWORK is not set CONFIG_ANON_INODES=y # CONFIG_APDS9802ALS is not set # CONFIG_APM_EMULATION is not set # CONFIG_ARCH_AT91 is not set CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_DAVINCI is not set # CONFIG_ARCH_DOVE is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_EP93XX is not set CONFIG_ARCH_EXYNOS=y CONFIG_ARCH_EXYNOS4=y CONFIG_ARCH_EXYNOS5=y # CONFIG_ARCH_FOOTBRIDGE is not set # CONFIG_ARCH_GEMINI is not set CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y CONFIG_ARCH_HAS_BANDGAP=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y CONFIG_ARCH_HAS_OPP=y CONFIG_ARCH_HAS_TICK_BROADCAST=y CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_IOP13XX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set # CONFIG_ARCH_IXP4XX is not set # CONFIG_ARCH_KIRKWOOD is not set # CONFIG_ARCH_KS8695 is not set # CONFIG_ARCH_LPC32XX is not set CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y # CONFIG_ARCH_MMP is not set # CONFIG_ARCH_MSM_NODT is not set # CONFIG_ARCH_MULTIPLATFORM is not set # CONFIG_ARCH_MV78XX0 is not set # CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set # CONFIG_ARCH_NETX is not set CONFIG_ARCH_NR_GPIO=512 # CONFIG_ARCH_OMAP1 is not set # CONFIG_ARCH_ORION5X is not set # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set # CONFIG_ARCH_PXA is not set # CONFIG_ARCH_REALVIEW is not set CONFIG_ARCH_REQUIRE_GPIOLIB=y # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_S3C24XX is not set # CONFIG_ARCH_S3C64XX is not set # CONFIG_ARCH_S5P64X0 is not set # CONFIG_ARCH_S5PC100 is not set # CONFIG_ARCH_S5PV210 is not set # CONFIG_ARCH_SA1100 is not set CONFIG_ARCH_SELECT_MEMORY_MODEL=y # CONFIG_ARCH_SHMOBILE_LEGACY is not set CONFIG_ARCH_SPARSEMEM_DEFAULT=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_USE_BUILTIN_BSWAP=y CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_W90X900 is not set CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y # CONFIG_ARC_EMAC is not set CONFIG_ARM=y CONFIG_ARM_AMBA=y CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ARCH_TIMER=y CONFIG_ARM_ARCH_TIMER_EVTSTREAM=y CONFIG_ARM_ASM_UNIFIED=y # CONFIG_ARM_AT91_ETHER is not set CONFIG_ARM_ATAG_DTB_COMPAT=y # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y # CONFIG_ARM_CCI is not set CONFIG_ARM_CPU_SUSPEND=y CONFIG_ARM_CPU_TOPOLOGY=y CONFIG_ARM_DMA_IOMMU_ALIGNMENT=8 CONFIG_ARM_DMA_MEM_BUFFERABLE=y CONFIG_ARM_DMA_USE_IOMMU=y # CONFIG_ARM_ERRATA_430973 is not set # CONFIG_ARM_ERRATA_458693 is not set # CONFIG_ARM_ERRATA_460075 is not set # CONFIG_ARM_ERRATA_643719 is not set # CONFIG_ARM_ERRATA_720789 is not set # CONFIG_ARM_ERRATA_742230 is not set # CONFIG_ARM_ERRATA_742231 is not set # CONFIG_ARM_ERRATA_743622 is not set # CONFIG_ARM_ERRATA_751472 is not set # CONFIG_ARM_ERRATA_754322 is not set # CONFIG_ARM_ERRATA_754327 is not set # CONFIG_ARM_ERRATA_764369 is not set # CONFIG_ARM_ERRATA_773022 is not set # CONFIG_ARM_ERRATA_775420 is not set # CONFIG_ARM_ERRATA_798181 is not set CONFIG_ARM_EXYNOS4210_CPUFREQ=y CONFIG_ARM_EXYNOS4X12_CPUFREQ=y CONFIG_ARM_EXYNOS5250_CPUFREQ=y CONFIG_ARM_EXYNOS5440_CPUFREQ=y CONFIG_ARM_EXYNOS_CPUFREQ=y # CONFIG_ARM_EXYNOS_CPU_FREQ_BOOST_SW is not set # CONFIG_ARM_FLUSH_CONSOLE_ON_RESTART is not set CONFIG_ARM_GIC=y CONFIG_ARM_HAS_SG_CHAIN=y # CONFIG_ARM_KIRKWOOD_CPUFREQ is not set CONFIG_ARM_L1_CACHE_SHIFT=6 CONFIG_ARM_L1_CACHE_SHIFT_6=y # CONFIG_ARM_LPAE is not set CONFIG_ARM_NR_BANKS=8 CONFIG_ARM_PATCH_PHYS_VIRT=y # CONFIG_ARM_PSCI is not set # CONFIG_ARM_PTDUMP is not set # CONFIG_ARM_SCPI_MHU is not set CONFIG_ARM_THUMB=y # CONFIG_ARM_THUMBEE is not set CONFIG_ARM_UNWIND=y CONFIG_ARM_VIRT_EXT=y CONFIG_ASSOCIATIVE_ARRAY=y # CONFIG_ASYMMETRIC_KEY_TYPE is not set # CONFIG_ASYNC_TX_DMA is not set # CONFIG_AT803X_PHY is not set # CONFIG_ATA is not set CONFIG_ATAGS=y # CONFIG_ATALK is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_ATA_OVER_ETH is not set # CONFIG_ATM is not set # CONFIG_ATMEL_PWM is not set # CONFIG_ATMEL_SSC is not set # CONFIG_ATOMIC64_SELFTEST is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_GENERIC=y CONFIG_AUDIT_TREE=y CONFIG_AUDIT_WATCH=y CONFIG_AUTOFS4_FS=y CONFIG_AUTO_ZRELADDR=y # CONFIG_AUXDISPLAY is not set # CONFIG_AVERAGE is not set CONFIG_AX88796=y CONFIG_AX88796_93CX6=y # CONFIG_B44 is not set # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # CONFIG_BACKTRACE_SELF_TEST is not set CONFIG_BASE_FULL=y CONFIG_BASE_SMALL=0 # CONFIG_BATMAN_ADV is not set # CONFIG_BCACHE is not set # CONFIG_BCM87XX_PHY is not set # CONFIG_BCMA is not set CONFIG_BCMA_POSSIBLE=y # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_BIG_KEYS is not set # CONFIG_BIG_LITTLE is not set CONFIG_BINARY_PRINTF=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_BINFMT_SCRIPT=y CONFIG_BITREVERSE=y # CONFIG_BLK_CGROUP is not set # CONFIG_BLK_CMDLINE_PARSER is not set CONFIG_BLK_DEV=y CONFIG_BLK_DEV_BSG=y # CONFIG_BLK_DEV_BSGLIB is not set # CONFIG_BLK_DEV_COW_COMMON is not set # CONFIG_BLK_DEV_CRYPTOLOOP is not set CONFIG_BLK_DEV_DM=y CONFIG_BLK_DEV_DM_BUILTIN=y # CONFIG_BLK_DEV_DRBD is not set CONFIG_BLK_DEV_INITRD=y # CONFIG_BLK_DEV_INTEGRITY is not set # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 # CONFIG_BLK_DEV_MD is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_NULL_BLK is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=65536 # CONFIG_BLK_DEV_RBD is not set # CONFIG_BLK_DEV_SD is not set # CONFIG_BLK_DEV_SR is not set # CONFIG_BLK_DEV_XIP is not set CONFIG_BLOCK=y # CONFIG_BMP085_I2C is not set # CONFIG_BONDING is not set # CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0 # CONFIG_BOOT_PRINTK_DELAY is not set CONFIG_BOUNCE=y # CONFIG_BPF_JIT is not set CONFIG_BQL=y CONFIG_BRANCH_PROFILE_NONE=y CONFIG_BRIDGE=m # CONFIG_BRIDGE_EBT_802_3 is not set # CONFIG_BRIDGE_EBT_AMONG is not set # CONFIG_BRIDGE_EBT_ARP is not set # CONFIG_BRIDGE_EBT_ARPREPLY is not set # CONFIG_BRIDGE_EBT_BROUTE is not set # CONFIG_BRIDGE_EBT_DNAT is not set # CONFIG_BRIDGE_EBT_IP is not set # CONFIG_BRIDGE_EBT_IP6 is not set # CONFIG_BRIDGE_EBT_LIMIT is not set # CONFIG_BRIDGE_EBT_LOG is not set # CONFIG_BRIDGE_EBT_MARK is not set CONFIG_BRIDGE_EBT_MARK_T=m # CONFIG_BRIDGE_EBT_NFLOG is not set # CONFIG_BRIDGE_EBT_PKTTYPE is not set # CONFIG_BRIDGE_EBT_REDIRECT is not set # CONFIG_BRIDGE_EBT_SNAT is not set # CONFIG_BRIDGE_EBT_STP is not set CONFIG_BRIDGE_EBT_T_FILTER=m CONFIG_BRIDGE_EBT_T_NAT=m # CONFIG_BRIDGE_EBT_ULOG is not set # CONFIG_BRIDGE_EBT_VLAN is not set CONFIG_BRIDGE_IGMP_SNOOPING=y CONFIG_BRIDGE_NETFILTER=y CONFIG_BRIDGE_NF_EBTABLES=m # CONFIG_BROADCOM_PHY is not set # CONFIG_BSD_DISKLABEL is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_BT is not set # CONFIG_BTRFS_ASSERT is not set # CONFIG_BTRFS_DEBUG is not set CONFIG_BTRFS_FS=y # CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set # CONFIG_BTRFS_FS_POSIX_ACL is not set # CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set CONFIG_BUG=y CONFIG_BUILDTIME_EXTABLE_SORT=y # CONFIG_BUILD_ARM_APPENDED_DTB_IMAGE is not set # CONFIG_C2PORT is not set CONFIG_CACHE_L2X0=y CONFIG_CACHE_PL310=y # CONFIG_CAIF is not set # CONFIG_CAN is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_CC_STACKPROTECTOR=y # CONFIG_CC_STACKPROTECTOR_NONE is not set CONFIG_CC_STACKPROTECTOR_REGULAR=y # CONFIG_CC_STACKPROTECTOR_STRONG is not set # CONFIG_CDROM_PKTCDVD is not set # CONFIG_CEPH_FS is not set # CONFIG_CEPH_LIB is not set # CONFIG_CFG80211 is not set CONFIG_CGROUPS=y # CONFIG_CGROUP_CPUACCT is not set # CONFIG_CGROUP_DEBUG is not set # CONFIG_CGROUP_DEVICE is not set # CONFIG_CGROUP_FREEZER is not set # CONFIG_CGROUP_NET_CLASSID is not set # CONFIG_CGROUP_NET_PRIO is not set # CONFIG_CGROUP_PERF is not set # CONFIG_CGROUP_SCHED is not set # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_CHR_DEV_SCH is not set # CONFIG_CHR_DEV_SG is not set # CONFIG_CHR_DEV_ST is not set # CONFIG_CICADA_PHY is not set # CONFIG_CIFS is not set # CONFIG_CLEANCACHE is not set CONFIG_CLKDEV_LOOKUP=y CONFIG_CLKSRC_EXYNOS_MCT=y CONFIG_CLKSRC_OF=y CONFIG_CLKSRC_SAMSUNG_PWM=y CONFIG_CLONE_BACKWARDS=y CONFIG_CMA=y CONFIG_CMA_ALIGNMENT=8 CONFIG_CMA_AREAS=7 # CONFIG_CMA_DEBUG is not set CONFIG_CMA_SIZE_MBYTES=128 # CONFIG_CMA_SIZE_SEL_MAX is not set CONFIG_CMA_SIZE_SEL_MBYTES=y # CONFIG_CMA_SIZE_SEL_MIN is not set # CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set CONFIG_CMDLINE="root=/dev/ram0 rw ramdisk=8192 initrd=0x41000000,8M console=ttySAC3,115200 init=/linuxrc mem=256M" # CONFIG_CMDLINE_EXTEND is not set # CONFIG_CMDLINE_FORCE is not set CONFIG_CMDLINE_FROM_BOOTLOADER=y # CONFIG_CMDLINE_PARTITION is not set # CONFIG_CODA_FS is not set CONFIG_COMMON_CLK=y # CONFIG_COMMON_CLK_QCOM is not set # CONFIG_COMMON_CLK_S2MPS11 is not set # CONFIG_COMMON_CLK_SI5351 is not set # CONFIG_COMMON_CLK_SI570 is not set CONFIG_COMPACTION=y # CONFIG_COMPAT_BRK is not set # CONFIG_COMPILE_TEST is not set # CONFIG_CONFIGFS_FS is not set CONFIG_CONNECTOR=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_CONTEXT_SWITCH_TRACER=y # CONFIG_CORDIC is not set CONFIG_COREDUMP=y CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y # CONFIG_CPUSETS is not set CONFIG_CPU_32v6K=y CONFIG_CPU_32v7=y CONFIG_CPU_ABRT_EV7=y # CONFIG_CPU_BIG_ENDIAN is not set # CONFIG_CPU_BPREDICT_DISABLE is not set CONFIG_CPU_CACHE_V7=y CONFIG_CPU_CACHE_VIPT=y CONFIG_CPU_COPY_V6=y CONFIG_CPU_CP15=y CONFIG_CPU_CP15_MMU=y # CONFIG_CPU_DCACHE_DISABLE is not set CONFIG_CPU_EXYNOS4210=y CONFIG_CPU_FREQ=y # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_INTERACTIVE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_COMMON=y # CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set # CONFIG_CPU_FREQ_GOV_INTERACTIVE is not set CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_GOV_USERSPACE is not set CONFIG_CPU_FREQ_STAT=y # CONFIG_CPU_FREQ_STAT_DETAILS is not set CONFIG_CPU_HAS_ASID=y # CONFIG_CPU_ICACHE_DISABLE is not set CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y # CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is not set CONFIG_CPU_PABRT_V7=y CONFIG_CPU_PM=y CONFIG_CPU_RMAP=y CONFIG_CPU_THERMAL=y CONFIG_CPU_TLB_V7=y CONFIG_CPU_V7=y CONFIG_CRAMFS=y # CONFIG_CRASH_DUMP is not set CONFIG_CRC16=y CONFIG_CRC32=y # CONFIG_CRC32_BIT is not set # CONFIG_CRC32_SARWATE is not set # CONFIG_CRC32_SELFTEST is not set # CONFIG_CRC32_SLICEBY4 is not set CONFIG_CRC32_SLICEBY8=y CONFIG_CRC7=y # CONFIG_CRC8 is not set CONFIG_CRC_CCITT=y CONFIG_CRC_ITU_T=y CONFIG_CRC_T10DIF=y CONFIG_CROSS_COMPILE="" CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_CRYPTO=y CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_AES=y # CONFIG_CRYPTO_AES_ARM is not set CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_ANSI_CPRNG=m # CONFIG_CRYPTO_ANUBIS is not set # CONFIG_CRYPTO_ARC4 is not set # CONFIG_CRYPTO_AUTHENC is not set CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_BLKCIPHER2=y # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_CAMELLIA is not set # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set CONFIG_CRYPTO_CBC=y # CONFIG_CRYPTO_CCM is not set # CONFIG_CRYPTO_CMAC is not set # CONFIG_CRYPTO_CRC32 is not set CONFIG_CRYPTO_CRC32C=y CONFIG_CRYPTO_CRCT10DIF=y # CONFIG_CRYPTO_CRYPTD is not set # CONFIG_CRYPTO_CTR is not set # CONFIG_CRYPTO_CTS is not set # CONFIG_CRYPTO_DEFLATE is not set # CONFIG_CRYPTO_DES is not set CONFIG_CRYPTO_ECB=y # CONFIG_CRYPTO_FCRYPT is not set # CONFIG_CRYPTO_GCM is not set # CONFIG_CRYPTO_GF128MUL is not set # CONFIG_CRYPTO_GHASH is not set CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y # CONFIG_CRYPTO_HMAC is not set CONFIG_CRYPTO_HW=y # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_LRW is not set # CONFIG_CRYPTO_LZ4 is not set # CONFIG_CRYPTO_LZ4HC is not set # CONFIG_CRYPTO_LZO is not set CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_MICHAEL_MIC=y # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_PCBC is not set CONFIG_CRYPTO_PCOMP2=y # CONFIG_CRYPTO_PCRYPT is not set # CONFIG_CRYPTO_RMD128 is not set # CONFIG_CRYPTO_RMD160 is not set # CONFIG_CRYPTO_RMD256 is not set # CONFIG_CRYPTO_RMD320 is not set CONFIG_CRYPTO_RNG=m CONFIG_CRYPTO_RNG2=y # CONFIG_CRYPTO_SALSA20 is not set # CONFIG_CRYPTO_SEED is not set # CONFIG_CRYPTO_SEQIV is not set # CONFIG_CRYPTO_SERPENT is not set CONFIG_CRYPTO_SHA1=y # CONFIG_CRYPTO_SHA1_ARM is not set # CONFIG_CRYPTO_SHA256 is not set # CONFIG_CRYPTO_SHA512 is not set # CONFIG_CRYPTO_TEA is not set # CONFIG_CRYPTO_TEST is not set # CONFIG_CRYPTO_TGR192 is not set # CONFIG_CRYPTO_TWOFISH is not set # CONFIG_CRYPTO_USER is not set # CONFIG_CRYPTO_USER_API_HASH is not set # CONFIG_CRYPTO_USER_API_SKCIPHER is not set # CONFIG_CRYPTO_VMAC is not set CONFIG_CRYPTO_WORKQUEUE=y # CONFIG_CRYPTO_WP512 is not set # CONFIG_CRYPTO_XCBC is not set # CONFIG_CRYPTO_XTS is not set # CONFIG_CRYPTO_ZLIB is not set # CONFIG_CS89x0 is not set # CONFIG_DAVICOM_PHY is not set CONFIG_DCACHE_WORD_ACCESS=y # CONFIG_DCB is not set # CONFIG_DCC_TTY is not set # CONFIG_DDR is not set # CONFIG_DEBUG_ATOMIC_SLEEP is not set # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_CREDENTIALS is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set CONFIG_DEBUG_FS=y # CONFIG_DEBUG_GPIO is not set # CONFIG_DEBUG_HIGHMEM is not set # CONFIG_DEBUG_INFO is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_KMEMLEAK is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_LIST is not set # CONFIG_DEBUG_LL is not set CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S" # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_DEBUG_MEMORY_INIT is not set CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_NOTIFIERS is not set # CONFIG_DEBUG_OBJECTS is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_DEBUG_PERF_USE_VMALLOC is not set # CONFIG_DEBUG_PER_CPU_MAPS is not set # CONFIG_DEBUG_PINCTRL is not set CONFIG_DEBUG_PI_LIST=y CONFIG_DEBUG_RT_MUTEXES=y # CONFIG_DEBUG_SECTION_MISMATCH is not set # CONFIG_DEBUG_SET_MODULE_RONX is not set # CONFIG_DEBUG_SG is not set # CONFIG_DEBUG_SHIRQ is not set # CONFIG_DEBUG_SLAB is not set CONFIG_DEBUG_SPINLOCK=y # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_UART_8250 is not set # CONFIG_DEBUG_UART_PL01X is not set CONFIG_DEBUG_USER=y # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_WRITECOUNT is not set # CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set # CONFIG_DECNET is not set CONFIG_DECOMPRESS_GZIP=y CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120 CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4 CONFIG_DEFAULT_MMAP_MIN_ADDR=32768 # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_SECURITY="apparmor" CONFIG_DEFAULT_SECURITY_APPARMOR=y # CONFIG_DEFAULT_SECURITY_DAC is not set # CONFIG_DEFAULT_SECURITY_SELINUX is not set # CONFIG_DEFAULT_SECURITY_SMACK is not set CONFIG_DEFAULT_TCP_CONG="cubic" CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # CONFIG_DEPRECATED_PARAM_STRUCT is not set CONFIG_DETECT_HUNG_TASK=y # CONFIG_DEVKMEM is not set CONFIG_DEVMEM=y # CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y # CONFIG_DM9000 is not set CONFIG_DMADEVICES=y # CONFIG_DMADEVICES_DEBUG is not set # CONFIG_DMATEST is not set # CONFIG_DMA_API_DEBUG is not set CONFIG_DMA_CMA=y CONFIG_DMA_ENGINE=y CONFIG_DMA_OF=y CONFIG_DMA_SHARED_BUFFER=y # CONFIG_DM_CACHE is not set # CONFIG_DM_CRYPT is not set # CONFIG_DM_DEBUG is not set # CONFIG_DM_DELAY is not set # CONFIG_DM_FLAKEY is not set # CONFIG_DM_MIRROR is not set # CONFIG_DM_MULTIPATH is not set # CONFIG_DM_RAID is not set # CONFIG_DM_SNAPSHOT is not set # CONFIG_DM_SWITCH is not set # CONFIG_DM_THIN_PROVISIONING is not set # CONFIG_DM_UEVENT is not set # CONFIG_DM_VERITY is not set # CONFIG_DM_ZERO is not set # CONFIG_DNET is not set CONFIG_DNOTIFY=y CONFIG_DNS_RESOLVER=y CONFIG_DQL=y CONFIG_DRM=y # CONFIG_DRM_ARMADA is not set CONFIG_DRM_EXYNOS=y CONFIG_DRM_EXYNOS_DMABUF=y # CONFIG_DRM_EXYNOS_FIMD is not set # CONFIG_DRM_EXYNOS_G2D is not set CONFIG_DRM_EXYNOS_HDMI=y CONFIG_DRM_EXYNOS_IOMMU=y # CONFIG_DRM_EXYNOS_IPP is not set # CONFIG_DRM_EXYNOS_VIDI is not set # CONFIG_DRM_I2C_CH7006 is not set # CONFIG_DRM_I2C_NXP_TDA998X is not set # CONFIG_DRM_I2C_SIL164 is not set CONFIG_DRM_KMS_FB_HELPER=y CONFIG_DRM_KMS_HELPER=y # CONFIG_DRM_RCAR_DU is not set # CONFIG_DRM_SHMOBILE is not set # CONFIG_DRM_TILCDC is not set # CONFIG_DRM_UDL is not set # CONFIG_DS1682 is not set CONFIG_DTC=y # CONFIG_DUMMY is not set CONFIG_DUMMY_CONSOLE=y # CONFIG_DUMMY_IRQ is not set # CONFIG_DW_DMAC is not set # CONFIG_DW_DMAC_CORE is not set # CONFIG_DYNAMIC_DEBUG is not set CONFIG_DYNAMIC_FTRACE=y CONFIG_ECRYPT_FS=y # CONFIG_ECRYPT_FS_MESSAGING is not set # CONFIG_EDAC is not set CONFIG_EEPROM_93CX6=y # CONFIG_EEPROM_AT24 is not set # CONFIG_EEPROM_LEGACY is not set # CONFIG_EEPROM_MAX6875 is not set CONFIG_EFI_PARTITION=y # CONFIG_EFS_FS is not set CONFIG_ELF_CORE=y CONFIG_EMBEDDED=y CONFIG_ENABLE_MUST_CHECK=y CONFIG_ENABLE_WARN_DEPRECATED=y # CONFIG_ENCLOSURE_SERVICES is not set # CONFIG_ENCRYPTED_KEYS is not set CONFIG_EPOLL=y # CONFIG_EQUALIZER is not set CONFIG_ETHERNET=y # CONFIG_ETHOC is not set CONFIG_EVENTFD=y CONFIG_EVENT_TRACING=y # CONFIG_EVM is not set CONFIG_EXPERT=y CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set # CONFIG_EXT2_FS_XIP is not set CONFIG_EXT3_DEFAULTS_TO_ORDERED=y CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_POSIX_ACL is not set # CONFIG_EXT3_FS_SECURITY is not set CONFIG_EXT3_FS_XATTR=y # CONFIG_EXT4_DEBUG is not set CONFIG_EXT4_FS=y # CONFIG_EXT4_FS_POSIX_ACL is not set # CONFIG_EXT4_FS_SECURITY is not set CONFIG_EXTCON=y # CONFIG_EXTCON_GPIO is not set CONFIG_EXYNOS_IOMMU=y CONFIG_EXYNOS_IOMMU_DEBUG=y CONFIG_EXYNOS_THERMAL=y CONFIG_EXYNOS_THERMAL_CORE=y # CONFIG_EXYNOS_VIDEO is not set # CONFIG_F2FS_FS is not set # CONFIG_FANOTIFY is not set CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_FAT_FS=y # CONFIG_FAULT_INJECTION is not set CONFIG_FB=y # CONFIG_FB_ARMCLCD is not set # CONFIG_FB_ARMHDLCD is not set # CONFIG_FB_AUO_K190X is not set # CONFIG_FB_BACKLIGHT is not set # CONFIG_FB_BOOT_VESA_SUPPORT is not set # CONFIG_FB_BROADSHEET is not set CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set # CONFIG_FB_DDC is not set # CONFIG_FB_FOREIGN_ENDIAN is not set # CONFIG_FB_GOLDFISH is not set # CONFIG_FB_MACMODES is not set # CONFIG_FB_METRONOME is not set # CONFIG_FB_MODE_HELPERS is not set # CONFIG_FB_OPENCORES is not set # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_S3C is not set # CONFIG_FB_SIMPLE is not set # CONFIG_FB_SMSCUFX is not set # CONFIG_FB_SSD1307 is not set # CONFIG_FB_SVGALIB is not set # CONFIG_FB_SYS_COPYAREA is not set # CONFIG_FB_SYS_FILLRECT is not set # CONFIG_FB_SYS_FOPS is not set # CONFIG_FB_SYS_IMAGEBLIT is not set # CONFIG_FB_TILEBLITTING is not set # CONFIG_FB_TMIO is not set # CONFIG_FB_UDL is not set # CONFIG_FB_UVESA is not set # CONFIG_FB_VIRTUAL is not set # CONFIG_FHANDLE is not set CONFIG_FILE_LOCKING=y # CONFIG_FIQ_DEBUGGER is not set # CONFIG_FIRMWARE_EDID is not set CONFIG_FIRMWARE_IN_KERNEL=y # CONFIG_FIXED_PHY is not set # CONFIG_FMC is not set # CONFIG_FONTS is not set CONFIG_FONT_8x16=y CONFIG_FONT_8x8=y CONFIG_FONT_SUPPORT=y CONFIG_FORCE_MAX_ZONEORDER=11 CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set CONFIG_FRAME_WARN=1024 CONFIG_FREEZER=y # CONFIG_FRONTSWAP is not set # CONFIG_FSCACHE is not set CONFIG_FSNOTIFY=y CONFIG_FS_MBCACHE=y CONFIG_FS_POSIX_ACL=y # CONFIG_FTGMAC100 is not set # CONFIG_FTL is not set # CONFIG_FTMAC100 is not set CONFIG_FTRACE=y CONFIG_FTRACE_MCOUNT_RECORD=y # CONFIG_FTRACE_STARTUP_TEST is not set # CONFIG_FTRACE_SYSCALLS is not set # CONFIG_FUNCTION_PROFILER is not set CONFIG_FUNCTION_TRACER=y # CONFIG_FUSE_FS is not set CONFIG_FUTEX=y CONFIG_FW_LOADER=y CONFIG_FW_LOADER_USER_HELPER=y # CONFIG_GAMEPORT is not set CONFIG_GATOR=m # CONFIG_GCOV_KERNEL is not set CONFIG_GENERIC_BUG=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_GENERIC_CPUFREQ_CPU0 is not set # CONFIG_GENERIC_CPU_DEVICES is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_IDLE_POLL_SETUP=y CONFIG_GENERIC_IO=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_NET_UTILS=y CONFIG_GENERIC_PCI_IOMAP=y # CONFIG_GENERIC_PHY is not set CONFIG_GENERIC_SCHED_CLOCK=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_GENERIC_STRNCPY_FROM_USER=y CONFIG_GENERIC_STRNLEN_USER=y CONFIG_GENERIC_TRACER=y # CONFIG_GFS2_FS is not set CONFIG_GIC_NON_BANKED=y CONFIG_GPIOLIB=y # CONFIG_GPIO_ADNP is not set # CONFIG_GPIO_ADP5588 is not set # CONFIG_GPIO_BCM_KONA is not set CONFIG_GPIO_DEVRES=y # CONFIG_GPIO_EM is not set # CONFIG_GPIO_GENERIC_PLATFORM is not set # CONFIG_GPIO_GRGPIO is not set # CONFIG_GPIO_MAX7300 is not set # CONFIG_GPIO_MAX732X is not set # CONFIG_GPIO_MCP23S08 is not set # CONFIG_GPIO_PCA953X is not set # CONFIG_GPIO_PCF857X is not set # CONFIG_GPIO_PL061 is not set # CONFIG_GPIO_RCAR is not set # CONFIG_GPIO_SCH311X is not set # CONFIG_GPIO_SX150X is not set # CONFIG_GPIO_SYSFS is not set # CONFIG_GPIO_TS5500 is not set # CONFIG_HAMRADIO is not set CONFIG_HARDIRQS_SW_RESEND=y CONFIG_HAS_DMA=y CONFIG_HAS_IOMEM=y CONFIG_HAS_WAKELOCK=y # CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set # CONFIG_HAVE_AOUT is not set CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_HAVE_ARCH_KGDB=y CONFIG_HAVE_ARCH_PFN_VALID=y CONFIG_HAVE_ARCH_SECCOMP_FILTER=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_ARM_ARCH_TIMER=y CONFIG_HAVE_ARM_SCU=y # CONFIG_HAVE_BOOTMEM_INFO_NODE is not set CONFIG_HAVE_BPF_JIT=y CONFIG_HAVE_CC_STACKPROTECTOR=y CONFIG_HAVE_CLK=y CONFIG_HAVE_CLK_PREPARE=y CONFIG_HAVE_CONTEXT_TRACKING=y CONFIG_HAVE_C_RECORDMCOUNT=y CONFIG_HAVE_DEBUG_KMEMLEAK=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_HAVE_DMA_CONTIGUOUS=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_HAVE_HW_BREAKPOINT=y CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_MEMBLOCK=y CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_HAVE_MOD_ARCH_SPECIFIC=y CONFIG_HAVE_NET_DSA=y CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_PERF_EVENTS=y CONFIG_HAVE_PERF_REGS=y CONFIG_HAVE_PERF_USER_STACK_DUMP=y CONFIG_HAVE_PROC_CPU=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_S3C2410_I2C=y CONFIG_HAVE_S3C_RTC=y CONFIG_HAVE_SMP=y CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_HAVE_UID16=y CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y CONFIG_HDMI=y # CONFIG_HEADERS_CHECK is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_HFS_FS is not set CONFIG_HID=y # CONFIG_HIDRAW is not set # CONFIG_HID_A4TECH is not set # CONFIG_HID_ACRUX is not set # CONFIG_HID_APPLE is not set # CONFIG_HID_APPLEIR is not set # CONFIG_HID_AUREAL is not set # CONFIG_HID_BELKIN is not set # CONFIG_HID_CHERRY is not set # CONFIG_HID_CHICONY is not set # CONFIG_HID_CYPRESS is not set # CONFIG_HID_DRAGONRISE is not set # CONFIG_HID_ELECOM is not set # CONFIG_HID_ELO is not set # CONFIG_HID_EMS_FF is not set # CONFIG_HID_EZKEY is not set CONFIG_HID_GENERIC=y # CONFIG_HID_GREENASIA is not set # CONFIG_HID_GYRATION is not set # CONFIG_HID_HOLTEK is not set # CONFIG_HID_HUION is not set # CONFIG_HID_ICADE is not set # CONFIG_HID_KENSINGTON is not set # CONFIG_HID_KEYTOUCH is not set # CONFIG_HID_KYE is not set # CONFIG_HID_LCPOWER is not set # CONFIG_HID_LENOVO_TPKBD is not set # CONFIG_HID_LOGITECH is not set # CONFIG_HID_MAGICMOUSE is not set # CONFIG_HID_MICROSOFT is not set # CONFIG_HID_MONTEREY is not set # CONFIG_HID_MULTITOUCH is not set # CONFIG_HID_NTRIG is not set # CONFIG_HID_ORTEK is not set # CONFIG_HID_PANTHERLORD is not set # CONFIG_HID_PETALYNX is not set # CONFIG_HID_PICOLCD is not set # CONFIG_HID_PID is not set # CONFIG_HID_PRIMAX is not set # CONFIG_HID_PRODIKEYS is not set # CONFIG_HID_ROCCAT is not set # CONFIG_HID_SAITEK is not set # CONFIG_HID_SAMSUNG is not set # CONFIG_HID_SENSOR_HUB is not set # CONFIG_HID_SMARTJOYPLUS is not set # CONFIG_HID_SPEEDLINK is not set # CONFIG_HID_STEELSERIES is not set # CONFIG_HID_SUNPLUS is not set # CONFIG_HID_THRUSTMASTER is not set # CONFIG_HID_TIVO is not set # CONFIG_HID_TOPSEED is not set # CONFIG_HID_TWINHAN is not set # CONFIG_HID_UCLOGIC is not set # CONFIG_HID_WALTOP is not set # CONFIG_HID_XINMO is not set # CONFIG_HID_ZEROPLUS is not set # CONFIG_HID_ZYDACRON is not set CONFIG_HIGHMEM=y # CONFIG_HIGHPTE is not set CONFIG_HIGH_RES_TIMERS=y # CONFIG_HMC6352 is not set # CONFIG_HOSTAP is not set CONFIG_HOTPLUG_CPU=y # CONFIG_HPFS_FS is not set # CONFIG_HSI is not set # CONFIG_HSR is not set # CONFIG_HTC_EGPIO is not set # CONFIG_HTC_I2CPLD is not set # CONFIG_HTC_PASIC3 is not set # CONFIG_HUGETLB_PAGE is not set # CONFIG_HVC_DCC is not set CONFIG_HWMON=y # CONFIG_HWMON_DEBUG_CHIP is not set # CONFIG_HWMON_VID is not set CONFIG_HW_CONSOLE=y CONFIG_HW_PERF_EVENTS=y CONFIG_HW_RANDOM=y # CONFIG_HW_RANDOM_ATMEL is not set # CONFIG_HW_RANDOM_EXYNOS is not set # CONFIG_HW_RANDOM_TIMERIOMEM is not set CONFIG_HZ=200 CONFIG_HZ_FIXED=200 # CONFIG_HZ_PERIODIC is not set CONFIG_I2C=y CONFIG_I2C_ALGOBIT=y CONFIG_I2C_BOARDINFO=y # CONFIG_I2C_CBUS_GPIO is not set # CONFIG_I2C_CHARDEV is not set CONFIG_I2C_COMPAT=y # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DESIGNWARE_PLATFORM is not set # CONFIG_I2C_DIOLAN_U2C is not set CONFIG_I2C_EXYNOS5=y # CONFIG_I2C_GPIO is not set CONFIG_I2C_HELPER_AUTO=y # CONFIG_I2C_HID is not set # CONFIG_I2C_MUX is not set # CONFIG_I2C_NOMADIK is not set # CONFIG_I2C_OCORES is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PCA_PLATFORM is not set # CONFIG_I2C_PXA_PCI is not set # CONFIG_I2C_ROBOTFUZZ_OSIF is not set CONFIG_I2C_S3C2410=y # CONFIG_I2C_SIMTEC is not set # CONFIG_I2C_STUB is not set # CONFIG_I2C_TAOS_EVM is not set # CONFIG_I2C_TINY_USB is not set # CONFIG_I2C_XILINX is not set # CONFIG_ICPLUS_PHY is not set # CONFIG_ICS932S401 is not set # CONFIG_IEEE802154 is not set # CONFIG_IIO is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_IMA is not set CONFIG_INET=y # CONFIG_INET6_AH is not set # CONFIG_INET6_ESP is not set # CONFIG_INET6_IPCOMP is not set # CONFIG_INET6_TUNNEL is not set CONFIG_INET6_XFRM_MODE_BEET=y # CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set CONFIG_INET6_XFRM_MODE_TRANSPORT=y CONFIG_INET6_XFRM_MODE_TUNNEL=y # CONFIG_INET6_XFRM_TUNNEL is not set # CONFIG_INET_AH is not set CONFIG_INET_DIAG=y # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # CONFIG_INET_LRO is not set CONFIG_INET_TCP_DIAG=y CONFIG_INET_TUNNEL=y # CONFIG_INET_UDP_DIAG is not set CONFIG_INET_XFRM_MODE_BEET=y CONFIG_INET_XFRM_MODE_TRANSPORT=y CONFIG_INET_XFRM_MODE_TUNNEL=y # CONFIG_INET_XFRM_TUNNEL is not set # CONFIG_INFTL is not set CONFIG_INITRAMFS_SOURCE="" CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_INOTIFY_USER=y CONFIG_INPUT=y # CONFIG_INPUT_AD714X is not set # CONFIG_INPUT_ADXL34X is not set # CONFIG_INPUT_ATI_REMOTE2 is not set # CONFIG_INPUT_BMA150 is not set # CONFIG_INPUT_CM109 is not set # CONFIG_INPUT_CMA3000 is not set # CONFIG_INPUT_EVBUG is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_FF_MEMLESS is not set # CONFIG_INPUT_GP2A is not set # CONFIG_INPUT_GPIO is not set # CONFIG_INPUT_GPIO_BEEPER is not set # CONFIG_INPUT_GPIO_ROTARY_ENCODER is not set # CONFIG_INPUT_GPIO_TILT_POLLED is not set # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_JOYSTICK is not set CONFIG_INPUT_KEYBOARD=y # CONFIG_INPUT_KEYCHORD is not set # CONFIG_INPUT_KEYRESET is not set # CONFIG_INPUT_KEYSPAN_REMOTE is not set # CONFIG_INPUT_KXTJ9 is not set CONFIG_INPUT_MATRIXKMAP=y CONFIG_INPUT_MISC=y # CONFIG_INPUT_MMA8450 is not set CONFIG_INPUT_MOUSE=y CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_MPU3050 is not set # CONFIG_INPUT_PCF8574 is not set # CONFIG_INPUT_POLLDEV is not set # CONFIG_INPUT_POWERMATE is not set # CONFIG_INPUT_SPARSEKMAP is not set # CONFIG_INPUT_TABLET is not set CONFIG_INPUT_TOUCHSCREEN=y CONFIG_INPUT_UINPUT=y # CONFIG_INPUT_YEALINK is not set # CONFIG_INTERVAL_TREE_TEST is not set CONFIG_IOMMU_API=y CONFIG_IOMMU_HELPER=y CONFIG_IOMMU_SUPPORT=y CONFIG_IOSCHED_CFQ=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_NOOP=y CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MANGLE=m # CONFIG_IP6_NF_MATCH_AH is not set # CONFIG_IP6_NF_MATCH_EUI64 is not set # CONFIG_IP6_NF_MATCH_FRAG is not set # CONFIG_IP6_NF_MATCH_HL is not set # CONFIG_IP6_NF_MATCH_IPV6HEADER is not set # CONFIG_IP6_NF_MATCH_MH is not set # CONFIG_IP6_NF_MATCH_OPTS is not set # CONFIG_IP6_NF_MATCH_RPFILTER is not set # CONFIG_IP6_NF_MATCH_RT is not set # CONFIG_IP6_NF_RAW is not set # CONFIG_IP6_NF_SECURITY is not set # CONFIG_IP6_NF_TARGET_HL is not set CONFIG_IP6_NF_TARGET_MASQUERADE=m # CONFIG_IP6_NF_TARGET_NPT is not set CONFIG_IP6_NF_TARGET_REJECT=m # CONFIG_IP6_NF_TARGET_SYNPROXY is not set # CONFIG_IPACK_BUS is not set # CONFIG_IPMI_HANDLER is not set CONFIG_IPV6=y # CONFIG_IPV6_GRE is not set # CONFIG_IPV6_MIP6 is not set # CONFIG_IPV6_MROUTE is not set # CONFIG_IPV6_MULTIPLE_TABLES is not set CONFIG_IPV6_NDISC_NODETYPE=y # CONFIG_IPV6_OPTIMISTIC_DAD is not set # CONFIG_IPV6_ROUTER_PREF is not set CONFIG_IPV6_SIT=y # CONFIG_IPV6_SIT_6RD is not set # CONFIG_IPV6_TUNNEL is not set # CONFIG_IPV6_VTI is not set # CONFIG_IPX is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_DCCP is not set # CONFIG_IP_MROUTE is not set CONFIG_IP_MULTICAST=y # CONFIG_IP_NF_ARPTABLES is not set CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MANGLE=m # CONFIG_IP_NF_MATCH_AH is not set # CONFIG_IP_NF_MATCH_ECN is not set # CONFIG_IP_NF_MATCH_RPFILTER is not set # CONFIG_IP_NF_MATCH_TTL is not set # CONFIG_IP_NF_RAW is not set # CONFIG_IP_NF_SECURITY is not set # CONFIG_IP_NF_TARGET_CLUSTERIP is not set # CONFIG_IP_NF_TARGET_ECN is not set CONFIG_IP_NF_TARGET_MASQUERADE=m # CONFIG_IP_NF_TARGET_NETMAP is not set # CONFIG_IP_NF_TARGET_REDIRECT is not set CONFIG_IP_NF_TARGET_REJECT=m # CONFIG_IP_NF_TARGET_SYNPROXY is not set # CONFIG_IP_NF_TARGET_TTL is not set # CONFIG_IP_NF_TARGET_ULOG is not set CONFIG_IP_PNP=y CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_RARP=y # CONFIG_IP_SCTP is not set # CONFIG_IP_SET is not set # CONFIG_IP_VS is not set # CONFIG_IRDA is not set CONFIG_IRQCHIP=y # CONFIG_IRQSOFF_TRACER is not set CONFIG_IRQ_DOMAIN=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_IRQ_WORK=y # CONFIG_ISCSI_BOOT_SYSFS is not set # CONFIG_ISCSI_TCP is not set # CONFIG_ISDN is not set # CONFIG_ISL29003 is not set # CONFIG_ISL29020 is not set # CONFIG_ISO9660_FS is not set CONFIG_JBD=y CONFIG_JBD2=y # CONFIG_JBD2_DEBUG is not set # CONFIG_JBD_DEBUG is not set # CONFIG_JFFS2_CMODE_FAVOURLZO is not set # CONFIG_JFFS2_CMODE_NONE is not set CONFIG_JFFS2_CMODE_PRIORITY=y # CONFIG_JFFS2_CMODE_SIZE is not set CONFIG_JFFS2_COMPRESSION_OPTIONS=y CONFIG_JFFS2_FS=y CONFIG_JFFS2_FS_DEBUG=0 CONFIG_JFFS2_FS_POSIX_ACL=y CONFIG_JFFS2_FS_SECURITY=y # CONFIG_JFFS2_FS_WBUF_VERIFY is not set CONFIG_JFFS2_FS_WRITEBUFFER=y CONFIG_JFFS2_FS_XATTR=y CONFIG_JFFS2_LZO=y CONFIG_JFFS2_RTIME=y CONFIG_JFFS2_RUBIN=y CONFIG_JFFS2_SUMMARY=y CONFIG_JFFS2_ZLIB=y # CONFIG_JFS_FS is not set # CONFIG_JUMP_LABEL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KARMA_PARTITION is not set CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_LZ4 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_MODE_NEON is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KEXEC is not set # CONFIG_KEYBOARD_ADP5588 is not set # CONFIG_KEYBOARD_ADP5589 is not set CONFIG_KEYBOARD_ATKBD=y CONFIG_KEYBOARD_GPIO=y # CONFIG_KEYBOARD_GPIO_POLLED is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_LM8333 is not set # CONFIG_KEYBOARD_MATRIX is not set # CONFIG_KEYBOARD_MAX7359 is not set # CONFIG_KEYBOARD_MCS is not set # CONFIG_KEYBOARD_MPR121 is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_OPENCORES is not set # CONFIG_KEYBOARD_QT1070 is not set # CONFIG_KEYBOARD_QT2160 is not set CONFIG_KEYBOARD_SAMSUNG=y # CONFIG_KEYBOARD_STOWAWAY is not set # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_TCA6416 is not set # CONFIG_KEYBOARD_TCA8418 is not set # CONFIG_KEYBOARD_XTKBD is not set CONFIG_KEYS=y # CONFIG_KEYS_DEBUG_PROC_KEYS is not set # CONFIG_KGDB is not set # CONFIG_KPROBES is not set # CONFIG_KS8842 is not set # CONFIG_KS8851_MLL is not set # CONFIG_KSM is not set CONFIG_KTIME_SCALAR=y CONFIG_KUSER_HELPERS=y # CONFIG_L2TP is not set # CONFIG_LAPB is not set CONFIG_LBDAF=y # CONFIG_LDM_PARTITION is not set CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_LIB80211 is not set # CONFIG_LIBCRC32C is not set # CONFIG_LIBFC is not set # CONFIG_LIBFCOE is not set # CONFIG_LKDTM is not set CONFIG_LLC=m # CONFIG_LLC2 is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_LOCKD=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_LOCKD_V4=y # CONFIG_LOCKUP_DETECTOR is not set # CONFIG_LOCK_STAT is not set # CONFIG_LOGFS is not set CONFIG_LOGO=y CONFIG_LOGO_LINUX_CLUT224=y CONFIG_LOGO_LINUX_MONO=y CONFIG_LOGO_LINUX_VGA16=y CONFIG_LOG_BUF_SHIFT=16 # CONFIG_LSI_ET1011C_PHY is not set CONFIG_LSM_MMAP_MIN_ADDR=0 # CONFIG_LXT_PHY is not set CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y # CONFIG_MACB is not set # CONFIG_MACVLAN is not set # CONFIG_MAC_PARTITION is not set CONFIG_MAGIC_SYSRQ=y CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1 # CONFIG_MAILBOX is not set # CONFIG_MARVELL_PHY is not set # CONFIG_MCPM is not set CONFIG_MD=y CONFIG_MDIO_BITBANG=y # CONFIG_MDIO_BUS_MUX_GPIO is not set # CONFIG_MDIO_BUS_MUX_MMIOREG is not set # CONFIG_MDIO_GPIO is not set # CONFIG_MEDIA_SUPPORT is not set # CONFIG_MEMORY is not set CONFIG_MEMORY_ISOLATION=y # CONFIG_MEMSTICK is not set # CONFIG_MFD_88PM800 is not set # CONFIG_MFD_88PM805 is not set # CONFIG_MFD_88PM860X is not set # CONFIG_MFD_AAT2870_CORE is not set # CONFIG_MFD_ARIZONA_I2C is not set # CONFIG_MFD_AS3711 is not set # CONFIG_MFD_AS3722 is not set # CONFIG_MFD_ASIC3 is not set # CONFIG_MFD_BCM590XX is not set CONFIG_MFD_CORE=y # CONFIG_MFD_CROS_EC is not set # CONFIG_MFD_DA9052_I2C is not set # CONFIG_MFD_DA9055 is not set # CONFIG_MFD_DA9063 is not set # CONFIG_MFD_HI6421_PMIC is not set # CONFIG_MFD_KEMPLD is not set # CONFIG_MFD_LM3533 is not set # CONFIG_MFD_LP3943 is not set # CONFIG_MFD_LP8788 is not set # CONFIG_MFD_MAX14577 is not set # CONFIG_MFD_MAX77686 is not set # CONFIG_MFD_MAX77693 is not set # CONFIG_MFD_MAX8907 is not set # CONFIG_MFD_MAX8925 is not set # CONFIG_MFD_MAX8997 is not set # CONFIG_MFD_MAX8998 is not set # CONFIG_MFD_MC13XXX_I2C is not set # CONFIG_MFD_PALMAS is not set # CONFIG_MFD_PCF50633 is not set # CONFIG_MFD_RC5T583 is not set # CONFIG_MFD_RETU is not set CONFIG_MFD_SEC_CORE=y # CONFIG_MFD_SI476X_CORE is not set # CONFIG_MFD_SM501 is not set # CONFIG_MFD_SMSC is not set # CONFIG_MFD_STMPE is not set # CONFIG_MFD_SYSCON is not set # CONFIG_MFD_T7L66XB is not set # CONFIG_MFD_TC3589X is not set # CONFIG_MFD_TC6387XB is not set # CONFIG_MFD_TC6393XB is not set # CONFIG_MFD_TI_AM335X_TSCADC is not set # CONFIG_MFD_TMIO is not set # CONFIG_MFD_TPS65090 is not set # CONFIG_MFD_TPS65217 is not set # CONFIG_MFD_TPS6586X is not set # CONFIG_MFD_TPS65910 is not set # CONFIG_MFD_TPS65912 is not set # CONFIG_MFD_TPS65912_I2C is not set # CONFIG_MFD_TPS80031 is not set # CONFIG_MFD_VIPERBOARD is not set # CONFIG_MFD_WL1273_CORE is not set # CONFIG_MFD_WM831X_I2C is not set # CONFIG_MFD_WM8350_I2C is not set # CONFIG_MFD_WM8400 is not set # CONFIG_MFD_WM8994 is not set # CONFIG_MG_DISK is not set # CONFIG_MICREL_PHY is not set CONFIG_MIGHT_HAVE_CACHE_L2X0=y CONFIG_MIGHT_HAVE_PCI=y CONFIG_MIGRATION=y CONFIG_MII=y # CONFIG_MINIX_FS is not set # CONFIG_MINIX_SUBPARTITION is not set CONFIG_MISC_FILESYSTEMS=y CONFIG_MMC=y # CONFIG_MMC_ARMMMCI is not set CONFIG_MMC_BLOCK=y CONFIG_MMC_BLOCK_BOUNCE=y # CONFIG_MMC_BLOCK_DEFERRED_RESUME is not set CONFIG_MMC_BLOCK_MINORS=8 # CONFIG_MMC_CLKGATE is not set # CONFIG_MMC_DEBUG is not set CONFIG_MMC_DW=y CONFIG_MMC_DW_EXYNOS=y CONFIG_MMC_DW_IDMAC=y # CONFIG_MMC_DW_K3 is not set CONFIG_MMC_DW_PLTFM=y # CONFIG_MMC_EMBEDDED_SDIO is not set # CONFIG_MMC_PARANOID_SD_INIT is not set # CONFIG_MMC_SDHCI is not set # CONFIG_MMC_SDHCI_PXAV2 is not set # CONFIG_MMC_SDHCI_PXAV3 is not set # CONFIG_MMC_TEST is not set CONFIG_MMC_UNSAFE_RESUME=y # CONFIG_MMC_USHC is not set # CONFIG_MMC_VUB300 is not set CONFIG_MMU=y CONFIG_MODULES=y CONFIG_MODULES_USE_ELF_REL=y # CONFIG_MODULE_FORCE_LOAD is not set # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODULE_SIG is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MOUSE_APPLETOUCH is not set # CONFIG_MOUSE_BCM5974 is not set # CONFIG_MOUSE_CYAPA is not set # CONFIG_MOUSE_GPIO is not set CONFIG_MOUSE_PS2=y CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_CYPRESS=y # CONFIG_MOUSE_PS2_ELANTECH is not set CONFIG_MOUSE_PS2_LOGIPS2PP=y # CONFIG_MOUSE_PS2_SENTELIC is not set CONFIG_MOUSE_PS2_SYNAPTICS=y # CONFIG_MOUSE_PS2_TOUCHKIT is not set CONFIG_MOUSE_PS2_TRACKPOINT=y # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_SYNAPTICS_I2C is not set # CONFIG_MOUSE_SYNAPTICS_USB is not set # CONFIG_MOUSE_VSXXXAA is not set CONFIG_MSDOS_FS=y CONFIG_MSDOS_PARTITION=y CONFIG_MTD=y # CONFIG_MTD_ABSENT is not set # CONFIG_MTD_AFS_PARTS is not set # CONFIG_MTD_AR7_PARTS is not set CONFIG_MTD_BLKDEVS=y CONFIG_MTD_BLOCK=y # CONFIG_MTD_BLOCK2MTD is not set CONFIG_MTD_CFI=y # CONFIG_MTD_CFI_ADV_OPTIONS is not set # CONFIG_MTD_CFI_AMDSTD is not set CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y # CONFIG_MTD_CFI_I4 is not set # CONFIG_MTD_CFI_I8 is not set CONFIG_MTD_CFI_INTELEXT=y # CONFIG_MTD_CFI_STAA is not set CONFIG_MTD_CFI_UTIL=y CONFIG_MTD_CMDLINE_PARTS=y # CONFIG_MTD_COMPLEX_MAPPINGS is not set # CONFIG_MTD_DOCG3 is not set CONFIG_MTD_GEN_PROBE=y # CONFIG_MTD_JEDECPROBE is not set # CONFIG_MTD_LPDDR is not set CONFIG_MTD_MAP_BANK_WIDTH_1=y # CONFIG_MTD_MAP_BANK_WIDTH_16 is not set CONFIG_MTD_MAP_BANK_WIDTH_2=y # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set CONFIG_MTD_MAP_BANK_WIDTH_4=y # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set # CONFIG_MTD_MTDRAM is not set CONFIG_MTD_NAND=y # CONFIG_MTD_NAND_DENALI is not set # CONFIG_MTD_NAND_DISKONCHIP is not set # CONFIG_MTD_NAND_DOCG4 is not set CONFIG_MTD_NAND_ECC=y # CONFIG_MTD_NAND_ECC_BCH is not set # CONFIG_MTD_NAND_ECC_SMC is not set # CONFIG_MTD_NAND_GPIO is not set CONFIG_MTD_NAND_IDS=y # CONFIG_MTD_NAND_NANDSIM is not set # CONFIG_MTD_NAND_PLATFORM is not set CONFIG_MTD_OF_PARTS=y # CONFIG_MTD_ONENAND is not set CONFIG_MTD_OOPS=y # CONFIG_MTD_PHRAM is not set # CONFIG_MTD_PHYSMAP is not set # CONFIG_MTD_PHYSMAP_OF is not set # CONFIG_MTD_PLATRAM is not set # CONFIG_MTD_RAM is not set # CONFIG_MTD_REDBOOT_PARTS is not set # CONFIG_MTD_ROM is not set # CONFIG_MTD_SLRAM is not set # CONFIG_MTD_SM_COMMON is not set # CONFIG_MTD_SWAP is not set # CONFIG_MTD_TESTS is not set # CONFIG_MTD_UBI is not set CONFIG_MULTI_IRQ_HANDLER=y # CONFIG_MVMDIO is not set # CONFIG_NAMESPACES is not set # CONFIG_NATIONAL_PHY is not set # CONFIG_NCP_FS is not set CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_MACH_MEMORY_H=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_NEON=y CONFIG_NET=y # CONFIG_NETCONSOLE is not set CONFIG_NETDEVICES=y CONFIG_NETFILTER=y CONFIG_NETFILTER_ADVANCED=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_NETFILTER_NETLINK=m # CONFIG_NETFILTER_NETLINK_ACCT is not set CONFIG_NETFILTER_NETLINK_LOG=m # CONFIG_NETFILTER_NETLINK_QUEUE is not set CONFIG_NETFILTER_XTABLES=m CONFIG_NETFILTER_XT_CONNMARK=m CONFIG_NETFILTER_XT_MARK=m # CONFIG_NETFILTER_XT_MATCH_ADDRTYPE is not set # CONFIG_NETFILTER_XT_MATCH_BPF is not set # CONFIG_NETFILTER_XT_MATCH_CGROUP is not set # CONFIG_NETFILTER_XT_MATCH_CLUSTER is not set # CONFIG_NETFILTER_XT_MATCH_COMMENT is not set # CONFIG_NETFILTER_XT_MATCH_CONNBYTES is not set # CONFIG_NETFILTER_XT_MATCH_CONNLABEL is not set # CONFIG_NETFILTER_XT_MATCH_CONNLIMIT is not set CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m # CONFIG_NETFILTER_XT_MATCH_CPU is not set # CONFIG_NETFILTER_XT_MATCH_DCCP is not set # CONFIG_NETFILTER_XT_MATCH_DEVGROUP is not set # CONFIG_NETFILTER_XT_MATCH_DSCP is not set # CONFIG_NETFILTER_XT_MATCH_ECN is not set # CONFIG_NETFILTER_XT_MATCH_ESP is not set # CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set # CONFIG_NETFILTER_XT_MATCH_HELPER is not set # CONFIG_NETFILTER_XT_MATCH_HL is not set # CONFIG_NETFILTER_XT_MATCH_IPCOMP is not set # CONFIG_NETFILTER_XT_MATCH_IPRANGE is not set # CONFIG_NETFILTER_XT_MATCH_L2TP is not set # CONFIG_NETFILTER_XT_MATCH_LENGTH is not set CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m # CONFIG_NETFILTER_XT_MATCH_MARK is not set CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m # CONFIG_NETFILTER_XT_MATCH_NFACCT is not set # CONFIG_NETFILTER_XT_MATCH_OSF is not set # CONFIG_NETFILTER_XT_MATCH_OWNER is not set # CONFIG_NETFILTER_XT_MATCH_PHYSDEV is not set # CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set # CONFIG_NETFILTER_XT_MATCH_POLICY is not set # CONFIG_NETFILTER_XT_MATCH_QUOTA is not set # CONFIG_NETFILTER_XT_MATCH_QUOTA2 is not set # CONFIG_NETFILTER_XT_MATCH_RATEEST is not set # CONFIG_NETFILTER_XT_MATCH_REALM is not set # CONFIG_NETFILTER_XT_MATCH_RECENT is not set # CONFIG_NETFILTER_XT_MATCH_SCTP is not set # CONFIG_NETFILTER_XT_MATCH_SOCKET is not set CONFIG_NETFILTER_XT_MATCH_STATE=m # CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set # CONFIG_NETFILTER_XT_MATCH_STRING is not set # CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set # CONFIG_NETFILTER_XT_MATCH_TIME is not set # CONFIG_NETFILTER_XT_MATCH_U32 is not set # CONFIG_NETFILTER_XT_TARGET_AUDIT is not set CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m # CONFIG_NETFILTER_XT_TARGET_CLASSIFY is not set # CONFIG_NETFILTER_XT_TARGET_CONNMARK is not set # CONFIG_NETFILTER_XT_TARGET_DSCP is not set # CONFIG_NETFILTER_XT_TARGET_HL is not set # CONFIG_NETFILTER_XT_TARGET_HMARK is not set # CONFIG_NETFILTER_XT_TARGET_IDLETIMER is not set CONFIG_NETFILTER_XT_TARGET_LOG=m # CONFIG_NETFILTER_XT_TARGET_MARK is not set # CONFIG_NETFILTER_XT_TARGET_NETMAP is not set # CONFIG_NETFILTER_XT_TARGET_NFLOG is not set # CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set # CONFIG_NETFILTER_XT_TARGET_RATEEST is not set CONFIG_NETFILTER_XT_TARGET_REDIRECT=m # CONFIG_NETFILTER_XT_TARGET_SECMARK is not set # CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set # CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP is not set # CONFIG_NETFILTER_XT_TARGET_TEE is not set # CONFIG_NETFILTER_XT_TARGET_TPROXY is not set CONFIG_NETLABEL=y # CONFIG_NETLINK_DIAG is not set # CONFIG_NETLINK_MMAP is not set # CONFIG_NETPOLL is not set CONFIG_NETWORK_FILESYSTEMS=y # CONFIG_NETWORK_PHY_TIMESTAMPING is not set CONFIG_NETWORK_SECMARK=y # CONFIG_NET_9P is not set # CONFIG_NET_ACTIVITY_STATS is not set CONFIG_NET_CADENCE=y # CONFIG_NET_CALXEDA_XGMAC is not set CONFIG_NET_CORE=y # CONFIG_NET_DROP_MONITOR is not set # CONFIG_NET_DSA_MV88E6060 is not set # CONFIG_NET_DSA_MV88E6123_61_65 is not set # CONFIG_NET_DSA_MV88E6131 is not set # CONFIG_NET_DSA_MV88E6XXX is not set # CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set CONFIG_NET_FLOW_LIMIT=y # CONFIG_NET_IPGRE_DEMUX is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPVTI is not set CONFIG_NET_IP_TUNNEL=y CONFIG_NET_KEY=y CONFIG_NET_KEY_MIGRATE=y # CONFIG_NET_MPLS_GSO is not set # CONFIG_NET_PKTGEN is not set # CONFIG_NET_POLL_CONTROLLER is not set CONFIG_NET_RX_BUSY_POLL=y # CONFIG_NET_SCHED is not set # CONFIG_NET_TEAM is not set CONFIG_NET_VENDOR_8390=y CONFIG_NET_VENDOR_ARC=y CONFIG_NET_VENDOR_BROADCOM=y CONFIG_NET_VENDOR_CIRRUS=y CONFIG_NET_VENDOR_FARADAY=y CONFIG_NET_VENDOR_I825XX=y CONFIG_NET_VENDOR_INTEL=y CONFIG_NET_VENDOR_MARVELL=y CONFIG_NET_VENDOR_MICREL=y CONFIG_NET_VENDOR_NATSEMI=y CONFIG_NET_VENDOR_SEEQ=y CONFIG_NET_VENDOR_SMSC=y CONFIG_NET_VENDOR_STMICRO=y CONFIG_NET_VENDOR_VIA=y CONFIG_NET_VENDOR_WIZNET=y # CONFIG_NEW_LEDS is not set # CONFIG_NFC is not set # CONFIG_NFSD is not set CONFIG_NFS_ACL_SUPPORT=y CONFIG_NFS_COMMON=y CONFIG_NFS_FS=y # CONFIG_NFS_SWAP is not set CONFIG_NFS_USE_KERNEL_DNS=y # CONFIG_NFS_USE_LEGACY_DNS is not set # CONFIG_NFS_V2 is not set CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y # CONFIG_NFS_V4_1 is not set # CONFIG_NFTL is not set CONFIG_NF_CONNTRACK=m # CONFIG_NF_CONNTRACK_AMANDA is not set # CONFIG_NF_CONNTRACK_EVENTS is not set # CONFIG_NF_CONNTRACK_FTP is not set # CONFIG_NF_CONNTRACK_H323 is not set CONFIG_NF_CONNTRACK_IPV4=m CONFIG_NF_CONNTRACK_IPV6=m # CONFIG_NF_CONNTRACK_IRC is not set CONFIG_NF_CONNTRACK_MARK=y # CONFIG_NF_CONNTRACK_NETBIOS_NS is not set # CONFIG_NF_CONNTRACK_PPTP is not set CONFIG_NF_CONNTRACK_PROCFS=y CONFIG_NF_CONNTRACK_PROC_COMPAT=y # CONFIG_NF_CONNTRACK_SANE is not set # CONFIG_NF_CONNTRACK_SECMARK is not set # CONFIG_NF_CONNTRACK_SIP is not set # CONFIG_NF_CONNTRACK_SNMP is not set # CONFIG_NF_CONNTRACK_TFTP is not set # CONFIG_NF_CONNTRACK_TIMEOUT is not set # CONFIG_NF_CONNTRACK_TIMESTAMP is not set CONFIG_NF_CT_NETLINK=m # CONFIG_NF_CT_NETLINK_TIMEOUT is not set # CONFIG_NF_CT_PROTO_DCCP is not set # CONFIG_NF_CT_PROTO_SCTP is not set # CONFIG_NF_CT_PROTO_UDPLITE is not set CONFIG_NF_DEFRAG_IPV4=m CONFIG_NF_DEFRAG_IPV6=m CONFIG_NF_NAT=m # CONFIG_NF_NAT_AMANDA is not set # CONFIG_NF_NAT_FTP is not set # CONFIG_NF_NAT_H323 is not set CONFIG_NF_NAT_IPV4=m CONFIG_NF_NAT_IPV6=m # CONFIG_NF_NAT_IRC is not set CONFIG_NF_NAT_NEEDED=y # CONFIG_NF_NAT_PPTP is not set # CONFIG_NF_NAT_SIP is not set # CONFIG_NF_NAT_TFTP is not set # CONFIG_NF_TABLES is not set # CONFIG_NILFS2_FS is not set CONFIG_NLATTR=y # CONFIG_NLMON is not set CONFIG_NLS=y # CONFIG_NLS_ASCII is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_950 is not set CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_MAC_CELTIC is not set # CONFIG_NLS_MAC_CENTEURO is not set # CONFIG_NLS_MAC_CROATIAN is not set # CONFIG_NLS_MAC_CYRILLIC is not set # CONFIG_NLS_MAC_GAELIC is not set # CONFIG_NLS_MAC_GREEK is not set # CONFIG_NLS_MAC_ICELAND is not set # CONFIG_NLS_MAC_INUIT is not set # CONFIG_NLS_MAC_ROMAN is not set # CONFIG_NLS_MAC_ROMANIAN is not set # CONFIG_NLS_MAC_TURKISH is not set # CONFIG_NLS_UTF8 is not set CONFIG_NOP_TRACER=y # CONFIG_NOP_USB_XCEIV is not set # CONFIG_NOTIFIER_ERROR_INJECTION is not set CONFIG_NO_BOOTMEM=y CONFIG_NO_HZ=y CONFIG_NO_HZ_COMMON=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_IOPORT=y CONFIG_NR_CPUS=8 # CONFIG_NTFS_FS is not set # CONFIG_N_GSM is not set # CONFIG_OC_ETM is not set CONFIG_OF=y CONFIG_OF_ADDRESS=y CONFIG_OF_EARLY_FLATTREE=y CONFIG_OF_EXTCON=y CONFIG_OF_FLATTREE=y CONFIG_OF_GPIO=y CONFIG_OF_IOMMU=y CONFIG_OF_IRQ=y CONFIG_OF_MDIO=y CONFIG_OF_MTD=y CONFIG_OF_NET=y # CONFIG_OF_SELFTEST is not set CONFIG_OID_REGISTRY=y CONFIG_OLD_SIGACTION=y CONFIG_OLD_SIGSUSPEND3=y # CONFIG_OMFS_FS is not set # CONFIG_OPENVSWITCH is not set CONFIG_OPROFILE=y # CONFIG_OSF_PARTITION is not set CONFIG_OUTER_CACHE=y CONFIG_OUTER_CACHE_SYNC=y CONFIG_PACKET=y # CONFIG_PACKET_DIAG is not set CONFIG_PAGE_OFFSET=0xC0000000 # CONFIG_PANIC_ON_OOPS is not set CONFIG_PANIC_ON_OOPS_VALUE=0 CONFIG_PANIC_TIMEOUT=0 # CONFIG_PARPORT is not set CONFIG_PARTITION_ADVANCED=y # CONFIG_PCCARD is not set # CONFIG_PCI is not set # CONFIG_PCI_SYSCALL is not set # CONFIG_PERCPU_TEST is not set CONFIG_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # CONFIG_PERSISTENT_KEYRINGS is not set # CONFIG_PHONET is not set CONFIG_PHYLIB=y # CONFIG_PHYS_ADDR_T_64BIT is not set # CONFIG_PHY_EXYNOS_DP_VIDEO is not set # CONFIG_PHY_EXYNOS_MIPI_VIDEO is not set # CONFIG_PID_IN_CONTEXTIDR is not set CONFIG_PINCONF=y CONFIG_PINCTRL=y # CONFIG_PINCTRL_CAPRI is not set CONFIG_PINCTRL_EXYNOS=y CONFIG_PINCTRL_EXYNOS5440=y # CONFIG_PINCTRL_MSM8X74 is not set CONFIG_PINCTRL_SAMSUNG=y # CONFIG_PINCTRL_SINGLE is not set CONFIG_PINMUX=y # CONFIG_PL310_ERRATA_588369 is not set # CONFIG_PL310_ERRATA_727915 is not set # CONFIG_PL310_ERRATA_753970 is not set # CONFIG_PL310_ERRATA_769419 is not set CONFIG_PL330_DMA=y CONFIG_PLAT_SAMSUNG=y # CONFIG_PLAT_SPEAR is not set CONFIG_PM=y # CONFIG_PMBUS is not set # CONFIG_PMIC_ADP5520 is not set # CONFIG_PMIC_DA903X is not set # CONFIG_PM_AUTOSLEEP is not set CONFIG_PM_CLK=y # CONFIG_PM_DEBUG is not set # CONFIG_PM_DEVFREQ is not set CONFIG_PM_GENERIC_DOMAINS=y CONFIG_PM_GENERIC_DOMAINS_RUNTIME=y CONFIG_PM_GENERIC_DOMAINS_SLEEP=y CONFIG_PM_OPP=y CONFIG_PM_RUNTIME=y CONFIG_PM_SLEEP=y CONFIG_PM_SLEEP_SMP=y # CONFIG_PM_WAKELOCKS is not set CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y # CONFIG_POWERCAP is not set # CONFIG_POWER_AVS is not set # CONFIG_POWER_SUPPLY is not set # CONFIG_PPP is not set # CONFIG_PPS is not set # CONFIG_PREEMPT is not set CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_RCU is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_PRINTK=y CONFIG_PRINTK_TIME=y CONFIG_PRINT_QUOTA_WARNING=y # CONFIG_PROBE_EVENTS is not set CONFIG_PROC_DEVICETREE=y CONFIG_PROC_EVENTS=y CONFIG_PROC_FS=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_PROC_SYSCTL=y # CONFIG_PROFILE_ALL_BRANCHES is not set # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set CONFIG_PROFILING=y # CONFIG_PROVE_LOCKING is not set # CONFIG_PSTORE is not set # CONFIG_PTP_1588_CLOCK is not set # CONFIG_PWM is not set # CONFIG_QFMT_V1 is not set CONFIG_QFMT_V2=y # CONFIG_QNX4FS_FS is not set # CONFIG_QNX6FS_FS is not set # CONFIG_QSEMI_PHY is not set CONFIG_QUOTA=y CONFIG_QUOTACTL=y # CONFIG_QUOTA_DEBUG is not set # CONFIG_QUOTA_NETLINK_INTERFACE is not set CONFIG_QUOTA_TREE=y # CONFIG_R3964 is not set CONFIG_RAID6_PQ=y # CONFIG_RAID_ATTRS is not set # CONFIG_RANDOM32_SELFTEST is not set # CONFIG_RAW_DRIVER is not set # CONFIG_RBTREE_TEST is not set # CONFIG_RCU_CPU_STALL_INFO is not set CONFIG_RCU_CPU_STALL_TIMEOUT=21 CONFIG_RCU_FANOUT=32 # CONFIG_RCU_FANOUT_EXACT is not set CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FAST_NO_HZ is not set # CONFIG_RCU_NOCB_CPU is not set CONFIG_RCU_STALL_COMMON=y # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_RCU_TRACE is not set # CONFIG_RCU_USER_QS is not set # CONFIG_RDS is not set # CONFIG_RD_BZIP2 is not set CONFIG_RD_GZIP=y # CONFIG_RD_LZ4 is not set # CONFIG_RD_LZMA is not set # CONFIG_RD_LZO is not set # CONFIG_RD_XZ is not set # CONFIG_READABLE_ASM is not set # CONFIG_REALTEK_PHY is not set CONFIG_REGMAP=y CONFIG_REGMAP_I2C=y CONFIG_REGMAP_IRQ=y CONFIG_REGULATOR=y # CONFIG_REGULATOR_ACT8865 is not set # CONFIG_REGULATOR_AD5398 is not set # CONFIG_REGULATOR_DA9210 is not set # CONFIG_REGULATOR_DEBUG is not set # CONFIG_REGULATOR_FAN53555 is not set CONFIG_REGULATOR_FIXED_VOLTAGE=y # CONFIG_REGULATOR_GPIO is not set # CONFIG_REGULATOR_ISL6271A is not set # CONFIG_REGULATOR_LP3971 is not set # CONFIG_REGULATOR_LP3972 is not set # CONFIG_REGULATOR_LP872X is not set # CONFIG_REGULATOR_LP8755 is not set # CONFIG_REGULATOR_MAX1586 is not set # CONFIG_REGULATOR_MAX8649 is not set # CONFIG_REGULATOR_MAX8660 is not set # CONFIG_REGULATOR_MAX8952 is not set # CONFIG_REGULATOR_MAX8973 is not set # CONFIG_REGULATOR_PFUZE100 is not set CONFIG_REGULATOR_S2MPS11=y # CONFIG_REGULATOR_S5M8767 is not set # CONFIG_REGULATOR_TPS51632 is not set # CONFIG_REGULATOR_TPS62360 is not set # CONFIG_REGULATOR_TPS65023 is not set # CONFIG_REGULATOR_TPS6507X is not set # CONFIG_REGULATOR_USERSPACE_CONSUMER is not set # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REISERFS_FS is not set # CONFIG_RELAY is not set # CONFIG_RESET_CONTROLLER is not set # CONFIG_RESOURCE_COUNTERS is not set # CONFIG_RFD_FTL is not set # CONFIG_RFKILL is not set # CONFIG_RFKILL_REGULATOR is not set CONFIG_RFS_ACCEL=y CONFIG_RING_BUFFER=y CONFIG_RING_BUFFER_ALLOW_SWAP=y # CONFIG_RING_BUFFER_BENCHMARK is not set # CONFIG_RING_BUFFER_STARTUP_TEST is not set # CONFIG_ROMFS_FS is not set CONFIG_ROOT_NFS=y CONFIG_RPS=y CONFIG_RTC_CLASS=y # CONFIG_RTC_DEBUG is not set # CONFIG_RTC_DRV_BQ32K is not set # CONFIG_RTC_DRV_BQ4802 is not set # CONFIG_RTC_DRV_CMOS is not set # CONFIG_RTC_DRV_DS1286 is not set # CONFIG_RTC_DRV_DS1307 is not set # CONFIG_RTC_DRV_DS1374 is not set # CONFIG_RTC_DRV_DS1511 is not set # CONFIG_RTC_DRV_DS1553 is not set # CONFIG_RTC_DRV_DS1672 is not set # CONFIG_RTC_DRV_DS1742 is not set # CONFIG_RTC_DRV_DS2404 is not set # CONFIG_RTC_DRV_DS3232 is not set # CONFIG_RTC_DRV_EM3027 is not set # CONFIG_RTC_DRV_FM3130 is not set # CONFIG_RTC_DRV_HID_SENSOR_TIME is not set # CONFIG_RTC_DRV_HYM8563 is not set # CONFIG_RTC_DRV_ISL12022 is not set # CONFIG_RTC_DRV_ISL12057 is not set # CONFIG_RTC_DRV_ISL1208 is not set # CONFIG_RTC_DRV_M41T80 is not set # CONFIG_RTC_DRV_M48T35 is not set # CONFIG_RTC_DRV_M48T59 is not set # CONFIG_RTC_DRV_M48T86 is not set # CONFIG_RTC_DRV_MAX6900 is not set # CONFIG_RTC_DRV_MOXART is not set # CONFIG_RTC_DRV_MSM6242 is not set # CONFIG_RTC_DRV_PCF2127 is not set # CONFIG_RTC_DRV_PCF8523 is not set # CONFIG_RTC_DRV_PCF8563 is not set # CONFIG_RTC_DRV_PCF8583 is not set # CONFIG_RTC_DRV_PL030 is not set # CONFIG_RTC_DRV_PL031 is not set # CONFIG_RTC_DRV_RP5C01 is not set # CONFIG_RTC_DRV_RS5C372 is not set # CONFIG_RTC_DRV_RV3029C2 is not set # CONFIG_RTC_DRV_RX8025 is not set # CONFIG_RTC_DRV_RX8581 is not set # CONFIG_RTC_DRV_S35390A is not set CONFIG_RTC_DRV_S3C=y # CONFIG_RTC_DRV_S5M is not set # CONFIG_RTC_DRV_SNVS is not set # CONFIG_RTC_DRV_STK17TA8 is not set # CONFIG_RTC_DRV_TEST is not set # CONFIG_RTC_DRV_V3020 is not set # CONFIG_RTC_DRV_X1205 is not set CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE="rtc0" CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_LIB=y CONFIG_RTC_SYSTOHC=y CONFIG_RT_MUTEXES=y # CONFIG_RT_MUTEX_TESTER is not set CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_S3C_BOOT_ERROR_RESET is not set CONFIG_S3C_BOOT_UART_FORCE_FIFO=y CONFIG_S3C_LOWLEVEL_UART_PORT=3 CONFIG_S5P_DEV_MFC=y CONFIG_S5P_PM=y CONFIG_S5P_SLEEP=y # CONFIG_SAMPLES is not set # CONFIG_SAMSUNG_ATAGS is not set CONFIG_SAMSUNG_DMADEV=y CONFIG_SAMSUNG_PM=y # CONFIG_SAMSUNG_PM_CHECK is not set # CONFIG_SAMSUNG_PM_DEBUG is not set CONFIG_SAMSUNG_USB2PHY=y CONFIG_SAMSUNG_USB3PHY=y CONFIG_SAMSUNG_USBPHY=y CONFIG_SCHEDSTATS=y # CONFIG_SCHED_AUTOGROUP is not set CONFIG_SCHED_DEBUG=y CONFIG_SCHED_HRTICK=y CONFIG_SCHED_MC=y CONFIG_SCHED_SMT=y # CONFIG_SCHED_TRACER is not set CONFIG_SCSI=y # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_DEBUG is not set # CONFIG_SCSI_DH is not set CONFIG_SCSI_DMA=y # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # CONFIG_SCSI_LOGGING is not set CONFIG_SCSI_LOWLEVEL=y CONFIG_SCSI_MOD=y # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_NETLINK is not set # CONFIG_SCSI_OSD_INITIATOR is not set CONFIG_SCSI_PROC_FS=y # CONFIG_SCSI_SAS_ATTRS is not set # CONFIG_SCSI_SAS_LIBSAS is not set # CONFIG_SCSI_SCAN_ASYNC is not set # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_SRP_ATTRS is not set # CONFIG_SCSI_TGT is not set # CONFIG_SCSI_UFSHCD is not set # CONFIG_SDIO_UART is not set CONFIG_SECCOMP=y CONFIG_SECCOMP_FILTER=y CONFIG_SECURITY=y CONFIG_SECURITYFS=y CONFIG_SECURITY_APPARMOR=y CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1 CONFIG_SECURITY_APPARMOR_HASH=y # CONFIG_SECURITY_DMESG_RESTRICT is not set CONFIG_SECURITY_NETWORK=y # CONFIG_SECURITY_NETWORK_XFRM is not set CONFIG_SECURITY_PATH=y CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_AVC_STATS=y # CONFIG_SECURITY_SELINUX_BOOTPARAM is not set CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 CONFIG_SECURITY_SELINUX_DEVELOP=y # CONFIG_SECURITY_SELINUX_DISABLE is not set # CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set CONFIG_SECURITY_SMACK=y # CONFIG_SECURITY_TOMOYO is not set # CONFIG_SECURITY_YAMA is not set CONFIG_SELECT_MEMORY_MODEL=y # CONFIG_SENSORS_AD7414 is not set # CONFIG_SENSORS_AD7418 is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1029 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ADM9240 is not set # CONFIG_SENSORS_ADS1015 is not set # CONFIG_SENSORS_ADS7828 is not set # CONFIG_SENSORS_ADT7410 is not set # CONFIG_SENSORS_ADT7411 is not set # CONFIG_SENSORS_ADT7462 is not set # CONFIG_SENSORS_ADT7470 is not set # CONFIG_SENSORS_ADT7475 is not set # CONFIG_SENSORS_AMC6821 is not set # CONFIG_SENSORS_APDS990X is not set # CONFIG_SENSORS_ASC7621 is not set # CONFIG_SENSORS_ATXP1 is not set # CONFIG_SENSORS_BH1770 is not set # CONFIG_SENSORS_BH1780 is not set # CONFIG_SENSORS_DME1737 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_DS620 is not set # CONFIG_SENSORS_EMC1403 is not set # CONFIG_SENSORS_EMC2103 is not set # CONFIG_SENSORS_EMC6W201 is not set # CONFIG_SENSORS_F71805F is not set # CONFIG_SENSORS_F71882FG is not set # CONFIG_SENSORS_F75375S is not set # CONFIG_SENSORS_G760A is not set # CONFIG_SENSORS_G762 is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set # CONFIG_SENSORS_GPIO_FAN is not set # CONFIG_SENSORS_HIH6130 is not set # CONFIG_SENSORS_HTU21 is not set # CONFIG_SENSORS_INA209 is not set # CONFIG_SENSORS_INA2XX is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_JC42 is not set # CONFIG_SENSORS_LINEAGE is not set # CONFIG_SENSORS_LIS3LV02D is not set # CONFIG_SENSORS_LIS3_I2C is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM73 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set # CONFIG_SENSORS_LM93 is not set # CONFIG_SENSORS_LM95234 is not set # CONFIG_SENSORS_LM95241 is not set # CONFIG_SENSORS_LM95245 is not set # CONFIG_SENSORS_LTC4151 is not set # CONFIG_SENSORS_LTC4215 is not set # CONFIG_SENSORS_LTC4245 is not set # CONFIG_SENSORS_LTC4261 is not set # CONFIG_SENSORS_MAX16065 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_MAX1668 is not set # CONFIG_SENSORS_MAX197 is not set # CONFIG_SENSORS_MAX6639 is not set # CONFIG_SENSORS_MAX6642 is not set # CONFIG_SENSORS_MAX6650 is not set # CONFIG_SENSORS_MAX6697 is not set # CONFIG_SENSORS_MCP3021 is not set # CONFIG_SENSORS_NCT6775 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_PC87427 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_SCH56XX_COMMON is not set # CONFIG_SENSORS_SHT15 is not set # CONFIG_SENSORS_SHT21 is not set # CONFIG_SENSORS_SMM665 is not set # CONFIG_SENSORS_SMSC47B397 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_SMSC47M192 is not set # CONFIG_SENSORS_THMC50 is not set # CONFIG_SENSORS_TMP102 is not set # CONFIG_SENSORS_TMP401 is not set # CONFIG_SENSORS_TMP421 is not set # CONFIG_SENSORS_TSL2550 is not set # CONFIG_SENSORS_VT1211 is not set # CONFIG_SENSORS_W83627EHF is not set # CONFIG_SENSORS_W83627HF is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83791D is not set # CONFIG_SENSORS_W83792D is not set # CONFIG_SENSORS_W83793 is not set # CONFIG_SENSORS_W83795 is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83L786NG is not set CONFIG_SERIAL_8250=y # CONFIG_SERIAL_8250_CONSOLE is not set CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y CONFIG_SERIAL_8250_DMA=y # CONFIG_SERIAL_8250_DW is not set # CONFIG_SERIAL_8250_EM is not set # CONFIG_SERIAL_8250_EXTENDED is not set CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 # CONFIG_SERIAL_ALTERA_JTAGUART is not set # CONFIG_SERIAL_ALTERA_UART is not set # CONFIG_SERIAL_AMBA_PL010 is not set # CONFIG_SERIAL_AMBA_PL011 is not set # CONFIG_SERIAL_ARC is not set CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_SERIAL_FSL_LPUART is not set # CONFIG_SERIAL_NONSTANDARD is not set # CONFIG_SERIAL_OF_PLATFORM is not set CONFIG_SERIAL_SAMSUNG=y CONFIG_SERIAL_SAMSUNG_CONSOLE=y CONFIG_SERIAL_SAMSUNG_UARTS=4 CONFIG_SERIAL_SAMSUNG_UARTS_4=y # CONFIG_SERIAL_SCCNXP is not set # CONFIG_SERIAL_SH_SCI is not set # CONFIG_SERIAL_ST_ASC is not set # CONFIG_SERIAL_TIMBERDALE is not set # CONFIG_SERIAL_XILINX_PS_UART is not set CONFIG_SERIO=y # CONFIG_SERIO_ALTERA_PS2 is not set # CONFIG_SERIO_AMBAKMI is not set # CONFIG_SERIO_APBPS2 is not set # CONFIG_SERIO_ARC_PS2 is not set CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_OLPC_APSP is not set # CONFIG_SERIO_PS2MULT is not set # CONFIG_SERIO_RAW is not set CONFIG_SERIO_SERPORT=y # CONFIG_SGI_PARTITION is not set CONFIG_SHMEM=y # CONFIG_SH_ETH is not set CONFIG_SIGNALFD=y CONFIG_SLAB=y CONFIG_SLABINFO=y # CONFIG_SLIP is not set # CONFIG_SLOB is not set # CONFIG_SLUB is not set # CONFIG_SMC911X is not set # CONFIG_SMC91X is not set CONFIG_SMP=y CONFIG_SMP_ON_UP=y # CONFIG_SMSC911X is not set # CONFIG_SMSC_PHY is not set # CONFIG_SM_FTL is not set CONFIG_SND=y # CONFIG_SND_ALOOP is not set CONFIG_SND_ARM=y # CONFIG_SND_ARMAACI is not set # CONFIG_SND_ATMEL_SOC is not set CONFIG_SND_COMPRESS_OFFLOAD=y # CONFIG_SND_DEBUG is not set # CONFIG_SND_DESIGNWARE_I2S is not set CONFIG_SND_DMAENGINE_PCM=y CONFIG_SND_DRIVERS=y # CONFIG_SND_DUMMY is not set # CONFIG_SND_DYNAMIC_MINORS is not set # CONFIG_SND_EMU10K1_SEQ is not set # CONFIG_SND_HRTIMER is not set CONFIG_SND_JACK=y # CONFIG_SND_MIXER_OSS is not set # CONFIG_SND_MPU401 is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_OPL3_LIB_SEQ is not set # CONFIG_SND_OPL4_LIB_SEQ is not set CONFIG_SND_PCM=y # CONFIG_SND_PCM_OSS is not set # CONFIG_SND_RAWMIDI_SEQ is not set CONFIG_SND_S3C_DMA=y CONFIG_SND_SAMSUNG_I2S=y # CONFIG_SND_SBAWE_SEQ is not set # CONFIG_SND_SEQUENCER is not set # CONFIG_SND_SERIAL_U16550 is not set # CONFIG_SND_SIMPLE_CARD is not set CONFIG_SND_SOC=y CONFIG_SND_SOC_GENERIC_DMAENGINE_PCM=y CONFIG_SND_SOC_I2C_AND_SPI=y CONFIG_SND_SOC_I2S_STUB=y CONFIG_SND_SOC_SAMSUNG=y # CONFIG_SND_SOC_SAMSUNG_SMDK_SPDIF is not set # CONFIG_SND_SOC_SAMSUNG_SMDK_WM8994 is not set CONFIG_SND_SOC_SMDK_I2S_STUB=y # CONFIG_SND_SOC_SMDK_WM8994_PCM is not set CONFIG_SND_SUPPORT_OLD_API=y CONFIG_SND_TIMER=y CONFIG_SND_USB=y # CONFIG_SND_USB_6FIRE is not set # CONFIG_SND_USB_AUDIO is not set # CONFIG_SND_USB_CAIAQ is not set # CONFIG_SND_USB_HIFACE is not set # CONFIG_SND_USB_UA101 is not set # CONFIG_SND_VERBOSE_PRINTK is not set CONFIG_SND_VERBOSE_PROCFS=y CONFIG_SOC_EXYNOS4212=y CONFIG_SOC_EXYNOS4412=y CONFIG_SOC_EXYNOS5250=y CONFIG_SOC_EXYNOS5420=y CONFIG_SOC_EXYNOS5440=y # CONFIG_SOLARIS_X86_PARTITION is not set CONFIG_SOUND=y # CONFIG_SOUND_OSS_CORE is not set # CONFIG_SOUND_PRIME is not set CONFIG_SPARSEMEM=y CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSE_IRQ=y # CONFIG_SPARSE_RCU_POINTER is not set # CONFIG_SPI is not set CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_SQUASHFS is not set # CONFIG_SRAM is not set # CONFIG_SSB is not set CONFIG_SSB_POSSIBLE=y # CONFIG_SSFDC is not set CONFIG_STACKTRACE=y CONFIG_STACKTRACE_SUPPORT=y # CONFIG_STACK_TRACER is not set # CONFIG_STAGING is not set CONFIG_STANDALONE=y # CONFIG_STE10XP is not set # CONFIG_STE_MODEM_RPROC is not set # CONFIG_STMMAC_ETH is not set CONFIG_STOP_MACHINE=y CONFIG_STP=m CONFIG_STRICT_DEVMEM=y # CONFIG_STRIP_ASM_SYMS is not set CONFIG_SUNRPC=y # CONFIG_SUNRPC_DEBUG is not set CONFIG_SUNRPC_GSS=y # CONFIG_SUN_PARTITION is not set CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y # CONFIG_SUSPEND_TIME is not set CONFIG_SWAP=y CONFIG_SWIOTLB=y # CONFIG_SWITCH is not set CONFIG_SWP_EMULATE=y CONFIG_SYN_COOKIES=y CONFIG_SYSCTL=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_SYSFS=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_SYSTEM_TRUSTED_KEYRING is not set # CONFIG_SYSV68_PARTITION is not set CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_SYSV_FS is not set # CONFIG_SYS_HYPERVISOR is not set CONFIG_SYS_SUPPORTS_APM_EMULATION=y # CONFIG_TARGET_CORE is not set # CONFIG_TASKSTATS is not set # CONFIG_TCG_TPM is not set # CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_CUBIC=y # CONFIG_TCP_MD5SIG is not set # CONFIG_TEST_KSTRTOX is not set # CONFIG_TEST_LIST_SORT is not set # CONFIG_TEST_MODULE is not set # CONFIG_TEST_STRING_HELPERS is not set # CONFIG_TEST_USER_COPY is not set CONFIG_THERMAL=y # CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y # CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set # CONFIG_THERMAL_EMULATION is not set # CONFIG_THERMAL_GOV_FAIR_SHARE is not set CONFIG_THERMAL_GOV_STEP_WISE=y # CONFIG_THERMAL_GOV_USER_SPACE is not set CONFIG_THERMAL_HWMON=y CONFIG_THERMAL_OF=y CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11=y CONFIG_THUMB2_KERNEL=y CONFIG_TICK_CPU_ACCOUNTING=y CONFIG_TICK_ONESHOT=y # CONFIG_TIMB_DMA is not set CONFIG_TIMERFD=y CONFIG_TIMER_STATS=y # CONFIG_TIPC is not set # CONFIG_TI_SOC_THERMAL is not set # CONFIG_TI_ST is not set CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_TMPFS_XATTR=y # CONFIG_TOUCHSCREEN_AD7879 is not set # CONFIG_TOUCHSCREEN_ATMEL_MXT is not set # CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set # CONFIG_TOUCHSCREEN_BU21013 is not set # CONFIG_TOUCHSCREEN_CY8CTMG110 is not set # CONFIG_TOUCHSCREEN_CYTTSP4_CORE is not set # CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set # CONFIG_TOUCHSCREEN_DYNAPRO is not set # CONFIG_TOUCHSCREEN_EDT_FT5X06 is not set # CONFIG_TOUCHSCREEN_EETI is not set # CONFIG_TOUCHSCREEN_EGALAX is not set # CONFIG_TOUCHSCREEN_ELO is not set # CONFIG_TOUCHSCREEN_FUJITSU is not set # CONFIG_TOUCHSCREEN_GUNZE is not set # CONFIG_TOUCHSCREEN_HAMPSHIRE is not set # CONFIG_TOUCHSCREEN_ILI210X is not set # CONFIG_TOUCHSCREEN_INEXIO is not set # CONFIG_TOUCHSCREEN_MAX11801 is not set # CONFIG_TOUCHSCREEN_MCS5000 is not set # CONFIG_TOUCHSCREEN_MK712 is not set # CONFIG_TOUCHSCREEN_MMS114 is not set # CONFIG_TOUCHSCREEN_MTOUCH is not set # CONFIG_TOUCHSCREEN_MXT224E is not set # CONFIG_TOUCHSCREEN_PENMOUNT is not set # CONFIG_TOUCHSCREEN_PIXCIR is not set # CONFIG_TOUCHSCREEN_ST1232 is not set # CONFIG_TOUCHSCREEN_SUR40 is not set # CONFIG_TOUCHSCREEN_TOUCHIT213 is not set # CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set # CONFIG_TOUCHSCREEN_TOUCHWIN is not set # CONFIG_TOUCHSCREEN_TPS6507X is not set # CONFIG_TOUCHSCREEN_TSC2007 is not set # CONFIG_TOUCHSCREEN_TSC_SERIO is not set # CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set # CONFIG_TOUCHSCREEN_W90X900 is not set # CONFIG_TOUCHSCREEN_WACOM_I2C is not set # CONFIG_TOUCHSCREEN_WACOM_W8001 is not set # CONFIG_TOUCHSCREEN_ZFORCE is not set # CONFIG_TPS6105X is not set # CONFIG_TPS65010 is not set # CONFIG_TPS6507X is not set CONFIG_TRACEPOINTS=y # CONFIG_TRACER_SNAPSHOT is not set CONFIG_TRACE_CLOCK=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y # CONFIG_TRACE_SINK is not set CONFIG_TRACING=y CONFIG_TRACING_SUPPORT=y CONFIG_TREE_RCU=y # CONFIG_TREE_RCU_TRACE is not set CONFIG_TTY=y # CONFIG_TTY_PRINTK is not set # CONFIG_TUN is not set # CONFIG_TWL4030_CORE is not set # CONFIG_TWL6040_CORE is not set # CONFIG_UACCESS_WITH_MEMCPY is not set # CONFIG_UDF_FS is not set CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" # CONFIG_UFS_FS is not set # CONFIG_UHID is not set CONFIG_UID16=y # CONFIG_UID_STAT is not set # CONFIG_UIO is not set # CONFIG_ULTRIX_PARTITION is not set CONFIG_UNCOMPRESS_INCLUDE="mach/uncompress.h" CONFIG_UNINLINE_SPIN_UNLOCK=y CONFIG_UNIX=y CONFIG_UNIX98_PTYS=y # CONFIG_UNIXWARE_DISKLABEL is not set # CONFIG_UNIX_DIAG is not set # CONFIG_UNUSED_SYMBOLS is not set # CONFIG_UPROBES is not set # CONFIG_UPROBE_EVENT is not set CONFIG_USB=y # CONFIG_USB_ACM is not set # CONFIG_USB_ADUTUX is not set # CONFIG_USB_ALI_M5632 is not set # CONFIG_USB_AN2720 is not set CONFIG_USB_ANNOUNCE_NEW_DEVICES=y # CONFIG_USB_APPLEDISPLAY is not set CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_XHCI=y CONFIG_USB_ARMLINUX=y # CONFIG_USB_AUDIO is not set CONFIG_USB_BELKIN=y # CONFIG_USB_C67X00_HCD is not set # CONFIG_USB_CATC is not set # CONFIG_USB_CDC_COMPOSITE is not set # CONFIG_USB_CHIPIDEA is not set CONFIG_USB_COMMON=y # CONFIG_USB_CONFIGFS is not set # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_DEBUG is not set CONFIG_USB_DEFAULT_PERSIST=y # CONFIG_USB_DUMMY_HCD is not set # CONFIG_USB_DWC2 is not set CONFIG_USB_DWC3=y # CONFIG_USB_DWC3_DEBUG is not set # CONFIG_USB_DWC3_DUAL_ROLE is not set CONFIG_USB_DWC3_EXYNOS=y # CONFIG_USB_DWC3_GADGET is not set CONFIG_USB_DWC3_HOST=y CONFIG_USB_DWC3_KEYSTONE=y CONFIG_USB_DWC3_OMAP=y # CONFIG_USB_DYNAMIC_MINORS is not set CONFIG_USB_EHCI_EXYNOS=y CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_HCD_PLATFORM is not set # CONFIG_USB_EHCI_HCD_SYNOPSYS is not set CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y # CONFIG_USB_EHSET_TEST_FIXTURE is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_EMI62 is not set # CONFIG_USB_EPSON2888 is not set # CONFIG_USB_ETH is not set # CONFIG_USB_EZUSB_FX2 is not set # CONFIG_USB_FOTG210_HCD is not set # CONFIG_USB_FOTG210_UDC is not set # CONFIG_USB_FTDI_ELAN is not set # CONFIG_USB_FUNCTIONFS is not set # CONFIG_USB_FUSB300 is not set # CONFIG_USB_FUSBH200_HCD is not set CONFIG_USB_GADGET=y # CONFIG_USB_GADGETFS is not set # CONFIG_USB_GADGET_DEBUG is not set # CONFIG_USB_GADGET_DEBUG_FILES is not set # CONFIG_USB_GADGET_DEBUG_FS is not set CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2 CONFIG_USB_GADGET_VBUS_DRAW=2 # CONFIG_USB_GPIO_VBUS is not set # CONFIG_USB_GR_UDC is not set # CONFIG_USB_G_ACM_MS is not set # CONFIG_USB_G_DBGP is not set # CONFIG_USB_G_HID is not set # CONFIG_USB_G_MULTI is not set # CONFIG_USB_G_NCM is not set # CONFIG_USB_G_PRINTER is not set # CONFIG_USB_G_SERIAL is not set # CONFIG_USB_HCD_TEST_MODE is not set CONFIG_USB_HID=y # CONFIG_USB_HIDDEV is not set CONFIG_USB_HSIC_USB3503=y # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_IPHETH is not set # CONFIG_USB_ISIGHTFW is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_ISP1301 is not set # CONFIG_USB_ISP1362_HCD is not set # CONFIG_USB_ISP1760_HCD is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_KC2190 is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LD is not set # CONFIG_USB_LED is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_M66592 is not set # CONFIG_USB_MASS_STORAGE is not set # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_MIDI_GADGET is not set # CONFIG_USB_MON is not set # CONFIG_USB_MUSB_HDRC is not set # CONFIG_USB_MV_U3D is not set # CONFIG_USB_MV_UDC is not set # CONFIG_USB_NET2272 is not set CONFIG_USB_NET_AX88179_178A=y CONFIG_USB_NET_AX8817X=y CONFIG_USB_NET_CDCETHER=y # CONFIG_USB_NET_CDC_EEM is not set # CONFIG_USB_NET_CDC_MBIM is not set CONFIG_USB_NET_CDC_NCM=y CONFIG_USB_NET_CDC_SUBSET=y # CONFIG_USB_NET_CX82310_ETH is not set CONFIG_USB_NET_DM9601=y # CONFIG_USB_NET_GL620A is not set # CONFIG_USB_NET_HUAWEI_CDC_NCM is not set # CONFIG_USB_NET_INT51X1 is not set # CONFIG_USB_NET_KALMIA is not set CONFIG_USB_NET_MCS7830=y CONFIG_USB_NET_NET1080=y # CONFIG_USB_NET_PLUSB is not set # CONFIG_USB_NET_QMI_WWAN is not set # CONFIG_USB_NET_RNDIS_HOST is not set # CONFIG_USB_NET_SMSC75XX is not set # CONFIG_USB_NET_SMSC95XX is not set # CONFIG_USB_NET_SR9700 is not set # CONFIG_USB_NET_SR9800 is not set CONFIG_USB_NET_ZAURUS=y CONFIG_USB_OHCI_EXYNOS=y CONFIG_USB_OHCI_HCD=y # CONFIG_USB_OHCI_HCD_PLATFORM is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y # CONFIG_USB_OTG is not set # CONFIG_USB_OTG_BLACKLIST_HUB is not set # CONFIG_USB_OTG_FSM is not set # CONFIG_USB_OTG_WAKELOCK is not set # CONFIG_USB_OTG_WHITELIST is not set # CONFIG_USB_OXU210HP_HCD is not set # CONFIG_USB_PEGASUS is not set CONFIG_USB_PHY=y # CONFIG_USB_PRINTER is not set # CONFIG_USB_PXA27X is not set # CONFIG_USB_R8A66597 is not set # CONFIG_USB_R8A66597_HCD is not set # CONFIG_USB_RCAR_PHY is not set # CONFIG_USB_RENESAS_USBHS is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_RTL8152 is not set # CONFIG_USB_S3C_HSOTG is not set # CONFIG_USB_SERIAL is not set # CONFIG_USB_SEVSEG is not set # CONFIG_USB_SIERRA_NET is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_SL811_HCD is not set CONFIG_USB_STORAGE=y # CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_ENE_UB6250 is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_STORAGE_KARMA is not set # CONFIG_USB_STORAGE_ONETOUCH is not set # CONFIG_USB_STORAGE_REALTEK is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_USBAT is not set CONFIG_USB_SUPPORT=y # CONFIG_USB_SWITCH_FSA9480 is not set # CONFIG_USB_TEST is not set # CONFIG_USB_TMC is not set # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_ULPI is not set CONFIG_USB_USBNET=y # CONFIG_USB_VL600 is not set # CONFIG_USB_WDM is not set # CONFIG_USB_WUSB_CBAF is not set CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_PLATFORM=y # CONFIG_USB_YUREX is not set # CONFIG_USB_ZD1201 is not set # CONFIG_USB_ZERO is not set CONFIG_USE_OF=y CONFIG_VECTORS_BASE=0xffff0000 # CONFIG_VETH is not set # CONFIG_VEXPRESS_CONFIG is not set CONFIG_VFAT_FS=y # CONFIG_VFIO is not set CONFIG_VFP=y CONFIG_VFPv3=y # CONFIG_VGASTATE is not set # CONFIG_VIA_VELOCITY is not set CONFIG_VIDEOMODE_HELPERS=y # CONFIG_VIDEO_OUTPUT_CONTROL is not set # CONFIG_VIRTIO_MMIO is not set # CONFIG_VIRTUALIZATION is not set # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_VIRT_DRIVERS is not set # CONFIG_VITESSE_PHY is not set # CONFIG_VLAN_8021Q is not set # CONFIG_VMSPLIT_1G is not set # CONFIG_VMSPLIT_2G is not set CONFIG_VMSPLIT_3G=y CONFIG_VM_EVENT_COUNTERS=y # CONFIG_VSOCKETS is not set CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_VT_CONSOLE_SLEEP=y CONFIG_VT_HW_CONSOLE_BINDING=y # CONFIG_VXFS_FS is not set # CONFIG_VXLAN is not set # CONFIG_W1 is not set CONFIG_WAKELOCK=y # CONFIG_WAN is not set # CONFIG_WATCHDOG is not set # CONFIG_WIFI_CONTROL_FUNC is not set # CONFIG_WIMAX is not set CONFIG_WIRELESS=y # CONFIG_WIZNET_W5100 is not set # CONFIG_WIZNET_W5300 is not set CONFIG_WLAN=y # CONFIG_WL_TI is not set # CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set # CONFIG_X25 is not set # CONFIG_XEN is not set CONFIG_XFRM=y CONFIG_XFRM_ALGO=y CONFIG_XFRM_MIGRATE=y # CONFIG_XFRM_STATISTICS is not set # CONFIG_XFRM_SUB_POLICY is not set CONFIG_XFRM_USER=y # CONFIG_XFS_FS is not set # CONFIG_XIP_KERNEL is not set CONFIG_XOR_BLOCKS=y CONFIG_XPS=y # CONFIG_XZ_DEC is not set # CONFIG_XZ_DEC_BCJ is not set CONFIG_ZBOOT_ROM_BSS=0 CONFIG_ZBOOT_ROM_TEXT=0 # CONFIG_ZBUD is not set CONFIG_ZLIB_DEFLATE=y CONFIG_ZLIB_INFLATE=y CONFIG_ZONE_DMA_FLAG=0 ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators 2014-09-29 12:31 ` Bartlomiej Zolnierkiewicz @ 2014-09-30 5:23 ` Jaehoon Chung 2014-10-01 13:57 ` Bartlomiej Zolnierkiewicz 2014-09-30 17:22 ` Doug Anderson 1 sibling, 1 reply; 43+ messages in thread From: Jaehoon Chung @ 2014-09-30 5:23 UTC (permalink / raw) To: linux-arm-kernel Hi On 09/29/2014 09:31 PM, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Friday, August 29, 2014 01:34:44 PM Ulf Hansson wrote: >> On 22 August 2014 15:47, 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> >> >> Thanks! Applied for next. > > Unfortunately this patch breaks mmc1 card (Kingston 32GB micro SDHC) > detection on Exynos5420 Arndale Octa for me: > > [ 10.797979] dwmmc_exynos 12220000.mmc: no support for card's volts > [ 10.797998] mmc1: error -22 whilst initialising SD card OCR value is not matched. Which values are supported about the mmc_host's value and card's value? Could you share the value? Best Regards, Jaehoon Chung > > Without the patch: > > [ 10.866926] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0) > [ 10.866977] mmc1: new high speed SDHC card at address 1234 > [ 10.868730] mmcblk1: mmc1:1234 SA32G 29.3 GiB > [ 10.915054] mmcblk1: p1 p2 p3 > > The config is attached (exynos_defconfig doesn't work correctly for > this board yet). > > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R&D Institute Poland > Samsung Electronics > >> Kind regards >> Uffe >> >>> --- >>> changes from v1: >>> 1.Used mmc_regulator_set_ocr() instead of regulator_enable() for vmmc. >>> 2.Turned on vmmc and vqmmc during MMC_POWER_UP. >>> 3. Removed the flags DW_MMC_CARD_POWERED and DW_MMC_IO_POWERED which >>> added during the initial version of this patch. >>> 4. Added error message, if it failed to turn on regulator's. >>> >>> drivers/mmc/host/dw_mmc.c | 72 +++++++++++++++++++++----------------------- >>> include/linux/mmc/dw_mmc.h | 2 +- >>> 2 files changed, 36 insertions(+), 38 deletions(-) >>> >>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c >>> index 7f227e9..aadb0d6 100644 >>> --- a/drivers/mmc/host/dw_mmc.c >>> +++ b/drivers/mmc/host/dw_mmc.c >>> @@ -936,6 +936,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: >>> @@ -974,12 +975,38 @@ 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)) { >>> + ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, >>> + ios->vdd); >>> + if (ret) { >>> + dev_err(slot->host->dev, >>> + "failed to enable vmmc regulator\n"); >>> + /*return, if failed turn on vmmc*/ >>> + return; >>> + } >>> + } >>> + if (!IS_ERR(mmc->supply.vqmmc) && !slot->host->vqmmc_enabled) { >>> + ret = regulator_enable(mmc->supply.vqmmc); >>> + if (ret < 0) >>> + dev_err(slot->host->dev, >>> + "failed to enable vqmmc regulator\n"); >>> + else >>> + slot->host->vqmmc_enabled = true; >>> + } >>> 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.vmmc)) >>> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0); >>> + >>> + if (!IS_ERR(mmc->supply.vqmmc) && slot->host->vqmmc_enabled) { >>> + regulator_disable(mmc->supply.vqmmc); >>> + slot->host->vqmmc_enabled = false; >>> + } >>> + >>> regs = mci_readl(slot->host, PWREN); >>> regs &= ~(1 << slot->id); >>> mci_writel(slot->host, PWREN, regs); >>> @@ -2110,7 +2137,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; >>> @@ -2176,7 +2209,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) >>> @@ -2469,24 +2502,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); >>> @@ -2630,8 +2645,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)) >>> @@ -2667,9 +2680,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); >>> >>> @@ -2686,9 +2696,6 @@ EXPORT_SYMBOL(dw_mci_remove); >>> */ >>> int dw_mci_suspend(struct dw_mci *host) >>> { >>> - if (host->vmmc) >>> - regulator_disable(host->vmmc); >>> - >>> return 0; >>> } >>> EXPORT_SYMBOL(dw_mci_suspend); >>> @@ -2697,15 +2704,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_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS)) { >>> ret = -ENODEV; >>> return ret; >>> diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h >>> index 29ce014..84e2827 100644 >>> --- a/include/linux/mmc/dw_mmc.h >>> +++ b/include/linux/mmc/dw_mmc.h >>> @@ -188,7 +188,7 @@ struct dw_mci { >>> /* Workaround flags */ >>> u32 quirks; >>> >>> - struct regulator *vmmc; /* Power regulator */ >>> + bool vqmmc_enabled; >>> unsigned long irq_flags; /* IRQ flags */ >>> int irq; >>> }; >>> -- >>> 1.7.10.4 ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators 2014-09-30 5:23 ` Jaehoon Chung @ 2014-10-01 13:57 ` Bartlomiej Zolnierkiewicz 2014-10-01 14:14 ` Bartlomiej Zolnierkiewicz 0 siblings, 1 reply; 43+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2014-10-01 13:57 UTC (permalink / raw) To: linux-arm-kernel Hi, On Tuesday, September 30, 2014 02:23:44 PM Jaehoon Chung wrote: > Hi > > On 09/29/2014 09:31 PM, Bartlomiej Zolnierkiewicz wrote: > > > > Hi, > > > > On Friday, August 29, 2014 01:34:44 PM Ulf Hansson wrote: > >> On 22 August 2014 15:47, 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> > >> > >> Thanks! Applied for next. > > > > Unfortunately this patch breaks mmc1 card (Kingston 32GB micro SDHC) > > detection on Exynos5420 Arndale Octa for me: > > > > [ 10.797979] dwmmc_exynos 12220000.mmc: no support for card's volts > > [ 10.797998] mmc1: error -22 whilst initialising SD card > > OCR value is not matched. Which values are supported about the mmc_host's value and card's value? > Could you share the value? Sure. I've added dev_info()s at the beginning of mmc_select_voltage(): + dev_warn(mmc_dev(host), "card's volts: 0x%0x\n", ocr); + dev_warn(mmc_dev(host), "host's volts: 0x%0x\n", host->ocr_avail); and got following results: [ 10.851678] dwmmc_exynos 12220000.mmc: card's volts: 0xff8000 [ 10.851691] dwmmc_exynos 12220000.mmc: host's volts: 0x80 Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > Best Regards, > Jaehoon Chung > > > > > Without the patch: > > > > [ 10.866926] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0) > > [ 10.866977] mmc1: new high speed SDHC card at address 1234 > > [ 10.868730] mmcblk1: mmc1:1234 SA32G 29.3 GiB > > [ 10.915054] mmcblk1: p1 p2 p3 > > > > The config is attached (exynos_defconfig doesn't work correctly for > > this board yet). > > > > Best regards, > > -- > > Bartlomiej Zolnierkiewicz > > Samsung R&D Institute Poland > > Samsung Electronics > > > >> Kind regards > >> Uffe > >> > >>> --- > >>> changes from v1: > >>> 1.Used mmc_regulator_set_ocr() instead of regulator_enable() for vmmc. > >>> 2.Turned on vmmc and vqmmc during MMC_POWER_UP. > >>> 3. Removed the flags DW_MMC_CARD_POWERED and DW_MMC_IO_POWERED which > >>> added during the initial version of this patch. > >>> 4. Added error message, if it failed to turn on regulator's. > >>> > >>> drivers/mmc/host/dw_mmc.c | 72 +++++++++++++++++++++----------------------- > >>> include/linux/mmc/dw_mmc.h | 2 +- > >>> 2 files changed, 36 insertions(+), 38 deletions(-) > >>> > >>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c > >>> index 7f227e9..aadb0d6 100644 > >>> --- a/drivers/mmc/host/dw_mmc.c > >>> +++ b/drivers/mmc/host/dw_mmc.c > >>> @@ -936,6 +936,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: > >>> @@ -974,12 +975,38 @@ 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)) { > >>> + ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, > >>> + ios->vdd); > >>> + if (ret) { > >>> + dev_err(slot->host->dev, > >>> + "failed to enable vmmc regulator\n"); > >>> + /*return, if failed turn on vmmc*/ > >>> + return; > >>> + } > >>> + } > >>> + if (!IS_ERR(mmc->supply.vqmmc) && !slot->host->vqmmc_enabled) { > >>> + ret = regulator_enable(mmc->supply.vqmmc); > >>> + if (ret < 0) > >>> + dev_err(slot->host->dev, > >>> + "failed to enable vqmmc regulator\n"); > >>> + else > >>> + slot->host->vqmmc_enabled = true; > >>> + } > >>> 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.vmmc)) > >>> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0); > >>> + > >>> + if (!IS_ERR(mmc->supply.vqmmc) && slot->host->vqmmc_enabled) { > >>> + regulator_disable(mmc->supply.vqmmc); > >>> + slot->host->vqmmc_enabled = false; > >>> + } > >>> + > >>> regs = mci_readl(slot->host, PWREN); > >>> regs &= ~(1 << slot->id); > >>> mci_writel(slot->host, PWREN, regs); > >>> @@ -2110,7 +2137,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; > >>> @@ -2176,7 +2209,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) > >>> @@ -2469,24 +2502,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); > >>> @@ -2630,8 +2645,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)) > >>> @@ -2667,9 +2680,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); > >>> > >>> @@ -2686,9 +2696,6 @@ EXPORT_SYMBOL(dw_mci_remove); > >>> */ > >>> int dw_mci_suspend(struct dw_mci *host) > >>> { > >>> - if (host->vmmc) > >>> - regulator_disable(host->vmmc); > >>> - > >>> return 0; > >>> } > >>> EXPORT_SYMBOL(dw_mci_suspend); > >>> @@ -2697,15 +2704,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_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS)) { > >>> ret = -ENODEV; > >>> return ret; > >>> diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h > >>> index 29ce014..84e2827 100644 > >>> --- a/include/linux/mmc/dw_mmc.h > >>> +++ b/include/linux/mmc/dw_mmc.h > >>> @@ -188,7 +188,7 @@ struct dw_mci { > >>> /* Workaround flags */ > >>> u32 quirks; > >>> > >>> - struct regulator *vmmc; /* Power regulator */ > >>> + bool vqmmc_enabled; > >>> unsigned long irq_flags; /* IRQ flags */ > >>> int irq; > >>> }; > >>> -- > >>> 1.7.10.4 ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators 2014-10-01 13:57 ` Bartlomiej Zolnierkiewicz @ 2014-10-01 14:14 ` Bartlomiej Zolnierkiewicz 0 siblings, 0 replies; 43+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2014-10-01 14:14 UTC (permalink / raw) To: linux-arm-kernel On Wednesday, October 01, 2014 03:57:54 PM Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Tuesday, September 30, 2014 02:23:44 PM Jaehoon Chung wrote: > > Hi > > > > On 09/29/2014 09:31 PM, Bartlomiej Zolnierkiewicz wrote: > > > > > > Hi, > > > > > > On Friday, August 29, 2014 01:34:44 PM Ulf Hansson wrote: > > >> On 22 August 2014 15:47, 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> > > >> > > >> Thanks! Applied for next. > > > > > > Unfortunately this patch breaks mmc1 card (Kingston 32GB micro SDHC) > > > detection on Exynos5420 Arndale Octa for me: > > > > > > [ 10.797979] dwmmc_exynos 12220000.mmc: no support for card's volts > > > [ 10.797998] mmc1: error -22 whilst initialising SD card > > > > OCR value is not matched. Which values are supported about the mmc_host's value and card's value? > > Could you share the value? > > Sure. I've added dev_info()s at the beginning of mmc_select_voltage(): > > + dev_warn(mmc_dev(host), "card's volts: 0x%0x\n", ocr); > + dev_warn(mmc_dev(host), "host's volts: 0x%0x\n", host->ocr_avail); > > and got following results: > > [ 10.851678] dwmmc_exynos 12220000.mmc: card's volts: 0xff8000 > [ 10.851691] dwmmc_exynos 12220000.mmc: host's volts: 0x80 Data for the working kernel: [ 10.856214] dwmmc_exynos 12220000.mmc: card's volts: 0xff8000 [ 10.856227] dwmmc_exynos 12220000.mmc: host's volts: 0x300000 Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R&D Institute Poland > Samsung Electronics > > > Best Regards, > > Jaehoon Chung > > > > > > > > Without the patch: > > > > > > [ 10.866926] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0) > > > [ 10.866977] mmc1: new high speed SDHC card at address 1234 > > > [ 10.868730] mmcblk1: mmc1:1234 SA32G 29.3 GiB > > > [ 10.915054] mmcblk1: p1 p2 p3 > > > > > > The config is attached (exynos_defconfig doesn't work correctly for > > > this board yet). > > > > > > Best regards, > > > -- > > > Bartlomiej Zolnierkiewicz > > > Samsung R&D Institute Poland > > > Samsung Electronics > > > > > >> Kind regards > > >> Uffe > > >> > > >>> --- > > >>> changes from v1: > > >>> 1.Used mmc_regulator_set_ocr() instead of regulator_enable() for vmmc. > > >>> 2.Turned on vmmc and vqmmc during MMC_POWER_UP. > > >>> 3. Removed the flags DW_MMC_CARD_POWERED and DW_MMC_IO_POWERED which > > >>> added during the initial version of this patch. > > >>> 4. Added error message, if it failed to turn on regulator's. > > >>> > > >>> drivers/mmc/host/dw_mmc.c | 72 +++++++++++++++++++++----------------------- > > >>> include/linux/mmc/dw_mmc.h | 2 +- > > >>> 2 files changed, 36 insertions(+), 38 deletions(-) > > >>> > > >>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c > > >>> index 7f227e9..aadb0d6 100644 > > >>> --- a/drivers/mmc/host/dw_mmc.c > > >>> +++ b/drivers/mmc/host/dw_mmc.c > > >>> @@ -936,6 +936,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: > > >>> @@ -974,12 +975,38 @@ 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)) { > > >>> + ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, > > >>> + ios->vdd); > > >>> + if (ret) { > > >>> + dev_err(slot->host->dev, > > >>> + "failed to enable vmmc regulator\n"); > > >>> + /*return, if failed turn on vmmc*/ > > >>> + return; > > >>> + } > > >>> + } > > >>> + if (!IS_ERR(mmc->supply.vqmmc) && !slot->host->vqmmc_enabled) { > > >>> + ret = regulator_enable(mmc->supply.vqmmc); > > >>> + if (ret < 0) > > >>> + dev_err(slot->host->dev, > > >>> + "failed to enable vqmmc regulator\n"); > > >>> + else > > >>> + slot->host->vqmmc_enabled = true; > > >>> + } > > >>> 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.vmmc)) > > >>> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0); > > >>> + > > >>> + if (!IS_ERR(mmc->supply.vqmmc) && slot->host->vqmmc_enabled) { > > >>> + regulator_disable(mmc->supply.vqmmc); > > >>> + slot->host->vqmmc_enabled = false; > > >>> + } > > >>> + > > >>> regs = mci_readl(slot->host, PWREN); > > >>> regs &= ~(1 << slot->id); > > >>> mci_writel(slot->host, PWREN, regs); > > >>> @@ -2110,7 +2137,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; > > >>> @@ -2176,7 +2209,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) > > >>> @@ -2469,24 +2502,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); > > >>> @@ -2630,8 +2645,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)) > > >>> @@ -2667,9 +2680,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); > > >>> > > >>> @@ -2686,9 +2696,6 @@ EXPORT_SYMBOL(dw_mci_remove); > > >>> */ > > >>> int dw_mci_suspend(struct dw_mci *host) > > >>> { > > >>> - if (host->vmmc) > > >>> - regulator_disable(host->vmmc); > > >>> - > > >>> return 0; > > >>> } > > >>> EXPORT_SYMBOL(dw_mci_suspend); > > >>> @@ -2697,15 +2704,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_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS)) { > > >>> ret = -ENODEV; > > >>> return ret; > > >>> diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h > > >>> index 29ce014..84e2827 100644 > > >>> --- a/include/linux/mmc/dw_mmc.h > > >>> +++ b/include/linux/mmc/dw_mmc.h > > >>> @@ -188,7 +188,7 @@ struct dw_mci { > > >>> /* Workaround flags */ > > >>> u32 quirks; > > >>> > > >>> - struct regulator *vmmc; /* Power regulator */ > > >>> + bool vqmmc_enabled; > > >>> unsigned long irq_flags; /* IRQ flags */ > > >>> int irq; > > >>> }; > > >>> -- > > >>> 1.7.10.4 ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators 2014-09-29 12:31 ` Bartlomiej Zolnierkiewicz 2014-09-30 5:23 ` Jaehoon Chung @ 2014-09-30 17:22 ` Doug Anderson 2014-10-01 13:06 ` Bartlomiej Zolnierkiewicz 1 sibling, 1 reply; 43+ messages in thread From: Doug Anderson @ 2014-09-30 17:22 UTC (permalink / raw) To: linux-arm-kernel Bartlomiej On Mon, Sep 29, 2014 at 5:31 AM, Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> wrote: > > Hi, > > On Friday, August 29, 2014 01:34:44 PM Ulf Hansson wrote: >> On 22 August 2014 15:47, 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> >> >> Thanks! Applied for next. > > Unfortunately this patch breaks mmc1 card (Kingston 32GB micro SDHC) > detection on Exynos5420 Arndale Octa for me: > > [ 10.797979] dwmmc_exynos 12220000.mmc: no support for card's volts > [ 10.797998] mmc1: error -22 whilst initialising SD card > > Without the patch: > > [ 10.866926] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0) > [ 10.866977] mmc1: new high speed SDHC card at address 1234 > [ 10.868730] mmcblk1: mmc1:1234 SA32G 29.3 GiB > [ 10.915054] mmcblk1: p1 p2 p3 > > The config is attached (exynos_defconfig doesn't work correctly for > this board yet). Yup, this is an expected behavior, unfortunately. This was talked about extensively during the review of this patch series. I believe that patch #3 in Yuvaraj's series would fix your problem. Specifically <https://patchwork.kernel.org/patch/4763891/>. The current summary of this issue is (Ulf, please correct me if I got anything wrong): 1. If nothing else, Yuvaraj's patch should probably be split in two. One half should be the MMC core half that I originally sent Yuvaraj. I just rebased and re-uploaed it at <https://chromium-review.googlesource.com/220560> in case you're curious. The second half should be the dw_mmc piece that Yuvaraj wrote. 2. Ulf has indicated that he thinks that the MMC core change (and thus Yuvaraj's patch) is ugly and not necessary. He advocates instead using the MMC_CAP_NEEDS_POLL on all affected platforms. That means we'll turn on the power every second, check for the card, then turn off power. 3. I'm still of the opinion that the MMC core change isn't _that_ ugly. Given that there are a large number of systems affected (across at least two SoC vendors) and that it would be nice if those systems didn't have to poll, I'd still be happy if the MMC core change could go in. ...but I'm a pragmatist and know that the polling isn't _terrible_, so if that's the way we need to go then so be it. -- My understanding was that Yuvaraj was going to spin his patch to use a similar type of scheme to autodetect affected SoCs (looking for SoCs known to have this problem where the platform data shows them using the built-in card detect) and then enable MMC_CAP_NEEDS_POLL. I haven't seen a patch from him, so maybe you could post this up? Note: the reason why exynos5250-snow and some other boards aren't affected yet is that the regulator is simply not specified in the device tree (it's just left always on). --- -Doug ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators 2014-09-30 17:22 ` Doug Anderson @ 2014-10-01 13:06 ` Bartlomiej Zolnierkiewicz 2014-10-01 15:38 ` Doug Anderson 0 siblings, 1 reply; 43+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2014-10-01 13:06 UTC (permalink / raw) To: linux-arm-kernel Hi, On Tuesday, September 30, 2014 10:22:34 AM Doug Anderson wrote: > Bartlomiej > > On Mon, Sep 29, 2014 at 5:31 AM, Bartlomiej Zolnierkiewicz > <b.zolnierkie@samsung.com> wrote: > > > > Hi, > > > > On Friday, August 29, 2014 01:34:44 PM Ulf Hansson wrote: > >> On 22 August 2014 15:47, 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> > >> > >> Thanks! Applied for next. > > > > Unfortunately this patch breaks mmc1 card (Kingston 32GB micro SDHC) > > detection on Exynos5420 Arndale Octa for me: > > > > [ 10.797979] dwmmc_exynos 12220000.mmc: no support for card's volts > > [ 10.797998] mmc1: error -22 whilst initialising SD card > > > > Without the patch: > > > > [ 10.866926] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0) > > [ 10.866977] mmc1: new high speed SDHC card at address 1234 > > [ 10.868730] mmcblk1: mmc1:1234 SA32G 29.3 GiB > > [ 10.915054] mmcblk1: p1 p2 p3 > > > > The config is attached (exynos_defconfig doesn't work correctly for > > this board yet). > > Yup, this is an expected behavior, unfortunately. This was talked > about extensively during the review of this patch series. Do you mean that a patch with a known regression has been merged into next branch of mmc tree? It would be quite sad if it would be true. > I believe that patch #3 in Yuvaraj's series would fix your problem. > Specifically <https://patchwork.kernel.org/patch/4763891/>. Unfortunately this patch doesn't fix the problem (there is no longer a lockup on regulators initialization but -22 error is still present). > The current summary of this issue is (Ulf, please correct me if I got > anything wrong): > > 1. If nothing else, Yuvaraj's patch should probably be split in two. > One half should be the MMC core half that I originally sent Yuvaraj. > I just rebased and re-uploaed it at > <https://chromium-review.googlesource.com/220560> in case you're > curious. The second half should be the dw_mmc piece that Yuvaraj > wrote. > > 2. Ulf has indicated that he thinks that the MMC core change (and thus > Yuvaraj's patch) is ugly and not necessary. He advocates instead > using the MMC_CAP_NEEDS_POLL on all affected platforms. That means > we'll turn on the power every second, check for the card, then turn > off power. > > 3. I'm still of the opinion that the MMC core change isn't _that_ > ugly. Given that there are a large number of systems affected (across It also doesn't look that bad for me and well, when the hardware is quirky then the resulting code can't be esthetically perfect.. > at least two SoC vendors) and that it would be nice if those systems > didn't have to poll, I'd still be happy if the MMC core change could > go in. ...but I'm a pragmatist and know that the polling isn't > _terrible_, so if that's the way we need to go then so be it. > > -- > > My understanding was that Yuvaraj was going to spin his patch to use a > similar type of scheme to autodetect affected SoCs (looking for SoCs > known to have this problem where the platform data shows them using > the built-in card detect) and then enable MMC_CAP_NEEDS_POLL. I > haven't seen a patch from him, so maybe you could post this up? I worry that I have too little time and MMC code expertise to do this. > Note: the reason why exynos5250-snow and some other boards aren't > affected yet is that the regulator is simply not specified in the > device tree (it's just left always on). Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators 2014-10-01 13:06 ` Bartlomiej Zolnierkiewicz @ 2014-10-01 15:38 ` Doug Anderson 0 siblings, 0 replies; 43+ messages in thread From: Doug Anderson @ 2014-10-01 15:38 UTC (permalink / raw) To: linux-arm-kernel Hi, On Wed, Oct 1, 2014 at 6:06 AM, Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> wrote: > > Hi, > > On Tuesday, September 30, 2014 10:22:34 AM Doug Anderson wrote: >> Bartlomiej >> >> On Mon, Sep 29, 2014 at 5:31 AM, Bartlomiej Zolnierkiewicz >> <b.zolnierkie@samsung.com> wrote: >> > >> > Hi, >> > >> > On Friday, August 29, 2014 01:34:44 PM Ulf Hansson wrote: >> >> On 22 August 2014 15:47, 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> >> >> >> >> Thanks! Applied for next. >> > >> > Unfortunately this patch breaks mmc1 card (Kingston 32GB micro SDHC) >> > detection on Exynos5420 Arndale Octa for me: >> > >> > [ 10.797979] dwmmc_exynos 12220000.mmc: no support for card's volts >> > [ 10.797998] mmc1: error -22 whilst initialising SD card >> > >> > Without the patch: >> > >> > [ 10.866926] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0) >> > [ 10.866977] mmc1: new high speed SDHC card at address 1234 >> > [ 10.868730] mmcblk1: mmc1:1234 SA32G 29.3 GiB >> > [ 10.915054] mmcblk1: p1 p2 p3 >> > >> > The config is attached (exynos_defconfig doesn't work correctly for >> > this board yet). >> >> Yup, this is an expected behavior, unfortunately. This was talked >> about extensively during the review of this patch series. > > Do you mean that a patch with a known regression has been merged > into next branch of mmc tree? It would be quite sad if it would be > true. ...so looking at your "dts" file, it looks like this _isn't_ your problem. Your "vmmc" regulator is listed as "always on", so I believe that you're OK. Your regulator probably _shouldn't_ be "always on" (it prevents power cycling the SD card) but right now it's good that it is... If any board has a "vmmc" that is not listed as always on then it would regress with the first two patches applied (and without the 3rd), but there are none that I personally know of that do. ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 2/3] mmc: dw_mmc: Support voltage changes 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-22 13:47 ` Yuvaraj Kumar C D 2014-08-22 15:35 ` Ulf Hansson 2014-08-22 13:47 ` [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc Yuvaraj Kumar C D 2 siblings, 1 reply; 43+ messages in thread From: Yuvaraj Kumar C D @ 2014-08-22 13:47 UTC (permalink / raw) To: linux-arm-kernel 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(). + */ + clk_en_a = mci_readl(host, CLKENA); + clk_en_a &= ~(SDMMC_CLKEN_LOW_PWR << slot->id); + mci_writel(host, CLKENA, clk_en_a); + mci_send_cmd(slot, SDMMC_CMD_UPD_CLK | + SDMMC_CMD_PRV_DAT_WAIT, 0); + } + if (cmd->flags & MMC_RSP_PRESENT) { /* We expect a response, so set this bit */ cmdr |= SDMMC_CMD_RESP_EXP; @@ -775,11 +804,15 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit) unsigned int clock = slot->clock; u32 div; u32 clk_en_a; + u32 sdmmc_cmd_bits = SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT; + + /* We must continue to set bit 28 in CMD until the change is complete */ + if (host->state == STATE_WAITING_CMD11_DONE) + sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH; if (!clock) { mci_writel(host, CLKENA, 0); - mci_send_cmd(slot, - SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0); + mci_send_cmd(slot, sdmmc_cmd_bits, 0); } else if (clock != host->current_speed || force_clkinit) { div = host->bus_hz / clock; if (host->bus_hz % clock && host->bus_hz > clock) @@ -803,15 +836,13 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit) mci_writel(host, CLKSRC, 0); /* inform CIU */ - mci_send_cmd(slot, - SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0); + mci_send_cmd(slot, sdmmc_cmd_bits, 0); /* set clock to desired speed */ mci_writel(host, CLKDIV, div); /* inform CIU */ - mci_send_cmd(slot, - SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0); + mci_send_cmd(slot, sdmmc_cmd_bits, 0); /* enable clock; only low power if no SDIO */ clk_en_a = SDMMC_CLKEN_ENABLE << slot->id; @@ -820,8 +851,7 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit) mci_writel(host, CLKENA, clk_en_a); /* inform CIU */ - mci_send_cmd(slot, - SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0); + mci_send_cmd(slot, sdmmc_cmd_bits, 0); /* keep the clock with reflecting clock dividor */ slot->__clk_old = clock << div; @@ -897,6 +927,17 @@ static void dw_mci_queue_request(struct dw_mci *host, struct dw_mci_slot *slot, slot->mrq = mrq; + if (host->state == STATE_WAITING_CMD11_DONE) { + dev_warn(&slot->mmc->class_dev, + "Voltage change didn't complete\n"); + /* + * this case isn't expected to happen, so we can + * either crash here or just try to continue on + * in the closest possible state + */ + host->state = STATE_IDLE; + } + if (host->state == STATE_IDLE) { host->state = STATE_SENDING_CMD; dw_mci_start_request(host, slot); @@ -973,6 +1014,9 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) /* Slot specific timing and width adjustment */ dw_mci_setup_bus(slot, false); + if (slot->host->state == STATE_WAITING_CMD11_DONE && ios->clock != 0) + slot->host->state = STATE_IDLE; + switch (ios->power_mode) { case MMC_POWER_UP: if (!IS_ERR(mmc->supply.vmmc)) { @@ -1016,6 +1060,59 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) } } +static int dw_mci_card_busy(struct mmc_host *mmc) +{ + struct dw_mci_slot *slot = mmc_priv(mmc); + u32 status; + + /* + * Check the busy bit which is low when DAT[3:0] + * (the data lines) are 0000 + */ + status = mci_readl(slot->host, STATUS); + + return !!(status & SDMMC_STATUS_BUSY); +} + +static int dw_mci_switch_voltage(struct mmc_host *mmc, struct mmc_ios *ios) +{ + struct dw_mci_slot *slot = mmc_priv(mmc); + struct dw_mci *host = slot->host; + u32 uhs; + u32 v18 = SDMMC_UHS_18V << slot->id; + int min_uv, max_uv; + int ret; + + /* + * Program the voltage. Note that some instances of dw_mmc may use + * the UHS_REG for this. For other instances (like exynos) the UHS_REG + * does no harm but you need to set the regulator directly. Try both. + */ + uhs = mci_readl(host, UHS_REG); + if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_330) { + min_uv = 2700000; + max_uv = 3600000; + uhs &= ~v18; + } else { + min_uv = 1700000; + max_uv = 1950000; + uhs |= v18; + } + if (!IS_ERR(mmc->supply.vqmmc)) { + ret = regulator_set_voltage(mmc->supply.vqmmc, min_uv, max_uv); + + if (ret) { + dev_err(&mmc->class_dev, + "Regulator set error %d: %d - %d\n", + ret, min_uv, max_uv); + return ret; + } + } + mci_writel(host, UHS_REG, uhs); + + return 0; +} + static int dw_mci_get_ro(struct mmc_host *mmc) { int read_only; @@ -1158,6 +1255,9 @@ static const struct mmc_host_ops dw_mci_ops = { .get_cd = dw_mci_get_cd, .enable_sdio_irq = dw_mci_enable_sdio_irq, .execute_tuning = dw_mci_execute_tuning, + .card_busy = dw_mci_card_busy, + .start_signal_voltage_switch = dw_mci_switch_voltage, + }; static void dw_mci_request_end(struct dw_mci *host, struct mmc_request *mrq) @@ -1181,7 +1281,11 @@ static void dw_mci_request_end(struct dw_mci *host, struct mmc_request *mrq) dw_mci_start_request(host, slot); } else { dev_vdbg(host->dev, "list empty\n"); - host->state = STATE_IDLE; + + if (host->state == STATE_SENDING_CMD11) + host->state = STATE_WAITING_CMD11_DONE; + else + host->state = STATE_IDLE; } spin_unlock(&host->lock); @@ -1292,8 +1396,10 @@ static void dw_mci_tasklet_func(unsigned long priv) switch (state) { case STATE_IDLE: + case STATE_WAITING_CMD11_DONE: break; + case STATE_SENDING_CMD11: case STATE_SENDING_CMD: if (!test_and_clear_bit(EVENT_CMD_COMPLETE, &host->pending_events)) @@ -1894,6 +2000,14 @@ static irqreturn_t dw_mci_interrupt(int irq, void *dev_id) } if (pending) { + /* Check volt switch first, since it can look like an error */ + if ((host->state == STATE_SENDING_CMD11) && + (pending & SDMMC_INT_VOLT_SWITCH)) { + mci_writel(host, RINTSTS, SDMMC_INT_VOLT_SWITCH); + pending &= ~SDMMC_INT_VOLT_SWITCH; + dw_mci_cmd_interrupt(host, pending); + } + if (pending & DW_MCI_CMD_ERROR_FLAGS) { mci_writel(host, RINTSTS, DW_MCI_CMD_ERROR_FLAGS); host->cmd_status = pending; @@ -1999,7 +2113,9 @@ static void dw_mci_work_routine_card(struct work_struct *work) switch (host->state) { case STATE_IDLE: + case STATE_WAITING_CMD11_DONE: break; + case STATE_SENDING_CMD11: case STATE_SENDING_CMD: mrq->cmd->error = -ENOMEDIUM; if (!mrq->data) diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h index 08fd956..01b99e8 100644 --- a/drivers/mmc/host/dw_mmc.h +++ b/drivers/mmc/host/dw_mmc.h @@ -99,6 +99,7 @@ #define SDMMC_INT_HLE BIT(12) #define SDMMC_INT_FRUN BIT(11) #define SDMMC_INT_HTO BIT(10) +#define SDMMC_INT_VOLT_SWITCH BIT(10) /* overloads bit 10! */ #define SDMMC_INT_DRTO BIT(9) #define SDMMC_INT_RTO BIT(8) #define SDMMC_INT_DCRC BIT(7) @@ -113,6 +114,7 @@ /* Command register defines */ #define SDMMC_CMD_START BIT(31) #define SDMMC_CMD_USE_HOLD_REG BIT(29) +#define SDMMC_CMD_VOLT_SWITCH BIT(28) #define SDMMC_CMD_CCS_EXP BIT(23) #define SDMMC_CMD_CEATA_RD BIT(22) #define SDMMC_CMD_UPD_CLK BIT(21) @@ -130,6 +132,7 @@ /* Status register defines */ #define SDMMC_GET_FCNT(x) (((x)>>17) & 0x1FFF) #define SDMMC_STATUS_DMA_REQ BIT(31) +#define SDMMC_STATUS_BUSY BIT(9) /* FIFOTH register defines */ #define SDMMC_SET_FIFOTH(m, r, t) (((m) & 0x7) << 28 | \ ((r) & 0xFFF) << 16 | \ @@ -150,7 +153,7 @@ #define SDMMC_GET_VERID(x) ((x) & 0xFFFF) /* Card read threshold */ #define SDMMC_SET_RD_THLD(v, x) (((v) & 0x1FFF) << 16 | (x)) - +#define SDMMC_UHS_18V BIT(0) /* All ctrl reset bits */ #define SDMMC_CTRL_ALL_RESET_FLAGS \ (SDMMC_CTRL_RESET | SDMMC_CTRL_FIFO_RESET | SDMMC_CTRL_DMA_RESET) diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h index 84e2827..0013669 100644 --- a/include/linux/mmc/dw_mmc.h +++ b/include/linux/mmc/dw_mmc.h @@ -26,6 +26,8 @@ enum dw_mci_state { STATE_DATA_BUSY, STATE_SENDING_STOP, STATE_DATA_ERROR, + STATE_SENDING_CMD11, + STATE_WAITING_CMD11_DONE, }; enum { -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH V2 2/3] mmc: dw_mmc: Support voltage changes 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 0 siblings, 1 reply; 43+ messages in thread From: Ulf Hansson @ 2014-08-22 15:35 UTC (permalink / raw) To: linux-arm-kernel 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? Kind regards Uffe > + clk_en_a = mci_readl(host, CLKENA); > + clk_en_a &= ~(SDMMC_CLKEN_LOW_PWR << slot->id); > + mci_writel(host, CLKENA, clk_en_a); > + mci_send_cmd(slot, SDMMC_CMD_UPD_CLK | > + SDMMC_CMD_PRV_DAT_WAIT, 0); > + } > + > if (cmd->flags & MMC_RSP_PRESENT) { > /* We expect a response, so set this bit */ > cmdr |= SDMMC_CMD_RESP_EXP; > @@ -775,11 +804,15 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit) > unsigned int clock = slot->clock; > u32 div; > u32 clk_en_a; > + u32 sdmmc_cmd_bits = SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT; > + > + /* We must continue to set bit 28 in CMD until the change is complete */ > + if (host->state == STATE_WAITING_CMD11_DONE) > + sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH; > > if (!clock) { > mci_writel(host, CLKENA, 0); > - mci_send_cmd(slot, > - SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0); > + mci_send_cmd(slot, sdmmc_cmd_bits, 0); > } else if (clock != host->current_speed || force_clkinit) { > div = host->bus_hz / clock; > if (host->bus_hz % clock && host->bus_hz > clock) > @@ -803,15 +836,13 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit) > mci_writel(host, CLKSRC, 0); > > /* inform CIU */ > - mci_send_cmd(slot, > - SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0); > + mci_send_cmd(slot, sdmmc_cmd_bits, 0); > > /* set clock to desired speed */ > mci_writel(host, CLKDIV, div); > > /* inform CIU */ > - mci_send_cmd(slot, > - SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0); > + mci_send_cmd(slot, sdmmc_cmd_bits, 0); > > /* enable clock; only low power if no SDIO */ > clk_en_a = SDMMC_CLKEN_ENABLE << slot->id; > @@ -820,8 +851,7 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit) > mci_writel(host, CLKENA, clk_en_a); > > /* inform CIU */ > - mci_send_cmd(slot, > - SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0); > + mci_send_cmd(slot, sdmmc_cmd_bits, 0); > > /* keep the clock with reflecting clock dividor */ > slot->__clk_old = clock << div; > @@ -897,6 +927,17 @@ static void dw_mci_queue_request(struct dw_mci *host, struct dw_mci_slot *slot, > > slot->mrq = mrq; > > + if (host->state == STATE_WAITING_CMD11_DONE) { > + dev_warn(&slot->mmc->class_dev, > + "Voltage change didn't complete\n"); > + /* > + * this case isn't expected to happen, so we can > + * either crash here or just try to continue on > + * in the closest possible state > + */ > + host->state = STATE_IDLE; > + } > + > if (host->state == STATE_IDLE) { > host->state = STATE_SENDING_CMD; > dw_mci_start_request(host, slot); > @@ -973,6 +1014,9 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) > /* Slot specific timing and width adjustment */ > dw_mci_setup_bus(slot, false); > > + if (slot->host->state == STATE_WAITING_CMD11_DONE && ios->clock != 0) > + slot->host->state = STATE_IDLE; > + > switch (ios->power_mode) { > case MMC_POWER_UP: > if (!IS_ERR(mmc->supply.vmmc)) { > @@ -1016,6 +1060,59 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) > } > } > > +static int dw_mci_card_busy(struct mmc_host *mmc) > +{ > + struct dw_mci_slot *slot = mmc_priv(mmc); > + u32 status; > + > + /* > + * Check the busy bit which is low when DAT[3:0] > + * (the data lines) are 0000 > + */ > + status = mci_readl(slot->host, STATUS); > + > + return !!(status & SDMMC_STATUS_BUSY); > +} > + > +static int dw_mci_switch_voltage(struct mmc_host *mmc, struct mmc_ios *ios) > +{ > + struct dw_mci_slot *slot = mmc_priv(mmc); > + struct dw_mci *host = slot->host; > + u32 uhs; > + u32 v18 = SDMMC_UHS_18V << slot->id; > + int min_uv, max_uv; > + int ret; > + > + /* > + * Program the voltage. Note that some instances of dw_mmc may use > + * the UHS_REG for this. For other instances (like exynos) the UHS_REG > + * does no harm but you need to set the regulator directly. Try both. > + */ > + uhs = mci_readl(host, UHS_REG); > + if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_330) { > + min_uv = 2700000; > + max_uv = 3600000; > + uhs &= ~v18; > + } else { > + min_uv = 1700000; > + max_uv = 1950000; > + uhs |= v18; > + } > + if (!IS_ERR(mmc->supply.vqmmc)) { > + ret = regulator_set_voltage(mmc->supply.vqmmc, min_uv, max_uv); > + > + if (ret) { > + dev_err(&mmc->class_dev, > + "Regulator set error %d: %d - %d\n", > + ret, min_uv, max_uv); > + return ret; > + } > + } > + mci_writel(host, UHS_REG, uhs); > + > + return 0; > +} > + > static int dw_mci_get_ro(struct mmc_host *mmc) > { > int read_only; > @@ -1158,6 +1255,9 @@ static const struct mmc_host_ops dw_mci_ops = { > .get_cd = dw_mci_get_cd, > .enable_sdio_irq = dw_mci_enable_sdio_irq, > .execute_tuning = dw_mci_execute_tuning, > + .card_busy = dw_mci_card_busy, > + .start_signal_voltage_switch = dw_mci_switch_voltage, > + > }; > > static void dw_mci_request_end(struct dw_mci *host, struct mmc_request *mrq) > @@ -1181,7 +1281,11 @@ static void dw_mci_request_end(struct dw_mci *host, struct mmc_request *mrq) > dw_mci_start_request(host, slot); > } else { > dev_vdbg(host->dev, "list empty\n"); > - host->state = STATE_IDLE; > + > + if (host->state == STATE_SENDING_CMD11) > + host->state = STATE_WAITING_CMD11_DONE; > + else > + host->state = STATE_IDLE; > } > > spin_unlock(&host->lock); > @@ -1292,8 +1396,10 @@ static void dw_mci_tasklet_func(unsigned long priv) > > switch (state) { > case STATE_IDLE: > + case STATE_WAITING_CMD11_DONE: > break; > > + case STATE_SENDING_CMD11: > case STATE_SENDING_CMD: > if (!test_and_clear_bit(EVENT_CMD_COMPLETE, > &host->pending_events)) > @@ -1894,6 +2000,14 @@ static irqreturn_t dw_mci_interrupt(int irq, void *dev_id) > } > > if (pending) { > + /* Check volt switch first, since it can look like an error */ > + if ((host->state == STATE_SENDING_CMD11) && > + (pending & SDMMC_INT_VOLT_SWITCH)) { > + mci_writel(host, RINTSTS, SDMMC_INT_VOLT_SWITCH); > + pending &= ~SDMMC_INT_VOLT_SWITCH; > + dw_mci_cmd_interrupt(host, pending); > + } > + > if (pending & DW_MCI_CMD_ERROR_FLAGS) { > mci_writel(host, RINTSTS, DW_MCI_CMD_ERROR_FLAGS); > host->cmd_status = pending; > @@ -1999,7 +2113,9 @@ static void dw_mci_work_routine_card(struct work_struct *work) > > switch (host->state) { > case STATE_IDLE: > + case STATE_WAITING_CMD11_DONE: > break; > + case STATE_SENDING_CMD11: > case STATE_SENDING_CMD: > mrq->cmd->error = -ENOMEDIUM; > if (!mrq->data) > diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h > index 08fd956..01b99e8 100644 > --- a/drivers/mmc/host/dw_mmc.h > +++ b/drivers/mmc/host/dw_mmc.h > @@ -99,6 +99,7 @@ > #define SDMMC_INT_HLE BIT(12) > #define SDMMC_INT_FRUN BIT(11) > #define SDMMC_INT_HTO BIT(10) > +#define SDMMC_INT_VOLT_SWITCH BIT(10) /* overloads bit 10! */ > #define SDMMC_INT_DRTO BIT(9) > #define SDMMC_INT_RTO BIT(8) > #define SDMMC_INT_DCRC BIT(7) > @@ -113,6 +114,7 @@ > /* Command register defines */ > #define SDMMC_CMD_START BIT(31) > #define SDMMC_CMD_USE_HOLD_REG BIT(29) > +#define SDMMC_CMD_VOLT_SWITCH BIT(28) > #define SDMMC_CMD_CCS_EXP BIT(23) > #define SDMMC_CMD_CEATA_RD BIT(22) > #define SDMMC_CMD_UPD_CLK BIT(21) > @@ -130,6 +132,7 @@ > /* Status register defines */ > #define SDMMC_GET_FCNT(x) (((x)>>17) & 0x1FFF) > #define SDMMC_STATUS_DMA_REQ BIT(31) > +#define SDMMC_STATUS_BUSY BIT(9) > /* FIFOTH register defines */ > #define SDMMC_SET_FIFOTH(m, r, t) (((m) & 0x7) << 28 | \ > ((r) & 0xFFF) << 16 | \ > @@ -150,7 +153,7 @@ > #define SDMMC_GET_VERID(x) ((x) & 0xFFFF) > /* Card read threshold */ > #define SDMMC_SET_RD_THLD(v, x) (((v) & 0x1FFF) << 16 | (x)) > - > +#define SDMMC_UHS_18V BIT(0) > /* All ctrl reset bits */ > #define SDMMC_CTRL_ALL_RESET_FLAGS \ > (SDMMC_CTRL_RESET | SDMMC_CTRL_FIFO_RESET | SDMMC_CTRL_DMA_RESET) > diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h > index 84e2827..0013669 100644 > --- a/include/linux/mmc/dw_mmc.h > +++ b/include/linux/mmc/dw_mmc.h > @@ -26,6 +26,8 @@ enum dw_mci_state { > STATE_DATA_BUSY, > STATE_SENDING_STOP, > STATE_DATA_ERROR, > + STATE_SENDING_CMD11, > + STATE_WAITING_CMD11_DONE, > }; > > enum { > -- > 1.7.10.4 > ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 2/3] mmc: dw_mmc: Support voltage changes 2014-08-22 15:35 ` Ulf Hansson @ 2014-08-22 20:38 ` Doug Anderson 2014-08-25 8:31 ` Ulf Hansson 0 siblings, 1 reply; 43+ messages in thread From: Doug Anderson @ 2014-08-22 20:38 UTC (permalink / raw) To: linux-arm-kernel 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. 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. -Doug ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 2/3] mmc: dw_mmc: Support voltage changes 2014-08-22 20:38 ` Doug Anderson @ 2014-08-25 8:31 ` Ulf Hansson 2014-08-25 20:59 ` Doug Anderson 0 siblings, 1 reply; 43+ messages in thread From: Ulf Hansson @ 2014-08-25 8:31 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 2/3] mmc: dw_mmc: Support voltage changes 2014-08-25 8:31 ` Ulf Hansson @ 2014-08-25 20:59 ` Doug Anderson 2014-08-29 11:43 ` Ulf Hansson 0 siblings, 1 reply; 43+ messages in thread From: Doug Anderson @ 2014-08-25 20:59 UTC (permalink / raw) To: linux-arm-kernel Ulf, On Mon, Aug 25, 2014 at 1:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: > 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. :-) OK, how about: /* * We need to disable low power mode (automatic clock stop) * while doing voltage switch so we don't confuse the card, * since stopping the clock is a specific part of the UHS * voltage change dance. * * Note that low power mode (SDMMC_CLKEN_LOW_PWR) will be * unconditionally turned back on in dw_mci_setup_bus() if it's * ever called with a non-zero clock. That shouldn't happen * until the voltage change is all done. */ Yuvaraj: can you include that in the next patch set you send out? ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 2/3] mmc: dw_mmc: Support voltage changes 2014-08-25 20:59 ` Doug Anderson @ 2014-08-29 11:43 ` Ulf Hansson 2014-09-29 12:49 ` Bartlomiej Zolnierkiewicz 0 siblings, 1 reply; 43+ messages in thread From: Ulf Hansson @ 2014-08-29 11:43 UTC (permalink / raw) To: linux-arm-kernel On 25 August 2014 22:59, Doug Anderson <dianders@google.com> wrote: > Ulf, > > On Mon, Aug 25, 2014 at 1:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >> 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. :-) > > OK, how about: > > /* > * We need to disable low power mode (automatic clock stop) > * while doing voltage switch so we don't confuse the card, > * since stopping the clock is a specific part of the UHS > * voltage change dance. > * > * Note that low power mode (SDMMC_CLKEN_LOW_PWR) will be > * unconditionally turned back on in dw_mci_setup_bus() if it's > * ever called with a non-zero clock. That shouldn't happen > * until the voltage change is all done. > */ > > Yuvaraj: can you include that in the next patch set you send out? Thanks! Applied for next! I took the liberty to change to the clarified comment from Doug above. Kind regards Uffe ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 2/3] mmc: dw_mmc: Support voltage changes 2014-08-29 11:43 ` Ulf Hansson @ 2014-09-29 12:49 ` Bartlomiej Zolnierkiewicz 0 siblings, 0 replies; 43+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2014-09-29 12:49 UTC (permalink / raw) To: linux-arm-kernel Hi, On Friday, August 29, 2014 01:43:16 PM Ulf Hansson wrote: > On 25 August 2014 22:59, Doug Anderson <dianders@google.com> wrote: > > Ulf, > > > > On Mon, Aug 25, 2014 at 1:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: > >> 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. :-) > > > > OK, how about: > > > > /* > > * We need to disable low power mode (automatic clock stop) > > * while doing voltage switch so we don't confuse the card, > > * since stopping the clock is a specific part of the UHS > > * voltage change dance. > > * > > * Note that low power mode (SDMMC_CLKEN_LOW_PWR) will be > > * unconditionally turned back on in dw_mci_setup_bus() if it's > > * ever called with a non-zero clock. That shouldn't happen > > * until the voltage change is all done. > > */ > > > > Yuvaraj: can you include that in the next patch set you send out? > > Thanks! Applied for next! > > I took the liberty to change to the clarified comment from Doug above. This patch casuses a boot hang during regulators initizalization on Exynos5420 Arndale Octa board. The kernel config used can was posted in other thread: http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg37210.html IOW I need to revert both "mmc: dw_mmc: Support voltage changes" and "mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators" patches to make next branch of mmc-uh tree work on my setup. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 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-22 13:47 ` [PATCH V2 2/3] mmc: dw_mmc: Support voltage changes Yuvaraj Kumar C D @ 2014-08-22 13:47 ` Yuvaraj Kumar C D 2014-08-22 15:31 ` Ulf Hansson 2 siblings, 1 reply; 43+ messages in thread From: Yuvaraj Kumar C D @ 2014-08-22 13:47 UTC (permalink / raw) To: linux-arm-kernel Exynos 5250 and 5420 based boards uses built-in CD# line for card detection.But unfortunately CD# line is on the same voltage rails as of I/O voltage rails. When we cut off vqmmc,the consequent card detection will break in these boards. These hosts (obviously) need to keep vqmmc (and thus vmmc) on all the time, even when the mmc core tells them to power off. However, one problem is that these cards won't properly handle mmc_power_cycle(). That's needed to handle error cases when trying to switch voltages (see 0797e5f mmc:core: Fixup signal voltage switch). This patch adds a new MMC_POWER_OFF_HARD mode when it's doing a power cycle. This mode differs from the normal MMC_POWER_OFF mode in that the mmc core will promise to power the slot back on before it expects the host to detect card insertion or removal. Also if we let alone the vqmmc turned on when vmmc turned off, the card could have half way powered and this can damage the card. So this patch adds a check so that, if the board used the built-in card detection mechanism i.e through CDETECT, it will not turned down vqmmc and vmmc both. Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com> Signed-off-by: Doug Anderson <dianders@chromium.org> --- changes from v1: 1.added a new MMC_POWER_OFF_HARD mode as per Doug Anderson's suggestion. 2.added dw_mci_exynos_post_init() to perform the host specific post initialisation. 3.added a new flag MMC_CAP2_CD_NEEDS_POWER for host->caps2. drivers/mmc/core/core.c | 16 ++++++++++++++-- drivers/mmc/core/debugfs.c | 3 +++ drivers/mmc/host/dw_mmc-exynos.c | 12 ++++++++++++ drivers/mmc/host/dw_mmc.c | 25 +++++++++++++++++++++++++ drivers/mmc/host/dw_mmc.h | 2 ++ include/linux/mmc/host.h | 2 ++ 6 files changed, 58 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index 68f5f4b..79ced36 100644 --- a/drivers/mmc/core/core.c +++ b/drivers/mmc/core/core.c @@ -1564,9 +1564,9 @@ void mmc_power_up(struct mmc_host *host, u32 ocr) mmc_host_clk_release(host); } -void mmc_power_off(struct mmc_host *host) +void _mmc_power_off(struct mmc_host *host, unsigned char power_mode) { - if (host->ios.power_mode == MMC_POWER_OFF) + if (host->ios.power_mode == power_mode) return; mmc_host_clk_hold(host); @@ -1579,6 +1579,7 @@ void mmc_power_off(struct mmc_host *host) host->ios.chip_select = MMC_CS_DONTCARE; } host->ios.power_mode = MMC_POWER_OFF; + host->ios.power_mode = power_mode; host->ios.bus_width = MMC_BUS_WIDTH_1; host->ios.timing = MMC_TIMING_LEGACY; mmc_set_ios(host); @@ -1593,9 +1594,20 @@ void mmc_power_off(struct mmc_host *host) mmc_host_clk_release(host); } +void mmc_power_off(struct mmc_host *host) +{ + _mmc_power_off(host, MMC_POWER_OFF); +} + void mmc_power_cycle(struct mmc_host *host, u32 ocr) { mmc_power_off(host); + /* If host normally ignores MMC_POWER_OFF, tell it to pay attention */ + if (host->caps2 & MMC_CAP2_CD_NEEDS_POWER) + _mmc_power_off(host, MMC_POWER_OFF_HARD); + else + _mmc_power_off(host, MMC_POWER_OFF); + /* Wait at least 1 ms according to SD spec */ mmc_delay(1); mmc_power_up(host, ocr); diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c index 91eb162..3d9c5a3 100644 --- a/drivers/mmc/core/debugfs.c +++ b/drivers/mmc/core/debugfs.c @@ -108,6 +108,9 @@ static int mmc_ios_show(struct seq_file *s, void *data) case MMC_POWER_ON: str = "on"; break; + case MMC_POWER_OFF_HARD: + str = "hard off"; + break; default: str = "invalid"; break; diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c index 0fbc53a..4e26049 100644 --- a/drivers/mmc/host/dw_mmc-exynos.c +++ b/drivers/mmc/host/dw_mmc-exynos.c @@ -17,6 +17,7 @@ #include <linux/mmc/mmc.h> #include <linux/of.h> #include <linux/of_gpio.h> +#include <linux/mmc/slot-gpio.h> #include <linux/slab.h> #include "dw_mmc.h" @@ -217,6 +218,16 @@ static void dw_mci_exynos_set_ios(struct dw_mci *host, struct mmc_ios *ios) } } +static void dw_mci_exynos_post_init(struct dw_mci_slot *slot) +{ + struct dw_mci_board *brd = slot->host->pdata; + struct mmc_host *mmc = slot->mmc; + + if (!(brd->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION) && + IS_ERR_VALUE(mmc_gpio_get_cd(mmc))) + mmc->caps2 |= MMC_CAP2_CD_NEEDS_POWER; +} + static int dw_mci_exynos_parse_dt(struct dw_mci *host) { struct dw_mci_exynos_priv_data *priv; @@ -399,6 +410,7 @@ static const struct dw_mci_drv_data exynos_drv_data = { .prepare_command = dw_mci_exynos_prepare_command, .set_ios = dw_mci_exynos_set_ios, .parse_dt = dw_mci_exynos_parse_dt, + .post_init = dw_mci_exynos_post_init, .execute_tuning = dw_mci_exynos_execute_tuning, }; diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index f20b4b8..6f2c681 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -972,6 +972,22 @@ static void dw_mci_request(struct mmc_host *mmc, struct mmc_request *mrq) spin_unlock_bh(&host->lock); } +/* + * some of the boards use controller CD line for card detection.Unfortunately + * CD line is bind to the same volatge domain as of the IO lines.If we turn off + * IO voltage domain, CD line wont work. + * Return true when controller CD line is used for card detection or return + * false. + */ +static bool dw_mci_builtin_cd(struct dw_mci_slot *slot) +{ + struct dw_mci_board *brd = slot->host->pdata; + struct mmc_host *mmc = slot->mmc; + + return (!(brd->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION) && + IS_ERR_VALUE(mmc_gpio_get_cd(mmc))) ? 1 : 0; +} + static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) { struct dw_mci_slot *slot = mmc_priv(mmc); @@ -1043,6 +1059,10 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) mci_writel(slot->host, PWREN, regs); break; case MMC_POWER_OFF: + if (dw_mci_builtin_cd(slot) && + !test_bit(DW_MMC_CARD_PRESENT, &slot->flags)) + return; + if (!IS_ERR(mmc->supply.vmmc)) mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0); @@ -1055,6 +1075,8 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) regs &= ~(1 << slot->id); mci_writel(slot->host, PWREN, regs); break; + case MMC_POWER_OFF_HARD: + break; default: break; } @@ -2310,6 +2332,9 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id) else clear_bit(DW_MMC_CARD_PRESENT, &slot->flags); + if (drv_data && drv_data->post_init) + drv_data->post_init(slot); + ret = mmc_add_host(mmc); if (ret) goto err_setup_bus; diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h index 01b99e8..a3c2628 100644 --- a/drivers/mmc/host/dw_mmc.h +++ b/drivers/mmc/host/dw_mmc.h @@ -250,6 +250,7 @@ struct dw_mci_tuning_data { * @prepare_command: handle CMD register extensions. * @set_ios: handle bus specific extensions. * @parse_dt: parse implementation specific device tree properties. + * @post_init: implementation specific post initialization. * @execute_tuning: implementation specific tuning procedure. * * Provide controller implementation specific extensions. The usage of this @@ -263,6 +264,7 @@ struct dw_mci_drv_data { void (*prepare_command)(struct dw_mci *host, u32 *cmdr); void (*set_ios)(struct dw_mci *host, struct mmc_ios *ios); int (*parse_dt)(struct dw_mci *host); + void (*post_init)(struct dw_mci_slot *slot); int (*execute_tuning)(struct dw_mci_slot *slot, u32 opcode, struct dw_mci_tuning_data *tuning_data); }; diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h index 4cbf614..5eb24ff 100644 --- a/include/linux/mmc/host.h +++ b/include/linux/mmc/host.h @@ -42,6 +42,7 @@ struct mmc_ios { #define MMC_POWER_OFF 0 #define MMC_POWER_UP 1 #define MMC_POWER_ON 2 +#define MMC_POWER_OFF_HARD 3 unsigned char bus_width; /* data bus width */ @@ -283,6 +284,7 @@ struct mmc_host { #define MMC_CAP2_HS400 (MMC_CAP2_HS400_1_8V | \ MMC_CAP2_HS400_1_2V) #define MMC_CAP2_SDIO_IRQ_NOTHREAD (1 << 17) +#define MMC_CAP2_CD_NEEDS_POWER (1 << 18) /* Card detect needs power */ mmc_pm_flag_t pm_caps; /* supported pm features */ -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 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 0 siblings, 1 reply; 43+ messages in thread From: Ulf Hansson @ 2014-08-22 15:31 UTC (permalink / raw) To: linux-arm-kernel On 22 August 2014 15:47, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote: > Exynos 5250 and 5420 based boards uses built-in CD# line for card > detection.But unfortunately CD# line is on the same voltage rails > as of I/O voltage rails. When we cut off vqmmc,the consequent card > detection will break in these boards. I am not sure I follow here. Is the card detect mechanism handled internally by the dw_mmc controller? I thought HW engineers long time ago realized that this should be done separately on a GPIO line to be able to save power while waiting for a card to be inserted. But that's not case then? > > These hosts (obviously) need to keep vqmmc (and thus vmmc) on all the > time, even when the mmc core tells them to power off. However, one > problem is that these cards won't properly handle mmc_power_cycle(). > That's needed to handle error cases when trying to switch voltages > (see 0797e5f mmc:core: Fixup signal voltage switch). > > This patch adds a new MMC_POWER_OFF_HARD mode when it's doing a power > cycle. This mode differs from the normal MMC_POWER_OFF mode in that > the mmc core will promise to power the slot back on before it expects > the host to detect card insertion or removal. > > Also if we let alone the vqmmc turned on when vmmc turned off, the > card could have half way powered and this can damage the card. So > this patch adds a check so that, if the board used the built-in > card detection mechanism i.e through CDETECT, it will not turned > down vqmmc and vmmc both. Why does vmmc needs to be enabled when there are no card inserted? That can't be right? Kind regards Uffe > > Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com> > Signed-off-by: Doug Anderson <dianders@chromium.org> > --- > changes from v1: > 1.added a new MMC_POWER_OFF_HARD mode as per Doug Anderson's suggestion. > 2.added dw_mci_exynos_post_init() to perform the host specific post > initialisation. > 3.added a new flag MMC_CAP2_CD_NEEDS_POWER for host->caps2. > > drivers/mmc/core/core.c | 16 ++++++++++++++-- > drivers/mmc/core/debugfs.c | 3 +++ > drivers/mmc/host/dw_mmc-exynos.c | 12 ++++++++++++ > drivers/mmc/host/dw_mmc.c | 25 +++++++++++++++++++++++++ > drivers/mmc/host/dw_mmc.h | 2 ++ > include/linux/mmc/host.h | 2 ++ > 6 files changed, 58 insertions(+), 2 deletions(-) > > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c > index 68f5f4b..79ced36 100644 > --- a/drivers/mmc/core/core.c > +++ b/drivers/mmc/core/core.c > @@ -1564,9 +1564,9 @@ void mmc_power_up(struct mmc_host *host, u32 ocr) > mmc_host_clk_release(host); > } > > -void mmc_power_off(struct mmc_host *host) > +void _mmc_power_off(struct mmc_host *host, unsigned char power_mode) > { > - if (host->ios.power_mode == MMC_POWER_OFF) > + if (host->ios.power_mode == power_mode) > return; > > mmc_host_clk_hold(host); > @@ -1579,6 +1579,7 @@ void mmc_power_off(struct mmc_host *host) > host->ios.chip_select = MMC_CS_DONTCARE; > } > host->ios.power_mode = MMC_POWER_OFF; > + host->ios.power_mode = power_mode; > host->ios.bus_width = MMC_BUS_WIDTH_1; > host->ios.timing = MMC_TIMING_LEGACY; > mmc_set_ios(host); > @@ -1593,9 +1594,20 @@ void mmc_power_off(struct mmc_host *host) > mmc_host_clk_release(host); > } > > +void mmc_power_off(struct mmc_host *host) > +{ > + _mmc_power_off(host, MMC_POWER_OFF); > +} > + > void mmc_power_cycle(struct mmc_host *host, u32 ocr) > { > mmc_power_off(host); > + /* If host normally ignores MMC_POWER_OFF, tell it to pay attention */ > + if (host->caps2 & MMC_CAP2_CD_NEEDS_POWER) > + _mmc_power_off(host, MMC_POWER_OFF_HARD); > + else > + _mmc_power_off(host, MMC_POWER_OFF); > + > /* Wait at least 1 ms according to SD spec */ > mmc_delay(1); > mmc_power_up(host, ocr); > diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c > index 91eb162..3d9c5a3 100644 > --- a/drivers/mmc/core/debugfs.c > +++ b/drivers/mmc/core/debugfs.c > @@ -108,6 +108,9 @@ static int mmc_ios_show(struct seq_file *s, void *data) > case MMC_POWER_ON: > str = "on"; > break; > + case MMC_POWER_OFF_HARD: > + str = "hard off"; > + break; > default: > str = "invalid"; > break; > diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c > index 0fbc53a..4e26049 100644 > --- a/drivers/mmc/host/dw_mmc-exynos.c > +++ b/drivers/mmc/host/dw_mmc-exynos.c > @@ -17,6 +17,7 @@ > #include <linux/mmc/mmc.h> > #include <linux/of.h> > #include <linux/of_gpio.h> > +#include <linux/mmc/slot-gpio.h> > #include <linux/slab.h> > > #include "dw_mmc.h" > @@ -217,6 +218,16 @@ static void dw_mci_exynos_set_ios(struct dw_mci *host, struct mmc_ios *ios) > } > } > > +static void dw_mci_exynos_post_init(struct dw_mci_slot *slot) > +{ > + struct dw_mci_board *brd = slot->host->pdata; > + struct mmc_host *mmc = slot->mmc; > + > + if (!(brd->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION) && > + IS_ERR_VALUE(mmc_gpio_get_cd(mmc))) > + mmc->caps2 |= MMC_CAP2_CD_NEEDS_POWER; > +} > + > static int dw_mci_exynos_parse_dt(struct dw_mci *host) > { > struct dw_mci_exynos_priv_data *priv; > @@ -399,6 +410,7 @@ static const struct dw_mci_drv_data exynos_drv_data = { > .prepare_command = dw_mci_exynos_prepare_command, > .set_ios = dw_mci_exynos_set_ios, > .parse_dt = dw_mci_exynos_parse_dt, > + .post_init = dw_mci_exynos_post_init, > .execute_tuning = dw_mci_exynos_execute_tuning, > }; > > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c > index f20b4b8..6f2c681 100644 > --- a/drivers/mmc/host/dw_mmc.c > +++ b/drivers/mmc/host/dw_mmc.c > @@ -972,6 +972,22 @@ static void dw_mci_request(struct mmc_host *mmc, struct mmc_request *mrq) > spin_unlock_bh(&host->lock); > } > > +/* > + * some of the boards use controller CD line for card detection.Unfortunately > + * CD line is bind to the same volatge domain as of the IO lines.If we turn off > + * IO voltage domain, CD line wont work. > + * Return true when controller CD line is used for card detection or return > + * false. > + */ > +static bool dw_mci_builtin_cd(struct dw_mci_slot *slot) > +{ > + struct dw_mci_board *brd = slot->host->pdata; > + struct mmc_host *mmc = slot->mmc; > + > + return (!(brd->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION) && > + IS_ERR_VALUE(mmc_gpio_get_cd(mmc))) ? 1 : 0; > +} > + > static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) > { > struct dw_mci_slot *slot = mmc_priv(mmc); > @@ -1043,6 +1059,10 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) > mci_writel(slot->host, PWREN, regs); > break; > case MMC_POWER_OFF: > + if (dw_mci_builtin_cd(slot) && > + !test_bit(DW_MMC_CARD_PRESENT, &slot->flags)) > + return; > + > if (!IS_ERR(mmc->supply.vmmc)) > mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0); > > @@ -1055,6 +1075,8 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) > regs &= ~(1 << slot->id); > mci_writel(slot->host, PWREN, regs); > break; > + case MMC_POWER_OFF_HARD: > + break; > default: > break; > } > @@ -2310,6 +2332,9 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id) > else > clear_bit(DW_MMC_CARD_PRESENT, &slot->flags); > > + if (drv_data && drv_data->post_init) > + drv_data->post_init(slot); > + > ret = mmc_add_host(mmc); > if (ret) > goto err_setup_bus; > diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h > index 01b99e8..a3c2628 100644 > --- a/drivers/mmc/host/dw_mmc.h > +++ b/drivers/mmc/host/dw_mmc.h > @@ -250,6 +250,7 @@ struct dw_mci_tuning_data { > * @prepare_command: handle CMD register extensions. > * @set_ios: handle bus specific extensions. > * @parse_dt: parse implementation specific device tree properties. > + * @post_init: implementation specific post initialization. > * @execute_tuning: implementation specific tuning procedure. > * > * Provide controller implementation specific extensions. The usage of this > @@ -263,6 +264,7 @@ struct dw_mci_drv_data { > void (*prepare_command)(struct dw_mci *host, u32 *cmdr); > void (*set_ios)(struct dw_mci *host, struct mmc_ios *ios); > int (*parse_dt)(struct dw_mci *host); > + void (*post_init)(struct dw_mci_slot *slot); > int (*execute_tuning)(struct dw_mci_slot *slot, u32 opcode, > struct dw_mci_tuning_data *tuning_data); > }; > diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h > index 4cbf614..5eb24ff 100644 > --- a/include/linux/mmc/host.h > +++ b/include/linux/mmc/host.h > @@ -42,6 +42,7 @@ struct mmc_ios { > #define MMC_POWER_OFF 0 > #define MMC_POWER_UP 1 > #define MMC_POWER_ON 2 > +#define MMC_POWER_OFF_HARD 3 > > unsigned char bus_width; /* data bus width */ > > @@ -283,6 +284,7 @@ struct mmc_host { > #define MMC_CAP2_HS400 (MMC_CAP2_HS400_1_8V | \ > MMC_CAP2_HS400_1_2V) > #define MMC_CAP2_SDIO_IRQ_NOTHREAD (1 << 17) > +#define MMC_CAP2_CD_NEEDS_POWER (1 << 18) /* Card detect needs power */ > > mmc_pm_flag_t pm_caps; /* supported pm features */ > > -- > 1.7.10.4 > ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 2014-08-22 15:31 ` Ulf Hansson @ 2014-08-22 18:27 ` Sonny Rao 2014-08-25 8:13 ` Ulf Hansson 0 siblings, 1 reply; 43+ messages in thread From: Sonny Rao @ 2014-08-22 18:27 UTC (permalink / raw) To: linux-arm-kernel On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: > On 22 August 2014 15:47, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote: >> Exynos 5250 and 5420 based boards uses built-in CD# line for card >> detection.But unfortunately CD# line is on the same voltage rails >> as of I/O voltage rails. When we cut off vqmmc,the consequent card >> detection will break in these boards. > > I am not sure I follow here. > > Is the card detect mechanism handled internally by the dw_mmc controller? Yes > > I thought HW engineers long time ago realized that this should be done > separately on a GPIO line to be able to save power while waiting for a > card to be inserted. But that's not case then? At least in my limited experience, this seems to be common among SoC vendors who are using dw_mmc, as we've seen this elsewhere as well and after seeing it here we know that we need to ignore the CD pin that's routed to dw_mmc and use a separately powered GPIO on the board, but still there are probably many SoCs/boards which are doing it this way. >> >> These hosts (obviously) need to keep vqmmc (and thus vmmc) on all the >> time, even when the mmc core tells them to power off. However, one >> problem is that these cards won't properly handle mmc_power_cycle(). >> That's needed to handle error cases when trying to switch voltages >> (see 0797e5f mmc:core: Fixup signal voltage switch). >> >> This patch adds a new MMC_POWER_OFF_HARD mode when it's doing a power >> cycle. This mode differs from the normal MMC_POWER_OFF mode in that >> the mmc core will promise to power the slot back on before it expects >> the host to detect card insertion or removal. This patch is based off of one that Doug wrote (sent privately to Yuvaraj) which just modifies the MMC core, and should be split into two patches. One that modifies the mmc core and one that implements this in dw_mmc. >> >> Also if we let alone the vqmmc turned on when vmmc turned off, the >> card could have half way powered and this can damage the card. So >> this patch adds a check so that, if the board used the built-in >> card detection mechanism i.e through CDETECT, it will not turned >> down vqmmc and vmmc both. > > Why does vmmc needs to be enabled when there are no card inserted? > That can't be right? I think this is because we don't want to send power to a card over the I/O pins but not the vcc pin, even for a little while. We also asked some SD card manufacturers about whether it was okay to leave vqmmc on and they recommended not doing this, because there's a risk of damage to the card. So, in this (broken) environment, we basically just keep both vmmc and vqmmc on all the time unless mmc core is asking the driver to power cycle the card through MMC_POWER_OFF and MMC_POWER_ON modes. Does that help? > > Kind regards > Uffe > >> >> Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com> >> Signed-off-by: Doug Anderson <dianders@chromium.org> >> --- >> changes from v1: >> 1.added a new MMC_POWER_OFF_HARD mode as per Doug Anderson's suggestion. >> 2.added dw_mci_exynos_post_init() to perform the host specific post >> initialisation. >> 3.added a new flag MMC_CAP2_CD_NEEDS_POWER for host->caps2. >> >> drivers/mmc/core/core.c | 16 ++++++++++++++-- >> drivers/mmc/core/debugfs.c | 3 +++ >> drivers/mmc/host/dw_mmc-exynos.c | 12 ++++++++++++ >> drivers/mmc/host/dw_mmc.c | 25 +++++++++++++++++++++++++ >> drivers/mmc/host/dw_mmc.h | 2 ++ >> include/linux/mmc/host.h | 2 ++ >> 6 files changed, 58 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c >> index 68f5f4b..79ced36 100644 >> --- a/drivers/mmc/core/core.c >> +++ b/drivers/mmc/core/core.c >> @@ -1564,9 +1564,9 @@ void mmc_power_up(struct mmc_host *host, u32 ocr) >> mmc_host_clk_release(host); >> } >> >> -void mmc_power_off(struct mmc_host *host) >> +void _mmc_power_off(struct mmc_host *host, unsigned char power_mode) >> { >> - if (host->ios.power_mode == MMC_POWER_OFF) >> + if (host->ios.power_mode == power_mode) >> return; >> >> mmc_host_clk_hold(host); >> @@ -1579,6 +1579,7 @@ void mmc_power_off(struct mmc_host *host) >> host->ios.chip_select = MMC_CS_DONTCARE; >> } >> host->ios.power_mode = MMC_POWER_OFF; >> + host->ios.power_mode = power_mode; >> host->ios.bus_width = MMC_BUS_WIDTH_1; >> host->ios.timing = MMC_TIMING_LEGACY; >> mmc_set_ios(host); >> @@ -1593,9 +1594,20 @@ void mmc_power_off(struct mmc_host *host) >> mmc_host_clk_release(host); >> } >> >> +void mmc_power_off(struct mmc_host *host) >> +{ >> + _mmc_power_off(host, MMC_POWER_OFF); >> +} >> + >> void mmc_power_cycle(struct mmc_host *host, u32 ocr) >> { >> mmc_power_off(host); >> + /* If host normally ignores MMC_POWER_OFF, tell it to pay attention */ >> + if (host->caps2 & MMC_CAP2_CD_NEEDS_POWER) >> + _mmc_power_off(host, MMC_POWER_OFF_HARD); >> + else >> + _mmc_power_off(host, MMC_POWER_OFF); >> + >> /* Wait at least 1 ms according to SD spec */ >> mmc_delay(1); >> mmc_power_up(host, ocr); >> diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c >> index 91eb162..3d9c5a3 100644 >> --- a/drivers/mmc/core/debugfs.c >> +++ b/drivers/mmc/core/debugfs.c >> @@ -108,6 +108,9 @@ static int mmc_ios_show(struct seq_file *s, void *data) >> case MMC_POWER_ON: >> str = "on"; >> break; >> + case MMC_POWER_OFF_HARD: >> + str = "hard off"; >> + break; >> default: >> str = "invalid"; >> break; >> diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c >> index 0fbc53a..4e26049 100644 >> --- a/drivers/mmc/host/dw_mmc-exynos.c >> +++ b/drivers/mmc/host/dw_mmc-exynos.c >> @@ -17,6 +17,7 @@ >> #include <linux/mmc/mmc.h> >> #include <linux/of.h> >> #include <linux/of_gpio.h> >> +#include <linux/mmc/slot-gpio.h> >> #include <linux/slab.h> >> >> #include "dw_mmc.h" >> @@ -217,6 +218,16 @@ static void dw_mci_exynos_set_ios(struct dw_mci *host, struct mmc_ios *ios) >> } >> } >> >> +static void dw_mci_exynos_post_init(struct dw_mci_slot *slot) >> +{ >> + struct dw_mci_board *brd = slot->host->pdata; >> + struct mmc_host *mmc = slot->mmc; >> + >> + if (!(brd->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION) && >> + IS_ERR_VALUE(mmc_gpio_get_cd(mmc))) >> + mmc->caps2 |= MMC_CAP2_CD_NEEDS_POWER; >> +} >> + >> static int dw_mci_exynos_parse_dt(struct dw_mci *host) >> { >> struct dw_mci_exynos_priv_data *priv; >> @@ -399,6 +410,7 @@ static const struct dw_mci_drv_data exynos_drv_data = { >> .prepare_command = dw_mci_exynos_prepare_command, >> .set_ios = dw_mci_exynos_set_ios, >> .parse_dt = dw_mci_exynos_parse_dt, >> + .post_init = dw_mci_exynos_post_init, >> .execute_tuning = dw_mci_exynos_execute_tuning, >> }; >> >> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c >> index f20b4b8..6f2c681 100644 >> --- a/drivers/mmc/host/dw_mmc.c >> +++ b/drivers/mmc/host/dw_mmc.c >> @@ -972,6 +972,22 @@ static void dw_mci_request(struct mmc_host *mmc, struct mmc_request *mrq) >> spin_unlock_bh(&host->lock); >> } >> >> +/* >> + * some of the boards use controller CD line for card detection.Unfortunately >> + * CD line is bind to the same volatge domain as of the IO lines.If we turn off >> + * IO voltage domain, CD line wont work. >> + * Return true when controller CD line is used for card detection or return >> + * false. >> + */ >> +static bool dw_mci_builtin_cd(struct dw_mci_slot *slot) >> +{ >> + struct dw_mci_board *brd = slot->host->pdata; >> + struct mmc_host *mmc = slot->mmc; >> + >> + return (!(brd->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION) && >> + IS_ERR_VALUE(mmc_gpio_get_cd(mmc))) ? 1 : 0; >> +} >> + >> static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) >> { >> struct dw_mci_slot *slot = mmc_priv(mmc); >> @@ -1043,6 +1059,10 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) >> mci_writel(slot->host, PWREN, regs); >> break; >> case MMC_POWER_OFF: >> + if (dw_mci_builtin_cd(slot) && >> + !test_bit(DW_MMC_CARD_PRESENT, &slot->flags)) >> + return; >> + >> if (!IS_ERR(mmc->supply.vmmc)) >> mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0); >> >> @@ -1055,6 +1075,8 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) >> regs &= ~(1 << slot->id); >> mci_writel(slot->host, PWREN, regs); >> break; >> + case MMC_POWER_OFF_HARD: >> + break; >> default: >> break; >> } >> @@ -2310,6 +2332,9 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id) >> else >> clear_bit(DW_MMC_CARD_PRESENT, &slot->flags); >> >> + if (drv_data && drv_data->post_init) >> + drv_data->post_init(slot); >> + >> ret = mmc_add_host(mmc); >> if (ret) >> goto err_setup_bus; >> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h >> index 01b99e8..a3c2628 100644 >> --- a/drivers/mmc/host/dw_mmc.h >> +++ b/drivers/mmc/host/dw_mmc.h >> @@ -250,6 +250,7 @@ struct dw_mci_tuning_data { >> * @prepare_command: handle CMD register extensions. >> * @set_ios: handle bus specific extensions. >> * @parse_dt: parse implementation specific device tree properties. >> + * @post_init: implementation specific post initialization. >> * @execute_tuning: implementation specific tuning procedure. >> * >> * Provide controller implementation specific extensions. The usage of this >> @@ -263,6 +264,7 @@ struct dw_mci_drv_data { >> void (*prepare_command)(struct dw_mci *host, u32 *cmdr); >> void (*set_ios)(struct dw_mci *host, struct mmc_ios *ios); >> int (*parse_dt)(struct dw_mci *host); >> + void (*post_init)(struct dw_mci_slot *slot); >> int (*execute_tuning)(struct dw_mci_slot *slot, u32 opcode, >> struct dw_mci_tuning_data *tuning_data); >> }; >> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h >> index 4cbf614..5eb24ff 100644 >> --- a/include/linux/mmc/host.h >> +++ b/include/linux/mmc/host.h >> @@ -42,6 +42,7 @@ struct mmc_ios { >> #define MMC_POWER_OFF 0 >> #define MMC_POWER_UP 1 >> #define MMC_POWER_ON 2 >> +#define MMC_POWER_OFF_HARD 3 >> >> unsigned char bus_width; /* data bus width */ >> >> @@ -283,6 +284,7 @@ struct mmc_host { >> #define MMC_CAP2_HS400 (MMC_CAP2_HS400_1_8V | \ >> MMC_CAP2_HS400_1_2V) >> #define MMC_CAP2_SDIO_IRQ_NOTHREAD (1 << 17) >> +#define MMC_CAP2_CD_NEEDS_POWER (1 << 18) /* Card detect needs power */ >> >> mmc_pm_flag_t pm_caps; /* supported pm features */ >> >> -- >> 1.7.10.4 >> ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 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:20 ` Doug Anderson 0 siblings, 2 replies; 43+ messages in thread From: Ulf Hansson @ 2014-08-25 8:13 UTC (permalink / raw) To: linux-arm-kernel On 22 August 2014 20:27, Sonny Rao <sonnyrao@chromium.org> wrote: > On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >> On 22 August 2014 15:47, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote: >>> Exynos 5250 and 5420 based boards uses built-in CD# line for card >>> detection.But unfortunately CD# line is on the same voltage rails >>> as of I/O voltage rails. When we cut off vqmmc,the consequent card >>> detection will break in these boards. >> >> I am not sure I follow here. >> >> Is the card detect mechanism handled internally by the dw_mmc controller? > > Yes Just out of curiosity. Do you know how the power to the actual dw_mmc controller is handled? I expect it to be SoC specific and I am guessing power domain regulators may be involved!? > >> >> I thought HW engineers long time ago realized that this should be done >> separately on a GPIO line to be able to save power while waiting for a >> card to be inserted. But that's not case then? > > At least in my limited experience, this seems to be common among SoC > vendors who are using dw_mmc, as we've seen this elsewhere as well and > after seeing it here we know that we need to ignore the CD pin that's > routed to dw_mmc and use a separately powered GPIO on the board, but > still there are probably many SoCs/boards which are doing it this way. > >>> >>> These hosts (obviously) need to keep vqmmc (and thus vmmc) on all the >>> time, even when the mmc core tells them to power off. However, one >>> problem is that these cards won't properly handle mmc_power_cycle(). >>> That's needed to handle error cases when trying to switch voltages >>> (see 0797e5f mmc:core: Fixup signal voltage switch). >>> >>> This patch adds a new MMC_POWER_OFF_HARD mode when it's doing a power >>> cycle. This mode differs from the normal MMC_POWER_OFF mode in that >>> the mmc core will promise to power the slot back on before it expects >>> the host to detect card insertion or removal. > > This patch is based off of one that Doug wrote (sent privately to > Yuvaraj) which just modifies the MMC core, and should be split into > two patches. > One that modifies the mmc core and one that implements this in dw_mmc. I looked at the mmc core parts, it seems like the wrong approach. I think you shall be able use MMC_CAP_NEEDS_POLL, to handle this broken card detect mechanism. We even have a DT binding for that, "broken-cd". Kind regards Uffe ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 2014-08-25 8:13 ` Ulf Hansson @ 2014-08-25 8:50 ` Jaehoon Chung 2014-08-25 15:25 ` Doug Anderson 2014-08-25 15:20 ` Doug Anderson 1 sibling, 1 reply; 43+ messages in thread From: Jaehoon Chung @ 2014-08-25 8:50 UTC (permalink / raw) To: linux-arm-kernel On 08/25/2014 05:13 PM, Ulf Hansson wrote: > On 22 August 2014 20:27, Sonny Rao <sonnyrao@chromium.org> wrote: >> On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>> On 22 August 2014 15:47, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote: >>>> Exynos 5250 and 5420 based boards uses built-in CD# line for card >>>> detection.But unfortunately CD# line is on the same voltage rails >>>> as of I/O voltage rails. When we cut off vqmmc,the consequent card >>>> detection will break in these boards. I didn't know that use CD# line for card detect. And if CD# voltage rails and I/O voltage rail are same voltage, it doesn't make sense. Which card is used with same voltages? (eMMC? SD? SDIO?) Well, I have checked Exynos5250 and 5420, but it looks like not same rails. >>> >>> I am not sure I follow here. >>> >>> Is the card detect mechanism handled internally by the dw_mmc controller? >> >> Yes What card detect mechanism? > > Just out of curiosity. > > Do you know how the power to the actual dw_mmc controller is handled? > I expect it to be SoC specific and I am guessing power domain > regulators may be involved!? > >> >>> >>> I thought HW engineers long time ago realized that this should be done >>> separately on a GPIO line to be able to save power while waiting for a >>> card to be inserted. But that's not case then? >> >> At least in my limited experience, this seems to be common among SoC >> vendors who are using dw_mmc, as we've seen this elsewhere as well and >> after seeing it here we know that we need to ignore the CD pin that's >> routed to dw_mmc and use a separately powered GPIO on the board, but >> still there are probably many SoCs/boards which are doing it this way. >> >>>> >>>> These hosts (obviously) need to keep vqmmc (and thus vmmc) on all the >>>> time, even when the mmc core tells them to power off. However, one >>>> problem is that these cards won't properly handle mmc_power_cycle(). >>>> That's needed to handle error cases when trying to switch voltages >>>> (see 0797e5f mmc:core: Fixup signal voltage switch). >>>> >>>> This patch adds a new MMC_POWER_OFF_HARD mode when it's doing a power >>>> cycle. This mode differs from the normal MMC_POWER_OFF mode in that >>>> the mmc core will promise to power the slot back on before it expects >>>> the host to detect card insertion or removal. >> >> This patch is based off of one that Doug wrote (sent privately to >> Yuvaraj) which just modifies the MMC core, and should be split into >> two patches. >> One that modifies the mmc core and one that implements this in dw_mmc. > > I looked at the mmc core parts, it seems like the wrong approach. > > I think you shall be able use MMC_CAP_NEEDS_POLL, to handle this > broken card detect mechanism. We even have a DT binding for that, > "broken-cd". I agreed with Ulf's opinion. Best Regards, Jaehoon Chung > > Kind regards > Uffe > ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 2014-08-25 8:50 ` Jaehoon Chung @ 2014-08-25 15:25 ` Doug Anderson 2014-08-27 3:48 ` Jaehoon Chung 0 siblings, 1 reply; 43+ messages in thread From: Doug Anderson @ 2014-08-25 15:25 UTC (permalink / raw) To: linux-arm-kernel Jaehoon, On Mon, Aug 25, 2014 at 1:50 AM, Jaehoon Chung <jh80.chung@samsung.com> wrote: > On 08/25/2014 05:13 PM, Ulf Hansson wrote: >> On 22 August 2014 20:27, Sonny Rao <sonnyrao@chromium.org> wrote: >>> On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>>> On 22 August 2014 15:47, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote: >>>>> Exynos 5250 and 5420 based boards uses built-in CD# line for card >>>>> detection.But unfortunately CD# line is on the same voltage rails >>>>> as of I/O voltage rails. When we cut off vqmmc,the consequent card >>>>> detection will break in these boards. > > I didn't know that use CD# line for card detect. > And if CD# voltage rails and I/O voltage rail are same voltage, it doesn't make sense. > Which card is used with same voltages? (eMMC? SD? SDIO?) > > Well, I have checked Exynos5250 and 5420, but it looks like not same rails. I'm not sure I totally understood what you said. In my manual I have a table titled "Table 2-1 Exynos 5420 Pin List". Look in this table for XMMC2CDN and XMMC2DATA_0. Look to the right of the table and you'll see the power domain. For both it shows VDDQ_MMC2. If that doesn't mean that the two are in the same voltage domain then I don't know what does. Can you point to any examples where they have different voltage domains? I agree that what exynos does is not sensible, but that's what it is. >>>> I am not sure I follow here. >>>> >>>> Is the card detect mechanism handled internally by the dw_mmc controller? >>> >>> Yes > > What card detect mechanism? The dw_mmc controller has a way to read the card detect, right? That's internal to the controller. The alternative would be to use a generic GPIO for card detect. ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 2014-08-25 15:25 ` Doug Anderson @ 2014-08-27 3:48 ` Jaehoon Chung 2014-08-27 4:14 ` Doug Anderson 0 siblings, 1 reply; 43+ messages in thread From: Jaehoon Chung @ 2014-08-27 3:48 UTC (permalink / raw) To: linux-arm-kernel Hi, Doug, On 08/26/2014 12:25 AM, Doug Anderson wrote: > Jaehoon, > > On Mon, Aug 25, 2014 at 1:50 AM, Jaehoon Chung <jh80.chung@samsung.com> wrote: >> On 08/25/2014 05:13 PM, Ulf Hansson wrote: >>> On 22 August 2014 20:27, Sonny Rao <sonnyrao@chromium.org> wrote: >>>> On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>>>> On 22 August 2014 15:47, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote: >>>>>> Exynos 5250 and 5420 based boards uses built-in CD# line for card >>>>>> detection.But unfortunately CD# line is on the same voltage rails >>>>>> as of I/O voltage rails. When we cut off vqmmc,the consequent card >>>>>> detection will break in these boards. >> >> I didn't know that use CD# line for card detect. >> And if CD# voltage rails and I/O voltage rail are same voltage, it doesn't make sense. >> Which card is used with same voltages? (eMMC? SD? SDIO?) >> >> Well, I have checked Exynos5250 and 5420, but it looks like not same rails. > > I'm not sure I totally understood what you said. In my manual I have > a table titled "Table 2-1 Exynos 5420 Pin List". Look in this table > for XMMC2CDN and XMMC2DATA_0. Look to the right of the table and > you'll see the power domain. For both it shows VDDQ_MMC2. If that > doesn't mean that the two are in the same voltage domain then I don't > know what does. Can you point to any examples where they have > different voltage domains? I think you're mis-understanding for it. Right, It's described at exynos5420, but it's not connected. Exynos4 series are also described, but we used the broken card detection scheme and power used one of "always-on" powers. Because Card-detection rail need to enable as "always-on". We don't need to consider this. I checked the circuit, this patch didn't need. exynos5 also used the gpio-pin for card-detection. And we can use the slot-gpio API. Best Regards, Jaehoon Chung > > I agree that what exynos does is not sensible, but that's what it is. > > >>>>> I am not sure I follow here. >>>>> >>>>> Is the card detect mechanism handled internally by the dw_mmc controller? >>>> >>>> Yes >> >> What card detect mechanism? > > The dw_mmc controller has a way to read the card detect, right? > That's internal to the controller. The alternative would be to use a > generic GPIO for card detect. > ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 2014-08-27 3:48 ` Jaehoon Chung @ 2014-08-27 4:14 ` Doug Anderson 2014-08-27 4:47 ` Jaehoon Chung 0 siblings, 1 reply; 43+ messages in thread From: Doug Anderson @ 2014-08-27 4:14 UTC (permalink / raw) To: linux-arm-kernel Jaehoon, On Tue, Aug 26, 2014 at 8:48 PM, Jaehoon Chung <jh80.chung@samsung.com> wrote: > Hi, Doug, > > On 08/26/2014 12:25 AM, Doug Anderson wrote: >> Jaehoon, >> >> On Mon, Aug 25, 2014 at 1:50 AM, Jaehoon Chung <jh80.chung@samsung.com> wrote: >>> On 08/25/2014 05:13 PM, Ulf Hansson wrote: >>>> On 22 August 2014 20:27, Sonny Rao <sonnyrao@chromium.org> wrote: >>>>> On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>>>>> On 22 August 2014 15:47, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote: >>>>>>> Exynos 5250 and 5420 based boards uses built-in CD# line for card >>>>>>> detection.But unfortunately CD# line is on the same voltage rails >>>>>>> as of I/O voltage rails. When we cut off vqmmc,the consequent card >>>>>>> detection will break in these boards. >>> >>> I didn't know that use CD# line for card detect. >>> And if CD# voltage rails and I/O voltage rail are same voltage, it doesn't make sense. >>> Which card is used with same voltages? (eMMC? SD? SDIO?) >>> >>> Well, I have checked Exynos5250 and 5420, but it looks like not same rails. >> >> I'm not sure I totally understood what you said. In my manual I have >> a table titled "Table 2-1 Exynos 5420 Pin List". Look in this table >> for XMMC2CDN and XMMC2DATA_0. Look to the right of the table and >> you'll see the power domain. For both it shows VDDQ_MMC2. If that >> doesn't mean that the two are in the same voltage domain then I don't >> know what does. Can you point to any examples where they have >> different voltage domains? > I think you're mis-understanding for it. > Right, It's described at exynos5420, but it's not connected. "It's not connected". What do you mean? If I were to guess I'd say that on some particular board you're looking at they don't happen to use the "CD" pin for card detect. If this is what you mean, it doesn't help me. exynos5420-peach-pit does use the CD pin for card detect. You can look at the DTS file and confirm it. ...or are you saying that the CD pin somehow changes voltage domains when configured as a GPIO? I find that very hard to believe. What voltage domain does it go to? If it goes to a 1.8V voltage domain then that would be bad when vqmmc was 3.3V. If it goes to a 3.3V voltage domain then that would be bad when vqmmc was 1.8V. Remember that externally we've got a pull up to vqmmc. Even if somehow magically we can read the card detect pin with vqmmc off, we have an external pullup on this line that goes directly to the "vqmmc" power rail. If the vqmmc power rail is off then this external pull up would not work and would actually act as an external pull down if you could somehow configure the internal line to be a pullup. > Exynos4 series are also described, but we used the broken card detection scheme and power used one of "always-on" powers. > Because Card-detection rail need to enable as "always-on". > > We don't need to consider this. I checked the circuit, this patch didn't need. > > exynos5 also used the gpio-pin for card-detection. And we can use the slot-gpio API. When you say "exynos5", what do you mean here? Do you mean the smdk for 5250, or something else? ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 2014-08-27 4:14 ` Doug Anderson @ 2014-08-27 4:47 ` Jaehoon Chung 2014-08-27 15:49 ` Doug Anderson 0 siblings, 1 reply; 43+ messages in thread From: Jaehoon Chung @ 2014-08-27 4:47 UTC (permalink / raw) To: linux-arm-kernel Doug, On 08/27/2014 01:14 PM, Doug Anderson wrote: > Jaehoon, > > On Tue, Aug 26, 2014 at 8:48 PM, Jaehoon Chung <jh80.chung@samsung.com> wrote: >> Hi, Doug, >> >> On 08/26/2014 12:25 AM, Doug Anderson wrote: >>> Jaehoon, >>> >>> On Mon, Aug 25, 2014 at 1:50 AM, Jaehoon Chung <jh80.chung@samsung.com> wrote: >>>> On 08/25/2014 05:13 PM, Ulf Hansson wrote: >>>>> On 22 August 2014 20:27, Sonny Rao <sonnyrao@chromium.org> wrote: >>>>>> On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>>>>>> On 22 August 2014 15:47, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote: >>>>>>>> Exynos 5250 and 5420 based boards uses built-in CD# line for card >>>>>>>> detection.But unfortunately CD# line is on the same voltage rails >>>>>>>> as of I/O voltage rails. When we cut off vqmmc,the consequent card >>>>>>>> detection will break in these boards. >>>> >>>> I didn't know that use CD# line for card detect. >>>> And if CD# voltage rails and I/O voltage rail are same voltage, it doesn't make sense. >>>> Which card is used with same voltages? (eMMC? SD? SDIO?) >>>> >>>> Well, I have checked Exynos5250 and 5420, but it looks like not same rails. >>> >>> I'm not sure I totally understood what you said. In my manual I have >>> a table titled "Table 2-1 Exynos 5420 Pin List". Look in this table >>> for XMMC2CDN and XMMC2DATA_0. Look to the right of the table and >>> you'll see the power domain. For both it shows VDDQ_MMC2. If that >>> doesn't mean that the two are in the same voltage domain then I don't >>> know what does. Can you point to any examples where they have >>> different voltage domains? >> I think you're mis-understanding for it. >> Right, It's described at exynos5420, but it's not connected. > > "It's not connected". What do you mean? If I were to guess I'd say > that on some particular board you're looking at they don't happen to > use the "CD" pin for card detect. If this is what you mean, it > doesn't help me. exynos5420-peach-pit does use the CD pin for card > detect. You can look at the DTS file and confirm it. I didn't know how exynos5420-peach-pit's circuit is configured. But i guess that almost all exynos5 boards are configured with the similar circuit. At Almost all Exynos5 board, CD-pin is used, but not included in Same power domain. (CD-pin is external card-detect pin. - like XEINT_# pin) You mentioned CD# and DATA# lines is used the same power domain, right? In Circuit (not exynos5420-peach-pit), DATA# line and CMD/CLK(vqmmc) is same power supply, and vdd is used other power supply. Not use the CD# pin, used the XEINT_# pin. So i think we don't need to consider the CD#. If exynos5420-peach-pit board is used the CD#-pin, then our discussion can be changed. Your commit message looks like all exynos5250/5420 board are used CD# line. > > ...or are you saying that the CD pin somehow changes voltage domains > when configured as a GPIO? I find that very hard to believe. What > voltage domain does it go to? If it goes to a 1.8V voltage domain > then that would be bad when vqmmc was 3.3V. If it goes to a 3.3V > voltage domain then that would be bad when vqmmc was 1.8V. Remember > that externally we've got a pull up to vqmmc. It is used with XEINT_# pin instead of CD# pin. As i mentioned above, if exynos5420-peach-pit is used CD# line and not used XEINT_# pin, my point is meaningless. :) Is exynos5420-peach-pit board used with CD#pin, not XEINT_# pin? Best Regards, Jaehoon Chung > > Even if somehow magically we can read the card detect pin with vqmmc > off, we have an external pullup on this line that goes directly to the > "vqmmc" power rail. If the vqmmc power rail is off then this external > pull up would not work and would actually act as an external pull down > if you could somehow configure the internal line to be a pullup. > > >> Exynos4 series are also described, but we used the broken card detection scheme and power used one of "always-on" powers. >> Because Card-detection rail need to enable as "always-on". >> >> We don't need to consider this. I checked the circuit, this patch didn't need. >> >> exynos5 also used the gpio-pin for card-detection. And we can use the slot-gpio API. > > When you say "exynos5", what do you mean here? Do you mean the smdk > for 5250, or something else? > ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 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 0 siblings, 2 replies; 43+ messages in thread From: Doug Anderson @ 2014-08-27 15:49 UTC (permalink / raw) To: linux-arm-kernel Jaehoon, On Tue, Aug 26, 2014 at 9:47 PM, Jaehoon Chung <jh80.chung@samsung.com> wrote: > Doug, > > On 08/27/2014 01:14 PM, Doug Anderson wrote: >> Jaehoon, >> >> On Tue, Aug 26, 2014 at 8:48 PM, Jaehoon Chung <jh80.chung@samsung.com> wrote: >>> Hi, Doug, >>> >>> On 08/26/2014 12:25 AM, Doug Anderson wrote: >>>> Jaehoon, >>>> >>>> On Mon, Aug 25, 2014 at 1:50 AM, Jaehoon Chung <jh80.chung@samsung.com> wrote: >>>>> On 08/25/2014 05:13 PM, Ulf Hansson wrote: >>>>>> On 22 August 2014 20:27, Sonny Rao <sonnyrao@chromium.org> wrote: >>>>>>> On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>>>>>>> On 22 August 2014 15:47, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote: >>>>>>>>> Exynos 5250 and 5420 based boards uses built-in CD# line for card >>>>>>>>> detection.But unfortunately CD# line is on the same voltage rails >>>>>>>>> as of I/O voltage rails. When we cut off vqmmc,the consequent card >>>>>>>>> detection will break in these boards. >>>>> >>>>> I didn't know that use CD# line for card detect. >>>>> And if CD# voltage rails and I/O voltage rail are same voltage, it doesn't make sense. >>>>> Which card is used with same voltages? (eMMC? SD? SDIO?) >>>>> >>>>> Well, I have checked Exynos5250 and 5420, but it looks like not same rails. >>>> >>>> I'm not sure I totally understood what you said. In my manual I have >>>> a table titled "Table 2-1 Exynos 5420 Pin List". Look in this table >>>> for XMMC2CDN and XMMC2DATA_0. Look to the right of the table and >>>> you'll see the power domain. For both it shows VDDQ_MMC2. If that >>>> doesn't mean that the two are in the same voltage domain then I don't >>>> know what does. Can you point to any examples where they have >>>> different voltage domains? >>> I think you're mis-understanding for it. >>> Right, It's described at exynos5420, but it's not connected. >> >> "It's not connected". What do you mean? If I were to guess I'd say >> that on some particular board you're looking at they don't happen to >> use the "CD" pin for card detect. If this is what you mean, it >> doesn't help me. exynos5420-peach-pit does use the CD pin for card >> detect. You can look at the DTS file and confirm it. > > I didn't know how exynos5420-peach-pit's circuit is configured. > But i guess that almost all exynos5 boards are configured with the similar circuit. > > At Almost all Exynos5 board, CD-pin is used, but not included in Same power domain. > (CD-pin is external card-detect pin. - like XEINT_# pin) > You mentioned CD# and DATA# lines is used the same power domain, right? > In Circuit (not exynos5420-peach-pit), DATA# line and CMD/CLK(vqmmc) is same power supply, and vdd is used other power supply. > Not use the CD# pin, used the XEINT_# pin. > So i think we don't need to consider the CD#. > If exynos5420-peach-pit board is used the CD#-pin, then our discussion can be changed. Maybe on your board you have CD connected to a "gpx" line. ...but not mine. The guys who designed our hardware followed the SMDK5420 reference schematics which connect the SD card slot card detect to "gpc2_2", which is the card detect pin. See "arch/arm/boot/dts/exynos5420-smdk5420.dts", specifically noting the lack of a GPIO card detect and the inclusion of "sd2_cd" mmc at 12220000 { status = "okay"; card-detect-delay = <200>; samsung,dw-mshc-ciu-div = <3>; samsung,dw-mshc-sdr-timing = <2 3>; samsung,dw-mshc-ddr-timing = <1 2>; pinctrl-names = "default"; pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>; bus-width = <4>; cap-sd-highspeed; }; See "arch/arm/boot/dts/exynos5420-peach-pit.dts" too: &mmc_2 { status = "okay"; num-slots = <1>; cap-sd-highspeed; card-detect-delay = <200>; clock-frequency = <400000000>; samsung,dw-mshc-ciu-div = <3>; samsung,dw-mshc-sdr-timing = <2 3>; samsung,dw-mshc-ddr-timing = <1 2>; pinctrl-names = "default"; pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>; bus-width = <4>; }; Here, see this ASCII art that shows how some lines are hooked up on peach-pit. You might need to paste this into something with a fixed-width font. +-------------------- | Exynos 5420 | | P2.8V_LOUT4 ---------|- VDDQ_MMC2 (AK7) | | | | +-+- 10K res -+----|- XMMC2CDN (AK6) | | | | | | | | | | Ext CD | | | +-- 10K res-+--+---|- XMMC2CMD (AK8) | | Ext CMD You can see from the above that the external card detect signal (that goes to the connector) named "Ext CD" is pulled up to the same voltage as the external CMD signal (that also goes to the connector). This is vqmmc. If we turn off vqmmc then the 10K resistor will (I think) act as a pull down, or in the best case it will be floating. Said another way: we can't read card detect when vqmmc is off. > Your commit message looks like all exynos5250/5420 board are used CD# line. The commit message should be clearer, agreed. I think I asked Yuvaraj to make sure that the code only invoked this quirk on exynos and only if a GPIO was not used for card detect. Yuvaraj: can you make it more obvious that not all exynos5250/5420 boards need this, only those that use the "official" card detect line? >> ...or are you saying that the CD pin somehow changes voltage domains >> when configured as a GPIO? I find that very hard to believe. What >> voltage domain does it go to? If it goes to a 1.8V voltage domain >> then that would be bad when vqmmc was 3.3V. If it goes to a 3.3V >> voltage domain then that would be bad when vqmmc was 1.8V. Remember >> that externally we've got a pull up to vqmmc. > > It is used with XEINT_# pin instead of CD# pin. > As i mentioned above, if exynos5420-peach-pit is used CD# line and not used XEINT_# pin, > my point is meaningless. :) > > Is exynos5420-peach-pit board used with CD#pin, not XEINT_# pin? Yes. It is using CD#. Do you remove your objections to this patch, then (once the commit message is clearer)? -Doug ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 2014-08-27 15:49 ` Doug Anderson @ 2014-08-28 4:54 ` Yuvaraj Kumar 2014-08-28 8:43 ` Jaehoon Chung 1 sibling, 0 replies; 43+ messages in thread From: Yuvaraj Kumar @ 2014-08-28 4:54 UTC (permalink / raw) To: linux-arm-kernel On Wed, Aug 27, 2014 at 9:19 PM, Doug Anderson <dianders@google.com> wrote: > Jaehoon, > > On Tue, Aug 26, 2014 at 9:47 PM, Jaehoon Chung <jh80.chung@samsung.com> wrote: >> Doug, >> >> On 08/27/2014 01:14 PM, Doug Anderson wrote: >>> Jaehoon, >>> >>> On Tue, Aug 26, 2014 at 8:48 PM, Jaehoon Chung <jh80.chung@samsung.com> wrote: >>>> Hi, Doug, >>>> >>>> On 08/26/2014 12:25 AM, Doug Anderson wrote: >>>>> Jaehoon, >>>>> >>>>> On Mon, Aug 25, 2014 at 1:50 AM, Jaehoon Chung <jh80.chung@samsung.com> wrote: >>>>>> On 08/25/2014 05:13 PM, Ulf Hansson wrote: >>>>>>> On 22 August 2014 20:27, Sonny Rao <sonnyrao@chromium.org> wrote: >>>>>>>> On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>>>>>>>> On 22 August 2014 15:47, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote: >>>>>>>>>> Exynos 5250 and 5420 based boards uses built-in CD# line for card >>>>>>>>>> detection.But unfortunately CD# line is on the same voltage rails >>>>>>>>>> as of I/O voltage rails. When we cut off vqmmc,the consequent card >>>>>>>>>> detection will break in these boards. >>>>>> >>>>>> I didn't know that use CD# line for card detect. >>>>>> And if CD# voltage rails and I/O voltage rail are same voltage, it doesn't make sense. >>>>>> Which card is used with same voltages? (eMMC? SD? SDIO?) >>>>>> >>>>>> Well, I have checked Exynos5250 and 5420, but it looks like not same rails. >>>>> >>>>> I'm not sure I totally understood what you said. In my manual I have >>>>> a table titled "Table 2-1 Exynos 5420 Pin List". Look in this table >>>>> for XMMC2CDN and XMMC2DATA_0. Look to the right of the table and >>>>> you'll see the power domain. For both it shows VDDQ_MMC2. If that >>>>> doesn't mean that the two are in the same voltage domain then I don't >>>>> know what does. Can you point to any examples where they have >>>>> different voltage domains? >>>> I think you're mis-understanding for it. >>>> Right, It's described at exynos5420, but it's not connected. >>> >>> "It's not connected". What do you mean? If I were to guess I'd say >>> that on some particular board you're looking at they don't happen to >>> use the "CD" pin for card detect. If this is what you mean, it >>> doesn't help me. exynos5420-peach-pit does use the CD pin for card >>> detect. You can look at the DTS file and confirm it. >> >> I didn't know how exynos5420-peach-pit's circuit is configured. >> But i guess that almost all exynos5 boards are configured with the similar circuit. >> >> At Almost all Exynos5 board, CD-pin is used, but not included in Same power domain. >> (CD-pin is external card-detect pin. - like XEINT_# pin) >> You mentioned CD# and DATA# lines is used the same power domain, right? >> In Circuit (not exynos5420-peach-pit), DATA# line and CMD/CLK(vqmmc) is same power supply, and vdd is used other power supply. >> Not use the CD# pin, used the XEINT_# pin. >> So i think we don't need to consider the CD#. >> If exynos5420-peach-pit board is used the CD#-pin, then our discussion can be changed. > > Maybe on your board you have CD connected to a "gpx" line. ...but not > mine. The guys who designed our hardware followed the SMDK5420 > reference schematics which connect the SD card slot card detect to > "gpc2_2", which is the card detect pin. > > See "arch/arm/boot/dts/exynos5420-smdk5420.dts", specifically noting > the lack of a GPIO card detect and the inclusion of "sd2_cd" > > mmc at 12220000 { > status = "okay"; > card-detect-delay = <200>; > samsung,dw-mshc-ciu-div = <3>; > samsung,dw-mshc-sdr-timing = <2 3>; > samsung,dw-mshc-ddr-timing = <1 2>; > pinctrl-names = "default"; > pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>; > bus-width = <4>; > cap-sd-highspeed; > }; > > See "arch/arm/boot/dts/exynos5420-peach-pit.dts" too: > > &mmc_2 { > status = "okay"; > num-slots = <1>; > cap-sd-highspeed; > card-detect-delay = <200>; > clock-frequency = <400000000>; > samsung,dw-mshc-ciu-div = <3>; > samsung,dw-mshc-sdr-timing = <2 3>; > samsung,dw-mshc-ddr-timing = <1 2>; > pinctrl-names = "default"; > pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>; > bus-width = <4>; > }; > > > Here, see this ASCII art that shows how some lines are hooked up on > peach-pit. You might need to paste this into something with a > fixed-width font. > > +-------------------- > | Exynos 5420 > | > | > P2.8V_LOUT4 ---------|- VDDQ_MMC2 (AK7) > | | > | | > +-+- 10K res -+----|- XMMC2CDN (AK6) > | | | > | | | > | | | > | Ext CD | > | | > +-- 10K res-+--+---|- XMMC2CMD (AK8) > | > | > Ext CMD > > You can see from the above that the external card detect signal (that > goes to the connector) named "Ext CD" is pulled up to the same voltage > as the external CMD signal (that also goes to the connector). This is > vqmmc. If we turn off vqmmc then the 10K resistor will (I think) act > as a pull down, or in the best case it will be floating. > > Said another way: we can't read card detect when vqmmc is off. > >> Your commit message looks like all exynos5250/5420 board are used CD# line. > > The commit message should be clearer, agreed. I think I asked Yuvaraj > to make sure that the code only invoked this quirk on exynos and only > if a GPIO was not used for card detect. Yuvaraj: can you make it more > obvious that not all exynos5250/5420 boards need this, only those that > use the "official" card detect line? if (!(brd->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION) && IS_ERR_VALUE(mmc_gpio_get_cd(mmc))) This check will not enable the quirk, if a GPIO was used for the card detect.Did I miss something? I will change the commit message to exclude "all exynos5250/5420 boards". > > >>> ...or are you saying that the CD pin somehow changes voltage domains >>> when configured as a GPIO? I find that very hard to believe. What >>> voltage domain does it go to? If it goes to a 1.8V voltage domain >>> then that would be bad when vqmmc was 3.3V. If it goes to a 3.3V >>> voltage domain then that would be bad when vqmmc was 1.8V. Remember >>> that externally we've got a pull up to vqmmc. >> >> It is used with XEINT_# pin instead of CD# pin. >> As i mentioned above, if exynos5420-peach-pit is used CD# line and not used XEINT_# pin, >> my point is meaningless. :) >> >> Is exynos5420-peach-pit board used with CD#pin, not XEINT_# pin? > > Yes. It is using CD#. Do you remove your objections to this patch, > then (once the commit message is clearer)? > > -Doug ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 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 1 sibling, 1 reply; 43+ messages in thread From: Jaehoon Chung @ 2014-08-28 8:43 UTC (permalink / raw) To: linux-arm-kernel On 08/28/2014 12:49 AM, Doug Anderson wrote: > Jaehoon, > > On Tue, Aug 26, 2014 at 9:47 PM, Jaehoon Chung <jh80.chung@samsung.com> wrote: >> Doug, >> >> On 08/27/2014 01:14 PM, Doug Anderson wrote: >>> Jaehoon, >>> >>> On Tue, Aug 26, 2014 at 8:48 PM, Jaehoon Chung <jh80.chung@samsung.com> wrote: >>>> Hi, Doug, >>>> >>>> On 08/26/2014 12:25 AM, Doug Anderson wrote: >>>>> Jaehoon, >>>>> >>>>> On Mon, Aug 25, 2014 at 1:50 AM, Jaehoon Chung <jh80.chung@samsung.com> wrote: >>>>>> On 08/25/2014 05:13 PM, Ulf Hansson wrote: >>>>>>> On 22 August 2014 20:27, Sonny Rao <sonnyrao@chromium.org> wrote: >>>>>>>> On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>>>>>>>> On 22 August 2014 15:47, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote: >>>>>>>>>> Exynos 5250 and 5420 based boards uses built-in CD# line for card >>>>>>>>>> detection.But unfortunately CD# line is on the same voltage rails >>>>>>>>>> as of I/O voltage rails. When we cut off vqmmc,the consequent card >>>>>>>>>> detection will break in these boards. >>>>>> >>>>>> I didn't know that use CD# line for card detect. >>>>>> And if CD# voltage rails and I/O voltage rail are same voltage, it doesn't make sense. >>>>>> Which card is used with same voltages? (eMMC? SD? SDIO?) >>>>>> >>>>>> Well, I have checked Exynos5250 and 5420, but it looks like not same rails. >>>>> >>>>> I'm not sure I totally understood what you said. In my manual I have >>>>> a table titled "Table 2-1 Exynos 5420 Pin List". Look in this table >>>>> for XMMC2CDN and XMMC2DATA_0. Look to the right of the table and >>>>> you'll see the power domain. For both it shows VDDQ_MMC2. If that >>>>> doesn't mean that the two are in the same voltage domain then I don't >>>>> know what does. Can you point to any examples where they have >>>>> different voltage domains? >>>> I think you're mis-understanding for it. >>>> Right, It's described at exynos5420, but it's not connected. >>> >>> "It's not connected". What do you mean? If I were to guess I'd say >>> that on some particular board you're looking at they don't happen to >>> use the "CD" pin for card detect. If this is what you mean, it >>> doesn't help me. exynos5420-peach-pit does use the CD pin for card >>> detect. You can look at the DTS file and confirm it. >> >> I didn't know how exynos5420-peach-pit's circuit is configured. >> But i guess that almost all exynos5 boards are configured with the similar circuit. >> >> At Almost all Exynos5 board, CD-pin is used, but not included in Same power domain. >> (CD-pin is external card-detect pin. - like XEINT_# pin) >> You mentioned CD# and DATA# lines is used the same power domain, right? >> In Circuit (not exynos5420-peach-pit), DATA# line and CMD/CLK(vqmmc) is same power supply, and vdd is used other power supply. >> Not use the CD# pin, used the XEINT_# pin. >> So i think we don't need to consider the CD#. >> If exynos5420-peach-pit board is used the CD#-pin, then our discussion can be changed. > > Maybe on your board you have CD connected to a "gpx" line. ...but not > mine. The guys who designed our hardware followed the SMDK5420 > reference schematics which connect the SD card slot card detect to > "gpc2_2", which is the card detect pin. > > See "arch/arm/boot/dts/exynos5420-smdk5420.dts", specifically noting > the lack of a GPIO card detect and the inclusion of "sd2_cd" > > mmc at 12220000 { > status = "okay"; > card-detect-delay = <200>; > samsung,dw-mshc-ciu-div = <3>; > samsung,dw-mshc-sdr-timing = <2 3>; > samsung,dw-mshc-ddr-timing = <1 2>; > pinctrl-names = "default"; > pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>; > bus-width = <4>; > cap-sd-highspeed; > }; > > See "arch/arm/boot/dts/exynos5420-peach-pit.dts" too: > > &mmc_2 { > status = "okay"; > num-slots = <1>; > cap-sd-highspeed; > card-detect-delay = <200>; > clock-frequency = <400000000>; > samsung,dw-mshc-ciu-div = <3>; > samsung,dw-mshc-sdr-timing = <2 3>; > samsung,dw-mshc-ddr-timing = <1 2>; > pinctrl-names = "default"; > pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>; > bus-width = <4>; > }; > > > Here, see this ASCII art that shows how some lines are hooked up on > peach-pit. You might need to paste this into something with a > fixed-width font. > > +-------------------- > | Exynos 5420 > | > | > P2.8V_LOUT4 ---------|- VDDQ_MMC2 (AK7) > | | > | | > +-+- 10K res -+----|- XMMC2CDN (AK6) > | | | > | | | > | | | > | Ext CD | > | | > +-- 10K res-+--+---|- XMMC2CMD (AK8) > | > | > Ext CMD > > You can see from the above that the external card detect signal (that > goes to the connector) named "Ext CD" is pulled up to the same voltage > as the external CMD signal (that also goes to the connector). This is > vqmmc. If we turn off vqmmc then the 10K resistor will (I think) act > as a pull down, or in the best case it will be floating. > > Said another way: we can't read card detect when vqmmc is off. If that's the case, it makes sense. But i wonder why designed like that. Anyway, then we need to consider that controls the vqmmc power for card-detection. But if polling system uses, it seems to detect the card. Polling is the method that sends the status command. At that time, we can notice whether card is insert/remove. Is it impossible? > >> Your commit message looks like all exynos5250/5420 board are used CD# line. > > The commit message should be clearer, agreed. I think I asked Yuvaraj > to make sure that the code only invoked this quirk on exynos and only > if a GPIO was not used for card detect. Yuvaraj: can you make it more > obvious that not all exynos5250/5420 boards need this, only those that > use the "official" card detect line? > > >>> ...or are you saying that the CD pin somehow changes voltage domains >>> when configured as a GPIO? I find that very hard to believe. What >>> voltage domain does it go to? If it goes to a 1.8V voltage domain >>> then that would be bad when vqmmc was 3.3V. If it goes to a 3.3V >>> voltage domain then that would be bad when vqmmc was 1.8V. Remember >>> that externally we've got a pull up to vqmmc. >> >> It is used with XEINT_# pin instead of CD# pin. >> As i mentioned above, if exynos5420-peach-pit is used CD# line and not used XEINT_# pin, >> my point is meaningless. :) >> >> Is exynos5420-peach-pit board used with CD#pin, not XEINT_# pin? > > Yes. It is using CD#. Do you remove your objections to this patch, > then (once the commit message is clearer)? Sure. And I will also effort to find it, if we can find the more generic approach. Best Regards, Jaehoon Chung > > -Doug > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 2014-08-28 8:43 ` Jaehoon Chung @ 2014-08-28 15:52 ` Doug Anderson 0 siblings, 0 replies; 43+ messages in thread From: Doug Anderson @ 2014-08-28 15:52 UTC (permalink / raw) To: linux-arm-kernel Jaehoon, On Thu, Aug 28, 2014 at 1:43 AM, Jaehoon Chung <jh80.chung@samsung.com> wrote: > On 08/28/2014 12:49 AM, Doug Anderson wrote: >> Jaehoon, >> >> On Tue, Aug 26, 2014 at 9:47 PM, Jaehoon Chung <jh80.chung@samsung.com> wrote: >>> Doug, >>> >>> On 08/27/2014 01:14 PM, Doug Anderson wrote: >>>> Jaehoon, >>>> >>>> On Tue, Aug 26, 2014 at 8:48 PM, Jaehoon Chung <jh80.chung@samsung.com> wrote: >>>>> Hi, Doug, >>>>> >>>>> On 08/26/2014 12:25 AM, Doug Anderson wrote: >>>>>> Jaehoon, >>>>>> >>>>>> On Mon, Aug 25, 2014 at 1:50 AM, Jaehoon Chung <jh80.chung@samsung.com> wrote: >>>>>>> On 08/25/2014 05:13 PM, Ulf Hansson wrote: >>>>>>>> On 22 August 2014 20:27, Sonny Rao <sonnyrao@chromium.org> wrote: >>>>>>>>> On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>>>>>>>>> On 22 August 2014 15:47, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote: >>>>>>>>>>> Exynos 5250 and 5420 based boards uses built-in CD# line for card >>>>>>>>>>> detection.But unfortunately CD# line is on the same voltage rails >>>>>>>>>>> as of I/O voltage rails. When we cut off vqmmc,the consequent card >>>>>>>>>>> detection will break in these boards. >>>>>>> >>>>>>> I didn't know that use CD# line for card detect. >>>>>>> And if CD# voltage rails and I/O voltage rail are same voltage, it doesn't make sense. >>>>>>> Which card is used with same voltages? (eMMC? SD? SDIO?) >>>>>>> >>>>>>> Well, I have checked Exynos5250 and 5420, but it looks like not same rails. >>>>>> >>>>>> I'm not sure I totally understood what you said. In my manual I have >>>>>> a table titled "Table 2-1 Exynos 5420 Pin List". Look in this table >>>>>> for XMMC2CDN and XMMC2DATA_0. Look to the right of the table and >>>>>> you'll see the power domain. For both it shows VDDQ_MMC2. If that >>>>>> doesn't mean that the two are in the same voltage domain then I don't >>>>>> know what does. Can you point to any examples where they have >>>>>> different voltage domains? >>>>> I think you're mis-understanding for it. >>>>> Right, It's described at exynos5420, but it's not connected. >>>> >>>> "It's not connected". What do you mean? If I were to guess I'd say >>>> that on some particular board you're looking at they don't happen to >>>> use the "CD" pin for card detect. If this is what you mean, it >>>> doesn't help me. exynos5420-peach-pit does use the CD pin for card >>>> detect. You can look at the DTS file and confirm it. >>> >>> I didn't know how exynos5420-peach-pit's circuit is configured. >>> But i guess that almost all exynos5 boards are configured with the similar circuit. >>> >>> At Almost all Exynos5 board, CD-pin is used, but not included in Same power domain. >>> (CD-pin is external card-detect pin. - like XEINT_# pin) >>> You mentioned CD# and DATA# lines is used the same power domain, right? >>> In Circuit (not exynos5420-peach-pit), DATA# line and CMD/CLK(vqmmc) is same power supply, and vdd is used other power supply. >>> Not use the CD# pin, used the XEINT_# pin. >>> So i think we don't need to consider the CD#. >>> If exynos5420-peach-pit board is used the CD#-pin, then our discussion can be changed. >> >> Maybe on your board you have CD connected to a "gpx" line. ...but not >> mine. The guys who designed our hardware followed the SMDK5420 >> reference schematics which connect the SD card slot card detect to >> "gpc2_2", which is the card detect pin. >> >> See "arch/arm/boot/dts/exynos5420-smdk5420.dts", specifically noting >> the lack of a GPIO card detect and the inclusion of "sd2_cd" >> >> mmc at 12220000 { >> status = "okay"; >> card-detect-delay = <200>; >> samsung,dw-mshc-ciu-div = <3>; >> samsung,dw-mshc-sdr-timing = <2 3>; >> samsung,dw-mshc-ddr-timing = <1 2>; >> pinctrl-names = "default"; >> pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>; >> bus-width = <4>; >> cap-sd-highspeed; >> }; >> >> See "arch/arm/boot/dts/exynos5420-peach-pit.dts" too: >> >> &mmc_2 { >> status = "okay"; >> num-slots = <1>; >> cap-sd-highspeed; >> card-detect-delay = <200>; >> clock-frequency = <400000000>; >> samsung,dw-mshc-ciu-div = <3>; >> samsung,dw-mshc-sdr-timing = <2 3>; >> samsung,dw-mshc-ddr-timing = <1 2>; >> pinctrl-names = "default"; >> pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>; >> bus-width = <4>; >> }; >> >> >> Here, see this ASCII art that shows how some lines are hooked up on >> peach-pit. You might need to paste this into something with a >> fixed-width font. >> >> +-------------------- >> | Exynos 5420 >> | >> | >> P2.8V_LOUT4 ---------|- VDDQ_MMC2 (AK7) >> | | >> | | >> +-+- 10K res -+----|- XMMC2CDN (AK6) >> | | | >> | | | >> | | | >> | Ext CD | >> | | >> +-- 10K res-+--+---|- XMMC2CMD (AK8) >> | >> | >> Ext CMD >> >> You can see from the above that the external card detect signal (that >> goes to the connector) named "Ext CD" is pulled up to the same voltage >> as the external CMD signal (that also goes to the connector). This is >> vqmmc. If we turn off vqmmc then the 10K resistor will (I think) act >> as a pull down, or in the best case it will be floating. >> >> Said another way: we can't read card detect when vqmmc is off. > > If that's the case, it makes sense. But i wonder why designed like that. > Anyway, then we need to consider that controls the vqmmc power for card-detection. Maybe you can send a message to the SoC designers at Samsung not to design the chip incorrectly in the future? ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 2014-08-25 8:13 ` Ulf Hansson 2014-08-25 8:50 ` Jaehoon Chung @ 2014-08-25 15:20 ` Doug Anderson 2014-08-26 7:37 ` Ulf Hansson 2014-08-27 3:55 ` Jaehoon Chung 1 sibling, 2 replies; 43+ messages in thread From: Doug Anderson @ 2014-08-25 15:20 UTC (permalink / raw) To: linux-arm-kernel Ulf, On Mon, Aug 25, 2014 at 1:13 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: > On 22 August 2014 20:27, Sonny Rao <sonnyrao@chromium.org> wrote: >> On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>> On 22 August 2014 15:47, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote: >>>> Exynos 5250 and 5420 based boards uses built-in CD# line for card >>>> detection.But unfortunately CD# line is on the same voltage rails >>>> as of I/O voltage rails. When we cut off vqmmc,the consequent card >>>> detection will break in these boards. >>> >>> I am not sure I follow here. >>> >>> Is the card detect mechanism handled internally by the dw_mmc controller? >> >> Yes > > Just out of curiosity. > > Do you know how the power to the actual dw_mmc controller is handled? > I expect it to be SoC specific and I am guessing power domain > regulators may be involved!? You can likely read the dw_mmc registers when vqmmc is off. Is that what you're asking? Certainly if vqmmc is not powered then the lines themselves will be useless, won't they? The "vqmmc" supply goes to the "VDDQ_MMC2" pin on 5420. In my 5420 user manual, I see that "clk", "cmd", "cd", "datN", "wp" and "biuvr" pins are all in this same voltage (VDDQ_MMC2) domain. Can you really read a pin without powering that part of the SoC? >>> I thought HW engineers long time ago realized that this should be done >>> separately on a GPIO line to be able to save power while waiting for a >>> card to be inserted. But that's not case then? >> >> At least in my limited experience, this seems to be common among SoC >> vendors who are using dw_mmc, as we've seen this elsewhere as well and >> after seeing it here we know that we need to ignore the CD pin that's >> routed to dw_mmc and use a separately powered GPIO on the board, but >> still there are probably many SoCs/boards which are doing it this way. >> >>>> >>>> These hosts (obviously) need to keep vqmmc (and thus vmmc) on all the >>>> time, even when the mmc core tells them to power off. However, one >>>> problem is that these cards won't properly handle mmc_power_cycle(). >>>> That's needed to handle error cases when trying to switch voltages >>>> (see 0797e5f mmc:core: Fixup signal voltage switch). >>>> >>>> This patch adds a new MMC_POWER_OFF_HARD mode when it's doing a power >>>> cycle. This mode differs from the normal MMC_POWER_OFF mode in that >>>> the mmc core will promise to power the slot back on before it expects >>>> the host to detect card insertion or removal. >> >> This patch is based off of one that Doug wrote (sent privately to >> Yuvaraj) which just modifies the MMC core, and should be split into >> two patches. >> One that modifies the mmc core and one that implements this in dw_mmc. > > I looked at the mmc core parts, it seems like the wrong approach. > > I think you shall be able use MMC_CAP_NEEDS_POLL, to handle this > broken card detect mechanism. We even have a DT binding for that, > "broken-cd". I don't think this is possible, but let me explain why I think so and you can correct me. The voltage domain of the "card detect" pin on the SoC is vqmmc, right? That means that you won't be able to read the pin without turning on vqmmc. Even if you could read the pin without turning on vqmmc, the pullup on this line is connected to vqmmc too. ...so if vqmmc is off then there's no pulup and you can't use card detect. Are you suggesting that we should flip the voltage of vqmmc (and thus vmmc to prevent damaging the card) during polling? That seems ugly. One other thing to mention: we didn't find any power savings by actually turning off vmmc and vqmmc when there was no card inserted. There's no current running through the lines when there is no card inserted and apparently everything is efficient enough that there was no problem. -Doug ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 2014-08-25 15:20 ` Doug Anderson @ 2014-08-26 7:37 ` Ulf Hansson 2014-08-26 20:32 ` Doug Anderson 2014-08-27 3:55 ` Jaehoon Chung 1 sibling, 1 reply; 43+ messages in thread From: Ulf Hansson @ 2014-08-26 7:37 UTC (permalink / raw) To: linux-arm-kernel On 25 August 2014 17:20, Doug Anderson <dianders@google.com> wrote: > Ulf, > > On Mon, Aug 25, 2014 at 1:13 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >> On 22 August 2014 20:27, Sonny Rao <sonnyrao@chromium.org> wrote: >>> On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>>> On 22 August 2014 15:47, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote: >>>>> Exynos 5250 and 5420 based boards uses built-in CD# line for card >>>>> detection.But unfortunately CD# line is on the same voltage rails >>>>> as of I/O voltage rails. When we cut off vqmmc,the consequent card >>>>> detection will break in these boards. >>>> >>>> I am not sure I follow here. >>>> >>>> Is the card detect mechanism handled internally by the dw_mmc controller? >>> >>> Yes >> >> Just out of curiosity. >> >> Do you know how the power to the actual dw_mmc controller is handled? >> I expect it to be SoC specific and I am guessing power domain >> regulators may be involved!? > > You can likely read the dw_mmc registers when vqmmc is off. Is that > what you're asking? Certainly if vqmmc is not powered then the lines > themselves will be useless, won't they? The "vqmmc" supply goes to > the "VDDQ_MMC2" pin on 5420. In my 5420 user manual, I see that > "clk", "cmd", "cd", "datN", "wp" and "biuvr" pins are all in this same > voltage (VDDQ_MMC2) domain. Can you really read a pin without > powering that part of the SoC? Can you verify that you can't re-route these signals to GPIOs on your Exynos board, especially for wp and cd? That would mean, you don't need the internal logic of the dw_mmc to get either card detect or write protect, which would solve your problem. > > >>>> I thought HW engineers long time ago realized that this should be done >>>> separately on a GPIO line to be able to save power while waiting for a >>>> card to be inserted. But that's not case then? >>> >>> At least in my limited experience, this seems to be common among SoC >>> vendors who are using dw_mmc, as we've seen this elsewhere as well and >>> after seeing it here we know that we need to ignore the CD pin that's >>> routed to dw_mmc and use a separately powered GPIO on the board, but >>> still there are probably many SoCs/boards which are doing it this way. >>> >>>>> >>>>> These hosts (obviously) need to keep vqmmc (and thus vmmc) on all the >>>>> time, even when the mmc core tells them to power off. However, one >>>>> problem is that these cards won't properly handle mmc_power_cycle(). >>>>> That's needed to handle error cases when trying to switch voltages >>>>> (see 0797e5f mmc:core: Fixup signal voltage switch). >>>>> >>>>> This patch adds a new MMC_POWER_OFF_HARD mode when it's doing a power >>>>> cycle. This mode differs from the normal MMC_POWER_OFF mode in that >>>>> the mmc core will promise to power the slot back on before it expects >>>>> the host to detect card insertion or removal. >>> >>> This patch is based off of one that Doug wrote (sent privately to >>> Yuvaraj) which just modifies the MMC core, and should be split into >>> two patches. >>> One that modifies the mmc core and one that implements this in dw_mmc. >> >> I looked at the mmc core parts, it seems like the wrong approach. >> >> I think you shall be able use MMC_CAP_NEEDS_POLL, to handle this >> broken card detect mechanism. We even have a DT binding for that, >> "broken-cd". > > I don't think this is possible, but let me explain why I think so and > you can correct me. > > The voltage domain of the "card detect" pin on the SoC is vqmmc, > right? That means that you won't be able to read the pin without > turning on vqmmc. Even if you could read the pin without turning on > vqmmc, the pullup on this line is connected to vqmmc too. ...so if > vqmmc is off then there's no pulup and you can't use card detect. > > Are you suggesting that we should flip the voltage of vqmmc (and thus > vmmc to prevent damaging the card) during polling? That seems ugly. I am not sure I follow to understand the problem. All I am saying is: >From your ->set_ios() when you get MMC_POWER_UP, enable vcc and vccq. >From your ->set_ios() when you get MMC_POWER_OFF, disable vccq and vcc. The rest is taken care of from mmc core, when trying to initialize the card. > > > One other thing to mention: we didn't find any power savings by > actually turning off vmmc and vqmmc when there was no card inserted. > There's no current running through the lines when there is no card > inserted and apparently everything is efficient enough that there was > no problem. On what level of current leakage did you measure? In an system PM suspend state we are chasing uA; I find it hard that no leakage is added when the power is enabled. Anyway, let's leave that as a separate discussion. :-) Kind regards Uffe ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 2014-08-26 7:37 ` Ulf Hansson @ 2014-08-26 20:32 ` Doug Anderson 2014-08-27 11:17 ` Ulf Hansson 0 siblings, 1 reply; 43+ messages in thread From: Doug Anderson @ 2014-08-26 20:32 UTC (permalink / raw) To: linux-arm-kernel Ulf, On Tue, Aug 26, 2014 at 12:37 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: > On 25 August 2014 17:20, Doug Anderson <dianders@google.com> wrote: >> Ulf, >> >> On Mon, Aug 25, 2014 at 1:13 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>> On 22 August 2014 20:27, Sonny Rao <sonnyrao@chromium.org> wrote: >>>> On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>>>> On 22 August 2014 15:47, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote: >>>>>> Exynos 5250 and 5420 based boards uses built-in CD# line for card >>>>>> detection.But unfortunately CD# line is on the same voltage rails >>>>>> as of I/O voltage rails. When we cut off vqmmc,the consequent card >>>>>> detection will break in these boards. >>>>> >>>>> I am not sure I follow here. >>>>> >>>>> Is the card detect mechanism handled internally by the dw_mmc controller? >>>> >>>> Yes >>> >>> Just out of curiosity. >>> >>> Do you know how the power to the actual dw_mmc controller is handled? >>> I expect it to be SoC specific and I am guessing power domain >>> regulators may be involved!? >> >> You can likely read the dw_mmc registers when vqmmc is off. Is that >> what you're asking? Certainly if vqmmc is not powered then the lines >> themselves will be useless, won't they? The "vqmmc" supply goes to >> the "VDDQ_MMC2" pin on 5420. In my 5420 user manual, I see that >> "clk", "cmd", "cd", "datN", "wp" and "biuvr" pins are all in this same >> voltage (VDDQ_MMC2) domain. Can you really read a pin without >> powering that part of the SoC? > > Can you verify that you can't re-route these signals to GPIOs on your > Exynos board, especially for wp and cd? Verified. > That would mean, you don't need the internal logic of the dw_mmc to > get either card detect or write protect, which would solve your > problem. Right. ...but since I can't re-route, I can't use this to solve my problem. >>>>> I thought HW engineers long time ago realized that this should be done >>>>> separately on a GPIO line to be able to save power while waiting for a >>>>> card to be inserted. But that's not case then? >>>> >>>> At least in my limited experience, this seems to be common among SoC >>>> vendors who are using dw_mmc, as we've seen this elsewhere as well and >>>> after seeing it here we know that we need to ignore the CD pin that's >>>> routed to dw_mmc and use a separately powered GPIO on the board, but >>>> still there are probably many SoCs/boards which are doing it this way. >>>> >>>>>> >>>>>> These hosts (obviously) need to keep vqmmc (and thus vmmc) on all the >>>>>> time, even when the mmc core tells them to power off. However, one >>>>>> problem is that these cards won't properly handle mmc_power_cycle(). >>>>>> That's needed to handle error cases when trying to switch voltages >>>>>> (see 0797e5f mmc:core: Fixup signal voltage switch). >>>>>> >>>>>> This patch adds a new MMC_POWER_OFF_HARD mode when it's doing a power >>>>>> cycle. This mode differs from the normal MMC_POWER_OFF mode in that >>>>>> the mmc core will promise to power the slot back on before it expects >>>>>> the host to detect card insertion or removal. >>>> >>>> This patch is based off of one that Doug wrote (sent privately to >>>> Yuvaraj) which just modifies the MMC core, and should be split into >>>> two patches. >>>> One that modifies the mmc core and one that implements this in dw_mmc. >>> >>> I looked at the mmc core parts, it seems like the wrong approach. >>> >>> I think you shall be able use MMC_CAP_NEEDS_POLL, to handle this >>> broken card detect mechanism. We even have a DT binding for that, >>> "broken-cd". >> >> I don't think this is possible, but let me explain why I think so and >> you can correct me. >> >> The voltage domain of the "card detect" pin on the SoC is vqmmc, >> right? That means that you won't be able to read the pin without >> turning on vqmmc. Even if you could read the pin without turning on >> vqmmc, the pullup on this line is connected to vqmmc too. ...so if >> vqmmc is off then there's no pulup and you can't use card detect. >> >> Are you suggesting that we should flip the voltage of vqmmc (and thus >> vmmc to prevent damaging the card) during polling? That seems ugly. > > I am not sure I follow to understand the problem. All I am saying is: > From your ->set_ios() when you get MMC_POWER_UP, enable vcc and vccq. > From your ->set_ios() when you get MMC_POWER_OFF, disable vccq and vcc. > > The rest is taken care of from mmc core, when trying to initialize the card. We must not be on the same page, so I'll put all my assumptions in super detail and we can see what's different... So if I have "MMC_CAP_NEEDS_POLL" set, the MMC core will poll things, right? ...and you are suggesting that I could solve my vqmmc vs. card detect problem by using MMC_CAP_NEEDS_POLL, right? Let's think about the case when no card is inserted. When no card is inserted the core will call set_ios() with MMC_POWER_OFF, right? ...and we want that to turn off vmmc. ...and if we turn off vmmc, we should turn off vqmmc. Now we've got vmmc off and vqmmc off and on this board we can't read the card detect line, right? Now, we've got MMC_CAP_NEEDS_POLL, so dw_mmc will periodically be called to check the card detect line, but with vmmc and vqmmc off. It will be unable to return a sensible value without actually turning on vmmc and vqmmc. ...so with that context, I'll ask my questoin again: Are you suggesting that we should flip the voltage of vqmmc (and thus vmmc to prevent damaging the card) during polling? That seems ugly. >> One other thing to mention: we didn't find any power savings by >> actually turning off vmmc and vqmmc when there was no card inserted. >> There's no current running through the lines when there is no card >> inserted and apparently everything is efficient enough that there was >> no problem. > > On what level of current leakage did you measure? It was not measurable during normal running (S0). > In an system PM suspend state we are chasing uA; I find it hard that > no leakage is added when the power is enabled. Anyway, let's leave > that as a separate discussion. :-) During system PM state we actually _can_ turn power off. We don't need to detect card insertions at that time (card detect is not a wakeup source on this board). -Doug ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 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 0 siblings, 2 replies; 43+ messages in thread From: Ulf Hansson @ 2014-08-27 11:17 UTC (permalink / raw) To: linux-arm-kernel Hi Doug, [snip] >>>> I think you shall be able use MMC_CAP_NEEDS_POLL, to handle this >>>> broken card detect mechanism. We even have a DT binding for that, >>>> "broken-cd". >>> >>> I don't think this is possible, but let me explain why I think so and >>> you can correct me. >>> >>> The voltage domain of the "card detect" pin on the SoC is vqmmc, >>> right? That means that you won't be able to read the pin without >>> turning on vqmmc. Even if you could read the pin without turning on >>> vqmmc, the pullup on this line is connected to vqmmc too. ...so if >>> vqmmc is off then there's no pulup and you can't use card detect. >>> >>> Are you suggesting that we should flip the voltage of vqmmc (and thus >>> vmmc to prevent damaging the card) during polling? That seems ugly. >> >> I am not sure I follow to understand the problem. All I am saying is: >> From your ->set_ios() when you get MMC_POWER_UP, enable vcc and vccq. >> From your ->set_ios() when you get MMC_POWER_OFF, disable vccq and vcc. >> >> The rest is taken care of from mmc core, when trying to initialize the card. > > We must not be on the same page, so I'll put all my assumptions in > super detail and we can see what's different... > > > So if I have "MMC_CAP_NEEDS_POLL" set, the MMC core will poll things, > right? ...and you are suggesting that I could solve my vqmmc vs. card > detect problem by using MMC_CAP_NEEDS_POLL, right? Yes. > > > Let's think about the case when no card is inserted. When no card is > inserted the core will call set_ios() with MMC_POWER_OFF, right? > > ...and we want that to turn off vmmc. > ...and if we turn off vmmc, we should turn off vqmmc. Correct. At MMC_POWER_OFF, all host drivers shall turn off all the possible powers that goes to the card. I am just telling this to make sure, we don't think this is a dw_mmc specific thing. > > Now we've got vmmc off and vqmmc off and on this board we can't read > the card detect line, right? Got it. :-) > > Now, we've got MMC_CAP_NEEDS_POLL, so dw_mmc will periodically be > called to check the card detect line, but with vmmc and vqmmc off. It > will be unable to return a sensible value without actually turning on > vmmc and vqmmc. Currently MMC_CAP_NEEDS_POLL mean the mmc rescan work will reschedule itself with HZ interval. This to check for card insert/removal. Now, mmc_rescan() will, if present, invoke host's ->get_cd() callback to check whether it's worth to continue initialization sequence or if it should re-schedule itself again. If your host driver can distinguish whether a card is inserted, which in this the are when vccq is turned off, your ->get_cd() callback need to return 0. That will allow mmc_rescan() to continue it's initialization sequence and do mmc_power_up(). > > > ...so with that context, I'll ask my questoin again: > > Are you suggesting that we should flip the voltage of vqmmc (and thus > vmmc to prevent damaging the card) during polling? That seems ugly. Nope. Kind regards Uffe ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 2014-08-27 11:17 ` Ulf Hansson @ 2014-08-27 11:20 ` Ulf Hansson 2014-08-27 15:52 ` Doug Anderson 1 sibling, 0 replies; 43+ messages in thread From: Ulf Hansson @ 2014-08-27 11:20 UTC (permalink / raw) To: linux-arm-kernel On 27 August 2014 13:17, Ulf Hansson <ulf.hansson@linaro.org> wrote: > Hi Doug, > > [snip] > >>>>> I think you shall be able use MMC_CAP_NEEDS_POLL, to handle this >>>>> broken card detect mechanism. We even have a DT binding for that, >>>>> "broken-cd". >>>> >>>> I don't think this is possible, but let me explain why I think so and >>>> you can correct me. >>>> >>>> The voltage domain of the "card detect" pin on the SoC is vqmmc, >>>> right? That means that you won't be able to read the pin without >>>> turning on vqmmc. Even if you could read the pin without turning on >>>> vqmmc, the pullup on this line is connected to vqmmc too. ...so if >>>> vqmmc is off then there's no pulup and you can't use card detect. >>>> >>>> Are you suggesting that we should flip the voltage of vqmmc (and thus >>>> vmmc to prevent damaging the card) during polling? That seems ugly. >>> >>> I am not sure I follow to understand the problem. All I am saying is: >>> From your ->set_ios() when you get MMC_POWER_UP, enable vcc and vccq. >>> From your ->set_ios() when you get MMC_POWER_OFF, disable vccq and vcc. >>> >>> The rest is taken care of from mmc core, when trying to initialize the card. >> >> We must not be on the same page, so I'll put all my assumptions in >> super detail and we can see what's different... >> >> >> So if I have "MMC_CAP_NEEDS_POLL" set, the MMC core will poll things, >> right? ...and you are suggesting that I could solve my vqmmc vs. card >> detect problem by using MMC_CAP_NEEDS_POLL, right? > > Yes. > >> >> >> Let's think about the case when no card is inserted. When no card is >> inserted the core will call set_ios() with MMC_POWER_OFF, right? >> >> ...and we want that to turn off vmmc. >> ...and if we turn off vmmc, we should turn off vqmmc. > > Correct. At MMC_POWER_OFF, all host drivers shall turn off all the > possible powers that goes to the card. I am just telling this to make > sure, we don't think this is a dw_mmc specific thing. > >> >> Now we've got vmmc off and vqmmc off and on this board we can't read >> the card detect line, right? > > Got it. :-) > >> >> Now, we've got MMC_CAP_NEEDS_POLL, so dw_mmc will periodically be >> called to check the card detect line, but with vmmc and vqmmc off. It >> will be unable to return a sensible value without actually turning on >> vmmc and vqmmc. > > Currently MMC_CAP_NEEDS_POLL mean the mmc rescan work will reschedule > itself with HZ interval. This to check for card insert/removal. > > Now, mmc_rescan() will, if present, invoke host's ->get_cd() callback > to check whether it's worth to continue initialization sequence or if > it should re-schedule itself again. > > If your host driver can distinguish whether a card is inserted, which > in this the are when vccq is turned off, your ->get_cd() callback need /s /the /case > to return 0. That will allow mmc_rescan() to continue it's /s /return 0 /return 1 > initialization sequence and do mmc_power_up(). > >> >> >> ...so with that context, I'll ask my questoin again: >> >> Are you suggesting that we should flip the voltage of vqmmc (and thus >> vmmc to prevent damaging the card) during polling? That seems ugly. > > Nope. > > Kind regards > Uffe ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 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 1 sibling, 1 reply; 43+ messages in thread From: Doug Anderson @ 2014-08-27 15:52 UTC (permalink / raw) To: linux-arm-kernel Ulf, On Wed, Aug 27, 2014 at 4:17 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >> Now, we've got MMC_CAP_NEEDS_POLL, so dw_mmc will periodically be >> called to check the card detect line, but with vmmc and vqmmc off. It >> will be unable to return a sensible value without actually turning on >> vmmc and vqmmc. > > Currently MMC_CAP_NEEDS_POLL mean the mmc rescan work will reschedule > itself with HZ interval. This to check for card insert/removal. > > Now, mmc_rescan() will, if present, invoke host's ->get_cd() callback > to check whether it's worth to continue initialization sequence or if > it should re-schedule itself again. > > If your host driver can distinguish whether a card is inserted, which > in this case are when vccq is turned off, your ->get_cd() callback need > to return 1. That will allow mmc_rescan() to continue it's > initialization sequence and do mmc_power_up(). As per my other email, we can't tell whether a card is inserted when vqmmc is off. Does this mean that you have removed your objections to a solution like Yuvaraj has posted? We still need to break it into two patches (the core part and the dwmmc part), but otherwise is it OK? I can post the original patch I sent Yuvaraj if it's helpful (or he can just include my patch as part 1 of his series). -Doug ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 2014-08-27 15:52 ` Doug Anderson @ 2014-08-28 7:25 ` Ulf Hansson 2014-08-28 15:50 ` Doug Anderson 0 siblings, 1 reply; 43+ messages in thread From: Ulf Hansson @ 2014-08-28 7:25 UTC (permalink / raw) To: linux-arm-kernel On 27 August 2014 17:52, Doug Anderson <dianders@google.com> wrote: > Ulf, > > On Wed, Aug 27, 2014 at 4:17 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>> Now, we've got MMC_CAP_NEEDS_POLL, so dw_mmc will periodically be >>> called to check the card detect line, but with vmmc and vqmmc off. It >>> will be unable to return a sensible value without actually turning on >>> vmmc and vqmmc. >> >> Currently MMC_CAP_NEEDS_POLL mean the mmc rescan work will reschedule >> itself with HZ interval. This to check for card insert/removal. >> >> Now, mmc_rescan() will, if present, invoke host's ->get_cd() callback >> to check whether it's worth to continue initialization sequence or if >> it should re-schedule itself again. >> >> If your host driver can distinguish whether a card is inserted, which >> in this case are when vccq is turned off, your ->get_cd() callback need >> to return 1. That will allow mmc_rescan() to continue it's >> initialization sequence and do mmc_power_up(). > > As per my other email, we can't tell whether a card is inserted when > vqmmc is off. I understand. The solution I proposed above, is: 1) Enable MMC_CAP_NEEDS_POLL. 2) Make ->get_cd() return 1, when you can't distinguish if the card is inserted. That will solve this issue and without messing up the mmc core. > > Does this mean that you have removed your objections to a solution > like Yuvaraj has posted? We still need to break it into two patches > (the core part and the dwmmc part), but otherwise is it OK? I can > post the original patch I sent Yuvaraj if it's helpful (or he can just > include my patch as part 1 of his series). No. This can entirely be fixed in the host driver. As suggested above. Kind regards Uffe ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 2014-08-28 7:25 ` Ulf Hansson @ 2014-08-28 15:50 ` Doug Anderson 2014-08-28 17:50 ` Sonny Rao 0 siblings, 1 reply; 43+ messages in thread From: Doug Anderson @ 2014-08-28 15:50 UTC (permalink / raw) To: linux-arm-kernel Ulf, On Thu, Aug 28, 2014 at 12:25 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: > On 27 August 2014 17:52, Doug Anderson <dianders@google.com> wrote: >> Ulf, >> >> On Wed, Aug 27, 2014 at 4:17 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>>> Now, we've got MMC_CAP_NEEDS_POLL, so dw_mmc will periodically be >>>> called to check the card detect line, but with vmmc and vqmmc off. It >>>> will be unable to return a sensible value without actually turning on >>>> vmmc and vqmmc. >>> >>> Currently MMC_CAP_NEEDS_POLL mean the mmc rescan work will reschedule >>> itself with HZ interval. This to check for card insert/removal. >>> >>> Now, mmc_rescan() will, if present, invoke host's ->get_cd() callback >>> to check whether it's worth to continue initialization sequence or if >>> it should re-schedule itself again. >>> >>> If your host driver can distinguish whether a card is inserted, which >>> in this case are when vccq is turned off, your ->get_cd() callback need >>> to return 1. That will allow mmc_rescan() to continue it's >>> initialization sequence and do mmc_power_up(). >> >> As per my other email, we can't tell whether a card is inserted when >> vqmmc is off. > > I understand. > > The solution I proposed above, is: > > 1) Enable MMC_CAP_NEEDS_POLL. > 2) Make ->get_cd() return 1, when you can't distinguish if the card is inserted. > > That will solve this issue and without messing up the mmc core. Ah, I see! So every 1 second, we'll do the following: 1. Call get_cd(), which returns 1. 2. MMC core will power everything up (turn on all regulators) for MMC. 3. We'll start to initialize a card. 4. We'll notice that, oops, there's no card there. 5. MMC core will shut things down again. That seems awfully expensive to do every second when the card detect line actually does work (as long as you keep power lines). Is the patch to separate out the concepts of "power off because no card is inserted" and "power off because we're power cycling the card" really bad enough to warrant forcing us to use the above? I'm not an EE, but cycling regulators on and off every second doesn't seem super ideal, but maybe they're designed for it? Personally, I'd be tempted to just leave the power on all the time and if a card somehow needs to be power cycled (because UHS negotiation failed?) then that card just isn't supported. This could be done in the dts by saying that the regulator is "always on" and no need to pollute any source files. -Doug ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 2014-08-28 15:50 ` Doug Anderson @ 2014-08-28 17:50 ` Sonny Rao 2014-08-29 4:08 ` Doug Anderson 0 siblings, 1 reply; 43+ messages in thread From: Sonny Rao @ 2014-08-28 17:50 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 28, 2014 at 8:50 AM, Doug Anderson <dianders@google.com> wrote: > Ulf, > > On Thu, Aug 28, 2014 at 12:25 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >> On 27 August 2014 17:52, Doug Anderson <dianders@google.com> wrote: >>> Ulf, >>> >>> On Wed, Aug 27, 2014 at 4:17 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>>>> Now, we've got MMC_CAP_NEEDS_POLL, so dw_mmc will periodically be >>>>> called to check the card detect line, but with vmmc and vqmmc off. It >>>>> will be unable to return a sensible value without actually turning on >>>>> vmmc and vqmmc. >>>> >>>> Currently MMC_CAP_NEEDS_POLL mean the mmc rescan work will reschedule >>>> itself with HZ interval. This to check for card insert/removal. >>>> >>>> Now, mmc_rescan() will, if present, invoke host's ->get_cd() callback >>>> to check whether it's worth to continue initialization sequence or if >>>> it should re-schedule itself again. >>>> >>>> If your host driver can distinguish whether a card is inserted, which >>>> in this case are when vccq is turned off, your ->get_cd() callback need >>>> to return 1. That will allow mmc_rescan() to continue it's >>>> initialization sequence and do mmc_power_up(). >>> >>> As per my other email, we can't tell whether a card is inserted when >>> vqmmc is off. >> >> I understand. >> >> The solution I proposed above, is: >> >> 1) Enable MMC_CAP_NEEDS_POLL. >> 2) Make ->get_cd() return 1, when you can't distinguish if the card is inserted. >> >> That will solve this issue and without messing up the mmc core. > > Ah, I see! So every 1 second, we'll do the following: > > 1. Call get_cd(), which returns 1. > > 2. MMC core will power everything up (turn on all regulators) for MMC. > > 3. We'll start to initialize a card. > > 4. We'll notice that, oops, there's no card there. > > 5. MMC core will shut things down again. > > > That seems awfully expensive to do every second when the card detect > line actually does work (as long as you keep power lines). Is the > patch to separate out the concepts of "power off because no card is > inserted" and "power off because we're power cycling the card" really > bad enough to warrant forcing us to use the above? > > I'm not an EE, but cycling regulators on and off every second doesn't > seem super ideal, but maybe they're designed for it? > > > Personally, I'd be tempted to just leave the power on all the time and > if a card somehow needs to be power cycled (because UHS negotiation > failed?) then that card just isn't supported. This could be done in > the dts by saying that the regulator is "always on" and no need to > pollute any source files. Yeah, power cycling the regulators constantly doesn't seem like a great idea, we can ask the EEs what they think. This scheme of leaving them on all the time would prevent us from being able to actually power cycle the card, which I think is required by the spec in case UHS negotiation fails. > > > -Doug ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 2014-08-28 17:50 ` Sonny Rao @ 2014-08-29 4:08 ` Doug Anderson 0 siblings, 0 replies; 43+ messages in thread From: Doug Anderson @ 2014-08-29 4:08 UTC (permalink / raw) To: linux-arm-kernel Hi, On Thu, Aug 28, 2014 at 10:50 AM, Sonny Rao <sonnyrao@chromium.org> wrote: > On Thu, Aug 28, 2014 at 8:50 AM, Doug Anderson <dianders@google.com> wrote: >> Ulf, >> >> On Thu, Aug 28, 2014 at 12:25 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>> On 27 August 2014 17:52, Doug Anderson <dianders@google.com> wrote: >>>> Ulf, >>>> >>>> On Wed, Aug 27, 2014 at 4:17 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>>>>> Now, we've got MMC_CAP_NEEDS_POLL, so dw_mmc will periodically be >>>>>> called to check the card detect line, but with vmmc and vqmmc off. It >>>>>> will be unable to return a sensible value without actually turning on >>>>>> vmmc and vqmmc. >>>>> >>>>> Currently MMC_CAP_NEEDS_POLL mean the mmc rescan work will reschedule >>>>> itself with HZ interval. This to check for card insert/removal. >>>>> >>>>> Now, mmc_rescan() will, if present, invoke host's ->get_cd() callback >>>>> to check whether it's worth to continue initialization sequence or if >>>>> it should re-schedule itself again. >>>>> >>>>> If your host driver can distinguish whether a card is inserted, which >>>>> in this case are when vccq is turned off, your ->get_cd() callback need >>>>> to return 1. That will allow mmc_rescan() to continue it's >>>>> initialization sequence and do mmc_power_up(). >>>> >>>> As per my other email, we can't tell whether a card is inserted when >>>> vqmmc is off. >>> >>> I understand. >>> >>> The solution I proposed above, is: >>> >>> 1) Enable MMC_CAP_NEEDS_POLL. >>> 2) Make ->get_cd() return 1, when you can't distinguish if the card is inserted. >>> >>> That will solve this issue and without messing up the mmc core. >> >> Ah, I see! So every 1 second, we'll do the following: >> >> 1. Call get_cd(), which returns 1. >> >> 2. MMC core will power everything up (turn on all regulators) for MMC. >> >> 3. We'll start to initialize a card. >> >> 4. We'll notice that, oops, there's no card there. >> >> 5. MMC core will shut things down again. >> >> >> That seems awfully expensive to do every second when the card detect >> line actually does work (as long as you keep power lines). Is the >> patch to separate out the concepts of "power off because no card is >> inserted" and "power off because we're power cycling the card" really >> bad enough to warrant forcing us to use the above? >> >> I'm not an EE, but cycling regulators on and off every second doesn't >> seem super ideal, but maybe they're designed for it? >> >> >> Personally, I'd be tempted to just leave the power on all the time and >> if a card somehow needs to be power cycled (because UHS negotiation >> failed?) then that card just isn't supported. This could be done in >> the dts by saying that the regulator is "always on" and no need to >> pollute any source files. > > Yeah, power cycling the regulators constantly doesn't seem like a > great idea, we can ask the EEs what they think. > > This scheme of leaving them on all the time would prevent us from > being able to actually power cycle the card, which I think is required > by the spec in case UHS negotiation fails. OK, fair enough. I guess polling is less bad than nor supporting card power cycling. ...it still feels like adding this quirk to the core isn't super ugly, but if everyone is against it... -Doug ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 2014-08-25 15:20 ` Doug Anderson 2014-08-26 7:37 ` Ulf Hansson @ 2014-08-27 3:55 ` Jaehoon Chung 1 sibling, 0 replies; 43+ messages in thread From: Jaehoon Chung @ 2014-08-27 3:55 UTC (permalink / raw) To: linux-arm-kernel Hi. On 08/26/2014 12:20 AM, Doug Anderson wrote: > Ulf, > > On Mon, Aug 25, 2014 at 1:13 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >> On 22 August 2014 20:27, Sonny Rao <sonnyrao@chromium.org> wrote: >>> On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>>> On 22 August 2014 15:47, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote: >>>>> Exynos 5250 and 5420 based boards uses built-in CD# line for card >>>>> detection.But unfortunately CD# line is on the same voltage rails >>>>> as of I/O voltage rails. When we cut off vqmmc,the consequent card >>>>> detection will break in these boards. >>>> >>>> I am not sure I follow here. >>>> >>>> Is the card detect mechanism handled internally by the dw_mmc controller? >>> >>> Yes >> >> Just out of curiosity. >> >> Do you know how the power to the actual dw_mmc controller is handled? >> I expect it to be SoC specific and I am guessing power domain >> regulators may be involved!? > > You can likely read the dw_mmc registers when vqmmc is off. Is that > what you're asking? Certainly if vqmmc is not powered then the lines > themselves will be useless, won't they? The "vqmmc" supply goes to > the "VDDQ_MMC2" pin on 5420. In my 5420 user manual, I see that > "clk", "cmd", "cd", "datN", "wp" and "biuvr" pins are all in this same > voltage (VDDQ_MMC2) domain. Can you really read a pin without > powering that part of the SoC? It's not correct. At TRM, described as same voltage domain. But CD-pin is used with "always-on" power. In circuit, CD# pin is disconnected. > > >>>> I thought HW engineers long time ago realized that this should be done >>>> separately on a GPIO line to be able to save power while waiting for a >>>> card to be inserted. But that's not case then? >>> >>> At least in my limited experience, this seems to be common among SoC >>> vendors who are using dw_mmc, as we've seen this elsewhere as well and >>> after seeing it here we know that we need to ignore the CD pin that's >>> routed to dw_mmc and use a separately powered GPIO on the board, but >>> still there are probably many SoCs/boards which are doing it this way. >>> >>>>> >>>>> These hosts (obviously) need to keep vqmmc (and thus vmmc) on all the >>>>> time, even when the mmc core tells them to power off. However, one >>>>> problem is that these cards won't properly handle mmc_power_cycle(). >>>>> That's needed to handle error cases when trying to switch voltages >>>>> (see 0797e5f mmc:core: Fixup signal voltage switch). >>>>> >>>>> This patch adds a new MMC_POWER_OFF_HARD mode when it's doing a power >>>>> cycle. This mode differs from the normal MMC_POWER_OFF mode in that >>>>> the mmc core will promise to power the slot back on before it expects >>>>> the host to detect card insertion or removal. >>> >>> This patch is based off of one that Doug wrote (sent privately to >>> Yuvaraj) which just modifies the MMC core, and should be split into >>> two patches. >>> One that modifies the mmc core and one that implements this in dw_mmc. >> >> I looked at the mmc core parts, it seems like the wrong approach. >> >> I think you shall be able use MMC_CAP_NEEDS_POLL, to handle this >> broken card detect mechanism. We even have a DT binding for that, >> "broken-cd". > > I don't think this is possible, but let me explain why I think so and > you can correct me. Exynos series is using the external gpio-cd concept. So it need not to use MMC_CAP_NEEDS_POLL. Can use the slot-gpio API. In my exynos5 board, it's working fine with the slot-gpio API. Best Regards, Jaehoon Chung > > The voltage domain of the "card detect" pin on the SoC is vqmmc, > right? That means that you won't be able to read the pin without > turning on vqmmc. Even if you could read the pin without turning on > vqmmc, the pullup on this line is connected to vqmmc too. ...so if > vqmmc is off then there's no pulup and you can't use card detect. > > Are you suggesting that we should flip the voltage of vqmmc (and thus > vmmc to prevent damaging the card) during polling? That seems ugly. > > > One other thing to mention: we didn't find any power savings by > actually turning off vmmc and vqmmc when there was no card inserted. > There's no current running through the lines when there is no card > inserted and apparently everything is efficient enough that there was > no problem. > > -Doug > ^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2014-10-01 15:38 UTC | newest] Thread overview: 43+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
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).