Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Peter Ujfalusi]

On 11/18/2015 05:46 PM, Andy Shevchenko wrote:
> On Wed, Nov 18, 2015 at 4:21 PM, Peter Ujfalusi  wrote:
>> Hi Vinod,
>>
>> bringing this old thread back to life as I just started to work on this.
> 
> What I remember we need to convert drivers to use new API meanwhile it
> is good to keep old one to avoid patch storm which does nothing useful
> (IIRC Russel's opinion).

I tend to agree. But we need to start converting the users at some point
either way.
Another issue is the fact that the current dmaengine API is using all the good
names I can think of ;)

> On the other hand there are a lot of drivers that are used on the set
> of platforms starting from legacy and abandoned ones (like AVR32) to
> relatively new and newest.
> 
> And I'm not a fan of those thousands of API calls either.
> 

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] MMC fixes for v.4.4 rc2

[Ulf Hansson]

Hi Linus,

Here are some mmc fixes intended for v4.4 rc2. It's based on a commit
prior rc1 as I wanted to get them a bit more tested in next before
sending you the pull request.

Details are as usual found in the signed tag. Please pull this in!

Kind regards
Ulf Hansson


The following changes since commit ce5c2d2c256a4c8b523036537cd6be2d6af8f69d:

  arm64: fixup for mm renames (2015-11-07 16:45:51 -0800)

are available in the git repository at:

  git://git.linaro.org/people/ulf.hansson/mmc.git tags/mmc-v4.4-rc1

for you to fetch changes up to d3df0465db00cf4ed9f90d0bfc3b827d32b9c796:

  mmc: remove bondage between REQ_META and reliable write (2015-11-09
14:04:52 +0100)


MMC core:
 - Improve reliability when selecting HS200 mode
 - Improve reliability when selecting HS400 mode
 - mmc: remove bondage between REQ_META and reliable write

MMC host:
 - pxamci: Fix read-only gpio detection polarity
 - mtk-sd: Preinitialize delay_phase to fix the case when delay is zero
 - android-goldfish: Fix build dependency by adding HAS_DMA
 - dw_mmc: Remove Seungwon Jeon from MAINTAINERS


Adrian Hunter (4):
  mmc: mmc: Improve reliability of mmc_select_hs200()
  mmc: mmc: Fix HS setting in mmc_select_hs400()
  mmc: mmc: Move mmc_switch_status()
  mmc: mmc: Improve reliability of mmc_select_hs400()

Geert Uytterhoeven (2):
  mmc: mediatek: Preinitialize delay_phase in get_best_delay()
  mmc: MMC_GOLDFISH should depend on HAS_DMA

Luca Porzio (1):
  mmc: remove bondage between REQ_META and reliable write

Robert Jarzmik (1):
  mmc: pxamci: fix read-only gpio detection polarity

Ulf Hansson (1):
  MAINTAINERS: mmc: Remove Seungwon Jeon from dw_mmc

 MAINTAINERS   |  1 -
 drivers/mmc/card/block.c  | 11 ++
 drivers/mmc/core/mmc.c| 93 +++
 drivers/mmc/host/Kconfig  |  1 +
 drivers/mmc/host/mtk-sd.c |  2 +-
 drivers/mmc/host/pxamci.c |  2 +-
 6 files changed, 75 insertions(+), 35 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Correct DT properties for Arasan controller

[Arnd Bergmann]

On Thursday 19 November 2015 17:37:13 Marc Gonzalez wrote:
> Hello everyone,
> 
> My SoC provides an "SD3.0 / SDIO3.0 / eMMC4.4 AHB Host Controller"
> from Arasan Chip Systems (data sheet says rev 6.0, dated Feb 2010).
> 
> There are two instances of the controller:
> mmc0 is wired to an SD card reader,
> mmc1 is wired to an eMMC chip.
> 
> I'm trying to figure out how to write the DT.
> (Currently using Linux 4.2)
> 
> This is what I have so far:
> 
>   mmc0: mmc@21000 {
>   compatible = "arasan,sdhci-8.9a";

make this "arasan,sdhci-6.0", plus a chip specific string
in front of it.

>   reg = <0x21000 0x200>;
>   clock-names = "clk_xin", "clk_ahb";
>   clocks = <_clk>, < 1>;
>   interrupts = <60 IRQ_TYPE_LEVEL_HIGH>;
>   bus-width = <8>;
>   cap-sd-highspeed;
>   sd-uhs-sdr12;
>   sd-uhs-sdr25;
>   sd-uhs-sdr50;
>   sd-uhs-ddr50;
>   sd-uhs-sdr104;
>   };
> 
>   mmc1: mmc@21200 {
>   compatible = "arasan,sdhci-8.9a";
>   reg = <0x21200 0x200>;
>   clock-names = "clk_xin", "clk_ahb";
>   clocks = <_clk>, < 1>;
>   interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
>   bus-width = <8>;
>   non-removable;
>   };
> 
> https://www.kernel.org/doc/Documentation/devicetree/bindings/mmc/mmc.txt
> 
> (I don't know anything about MMC, SDHCI, SDIO, etc.)
> 
> Are cap-sd-highspeed and sd-uhs-* limited to mmc0? (wired to SD card reader)
> 
> Are cap-mmc-highspeed and mmc-* limited to mmc1? (wired to eMMC)

It depends: if the wiring is board specific, put them into the .dts file
and put the generic properties (interrupts, clocks, reg, compatible)
into the .dtsi file.

> What about these?
> - bus-width: Number of data lines, can be <1>, <4>, or <8>.  The default
>   will be <1> if the property is absent.

board specific

> - cap-power-off-card: powering off the card is safe
> - cap-mmc-hw-reset: eMMC hardware reset is supported
> - cap-sdio-irq: enable SDIO IRQ signalling on this interface
> - full-pwr-cycle: full power cycle of the card is supported
> 
> Also, I set clk_xin to 48 MHz (and clk_ahb is set to 400 MHz).
> Does clk_xin need to be higher for the faster modes?

don't know. I think the clock gets set by the driver, so the
clock controller needs to be programmable.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Correct DT properties for Arasan controller

[Alan Cooper]

On Thu, Nov 19, 2015 at 3:56 PM, Arnd Bergmann  wrote:
>>   cap-sd-highspeed;
>>   sd-uhs-sdr12;
>>   sd-uhs-sdr25;
>>   sd-uhs-sdr50;
>>   sd-uhs-ddr50;
>>   sd-uhs-sdr104;

These values normally come from the Host Controllers CAPS registers
and are only needed if the CAPS register setting are incorrect.

>> - cap-mmc-hw-reset: eMMC hardware reset is supported

This is only set if the driver supplies a hw_reset callback and the
Arasan driver does not.

>> - cap-sdio-irq: enable SDIO IRQ signalling on this interface

This is only set if the driver supplies a enable_sdio_irq and the
Arasan driver does not.



Al
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

mmc card suspension problem

[Renju Liu]

Hi All,

I'm currently studying the suspension behavior of MMC. However, I
don't quite understand the rationale why the kernel needs to wait
until timeout in the following code:

/*
 * If the host does not wait while the card signals busy, then we will
 * will have to wait the sleep/awake timeout.  Note, we cannot use the
 * SEND_STATUS command to poll the status because that command (and most
 * others) is invalid while the card sleeps.
 */

if (!(host->caps & MMC_CAP_WAIT_WHILE_BUSY)){
mmc_delay(DIV_ROUND_UP(card->ext_csd.sa_timeout, 1));
}

Can anyone explain this to me?


Best,
Renju Liu
i.am.renju@gmail.com

"Renju is awesome!"
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] mmc: sdhci-esdhc-imx: move the setting of watermark level out of probe

[Ulf Hansson]

On 10 November 2015 at 10:43, Haibo Chen  wrote:
> Currently, we config the watermark_level register only in probe.
> This will cause the mmc write operation timeout issue after system
> resume back in LPSR mode. Because in LPSR mode, after system resume
> back, the watermark_level register(0x44) changes to 0x08000880, which
> set the write watermark level as 0, and set the read watermark level
> as 128. This value is incorrect.
>
> This patch move the setting of watermark level register out of probe,
> so after system resume back, mmc driver can set this watermark level
> register back to 0x10401040.

This seems all reasonable! But...

>
> Signed-off-by: Haibo Chen 
> ---
>  drivers/mmc/host/sdhci-esdhc-imx.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
> b/drivers/mmc/host/sdhci-esdhc-imx.c
> index 1f1582f..1508949 100644
> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> @@ -584,6 +584,14 @@ static void esdhc_writeb_le(struct sdhci_host *host, u8 
> val, int reg)
> mask = 0x & ~(ESDHC_CTRL_BUSWIDTH_MASK | ESDHC_CTRL_D3CD);
>
> esdhc_clrset_le(host, mask, new_val, reg);
> +
> +   /*
> +* The imx6q/imx7d ROM code will change the default watermark
> +* level setting to something insane.  Change it back here.
> +*/
> +if (esdhc_is_usdhc(imx_data))
> +writel(0x10401040, host->ioaddr + ESDHC_WTMK_LVL);
> +

... why don't keep setting the watermark in ->probe() and instead just
add it at as additional task to do at system PM resume?

> return;
> }
> esdhc_clrset_le(host, 0xff, val, reg);
> @@ -1155,13 +1163,7 @@ static int sdhci_esdhc_imx_probe(struct 
> platform_device *pdev)
> host->quirks |= SDHCI_QUIRK_NO_MULTIBLOCK
> | SDHCI_QUIRK_BROKEN_ADMA;
>
> -   /*
> -* The imx6q ROM code will change the default watermark level setting
> -* to something insane.  Change it back here.
> -*/
> if (esdhc_is_usdhc(imx_data)) {
> -   writel(0x10401040, host->ioaddr + ESDHC_WTMK_LVL);
> -
> host->quirks2 |= SDHCI_QUIRK2_PRESET_VALUE_BROKEN;
> host->mmc->caps |= MMC_CAP_1_8V_DDR;
>
> --
> 1.9.1
>

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] mmc: sdhci-esdhc-imx: correct the tuning-step setting

[Ulf Hansson]

On 10 November 2015 at 10:43, Haibo Chen  wrote:
> Here we use '|=' to set the tuning-step, but before that, we should
> clear the tuning-step, otherwise we could got the wrong setting.
>
> Signed-off-by: Haibo Chen 
> ---
>  drivers/mmc/host/sdhci-esdhc-imx.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
> b/drivers/mmc/host/sdhci-esdhc-imx.c
> index 1508949..64275c7 100644
> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> @@ -76,6 +76,7 @@
>  #define ESDHC_STD_TUNING_EN(1 << 24)
>  /* NOTE: the minimum valid tuning start tap for mx6sl is 1 */
>  #define ESDHC_TUNING_START_TAP 0x1
> +#define ESDHC_TUNING_STEP_MASK 0x0007
>  #define ESDHC_TUNING_STEP_SHIFT16
>
>  /* pinctrl state */
> @@ -489,9 +490,11 @@ static void esdhc_writew_le(struct sdhci_host *host, u16 
> val, int reg)
> m |= ESDHC_MIX_CTRL_FBCLK_SEL;
> tuning_ctrl = readl(host->ioaddr + 
> ESDHC_TUNING_CTRL);
> tuning_ctrl |= ESDHC_STD_TUNING_EN | 
> ESDHC_TUNING_START_TAP;
> -   if (imx_data->boarddata.tuning_step)
> +   if (imx_data->boarddata.tuning_step) {
> +   tuning_ctrl &= 
> ~ESDHC_TUNING_STEP_MASK;
> tuning_ctrl |= 
> imx_data->boarddata.tuning_step << ESDHC_TUNING_STEP_SHIFT;
> -   writel(tuning_ctrl, host->ioaddr + 
> ESDHC_TUNING_CTRL);
> +   }
> +   writel(tuning_ctrl, host->ioaddr + 
> ESDHC_TUNING_CTRL);
> } else {
> v &= ~ESDHC_MIX_CTRL_EXE_TUNE;
> }
> --
> 1.9.1
>

Looks good to me, but is there a dependency to patch 1/2 that should
prevent me from applying this one?

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: sh_mmcif: Document r8a7793 DT bindings

[Ulf Hansson]

On 27 October 2015 at 17:56, Geert Uytterhoeven  wrote:
> From: Ulrich Hecht 
>
> Signed-off-by: Ulrich Hecht 
> Acked-by: Simon Horman 
> [geert: Rebased]
> Signed-off-by: Geert Uytterhoeven 

Thanks, applied for next!

Kind regards
Uffe

> ---
>  Documentation/devicetree/bindings/mmc/renesas,mmcif.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt 
> b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> index cae29eb5733d8a52..ff611fa66871dec9 100644
> --- a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> +++ b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> @@ -11,6 +11,7 @@ Required properties:
> - "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs
> - "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs
> - "renesas,mmcif-r8a7791" for the MMCIF found in r8a7791 SoCs
> +   - "renesas,mmcif-r8a7793" for the MMCIF found in r8a7793 SoCs
> - "renesas,mmcif-r8a7794" for the MMCIF found in r8a7794 SoCs
>
>  - clocks: reference to the functional clock
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2] mmc: change to use kmalloc

[Ulf Hansson]

On 12 November 2015 at 12:27, yalin wang  wrote:
> Use kmalloc instead of kzalloc, zero the memory is not needed.
>
> Signed-off-by: yalin wang 

Thanks, applied for next! I took liberty to update the change log and
the commit message header to make it more descriptive.

Kind regards
Uffe


> ---
>  drivers/mmc/card/block.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index c742cfd..c3fd4c8 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -345,7 +345,7 @@ static struct mmc_blk_ioc_data 
> *mmc_blk_ioctl_copy_from_user(
> struct mmc_blk_ioc_data *idata;
> int err;
>
> -   idata = kzalloc(sizeof(*idata), GFP_KERNEL);
> +   idata = kmalloc(sizeof(*idata), GFP_KERNEL);
> if (!idata) {
> err = -ENOMEM;
> goto out;
> @@ -365,7 +365,7 @@ static struct mmc_blk_ioc_data 
> *mmc_blk_ioctl_copy_from_user(
> if (!idata->buf_bytes)
> return idata;
>
> -   idata->buf = kzalloc(idata->buf_bytes, GFP_KERNEL);
> +   idata->buf = kmalloc(idata->buf_bytes, GFP_KERNEL);
> if (!idata->buf) {
> err = -ENOMEM;
> goto idata_err;
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: pwrseq: constify mmc_pwrseq_ops structures

[Ulf Hansson]

On 14 November 2015 at 18:05, Julia Lawall  wrote:
> The mmc_pwrseq_ops structures are never modified, so declare them as const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall 

Thanks, applied for next!

Kind regards
Uffe

>
> ---
>  drivers/mmc/core/pwrseq.h|2 +-
>  drivers/mmc/core/pwrseq_emmc.c   |2 +-
>  drivers/mmc/core/pwrseq_simple.c |2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/core/pwrseq.h b/drivers/mmc/core/pwrseq.h
> index 096da48..133de04 100644
> --- a/drivers/mmc/core/pwrseq.h
> +++ b/drivers/mmc/core/pwrseq.h
> @@ -16,7 +16,7 @@ struct mmc_pwrseq_ops {
>  };
>
>  struct mmc_pwrseq {
> -   struct mmc_pwrseq_ops *ops;
> +   const struct mmc_pwrseq_ops *ops;
>  };
>
>  #ifdef CONFIG_OF
> diff --git a/drivers/mmc/core/pwrseq_emmc.c b/drivers/mmc/core/pwrseq_emmc.c
> index ad4f94e..4a82bc7 100644
> --- a/drivers/mmc/core/pwrseq_emmc.c
> +++ b/drivers/mmc/core/pwrseq_emmc.c
> @@ -51,7 +51,7 @@ static void mmc_pwrseq_emmc_free(struct mmc_host *host)
> kfree(pwrseq);
>  }
>
> -static struct mmc_pwrseq_ops mmc_pwrseq_emmc_ops = {
> +static const struct mmc_pwrseq_ops mmc_pwrseq_emmc_ops = {
> .post_power_on = mmc_pwrseq_emmc_reset,
> .free = mmc_pwrseq_emmc_free,
>  };
> diff --git a/drivers/mmc/core/pwrseq_simple.c 
> b/drivers/mmc/core/pwrseq_simple.c
> index d10538b..2b16263 100644
> --- a/drivers/mmc/core/pwrseq_simple.c
> +++ b/drivers/mmc/core/pwrseq_simple.c
> @@ -87,7 +87,7 @@ static void mmc_pwrseq_simple_free(struct mmc_host *host)
> kfree(pwrseq);
>  }
>
> -static struct mmc_pwrseq_ops mmc_pwrseq_simple_ops = {
> +static const struct mmc_pwrseq_ops mmc_pwrseq_simple_ops = {
> .pre_power_on = mmc_pwrseq_simple_pre_power_on,
> .post_power_on = mmc_pwrseq_simple_post_power_on,
> .power_off = mmc_pwrseq_simple_power_off,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/19] mmc: core/host: enable support for the standard "wakeup-source" property

[Ulf Hansson]

On 21 October 2015 at 12:10, Sudeep Holla  wrote:
> Though the mmc core driver should/will continue to support the legacy
> "enable-sdio-wakeup" property to enable SDIO as the wakeup source, we
> need to add support for the new standard property "wakeup-source".
>
> This patch adds support for "wakeup-source" property in addition to the
> existing "enable-sdio-wakeup" property.
>
> Cc: Ulf Hansson 
> Cc: Adrian Hunter 
> Cc: linux-mmc@vger.kernel.org
> Signed-off-by: Sudeep Holla 

Thanks, applied for next!

Kind regards
Uffe

> ---
>  drivers/mmc/core/host.c| 3 ++-
>  drivers/mmc/host/sdhci-pltfm.c | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index 5466f25f0281..85222bb56c73 100644
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -513,7 +513,8 @@ int mmc_of_parse(struct mmc_host *host)
> host->caps2 |= MMC_CAP2_FULL_PWR_CYCLE;
> if (of_property_read_bool(np, "keep-power-in-suspend"))
> host->pm_caps |= MMC_PM_KEEP_POWER;
> -   if (of_property_read_bool(np, "enable-sdio-wakeup"))
> +   if (of_property_read_bool(np, "wakeup-source") ||
> +   of_property_read_bool(np, "enable-sdio-wakeup")) /* legacy */
> host->pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
> if (of_property_read_bool(np, "mmc-ddr-1_8v"))
> host->caps |= MMC_CAP_1_8V_DDR;
> diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
> index a207f5aaf62f..f00374bdafc9 100644
> --- a/drivers/mmc/host/sdhci-pltfm.c
> +++ b/drivers/mmc/host/sdhci-pltfm.c
> @@ -108,7 +108,8 @@ void sdhci_get_of_property(struct platform_device *pdev)
> if (of_find_property(np, "keep-power-in-suspend", NULL))
> host->mmc->pm_caps |= MMC_PM_KEEP_POWER;
>
> -   if (of_find_property(np, "enable-sdio-wakeup", NULL))
> +   if (of_property_read_bool(np, "wakeup-source") ||
> +   of_property_read_bool(np, "enable-sdio-wakeup")) /* legacy */
> host->mmc->pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
>  }
>  #else
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] mmc: tegra: Add Tegra210 support

[Ulf Hansson]

On 16 November 2015 at 10:27, Thierry Reding  wrote:
> From: Thierry Reding 
>
> Signed-off-by: Thierry Reding 

Thanks, applied for next!

Kind regards
Uffe

> ---
>  drivers/mmc/host/sdhci-tegra.c | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
> index 8d49d9af6f54..368f1b74a525 100644
> --- a/drivers/mmc/host/sdhci-tegra.c
> +++ b/drivers/mmc/host/sdhci-tegra.c
> @@ -236,7 +236,24 @@ static const struct sdhci_tegra_soc_data 
> soc_data_tegra114 = {
> NVQUIRK_DISABLE_SDR104,
>  };
>
> +static const struct sdhci_pltfm_data sdhci_tegra210_pdata = {
> +   .quirks = SDHCI_QUIRK_BROKEN_TIMEOUT_VAL |
> + SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
> + SDHCI_QUIRK_SINGLE_POWER_WRITE |
> + SDHCI_QUIRK_NO_HISPD_BIT |
> + SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC,
> +   .ops  = _sdhci_ops,
> +};
> +
> +static const struct sdhci_tegra_soc_data soc_data_tegra210 = {
> +   .pdata = _tegra210_pdata,
> +   .nvquirks = NVQUIRK_DISABLE_SDR50 |
> +   NVQUIRK_DISABLE_DDR50 |
> +   NVQUIRK_DISABLE_SDR104,
> +};
> +
>  static const struct of_device_id sdhci_tegra_dt_match[] = {
> +   { .compatible = "nvidia,tegra210-sdhci", .data = _data_tegra210 },
> { .compatible = "nvidia,tegra124-sdhci", .data = _data_tegra114 },
> { .compatible = "nvidia,tegra114-sdhci", .data = _data_tegra114 },
> { .compatible = "nvidia,tegra30-sdhci", .data = _data_tegra30 },
> --
> 2.5.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: sdhci: Fix strings broken across multiple lines

[Marek Vasut]

On Thursday, November 19, 2015 at 12:52:06 PM, Ulf Hansson wrote:
> On 18 November 2015 at 10:47, Marek Vasut  wrote:
> > This is a trivial patch which fixes printed strings split across two
> > or more lines in the source. I tried to grep for some error output*,
> > but I couldn't find it easily because it was broken across multiple
> > lines. This patch makes my life easier.
> > 
> > * in particular "Timeout waiting for hardware interrupt."
> > 
> > Signed-off-by: Marek Vasut 
> > Cc: Ulf Hansson 

Hi!

> Future wise, no need to add a Cc tag here. You should send the patch
> to me anyway.

Are CC tags now frowned upon? In case I have multiple distinct patches
(which go to distinct lists/recipients) in a queue, I use these CC tags
to track who to keep in a loop. Is there some better way to do this?

> Thanks, applied for next!

Thanks.

> FYI: There were some check patch warnings, but I decided to ignore
> them as those are related to the use of the DBG macro.

Oh yeah, the DBG() macro struck me as slightly odd. We should probably
use dev_err() or pr_err() where applicable.

> Kind regards
> Uffe

[..]

Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Arnd Bergmann]

On Thursday 19 November 2015 12:34:22 Peter Ujfalusi wrote:
> 
> I think we can go with a single API, but I don't really like that:
> dma_request_channel(dev, name, *mask, fn, fn_param);
> 
> This would cover all current uses being legacy, DT/ACPI, compat, etc:
> dma_request_channel(NULL, NULL, , fn, fn_param); /* Legacy slave */
> dma_request_channel(NULL, NULL, , NULL, NULL); /* memcpy. etc */
> dma_request_channel(dev, name, NULL, NULL, NULL); /* DT/ACPI, current slave */
> dma_request_channel(dev, name, , fn, fn_param); /* current compat */
> 
> Note, that we need "const dma_cap_mask_t *mask" to be able to make the mask
> optional.

Right, that would work, but I also don't really like it.

> If we have two main APIs, one to request slave channels and one to get any
> channel with given capability
> dma_request_slave_channel(NULL, NULL, , fn, fn_param); /* Legacy slave */
> dma_request_slave_channel(dev, name, NULL, NULL, NULL); /* DT/ACPI, current
>slave */
> dma_request_slave_channel(dev, name, , fn, fn_param); /* current compat*/
> 
> This way we can omit the mask also in cases when the client only want to get
> DMA_SLAVE, we can just build up the mask within the function. If the mask is
> provided we would copy the bits from the provided mask, so for example if you
> want to have DMA_SLAVE+DMA_CYCLIC, the driver only needs to pass DMA_CYCLIC,
> the DMA_SLAVE is going to be set anyways.

I think it's more logical here to have mask=NULL mean that we want DMA_SLAVE,
but otherwise pass the full mask as DMA_SLAVE|DMA_CYCLIC etc.

> dma_request_channel(mask); /* memcpy. etc, non slave mostly */
> 
> Not sure how to name this as reusing existing (good, descriptive) function
> names would mean changes all over the kernel to start off this.
> 
> Not used and
> request_dma_channel(); /* as _irq/_mem_region/_resource, etc */
> request_dma();
> dma_channel_request();

dma_request_slavechan();
dma_request_slave();
dma_request_mask();

> All in all, not sure which way would be better...

I think I would prefer the simplest API to have only the dev+name
arguments, as we tend to move that way for all platforms anyway, and it
seems silly to have all drivers pass three NULL arguments all the time.
At the moment, there are 139 references to dma_request_slave_channel_*
in the kernel, and only 46 of them are dma_request_slave_channel_compat.
Out of those 46, a couple can already be converted back to use
dma_request_slave_channel() because the platform now only supports
devicetree based boots and will not go back to platform data.

How about something like

extern struct dma_chan *
__dma_request_chan(struct device *dev, const char *name,
const dma_cap_mask_t *mask, dma_filter_fn fn, void 
*fn_param);

static inline struct dma_chan *
dma_request_slavechan(struct device *dev, const char *name)
{
return __dma_request_chan(dev, name, NULL, NULL, NULL);
}

static inline struct dma_chan *
dma_request_chan(const dma_cap_mask_t *mask)
{
return __dma_request_chan(NULL, NULL, mask, NULL, NULL);
}

That way the vast majority of drivers can use one of the two nice interfaces
and the rest can be converted to use __dma_request_chan().

On a related topic, we had in the past considered providing a way for
platform code to register a lookup table of some sort, to associate
a device/name pair with a configuration. That would let us use the
simplified dma_request_slavechan(dev, name) pair everywhere. We could
use the same method that we have for clk_register_clkdevs() or
pinctrl_register_map().

Something like either

static struct dma_chan_map myplatform_dma_map[] = {
{ .devname = "omap-aes0", .slave = "tx", .filter = omap_dma_filter_fn, 
.arg = (void *)65, },
{ .devname = "omap-aes0", .slave = "rx", .filter = omap_dma_filter_fn, 
.arg = (void *)66, },
};

or

static struct dma_chan_map myplatform_dma_map[] = {
{ .devname = "omap-aes0", .slave = "tx", .master = "omap-dma-engine0", 
.req = 65, },
{ .devname = "omap-aes0", .slave = "rx", .master = "omap-dma-engine0", 
.req = 66, },
};

we could even allow a combination of the two, so the simple case just specifies
master and req number, which requires changes to the dmaengine driver, but we 
could
also do a mass-conversion to the .filter/.arg variant.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] mmc: kconfig: replace FAULT_INJECTION with FAULT_INJECTION_DEBUG_FS

[Ulf Hansson]

On 10 November 2015 at 20:12, Adrien Schildknecht
 wrote:
> Fault-injection capability for MMC IO uses debugfs entries to configure
> the attributes.
> FAULT_INJECTION_DEBUG_FS must be enabled to use FAIL_MMC_REQUEST.
>
> Replace FAULT_INJECTION with FAULT_INJECTION_DEBUG_FS.
> Also remove 'select DEBUG_FS' since FAULT_INJECTION_DEBUG_FS depends on
> it.
>
> Signed-off-by: Adrien Schildknecht 

Thanks, applied for next!

Kind regards
Uffe


> ---
>  lib/Kconfig.debug | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 749e886..5c038d2 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1523,8 +1523,7 @@ config FAIL_IO_TIMEOUT
>
>  config FAIL_MMC_REQUEST
> bool "Fault-injection capability for MMC IO"
> -   select DEBUG_FS
> -   depends on FAULT_INJECTION && MMC
> +   depends on FAULT_INJECTION_DEBUG_FS && MMC
> help
>   Provide fault-injection capability for MMC IO.
>   This will make the mmc core return data errors. This is
> --
> 2.6.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: core: set regulator not found message as debug

[Ulf Hansson]

On 9 November 2015 at 15:03, Ludovic Desroches
 wrote:
> Turn the informative message about no vmmc/vqmmc regulator found in
> debug one. There is no need to indicate that something optional is
> missing. Moreover, it can bring confusion, people who doesn't know
> it is optional may consider these messages as warnings or errors.
>
> Signed-off-by: Ludovic Desroches 

Thanks, applied for next!

Kind regards
Uffe

> ---
>  drivers/mmc/core/core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 5ae89e4..5b294dd 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -1485,7 +1485,7 @@ int mmc_regulator_get_supply(struct mmc_host *mmc)
> if (IS_ERR(mmc->supply.vmmc)) {
> if (PTR_ERR(mmc->supply.vmmc) == -EPROBE_DEFER)
> return -EPROBE_DEFER;
> -   dev_info(dev, "No vmmc regulator found\n");
> +   dev_dbg(dev, "No vmmc regulator found\n");
> } else {
> ret = mmc_regulator_get_ocrmask(mmc->supply.vmmc);
> if (ret > 0)
> @@ -1497,7 +1497,7 @@ int mmc_regulator_get_supply(struct mmc_host *mmc)
> if (IS_ERR(mmc->supply.vqmmc)) {
> if (PTR_ERR(mmc->supply.vqmmc) == -EPROBE_DEFER)
> return -EPROBE_DEFER;
> -   dev_info(dev, "No vqmmc regulator found\n");
> +   dev_dbg(dev, "No vqmmc regulator found\n");
> }
>
> return 0;
> --
> 2.5.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] mmc: sdhci at91: add PM support

[Ulf Hansson]

On 11 November 2015 at 19:11, Ludovic Desroches
 wrote:
> Add runtime PM support and use runtime_force_suspend|resume() for system
> PM.
>
> Signed-off-by: Ludovic Desroches 

Thanks, applied for next!

Kind regards
Uffe

> ---
>
> Changes:
> - from v3: add error handling of runtime PM
> - from v2: cleanup thanks to Ulf feedback
> - from v1: take a runtime PM centric approach
>
>  drivers/mmc/host/sdhci-of-at91.c | 72 
> ++--
>  1 file changed, 70 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-at91.c 
> b/drivers/mmc/host/sdhci-of-at91.c
> index 06d0b50..81ab9db 100644
> --- a/drivers/mmc/host/sdhci-of-at91.c
> +++ b/drivers/mmc/host/sdhci-of-at91.c
> @@ -21,6 +21,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>
>  #include "sdhci-pltfm.h"
>
> @@ -51,6 +53,60 @@ static const struct of_device_id sdhci_at91_dt_match[] = {
> {}
>  };
>
> +#ifdef CONFIG_PM
> +static int sdhci_at91_runtime_suspend(struct device *dev)
> +{
> +   struct sdhci_host *host = dev_get_drvdata(dev);
> +   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> +   struct sdhci_at91_priv *priv = pltfm_host->priv;
> +   int ret;
> +
> +   ret = sdhci_runtime_suspend_host(host);
> +
> +   clk_disable_unprepare(priv->gck);
> +   clk_disable_unprepare(priv->hclock);
> +   clk_disable_unprepare(priv->mainck);
> +
> +   return ret;
> +}
> +
> +static int sdhci_at91_runtime_resume(struct device *dev)
> +{
> +   struct sdhci_host *host = dev_get_drvdata(dev);
> +   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> +   struct sdhci_at91_priv *priv = pltfm_host->priv;
> +   int ret;
> +
> +   ret = clk_prepare_enable(priv->mainck);
> +   if (ret) {
> +   dev_err(dev, "can't enable mainck\n");
> +   return ret;
> +   }
> +
> +   ret = clk_prepare_enable(priv->hclock);
> +   if (ret) {
> +   dev_err(dev, "can't enable hclock\n");
> +   return ret;
> +   }
> +
> +   ret = clk_prepare_enable(priv->gck);
> +   if (ret) {
> +   dev_err(dev, "can't enable gck\n");
> +   return ret;
> +   }
> +
> +   return sdhci_runtime_resume_host(host);
> +}
> +#endif /* CONFIG_PM */
> +
> +static const struct dev_pm_ops sdhci_at91_dev_pm_ops = {
> +   SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> +   pm_runtime_force_resume)
> +   SET_RUNTIME_PM_OPS(sdhci_at91_runtime_suspend,
> +  sdhci_at91_runtime_resume,
> +  NULL)
> +};
> +
>  static int sdhci_at91_probe(struct platform_device *pdev)
>  {
> const struct of_device_id   *match;
> @@ -144,12 +200,20 @@ static int sdhci_at91_probe(struct platform_device 
> *pdev)
>
> sdhci_get_of_property(pdev);
>
> +   pm_runtime_set_active(>dev);
> +   pm_runtime_enable(>dev);
> +   pm_runtime_set_autosuspend_delay(>dev, 50);
> +   pm_runtime_use_autosuspend(>dev);
> +
> ret = sdhci_add_host(host);
> if (ret)
> -   goto clocks_disable_unprepare;
> +   goto pm_runtime_disable;
>
> return 0;
>
> +pm_runtime_disable:
> +   pm_runtime_disable(>dev);
> +   pm_runtime_set_suspended(>dev);
>  clocks_disable_unprepare:
> clk_disable_unprepare(priv->gck);
> clk_disable_unprepare(priv->mainck);
> @@ -165,6 +229,10 @@ static int sdhci_at91_remove(struct platform_device 
> *pdev)
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> struct sdhci_at91_priv  *priv = pltfm_host->priv;
>
> +   pm_runtime_get_sync(>dev);
> +   pm_runtime_disable(>dev);
> +   pm_runtime_put_noidle(>dev);
> +
> sdhci_pltfm_unregister(pdev);
>
> clk_disable_unprepare(priv->gck);
> @@ -178,7 +246,7 @@ static struct platform_driver sdhci_at91_driver = {
> .driver = {
> .name   = "sdhci-at91",
> .of_match_table = sdhci_at91_dt_match,
> -   .pm = SDHCI_PLTFM_PMOPS,
> +   .pm = _at91_dev_pm_ops,
> },
> .probe  = sdhci_at91_probe,
> .remove = sdhci_at91_remove,
> --
> 2.5.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: omap_hsmmc: No need to check DMA channel validity at module remove

[Ulf Hansson]

On 3 November 2015 at 12:37, Peter Ujfalusi  wrote:
> The driver will not probe without valid DMA channels so no need to check
> if they are valid when the module is removed.
>
> Signed-off-by: Peter Ujfalusi 
> CC: Ulf Hansson 

Thanks, applied for next!

Kind regards
Uffe

> ---
>  drivers/mmc/host/omap_hsmmc.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index f70e52b05648..712c74fd0401 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -2262,10 +2262,8 @@ static int omap_hsmmc_remove(struct platform_device 
> *pdev)
> pm_runtime_get_sync(host->dev);
> mmc_remove_host(host->mmc);
>
> -   if (host->tx_chan)
> -   dma_release_channel(host->tx_chan);
> -   if (host->rx_chan)
> -   dma_release_channel(host->rx_chan);
> +   dma_release_channel(host->tx_chan);
> +   dma_release_channel(host->rx_chan);
>
> pm_runtime_put_sync(host->dev);
> pm_runtime_disable(host->dev);
> --
> 2.6.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: sh_mmcif: rework dma channel handling

[Arnd Bergmann]

On Thursday 19 November 2015 13:00:48 Ulf Hansson wrote:
> Thanks, applied for next!
> 
> FYI: There were some check patch warnings, I decided to fix them
> myself before applying.
> 

Ok, thanks!

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: sdhci: Fix strings broken across multiple lines

[Marek Vasut]

On Thursday, November 19, 2015 at 01:05:15 PM, Ulf Hansson wrote:
> On 19 November 2015 at 12:58, Marek Vasut  wrote:
> > On Thursday, November 19, 2015 at 12:52:06 PM, Ulf Hansson wrote:
> >> On 18 November 2015 at 10:47, Marek Vasut  wrote:
> >> > This is a trivial patch which fixes printed strings split across two
> >> > or more lines in the source. I tried to grep for some error output*,
> >> > but I couldn't find it easily because it was broken across multiple
> >> > lines. This patch makes my life easier.
> >> > 
> >> > * in particular "Timeout waiting for hardware interrupt."
> >> > 
> >> > Signed-off-by: Marek Vasut 
> >> > Cc: Ulf Hansson 
> > 
> > Hi!
> > 
> >> Future wise, no need to add a Cc tag here. You should send the patch
> >> to me anyway.
> > 
> > Are CC tags now frowned upon? In case I have multiple distinct patches
> > (which go to distinct lists/recipients) in a queue, I use these CC tags
> > to track who to keep in a loop. Is there some better way to do this?
> 
> As this was a separate patch I didn't quite understand the Cc.
> If the patch is a part of a patchset, it makes more sense if it
> involves different subsystems/maintainers.

It does, but the patches are orthogonal in my case, so I am sending them
using git send-email -1 or such.

> Anyway, no big deal for me! If I don't like the Cc tag, I can easily
> remove it when applying.

Thanks :-)

Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] mmc: sdhci-esdhc-imx: move the setting of watermark level out of probe

[Dong Aisheng]

On Thu, Nov 19, 2015 at 7:17 PM, Ulf Hansson  wrote:
> On 10 November 2015 at 10:43, Haibo Chen  wrote:
>> Currently, we config the watermark_level register only in probe.
>> This will cause the mmc write operation timeout issue after system
>> resume back in LPSR mode. Because in LPSR mode, after system resume
>> back, the watermark_level register(0x44) changes to 0x08000880, which
>> set the write watermark level as 0, and set the read watermark level
>> as 128. This value is incorrect.
>>
>> This patch move the setting of watermark level register out of probe,
>> so after system resume back, mmc driver can set this watermark level
>> register back to 0x10401040.
>
> This seems all reasonable! But...
>
>>
>> Signed-off-by: Haibo Chen 
>> ---
>>  drivers/mmc/host/sdhci-esdhc-imx.c | 14 --
>>  1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
>> b/drivers/mmc/host/sdhci-esdhc-imx.c
>> index 1f1582f..1508949 100644
>> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
>> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
>> @@ -584,6 +584,14 @@ static void esdhc_writeb_le(struct sdhci_host *host, u8 
>> val, int reg)
>> mask = 0x & ~(ESDHC_CTRL_BUSWIDTH_MASK | 
>> ESDHC_CTRL_D3CD);
>>
>> esdhc_clrset_le(host, mask, new_val, reg);
>> +
>> +   /*
>> +* The imx6q/imx7d ROM code will change the default watermark
>> +* level setting to something insane.  Change it back here.
>> +*/
>> +if (esdhc_is_usdhc(imx_data))
>> +writel(0x10401040, host->ioaddr + ESDHC_WTMK_LVL);
>> +
>
> ... why don't keep setting the watermark in ->probe() and instead just
> add it at as additional task to do at system PM resume?
>

I guess the reason may be keep using common sdhci_pltfrm_suspend() function
instead of creating new one.

But i think it's a good suggestion that we can create a platform
specific suspend/resume
function and put pm stuff into there for better code organization.
Haibo, you may try Ulf's suggestion.

Regards
Dong Aisheng

>> return;
>> }
>> esdhc_clrset_le(host, 0xff, val, reg);
>> @@ -1155,13 +1163,7 @@ static int sdhci_esdhc_imx_probe(struct 
>> platform_device *pdev)
>> host->quirks |= SDHCI_QUIRK_NO_MULTIBLOCK
>> | SDHCI_QUIRK_BROKEN_ADMA;
>>
>> -   /*
>> -* The imx6q ROM code will change the default watermark level setting
>> -* to something insane.  Change it back here.
>> -*/
>> if (esdhc_is_usdhc(imx_data)) {
>> -   writel(0x10401040, host->ioaddr + ESDHC_WTMK_LVL);
>> -
>> host->quirks2 |= SDHCI_QUIRK2_PRESET_VALUE_BROKEN;
>> host->mmc->caps |= MMC_CAP_1_8V_DDR;
>>
>> --
>> 1.9.1
>>
>
> Kind regards
> Uffe
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] mmc: sdhci-esdhc-imx: correct the tuning-step setting

[Dong Aisheng]

Hi Ulf,

On Thu, Nov 19, 2015 at 7:20 PM, Ulf Hansson  wrote:
> On 10 November 2015 at 10:43, Haibo Chen  wrote:
>> Here we use '|=' to set the tuning-step, but before that, we should
>> clear the tuning-step, otherwise we could got the wrong setting.
>>
>> Signed-off-by: Haibo Chen 
>> ---
>>  drivers/mmc/host/sdhci-esdhc-imx.c | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
>> b/drivers/mmc/host/sdhci-esdhc-imx.c
>> index 1508949..64275c7 100644
>> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
>> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
>> @@ -76,6 +76,7 @@
>>  #define ESDHC_STD_TUNING_EN(1 << 24)
>>  /* NOTE: the minimum valid tuning start tap for mx6sl is 1 */
>>  #define ESDHC_TUNING_START_TAP 0x1
>> +#define ESDHC_TUNING_STEP_MASK 0x0007
>>  #define ESDHC_TUNING_STEP_SHIFT16
>>
>>  /* pinctrl state */
>> @@ -489,9 +490,11 @@ static void esdhc_writew_le(struct sdhci_host *host, 
>> u16 val, int reg)
>> m |= ESDHC_MIX_CTRL_FBCLK_SEL;
>> tuning_ctrl = readl(host->ioaddr + 
>> ESDHC_TUNING_CTRL);
>> tuning_ctrl |= ESDHC_STD_TUNING_EN | 
>> ESDHC_TUNING_START_TAP;
>> -   if (imx_data->boarddata.tuning_step)
>> +   if (imx_data->boarddata.tuning_step) {
>> +   tuning_ctrl &= 
>> ~ESDHC_TUNING_STEP_MASK;
>> tuning_ctrl |= 
>> imx_data->boarddata.tuning_step << ESDHC_TUNING_STEP_SHIFT;
>> -   writel(tuning_ctrl, host->ioaddr + 
>> ESDHC_TUNING_CTRL);
>> +   }
>> +   writel(tuning_ctrl, host->ioaddr + 
>> ESDHC_TUNING_CTRL);
>> } else {
>> v &= ~ESDHC_MIX_CTRL_EXE_TUNE;
>> }
>> --
>> 1.9.1
>>
>
> Looks good to me, but is there a dependency to patch 1/2 that should
> prevent me from applying this one?
>

No dependency.
Acked-by: Dong Aisheng 

Regards
Dong Aisheng

> Kind regards
> Uffe
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html