Re: [RFC 3/3] mmc: dw_mmc: exynos: add a quirk for SMU.
On 20 August 2013 16:07, Alim Akhtar wrote:
> Hi Yuvaraj
>
> On Mon, Aug 19, 2013 at 12:06 PM, Yuvaraj Kumar C D
> wrote:
>> Exynos5420 Mobile Storage Host controller has Security Management Unit
>> (SMU) for channel 0 and channel 1 (mainly for eMMC).This patch adds a
>> quirk to bypass SMU as it is not being used yet.
>>
>> This patch is on top of the below patch by Doug Anderson.
>> mmc: dw_mmc: Add exynos resume_noirq callback to clear WAKEUP_INT
>>
>> Signed-off-by: Yuvaraj Kumar C D
>> ---
>> drivers/mmc/host/dw_mmc-exynos.c | 41
>> ++
>> drivers/mmc/host/dw_mmc.c|3 +++
>> include/linux/mmc/dw_mmc.h |2 ++
>> 3 files changed, 46 insertions(+)
>>
>> diff --git a/drivers/mmc/host/dw_mmc-exynos.c
>> b/drivers/mmc/host/dw_mmc-exynos.c
>> index 19c845b..5d82c45 100644
>> --- a/drivers/mmc/host/dw_mmc-exynos.c
>> +++ b/drivers/mmc/host/dw_mmc-exynos.c
>> @@ -35,6 +35,25 @@
>> #define EXYNOS4210_FIXED_CIU_CLK_DIV 2
>> #define EXYNOS4412_FIXED_CIU_CLK_DIV 4
>>
>> +/* Block number in eMMC */
>> +#define DWMCI_BLOCK_NUM0x
>> +
>> +#define SDMMC_EMMCP_BASE 0x1000
>> +#define SDMMC_MPSECURITY (SDMMC_EMMCP_BASE + 0x0010)
>> +#define SDMMC_MPSBEGIN0(SDMMC_EMMCP_BASE + 0x0200)
>> +#define SDMMC_MPSEND0 (SDMMC_EMMCP_BASE + 0x0204)
>> +#define SDMMC_MPSCTRL0 (SDMMC_EMMCP_BASE + 0x020C)
>> +
>> +/* SMU control bits */
>> +#define DWMCI_MPSCTRL_SECURE_READ_BIT BIT(7)
>> +#define DWMCI_MPSCTRL_SECURE_WRITE_BIT BIT(6)
>> +#define DWMCI_MPSCTRL_NON_SECURE_READ_BIT BIT(5)
>> +#define DWMCI_MPSCTRL_NON_SECURE_WRITE_BIT BIT(4)
>> +#define DWMCI_MPSCTRL_USE_FUSE_KEY BIT(3)
>> +#define DWMCI_MPSCTRL_ECB_MODE BIT(2)
>> +#define DWMCI_MPSCTRL_ENCRYPTION BIT(1)
>> +#define DWMCI_MPSCTRL_VALIDBIT(0)
>> +
>> /* Variations in Exynos specific dw-mshc controller */
>> enum dw_mci_exynos_type {
>> DW_MCI_TYPE_EXYNOS4210,
>> @@ -74,6 +93,17 @@ static int dw_mci_exynos_priv_init(struct dw_mci *host)
>> {
>> struct dw_mci_exynos_priv_data *priv = host->priv;
>>
>> + if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS5420 &&
>> + host->pdata->quirks & DW_MCI_QUIRK_BYPASS_SMU) {
>> + mci_writel(host, MPSBEGIN0, 0);
>> + mci_writel(host, MPSEND0, DWMCI_BLOCK_NUM);
>> + mci_writel(host, MPSCTRL0,
>> + DWMCI_MPSCTRL_SECURE_WRITE_BIT |
>> + DWMCI_MPSCTRL_NON_SECURE_READ_BIT |
>> + DWMCI_MPSCTRL_VALID |
>> + DWMCI_MPSCTRL_NON_SECURE_WRITE_BIT);
>> + }
>> +
> This seems to be repeating here and below, please make a function
> instead to avoid code duplication.
No need of a separate function for the above statement. Instead invoke
the dw_mci_exynos_priv_init() from the resume path. Because there is
no change in code.
>> return 0;
>> }
>>
>> @@ -106,7 +136,18 @@ static int dw_mci_exynos_suspend(struct device *dev)
>> static int dw_mci_exynos_resume(struct device *dev)
>> {
>> struct dw_mci *host = dev_get_drvdata(dev);
>> + struct dw_mci_exynos_priv_data *priv = host->priv;
>>
>> + if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS5420 &&
>> + host->pdata->quirks & DW_MCI_QUIRK_BYPASS_SMU) {
>> + mci_writel(host, MPSBEGIN0, 0);
>> + mci_writel(host, MPSEND0, DWMCI_BLOCK_NUM);
>> + mci_writel(host, MPSCTRL0,
>> + DWMCI_MPSCTRL_SECURE_WRITE_BIT |
>> + DWMCI_MPSCTRL_NON_SECURE_READ_BIT |
>> + DWMCI_MPSCTRL_VALID |
>> + DWMCI_MPSCTRL_NON_SECURE_WRITE_BIT);
>> + }
> See comment above.
>> return dw_mci_resume(host);
>> }
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 0c0cada..49df69f 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -2107,6 +2107,9 @@ static struct dw_mci_of_quirks {
>> }, {
>> .quirk = "broken-cd",
>> .id = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
>> + }, {
>> + .quirk = "bypass-smu",
>> + .id = DW_MCI_QUIRK_BYPASS_SMU,
>> },
>> };
>>
>> diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
>> index 198f0fa..2d3f83f 100644
>> --- a/include/linux/mmc/dw_mmc.h
>> +++ b/include/linux/mmc/dw_mmc.h
>> @@ -209,6 +209,8 @@ struct dw_mci_dma_ops {
>> #define DW_MCI_QUIRK_HIGHSPEED BIT(2)
>> /* Unreliable card detection */
>> #define DW_MCI_QUIRK_BROKEN_CARD_DETECTION BIT(3)
>> +/*Bypass the Security management unit*/
>> +#define DW_MCI_QUIRK_BYPASS_SMUBIT(4)
>>
>> /* S
Re: [PATCH V2 2/2] ARM: dts: Add dwmmc nodes in SOC specific dts file
--- Original Message ---
Sender : yuvaraj...@gmail.com
Date : Aug 21, 2013 12:07 (GMT+05:30)
Title : [PATCH V2 2/2] ARM: dts: Add dwmmc nodes in SOC specific dts file
From: Yuvaraj Kumar C D
Exynos5 series SOC's have different versions of DWMMC controller.
So dwmmc device nodes moved from Exynos5 SOC's common dts file to
SOC specific dts file.
changes since V1:
1.disable node by status = disabled in SOC file
2.enable node by status = okay in board specific file
Signed-off-by: Yuvaraj Kumar C D
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 10 ++
arch/arm/boot/dts/exynos5250.dtsi | 16
2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 2538b32..bd19d55d 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -141,6 +141,7 @@
};
dwmmc0@1220 {
+ status = "okay";
num-slots = <1>;
supports-highspeed;
broken-cd;
@@ -158,11 +159,8 @@
};
};
- dwmmc1@1221 {
- status = "disabled";
- };
-
dwmmc2@1222 {
+ status = "okay";
num-slots = <1>;
supports-highspeed;
fifo-depth = <0x80>;
@@ -180,10 +178,6 @@
};
};
- dwmmc3@1223 {
- status = "disabled";
- };
-
spi_0: spi@12d2 {
status = "disabled";
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 1eec646..b1b6f61 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -387,21 +387,36 @@
};
dwmmc_0: dwmmc0@1220 {
+ compatible = "samsung,exynos5250-dw-mshc";
+ interrupts = <0 75 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <0x1220 0x1000>;
clocks = <&clock 280>, <&clock 139>;
clock-names = "biu", "ciu";
+ status = "disabled";
};
dwmmc_1: dwmmc1@1221 {
+ compatible = "samsung,exynos5250-dw-mshc";
+ interrupts = <0 76 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <0x1221 0x1000>;
clocks = <&clock 281>, <&clock 140>;
clock-names = "biu", "ciu";
+ status = "disabled";
};
dwmmc_2: dwmmc2@1222 {
+ compatible = "samsung,exynos5250-dw-mshc";
+ interrupts = <0 77 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <0x1222 0x1000>;
clocks = <&clock 282>, <&clock 141>;
clock-names = "biu", "ciu";
+ status = "disabled";
};
dwmmc_3: dwmmc3@1223 {
@@ -412,6 +427,7 @@
#size-cells = <0>;
clocks = <&clock 283>, <&clock 142>;
clock-names = "biu", "ciu";
+ status = "disabled";
};
i2s0: i2s@0383 {
Looks Ok to me.
Reviewed By: Girish K S
--
1.7.9.5
Re: [PATCH v2] mmc: core: Fix select power class after resume
Hi,
On 23 April 2013 19:57, Fredrik Soderstedt
wrote:
>
> Use the saved values in card->ext_csd when selecting power class.
> By doing this the power class will be selected even if mmc_init_card
> is called with oldcard != NULL, which is the case after a suspend/resume.
>
> Today ext_csd is NULL if mmc_init_card is called with oldcard != NULL
> and power class will not be selected.
>
> According to the eMMC specification the POWER_CLASS value is reset after
> power failure, H/W reset assertion and any CMD0 reset.
>
> CC: Girish K S
> Signed-off-by: Fredrik Soderstedt
> ---
>
> Changes since v1:
> - Fix typo from card->ext_csd.raw_pwr_cl_52_360 to
> card->ext_csd.raw_pwr_cl_ddr_52_360
>
> drivers/mmc/core/mmc.c | 74
>
> include/linux/mmc/card.h | 10 ++-
> 2 files changed, 59 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 0cbd1ef..d6d957e 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -461,6 +461,24 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8
> *ext_csd)
> */
> card->ext_csd.boot_ro_lock = ext_csd[EXT_CSD_BOOT_WP];
> card->ext_csd.boot_ro_lockable = true;
> +
> + /* Save power class values */
> + card->ext_csd.raw_pwr_cl_52_195 =
> + ext_csd[EXT_CSD_PWR_CL_52_195];
> + card->ext_csd.raw_pwr_cl_26_195 =
> + ext_csd[EXT_CSD_PWR_CL_26_195];
> + card->ext_csd.raw_pwr_cl_52_360 =
> + ext_csd[EXT_CSD_PWR_CL_52_360];
> + card->ext_csd.raw_pwr_cl_26_360 =
> + ext_csd[EXT_CSD_PWR_CL_26_360];
> + card->ext_csd.raw_pwr_cl_200_195 =
> + ext_csd[EXT_CSD_PWR_CL_200_195];
> + card->ext_csd.raw_pwr_cl_200_360 =
> + ext_csd[EXT_CSD_PWR_CL_200_360];
> + card->ext_csd.raw_pwr_cl_ddr_52_195 =
> + ext_csd[EXT_CSD_PWR_CL_DDR_52_195];
> + card->ext_csd.raw_pwr_cl_ddr_52_360 =
> + ext_csd[EXT_CSD_PWR_CL_DDR_52_360];
> }
>
> if (card->ext_csd.rev >= 5) {
> @@ -607,7 +625,23 @@ static int mmc_compare_ext_csds(struct mmc_card
> *card, unsigned bus_width)
> (card->ext_csd.raw_sectors[2] ==
> bw_ext_csd[EXT_CSD_SEC_CNT + 2]) &&
> (card->ext_csd.raw_sectors[3] ==
> - bw_ext_csd[EXT_CSD_SEC_CNT + 3]));
> + bw_ext_csd[EXT_CSD_SEC_CNT + 3]) &&
> + (card->ext_csd.raw_pwr_cl_52_195 ==
> + bw_ext_csd[EXT_CSD_PWR_CL_52_195]) &&
> + (card->ext_csd.raw_pwr_cl_26_195 ==
> + bw_ext_csd[EXT_CSD_PWR_CL_26_195]) &&
> + (card->ext_csd.raw_pwr_cl_52_360 ==
> + bw_ext_csd[EXT_CSD_PWR_CL_52_360]) &&
> + (card->ext_csd.raw_pwr_cl_26_360 ==
> + bw_ext_csd[EXT_CSD_PWR_CL_26_360]) &&
> + (card->ext_csd.raw_pwr_cl_200_195 ==
> + bw_ext_csd[EXT_CSD_PWR_CL_200_195]) &&
> + (card->ext_csd.raw_pwr_cl_200_360 ==
> + bw_ext_csd[EXT_CSD_PWR_CL_200_360]) &&
> + (card->ext_csd.raw_pwr_cl_ddr_52_195 ==
> + bw_ext_csd[EXT_CSD_PWR_CL_DDR_52_195]) &&
> + (card->ext_csd.raw_pwr_cl_ddr_52_360 ==
> + bw_ext_csd[EXT_CSD_PWR_CL_DDR_52_360]));
> if (err)
> err = -EINVAL;
>
> @@ -676,11 +710,10 @@ static struct device_type mmc_type = {
> * mmc_switch command.
> */
> static int mmc_select_powerclass(struct mmc_card *card,
> - unsigned int bus_width, u8 *ext_csd)
> + unsigned int bus_width)
> {
> int err = 0;
> - unsigned int pwrclass_val;
> - unsigned int index = 0;
> + unsigned int pwrclass_val = 0;
> struct mmc_host *host;
>
> BUG_ON(!card);
> @@ -688,9 +721,6 @@ static int mmc_select_powerclass(struct mmc_card
> *card,
> host = card->host;
> BUG_ON(!host);
>
> - if (ext_csd == NULL)
> - return 0;
> -
> /* Power class selection is supported for versions >= 4.0 */
> if (card->csd.mmca_vsn < CSD_SPEC_VER_4)
>
Re: [PATCH] goldfish: emulated MMC device
On 21 January 2013 15:43, Alan Cox wrote:
> From: Mike Lockwood
>
> This driver handles the virtual MMC device present in the Goldfish emulator.
> The patch folds together initial work from Mike Lockwood and patches by
> San Mehat, Jun Nakajima and Tom Keel plus cleanups
> by Alan Cox to get it all into 3.6 shape.
>
> Signed-off-by: Mike A. Chan
> [cleaned up and x86 support added]
> Signed-off-by: Sheng Yang
> Signed-off-by: Yunhong Jiang
> Signed-off-by: Xiaohui Xin
> Signed-off-by: Jun Nakajima
> Signed-off-by: Bruce Beare
> [Moved to 3.4]
> Signed-off-by: Tom Keel
> [Moved to 3.7]
> Signed-off-by: Alan Cox
> ---
>
> drivers/mmc/host/Kconfig|7 +
> drivers/mmc/host/Makefile |1
> drivers/mmc/host/goldfish.c | 566
> +++
> 3 files changed, 574 insertions(+)
> create mode 100644 drivers/mmc/host/goldfish.c
>
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 7684f7f..aebe265 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -372,6 +372,13 @@ config MMC_DAVINCI
>If you have an DAVINCI board with a Multimedia Card slot,
>say Y or M here. If unsure, say N.
>
> +config MMC_GOLDFISH
> + tristate "goldfish qemu Multimedia Card Interface support"
> + depends on GOLDFISH
> + help
> + This selects the Goldfish Multimedia card Interface emulation
> + found on the Goldfish Android virtual device emulation.
> +
> config MMC_SPI
> tristate "MMC/SD/SDIO over SPI"
> depends on SPI_MASTER && !HIGHMEM && HAS_DMA
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> index d5ea0722..82eba3e 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_MMC_TIFM_SD) += tifm_sd.o
> obj-$(CONFIG_MMC_MSM) += msm_sdcc.o
> obj-$(CONFIG_MMC_MVSDIO) += mvsdio.o
> obj-$(CONFIG_MMC_DAVINCI) += davinci_mmc.o
> +obj-$(CONFIG_MMC_GOLDFISH) += goldfish.o
> obj-$(CONFIG_MMC_SPI) += mmc_spi.o
> ifeq ($(CONFIG_OF),y)
> obj-$(CONFIG_MMC_SPI) += of_mmc_spi.o
> diff --git a/drivers/mmc/host/goldfish.c b/drivers/mmc/host/goldfish.c
> new file mode 100644
> index 000..5763f78
> --- /dev/null
> +++ b/drivers/mmc/host/goldfish.c
> @@ -0,0 +1,566 @@
> +/*
> + * Copyright 2007, Google Inc.
> + * Copyright 2012, Intel Inc.
> + *
> + * based on omap.c driver, which was
> + * Copyright (C) 2004 Nokia Corporation
> + * Written by Tuukka Tikkanen and Juha Yrjölä
> + * Misc hacks here and there by Tony Lindgren
> + * Other hacks (DMA, SD, etc) by David Brownell
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#define DRIVER_NAME "goldfish_mmc"
> +
> +#define BUFFER_SIZE 16384
> +
> +#define GOLDFISH_MMC_READ(host, addr) (readl(host->reg_base + addr))
> +#define GOLDFISH_MMC_WRITE(host, addr, x) (writel(x, host->reg_base +
> addr))
> +
> +
> +enum {
> + /* status register */
> + MMC_INT_STATUS = 0x00,
> + /* set this to enable IRQ */
> + MMC_INT_ENABLE = 0x04,
> + /* set this to specify buffer address */
> + MMC_SET_BUFFER = 0x08,
> +
> + /* MMC command number */
> + MMC_CMD = 0x0C,
> +
> + /* MMC argument */
> + MMC_ARG = 0x10,
> +
> + /* MMC response (or R2 bits 0 - 31) */
> + MMC_RESP_0 = 0x14,
> +
> + /* MMC R2 response bits 32 - 63 */
> + MMC_RESP_1 = 0x18,
> +
> + /* MMC R2 response bits 64 - 95 */
> + MMC_RESP_2 = 0x1C,
> +
> + /* MMC R2 response bits 96 - 127 */
> + MMC_RESP_3 = 0x20,
> +
> + MMC_BLOCK_LENGTH= 0x24,
> + MMC_BLOCK_COUNT = 0x28,
> +
> + /* MMC state flags */
> + MMC_STATE = 0x2C,
> +
> + /* MMC_INT_STATUS bits */
> +
> + MMC_STAT_END_OF_CMD = 1U << 0,
> + MMC_STAT_END_OF_DATA= 1U << 1,
> + MMC_STAT_STATE_CHANGE = 1U << 2,
> + MMC_STAT_CMD_TIMEOUT= 1U << 3,
> +
> + /* MMC_STATE bits */
> + MMC_STATE_INSERTED = 1U << 0,
> + MMC_STATE_READ_ONLY= 1U << 1,
> +};
> +
> +/*
> + * Command types
> + */
> +#define OMAP_MMC_CMDTYPE_BC0
> +#define OMAP
Re: [RFC PATCH 3.7.0-rc4 2/4] mm:exynos: use of_simple_module_id_table macro.
On 16 November 2012 18:51, Srinivas KANDAGATLA
wrote:
> From: Srinivas Kandagatla
>
> This patch uses of_simple_module_id_table macro to replace code like:
>
> #ifdef CONFIG_OF
> static struct of_device_id xxx_of_match[] = {
> { .compatible = "yyy,xxx" },
> { },
> };
> MODULE_DEVICE_TABLE(of, xxx_of_match);
> #endif
>
> with
> of_simple_module_id_table(xxx_of_match, "yyy,zzz");
>
> Signed-off-by: Srinivas Kandagatla
> ---
> drivers/mmc/host/dw_mmc-exynos.c |7 +--
> 1 files changed, 1 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc-exynos.c
> b/drivers/mmc/host/dw_mmc-exynos.c
> index 660bbc5..1e9596a 100644
> --- a/drivers/mmc/host/dw_mmc-exynos.c
> +++ b/drivers/mmc/host/dw_mmc-exynos.c
> @@ -218,12 +218,7 @@ static struct dw_mci_drv_data exynos5250_drv_data = {
> .setup_bus = dw_mci_exynos_setup_bus,
> };
>
> -static const struct of_device_id dw_mci_exynos_match[] = {
> - { .compatible = "samsung,exynos5250-dw-mshc",
> - .data = (void *)&exynos5250_drv_data, },
> - {},
> -};
Here's the problem. You are missing the driver data for the exynos
SoC. this is very much required.
where's the .data = (void *)&exynos5250_drv_data,?
> -MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
> +of_simple_module_id_table(dw_mci_pltfm_match, "samsung,exynos5250-dw-mshc");
>
> int dw_mci_exynos_probe(struct platform_device *pdev)
> {
> --
> 1.7.0.4
>
> --
> 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/4 v4] MMC/SD: Add callback function to detect card
On 30 October 2012 13:42, wrote:
> From: Jerry Huang
>
> In order to check whether the card has been removed, the function
> mmc_send_status() will send command CMD13 to card and ask the card
> to send its status register to sdhc driver, which will generate
> many interrupts repeatedly and make the system performance bad.
>
> Therefore, add callback function get_cd() to check whether
> the card has been removed when the driver has this callback function.
>
> If the card is present, 1 will return, if the card is absent, 0 will return.
> If the controller will not support this feature, -ENOSYS will return.
>
> Signed-off-by: Jerry Huang
> CC: Anton Vorontsov
> CC: Chris Ball
> ---
> changes for v2:
> - when controller don't support get_cd, return -ENOSYS
> - add the CC
> changes for v3:
> - enalbe the controller clock in platform, instead of core
> changes for v4:
> - move the detect code to core.c according to the new structure
>
> drivers/mmc/core/core.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 9c162cd..6412355 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -2073,7 +2073,7 @@ static int mmc_rescan_try_freq(struct mmc_host *host,
> unsigned freq)
>
> int _mmc_detect_card_removed(struct mmc_host *host)
> {
> - int ret;
> + int ret = -ENOSYS;
>
> if ((host->caps & MMC_CAP_NONREMOVABLE) || !host->bus_ops->alive)
> return 0;
> @@ -2081,7 +2081,13 @@ int _mmc_detect_card_removed(struct mmc_host *host)
> if (!host->card || mmc_card_removed(host->card))
> return 1;
>
> - ret = host->bus_ops->alive(host);
> + if (host->ops->get_cd) {
> + ret = host->ops->get_cd(host);
> + if (ret >= 0)
> + ret = !ret;
> + }
> + if (ret < 0)
> + ret = host->bus_ops->alive(host);
why should we check for negative here? can move this code into else
path of if (host->ops->get_cd).
> if (ret) {
> mmc_card_set_removed(host->card);
> pr_debug("%s: card remove detected\n", mmc_hostname(host));
> --
> 1.7.9.5
>
>
> --
> 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: [RFC PATCH 2/2] MMC: SD/MMC Host Controller for Wondermedia WM8505/WM8650
On 16 October 2012 02:37, Tony Prisk wrote: > On Mon, 2012-10-15 at 21:32 +0900, Girish K S wrote: >> On 15 October 2012 17:24, Tony Prisk wrote: >> > This patch adds support for the SD/MMC host controller found >> > on Wondermedia 8xxx series SoCs, currently supported under >> > arm/arch-vt8500. >> > >> > Signed-off-by: Tony Prisk >> > --- >> > drivers/mmc/host/Kconfig | 12 + >> > drivers/mmc/host/Makefile|1 + >> > drivers/mmc/host/wmt-sdmmc.c | 983 >> > ++ >> > 3 files changed, 996 insertions(+) >> > create mode 100644 drivers/mmc/host/wmt-sdmmc.c >> > >> > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig >> > index 9bf10e7..7f4377b 100644 >> > --- a/drivers/mmc/host/Kconfig >> > +++ b/drivers/mmc/host/Kconfig >> > @@ -621,3 +621,15 @@ config MMC_USHC >> > >> > Note: These controllers only support SDIO cards and do not >> > support MMC or SD memory cards. >> > + >> > +config MMC_WMT >> > + tristate "Wondermedia SD/MMC Host Controller support" >> > + depends on ARCH_VT8500 >> > + default y >> > + help >> > + This selects support for the SD/MMC Host Controller on >> > + Wondermedia WM8505/WM8650 based SoCs. >> > + >> > + To compile this driver as a module, choose M here: the >> > + module will be called wmt-sdmmc. >> > + >> > diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile >> > index 17ad0a7..9c91f1f 100644 >> > --- a/drivers/mmc/host/Makefile >> > +++ b/drivers/mmc/host/Makefile >> > @@ -45,6 +45,7 @@ obj-$(CONFIG_MMC_SH_MMCIF)+= sh_mmcif.o >> > obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o >> > obj-$(CONFIG_MMC_VUB300) += vub300.o >> > obj-$(CONFIG_MMC_USHC) += ushc.o >> > +obj-$(CONFIG_MMC_WMT) += wmt-sdmmc.o >> > >> > obj-$(CONFIG_MMC_SDHCI_PLTFM) += sdhci-pltfm.o >> > obj-$(CONFIG_MMC_SDHCI_CNS3XXX)+= sdhci-cns3xxx.o >> > diff --git a/drivers/mmc/host/wmt-sdmmc.c b/drivers/mmc/host/wmt-sdmmc.c >> > new file mode 100644 >> > index 000..def1ec9 >> > --- /dev/null >> > +++ b/drivers/mmc/host/wmt-sdmmc.c >> > @@ -0,0 +1,983 @@ >> > +/* >> > + * WM8505/WM8650 SD/MMC Host Controller >> > + * >> > + * Copyright (C) 2010 Tony Prisk >> > + * Copyright (C) 2008 WonderMedia Technologies, Inc. >> > + * >> > + * This program is free software; you can redistribute it and/or modify >> > + * it under the terms of the GNU General Public License version 2 as >> > + * published by the Free Software Foundation >> > + */ >> > + >> > +#include >> > +#include >> > +#include >> > +#include >> > +#include >> > +#include >> > +#include >> > +#include >> > +#include >> > +#include >> > +#include >> > + >> > +#include >> > +#include >> > +#include >> > + >> > +#include >> > +#include >> > +#include >> > + >> > +#include >> > + >> > + >> > +#define DRIVER_NAME "wmt-sdhc" >> > + >> > + >> > +/* MMC/SD controller registers */ >> > +#define SDMMC_CTLR 0x00 >> > +#define SDMMC_CMD 0x01 >> > +#define SDMMC_RSPTYPE 0x02 >> > +#define SDMMC_ARG 0x04 >> > +#define SDMMC_BUSMODE 0x08 >> > +#define SDMMC_BLKLEN 0x0C >> > +#define SDMMC_BLKCNT 0x0E >> > +#define SDMMC_RSP 0x10 >> > +#define SDMMC_CBCR 0x20 >> > +#define SDMMC_INTMASK0 0x24 >> > +#define SDMMC_INTMASK1 0x25 >> > +#define SDMMC_STS0 0x28 >> > +#define SDMMC_STS1 0x29 >> > +#define SDMMC_STS2 0x2A >> > +#define SDMMC_STS3 0x2B >> > +#define SDMMC_RSPTIMEOUT 0x2C >> > +#define SDMMC_CLK 0x30/* VT8500 only */ >> > +#define SDMMC_EXTCTRL 0x34 >> > +#define SDMMC_SBLKLEN
Re: [RFC PATCH 2/2] MMC: SD/MMC Host Controller for Wondermedia WM8505/WM8650
On 15 October 2012 17:24, Tony Prisk wrote: > This patch adds support for the SD/MMC host controller found > on Wondermedia 8xxx series SoCs, currently supported under > arm/arch-vt8500. > > Signed-off-by: Tony Prisk > --- > drivers/mmc/host/Kconfig | 12 + > drivers/mmc/host/Makefile|1 + > drivers/mmc/host/wmt-sdmmc.c | 983 > ++ > 3 files changed, 996 insertions(+) > create mode 100644 drivers/mmc/host/wmt-sdmmc.c > > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig > index 9bf10e7..7f4377b 100644 > --- a/drivers/mmc/host/Kconfig > +++ b/drivers/mmc/host/Kconfig > @@ -621,3 +621,15 @@ config MMC_USHC > > Note: These controllers only support SDIO cards and do not > support MMC or SD memory cards. > + > +config MMC_WMT > + tristate "Wondermedia SD/MMC Host Controller support" > + depends on ARCH_VT8500 > + default y > + help > + This selects support for the SD/MMC Host Controller on > + Wondermedia WM8505/WM8650 based SoCs. > + > + To compile this driver as a module, choose M here: the > + module will be called wmt-sdmmc. > + > diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile > index 17ad0a7..9c91f1f 100644 > --- a/drivers/mmc/host/Makefile > +++ b/drivers/mmc/host/Makefile > @@ -45,6 +45,7 @@ obj-$(CONFIG_MMC_SH_MMCIF)+= sh_mmcif.o > obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o > obj-$(CONFIG_MMC_VUB300) += vub300.o > obj-$(CONFIG_MMC_USHC) += ushc.o > +obj-$(CONFIG_MMC_WMT) += wmt-sdmmc.o > > obj-$(CONFIG_MMC_SDHCI_PLTFM) += sdhci-pltfm.o > obj-$(CONFIG_MMC_SDHCI_CNS3XXX)+= sdhci-cns3xxx.o > diff --git a/drivers/mmc/host/wmt-sdmmc.c b/drivers/mmc/host/wmt-sdmmc.c > new file mode 100644 > index 000..def1ec9 > --- /dev/null > +++ b/drivers/mmc/host/wmt-sdmmc.c > @@ -0,0 +1,983 @@ > +/* > + * WM8505/WM8650 SD/MMC Host Controller > + * > + * Copyright (C) 2010 Tony Prisk > + * Copyright (C) 2008 WonderMedia Technologies, Inc. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +#include > + > + > +#define DRIVER_NAME "wmt-sdhc" > + > + > +/* MMC/SD controller registers */ > +#define SDMMC_CTLR 0x00 > +#define SDMMC_CMD 0x01 > +#define SDMMC_RSPTYPE 0x02 > +#define SDMMC_ARG 0x04 > +#define SDMMC_BUSMODE 0x08 > +#define SDMMC_BLKLEN 0x0C > +#define SDMMC_BLKCNT 0x0E > +#define SDMMC_RSP 0x10 > +#define SDMMC_CBCR 0x20 > +#define SDMMC_INTMASK0 0x24 > +#define SDMMC_INTMASK1 0x25 > +#define SDMMC_STS0 0x28 > +#define SDMMC_STS1 0x29 > +#define SDMMC_STS2 0x2A > +#define SDMMC_STS3 0x2B > +#define SDMMC_RSPTIMEOUT 0x2C > +#define SDMMC_CLK 0x30/* VT8500 only */ > +#define SDMMC_EXTCTRL 0x34 > +#define SDMMC_SBLKLEN 0x38 > +#define SDMMC_DMATIMEOUT 0x3C > + > + > +/* SDMMC_CTLR bit fields */ > +#define CTLR_CMD_START 0x01 > +#define CTLR_CMD_WRITE 0x04 > +#define CTLR_FIFO_RESET0x08 > + > +/* SDMMC_BUSMODE bit fields */ > +#define BM_SPI_MODE0x01 > +#define BM_FOURBIT_MODE0x02 > +#define BM_EIGHTBIT_MODE 0x04 > +#define BM_SD_OFF 0x10 > +#define BM_SPI_CS 0x20 > +#define BM_SD_POWER0x40 > +#define BM_SOFT_RESET 0x80 > +#define BM_ONEBIT_MASK 0xFD > + > +/* SDMMC_BLKLEN bit fields */ > +#define BLKL_CRCERR_ABORT 0x0800 > +#define BLKL_CD_POL_HIGH 0x1000 > +#define BLKL_GPI_CD0x2000 > +#define BLKL_DATA3_CD 0x4000 > +#define BLKL_INT_ENABLE0x8000 > + > +/* SDMMC_INTMASK0 bit fields */ > +#define INT0_MBLK_TRAN_DONE_INT_EN 0x10 > +#define INT0_BLK_TRAN_DONE_INT_EN 0x20 > +#define INT0_CD_INT_EN 0x40 > +#define INT0_DI_INT_EN 0x80 > + > +/* SDMMC_INTMASK1 bit fields */ > +#define INT1_CMD_RES_TRAN_DONE_INT_EN 0x02 > +#define INT1_CMD_RES_TOUT_INT_EN 0x04 > +#define INT1_MBLK_AUTO_STOP_INT_EN 0x08 > +#define INT1_DATA_TOUT_INT_EN 0x10 > +#define INT1_RESCRC_ERR_INT_EN 0
Re: [PATCH] mmc: dw_mmc: enable controller interrupt before calling mmc_start_host
On 8 October 2012 17:59, Yuvaraj CD wrote:
> As mmc_start_host is getting called before enabling the dw_mmc controller
> interrupt, there is a problem of missing the SDMMC_INT_CMD_DONE for the
> very first command sent by the sdio_reset.
> This problem occurs only when we disable MMC debugging i.e, MMC_DEBUG [=n].
> Hence this patch enables the dw_mmc controller interrupt before
> mmc_start_host.
>
> Signed-off-by: Yuvaraj CD
> ---
> drivers/mmc/host/dw_mmc.c | 29 +++--
> 1 file changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index a23af77..729c031 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -2233,6 +2233,21 @@ int dw_mci_probe(struct dw_mci *host)
> else
> host->num_slots = ((mci_readl(host, HCON) >> 1) & 0x1F) + 1;
>
> + /*
> +* Enable interrupts for command done, data over, data empty, card
> det,
> +* receive ready and error such as transmit, receive timeout, crc
> error
> +*/
> + mci_writel(host, RINTSTS, 0x);
> + mci_writel(host, INTMASK, SDMMC_INT_CMD_DONE | SDMMC_INT_DATA_OVER |
> + SDMMC_INT_TXDR | SDMMC_INT_RXDR |
> + DW_MCI_ERROR_FLAGS | SDMMC_INT_CD);
> + mci_writel(host, CTRL, SDMMC_CTRL_INT_ENABLE); /* Enable mci
> interrupt */
> +
> + dev_info(host->dev, "DW MMC controller at irq %d, "
> +"%d bit host data width, "
> +"%u deep fifo\n",
> +host->irq, width, fifo_size);
> +
Makes sense
Reviewed By: Girish K S
> /* We need at least one slot to succeed */
> for (i = 0; i < host->num_slots; i++) {
> ret = dw_mci_init_slot(host, i);
> @@ -2262,20 +2277,6 @@ int dw_mci_probe(struct dw_mci *host)
> else
> host->data_offset = DATA_240A_OFFSET;
>
> - /*
> -* Enable interrupts for command done, data over, data empty, card
> det,
> -* receive ready and error such as transmit, receive timeout, crc
> error
> -*/
> - mci_writel(host, RINTSTS, 0x);
> - mci_writel(host, INTMASK, SDMMC_INT_CMD_DONE | SDMMC_INT_DATA_OVER |
> - SDMMC_INT_TXDR | SDMMC_INT_RXDR |
> - DW_MCI_ERROR_FLAGS | SDMMC_INT_CD);
> - mci_writel(host, CTRL, SDMMC_CTRL_INT_ENABLE); /* Enable mci
> interrupt */
> -
> - dev_info(host->dev, "DW MMC controller at irq %d, "
> -"%d bit host data width, "
> -"%u deep fifo\n",
> -host->irq, width, fifo_size);
> if (host->quirks & DW_MCI_QUIRK_IDMAC_DTO)
> dev_info(host->dev, "Internal DMAC interrupt fix enabled.\n");
>
> --
> 1.7.9.5
>
--
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: Fixup broken suspend and eMMC4.5 power off notify
On 4 October 2012 20:46, Ulf Hansson wrote: > Hi Chris, > > On 3 October 2012 23:03, Chris Ball wrote: >> Hi Ulf, >> >> On Thu, Sep 13 2012, Ulf Hansson wrote: >>> From: Ulf Hansson >>> >>> This patch fixup the broken suspend sequence for eMMC >>> with sleep support. Additionally it reworks the eMMC4.5 >>> Power Off Notification feature so it fits together with >>> the existing sleep feature. >>> >>> The CMD0 based re-initialization of the eMMC at resume >>> is re-introduced to maintain compatiblity for devices >>> using sleep. >>> >>> A host shall use MMC_CAP2_POWEROFF_NOTIFY to enable the >>> Power Off Notification feature. We might be able to >>> remove this cap later on, if we think that Power Off >>> Notification always is preferred over sleep, even if the >>> host is not able to cut the eMMC VCCQ power. >>> >>> Signed-off-by: Ulf Hansson >>> Signed-off-by: Saugata Das >>> CC: Girish K S >>> CC: Asutosh Das >> >> I gave this patch a try on a board with an eMMC 4.41, but it didn't >> resolve the crash that I see. After applying the patch, I still see: >> >> [ 25.191917] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) >> done. >> [ 25.319299] mmc1: Got data interrupt 0x0002 even though no data >> operation was in progress. (Just a guess) for non-dt case just check in the machine fiile whether the correct platform device is passed. i mean for mmc0 channel devic0 and for mmc1 channel its device1. In my case i had duplicated device0 for both channels and had seen such log. >> [ 25.335054] PM: Device d4281000.sdhci failed to suspend: error -110 >> [ 25.341461] PM: Some devices failed to suspend >> >> and the suspend aborts. If I modify mmc_card_can_sleep() to always >> return false, the suspend completes without errors, so I know that >> something in the sleep code is responsible for my crash. > > This patch restores the sequence for how the sleep sequence is > executed, before the poweroff notify patches was merged at all. > So in principle I guess the problem for sdhci has been there for quite > a while, unless some patch in the sdhci driver has screwed something > up recently. > >> >> Any suggestions? Perhaps it's a different bug in the eMMC sleep code. > > Well, actually there is not so much that can be wrong in the sleep > code in the protocol layer. I believe we need to debug the sdhci > driver, to see what happens during the suspend operation instead. > > The sleep code from the protocol layer is requesting sdhci to run a > request (sleep cmd and "deselect" cmd). This request is not data > requests but cmd requests. Due to the prints from you log it indicates > that sdhci believes that there are an ongoing data request to handle. > This is not the case, so I think the sdhci has screwed up something. > > Although, I am not an sdhci expert, so just guessing. :-) > > Kind regards > Ulf Hansson -- 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: [PATCHv2] mmc: dw_mmc: use __devexit_p macro for .remove()
Reviewed By:- Girish K S
On 3 October 2012 22:45, Andy Shevchenko
wrote:
> Signed-off-by: Andy Shevchenko
> ---
> drivers/mmc/host/dw_mmc-pci.c |2 +-
> drivers/mmc/host/dw_mmc-pltfm.c |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc-pci.c b/drivers/mmc/host/dw_mmc-pci.c
> index edb37e9..53a09cb 100644
> --- a/drivers/mmc/host/dw_mmc-pci.c
> +++ b/drivers/mmc/host/dw_mmc-pci.c
> @@ -134,7 +134,7 @@ static struct pci_driver dw_mci_pci_driver = {
> .name = "dw_mmc_pci",
> .id_table = dw_mci_pci_id,
> .probe = dw_mci_pci_probe,
> - .remove = dw_mci_pci_remove,
> + .remove = __devexit_p(dw_mci_pci_remove),
> .driver = {
> .pm = &dw_mci_pci_pmops
> },
> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
> index c960ca7..777c585 100644
> --- a/drivers/mmc/host/dw_mmc-pltfm.c
> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
> @@ -119,7 +119,7 @@ static const struct of_device_id dw_mci_pltfm_match[] = {
> MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
>
> static struct platform_driver dw_mci_pltfm_driver = {
> - .remove = __exit_p(dw_mci_pltfm_remove),
> + .remove = __devexit_p(dw_mci_pltfm_remove),
> .driver = {
> .name = "dw_mmc",
> .of_match_table = of_match_ptr(dw_mci_pltfm_match),
> --
> 1.7.10.4
>
--
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: dw_mmc: use helper macro module_platform_driver()
Reviewd By:Girish K S
On 3 October 2012 22:26, Andy Shevchenko
wrote:
> Since v3.2 we have nice macro to define the platform driver's init and exit
> calls. This patch simplifies the dw_mmc platform driver by using that macro.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/mmc/host/dw_mmc-pltfm.c | 14 ++
> 1 file changed, 2 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
> index 777c585..779335b 100644
> --- a/drivers/mmc/host/dw_mmc-pltfm.c
> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
> @@ -119,6 +119,7 @@ static const struct of_device_id dw_mci_pltfm_match[] = {
> MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
>
> static struct platform_driver dw_mci_pltfm_driver = {
> + .probe = dw_mci_pltfm_probe,
> .remove = __devexit_p(dw_mci_pltfm_remove),
> .driver = {
> .name = "dw_mmc",
> @@ -127,18 +128,7 @@ static struct platform_driver dw_mci_pltfm_driver = {
> },
> };
>
> -static int __init dw_mci_init(void)
> -{
> - return platform_driver_probe(&dw_mci_pltfm_driver,
> dw_mci_pltfm_probe);
> -}
> -
> -static void __exit dw_mci_exit(void)
> -{
> - platform_driver_unregister(&dw_mci_pltfm_driver);
> -}
> -
> -module_init(dw_mci_init);
> -module_exit(dw_mci_exit);
> +module_platform_driver(dw_mci_pltfm_driver);
>
> MODULE_DESCRIPTION("DW Multimedia Card Interface driver");
> MODULE_AUTHOR("NXP Semiconductor VietNam");
> --
> 1.7.10.4
>
> --
> 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 1/2] mmc: dw_mmc: use __devinit_p macro for .remove()
its __devexit_p not __devinit_p
On 3 October 2012 22:26, Andy Shevchenko
wrote:
> Signed-off-by: Andy Shevchenko
> ---
> drivers/mmc/host/dw_mmc-pci.c |2 +-
> drivers/mmc/host/dw_mmc-pltfm.c |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc-pci.c b/drivers/mmc/host/dw_mmc-pci.c
> index edb37e9..53a09cb 100644
> --- a/drivers/mmc/host/dw_mmc-pci.c
> +++ b/drivers/mmc/host/dw_mmc-pci.c
> @@ -134,7 +134,7 @@ static struct pci_driver dw_mci_pci_driver = {
> .name = "dw_mmc_pci",
> .id_table = dw_mci_pci_id,
> .probe = dw_mci_pci_probe,
> - .remove = dw_mci_pci_remove,
> + .remove = __devexit_p(dw_mci_pci_remove),
> .driver = {
> .pm = &dw_mci_pci_pmops
> },
> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
> index c960ca7..777c585 100644
> --- a/drivers/mmc/host/dw_mmc-pltfm.c
> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
> @@ -119,7 +119,7 @@ static const struct of_device_id dw_mci_pltfm_match[] = {
> MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
>
> static struct platform_driver dw_mci_pltfm_driver = {
> - .remove = __exit_p(dw_mci_pltfm_remove),
> + .remove = __devexit_p(dw_mci_pltfm_remove),
> .driver = {
> .name = "dw_mmc",
> .of_match_table = of_match_ptr(dw_mci_pltfm_match),
> --
> 1.7.10.4
>
> --
> 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] mmc: Fixup broken suspend and eMMC4.5 power off notify
On 30 September 2012 16:07, Girish K S wrote: > On 30 September 2012 15:48, Tanya Brokhman wrote: >> Hi Ulf, >> >>> >>> Hi Tanya, >>> >>> Thanks a lot for helping out!!! >> >> NP. >>> >>> Testing suspend to ram, and then resuming back again is the key use case >> to >>> test. >> >> >> Is there a special scenario to trigger suspend or just leaving the system >> idle? I did that. Added prints in the code to verify that the PON was sent >> to the card It feels a bit superficial to me that's why I'm asking if >> there is a specific scenario I can try. >> Other than that, as I already mentioned we ran our test suit that includes >> various user-use cases such as playing a game, reading a web page, email >> etc. And of course I tried lmdd both ways. > from command prompt you can suspend by forcing the string mem to state > variable as given below > echo mem > sys/power/state > If sysfs is not mounted mount it(mount -t sysfs sys /sys) before > running the above command. > > If your board is configured for an external interrupt as a wakeup > source (on my board it is the keypad) > press the key for resume. > > If no External interrupt wakeup source is availabe, and if the SOc has > a RTC, it can be used for resume purpose as below > > echo 0 > /sys/class/rtc/rtcN/wakealarm (reset old value) > echo 10 > /sys/class/rtc/rtcN/wakealarm (set new value) > > After the specified above seconds the system will resume If you are using rtc as wakeup source. first configure rtc and then run echo mem > sys/power/state > >> >>> >>> Kind regards >>> Ulf Hansson >>> >> >> >> Thanks, >> Tanya Brokhman >> --- >> QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member >> of Code Aurora Forum, hosted by The Linux Foundation >> >> -- 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: Fixup broken suspend and eMMC4.5 power off notify
On 30 September 2012 15:48, Tanya Brokhman wrote: > Hi Ulf, > >> >> Hi Tanya, >> >> Thanks a lot for helping out!!! > > NP. >> >> Testing suspend to ram, and then resuming back again is the key use case > to >> test. > > > Is there a special scenario to trigger suspend or just leaving the system > idle? I did that. Added prints in the code to verify that the PON was sent > to the card It feels a bit superficial to me that's why I'm asking if > there is a specific scenario I can try. > Other than that, as I already mentioned we ran our test suit that includes > various user-use cases such as playing a game, reading a web page, email > etc. And of course I tried lmdd both ways. from command prompt you can suspend by forcing the string mem to state variable as given below echo mem > sys/power/state If sysfs is not mounted mount it(mount -t sysfs sys /sys) before running the above command. If your board is configured for an external interrupt as a wakeup source (on my board it is the keypad) press the key for resume. If no External interrupt wakeup source is availabe, and if the SOc has a RTC, it can be used for resume purpose as below echo 0 > /sys/class/rtc/rtcN/wakealarm (reset old value) echo 10 > /sys/class/rtc/rtcN/wakealarm (set new value) After the specified above seconds the system will resume > >> >> Kind regards >> Ulf Hansson >> > > > Thanks, > Tanya Brokhman > --- > QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation > > -- 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 14/15] mmc: sdhci: fix the bug that DDR50 can't work for emmc
On 27 September 2012 00:04, Kevin Liu wrote:
> 2012/9/26 Girish K S :
>> On 26 September 2012 20:38, Kevin Liu wrote:
>>> From: Kevin Liu
>>>
>>> Host controller must enable 1.8v signal for UHS modes.
>>> Otherwise UHS modes won't take effect.
>>> But mmc core does NOT switch to 1.8v for DDR50 mode.
>>> So enable the 1.8v signal for mmc DDR50 mode in host
>>> driver.
>>>
>>> Signed-off-by: Kevin Liu
>>> ---
>>> drivers/mmc/host/sdhci.c |9 -
>>> 1 files changed, 8 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> index 50e7a54..e3de041 100644
>>> --- a/drivers/mmc/host/sdhci.c
>>> +++ b/drivers/mmc/host/sdhci.c
>>> @@ -1529,8 +1529,15 @@ static void sdhci_do_set_ios(struct sdhci_host
>>> *host, struct mmc_ios *ios)
>>> ctrl_2 |= SDHCI_CTRL_UHS_SDR50;
>>> else if (ios->timing == MMC_TIMING_UHS_SDR104)
>>> ctrl_2 |= SDHCI_CTRL_UHS_SDR104;
>>> - else if (ios->timing == MMC_TIMING_UHS_DDR50)
>>> + else if (ios->timing == MMC_TIMING_UHS_DDR50) {
>>> + struct mmc_card *card;
>>> +
>>> ctrl_2 |= SDHCI_CTRL_UHS_DDR50;
>>> + card = container_of(&(host->mmc),
>>> + struct mmc_card, host);
>>> + if (mmc_card_mmc(card))
>>> + ctrl_2 |= SDHCI_CTRL_VDD_180;
>>> + }
>> If you want to set the voltage to 1.8. It has to be done from the core
>> layer using the api mmc_set_signal_voltage during the mmc card init.
>> as it is done for 1.2 volts switch. In the comment (mmc_card_init
>> function) it is explicitly mentioned
>> * 1.8V vccq at 3.3V core voltage (vcc) is not required
>> * in the JEDEC spec for DDR.
>> can you please check it. Still if you feel its necessary to change the
>> voltage to 1.8 v, you can do it from mmc_init_card function
>
> In JEDEC spec, there are two emmc device types which support DDR50.
> One type can work under signal 1.2v while the other type work under
> signal 1.8v or 3v. So current code just keep 3v for the second device
> type.
>
> But in SD host spec, 1.8v signal must be enabled for all UHS modes
> taking effect.
> So the fact is, if we use SD host to work with emmc chip, we have to
> select 1.8v in order to enable DDR50. Current code missed this.
>
> Because DDR50 shall can work under both signal 1.8v and 3v according
> to JEDEC spec, So I don't want to switch to 1.8v in mmc core code.
> It's the host controller requirement that 1.8v signal must be enabled
> in order to enable DDR50, which conflict with emmc spec. So I added
> this in host driver.
I understand. Thanks
>
> Thanks
> Kevin
--
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 v5] powerpc/esdhc: disable CMD23 for some Freescale SoCs
Looks good
Reviewed By:- Girish K S
On 26 September 2012 15:02, wrote:
> From: Jerry Huang
>
> CMD23 causes lots of errors in kernel on some freescale SoCs
> (P1020, P1021, P1022, P1024, P1025 and P4080) when MMC card used,
> which is because these controllers does not support CMD23,
> even on the SoCs which declares CMD23 is supported.
> Therefore, we'll not use CMD23.
>
> Signed-off-by: Jerry Huang
> Signed-off-by: Shaohui Xie
> CC: Anton Vorontsov
> CC: Chris Ball
> ---
> changes for v5:
> - change the error to warning information
> changes for v4:
> - change to detect the IP version
> - don't use callback function
> changes for v3:
> - move the limitation detect function to eSDHC file
> - add the callback funtion to do this limitation detect
> changes for v2:
> - discard the property mode and add the processor detection
>
> drivers/mmc/host/sdhci-of-esdhc.c | 33 +
> drivers/mmc/host/sdhci-pltfm.c|4 +++-
> drivers/mmc/host/sdhci-pltfm.h|1 +
> drivers/mmc/host/sdhci.c |3 +++
> include/linux/mmc/sdhci.h |1 +
> 5 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
> b/drivers/mmc/host/sdhci-of-esdhc.c
> index ae5fcbf..ffc1226 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -169,6 +169,38 @@ static void esdhc_of_resume(struct sdhci_host *host)
> }
> #endif
>
> +static void esdhc_of_detect_limitation(struct platform_device *pdev,
> + struct sdhci_pltfm_data *pdata)
> +{
> + void __iomem *ioaddr;
> + struct resource *iomem;
> + u32 vvn;
> +
> + iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!iomem) {
> + dev_warn(&pdev->dev, "failed to get resource\n");
> + goto end;
> + }
> + if (resource_size(iomem) < 0x100)
> + dev_warn(&pdev->dev, "Invalid iomem size!\n");
> +
> + ioaddr = ioremap(iomem->start, resource_size(iomem));
> + if (!ioaddr) {
> + dev_warn(&pdev->dev, "failed to remap registers\n");
> + goto end;
> + }
> +
> + /* P102x and P4080 has IP version VVN2.2, CMD23 is not supported */
> + vvn = in_be32(ioaddr + SDHCI_SLOT_INT_STATUS);
> + vvn = (vvn & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT;
> + if (vvn == VENDOR_V_22)
> + pdata->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
> +
> + iounmap(ioaddr);
> +end:
> + return;
> +}
> +
> static struct sdhci_ops sdhci_esdhc_ops = {
> .read_l = esdhc_readl,
> .read_w = esdhc_readw,
> @@ -199,6 +231,7 @@ static struct sdhci_pltfm_data sdhci_esdhc_pdata = {
>
> static int __devinit sdhci_esdhc_probe(struct platform_device *pdev)
> {
> + esdhc_of_detect_limitation(pdev, &sdhci_esdhc_pdata);
> return sdhci_pltfm_register(pdev, &sdhci_esdhc_pdata);
> }
>
> diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
> index 65551a9..4dd5770 100644
> --- a/drivers/mmc/host/sdhci-pltfm.c
> +++ b/drivers/mmc/host/sdhci-pltfm.c
> @@ -132,8 +132,10 @@ struct sdhci_host *sdhci_pltfm_init(struct
> platform_device *pdev,
> host->ops = pdata->ops;
> else
> host->ops = &sdhci_pltfm_ops;
> - if (pdata)
> + if (pdata) {
> host->quirks = pdata->quirks;
> + host->quirks2 = pdata->quirks2;
> + }
> host->irq = platform_get_irq(pdev, 0);
>
> if (!request_mem_region(iomem->start, resource_size(iomem),
> diff --git a/drivers/mmc/host/sdhci-pltfm.h b/drivers/mmc/host/sdhci-pltfm.h
> index 37e0e18..283d54a 100644
> --- a/drivers/mmc/host/sdhci-pltfm.h
> +++ b/drivers/mmc/host/sdhci-pltfm.h
> @@ -18,6 +18,7 @@
> struct sdhci_pltfm_data {
> struct sdhci_ops *ops;
> unsigned int quirks;
> + unsigned int quirks2;
> };
>
> struct sdhci_pltfm_host {
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 0e15c79..b0b7cad 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2837,6 +2837,9 @@ int sdhci_add_host(struct sdhci_host *host)
> if (!(host->quirks & SDHCI_QUIRK_FORCE_1_BIT_DATA))
> mmc->caps |= MMC_CAP_4_BIT_DATA;
>
> + if (host->quirks2 & SDHCI_QUIRK2_HOST_NO_CMD23)
> + mmc->
Re: [PATCH v4 07/15] mmc: host: adjust uhs timing value
Reviewed By: Girish K S
On 26 September 2012 20:38, Kevin Liu wrote:
> From: Kevin Liu
>
> Both of MMC_TIMING_LEGACY and MMC_TIMING_UHS_SDR12 are defined
> to 0. And ios->timing is set to MMC_TIMING_LEGACY during power up.
> But set_ios can't distinguish these two timing if host support
> spec 3.0. Just adjust timing values to be different can resolve
> this issue without any other impact.
>
> Acked-by: Ulf Hansson
> Signed-off-by: Kevin Liu
> ---
> include/linux/mmc/host.h | 12 ++--
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index d5d9bd4..036a5cc 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -53,12 +53,12 @@ struct mmc_ios {
> #define MMC_TIMING_LEGACY 0
> #define MMC_TIMING_MMC_HS 1
> #define MMC_TIMING_SD_HS 2
> -#define MMC_TIMING_UHS_SDR12 MMC_TIMING_LEGACY
> -#define MMC_TIMING_UHS_SDR25 MMC_TIMING_SD_HS
> -#define MMC_TIMING_UHS_SDR50 3
> -#define MMC_TIMING_UHS_SDR104 4
> -#define MMC_TIMING_UHS_DDR50 5
> -#define MMC_TIMING_MMC_HS200 6
> +#define MMC_TIMING_UHS_SDR12 3
> +#define MMC_TIMING_UHS_SDR25 4
> +#define MMC_TIMING_UHS_SDR50 5
> +#define MMC_TIMING_UHS_SDR104 6
> +#define MMC_TIMING_UHS_DDR50 7
> +#define MMC_TIMING_MMC_HS200 8
>
> #define MMC_SDR_MODE 0
> #define MMC_1_2V_DDR_MODE 1
> --
> 1.7.0.4
>
> --
> 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 v4 14/15] mmc: sdhci: fix the bug that DDR50 can't work for emmc
On 26 September 2012 20:38, Kevin Liu wrote:
> From: Kevin Liu
>
> Host controller must enable 1.8v signal for UHS modes.
> Otherwise UHS modes won't take effect.
> But mmc core does NOT switch to 1.8v for DDR50 mode.
> So enable the 1.8v signal for mmc DDR50 mode in host
> driver.
>
> Signed-off-by: Kevin Liu
> ---
> drivers/mmc/host/sdhci.c |9 -
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 50e7a54..e3de041 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1529,8 +1529,15 @@ static void sdhci_do_set_ios(struct sdhci_host *host,
> struct mmc_ios *ios)
> ctrl_2 |= SDHCI_CTRL_UHS_SDR50;
> else if (ios->timing == MMC_TIMING_UHS_SDR104)
> ctrl_2 |= SDHCI_CTRL_UHS_SDR104;
> - else if (ios->timing == MMC_TIMING_UHS_DDR50)
> + else if (ios->timing == MMC_TIMING_UHS_DDR50) {
> + struct mmc_card *card;
> +
> ctrl_2 |= SDHCI_CTRL_UHS_DDR50;
> + card = container_of(&(host->mmc),
> + struct mmc_card, host);
> + if (mmc_card_mmc(card))
> + ctrl_2 |= SDHCI_CTRL_VDD_180;
> + }
If you want to set the voltage to 1.8. It has to be done from the core
layer using the api mmc_set_signal_voltage during the mmc card init.
as it is done for 1.2 volts switch. In the comment (mmc_card_init
function) it is explicitly mentioned
* 1.8V vccq at 3.3V core voltage (vcc) is not required
* in the JEDEC spec for DDR.
can you please check it. Still if you feel its necessary to change the
voltage to 1.8 v, you can do it from mmc_init_card function
> sdhci_writew(host, ctrl_2, SDHCI_HOST_CONTROL2);
> }
> if (!(host->quirks2 & SDHCI_QUIRK2_PRESET_VALUE_BROKEN) &&
> --
> 1.7.0.4
>
> --
> 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 v4 01/15] mmc: sdhci: fix transfer mode setting bug for cmds w/o data transfer
Reviewed By: Girish K S
On 26 September 2012 20:38, Kevin Liu wrote:
> From: Kevin Liu
>
> Commands without data transfer like cmd5/cmd7 will use previous
> transfer mode setting, which may lead to error since some bits
> may have been set unexpectedly.
> For example, cmd5 following cmd18/cmd25 will have timeout error
> since audo cmd23 has been enabled.
>
> Signed-off-by: Jialing Fu
> Signed-off-by: Tim Wang
> Signed-off-by: Kevin Liu
> ---
> drivers/mmc/host/sdhci.c | 22 ++
> 1 files changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 0e15c79..9be6a8c 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -886,8 +886,21 @@ static void sdhci_set_transfer_mode(struct sdhci_host
> *host,
> u16 mode;
> struct mmc_data *data = cmd->data;
>
> - if (data == NULL)
> + if (!data) {
> + if (cmd->opcode == MMC_SEND_TUNING_BLOCK ||
> + cmd->opcode == MMC_SEND_TUNING_BLOCK_HS200)
> + /*
> +* The tuning block is sent by the card to the host
> +* controller. So we set the TRNS_READ bit in the
> +* Transfer Mode register. This also takes care of
> +* setting DMA Enable and Multi Block Select in the
> +* same register to 0.
> +*/
> + sdhci_writew(host, SDHCI_TRNS_READ,
> SDHCI_TRANSFER_MODE);
> + else
> + sdhci_writew(host, 0, SDHCI_TRANSFER_MODE);
> return;
> + }
>
> WARN_ON(!host->data);
>
> @@ -1850,13 +1863,6 @@ static int sdhci_execute_tuning(struct mmc_host *mmc,
> u32 opcode)
> SDHCI_BLOCK_SIZE);
> }
>
> - /*
> -* The tuning block is sent by the card to the host
> controller.
> -* So we set the TRNS_READ bit in the Transfer Mode register.
> -* This also takes care of setting DMA Enable and Multi Block
> -* Select in the same register to 0.
> -*/
> - sdhci_writew(host, SDHCI_TRNS_READ, SDHCI_TRANSFER_MODE);
>
> sdhci_send_command(host, &cmd);
>
> --
> 1.7.0.4
>
> --
> 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 v3 02/11] mmc: sdhci: set regulator min/max voltage according to spec
On 25 September 2012 19:38, Kevin Liu wrote:
> From: Kevin Liu
>
> Use voltage range as below rather than a specific value
> 3.3v: (3.2v, 3.4v)
> 3.0v: (2.9v, 3.1v)
> 1.8v: (1.65v, 1.95v)
Any specific reason to give range and not specific value?
>
> Signed-off-by: Jialing Fu
> Signed-off-by: Kevin Liu
> ---
> drivers/mmc/host/sdhci.c | 18 +-
> 1 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 2f844e5..f50efa6 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1628,7 +1628,7 @@ static int sdhci_do_3_3v_signal_voltage_switch(struct
> sdhci_host *host,
> sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
>
> if (host->vqmmc) {
> - ret = regulator_set_voltage(host->vqmmc, 330, 330);
> + ret = regulator_set_voltage(host->vqmmc, 320, 340);
> if (ret) {
> pr_warning("%s: Switching to 3.3V signalling voltage "
>" failed\n", mmc_hostname(host->mmc));
> @@ -1672,7 +1672,7 @@ static int sdhci_do_1_8v_signal_voltage_switch(struct
> sdhci_host *host,
> */
> if (host->vqmmc)
> ret = regulator_set_voltage(host->vqmmc,
> - 180, 180);
> + 165, 195);
> else
> ret = 0;
>
> @@ -2856,7 +2856,7 @@ int sdhci_add_host(struct sdhci_host *host)
> pr_info("%s: no vqmmc regulator found\n", mmc_hostname(mmc));
> host->vqmmc = NULL;
> }
> - else if (regulator_is_supported_voltage(host->vqmmc, 180,
> 180))
> + else if (regulator_is_supported_voltage(host->vqmmc, 165,
> 195))
> regulator_enable(host->vqmmc);
> else
> caps[1] &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
> @@ -2927,16 +2927,16 @@ int sdhci_add_host(struct sdhci_host *host)
>
> #ifdef CONFIG_REGULATOR
> if (host->vmmc) {
> - ret = regulator_is_supported_voltage(host->vmmc, 330,
> - 330);
> + ret = regulator_is_supported_voltage(host->vmmc, 320,
> + 340);
> if ((ret <= 0) || (!(caps[0] & SDHCI_CAN_VDD_330)))
> caps[0] &= ~SDHCI_CAN_VDD_330;
> - ret = regulator_is_supported_voltage(host->vmmc, 300,
> - 300);
> + ret = regulator_is_supported_voltage(host->vmmc, 290,
> + 310);
> if ((ret <= 0) || (!(caps[0] & SDHCI_CAN_VDD_300)))
> caps[0] &= ~SDHCI_CAN_VDD_300;
> - ret = regulator_is_supported_voltage(host->vmmc, 180,
> - 180);
> + ret = regulator_is_supported_voltage(host->vmmc, 165,
> + 195);
> if ((ret <= 0) || (!(caps[0] & SDHCI_CAN_VDD_180)))
> caps[0] &= ~SDHCI_CAN_VDD_180;
> }
> --
> 1.7.0.4
>
> --
> 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 v3 01/11] mmc: sdhci: fix transfer mode setting bug for cmds w/o data transfer
On 25 September 2012 19:38, Kevin Liu wrote:
> From: Kevin Liu
>
> Commands without data transfer like cmd5/cmd7 will use previous
> transfer mode setting, which may lead to error since some bits
> may have been set unexpectedly.
> For example, cmd5 following cmd18/cmd25 will have timeout error
> since audo cmd23 has been enabled.
>
> Signed-off-by: Jialing Fu
> Signed-off-by: Tim Wang
> Signed-off-by: Kevin Liu
> ---
> drivers/mmc/host/sdhci.c | 22 ++
> 1 files changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 0e15c79..2f844e5 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -886,8 +886,21 @@ static void sdhci_set_transfer_mode(struct sdhci_host
> *host,
> u16 mode;
> struct mmc_data *data = cmd->data;
>
> - if (data == NULL)
> + if (data == NULL) {
Even though its kept as it is in the prev code. avoid explicit check
for NULL. can use !data which is commonly used
> + if (cmd->opcode == MMC_SEND_TUNING_BLOCK ||
> + cmd->opcode == MMC_SEND_TUNING_BLOCK_HS200)
> + /*
> +* The tuning block is sent by the card to the host
> +* controller. So we set the TRNS_READ bit in the
> +* Transfer Mode register. This also takes care of
> +* setting DMA Enable and Multi Block Select in the
> +* same register to 0.
> +*/
> + sdhci_writew(host, SDHCI_TRNS_READ,
> SDHCI_TRANSFER_MODE);
> + else
> + sdhci_writew(host, 0, SDHCI_TRANSFER_MODE);
> return;
> + }
>
> WARN_ON(!host->data);
>
> @@ -1850,13 +1863,6 @@ static int sdhci_execute_tuning(struct mmc_host *mmc,
> u32 opcode)
> SDHCI_BLOCK_SIZE);
> }
>
> - /*
> -* The tuning block is sent by the card to the host
> controller.
> -* So we set the TRNS_READ bit in the Transfer Mode register.
> -* This also takes care of setting DMA Enable and Multi Block
> -* Select in the same register to 0.
> -*/
> - sdhci_writew(host, SDHCI_TRNS_READ, SDHCI_TRANSFER_MODE);
>
> sdhci_send_command(host, &cmd);
>
> --
> 1.7.0.4
>
> --
> 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 v4] powerpc/esdhc: disable CMD23 for some Freescale SoCs
On 25 September 2012 18:00, wrote:
> From: Jerry Huang
>
> CMD23 causes lots of errors in kernel on some freescale SoCs
> (P1020, P1021, P1022, P1024, P1025 and P4080) when MMC card used,
> which is because these controllers does not support CMD23,
> even on the SoCs which declares CMD23 is supported.
> Therefore, we'll not use CMD23.
>
> Signed-off-by: Jerry Huang
> Signed-off-by: Shaohui Xie
> CC: Anton Vorontsov
> CC: Chris Ball
> ---
> changes for v4:
> - change to detect the IP version
> - don't use callback function
> changes for v3:
> - move the limitation detect function to eSDHC file
> - add the callback funtion to do this limitation detect
> changes for v2:
> - discard the property mode and add the processor detection
>
> drivers/mmc/host/sdhci-of-esdhc.c | 33 +
> drivers/mmc/host/sdhci-pltfm.c|4 +++-
> drivers/mmc/host/sdhci-pltfm.h|1 +
> drivers/mmc/host/sdhci.c |3 +++
> include/linux/mmc/sdhci.h |1 +
> 5 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
> b/drivers/mmc/host/sdhci-of-esdhc.c
> index ae5fcbf..231672b 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -169,6 +169,38 @@ static void esdhc_of_resume(struct sdhci_host *host)
> }
> #endif
>
> +static void esdhc_of_detect_limitation(struct platform_device *pdev,
> + struct sdhci_pltfm_data *pdata)
> +{
> + void __iomem *ioaddr;
> + struct resource *iomem;
> + u32 vvn;
> +
> + iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!iomem) {
> + dev_err(&pdev->dev, "failed to get resource\n");
> + goto err;
> + }
> + if (resource_size(iomem) < 0x100)
> + dev_err(&pdev->dev, "Invalid iomem size!\n");
> +
> + ioaddr = ioremap(iomem->start, resource_size(iomem));
> + if (!ioaddr) {
> + dev_err(&pdev->dev, "failed to remap registers\n");
> + goto err;
> + }
> +
> + /* P102x and P4080 has IP version VVN2.2, CMD23 is not supported */
> + vvn = in_be32(ioaddr + SDHCI_SLOT_INT_STATUS);
> + vvn = (vvn & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT;
> + if (vvn == VENDOR_V_22)
> + pdata->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
> +
> + iounmap(ioaddr);
> +err:
> + return;
return a err value so that it is checked when called. If err then dont
have to proceed further.
> +}
> +
> static struct sdhci_ops sdhci_esdhc_ops = {
> .read_l = esdhc_readl,
> .read_w = esdhc_readw,
> @@ -199,6 +231,7 @@ static struct sdhci_pltfm_data sdhci_esdhc_pdata = {
>
> static int __devinit sdhci_esdhc_probe(struct platform_device *pdev)
> {
> + esdhc_of_detect_limitation(pdev, &sdhci_esdhc_pdata);
In the above function there is a err value returned. Do you have to
proceed further even though there is a error?
> return sdhci_pltfm_register(pdev, &sdhci_esdhc_pdata);
> }
>
> diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
> index 65551a9..4dd5770 100644
> --- a/drivers/mmc/host/sdhci-pltfm.c
> +++ b/drivers/mmc/host/sdhci-pltfm.c
> @@ -132,8 +132,10 @@ struct sdhci_host *sdhci_pltfm_init(struct
> platform_device *pdev,
> host->ops = pdata->ops;
> else
> host->ops = &sdhci_pltfm_ops;
> - if (pdata)
> + if (pdata) {
> host->quirks = pdata->quirks;
> + host->quirks2 = pdata->quirks2;
> + }
> host->irq = platform_get_irq(pdev, 0);
>
> if (!request_mem_region(iomem->start, resource_size(iomem),
> diff --git a/drivers/mmc/host/sdhci-pltfm.h b/drivers/mmc/host/sdhci-pltfm.h
> index 37e0e18..283d54a 100644
> --- a/drivers/mmc/host/sdhci-pltfm.h
> +++ b/drivers/mmc/host/sdhci-pltfm.h
> @@ -18,6 +18,7 @@
> struct sdhci_pltfm_data {
> struct sdhci_ops *ops;
> unsigned int quirks;
> + unsigned int quirks2;
> };
>
> struct sdhci_pltfm_host {
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 0e15c79..b0b7cad 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2837,6 +2837,9 @@ int sdhci_add_host(struct sdhci_host *host)
> if (!(host->quirks & SDHCI_QUIRK_FORCE_1_BIT_DATA))
> mmc->caps |= MMC_CAP_4_BIT_DATA;
>
> + if (host->quirks2 & SDHCI_QUIRK2_HOST_NO_CMD23)
> + mmc->caps &= ~MMC_CAP_CMD23;
> +
> if (caps[0] & SDHCI_CAN_DO_HISPD)
> mmc->caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED;
>
> diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
> index fa8529a..1edcb4d 100644
> --- a/include/linux/mmc/sdhci.h
> +++ b/include/linux/mmc/sdhci.h
> @@ -91,6 +91,7 @@ struct sdhci_host {
> unsigned int quirks2; /* More deviations from spec. */
>
Re: [PATCH v3] powerpc/esdhc: disable CMD23 for some Freescale SoCs
On 21 September 2012 15:55, wrote:
> From: Jerry Huang
>
> CMD23 causes lots of errors in kernel on some freescale SoCs
> (P1020, P1021, P1022, P1024, P1025 and P4080) when MMC card used,
> which is because these controllers does not support CMD23,
> even on the SoCs which declares CMD23 is supported.
> Therefore, we'll not use CMD23.
>
> Signed-off-by: Jerry Huang
> Signed-off-by: Shaohui Xie
> CC: Anton Vorontsov
> CC: Chris Ball
> ---
> changes for v3:
> - move the limitation detect function to eSDHC file
> - add the callback funtion to do this limitation detect
> changes for v2:
> - discard the property mode and add the processor detection
>
> drivers/mmc/host/sdhci-of-esdhc.c | 30 ++
> drivers/mmc/host/sdhci-pltfm.c|3 +++
> drivers/mmc/host/sdhci.c |3 +++
> drivers/mmc/host/sdhci.h |1 +
> include/linux/mmc/sdhci.h |1 +
> 5 files changed, 38 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
> b/drivers/mmc/host/sdhci-of-esdhc.c
> index f8eb1fb..2f40a7f 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -143,6 +143,35 @@ static void esdhc_of_resume(struct sdhci_host *host)
> }
> #endif
>
> +static const u32 non_cmd23_processor_table[] = {
> + /* P1020 Dual/Single core */
> + 0x80EC00, 0x80E400, 0x80ED00, 0x80E500,
> + /* P1021 Dual/Single core */
> + 0x80EC01, 0x80E401, 0x80ED01, 0x80E501,
> + /* P1022 Dual/Single core */
> + 0x80EE00, 0x80E600, 0x80EF00, 0x80E700,
> + /* P1024 Dual/Single core */
> + 0x80EC02, 0x80E402, 0x80ED02, 0x80E502,
> + /* P1025 Dual/Single core */
> + 0x80EC03, 0x80E403, 0x80ED03, 0x80E503,
> + /* P4080 and P4040 */
> + 0x82, 0x820800, 0x820100, 0x820900
> +};
> +
> +void esdhc_of_detect_limitation(struct sdhci_host *host)
> +{
> + u32 svr = mfspr(SPRN_SVR) >> 8;
> + u32 table_size = ARRAY_SIZE(non_cmd23_processor_table);
> + int i;
> +
> + for (i = 0; i < table_size; i++) {
> + if (non_cmd23_processor_table[i] == svr) {
> + host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
> + break;
> + }
> + }
> +}
> +
> static struct sdhci_ops sdhci_esdhc_ops = {
> .read_l = sdhci_be32bs_readl,
> .read_w = esdhc_readw,
> @@ -158,6 +187,7 @@ static struct sdhci_ops sdhci_esdhc_ops = {
> .platform_suspend = esdhc_of_suspend,
> .platform_resume = esdhc_of_resume,
> #endif
> + .platform_limitation = esdhc_of_detect_limitation,
> };
>
> static struct sdhci_pltfm_data sdhci_esdhc_pdata = {
> diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
> index d9a4ef4..864bedd 100644
> --- a/drivers/mmc/host/sdhci-pltfm.c
> +++ b/drivers/mmc/host/sdhci-pltfm.c
> @@ -185,6 +185,9 @@ int sdhci_pltfm_register(struct platform_device *pdev,
>
> sdhci_get_of_property(pdev);
>
> + if (host->ops->platform_limitation)
> + host->ops->platform_limitation(host);
> +
In your Soc specific sdhci-.c probe function you need to call
sdhci_pltfm_register function. And before calling this function you
can check for the above inserted code.
this will keep the sdhci-pltfm.c unchanged and also avoids the
additional callback in the generic header file
> ret = sdhci_add_host(host);
> if (ret)
> sdhci_pltfm_free(pdev);
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 9a11dc3..6208a8b 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2795,6 +2795,9 @@ int sdhci_add_host(struct sdhci_host *host)
> if (!(host->quirks & SDHCI_QUIRK_FORCE_1_BIT_DATA))
> mmc->caps |= MMC_CAP_4_BIT_DATA;
>
> + if (host->quirks2 & SDHCI_QUIRK2_HOST_NO_CMD23)
> + mmc->caps &= ~MMC_CAP_CMD23;
> +
> if (caps[0] & SDHCI_CAN_DO_HISPD)
> mmc->caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED;
>
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 97653ea..4296bef 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -278,6 +278,7 @@ struct sdhci_ops {
> void(*hw_reset)(struct sdhci_host *host);
> void(*platform_suspend)(struct sdhci_host *host);
> void(*platform_resume)(struct sdhci_host *host);
> + void(*platform_limitation)(struct sdhci_host *host);
> };
>
> #ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
> diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
> index ac83b10..97c73f5 100644
> --- a/include/linux/mmc/sdhci.h
> +++ b/include/linux/mmc/sdhci.h
> @@ -91,6 +91,7 @@ struct sdhci_host {
> unsigned int quirks2; /* More deviations from spec. */
>
> #define SDHCI_QUIRK2_HOST_OFF_CARD_ON (1<<0)
> +#define SDHCI_QUIRK2_HOST_NO_CMD23
Re: [PATCH v2] powerpc/esdhc: disable CMD23 for some Freescale SoCs
On 21 September 2012 14:38, wrote:
> From: Jerry Huang
>
> CMD23 causes lots of errors in kernel on some freescale SoCs
> (P1020, P1021, P1022, P1024, P1025 and P4080)
> when mmc card used, which is because these controllers does
> not support CMD23, but even on SoCs which declare CMD23 is supported,
> so we'll not use CMD23.
>
> Signed-off-by: Jerry Huang
> Signed-off-by: Shaohui Xie
> CC: Anton Vorontsov
> ---
> changes for v2:
> - discard the property mode and add the processor detection
>
> drivers/mmc/host/sdhci-pltfm.c | 32
> drivers/mmc/host/sdhci.c |3 +++
> include/linux/mmc/sdhci.h |1 +
> 3 files changed, 36 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
> index d9a4ef4..ad55181 100644
> --- a/drivers/mmc/host/sdhci-pltfm.c
> +++ b/drivers/mmc/host/sdhci-pltfm.c
> @@ -93,6 +93,36 @@ void sdhci_get_of_property(struct platform_device *pdev) {}
> #endif /* CONFIG_OF */
> EXPORT_SYMBOL_GPL(sdhci_get_of_property);
>
> +static const u32 processor_table[] = {
> + /* P1020 Dual/Single core */
> + 0x80EC00, 0x80E400, 0x80ED00, 0x80E500,
> + /* P1021 Dual/Single core */
> + 0x80EC01, 0x80E401, 0x80ED01, 0x80E501,
> + /* P1022 Dual/Single core */
> + 0x80EE00, 0x80E600, 0x80EF00, 0x80E700,
> + /* P1024 Dual/Single core */
> + 0x80EC02, 0x80E402, 0x80ED02, 0x80E502,
> + /* P1025 Dual/Single core */
> + 0x80EC03, 0x80E403, 0x80ED03, 0x80E503,
> + /* P4080 and P4040 */
> + 0x82, 0x820800, 0x820100, 0x820900
> +};
> +
> +void sdhci_detect_limitation(struct platform_device *pdev)
> +{
> + struct sdhci_host *host = platform_get_drvdata(pdev);
> + u32 svr = mfspr(SPRN_SVR) >> 8;
> + u32 table_size = ARRAY_SIZE(processor_table);
> + int i;
> +
> + for (i = 0; i < table_size; i++) {
> + if (processor_table[i] == svr) {
> + host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
> + break;
> + }
> + }
> +}
> +
These changes are specific to powerpc platform. And sdhci-pltfm.c is a
generic sdhci file. adding platform Soc code into this is not good.
You can find how other Socs are making use of this file by creating a
new Soc specific extension file.
Similarly you can have something like sdhci-powerpc.c
> struct sdhci_host *sdhci_pltfm_init(struct platform_device *pdev,
> struct sdhci_pltfm_data *pdata)
> {
> @@ -185,6 +215,8 @@ int sdhci_pltfm_register(struct platform_device *pdev,
>
> sdhci_get_of_property(pdev);
>
> + sdhci_detect_limitation(pdev);
> +
> ret = sdhci_add_host(host);
> if (ret)
> sdhci_pltfm_free(pdev);
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 9a11dc3..6208a8b 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2795,6 +2795,9 @@ int sdhci_add_host(struct sdhci_host *host)
> if (!(host->quirks & SDHCI_QUIRK_FORCE_1_BIT_DATA))
> mmc->caps |= MMC_CAP_4_BIT_DATA;
>
> + if (host->quirks2 & SDHCI_QUIRK2_HOST_NO_CMD23)
> + mmc->caps &= ~MMC_CAP_CMD23;
> +
> if (caps[0] & SDHCI_CAN_DO_HISPD)
> mmc->caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED;
>
> diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
> index ac83b10..97c73f5 100644
> --- a/include/linux/mmc/sdhci.h
> +++ b/include/linux/mmc/sdhci.h
> @@ -91,6 +91,7 @@ struct sdhci_host {
> unsigned int quirks2; /* More deviations from spec. */
>
> #define SDHCI_QUIRK2_HOST_OFF_CARD_ON (1<<0)
> +#define SDHCI_QUIRK2_HOST_NO_CMD23 (1<<1)
>
> int irq;/* Device IRQ */
> void __iomem *ioaddr; /* Mapped address */
> --
> 1.7.9.5
>
>
> --
> 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] mmc: Fixup broken suspend and eMMC4.5 power off notify
On 14 September 2012 20:34, Arnd Bergmann wrote: > On Friday 14 September 2012, Linus Walleij wrote: >> On Fri, Sep 14, 2012 at 10:25 AM, Girish K S >> wrote: >> > On 14 September 2012 12:37, Ulf Hansson wrote: >> >> Hi Girish, >> >> >> >> I should also have stated that this patch has not been tested with an >> >> eMMC 4.5 device, thus the power off notification is not fully tested. >> >> Unfortunate I don't have such a device available right now. What I did >> >> test was that patch must not break anything and tested that the >> >> suspend/resume sequence is fixed for eMMC with sleep support. I also >> >> tested this with MMC_CAP2_POWEROFF_NOTIFY enabled. >> >> >> >> Are you able to help out in testing with a eMMC 4.5 device with >> >> POWER_OFF_NOTIFY support? >> > >> > I am also facing the same problem. The board that i used earlier to >> > upstream 4.5 patches is not functioning. Thats the reason for the >> > delay in upstreaming or sending the patch. Once i get it repaired i ll >> > definitely do it. >> > It would be helpful if somebody in the list can do this in the mean time. >> >> Let's page Arnd, I was under the impression that he has a eMMC 4.5 >> board so maybe he can test it? > > I have a few eMMC samples but am only using them with my (slow) thinkpad > SD card reader. I also don't know which eMMC-4.5 features they implement, > as some may be early prototypes. > > What exactly do you need tested? Poweroff Notify feature with the above patch in suspend to ram. > > 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 -- 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/3] mmc: sdhci-s3c: Fix crash on module insertion for second time
good catch Reviewed by: Girish K S On 14 September 2012 14:38, Chander Kashyap wrote: > If sdhci-s3c driver is built as module, it gives following error if inserted > again after removing. This was happening as pm_runtime_use_autosuspend() is > called in sdhci_s3c_probe() function but in sdhci_s3c_remove() its > complementry > pm_runtime_dont_use_autosuspend() is not called. > > BUG: spinlock bad magic on CPU#1, insmod/955 > lock: 0xee771368, .magic: , .owner: insmod/955, .owner_cpu: 1 > [] (unwind_backtrace+0x0/0xf8) from [] > (do_raw_spin_unlock+0xa4/0xe4) > [] (do_raw_spin_unlock+0xa4/0xe4) from [] > (_raw_spin_unlock_irqrestore+0xc/0x38) > [] (_raw_spin_unlock_irqrestore+0xc/0x38) from [] > (sdhci_runtime_suspend_host+0x54/0x80) > [] (sdhci_runtime_suspend_host+0x54/0x80) from [] > (sdhci_s3c_runtime_suspend+0x14/0x38 [sdhci_s3c]) > [] (sdhci_s3c_runtime_suspend+0x14/0x38 [sdhci_s3c]) from > [] (pm_generic_runtime_suspend+0x2c/0x40) > [] (pm_generic_runtime_suspend+0x2c/0x40) from [] > (__rpm_callback+0x70/0x98) > [] (__rpm_callback+0x70/0x98) from [] > (rpm_suspend+0xf0/0x534) > [] (rpm_suspend+0xf0/0x534) from [] > (__pm_runtime_suspend+0x5c/0x74) > [] (__pm_runtime_suspend+0x5c/0x74) from [] > (pm_generic_runtime_idle+0x44/0x4c) > [] (pm_generic_runtime_idle+0x44/0x4c) from [] > (__rpm_callback+0x70/0x98) > [] (__rpm_callback+0x70/0x98) from [] > (rpm_idle+0xdc/0x18c) > [] (rpm_idle+0xdc/0x18c) from [] > (pm_runtime_set_autosuspend_delay+0x30/0x3c) > [] (pm_runtime_set_autosuspend_delay+0x30/0x3c) from [] > (sdhci_s3c_probe+0x35c/0x52c [sdhci_s3c]) > [] (sdhci_s3c_probe+0x35c/0x52c [sdhci_s3c]) from [] > (platform_drv_probe+0x18/0x1c) > > Signed-off-by: Chander Kashyap > --- > drivers/mmc/host/sdhci-s3c.c |1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c > index 0cbb4c2..3f4518d 100644 > --- a/drivers/mmc/host/sdhci-s3c.c > +++ b/drivers/mmc/host/sdhci-s3c.c > @@ -658,6 +658,7 @@ static int __devexit sdhci_s3c_remove(struct > platform_device *pdev) > > sdhci_remove_host(host, 1); > > + pm_runtime_dont_use_autosuspend(&pdev->dev); > pm_runtime_disable(&pdev->dev); > > clk_disable(sc->clk_bus[sc->cur_clk]); > -- > 1.7.9.5 > -- 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/3] mmc: sdhci-s3c: Enable only required bus clock
looks good
Reviewed by: Girish KS
On 14 September 2012 14:38, Chander Kashyap wrote:
> In case of multiple bus clock sources, all the clock sources were
> getting enabled. As only one clock source is needed at the time hence
> enable only the required bus clock.
>
> This patch does as follows:
> 1. In sdhci_s3c_probe enable only required bus clock source.
>
> 2. Handle the disabling of old bus clock and enables the
> best clock selected in sdhci_s3c_set_clock().
>
> Signed-off-by: Chander Kashyap
> ---
> drivers/mmc/host/sdhci-s3c.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index 00969ba..0cbb4c2 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -203,10 +203,12 @@ static void sdhci_s3c_set_clock(struct sdhci_host
> *host, unsigned int clock)
> best_src, clock, best);
>
> /* select the new clock source */
> -
> if (ourhost->cur_clk != best_src) {
> struct clk *clk = ourhost->clk_bus[best_src];
>
> + clk_enable(clk);
> + clk_disable(ourhost->clk_bus[ourhost->cur_clk]);
> +
> /* turn clock off to card before changing clock source */
> writew(0, host->ioaddr + SDHCI_CLOCK_CONTROL);
>
> @@ -501,8 +503,6 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
> */
> sc->cur_clk = ptr;
>
> - clk_enable(clk);
> -
> dev_info(dev, "clock source %d: %s (%ld Hz)\n",
> ptr, name, clk_get_rate(clk));
> }
> @@ -513,6 +513,8 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
> goto err_no_busclks;
> }
>
> + clk_enable(sc->clk_bus[sc->cur_clk]);
> +
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> host->ioaddr = devm_request_and_ioremap(&pdev->dev, res);
> if (!host->ioaddr) {
> @@ -621,9 +623,9 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
> return 0;
>
> err_req_regs:
> + clk_disable(sc->clk_bus[sc->cur_clk]);
> for (ptr = 0; ptr < MAX_BUS_CLK; ptr++) {
> if (sc->clk_bus[ptr]) {
> - clk_disable(sc->clk_bus[ptr]);
> clk_put(sc->clk_bus[ptr]);
> }
> }
> @@ -658,9 +660,9 @@ static int __devexit sdhci_s3c_remove(struct
> platform_device *pdev)
>
> pm_runtime_disable(&pdev->dev);
>
> + clk_disable(sc->clk_bus[sc->cur_clk]);
> for (ptr = 0; ptr < 3; ptr++) {
> if (sc->clk_bus[ptr]) {
> - clk_disable(sc->clk_bus[ptr]);
> clk_put(sc->clk_bus[ptr]);
> }
> }
> --
> 1.7.9.5
>
--
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: Fixup broken suspend and eMMC4.5 power off notify
On 14 September 2012 14:49, Ulf Hansson wrote: > On 14 September 2012 10:25, Girish K S > wrote: >> On 14 September 2012 12:37, Ulf Hansson wrote: >>> Hi Girish, >>> >>> I should also have stated that this patch has not been tested with an >>> eMMC 4.5 device, thus the power off notification is not fully tested. >>> Unfortunate I don't have such a device available right now. What I did >>> test was that patch must not break anything and tested that the >>> suspend/resume sequence is fixed for eMMC with sleep support. I also >>> tested this with MMC_CAP2_POWEROFF_NOTIFY enabled. >>> >>> Are you able to help out in testing with a eMMC 4.5 device with >>> POWER_OFF_NOTIFY support? >> I am also facing the same problem. The board that i used earlier to >> upstream 4.5 patches is not functioning. Thats the reason for the >> delay in upstreaming or sending the patch. Once i get it repaired i ll >> definitely do it. >> It would be helpful if somebody in the list can do this in the mean time. > > Ah, I see. > > If not possible to test soon, I anyway think we should go ahead with > this patch, since it fixes the supend/resume sequence for eMMC with > sleep, which to me is far more important right know, it has been > broken for several month now. If there are any issues with power off > notify feature, we can fix that later on. What do you think of that > approach? OK i do agree with it. you can add my signoff or ack for this > > Kind regards > Ulf Hansson -- 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: Fixup broken suspend and eMMC4.5 power off notify
On 14 September 2012 12:37, Ulf Hansson wrote:
> Hi Girish,
>
> I should also have stated that this patch has not been tested with an
> eMMC 4.5 device, thus the power off notification is not fully tested.
> Unfortunate I don't have such a device available right now. What I did
> test was that patch must not break anything and tested that the
> suspend/resume sequence is fixed for eMMC with sleep support. I also
> tested this with MMC_CAP2_POWEROFF_NOTIFY enabled.
>
> Are you able to help out in testing with a eMMC 4.5 device with
> POWER_OFF_NOTIFY support?
I am also facing the same problem. The board that i used earlier to
upstream 4.5 patches is not functioning. Thats the reason for the
delay in upstreaming or sending the patch. Once i get it repaired i ll
definitely do it.
It would be helpful if somebody in the list can do this in the mean time.
>
> Kind regards
> Ulf Hansson
>
> On 14 September 2012 08:38, Girish K S
> wrote:
>> On 14 September 2012 10:38, Girish K S
>> wrote:
>>> HI Ulf,
>>> You had Acked the rework patch mailed by Saugata. But this patch
>>> doesnt look same like the one sent by saugata.
>> Sorry Ulf
>> I saw your and Saugata mail after replying to this.
>> Pls ignore this
>>>
>>> On 13 September 2012 14:50, Ulf Hansson wrote:
>>>> From: Ulf Hansson
>>>>
>>>> This patch fixup the broken suspend sequence for eMMC
>>>> with sleep support. Additionally it reworks the eMMC4.5
>>>> Power Off Notification feature so it fits together with
>>>> the existing sleep feature.
>>>>
>>>> The CMD0 based re-initialization of the eMMC at resume
>>>> is re-introduced to maintain compatiblity for devices
>>>> using sleep.
>>>>
>>>> A host shall use MMC_CAP2_POWEROFF_NOTIFY to enable the
>>>> Power Off Notification feature. We might be able to
>>>> remove this cap later on, if we think that Power Off
>>>> Notification always is preferred over sleep, even if the
>>>> host is not able to cut the eMMC VCCQ power.
>>>>
>>>> Signed-off-by: Ulf Hansson
>>>> Signed-off-by: Saugata Das
>>>> CC: Girish K S
>>>> CC: Asutosh Das
>>>> ---
>>>> drivers/mmc/core/core.c | 62
>>>> -
>>>> drivers/mmc/core/mmc.c| 46 +
>>>> drivers/mmc/host/dw_mmc.c |5
>>>> drivers/mmc/host/sdhci.c |9 ---
>>>> include/linux/mmc/card.h | 10 +---
>>>> include/linux/mmc/host.h |4 ---
>>>> 6 files changed, 36 insertions(+), 100 deletions(-)
>>>>
>>>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>>>> index af2c4d2..2765097 100644
>>>> --- a/drivers/mmc/core/core.c
>>>> +++ b/drivers/mmc/core/core.c
>>>> @@ -1134,48 +1134,6 @@ void mmc_set_driver_type(struct mmc_host *host,
>>>> unsigned int drv_type)
>>>> mmc_host_clk_release(host);
>>>> }
>>>>
>>>> -static void mmc_poweroff_notify(struct mmc_host *host)
>>>> -{
>>>> - struct mmc_card *card;
>>>> - unsigned int timeout;
>>>> - unsigned int notify_type = EXT_CSD_NO_POWER_NOTIFICATION;
>>>> - int err = 0;
>>>> -
>>>> - card = host->card;
>>>> - mmc_claim_host(host);
>>>> -
>>>> - /*
>>>> -* Send power notify command only if card
>>>> -* is mmc and notify state is powered ON
>>>> -*/
>>>> - if (card && mmc_card_mmc(card) &&
>>>> - (card->poweroff_notify_state == MMC_POWERED_ON)) {
>>>> -
>>>> - if (host->power_notify_type == MMC_HOST_PW_NOTIFY_SHORT) {
>>>> - notify_type = EXT_CSD_POWER_OFF_SHORT;
>>>> - timeout = card->ext_csd.generic_cmd6_time;
>>>> - card->poweroff_notify_state = MMC_POWEROFF_SHORT;
>>>> - } else {
>>>> - notify_type = EXT_CSD_POWER_OFF_LONG;
>>>> - timeout = card->ext_csd.power_off_longtime;
>>>> - card->poweroff_notify_state = MMC_POWEROFF_LONG;
>>>> - }
>>>> -
>>>> -
Re: [PATCH] mmc: Fixup broken suspend and eMMC4.5 power off notify
On 14 September 2012 10:38, Girish K S wrote:
> HI Ulf,
> You had Acked the rework patch mailed by Saugata. But this patch
> doesnt look same like the one sent by saugata.
Sorry Ulf
I saw your and Saugata mail after replying to this.
Pls ignore this
>
> On 13 September 2012 14:50, Ulf Hansson wrote:
>> From: Ulf Hansson
>>
>> This patch fixup the broken suspend sequence for eMMC
>> with sleep support. Additionally it reworks the eMMC4.5
>> Power Off Notification feature so it fits together with
>> the existing sleep feature.
>>
>> The CMD0 based re-initialization of the eMMC at resume
>> is re-introduced to maintain compatiblity for devices
>> using sleep.
>>
>> A host shall use MMC_CAP2_POWEROFF_NOTIFY to enable the
>> Power Off Notification feature. We might be able to
>> remove this cap later on, if we think that Power Off
>> Notification always is preferred over sleep, even if the
>> host is not able to cut the eMMC VCCQ power.
>>
>> Signed-off-by: Ulf Hansson
>> Signed-off-by: Saugata Das
>> CC: Girish K S
>> CC: Asutosh Das
>> ---
>> drivers/mmc/core/core.c | 62
>> -
>> drivers/mmc/core/mmc.c| 46 +
>> drivers/mmc/host/dw_mmc.c |5
>> drivers/mmc/host/sdhci.c |9 ---
>> include/linux/mmc/card.h | 10 +---
>> include/linux/mmc/host.h |4 ---
>> 6 files changed, 36 insertions(+), 100 deletions(-)
>>
>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>> index af2c4d2..2765097 100644
>> --- a/drivers/mmc/core/core.c
>> +++ b/drivers/mmc/core/core.c
>> @@ -1134,48 +1134,6 @@ void mmc_set_driver_type(struct mmc_host *host,
>> unsigned int drv_type)
>> mmc_host_clk_release(host);
>> }
>>
>> -static void mmc_poweroff_notify(struct mmc_host *host)
>> -{
>> - struct mmc_card *card;
>> - unsigned int timeout;
>> - unsigned int notify_type = EXT_CSD_NO_POWER_NOTIFICATION;
>> - int err = 0;
>> -
>> - card = host->card;
>> - mmc_claim_host(host);
>> -
>> - /*
>> -* Send power notify command only if card
>> -* is mmc and notify state is powered ON
>> -*/
>> - if (card && mmc_card_mmc(card) &&
>> - (card->poweroff_notify_state == MMC_POWERED_ON)) {
>> -
>> - if (host->power_notify_type == MMC_HOST_PW_NOTIFY_SHORT) {
>> - notify_type = EXT_CSD_POWER_OFF_SHORT;
>> - timeout = card->ext_csd.generic_cmd6_time;
>> - card->poweroff_notify_state = MMC_POWEROFF_SHORT;
>> - } else {
>> - notify_type = EXT_CSD_POWER_OFF_LONG;
>> - timeout = card->ext_csd.power_off_longtime;
>> - card->poweroff_notify_state = MMC_POWEROFF_LONG;
>> - }
>> -
>> - err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>> -EXT_CSD_POWER_OFF_NOTIFICATION,
>> -notify_type, timeout);
>> -
>> - if (err && err != -EBADMSG)
>> - pr_err("Device failed to respond within %d poweroff "
>> - "time. Forcefully powering down the device\n",
>> - timeout);
>> -
>> - /* Set the card state to no notification after the poweroff
>> */
>> - card->poweroff_notify_state = MMC_NO_POWER_NOTIFICATION;
>> - }
>> - mmc_release_host(host);
>> -}
>> -
>> /*
>> * Apply power to the MMC stack. This is a two-stage process.
>> * First, we enable power to the card without the clock running.
>> @@ -1238,8 +1196,6 @@ static void mmc_power_up(struct mmc_host *host)
>>
>> void mmc_power_off(struct mmc_host *host)
>> {
>> - int err = 0;
>> -
>> if (host->ios.power_mode == MMC_POWER_OFF)
>> return;
>>
>> @@ -1248,22 +1204,6 @@ void mmc_power_off(struct mmc_host *host)
>> host->ios.clock = 0;
>> host->ios.vdd = 0;
>>
>> - /*
>> -* For eMMC 4.5 device send AWAKE command before
>> -* POWER_OFF_NOTIFY command, because in sleep state
>> -* eMMC 4.5 devices respond to only RESET and AWAKE cmd
>> -
Re: [PATCH] mmc: Fixup broken suspend and eMMC4.5 power off notify
HI Ulf,
You had Acked the rework patch mailed by Saugata. But this patch
doesnt look same like the one sent by saugata.
On 13 September 2012 14:50, Ulf Hansson wrote:
> From: Ulf Hansson
>
> This patch fixup the broken suspend sequence for eMMC
> with sleep support. Additionally it reworks the eMMC4.5
> Power Off Notification feature so it fits together with
> the existing sleep feature.
>
> The CMD0 based re-initialization of the eMMC at resume
> is re-introduced to maintain compatiblity for devices
> using sleep.
>
> A host shall use MMC_CAP2_POWEROFF_NOTIFY to enable the
> Power Off Notification feature. We might be able to
> remove this cap later on, if we think that Power Off
> Notification always is preferred over sleep, even if the
> host is not able to cut the eMMC VCCQ power.
>
> Signed-off-by: Ulf Hansson
> Signed-off-by: Saugata Das
> CC: Girish K S
> CC: Asutosh Das
> ---
> drivers/mmc/core/core.c | 62
> -
> drivers/mmc/core/mmc.c| 46 +
> drivers/mmc/host/dw_mmc.c |5
> drivers/mmc/host/sdhci.c |9 ---
> include/linux/mmc/card.h | 10 +---
> include/linux/mmc/host.h |4 ---
> 6 files changed, 36 insertions(+), 100 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index af2c4d2..2765097 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -1134,48 +1134,6 @@ void mmc_set_driver_type(struct mmc_host *host,
> unsigned int drv_type)
> mmc_host_clk_release(host);
> }
>
> -static void mmc_poweroff_notify(struct mmc_host *host)
> -{
> - struct mmc_card *card;
> - unsigned int timeout;
> - unsigned int notify_type = EXT_CSD_NO_POWER_NOTIFICATION;
> - int err = 0;
> -
> - card = host->card;
> - mmc_claim_host(host);
> -
> - /*
> -* Send power notify command only if card
> -* is mmc and notify state is powered ON
> -*/
> - if (card && mmc_card_mmc(card) &&
> - (card->poweroff_notify_state == MMC_POWERED_ON)) {
> -
> - if (host->power_notify_type == MMC_HOST_PW_NOTIFY_SHORT) {
> - notify_type = EXT_CSD_POWER_OFF_SHORT;
> - timeout = card->ext_csd.generic_cmd6_time;
> - card->poweroff_notify_state = MMC_POWEROFF_SHORT;
> - } else {
> - notify_type = EXT_CSD_POWER_OFF_LONG;
> - timeout = card->ext_csd.power_off_longtime;
> - card->poweroff_notify_state = MMC_POWEROFF_LONG;
> - }
> -
> - err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> -EXT_CSD_POWER_OFF_NOTIFICATION,
> -notify_type, timeout);
> -
> - if (err && err != -EBADMSG)
> - pr_err("Device failed to respond within %d poweroff "
> - "time. Forcefully powering down the device\n",
> - timeout);
> -
> - /* Set the card state to no notification after the poweroff */
> - card->poweroff_notify_state = MMC_NO_POWER_NOTIFICATION;
> - }
> - mmc_release_host(host);
> -}
> -
> /*
> * Apply power to the MMC stack. This is a two-stage process.
> * First, we enable power to the card without the clock running.
> @@ -1238,8 +1196,6 @@ static void mmc_power_up(struct mmc_host *host)
>
> void mmc_power_off(struct mmc_host *host)
> {
> - int err = 0;
> -
> if (host->ios.power_mode == MMC_POWER_OFF)
> return;
>
> @@ -1248,22 +1204,6 @@ void mmc_power_off(struct mmc_host *host)
> host->ios.clock = 0;
> host->ios.vdd = 0;
>
> - /*
> -* For eMMC 4.5 device send AWAKE command before
> -* POWER_OFF_NOTIFY command, because in sleep state
> -* eMMC 4.5 devices respond to only RESET and AWAKE cmd
> -*/
> - if (host->card && mmc_card_is_sleep(host->card) &&
> - host->bus_ops->resume) {
> - err = host->bus_ops->resume(host);
> -
> - if (!err)
> - mmc_poweroff_notify(host);
> - else
> - pr_warning("%s: error %d during resume "
> - "(continue with poweroff sequence)\n",
> - mmc_hostname(host), err);
>
Re: [PATCH] Revert "mmc: dw_mmc: Add check for IDMAC configuration"
On 12 September 2012 07:51, Seungwon Jeon wrote: > On Tuesday, September 11, 2012, Girish K S > wrote: >> On 11 September 2012 12:41, Girish K S >> wrote: >> > On 11 September 2012 12:09, Seungwon Jeon wrote: >> >> On Tuesday, September 11, 2012, Girish K S >> >> wrote: >> >>> On 11 September 2012 11:16, Seungwon Jeon wrote: >> >>> > On Tuesday, September 11, 2012, Girish K S >> >>> > wrote: >> >>> >> On 11 September 2012 07:53, Seungwon Jeon >> >>> >> wrote: >> >>> >> > This reverts commit 94c6cee91(Add check for IDMAC configuration). >> >>> >> > Synopsys says that only if internal dmac is not present, optional >> >>> >> > external dma interface is present. When internal dmac is present, >> >>> >> > '0' value in DMA_INTERFACE of HCON is reasonable. DMA_INTERFACE >> >>> >> > indicates external dma interface. And idmac initialization is >> >>> >> > prohibited now. So, let's revert this commit. >> >>> >> >> >>> >> There is no register, or a field in any register which says IDMAC >> >>> >> present. >> >>> >> I can see only use_idmac bit field in CTRL register. >> >>> >> So in first place how will i know whether IDMAC is present? Have you >> >>> >> assumed that IDMAC is present. >> >>> >> I would like to know without assuming, whether IDMAC is present. >> >>> >> If i have missed out something let me know. i will check and revert >> >>> >> back >> >>> > There is no way to see the presence of idmac from host controller on >> >>> > the runtime. >> >>> > But enabling idmac is not selected in the menuconfig just with >> >>> > assuming its presence. >> >>> > User can find the support of idmac from manual at least, I know the >> >>> > lack of this information in >> >>> manual though. >> >>> I cannot find any line in the manual saying "Support IDMAC". Keeping >> >>> this in mind and the with the literal meaning what the HCON field >> >>> DMA_INTERFACE means, the above patch was made. >> >>> i had posted a patch for adding quirk to this (was waiting for some dt >> >>> patches to be accepted to resend it). Once that patch gets merged it >> >>> will be helpful for the user to use it comfortably. If QUIRK is >> >>> enabled it means there is IDMAC and the driver user is intentionally >> >>> enabling it. >> >> I mentioned the lack of description of feature in manual. >> >> When we consider the real meaning of DMA_INTERFACE, '0' value doen't >> >> indicate the absence of idmac. >> >> So, we cannot decide the support of idmac with the DMA_INTERFACE. >> >> >> >> Do you mean this patch:"mmc: dwmmc: Add quirk for broken Hardware Config"? >> >> HCON register in the original Synopsys doesn't include information of >> >> internal dmac. >> >> Do you think it's also broken? >> > As per the current available information from the manual i think the >> > HCON is broken. >> > May be the synopsys is the right person to clarify this. >> If you have some confirmation regarding the DMA_INTERFACE from the >> synopsys. please post it, It will be really helpful in correcting my >> understanding abt the dma interface > Information regarding DMA_INTERFACE can be referred enough in Synopsys manual. > As mentioned above commit message, DMA_INTERFACE specifies the external dma > interface. If this is true (because my discussion is based on the information available in the SOc's manual). then i go with the decision of reverting. > '0'(DMA_INTERFACE) means that there is no external dma interface in current > host controller. > Synopsys may supply the idmac for host controller basically. > If Soc's vendor decides to use external dma interface instead of idmac, > then DMA_INTERFACE parameter should be configured before synthesizing RTL. > I hope it helpful to you. If there is something wrong, please let me know. > > Thanks, > Seungwon Jeon >> >>> > >> >>> >> >> >>> >> > >> >>> >> > CC: Girish K S >> >>> >> > Signed-off-by:
Re: [PATCH] Revert "mmc: dw_mmc: Add check for IDMAC configuration"
On 11 September 2012 12:41, Girish K S wrote:
> On 11 September 2012 12:09, Seungwon Jeon wrote:
>> On Tuesday, September 11, 2012, Girish K S
>> wrote:
>>> On 11 September 2012 11:16, Seungwon Jeon wrote:
>>> > On Tuesday, September 11, 2012, Girish K S
>>> > wrote:
>>> >> On 11 September 2012 07:53, Seungwon Jeon wrote:
>>> >> > This reverts commit 94c6cee91(Add check for IDMAC configuration).
>>> >> > Synopsys says that only if internal dmac is not present, optional
>>> >> > external dma interface is present. When internal dmac is present,
>>> >> > '0' value in DMA_INTERFACE of HCON is reasonable. DMA_INTERFACE
>>> >> > indicates external dma interface. And idmac initialization is
>>> >> > prohibited now. So, let's revert this commit.
>>> >>
>>> >> There is no register, or a field in any register which says IDMAC
>>> >> present.
>>> >> I can see only use_idmac bit field in CTRL register.
>>> >> So in first place how will i know whether IDMAC is present? Have you
>>> >> assumed that IDMAC is present.
>>> >> I would like to know without assuming, whether IDMAC is present.
>>> >> If i have missed out something let me know. i will check and revert back
>>> > There is no way to see the presence of idmac from host controller on the
>>> > runtime.
>>> > But enabling idmac is not selected in the menuconfig just with assuming
>>> > its presence.
>>> > User can find the support of idmac from manual at least, I know the lack
>>> > of this information in
>>> manual though.
>>> I cannot find any line in the manual saying "Support IDMAC". Keeping
>>> this in mind and the with the literal meaning what the HCON field
>>> DMA_INTERFACE means, the above patch was made.
>>> i had posted a patch for adding quirk to this (was waiting for some dt
>>> patches to be accepted to resend it). Once that patch gets merged it
>>> will be helpful for the user to use it comfortably. If QUIRK is
>>> enabled it means there is IDMAC and the driver user is intentionally
>>> enabling it.
>> I mentioned the lack of description of feature in manual.
>> When we consider the real meaning of DMA_INTERFACE, '0' value doen't
>> indicate the absence of idmac.
>> So, we cannot decide the support of idmac with the DMA_INTERFACE.
>>
>> Do you mean this patch:"mmc: dwmmc: Add quirk for broken Hardware Config"?
>> HCON register in the original Synopsys doesn't include information of
>> internal dmac.
>> Do you think it's also broken?
> As per the current available information from the manual i think the
> HCON is broken.
> May be the synopsys is the right person to clarify this.
If you have some confirmation regarding the DMA_INTERFACE from the
synopsys. please post it, It will be really helpful in correcting my
understanding abt the dma interface
>>
>> Thanks,
>> Seungwon Jeon
>>>
>>> >
>>> > Thanks,
>>> > Seungwon Jeon
>>> >
>>> >>
>>> >> >
>>> >> > CC: Girish K S
>>> >> > Signed-off-by: Seungwon Jeon
>>> >> > ---
>>> >> > drivers/mmc/host/dw_mmc.c | 15 ++-
>>> >> > 1 files changed, 2 insertions(+), 13 deletions(-)
>>> >> >
>>> >> > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>> >> > index 36f98c0..dcbe9aa 100644
>>> >> > --- a/drivers/mmc/host/dw_mmc.c
>>> >> > +++ b/drivers/mmc/host/dw_mmc.c
>>> >> > @@ -405,23 +405,11 @@ static void dw_mci_idmac_start_dma(struct dw_mci
>>> >> > *host, unsigned int sg_len)
>>> >> > static int dw_mci_idmac_init(struct dw_mci *host)
>>> >> > {
>>> >> > struct idmac_desc *p;
>>> >> > - int i, dma_support;
>>> >> > + int i;
>>> >> >
>>> >> > /* Number of descriptors in the ring buffer */
>>> >> > host->ring_size = PAGE_SIZE / sizeof(struct idmac_desc);
>>> >> >
>>> >> > - /* Check if Hardware Configuration Register has support for
>>> >> > DMA */
>>> >> > - dma_support = (mci_readl(host, HCON) >> 16) & 0x3;
Re: [PATCH] Revert "mmc: dw_mmc: Add check for IDMAC configuration"
On 11 September 2012 12:09, Seungwon Jeon wrote:
> On Tuesday, September 11, 2012, Girish K S
> wrote:
>> On 11 September 2012 11:16, Seungwon Jeon wrote:
>> > On Tuesday, September 11, 2012, Girish K S
>> > wrote:
>> >> On 11 September 2012 07:53, Seungwon Jeon wrote:
>> >> > This reverts commit 94c6cee91(Add check for IDMAC configuration).
>> >> > Synopsys says that only if internal dmac is not present, optional
>> >> > external dma interface is present. When internal dmac is present,
>> >> > '0' value in DMA_INTERFACE of HCON is reasonable. DMA_INTERFACE
>> >> > indicates external dma interface. And idmac initialization is
>> >> > prohibited now. So, let's revert this commit.
>> >>
>> >> There is no register, or a field in any register which says IDMAC present.
>> >> I can see only use_idmac bit field in CTRL register.
>> >> So in first place how will i know whether IDMAC is present? Have you
>> >> assumed that IDMAC is present.
>> >> I would like to know without assuming, whether IDMAC is present.
>> >> If i have missed out something let me know. i will check and revert back
>> > There is no way to see the presence of idmac from host controller on the
>> > runtime.
>> > But enabling idmac is not selected in the menuconfig just with assuming
>> > its presence.
>> > User can find the support of idmac from manual at least, I know the lack
>> > of this information in
>> manual though.
>> I cannot find any line in the manual saying "Support IDMAC". Keeping
>> this in mind and the with the literal meaning what the HCON field
>> DMA_INTERFACE means, the above patch was made.
>> i had posted a patch for adding quirk to this (was waiting for some dt
>> patches to be accepted to resend it). Once that patch gets merged it
>> will be helpful for the user to use it comfortably. If QUIRK is
>> enabled it means there is IDMAC and the driver user is intentionally
>> enabling it.
> I mentioned the lack of description of feature in manual.
> When we consider the real meaning of DMA_INTERFACE, '0' value doen't indicate
> the absence of idmac.
> So, we cannot decide the support of idmac with the DMA_INTERFACE.
>
> Do you mean this patch:"mmc: dwmmc: Add quirk for broken Hardware Config"?
> HCON register in the original Synopsys doesn't include information of
> internal dmac.
> Do you think it's also broken?
As per the current available information from the manual i think the
HCON is broken.
May be the synopsys is the right person to clarify this.
>
> Thanks,
> Seungwon Jeon
>>
>> >
>> > Thanks,
>> > Seungwon Jeon
>> >
>> >>
>> >> >
>> >> > CC: Girish K S
>> >> > Signed-off-by: Seungwon Jeon
>> >> > ---
>> >> > drivers/mmc/host/dw_mmc.c | 15 ++-
>> >> > 1 files changed, 2 insertions(+), 13 deletions(-)
>> >> >
>> >> > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> >> > index 36f98c0..dcbe9aa 100644
>> >> > --- a/drivers/mmc/host/dw_mmc.c
>> >> > +++ b/drivers/mmc/host/dw_mmc.c
>> >> > @@ -405,23 +405,11 @@ static void dw_mci_idmac_start_dma(struct dw_mci
>> >> > *host, unsigned int sg_len)
>> >> > static int dw_mci_idmac_init(struct dw_mci *host)
>> >> > {
>> >> > struct idmac_desc *p;
>> >> > - int i, dma_support;
>> >> > + int i;
>> >> >
>> >> > /* Number of descriptors in the ring buffer */
>> >> > host->ring_size = PAGE_SIZE / sizeof(struct idmac_desc);
>> >> >
>> >> > - /* Check if Hardware Configuration Register has support for DMA
>> >> > */
>> >> > - dma_support = (mci_readl(host, HCON) >> 16) & 0x3;
>> >> > -
>> >> > - if (!dma_support || dma_support > 2) {
>> >> > - dev_err(&host->dev,
>> >> > - "Host Controller does not support IDMA Tx.\n");
>> >> > - host->dma_ops = NULL;
>> >> > - return -ENODEV;
>> >> > - }
>> >> > -
>> >> > - dev_info(&host->dev, "Using internal DMA controller.\n");
>> >&
Re: [PATCH] Revert "mmc: dw_mmc: Add check for IDMAC configuration"
On 11 September 2012 11:16, Seungwon Jeon wrote:
> On Tuesday, September 11, 2012, Girish K S
> wrote:
>> On 11 September 2012 07:53, Seungwon Jeon wrote:
>> > This reverts commit 94c6cee91(Add check for IDMAC configuration).
>> > Synopsys says that only if internal dmac is not present, optional
>> > external dma interface is present. When internal dmac is present,
>> > '0' value in DMA_INTERFACE of HCON is reasonable. DMA_INTERFACE
>> > indicates external dma interface. And idmac initialization is
>> > prohibited now. So, let's revert this commit.
>>
>> There is no register, or a field in any register which says IDMAC present.
>> I can see only use_idmac bit field in CTRL register.
>> So in first place how will i know whether IDMAC is present? Have you
>> assumed that IDMAC is present.
>> I would like to know without assuming, whether IDMAC is present.
>> If i have missed out something let me know. i will check and revert back
> There is no way to see the presence of idmac from host controller on the
> runtime.
> But enabling idmac is not selected in the menuconfig just with assuming its
> presence.
> User can find the support of idmac from manual at least, I know the lack of
> this information in manual though.
I cannot find any line in the manual saying "Support IDMAC". Keeping
this in mind and the with the literal meaning what the HCON field
DMA_INTERFACE means, the above patch was made.
i had posted a patch for adding quirk to this (was waiting for some dt
patches to be accepted to resend it). Once that patch gets merged it
will be helpful for the user to use it comfortably. If QUIRK is
enabled it means there is IDMAC and the driver user is intentionally
enabling it.
>
> Thanks,
> Seungwon Jeon
>
>>
>> >
>> > CC: Girish K S
>> > Signed-off-by: Seungwon Jeon
>> > ---
>> > drivers/mmc/host/dw_mmc.c | 15 ++-
>> > 1 files changed, 2 insertions(+), 13 deletions(-)
>> >
>> > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> > index 36f98c0..dcbe9aa 100644
>> > --- a/drivers/mmc/host/dw_mmc.c
>> > +++ b/drivers/mmc/host/dw_mmc.c
>> > @@ -405,23 +405,11 @@ static void dw_mci_idmac_start_dma(struct dw_mci
>> > *host, unsigned int sg_len)
>> > static int dw_mci_idmac_init(struct dw_mci *host)
>> > {
>> > struct idmac_desc *p;
>> > - int i, dma_support;
>> > + int i;
>> >
>> > /* Number of descriptors in the ring buffer */
>> > host->ring_size = PAGE_SIZE / sizeof(struct idmac_desc);
>> >
>> > - /* Check if Hardware Configuration Register has support for DMA */
>> > - dma_support = (mci_readl(host, HCON) >> 16) & 0x3;
>> > -
>> > - if (!dma_support || dma_support > 2) {
>> > - dev_err(&host->dev,
>> > - "Host Controller does not support IDMA Tx.\n");
>> > - host->dma_ops = NULL;
>> > - return -ENODEV;
>> > - }
>> > -
>> > - dev_info(&host->dev, "Using internal DMA controller.\n");
>> > -
>> > /* Forward link the descriptor list */
>> > for (i = 0, p = host->sg_cpu; i < host->ring_size - 1; i++, p++)
>> > p->des3 = host->sg_dma + (sizeof(struct idmac_desc) * (i +
>> > 1));
>> > @@ -1895,6 +1883,7 @@ static void dw_mci_init_dma(struct dw_mci *host)
>> > /* Determine which DMA interface to use */
>> > #ifdef CONFIG_MMC_DW_IDMAC
>> > host->dma_ops = &dw_mci_idmac_ops;
>> > + dev_info(&host->dev, "Using internal DMA controller.\n");
>> > #endif
>> >
>> > if (!host->dma_ops)
>> > --
>> > 1.7.0.4
>> >
>> >
>> --
>> 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] Revert "mmc: dw_mmc: Add check for IDMAC configuration"
On 11 September 2012 10:06, Jaehoon Chung wrote:
> On 09/11/2012 12:46 PM, Girish K S wrote:
>> On 11 September 2012 07:53, Seungwon Jeon wrote:
>>> This reverts commit 94c6cee91(Add check for IDMAC configuration).
>>> Synopsys says that only if internal dmac is not present, optional
>>> external dma interface is present. When internal dmac is present,
>>> '0' value in DMA_INTERFACE of HCON is reasonable. DMA_INTERFACE
>>> indicates external dma interface. And idmac initialization is
>>> prohibited now. So, let's revert this commit.
>>
>> There is no register, or a field in any register which says IDMAC present.
>> I can see only use_idmac bit field in CTRL register.
>> So in first place how will i know whether IDMAC is present? Have you
>> assumed that IDMAC is present.
>> I would like to know without assuming, whether IDMAC is present.
>> If i have missed out something let me know. i will check and revert back
> I understood that if INTERNAL_DMAC at HCON register is set to 1, we didn't
> consdier the DMA_INTERFACE's value.
I cannot see any field by name INTERNAL_DMAC in the HCON: can you
please tell me the bit position of it.
I think INTERNAL_DMAC is the signal interface to AXI master.
> So although dma_interface is set to 0 or others, host can use the internal
> DMA.
>
> Best Regards,
> Jaehoon Chung
>>
>>>
>>> CC: Girish K S
>>> Signed-off-by: Seungwon Jeon
>>> ---
>>> drivers/mmc/host/dw_mmc.c | 15 ++-
>>> 1 files changed, 2 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>> index 36f98c0..dcbe9aa 100644
>>> --- a/drivers/mmc/host/dw_mmc.c
>>> +++ b/drivers/mmc/host/dw_mmc.c
>>> @@ -405,23 +405,11 @@ static void dw_mci_idmac_start_dma(struct dw_mci
>>> *host, unsigned int sg_len)
>>> static int dw_mci_idmac_init(struct dw_mci *host)
>>> {
>>> struct idmac_desc *p;
>>> - int i, dma_support;
>>> + int i;
>>>
>>> /* Number of descriptors in the ring buffer */
>>> host->ring_size = PAGE_SIZE / sizeof(struct idmac_desc);
>>>
>>> - /* Check if Hardware Configuration Register has support for DMA */
>>> - dma_support = (mci_readl(host, HCON) >> 16) & 0x3;
>>> -
>>> - if (!dma_support || dma_support > 2) {
>>> - dev_err(&host->dev,
>>> - "Host Controller does not support IDMA Tx.\n");
>>> - host->dma_ops = NULL;
>>> - return -ENODEV;
>>> - }
>>> -
>>> - dev_info(&host->dev, "Using internal DMA controller.\n");
>>> -
>>> /* Forward link the descriptor list */
>>> for (i = 0, p = host->sg_cpu; i < host->ring_size - 1; i++, p++)
>>> p->des3 = host->sg_dma + (sizeof(struct idmac_desc) * (i +
>>> 1));
>>> @@ -1895,6 +1883,7 @@ static void dw_mci_init_dma(struct dw_mci *host)
>>> /* Determine which DMA interface to use */
>>> #ifdef CONFIG_MMC_DW_IDMAC
>>> host->dma_ops = &dw_mci_idmac_ops;
>>> + dev_info(&host->dev, "Using internal DMA controller.\n");
>>> #endif
>>>
>>> if (!host->dma_ops)
>>> --
>>> 1.7.0.4
>>>
>>>
>> --
>> 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] Revert "mmc: dw_mmc: Add check for IDMAC configuration"
On 11 September 2012 07:53, Seungwon Jeon wrote:
> This reverts commit 94c6cee91(Add check for IDMAC configuration).
> Synopsys says that only if internal dmac is not present, optional
> external dma interface is present. When internal dmac is present,
> '0' value in DMA_INTERFACE of HCON is reasonable. DMA_INTERFACE
> indicates external dma interface. And idmac initialization is
> prohibited now. So, let's revert this commit.
There is no register, or a field in any register which says IDMAC present.
I can see only use_idmac bit field in CTRL register.
So in first place how will i know whether IDMAC is present? Have you
assumed that IDMAC is present.
I would like to know without assuming, whether IDMAC is present.
If i have missed out something let me know. i will check and revert back
>
> CC: Girish K S
> Signed-off-by: Seungwon Jeon
> ---
> drivers/mmc/host/dw_mmc.c | 15 ++-
> 1 files changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 36f98c0..dcbe9aa 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -405,23 +405,11 @@ static void dw_mci_idmac_start_dma(struct dw_mci *host,
> unsigned int sg_len)
> static int dw_mci_idmac_init(struct dw_mci *host)
> {
> struct idmac_desc *p;
> - int i, dma_support;
> + int i;
>
> /* Number of descriptors in the ring buffer */
> host->ring_size = PAGE_SIZE / sizeof(struct idmac_desc);
>
> - /* Check if Hardware Configuration Register has support for DMA */
> - dma_support = (mci_readl(host, HCON) >> 16) & 0x3;
> -
> - if (!dma_support || dma_support > 2) {
> - dev_err(&host->dev,
> - "Host Controller does not support IDMA Tx.\n");
> - host->dma_ops = NULL;
> - return -ENODEV;
> - }
> -
> - dev_info(&host->dev, "Using internal DMA controller.\n");
> -
> /* Forward link the descriptor list */
> for (i = 0, p = host->sg_cpu; i < host->ring_size - 1; i++, p++)
> p->des3 = host->sg_dma + (sizeof(struct idmac_desc) * (i +
> 1));
> @@ -1895,6 +1883,7 @@ static void dw_mci_init_dma(struct dw_mci *host)
> /* Determine which DMA interface to use */
> #ifdef CONFIG_MMC_DW_IDMAC
> host->dma_ops = &dw_mci_idmac_ops;
> + dev_info(&host->dev, "Using internal DMA controller.\n");
> #endif
>
> if (!host->dma_ops)
> --
> 1.7.0.4
>
>
--
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: Adjust timings for power ramping up
On 13 August 2012 11:19, Dmitry Rozhkov wrote: > According to p6.4.1.1 of the Physical Layer Simplified Specification > Ver3.01 the "host needs to keep power line level less than 0.5V and > more than 1ms before power ramp up". This patch adds an explicit delay > of 10ms just before power rump up. > > Without this patch some microSD cards (e.g. Kingston 8G Class 10) can't be > used as bootable media on some TI OMAP chips at least. > See https://bugs.nemomobile.org/show_bug.cgi?id=92 for details. > > Signed-off-by: Dmitry Rozhkov > --- > drivers/mmc/core/core.c |7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c > index 0b6141d..22b0eb2 100644 > --- a/drivers/mmc/core/core.c > +++ b/drivers/mmc/core/core.c > @@ -1163,6 +1163,13 @@ static void mmc_power_up(struct mmc_host *host) > > mmc_host_clk_hold(host); > > + /* > +* According to p6.4.1.1 of the Physical Layer Simplified > Specification > +* Ver3.01 the "host needs to keep power line level less than 0.5V and > +* more than 1ms before power ramp up". > +*/ > + mmc_delay(10); can you instead just try giving this delay in mmc_start_host as a parameter to mmc_detect_change. > + > /* If ocr is set, we use it */ > if (host->ocr) > bit = ffs(host->ocr) - 1; > -- > 1.7.9.5 > > -- > 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 1/3] mmc: dw_mmc: amend using error interrupt status
On 1 August 2012 06:00, Seungwon Jeon wrote:
> RINTSTS status includes masked interrupts as well as unmasked.
> data_status and cmd_status are set by value of RINTSTS in interrupt handler
> and tasklet finally uses it to decide whether error is happened or not.
> In addition, MINTSTS status is used for setting data_status in PIO.
> Masked error interrupt will not be handled and that status can be considered
> non-error case.
>
> Signed-off-by: Seungwon Jeon
> ---
> drivers/mmc/host/dw_mmc.c | 11 +--
> 1 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 72dc3cd..7baed45 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1547,12 +1547,11 @@ static void dw_mci_cmd_interrupt(struct dw_mci *host,
> u32 status)
> static irqreturn_t dw_mci_interrupt(int irq, void *dev_id)
> {
> struct dw_mci *host = dev_id;
> - u32 status, pending;
> + u32 pending;
> unsigned int pass_count = 0;
> int i;
>
> do {
> - status = mci_readl(host, RINTSTS);
> pending = mci_readl(host, MINTSTS); /* read-only mask reg */
>
> /*
> @@ -1570,7 +1569,7 @@ static irqreturn_t dw_mci_interrupt(int irq, void
> *dev_id)
>
> if (pending & DW_MCI_CMD_ERROR_FLAGS) {
> mci_writel(host, RINTSTS, DW_MCI_CMD_ERROR_FLAGS);
> - host->cmd_status = status;
> + host->cmd_status = pending;
> smp_wmb();
> set_bit(EVENT_CMD_COMPLETE, &host->pending_events);
> }
> @@ -1578,7 +1577,7 @@ static irqreturn_t dw_mci_interrupt(int irq, void
> *dev_id)
> if (pending & DW_MCI_DATA_ERROR_FLAGS) {
> /* if there is an error report DATA_ERROR */
> mci_writel(host, RINTSTS, DW_MCI_DATA_ERROR_FLAGS);
> - host->data_status = status;
> + host->data_status = pending;
> smp_wmb();
> set_bit(EVENT_DATA_ERROR, &host->pending_events);
> if (!(pending & (SDMMC_INT_DTO | SDMMC_INT_DCRC |
> @@ -1589,7 +1588,7 @@ static irqreturn_t dw_mci_interrupt(int irq, void
> *dev_id)
> if (pending & SDMMC_INT_DATA_OVER) {
> mci_writel(host, RINTSTS, SDMMC_INT_DATA_OVER);
> if (!host->data_status)
> - host->data_status = status;
> + host->data_status = pending;
> smp_wmb();
> if (host->dir_status == DW_MCI_RECV_STATUS) {
> if (host->sg != NULL)
> @@ -1613,7 +1612,7 @@ static irqreturn_t dw_mci_interrupt(int irq, void
> *dev_id)
>
> if (pending & SDMMC_INT_CMD_DONE) {
> mci_writel(host, RINTSTS, SDMMC_INT_CMD_DONE);
> - dw_mci_cmd_interrupt(host, status);
> + dw_mci_cmd_interrupt(host, pending);
> }
>
> if (pending & SDMMC_INT_CD) {
> --
Looks good to me
Reviewed By:- Girish K S
> 1.7.0.4
>
>
> --
> 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] mmc: dw_mmc: add busmode selection support
On 26 July 2012 11:30, Jaehoon Chung wrote:
> Hi Girish,
>
> I re-tested the your patch.
> How about locating into dw_mci_setup_bus()?
>
> And if compare the previously and current busmode,
> I think host needs not to re-write at register.
> For example,
> if (slot->bus_mode == ios->bus_mode)
> return;
>
> Then this patch looks good to me.
Thanks Jaehoon. I will try to test the same and let you know. if
relocation is fine then i will send a patch
>
> Best Regards,
> Jaehoon Chung
>
> On 07/26/2012 12:41 PM, Girish K S wrote:
>> On 24 July 2012 18:37, Jae hoon Chung wrote:
>>> Hi Girish,
>>>
>>> Right, it be mentioned about the open-drain mode in synopsys spec.
>>> But if didn't work on other board, there is some problem.
>>> We can consider the location of set_busmode() .
>> Sure. Currently i am setting the bus mode after sending the command
>> during the clock setting. since the bus mode has affect on the cmd
>> line i will try to move the location of calling bus mode before
>> setting the clock.
>> you can just check whether card gets detected by moving the set mode
>> function just below the switch statement of bus width.
>> On my board irrespective of the set bus mode location it works fine
>>>
>>> Best Regards,
>>> Jaehoon Chung
>>>
>>> 2012/7/24 Girish K S :
>>>> On 24 July 2012 17:06, Girish K S wrote:
>>>>> On 24 July 2012 16:39, Jaehoon Chung wrote:
>>>>>> Hi Girish,
>>>>>>
>>>>>> Well..just tested on my board.
>>>>>> this patch didn't work.(eMMC card didn't initialize)
>>>>>> meaning of ios->bus_mode and synosys's bus_mode is same?
>>>> Yes it is same. synopsys spec says this is specific to MMC
>>>> initialization. when the card core sets this mode during
>>>> initialization. the host has to set this bit
>>>>>> How did you test this patch?
>>>>> Tested it on exynos5 board using dt patches of thomas (with some
>>>>> modification to his patch)
>>>>>>
>>>>>> Best Regards,
>>>>>> Jaehoon Chung
>>>>>>
>>>>>> On 07/23/2012 08:16 PM, Girish K S wrote:
>>>>>>> Synopsis Designware host controller has suppport for open
>>>>>>> drain mode selection. During the mmc card initialization the
>>>>>>> host controller can select the open-drain bit to allow the device
>>>>>>> initialization in the open-drain mode. Once the device enters
>>>>>>> the standby mode this bit can be reset to enter push-pull mode.
>>>>>>>
>>>>>>> Signed-off-by: Girish K S
>>>>>>> ---
>>>>>>> drivers/mmc/host/dw_mmc.c | 14 ++
>>>>>>> drivers/mmc/host/dw_mmc.h |1 +
>>>>>>> 2 files changed, 15 insertions(+), 0 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>>>>>> index 72dc3cd..da11e5a 100644
>>>>>>> --- a/drivers/mmc/host/dw_mmc.c
>>>>>>> +++ b/drivers/mmc/host/dw_mmc.c
>>>>>>> @@ -773,6 +773,18 @@ static void dw_mci_request(struct mmc_host *mmc,
>>>>>>> struct mmc_request *mrq)
>>>>>>> spin_unlock_bh(&host->lock);
>>>>>>> }
>>>>>>>
>>>>>>> +static void dw_mci_set_busmode(struct dw_mci_slot *slot)
>>>>>>> +{
>>>>>>> + struct mmc_ios *ios = &slot->mmc->ios;
>>>>>>> + u32 reg;
>>>>>>> +
>>>>>>> + reg = mci_readl(slot->host, CTRL);
>>>>>>> + if (ios->bus_mode == MMC_BUSMODE_OPENDRAIN)
>>>>>>> + mci_writel(slot->host, CTRL, reg | SDMMC_CTRL_ENABLE_OD);
>>>>>>> + else
>>>>>>> + mci_writel(slot->host, CTRL, reg & ~SDMMC_CTRL_ENABLE_OD);
>>>>>>> +}
>>>>>>> +
>>>>>>> static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>>>>>>> {
>>>>>>> struct dw_mci_slot *slot = mmc_priv(mmc);
>>>>>>> @@ -818,6 +830,8 @@ static void dw_mci_set_ios(struct mmc_host *mmc,
>>>>>>> struct mmc_ios *ios)
>>>>>>> default:
>>>>>>> break;
>>>>>>> }
>>>>>>> +
>>>>>>> + dw_mci_set_busmode(slot);
>>>>>>> }
>>>>>>>
>>>>>>> static int dw_mci_get_ro(struct mmc_host *mmc)
>>>>>>> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
>>>>>>> index 15c27e1..1a53fb2 100644
>>>>>>> --- a/drivers/mmc/host/dw_mmc.h
>>>>>>> +++ b/drivers/mmc/host/dw_mmc.h
>>>>>>> @@ -67,6 +67,7 @@
>>>>>>>
>>>>>>> /* Control register defines */
>>>>>>> #define SDMMC_CTRL_USE_IDMAC BIT(25)
>>>>>>> +#define SDMMC_CTRL_ENABLE_OD BIT(24)
>>>>>>> #define SDMMC_CTRL_CEATA_INT_EN BIT(11)
>>>>>>> #define SDMMC_CTRL_SEND_AS_CCSD BIT(10)
>>>>>>> #define SDMMC_CTRL_SEND_CCSD BIT(9)
>>>>>>>
>>>>>>
>>>>>>
>>>> --
>>>> 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 V2] mmc: dwmmc: Add quirk for broken Hardware Config
On 24 July 2012 10:48, Seungwon Jeon wrote:
> Hi Girish,
>
> July 23, 2012, Girish K S wrote:
>> In some Soc'S that integrate Designware mmc host controllers, the
>> HCON register is broken. The hardware configuration is not
>> updated. One specific usecase is the IDMAC. In Exysons5 SoC
>> there exist a internal DMA, but the HCON register's DMA_INTERFACE
>> field is not set to indicate its existance.
>>
>> This quirk can be used in such case to force the existance broken
>> HCON field.
>>
>> changes in v2:
>> -moved the implementation to quirk framework as per venkat's
>>review comment.
>> changes in v1:
>> -modified the caps2 field access per controller index.Reported
>>by Jaehoon Chung .
>> -replaced the pointer to device with the pointer to platform
>>device in struct dw_mci.
> Change related to adding pointer of platform_device is needed in this patch
> seriously?
> I guess that the purpose is to get id of platform_device in case of non-dt.
> Although a lot of replace is done throughout dw_mmc, actual usage is only in
> dw_get_platform_device_id.
> You can split it into another patch if this change is needed, or it's good to
> use other way.
> For example, to_platform_device macro is useful to get pointer of
> platform_device.
I will make the necessary changes as suggested once Thomas's patches
gets accepted
>
> Best regards,
> Seungwon Jeon
>
>> -updated driver data for all 4 mmc controllers of exynos5 SoC.
>> -added non device-tree support for ctrl_id access.
>>
>> Signed-off-by: Girish K S
>> ---
>> drivers/mmc/host/dw_mmc-pltfm.c | 10 +++-
>> drivers/mmc/host/dw_mmc.c | 151
>> ---
>> drivers/mmc/host/dw_mmc.h |1 +
>> include/linux/mmc/dw_mmc.h |4 +-
>> 4 files changed, 107 insertions(+), 59 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c
>> b/drivers/mmc/host/dw_mmc-pltfm.c
>> index 900f412..7d31e90 100644
>> --- a/drivers/mmc/host/dw_mmc-pltfm.c
>> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
>> @@ -35,9 +35,17 @@ static unsigned long exynos5250_dwmmc_caps[4] = {
>> MMC_CAP_CMD23,
>> };
>>
>> +static unsigned long exynos5250_dwmmc_quirks[4] = {
>> + DW_MCI_QUIRK_NO_HCON_DMA_INFO,
>> + DW_MCI_QUIRK_NO_HCON_DMA_INFO,
>> + DW_MCI_QUIRK_NO_HCON_DMA_INFO,
>> + DW_MCI_QUIRK_NO_HCON_DMA_INFO,
>> +};
>> +
>> static struct dw_mci_drv_data exynos5250_drv_data = {
>> .ctrl_type = DW_MCI_TYPE_EXYNOS5250,
>> .caps = exynos5250_dwmmc_caps,
>> + .quirks = exynos5250_dwmmc_quirks,
>> };
>>
>> static const struct of_device_id dw_mci_pltfm_match[] = {
>> @@ -74,7 +82,7 @@ static int dw_mci_pltfm_probe(struct platform_device *pdev)
>> goto err_free;
>> }
>>
>> - host->dev = &pdev->dev;
>> + host->pdev = pdev;
>> host->irq_flags = 0;
>> host->pdata = pdev->dev.platform_data;
>> ret = -ENOMEM;
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 000da16..b32e200 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -283,8 +283,10 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc,
>> struct mmc_command *cmd)
>> static void dw_mci_start_command(struct dw_mci *host,
>>struct mmc_command *cmd, u32 cmd_flags)
>> {
>> + struct device *dev = &host->pdev->dev;
>> +
>> host->cmd = cmd;
>> - dev_vdbg(host->dev,
>> + dev_vdbg(dev,
>>"start command: ARGR=0x%08x CMDR=0x%08x\n",
>>cmd->arg, cmd_flags);
>>
>> @@ -323,10 +325,11 @@ static int dw_mci_get_dma_dir(struct mmc_data *data)
>> static void dw_mci_dma_cleanup(struct dw_mci *host)
>> {
>> struct mmc_data *data = host->data;
>> + struct device *dev = &host->pdev->dev;
>>
>> if (data)
>> if (!data->host_cookie)
>> - dma_unmap_sg(host->dev,
>> + dma_unmap_sg(dev,
>>data->sg,
>>data->sg_len,
>>dw_mci_get_dma_dir(data));
>> @@ -351,8 +354,9 @@ static void dw_mci_idmac_stop_dma(struct dw_mci *host)
>> static void dw_m
Re: [PATCH] mmc: dw_mmc: add busmode selection support
On 24 July 2012 18:37, Jae hoon Chung wrote:
> Hi Girish,
>
> Right, it be mentioned about the open-drain mode in synopsys spec.
> But if didn't work on other board, there is some problem.
> We can consider the location of set_busmode() .
Sure. Currently i am setting the bus mode after sending the command
during the clock setting. since the bus mode has affect on the cmd
line i will try to move the location of calling bus mode before
setting the clock.
you can just check whether card gets detected by moving the set mode
function just below the switch statement of bus width.
On my board irrespective of the set bus mode location it works fine
>
> Best Regards,
> Jaehoon Chung
>
> 2012/7/24 Girish K S :
>> On 24 July 2012 17:06, Girish K S wrote:
>>> On 24 July 2012 16:39, Jaehoon Chung wrote:
>>>> Hi Girish,
>>>>
>>>> Well..just tested on my board.
>>>> this patch didn't work.(eMMC card didn't initialize)
>>>> meaning of ios->bus_mode and synosys's bus_mode is same?
>> Yes it is same. synopsys spec says this is specific to MMC
>> initialization. when the card core sets this mode during
>> initialization. the host has to set this bit
>>>> How did you test this patch?
>>> Tested it on exynos5 board using dt patches of thomas (with some
>>> modification to his patch)
>>>>
>>>> Best Regards,
>>>> Jaehoon Chung
>>>>
>>>> On 07/23/2012 08:16 PM, Girish K S wrote:
>>>>> Synopsis Designware host controller has suppport for open
>>>>> drain mode selection. During the mmc card initialization the
>>>>> host controller can select the open-drain bit to allow the device
>>>>> initialization in the open-drain mode. Once the device enters
>>>>> the standby mode this bit can be reset to enter push-pull mode.
>>>>>
>>>>> Signed-off-by: Girish K S
>>>>> ---
>>>>> drivers/mmc/host/dw_mmc.c | 14 ++
>>>>> drivers/mmc/host/dw_mmc.h |1 +
>>>>> 2 files changed, 15 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>>>> index 72dc3cd..da11e5a 100644
>>>>> --- a/drivers/mmc/host/dw_mmc.c
>>>>> +++ b/drivers/mmc/host/dw_mmc.c
>>>>> @@ -773,6 +773,18 @@ static void dw_mci_request(struct mmc_host *mmc,
>>>>> struct mmc_request *mrq)
>>>>> spin_unlock_bh(&host->lock);
>>>>> }
>>>>>
>>>>> +static void dw_mci_set_busmode(struct dw_mci_slot *slot)
>>>>> +{
>>>>> + struct mmc_ios *ios = &slot->mmc->ios;
>>>>> + u32 reg;
>>>>> +
>>>>> + reg = mci_readl(slot->host, CTRL);
>>>>> + if (ios->bus_mode == MMC_BUSMODE_OPENDRAIN)
>>>>> + mci_writel(slot->host, CTRL, reg | SDMMC_CTRL_ENABLE_OD);
>>>>> + else
>>>>> + mci_writel(slot->host, CTRL, reg & ~SDMMC_CTRL_ENABLE_OD);
>>>>> +}
>>>>> +
>>>>> static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>>>>> {
>>>>> struct dw_mci_slot *slot = mmc_priv(mmc);
>>>>> @@ -818,6 +830,8 @@ static void dw_mci_set_ios(struct mmc_host *mmc,
>>>>> struct mmc_ios *ios)
>>>>> default:
>>>>> break;
>>>>> }
>>>>> +
>>>>> + dw_mci_set_busmode(slot);
>>>>> }
>>>>>
>>>>> static int dw_mci_get_ro(struct mmc_host *mmc)
>>>>> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
>>>>> index 15c27e1..1a53fb2 100644
>>>>> --- a/drivers/mmc/host/dw_mmc.h
>>>>> +++ b/drivers/mmc/host/dw_mmc.h
>>>>> @@ -67,6 +67,7 @@
>>>>>
>>>>> /* Control register defines */
>>>>> #define SDMMC_CTRL_USE_IDMAC BIT(25)
>>>>> +#define SDMMC_CTRL_ENABLE_OD BIT(24)
>>>>> #define SDMMC_CTRL_CEATA_INT_EN BIT(11)
>>>>> #define SDMMC_CTRL_SEND_AS_CCSD BIT(10)
>>>>> #define SDMMC_CTRL_SEND_CCSD BIT(9)
>>>>>
>>>>
>>>>
>> --
>> 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] mmc: dw_mmc: add busmode selection support
On 24 July 2012 19:14, Jae hoon Chung wrote:
> 2012/7/24 Girish K S :
>> On 24 July 2012 18:37, Jae hoon Chung wrote:
>>> Hi Girish,
>>>
>>> Right, it be mentioned about the open-drain mode in synopsys spec.
>>> But if didn't work on other board, there is some problem.
>>> We can consider the location of set_busmode() .
>> may i know the board on which you are testing. i will try to use the
>> same and simulate the problem
> Exynos4 board and eMMC4.5 card, Synopsys IP version is 2.40a
Just now i tested it on exynos4 board/ eMMC 4.4 card Synopsis 2.40a
host controller. Everything works fine. this patch doesnt have any
side effect on the exynos4 board
please check from ur end. might be some other issue.
>>>
>>> Best Regards,
>>> Jaehoon Chung
>>>
>>> 2012/7/24 Girish K S :
>>>> On 24 July 2012 17:06, Girish K S wrote:
>>>>> On 24 July 2012 16:39, Jaehoon Chung wrote:
>>>>>> Hi Girish,
>>>>>>
>>>>>> Well..just tested on my board.
>>>>>> this patch didn't work.(eMMC card didn't initialize)
>>>>>> meaning of ios->bus_mode and synosys's bus_mode is same?
>>>> Yes it is same. synopsys spec says this is specific to MMC
>>>> initialization. when the card core sets this mode during
>>>> initialization. the host has to set this bit
>>>>>> How did you test this patch?
>>>>> Tested it on exynos5 board using dt patches of thomas (with some
>>>>> modification to his patch)
>>>>>>
>>>>>> Best Regards,
>>>>>> Jaehoon Chung
>>>>>>
>>>>>> On 07/23/2012 08:16 PM, Girish K S wrote:
>>>>>>> Synopsis Designware host controller has suppport for open
>>>>>>> drain mode selection. During the mmc card initialization the
>>>>>>> host controller can select the open-drain bit to allow the device
>>>>>>> initialization in the open-drain mode. Once the device enters
>>>>>>> the standby mode this bit can be reset to enter push-pull mode.
>>>>>>>
>>>>>>> Signed-off-by: Girish K S
>>>>>>> ---
>>>>>>> drivers/mmc/host/dw_mmc.c | 14 ++
>>>>>>> drivers/mmc/host/dw_mmc.h |1 +
>>>>>>> 2 files changed, 15 insertions(+), 0 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>>>>>> index 72dc3cd..da11e5a 100644
>>>>>>> --- a/drivers/mmc/host/dw_mmc.c
>>>>>>> +++ b/drivers/mmc/host/dw_mmc.c
>>>>>>> @@ -773,6 +773,18 @@ static void dw_mci_request(struct mmc_host *mmc,
>>>>>>> struct mmc_request *mrq)
>>>>>>> spin_unlock_bh(&host->lock);
>>>>>>> }
>>>>>>>
>>>>>>> +static void dw_mci_set_busmode(struct dw_mci_slot *slot)
>>>>>>> +{
>>>>>>> + struct mmc_ios *ios = &slot->mmc->ios;
>>>>>>> + u32 reg;
>>>>>>> +
>>>>>>> + reg = mci_readl(slot->host, CTRL);
>>>>>>> + if (ios->bus_mode == MMC_BUSMODE_OPENDRAIN)
>>>>>>> + mci_writel(slot->host, CTRL, reg | SDMMC_CTRL_ENABLE_OD);
>>>>>>> + else
>>>>>>> + mci_writel(slot->host, CTRL, reg & ~SDMMC_CTRL_ENABLE_OD);
>>>>>>> +}
>>>>>>> +
>>>>>>> static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>>>>>>> {
>>>>>>> struct dw_mci_slot *slot = mmc_priv(mmc);
>>>>>>> @@ -818,6 +830,8 @@ static void dw_mci_set_ios(struct mmc_host *mmc,
>>>>>>> struct mmc_ios *ios)
>>>>>>> default:
>>>>>>> break;
>>>>>>> }
>>>>>>> +
>>>>>>> + dw_mci_set_busmode(slot);
>>>>>>> }
>>>>>>>
>>>>>>> static int dw_mci_get_ro(struct mmc_host *mmc)
>>>>>>> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
>>>>>>> index 15c27e1..1a53fb2 100644
>>>>>>> --- a/drivers/mmc/host/dw_mmc.h
>>>>>>> +++ b/drivers/mmc/host/dw_mmc.h
>>>>>>> @@ -67,6 +67,7 @@
>>>>>>>
>>>>>>> /* Control register defines */
>>>>>>> #define SDMMC_CTRL_USE_IDMAC BIT(25)
>>>>>>> +#define SDMMC_CTRL_ENABLE_OD BIT(24)
>>>>>>> #define SDMMC_CTRL_CEATA_INT_EN BIT(11)
>>>>>>> #define SDMMC_CTRL_SEND_AS_CCSD BIT(10)
>>>>>>> #define SDMMC_CTRL_SEND_CCSD BIT(9)
>>>>>>>
>>>>>>
>>>>>>
>>>> --
>>>> 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] mmc: dw_mmc: add busmode selection support
On 24 July 2012 18:37, Jae hoon Chung wrote:
> Hi Girish,
>
> Right, it be mentioned about the open-drain mode in synopsys spec.
> But if didn't work on other board, there is some problem.
> We can consider the location of set_busmode() .
may i know the board on which you are testing. i will try to use the
same and simulate the problem
>
> Best Regards,
> Jaehoon Chung
>
> 2012/7/24 Girish K S :
>> On 24 July 2012 17:06, Girish K S wrote:
>>> On 24 July 2012 16:39, Jaehoon Chung wrote:
>>>> Hi Girish,
>>>>
>>>> Well..just tested on my board.
>>>> this patch didn't work.(eMMC card didn't initialize)
>>>> meaning of ios->bus_mode and synosys's bus_mode is same?
>> Yes it is same. synopsys spec says this is specific to MMC
>> initialization. when the card core sets this mode during
>> initialization. the host has to set this bit
>>>> How did you test this patch?
>>> Tested it on exynos5 board using dt patches of thomas (with some
>>> modification to his patch)
>>>>
>>>> Best Regards,
>>>> Jaehoon Chung
>>>>
>>>> On 07/23/2012 08:16 PM, Girish K S wrote:
>>>>> Synopsis Designware host controller has suppport for open
>>>>> drain mode selection. During the mmc card initialization the
>>>>> host controller can select the open-drain bit to allow the device
>>>>> initialization in the open-drain mode. Once the device enters
>>>>> the standby mode this bit can be reset to enter push-pull mode.
>>>>>
>>>>> Signed-off-by: Girish K S
>>>>> ---
>>>>> drivers/mmc/host/dw_mmc.c | 14 ++
>>>>> drivers/mmc/host/dw_mmc.h |1 +
>>>>> 2 files changed, 15 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>>>> index 72dc3cd..da11e5a 100644
>>>>> --- a/drivers/mmc/host/dw_mmc.c
>>>>> +++ b/drivers/mmc/host/dw_mmc.c
>>>>> @@ -773,6 +773,18 @@ static void dw_mci_request(struct mmc_host *mmc,
>>>>> struct mmc_request *mrq)
>>>>> spin_unlock_bh(&host->lock);
>>>>> }
>>>>>
>>>>> +static void dw_mci_set_busmode(struct dw_mci_slot *slot)
>>>>> +{
>>>>> + struct mmc_ios *ios = &slot->mmc->ios;
>>>>> + u32 reg;
>>>>> +
>>>>> + reg = mci_readl(slot->host, CTRL);
>>>>> + if (ios->bus_mode == MMC_BUSMODE_OPENDRAIN)
>>>>> + mci_writel(slot->host, CTRL, reg | SDMMC_CTRL_ENABLE_OD);
>>>>> + else
>>>>> + mci_writel(slot->host, CTRL, reg & ~SDMMC_CTRL_ENABLE_OD);
>>>>> +}
>>>>> +
>>>>> static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>>>>> {
>>>>> struct dw_mci_slot *slot = mmc_priv(mmc);
>>>>> @@ -818,6 +830,8 @@ static void dw_mci_set_ios(struct mmc_host *mmc,
>>>>> struct mmc_ios *ios)
>>>>> default:
>>>>> break;
>>>>> }
>>>>> +
>>>>> + dw_mci_set_busmode(slot);
>>>>> }
>>>>>
>>>>> static int dw_mci_get_ro(struct mmc_host *mmc)
>>>>> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
>>>>> index 15c27e1..1a53fb2 100644
>>>>> --- a/drivers/mmc/host/dw_mmc.h
>>>>> +++ b/drivers/mmc/host/dw_mmc.h
>>>>> @@ -67,6 +67,7 @@
>>>>>
>>>>> /* Control register defines */
>>>>> #define SDMMC_CTRL_USE_IDMAC BIT(25)
>>>>> +#define SDMMC_CTRL_ENABLE_OD BIT(24)
>>>>> #define SDMMC_CTRL_CEATA_INT_EN BIT(11)
>>>>> #define SDMMC_CTRL_SEND_AS_CCSD BIT(10)
>>>>> #define SDMMC_CTRL_SEND_CCSD BIT(9)
>>>>>
>>>>
>>>>
>> --
>> 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] mmc: dw_mmc: add busmode selection support
On 24 July 2012 17:06, Girish K S wrote:
> On 24 July 2012 16:39, Jaehoon Chung wrote:
>> Hi Girish,
>>
>> Well..just tested on my board.
>> this patch didn't work.(eMMC card didn't initialize)
>> meaning of ios->bus_mode and synosys's bus_mode is same?
Yes it is same. synopsys spec says this is specific to MMC
initialization. when the card core sets this mode during
initialization. the host has to set this bit
>> How did you test this patch?
> Tested it on exynos5 board using dt patches of thomas (with some
> modification to his patch)
>>
>> Best Regards,
>> Jaehoon Chung
>>
>> On 07/23/2012 08:16 PM, Girish K S wrote:
>>> Synopsis Designware host controller has suppport for open
>>> drain mode selection. During the mmc card initialization the
>>> host controller can select the open-drain bit to allow the device
>>> initialization in the open-drain mode. Once the device enters
>>> the standby mode this bit can be reset to enter push-pull mode.
>>>
>>> Signed-off-by: Girish K S
>>> ---
>>> drivers/mmc/host/dw_mmc.c | 14 ++
>>> drivers/mmc/host/dw_mmc.h |1 +
>>> 2 files changed, 15 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>> index 72dc3cd..da11e5a 100644
>>> --- a/drivers/mmc/host/dw_mmc.c
>>> +++ b/drivers/mmc/host/dw_mmc.c
>>> @@ -773,6 +773,18 @@ static void dw_mci_request(struct mmc_host *mmc,
>>> struct mmc_request *mrq)
>>> spin_unlock_bh(&host->lock);
>>> }
>>>
>>> +static void dw_mci_set_busmode(struct dw_mci_slot *slot)
>>> +{
>>> + struct mmc_ios *ios = &slot->mmc->ios;
>>> + u32 reg;
>>> +
>>> + reg = mci_readl(slot->host, CTRL);
>>> + if (ios->bus_mode == MMC_BUSMODE_OPENDRAIN)
>>> + mci_writel(slot->host, CTRL, reg | SDMMC_CTRL_ENABLE_OD);
>>> + else
>>> + mci_writel(slot->host, CTRL, reg & ~SDMMC_CTRL_ENABLE_OD);
>>> +}
>>> +
>>> static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>>> {
>>> struct dw_mci_slot *slot = mmc_priv(mmc);
>>> @@ -818,6 +830,8 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct
>>> mmc_ios *ios)
>>> default:
>>> break;
>>> }
>>> +
>>> + dw_mci_set_busmode(slot);
>>> }
>>>
>>> static int dw_mci_get_ro(struct mmc_host *mmc)
>>> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
>>> index 15c27e1..1a53fb2 100644
>>> --- a/drivers/mmc/host/dw_mmc.h
>>> +++ b/drivers/mmc/host/dw_mmc.h
>>> @@ -67,6 +67,7 @@
>>>
>>> /* Control register defines */
>>> #define SDMMC_CTRL_USE_IDMAC BIT(25)
>>> +#define SDMMC_CTRL_ENABLE_OD BIT(24)
>>> #define SDMMC_CTRL_CEATA_INT_EN BIT(11)
>>> #define SDMMC_CTRL_SEND_AS_CCSD BIT(10)
>>> #define SDMMC_CTRL_SEND_CCSD BIT(9)
>>>
>>
>>
--
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: dw_mmc: add busmode selection support
On 24 July 2012 16:39, Jaehoon Chung wrote:
> Hi Girish,
>
> Well..just tested on my board.
> this patch didn't work.(eMMC card didn't initialize)
> meaning of ios->bus_mode and synosys's bus_mode is same?
> How did you test this patch?
Tested it on exynos5 board using dt patches of thomas (with some
modification to his patch)
>
> Best Regards,
> Jaehoon Chung
>
> On 07/23/2012 08:16 PM, Girish K S wrote:
>> Synopsis Designware host controller has suppport for open
>> drain mode selection. During the mmc card initialization the
>> host controller can select the open-drain bit to allow the device
>> initialization in the open-drain mode. Once the device enters
>> the standby mode this bit can be reset to enter push-pull mode.
>>
>> Signed-off-by: Girish K S
>> ---
>> drivers/mmc/host/dw_mmc.c | 14 ++
>> drivers/mmc/host/dw_mmc.h |1 +
>> 2 files changed, 15 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 72dc3cd..da11e5a 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -773,6 +773,18 @@ static void dw_mci_request(struct mmc_host *mmc, struct
>> mmc_request *mrq)
>> spin_unlock_bh(&host->lock);
>> }
>>
>> +static void dw_mci_set_busmode(struct dw_mci_slot *slot)
>> +{
>> + struct mmc_ios *ios = &slot->mmc->ios;
>> + u32 reg;
>> +
>> + reg = mci_readl(slot->host, CTRL);
>> + if (ios->bus_mode == MMC_BUSMODE_OPENDRAIN)
>> + mci_writel(slot->host, CTRL, reg | SDMMC_CTRL_ENABLE_OD);
>> + else
>> + mci_writel(slot->host, CTRL, reg & ~SDMMC_CTRL_ENABLE_OD);
>> +}
>> +
>> static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>> {
>> struct dw_mci_slot *slot = mmc_priv(mmc);
>> @@ -818,6 +830,8 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct
>> mmc_ios *ios)
>> default:
>> break;
>> }
>> +
>> + dw_mci_set_busmode(slot);
>> }
>>
>> static int dw_mci_get_ro(struct mmc_host *mmc)
>> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
>> index 15c27e1..1a53fb2 100644
>> --- a/drivers/mmc/host/dw_mmc.h
>> +++ b/drivers/mmc/host/dw_mmc.h
>> @@ -67,6 +67,7 @@
>>
>> /* Control register defines */
>> #define SDMMC_CTRL_USE_IDMAC BIT(25)
>> +#define SDMMC_CTRL_ENABLE_OD BIT(24)
>> #define SDMMC_CTRL_CEATA_INT_EN BIT(11)
>> #define SDMMC_CTRL_SEND_AS_CCSD BIT(10)
>> #define SDMMC_CTRL_SEND_CCSD BIT(9)
>>
>
>
--
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
[PATCH V2] Add Quirk for Broken Configuration
This patch is based on the device tree support of dw_mmc host controller posted by Thomas Abraham. Below is the list of his patch in review stage mmc: dw_mmc: convert copy of struct device in struct dw_mci to a reference mmc: dw_mmc: allow probe to succeed even if one slot is initialized mmc: dw_mmc: lookup for optional biu and ciu clocks mmc: dw_mmc: add quirk to indicate missing write protect line mmc: dw_mmc: add device tree support mmc: dw_mmc: add samsung exynos5250 specific extentions Girish K S (1): mmc: dwmmc: Add quirk for broken Hardware Config drivers/mmc/host/dw_mmc-pltfm.c | 10 +++- drivers/mmc/host/dw_mmc.c | 151 --- drivers/mmc/host/dw_mmc.h |1 + include/linux/mmc/dw_mmc.h |4 +- 4 files changed, 107 insertions(+), 59 deletions(-) -- 1.7.4.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
[PATCH V2] mmc: dwmmc: Add quirk for broken Hardware Config
In some Soc'S that integrate Designware mmc host controllers, the
HCON register is broken. The hardware configuration is not
updated. One specific usecase is the IDMAC. In Exysons5 SoC
there exist a internal DMA, but the HCON register's DMA_INTERFACE
field is not set to indicate its existance.
This quirk can be used in such case to force the existance broken
HCON field.
changes in v2:
-moved the implementation to quirk framework as per venkat's
review comment.
changes in v1:
-modified the caps2 field access per controller index.Reported
by Jaehoon Chung .
-replaced the pointer to device with the pointer to platform
device in struct dw_mci.
-updated driver data for all 4 mmc controllers of exynos5 SoC.
-added non device-tree support for ctrl_id access.
Signed-off-by: Girish K S
---
drivers/mmc/host/dw_mmc-pltfm.c | 10 +++-
drivers/mmc/host/dw_mmc.c | 151 ---
drivers/mmc/host/dw_mmc.h |1 +
include/linux/mmc/dw_mmc.h |4 +-
4 files changed, 107 insertions(+), 59 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index 900f412..7d31e90 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -35,9 +35,17 @@ static unsigned long exynos5250_dwmmc_caps[4] = {
MMC_CAP_CMD23,
};
+static unsigned long exynos5250_dwmmc_quirks[4] = {
+ DW_MCI_QUIRK_NO_HCON_DMA_INFO,
+ DW_MCI_QUIRK_NO_HCON_DMA_INFO,
+ DW_MCI_QUIRK_NO_HCON_DMA_INFO,
+ DW_MCI_QUIRK_NO_HCON_DMA_INFO,
+};
+
static struct dw_mci_drv_data exynos5250_drv_data = {
.ctrl_type = DW_MCI_TYPE_EXYNOS5250,
.caps = exynos5250_dwmmc_caps,
+ .quirks = exynos5250_dwmmc_quirks,
};
static const struct of_device_id dw_mci_pltfm_match[] = {
@@ -74,7 +82,7 @@ static int dw_mci_pltfm_probe(struct platform_device *pdev)
goto err_free;
}
- host->dev = &pdev->dev;
+ host->pdev = pdev;
host->irq_flags = 0;
host->pdata = pdev->dev.platform_data;
ret = -ENOMEM;
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 000da16..b32e200 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -283,8 +283,10 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc,
struct mmc_command *cmd)
static void dw_mci_start_command(struct dw_mci *host,
struct mmc_command *cmd, u32 cmd_flags)
{
+ struct device *dev = &host->pdev->dev;
+
host->cmd = cmd;
- dev_vdbg(host->dev,
+ dev_vdbg(dev,
"start command: ARGR=0x%08x CMDR=0x%08x\n",
cmd->arg, cmd_flags);
@@ -323,10 +325,11 @@ static int dw_mci_get_dma_dir(struct mmc_data *data)
static void dw_mci_dma_cleanup(struct dw_mci *host)
{
struct mmc_data *data = host->data;
+ struct device *dev = &host->pdev->dev;
if (data)
if (!data->host_cookie)
- dma_unmap_sg(host->dev,
+ dma_unmap_sg(dev,
data->sg,
data->sg_len,
dw_mci_get_dma_dir(data));
@@ -351,8 +354,9 @@ static void dw_mci_idmac_stop_dma(struct dw_mci *host)
static void dw_mci_idmac_complete_dma(struct dw_mci *host)
{
struct mmc_data *data = host->data;
+ struct device *dev = &host->pdev->dev;
- dev_vdbg(host->dev, "DMA complete\n");
+ dev_vdbg(dev, "DMA complete\n");
host->dma_ops->cleanup(host);
@@ -420,10 +424,27 @@ static void dw_mci_idmac_start_dma(struct dw_mci *host,
unsigned int sg_len)
mci_writel(host, PLDMND, 1);
}
+static int dw_get_platform_device_id(struct dw_mci *host)
+{
+ int ctrl_id;
+ struct device *dev = &host->pdev->dev;
+
+ if (dev->of_node)
+ ctrl_id = of_alias_get_id(dev->of_node, "mshc");
+ else
+ ctrl_id = host->pdev->id;
+
+ if (ctrl_id < 0)
+ ctrl_id = 0;
+
+ return ctrl_id;
+}
+
static int dw_mci_idmac_init(struct dw_mci *host)
{
struct idmac_desc *p;
int i, dma_support;
+ struct device *dev = &host->pdev->dev;
/* Number of descriptors in the ring buffer */
host->ring_size = PAGE_SIZE / sizeof(struct idmac_desc);
@@ -431,14 +452,20 @@ static int dw_mci_idmac_init(struct dw_mci *host)
/* Check if Hardware Configuration Register has support for DMA */
dma_support = (mci_readl(host, HCON) >> 16) & 0x3;
- if (!dma_support || dma_support > 2) {
- dev_err(&host->dev,
+ /*
+* I
[PATCH V1] Add Quirk for Broken Configuration
This patch is based on the device tree support of dw_mmc host controller posted by Thomas Abraham. Below is the list of his patch in review stage mmc: dw_mmc: convert copy of struct device in struct dw_mci to a reference mmc: dw_mmc: allow probe to succeed even if one slot is initialized mmc: dw_mmc: lookup for optional biu and ciu clocks mmc: dw_mmc: add quirk to indicate missing write protect line mmc: dw_mmc: add device tree support mmc: dw_mmc: add samsung exynos5250 specific extentions Girish K S (1): mmc: dwmmc: Add quirk for broken Hardware Config drivers/mmc/host/dw_mmc-pltfm.c | 10 +++- drivers/mmc/host/dw_mmc.c | 151 --- drivers/mmc/host/dw_mmc.h |1 + include/linux/mmc/dw_mmc.h |4 +- 4 files changed, 107 insertions(+), 59 deletions(-) -- 1.7.4.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
[PATCH] mmc: dw_mmc: add busmode selection support
Synopsis Designware host controller has suppport for open
drain mode selection. During the mmc card initialization the
host controller can select the open-drain bit to allow the device
initialization in the open-drain mode. Once the device enters
the standby mode this bit can be reset to enter push-pull mode.
Signed-off-by: Girish K S
---
drivers/mmc/host/dw_mmc.c | 14 ++
drivers/mmc/host/dw_mmc.h |1 +
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 72dc3cd..da11e5a 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -773,6 +773,18 @@ static void dw_mci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
spin_unlock_bh(&host->lock);
}
+static void dw_mci_set_busmode(struct dw_mci_slot *slot)
+{
+ struct mmc_ios *ios = &slot->mmc->ios;
+ u32 reg;
+
+ reg = mci_readl(slot->host, CTRL);
+ if (ios->bus_mode == MMC_BUSMODE_OPENDRAIN)
+ mci_writel(slot->host, CTRL, reg | SDMMC_CTRL_ENABLE_OD);
+ else
+ mci_writel(slot->host, CTRL, reg & ~SDMMC_CTRL_ENABLE_OD);
+}
+
static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
{
struct dw_mci_slot *slot = mmc_priv(mmc);
@@ -818,6 +830,8 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
default:
break;
}
+
+ dw_mci_set_busmode(slot);
}
static int dw_mci_get_ro(struct mmc_host *mmc)
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 15c27e1..1a53fb2 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -67,6 +67,7 @@
/* Control register defines */
#define SDMMC_CTRL_USE_IDMAC BIT(25)
+#define SDMMC_CTRL_ENABLE_OD BIT(24)
#define SDMMC_CTRL_CEATA_INT_ENBIT(11)
#define SDMMC_CTRL_SEND_AS_CCSDBIT(10)
#define SDMMC_CTRL_SEND_CCSD BIT(9)
--
1.7.4.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 V1] mmc: dwmmc: Add quirk for broken Hardware Config
Any other feedback on this?
On 18 July 2012 14:08, Girish K S wrote:
> In some Soc'S that integrate Designware mmc host controllers, the
> HCON register is broken. The hardware configuration is not
> updated. One specific usecase is the IDMAC. In Exysons5 SoC
> there exist a internal DMA, but the HCON register's DMA_INTERFACE
> field is not set to indicate its existance.
>
> This quirk can be used in such case to force the existance broken
> HCON field.
>
> changes in v1:
> -modified the caps2 field access per controller index.Reported
> by Jaehoon Chung .
> -replaced the pointer to device with the pointer to platform
> device in struct dw_mci.
> -updated driver data for all 4 mmc controllers of exynos5 SoC.
> -added non device-tree support for ctrl_id access.
>
> Signed-off-by: Girish K S
> ---
> drivers/mmc/host/dw_mmc-pltfm.c | 10 +++-
> drivers/mmc/host/dw_mmc.c | 150
> ---
> drivers/mmc/host/dw_mmc.h |1 +
> include/linux/mmc/dw_mmc.h |2 +-
> include/linux/mmc/host.h|1 +
> 5 files changed, 106 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
> index 900f412..c8eb573 100644
> --- a/drivers/mmc/host/dw_mmc-pltfm.c
> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
> @@ -35,9 +35,17 @@ static unsigned long exynos5250_dwmmc_caps[4] = {
> MMC_CAP_CMD23,
> };
>
> +static unsigned long exynos5250_dwmmc_caps2[4] = {
> + MMC_CAP2_CONFIG_BROKEN,
> + MMC_CAP2_CONFIG_BROKEN,
> + MMC_CAP2_CONFIG_BROKEN,
> + MMC_CAP2_CONFIG_BROKEN,
> +};
> +
> static struct dw_mci_drv_data exynos5250_drv_data = {
> .ctrl_type = DW_MCI_TYPE_EXYNOS5250,
> .caps = exynos5250_dwmmc_caps,
> + .caps2 = exynos5250_dwmmc_caps2,
> };
>
> static const struct of_device_id dw_mci_pltfm_match[] = {
> @@ -74,7 +82,7 @@ static int dw_mci_pltfm_probe(struct platform_device *pdev)
> goto err_free;
> }
>
> - host->dev = &pdev->dev;
> + host->pdev = pdev;
> host->irq_flags = 0;
> host->pdata = pdev->dev.platform_data;
> ret = -ENOMEM;
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 000da16..fd9233d 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -283,8 +283,10 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc,
> struct mmc_command *cmd)
> static void dw_mci_start_command(struct dw_mci *host,
> struct mmc_command *cmd, u32 cmd_flags)
> {
> + struct device *dev = &host->pdev->dev;
> +
> host->cmd = cmd;
> - dev_vdbg(host->dev,
> + dev_vdbg(dev,
> "start command: ARGR=0x%08x CMDR=0x%08x\n",
> cmd->arg, cmd_flags);
>
> @@ -323,10 +325,11 @@ static int dw_mci_get_dma_dir(struct mmc_data *data)
> static void dw_mci_dma_cleanup(struct dw_mci *host)
> {
> struct mmc_data *data = host->data;
> + struct device *dev = &host->pdev->dev;
>
> if (data)
> if (!data->host_cookie)
> - dma_unmap_sg(host->dev,
> + dma_unmap_sg(dev,
> data->sg,
> data->sg_len,
> dw_mci_get_dma_dir(data));
> @@ -351,8 +354,9 @@ static void dw_mci_idmac_stop_dma(struct dw_mci *host)
> static void dw_mci_idmac_complete_dma(struct dw_mci *host)
> {
> struct mmc_data *data = host->data;
> + struct device *dev = &host->pdev->dev;
>
> - dev_vdbg(host->dev, "DMA complete\n");
> + dev_vdbg(dev, "DMA complete\n");
>
> host->dma_ops->cleanup(host);
>
> @@ -420,10 +424,27 @@ static void dw_mci_idmac_start_dma(struct dw_mci *host,
> unsigned int sg_len)
> mci_writel(host, PLDMND, 1);
> }
>
> +static int dw_get_platform_device_id(struct dw_mci *host)
> +{
> + int ctrl_id;
> + struct device *dev = &host->pdev->dev;
> +
> + if (dev->of_node)
> + ctrl_id = of_alias_get_id(dev->of_node, "mshc");
> + else
> + ctrl_id = host->pdev->id;
> +
> + if (ctrl_id < 0)
> + ctrl_id = 0;
> +
> + return ctrl_id;
> +}
> +
> static int dw_mci_idmac_init(struct dw_mci *host)
> {
>
Re: [PATCH V1] mmc: dwmmc: Add quirk for broken Hardware Config
On 18 July 2012 18:25, S, Venkatraman wrote:
> On Wed, Jul 18, 2012 at 2:08 PM, Girish K S
> wrote:
>> In some Soc'S that integrate Designware mmc host controllers, the
>> HCON register is broken. The hardware configuration is not
>> updated. One specific usecase is the IDMAC. In Exysons5 SoC
>> there exist a internal DMA, but the HCON register's DMA_INTERFACE
>> field is not set to indicate its existance.
>>
>> This quirk can be used in such case to force the existance broken
>> HCON field.
>>
>> changes in v1:
>> -modified the caps2 field access per controller index.Reported
>> by Jaehoon Chung .
>> -replaced the pointer to device with the pointer to platform
>> device in struct dw_mci.
>> -updated driver data for all 4 mmc controllers of exynos5 SoC.
>> -added non device-tree support for ctrl_id access.
>>
>> Signed-off-by: Girish K S
>> ---
>> drivers/mmc/host/dw_mmc-pltfm.c | 10 +++-
>> drivers/mmc/host/dw_mmc.c | 150
>> ---
>> drivers/mmc/host/dw_mmc.h |1 +
>> include/linux/mmc/dw_mmc.h |2 +-
>> include/linux/mmc/host.h|1 +
>> 5 files changed, 106 insertions(+), 58 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c
>> b/drivers/mmc/host/dw_mmc-pltfm.c
>> index 900f412..c8eb573 100644
>> --- a/drivers/mmc/host/dw_mmc-pltfm.c
>> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
>> @@ -35,9 +35,17 @@ static unsigned long exynos5250_dwmmc_caps[4] = {
>> MMC_CAP_CMD23,
>> };
>>
>> +static unsigned long exynos5250_dwmmc_caps2[4] = {
>> + MMC_CAP2_CONFIG_BROKEN,
>> + MMC_CAP2_CONFIG_BROKEN,
>> + MMC_CAP2_CONFIG_BROKEN,
>> + MMC_CAP2_CONFIG_BROKEN,
>> +};
>> +
>> static struct dw_mci_drv_data exynos5250_drv_data = {
>> .ctrl_type = DW_MCI_TYPE_EXYNOS5250,
>> .caps = exynos5250_dwmmc_caps,
>> + .caps2 = exynos5250_dwmmc_caps2,
>> };
>>
>> static const struct of_device_id dw_mci_pltfm_match[] = {
>> @@ -74,7 +82,7 @@ static int dw_mci_pltfm_probe(struct platform_device *pdev)
>> goto err_free;
>> }
>>
>> - host->dev = &pdev->dev;
>> + host->pdev = pdev;
>> host->irq_flags = 0;
>> host->pdata = pdev->dev.platform_data;
>> ret = -ENOMEM;
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 000da16..fd9233d 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -283,8 +283,10 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc,
>> struct mmc_command *cmd)
>> static void dw_mci_start_command(struct dw_mci *host,
>> struct mmc_command *cmd, u32 cmd_flags)
>> {
>> + struct device *dev = &host->pdev->dev;
>> +
>> host->cmd = cmd;
>> - dev_vdbg(host->dev,
>> + dev_vdbg(dev,
>> "start command: ARGR=0x%08x CMDR=0x%08x\n",
>> cmd->arg, cmd_flags);
>>
>> @@ -323,10 +325,11 @@ static int dw_mci_get_dma_dir(struct mmc_data *data)
>> static void dw_mci_dma_cleanup(struct dw_mci *host)
>> {
>> struct mmc_data *data = host->data;
>> + struct device *dev = &host->pdev->dev;
>>
>> if (data)
>> if (!data->host_cookie)
>> - dma_unmap_sg(host->dev,
>> + dma_unmap_sg(dev,
>> data->sg,
>> data->sg_len,
>> dw_mci_get_dma_dir(data));
>> @@ -351,8 +354,9 @@ static void dw_mci_idmac_stop_dma(struct dw_mci *host)
>> static void dw_mci_idmac_complete_dma(struct dw_mci *host)
>> {
>> struct mmc_data *data = host->data;
>> + struct device *dev = &host->pdev->dev;
>>
>> - dev_vdbg(host->dev, "DMA complete\n");
>> + dev_vdbg(dev, "DMA complete\n");
>>
>> host->dma_ops->cleanup(host);
>>
>> @@ -420,10 +424,27 @@ static void dw_mci_idmac_start_dma(struct dw_mci
>> *host, unsigned int sg_len)
>> mci_writel(host, PLDMND, 1);
>> }
>>
>> +static int dw_get_platform_device_id(struct dw_mci *host)
>> +{
>> + i
Re: [PATCH 2/2] mmc: sd: Fix sd current limit setting
DHCI_CAN_VDD_180) {
> - int max_current_180;
> -
> ocr_avail |= MMC_VDD_165_195;
>
> - max_current_180 = ((max_current_caps &
> + mmc->max_current_180 = ((max_current_caps &
>SDHCI_MAX_CURRENT_180_MASK) >>
>SDHCI_MAX_CURRENT_180_SHIFT) *
>SDHCI_MAX_CURRENT_MULTIPLIER;
> -
> - if (max_current_180 > 150)
> - mmc->caps |= MMC_CAP_SET_XPC_180;
> -
> - /* Maximum current capabilities of the host at 1.8V */
> - if (max_current_180 >= 800)
> - mmc->caps |= MMC_CAP_MAX_CURRENT_800_180;
> - else if (max_current_180 >= 600)
> - mmc->caps |= MMC_CAP_MAX_CURRENT_600_180;
> - else if (max_current_180 >= 400)
> - mmc->caps |= MMC_CAP_MAX_CURRENT_400_180;
> - else if (max_current_180 >= 200)
> - mmc->caps |= MMC_CAP_MAX_CURRENT_200_180;
> }
>
> mmc->ocr_avail = ocr_avail;
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index 79d8921..8d2c052 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -189,6 +189,9 @@ struct mmc_host {
> u32 ocr_avail_sd; /* SD-specific OCR */
> u32 ocr_avail_mmc; /* MMC-specific OCR */
> struct notifier_block pm_notify;
> + u32 max_current_330;
> + u32 max_current_300;
> + u32 max_current_180;
>
> #define MMC_VDD_165_1950x0080 /* VDD voltage 1.65 -
> 1.95 */
> #define MMC_VDD_20_21 0x0100 /* VDD voltage 2.0 ~ 2.1 */
> @@ -232,16 +235,9 @@ struct mmc_host {
> #define MMC_CAP_UHS_SDR50 (1 << 17) /* Host supports UHS SDR50
> mode */
> #define MMC_CAP_UHS_SDR104 (1 << 18) /* Host supports UHS SDR104
> mode */
> #define MMC_CAP_UHS_DDR50 (1 << 19) /* Host supports UHS DDR50
> mode */
> -#define MMC_CAP_SET_XPC_330(1 << 20) /* Host supports >150mA
> current at 3.3V */
> -#define MMC_CAP_SET_XPC_300(1 << 21) /* Host supports >150mA
> current at 3.0V */
> -#define MMC_CAP_SET_XPC_180(1 << 22) /* Host supports >150mA
> current at 1.8V */
> #define MMC_CAP_DRIVER_TYPE_A (1 << 23) /* Host supports Driver Type
> A */
> #define MMC_CAP_DRIVER_TYPE_C (1 << 24) /* Host supports Driver Type
> C */
> #define MMC_CAP_DRIVER_TYPE_D (1 << 25) /* Host supports Driver Type
> D */
> -#define MMC_CAP_MAX_CURRENT_200_180 (1 << 26) /* Host max current limit is
> 200mA at 1.8V */
> -#define MMC_CAP_MAX_CURRENT_400_180 (1 << 27) /* Host max current limit is
> 400mA at 1.8V */
> -#define MMC_CAP_MAX_CURRENT_600_180 (1 << 28) /* Host max current limit is
> 600mA at 1.8V */
> -#define MMC_CAP_MAX_CURRENT_800_180 (1 << 29) /* Host max current limit is
> 800mA at 1.8V */
> #define MMC_CAP_CMD23 (1 << 30) /* CMD23 supported. */
> #define MMC_CAP_HW_RESET (1 << 31) /* Hardware reset */
>
> @@ -261,14 +257,6 @@ struct mmc_host {
> #define MMC_CAP2_HC_ERASE_SZ (1 << 9)/* High-capacity erase size */
> #define MMC_CAP2_CD_ACTIVE_HIGH(1 << 10) /* Card-detect signal
> active high */
> #define MMC_CAP2_RO_ACTIVE_HIGH(1 << 11) /* Write-protect
> signal active high */
> -#define MMC_CAP_MAX_CURRENT_200_300 (1 << 12) /* Host max current limit is
> 200mA at 3.0V */
> -#define MMC_CAP_MAX_CURRENT_400_300 (1 << 13) /* Host max current limit is
> 400mA at 3.0V */
> -#define MMC_CAP_MAX_CURRENT_600_300 (1 << 14) /* Host max current limit is
> 600mA at 3.0V */
> -#define MMC_CAP_MAX_CURRENT_800_300 (1 << 15) /* Host max current limit is
> 800mA at 3.0V */
> -#define MMC_CAP_MAX_CURRENT_200_330 (1 << 16) /* Host max current limit is
> 200mA at 3.3V */
> -#define MMC_CAP_MAX_CURRENT_400_330 (1 << 17) /* Host max current limit is
> 400mA at 3.3V */
> -#define MMC_CAP_MAX_CURRENT_600_330 (1 << 18) /* Host max current limit is
> 600mA at 3.3V */
> -#define MMC_CAP_MAX_CURRENT_800_330 (1 << 19) /* Host max current limit is
> 800mA at 3.3V */
> #define MMC_CAP2_PACKED_RD (1 << 20) /* Allow packed read */
> #define MMC_CAP2_PACKED_WR (1 << 21) /* Allow packed write */
> #define MMC_CAP2_PACKED_CMD(MMC_CAP2_PACKED_RD | \
>
Looks like a better solution than earlier one.
Reviewed By: Girish K S
Chris,
How about the holes created by removal of caps2 macros. Will they be
adjusted to follow the sequence or left as it is for future use.
>
> Thanks,
> Aaron
>
--
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
[PATCH V1] mmc: dwmmc: Add quirk for broken Hardware Config
In some Soc'S that integrate Designware mmc host controllers, the
HCON register is broken. The hardware configuration is not
updated. One specific usecase is the IDMAC. In Exysons5 SoC
there exist a internal DMA, but the HCON register's DMA_INTERFACE
field is not set to indicate its existance.
This quirk can be used in such case to force the existance broken
HCON field.
changes in v1:
-modified the caps2 field access per controller index.Reported
by Jaehoon Chung .
-replaced the pointer to device with the pointer to platform
device in struct dw_mci.
-updated driver data for all 4 mmc controllers of exynos5 SoC.
-added non device-tree support for ctrl_id access.
Signed-off-by: Girish K S
---
drivers/mmc/host/dw_mmc-pltfm.c | 10 +++-
drivers/mmc/host/dw_mmc.c | 150 ---
drivers/mmc/host/dw_mmc.h |1 +
include/linux/mmc/dw_mmc.h |2 +-
include/linux/mmc/host.h|1 +
5 files changed, 106 insertions(+), 58 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index 900f412..c8eb573 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -35,9 +35,17 @@ static unsigned long exynos5250_dwmmc_caps[4] = {
MMC_CAP_CMD23,
};
+static unsigned long exynos5250_dwmmc_caps2[4] = {
+ MMC_CAP2_CONFIG_BROKEN,
+ MMC_CAP2_CONFIG_BROKEN,
+ MMC_CAP2_CONFIG_BROKEN,
+ MMC_CAP2_CONFIG_BROKEN,
+};
+
static struct dw_mci_drv_data exynos5250_drv_data = {
.ctrl_type = DW_MCI_TYPE_EXYNOS5250,
.caps = exynos5250_dwmmc_caps,
+ .caps2 = exynos5250_dwmmc_caps2,
};
static const struct of_device_id dw_mci_pltfm_match[] = {
@@ -74,7 +82,7 @@ static int dw_mci_pltfm_probe(struct platform_device *pdev)
goto err_free;
}
- host->dev = &pdev->dev;
+ host->pdev = pdev;
host->irq_flags = 0;
host->pdata = pdev->dev.platform_data;
ret = -ENOMEM;
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 000da16..fd9233d 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -283,8 +283,10 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc,
struct mmc_command *cmd)
static void dw_mci_start_command(struct dw_mci *host,
struct mmc_command *cmd, u32 cmd_flags)
{
+ struct device *dev = &host->pdev->dev;
+
host->cmd = cmd;
- dev_vdbg(host->dev,
+ dev_vdbg(dev,
"start command: ARGR=0x%08x CMDR=0x%08x\n",
cmd->arg, cmd_flags);
@@ -323,10 +325,11 @@ static int dw_mci_get_dma_dir(struct mmc_data *data)
static void dw_mci_dma_cleanup(struct dw_mci *host)
{
struct mmc_data *data = host->data;
+ struct device *dev = &host->pdev->dev;
if (data)
if (!data->host_cookie)
- dma_unmap_sg(host->dev,
+ dma_unmap_sg(dev,
data->sg,
data->sg_len,
dw_mci_get_dma_dir(data));
@@ -351,8 +354,9 @@ static void dw_mci_idmac_stop_dma(struct dw_mci *host)
static void dw_mci_idmac_complete_dma(struct dw_mci *host)
{
struct mmc_data *data = host->data;
+ struct device *dev = &host->pdev->dev;
- dev_vdbg(host->dev, "DMA complete\n");
+ dev_vdbg(dev, "DMA complete\n");
host->dma_ops->cleanup(host);
@@ -420,10 +424,27 @@ static void dw_mci_idmac_start_dma(struct dw_mci *host,
unsigned int sg_len)
mci_writel(host, PLDMND, 1);
}
+static int dw_get_platform_device_id(struct dw_mci *host)
+{
+ int ctrl_id;
+ struct device *dev = &host->pdev->dev;
+
+ if (dev->of_node)
+ ctrl_id = of_alias_get_id(dev->of_node, "mshc");
+ else
+ ctrl_id = host->pdev->id;
+
+ if (ctrl_id < 0)
+ ctrl_id = 0;
+
+ return ctrl_id;
+}
+
static int dw_mci_idmac_init(struct dw_mci *host)
{
struct idmac_desc *p;
- int i, dma_support;
+ int i, dma_support, ctrl_id;
+ struct device *dev = &host->pdev->dev;
/* Number of descriptors in the ring buffer */
host->ring_size = PAGE_SIZE / sizeof(struct idmac_desc);
@@ -431,14 +452,23 @@ static int dw_mci_idmac_init(struct dw_mci *host)
/* Check if Hardware Configuration Register has support for DMA */
dma_support = (mci_readl(host, HCON) >> 16) & 0x3;
- if (!dma_support || dma_support > 2) {
- dev_err(&host->dev,
+ /*
+* In Some of the Soc's the HCON Register is broken. Even though
[PATCH V1] Add Quirk for Broken Configuration
This patch is based on the device tree support of dw_mmc host controller posted by Thomas Abraham. Below is the list of his patch in review stage mmc: dw_mmc: convert copy of struct device in struct dw_mci to a reference mmc: dw_mmc: allow probe to succeed even if one slot is initialized mmc: dw_mmc: lookup for optional biu and ciu clocks mmc: dw_mmc: add quirk to indicate missing write protect line mmc: dw_mmc: add device tree support mmc: dw_mmc: add samsung exynos5250 specific extentions Girish K S (1): mmc: dwmmc: Add quirk for broken Hardware Config drivers/mmc/host/dw_mmc-pltfm.c | 10 +++- drivers/mmc/host/dw_mmc.c | 150 --- drivers/mmc/host/dw_mmc.h |1 + include/linux/mmc/dw_mmc.h |2 +- include/linux/mmc/host.h|1 + 5 files changed, 106 insertions(+), 58 deletions(-) -- 1.7.4.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: core: skip mmc_power_up call from start host
On 17 July 2012 16:22, S, Venkatraman wrote: > On Fri, Jul 13, 2012 at 6:27 PM, Girish K S > wrote: >> The call to the mmc_power_up during the mmc_start_host breaks the card >> detection in design-ware host controller. This patch removes the call to >> mmc_power_up function during host start. >> > Please explain why. Which commit introduced it ? dw_mmc card detection is broken by this commit fa5501890d8974301042e0202d342a6cbe8609f4 > >> This fix works fine with sdhci (sdhci compatilble host controller) >> and dw_mmc (design-ware host controller). and has no side effect due to >> this removal. >> > How can you be sure ? What about other hosts ? I have tested on the available host controllers. It would be helpful if others test it and let me know whether this change of mine causes any problem. -- 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: dwmmc: Add quirk for broken Hardware Config
On 17 July 2012 15:43, Jaehoon Chung wrote:
> Hi Girish..
>
> i tested with your patch and applied the device tree patch.
> But i found the didn't compare with the MMC_CAP2_CONFIG_BROKEN.
>
> I think that host->drv_data->caps2 just denote address.
> So if running the your code,
> Maybe it's compared like "0xc02a6e54 & 0x1000".
> Is it wrong?
i got your point
Thanks for pointing it.
>
> Best Regards,
> Jaehoon Chung
>
> On 07/17/2012 06:54 PM, Girish K S wrote:
>> On 17 July 2012 15:18, Jaehoon Chung wrote:
>>> On 07/17/2012 06:17 PM, Girish K S wrote:
>>>> On 17 July 2012 13:16, Jaehoon Chung wrote:
>>>>> Hi Girish,
>>>>>
>>>>> On 07/16/2012 05:45 PM, Girish K S wrote:
>>>>>> In some Soc'S that integrate Designware mmc host controllers, the
>>>>>> HCON register is broken. The hardware configuration is not
>>>>>> updated. One specific usecase is the IDMAC. In Exysons5 SoC
>>>>>> there exist a internal DMA, but the HCON register's DMA_INTERFACE
>>>>>> field is not set to indicate its existance.
>>>>>>
>>>>>> This quirk can be used in such case to force the existance broken
>>>>>> HCON field.
>>>>>>
>>>>>> Signed-off-by: Girish K S
>>>>>> ---
>>>>>> drivers/mmc/host/dw_mmc-pltfm.c |5 +
>>>>>> drivers/mmc/host/dw_mmc.c | 11 ++-
>>>>>> drivers/mmc/host/dw_mmc.h |1 +
>>>>>> include/linux/mmc/host.h|1 +
>>>>>> 4 files changed, 17 insertions(+), 1 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c
>>>>>> b/drivers/mmc/host/dw_mmc-pltfm.c
>>>>>> index 900f412..24ea485 100644
>>>>>> --- a/drivers/mmc/host/dw_mmc-pltfm.c
>>>>>> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
>>>>>> @@ -35,9 +35,14 @@ static unsigned long exynos5250_dwmmc_caps[4] = {
>>>>>> MMC_CAP_CMD23,
>>>>>> };
>>>>>>
>>>>>> +static unsigned long exynos5250_dwmmc_caps2[1] = {
>>>>>> + MMC_CAP2_CONFIG_BROKEN,
>>>>>> +};
>>>>>> +
>>>>>> static struct dw_mci_drv_data exynos5250_drv_data = {
>>>>>> .ctrl_type = DW_MCI_TYPE_EXYNOS5250,
>>>>>> .caps = exynos5250_dwmmc_caps,
>>>>>> + .caps2 = exynos5250_dwmmc_caps2,
>>>>>> };
>>>>>>
>>>>>> static const struct of_device_id dw_mci_pltfm_match[] = {
>>>>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>>>>> index 1a59a92..030224c 100644
>>>>>> --- a/drivers/mmc/host/dw_mmc.c
>>>>>> +++ b/drivers/mmc/host/dw_mmc.c
>>>>>> @@ -431,7 +431,13 @@ static int dw_mci_idmac_init(struct dw_mci *host)
>>>>>> /* Check if Hardware Configuration Register has support for DMA */
>>>>>> dma_support = (mci_readl(host, HCON) >> 16) & 0x3;
>>>>>>
>>>>>> - if (!dma_support || dma_support > 2) {
>>>>>> + /*
>>>>>> + * In Some of the Soc's the HCON Register is broken. Even though
>>>>>> the
>>>>>> + * Soc's has a internal DMA the HCON register's DMA field doesnt
>>>>>> + * show it. So additional quirk is added for such Soc's
>>>>>> + */
>>>>>> + if ((!dma_support || dma_support > 2) &&
>>>>>> + !((u32)host->drv_data->caps2 & MMC_CAP2_CONFIG_BROKEN)) {
>>>>> Just caps2? if use the device tree, need to get ctrl_id?
>>>> but i found one thing. I have initialized only one channel. are you
>>>> mentioning to initialize all 4 channels of exynos5
>>> You're defined "unsigned long *caps2"..host->drv_data->caps2?? what's value?
>>
>> .caps2 = exynos5250_dwmmc_caps2
>> and
>> static unsigned long exynos5250_dwmmc_caps2[1] = {
>>MMC_CAP2_CONFIG_BROKEN,
>> };
>> hope i answered it
>>>>> It didn't work..
>>>>>> dev_err(&host->dev,
>>>>>> "Host Cont
Re: [PATCH] mmc: dwmmc: Add quirk for broken Hardware Config
On 17 July 2012 13:16, Jaehoon Chung wrote:
> Hi Girish,
>
> On 07/16/2012 05:45 PM, Girish K S wrote:
>> In some Soc'S that integrate Designware mmc host controllers, the
>> HCON register is broken. The hardware configuration is not
>> updated. One specific usecase is the IDMAC. In Exysons5 SoC
>> there exist a internal DMA, but the HCON register's DMA_INTERFACE
>> field is not set to indicate its existance.
>>
>> This quirk can be used in such case to force the existance broken
>> HCON field.
>>
>> Signed-off-by: Girish K S
>> ---
>> drivers/mmc/host/dw_mmc-pltfm.c |5 +
>> drivers/mmc/host/dw_mmc.c | 11 ++-
>> drivers/mmc/host/dw_mmc.h |1 +
>> include/linux/mmc/host.h|1 +
>> 4 files changed, 17 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c
>> b/drivers/mmc/host/dw_mmc-pltfm.c
>> index 900f412..24ea485 100644
>> --- a/drivers/mmc/host/dw_mmc-pltfm.c
>> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
>> @@ -35,9 +35,14 @@ static unsigned long exynos5250_dwmmc_caps[4] = {
>> MMC_CAP_CMD23,
>> };
>>
>> +static unsigned long exynos5250_dwmmc_caps2[1] = {
>> + MMC_CAP2_CONFIG_BROKEN,
>> +};
>> +
>> static struct dw_mci_drv_data exynos5250_drv_data = {
>> .ctrl_type = DW_MCI_TYPE_EXYNOS5250,
>> .caps = exynos5250_dwmmc_caps,
>> + .caps2 = exynos5250_dwmmc_caps2,
>> };
>>
>> static const struct of_device_id dw_mci_pltfm_match[] = {
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 1a59a92..030224c 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -431,7 +431,13 @@ static int dw_mci_idmac_init(struct dw_mci *host)
>> /* Check if Hardware Configuration Register has support for DMA */
>> dma_support = (mci_readl(host, HCON) >> 16) & 0x3;
>>
>> - if (!dma_support || dma_support > 2) {
>> + /*
>> + * In Some of the Soc's the HCON Register is broken. Even though the
>> + * Soc's has a internal DMA the HCON register's DMA field doesnt
>> + * show it. So additional quirk is added for such Soc's
>> + */
>> + if ((!dma_support || dma_support > 2) &&
>> + !((u32)host->drv_data->caps2 & MMC_CAP2_CONFIG_BROKEN)) {
> Just caps2? if use the device tree, need to get ctrl_id?
did you mean host->drv_data->caps2[ctrl_id].
Sorry my mistake i ll change it
> It didn't work..
>> dev_err(&host->dev,
>> "Host Controller does not support IDMA Tx.\n");
>> host->dma_ops = NULL;
>> @@ -1957,6 +1963,9 @@ static int __init dw_mci_init_slot(struct dw_mci
>> *host, unsigned int id)
>> if (host->pdata->caps2)
>> mmc->caps2 = host->pdata->caps2;
>>
>> + if (host->drv_data->caps2)
>> + mmc->caps2 |= host->drv_data->caps2[ctrl_id];
>> +
>> if (host->pdata->get_bus_wd) {
>> if (host->pdata->get_bus_wd(slot->id) >= 4)
>> mmc->caps |= MMC_CAP_4_BIT_DATA;
>> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
>> index 6c17282..8c4810a 100644
>> --- a/drivers/mmc/host/dw_mmc.h
>> +++ b/drivers/mmc/host/dw_mmc.h
>> @@ -203,6 +203,7 @@ extern int dw_mci_resume(struct dw_mci *host);
>> struct dw_mci_drv_data {
>> unsigned long ctrl_type;
>> unsigned long *caps;
>> + unsigned long *caps2;
>> };
>>
>> #endif /* _DW_MMC_H_ */
>> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
>> index 65c64ee..ab5c7f9 100644
>> --- a/include/linux/mmc/host.h
>> +++ b/include/linux/mmc/host.h
>> @@ -261,6 +261,7 @@ struct mmc_host {
>> #define MMC_CAP2_HC_ERASE_SZ (1 << 9)/* High-capacity erase size */
>> #define MMC_CAP2_CD_ACTIVE_HIGH (1 << 10) /* Card-detect signal
>> active high */
>> #define MMC_CAP2_RO_ACTIVE_HIGH (1 << 11) /* Write-protect
>> signal active high */
>> +#define MMC_CAP2_CONFIG_BROKEN (1 << 12) /* Broken Config
>> Register */
>>
>> mmc_pm_flag_t pm_caps;/* supported pm features */
>> unsigned intpower_notify_type;
>>
>
>
--
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: dwmmc: Add quirk for broken Hardware Config
On 17 July 2012 15:18, Jaehoon Chung wrote:
> On 07/17/2012 06:17 PM, Girish K S wrote:
>> On 17 July 2012 13:16, Jaehoon Chung wrote:
>>> Hi Girish,
>>>
>>> On 07/16/2012 05:45 PM, Girish K S wrote:
>>>> In some Soc'S that integrate Designware mmc host controllers, the
>>>> HCON register is broken. The hardware configuration is not
>>>> updated. One specific usecase is the IDMAC. In Exysons5 SoC
>>>> there exist a internal DMA, but the HCON register's DMA_INTERFACE
>>>> field is not set to indicate its existance.
>>>>
>>>> This quirk can be used in such case to force the existance broken
>>>> HCON field.
>>>>
>>>> Signed-off-by: Girish K S
>>>> ---
>>>> drivers/mmc/host/dw_mmc-pltfm.c |5 +
>>>> drivers/mmc/host/dw_mmc.c | 11 ++-
>>>> drivers/mmc/host/dw_mmc.h |1 +
>>>> include/linux/mmc/host.h|1 +
>>>> 4 files changed, 17 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c
>>>> b/drivers/mmc/host/dw_mmc-pltfm.c
>>>> index 900f412..24ea485 100644
>>>> --- a/drivers/mmc/host/dw_mmc-pltfm.c
>>>> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
>>>> @@ -35,9 +35,14 @@ static unsigned long exynos5250_dwmmc_caps[4] = {
>>>> MMC_CAP_CMD23,
>>>> };
>>>>
>>>> +static unsigned long exynos5250_dwmmc_caps2[1] = {
>>>> + MMC_CAP2_CONFIG_BROKEN,
>>>> +};
>>>> +
>>>> static struct dw_mci_drv_data exynos5250_drv_data = {
>>>> .ctrl_type = DW_MCI_TYPE_EXYNOS5250,
>>>> .caps = exynos5250_dwmmc_caps,
>>>> + .caps2 = exynos5250_dwmmc_caps2,
>>>> };
>>>>
>>>> static const struct of_device_id dw_mci_pltfm_match[] = {
>>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>>> index 1a59a92..030224c 100644
>>>> --- a/drivers/mmc/host/dw_mmc.c
>>>> +++ b/drivers/mmc/host/dw_mmc.c
>>>> @@ -431,7 +431,13 @@ static int dw_mci_idmac_init(struct dw_mci *host)
>>>> /* Check if Hardware Configuration Register has support for DMA */
>>>> dma_support = (mci_readl(host, HCON) >> 16) & 0x3;
>>>>
>>>> - if (!dma_support || dma_support > 2) {
>>>> + /*
>>>> + * In Some of the Soc's the HCON Register is broken. Even though the
>>>> + * Soc's has a internal DMA the HCON register's DMA field doesnt
>>>> + * show it. So additional quirk is added for such Soc's
>>>> + */
>>>> + if ((!dma_support || dma_support > 2) &&
>>>> + !((u32)host->drv_data->caps2 & MMC_CAP2_CONFIG_BROKEN)) {
>>> Just caps2? if use the device tree, need to get ctrl_id?
>> but i found one thing. I have initialized only one channel. are you
>> mentioning to initialize all 4 channels of exynos5
> You're defined "unsigned long *caps2"..host->drv_data->caps2?? what's value?
.caps2 = exynos5250_dwmmc_caps2
and
static unsigned long exynos5250_dwmmc_caps2[1] = {
MMC_CAP2_CONFIG_BROKEN,
};
hope i answered it
>>> It didn't work..
>>>> dev_err(&host->dev,
>>>> "Host Controller does not support IDMA Tx.\n");
>>>> host->dma_ops = NULL;
>>>> @@ -1957,6 +1963,9 @@ static int __init dw_mci_init_slot(struct dw_mci
>>>> *host, unsigned int id)
>>>> if (host->pdata->caps2)
>>>> mmc->caps2 = host->pdata->caps2;
>>>>
>>>> + if (host->drv_data->caps2)
>>>> + mmc->caps2 |= host->drv_data->caps2[ctrl_id];
>>>> +
>>>> if (host->pdata->get_bus_wd) {
>>>> if (host->pdata->get_bus_wd(slot->id) >= 4)
>>>> mmc->caps |= MMC_CAP_4_BIT_DATA;
>>>> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
>>>> index 6c17282..8c4810a 100644
>>>> --- a/drivers/mmc/host/dw_mmc.h
>>>> +++ b/drivers/mmc/host/dw_mmc.h
>>>> @@ -203,6 +203,7 @@ extern int dw_mci_resume(struct dw_mci *host);
>>>> struct dw_mci_drv_data {
>>>> unsigned long ctrl_t
Re: [PATCH 2/2] mmc: sd: Fix sd current limit setting
On 3 July 2012 11:46, Aaron Lu wrote:
> Host has different current capabilities at different voltages, we need
> to record these settings seperately. Before set current limit for the sd
> card, find out the current voltage first and then find out the current
> capabilities of the host to set the limit.
>
> Signed-off-by: Aaron Lu
> ---
> drivers/mmc/core/sd.c| 58
> ++--
> drivers/mmc/host/sdhci.c | 28 +++
> include/linux/mmc/host.h | 16 +
> 3 files changed, 87 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
> index ae72d6e..4b4cf4d 100644
> --- a/drivers/mmc/core/sd.c
> +++ b/drivers/mmc/core/sd.c
> @@ -521,11 +521,39 @@ static int sd_set_current_limit(struct mmc_card *card,
> u8 *status)
> {
> int current_limit = SD_SET_CURRENT_NO_CHANGE;
> int err;
> + u8 voltage;
>
> /*
> * Current limit switch is only defined for SDR50, SDR104, and DDR50
> * bus speed modes. For other bus speed modes, we do not change the
> * current limit.
> +*/
> + if ((card->sd_bus_speed != UHS_SDR50_BUS_SPEED) &&
> + (card->sd_bus_speed != UHS_SDR104_BUS_SPEED) &&
> + (card->sd_bus_speed != UHS_DDR50_BUS_SPEED))
> + return 0;
> +
> + /*
> +* Host has different current capabilities when operating at
> +* different voltages, so find out the current voltage first.
> +*/
> + switch (1 << card->host->ios.vdd) {
> + case MMC_VDD_165_195:
> + voltage = 0; /* host's voltage is 1.8V */
> + break;
> + case MMC_VDD_29_30:
> + case MMC_VDD_30_31:
> + voltage = 1; /* host's voltage is 3.0V */
> + break;
> + case MMC_VDD_32_33:
> + case MMC_VDD_33_34:
> + voltage = 2; /* host's voltage is 3.3V */
> + break;
> + default:
> + BUG(); /* host's voltage is invalid */
> + }
> +
> + /*
> * We only check host's capability here, if we set a limit that is
> * higher than the card's maximum current, the card will be using its
> * maximum current, e.g. if the card's maximum current is 300ma, and
> @@ -533,16 +561,32 @@ static int sd_set_current_limit(struct mmc_card *card,
> u8 *status)
> * when we set current limit to 400/600/800ma, the card will draw its
> * maximum 300ma from the host.
> */
> - if ((card->sd_bus_speed == UHS_SDR50_BUS_SPEED) ||
> - (card->sd_bus_speed == UHS_SDR104_BUS_SPEED) ||
> - (card->sd_bus_speed == UHS_DDR50_BUS_SPEED)) {
> - if (card->host->caps & MMC_CAP_MAX_CURRENT_800)
> + if (voltage == 0) {
> + if (card->host->caps & MMC_CAP_MAX_CURRENT_800_180)
> + current_limit = SD_SET_CURRENT_LIMIT_800;
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_600_180)
> + current_limit = SD_SET_CURRENT_LIMIT_600;
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_400_180)
> + current_limit = SD_SET_CURRENT_LIMIT_400;
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_200_180)
> + current_limit = SD_SET_CURRENT_LIMIT_200;
> + } else if (voltage == 1) {
> + if (card->host->caps & MMC_CAP_MAX_CURRENT_800_300)
> + current_limit = SD_SET_CURRENT_LIMIT_800;
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_600_300)
> + current_limit = SD_SET_CURRENT_LIMIT_600;
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_400_300)
> + current_limit = SD_SET_CURRENT_LIMIT_400;
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_200_300)
> + current_limit = SD_SET_CURRENT_LIMIT_200;
> + } else if (voltage == 2) {
> + if (card->host->caps & MMC_CAP_MAX_CURRENT_800_330)
> current_limit = SD_SET_CURRENT_LIMIT_800;
> - else if (card->host->caps & MMC_CAP_MAX_CURRENT_600)
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_600_330)
> current_limit = SD_SET_CURRENT_LIMIT_600;
> - else if (card->host->caps & MMC_CAP_MAX_CURRENT_400)
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_400_330)
> current_limit = SD_SET_CURRENT_LIMIT_400;
> - else if (card->host->caps & MMC_CAP_MAX_CURRENT_200)
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_200_330)
> current_limit = SD_SET_CURRENT_LIMIT_200;
> }
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/hos
Re: [PATCH] mmc: dwmmc: Add quirk for broken Hardware Config
On 17 July 2012 13:16, Jaehoon Chung wrote:
> Hi Girish,
>
> On 07/16/2012 05:45 PM, Girish K S wrote:
>> In some Soc'S that integrate Designware mmc host controllers, the
>> HCON register is broken. The hardware configuration is not
>> updated. One specific usecase is the IDMAC. In Exysons5 SoC
>> there exist a internal DMA, but the HCON register's DMA_INTERFACE
>> field is not set to indicate its existance.
>>
>> This quirk can be used in such case to force the existance broken
>> HCON field.
>>
>> Signed-off-by: Girish K S
>> ---
>> drivers/mmc/host/dw_mmc-pltfm.c |5 +
>> drivers/mmc/host/dw_mmc.c | 11 ++-
>> drivers/mmc/host/dw_mmc.h |1 +
>> include/linux/mmc/host.h|1 +
>> 4 files changed, 17 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c
>> b/drivers/mmc/host/dw_mmc-pltfm.c
>> index 900f412..24ea485 100644
>> --- a/drivers/mmc/host/dw_mmc-pltfm.c
>> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
>> @@ -35,9 +35,14 @@ static unsigned long exynos5250_dwmmc_caps[4] = {
>> MMC_CAP_CMD23,
>> };
>>
>> +static unsigned long exynos5250_dwmmc_caps2[1] = {
>> + MMC_CAP2_CONFIG_BROKEN,
>> +};
>> +
>> static struct dw_mci_drv_data exynos5250_drv_data = {
>> .ctrl_type = DW_MCI_TYPE_EXYNOS5250,
>> .caps = exynos5250_dwmmc_caps,
>> + .caps2 = exynos5250_dwmmc_caps2,
>> };
>>
>> static const struct of_device_id dw_mci_pltfm_match[] = {
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 1a59a92..030224c 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -431,7 +431,13 @@ static int dw_mci_idmac_init(struct dw_mci *host)
>> /* Check if Hardware Configuration Register has support for DMA */
>> dma_support = (mci_readl(host, HCON) >> 16) & 0x3;
>>
>> - if (!dma_support || dma_support > 2) {
>> + /*
>> + * In Some of the Soc's the HCON Register is broken. Even though the
>> + * Soc's has a internal DMA the HCON register's DMA field doesnt
>> + * show it. So additional quirk is added for such Soc's
>> + */
>> + if ((!dma_support || dma_support > 2) &&
>> + !((u32)host->drv_data->caps2 & MMC_CAP2_CONFIG_BROKEN)) {
> Just caps2? if use the device tree, need to get ctrl_id?
but i found one thing. I have initialized only one channel. are you
mentioning to initialize all 4 channels of exynos5
> It didn't work..
>> dev_err(&host->dev,
>> "Host Controller does not support IDMA Tx.\n");
>> host->dma_ops = NULL;
>> @@ -1957,6 +1963,9 @@ static int __init dw_mci_init_slot(struct dw_mci
>> *host, unsigned int id)
>> if (host->pdata->caps2)
>> mmc->caps2 = host->pdata->caps2;
>>
>> + if (host->drv_data->caps2)
>> + mmc->caps2 |= host->drv_data->caps2[ctrl_id];
>> +
>> if (host->pdata->get_bus_wd) {
>> if (host->pdata->get_bus_wd(slot->id) >= 4)
>> mmc->caps |= MMC_CAP_4_BIT_DATA;
>> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
>> index 6c17282..8c4810a 100644
>> --- a/drivers/mmc/host/dw_mmc.h
>> +++ b/drivers/mmc/host/dw_mmc.h
>> @@ -203,6 +203,7 @@ extern int dw_mci_resume(struct dw_mci *host);
>> struct dw_mci_drv_data {
>> unsigned long ctrl_type;
>> unsigned long *caps;
>> + unsigned long *caps2;
>> };
>>
>> #endif /* _DW_MMC_H_ */
>> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
>> index 65c64ee..ab5c7f9 100644
>> --- a/include/linux/mmc/host.h
>> +++ b/include/linux/mmc/host.h
>> @@ -261,6 +261,7 @@ struct mmc_host {
>> #define MMC_CAP2_HC_ERASE_SZ (1 << 9)/* High-capacity erase size */
>> #define MMC_CAP2_CD_ACTIVE_HIGH (1 << 10) /* Card-detect signal
>> active high */
>> #define MMC_CAP2_RO_ACTIVE_HIGH (1 << 11) /* Write-protect
>> signal active high */
>> +#define MMC_CAP2_CONFIG_BROKEN (1 << 12) /* Broken Config
>> Register */
>>
>> mmc_pm_flag_t pm_caps;/* supported pm features */
>> unsigned intpower_notify_type;
>>
>
>
--
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: dwmmc: Add quirk for broken Hardware Config
On 17 July 2012 13:16, Jaehoon Chung wrote:
> Hi Girish,
>
> On 07/16/2012 05:45 PM, Girish K S wrote:
>> In some Soc'S that integrate Designware mmc host controllers, the
>> HCON register is broken. The hardware configuration is not
>> updated. One specific usecase is the IDMAC. In Exysons5 SoC
>> there exist a internal DMA, but the HCON register's DMA_INTERFACE
>> field is not set to indicate its existance.
>>
>> This quirk can be used in such case to force the existance broken
>> HCON field.
>>
>> Signed-off-by: Girish K S
>> ---
>> drivers/mmc/host/dw_mmc-pltfm.c |5 +
>> drivers/mmc/host/dw_mmc.c | 11 ++-
>> drivers/mmc/host/dw_mmc.h |1 +
>> include/linux/mmc/host.h|1 +
>> 4 files changed, 17 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c
>> b/drivers/mmc/host/dw_mmc-pltfm.c
>> index 900f412..24ea485 100644
>> --- a/drivers/mmc/host/dw_mmc-pltfm.c
>> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
>> @@ -35,9 +35,14 @@ static unsigned long exynos5250_dwmmc_caps[4] = {
>> MMC_CAP_CMD23,
>> };
>>
>> +static unsigned long exynos5250_dwmmc_caps2[1] = {
>> + MMC_CAP2_CONFIG_BROKEN,
>> +};
>> +
>> static struct dw_mci_drv_data exynos5250_drv_data = {
>> .ctrl_type = DW_MCI_TYPE_EXYNOS5250,
>> .caps = exynos5250_dwmmc_caps,
>> + .caps2 = exynos5250_dwmmc_caps2,
>> };
>>
>> static const struct of_device_id dw_mci_pltfm_match[] = {
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 1a59a92..030224c 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -431,7 +431,13 @@ static int dw_mci_idmac_init(struct dw_mci *host)
>> /* Check if Hardware Configuration Register has support for DMA */
>> dma_support = (mci_readl(host, HCON) >> 16) & 0x3;
>>
>> - if (!dma_support || dma_support > 2) {
>> + /*
>> + * In Some of the Soc's the HCON Register is broken. Even though the
>> + * Soc's has a internal DMA the HCON register's DMA field doesnt
>> + * show it. So additional quirk is added for such Soc's
>> + */
>> + if ((!dma_support || dma_support > 2) &&
>> + !((u32)host->drv_data->caps2 & MMC_CAP2_CONFIG_BROKEN)) {
> Just caps2? if use the device tree, need to get ctrl_id?
ctrl id is available for exynos5 in the parent structure of caps2.
I think device tree will be used to only get the platform related
information. The platform information that dwmmc expects is only the
compatible string.
The quirk information is part of the driver data. And the caps2 is
embedded inside the driver data.
In the above case. IDMAC init is called in probe for every instance of
the host controller.
> It didn't work..
I tested it for exynos5. There is no issue.
>> dev_err(&host->dev,
>> "Host Controller does not support IDMA Tx.\n");
>> host->dma_ops = NULL;
>> @@ -1957,6 +1963,9 @@ static int __init dw_mci_init_slot(struct dw_mci
>> *host, unsigned int id)
>> if (host->pdata->caps2)
>> mmc->caps2 = host->pdata->caps2;
>>
>> + if (host->drv_data->caps2)
>> + mmc->caps2 |= host->drv_data->caps2[ctrl_id];
>> +
>> if (host->pdata->get_bus_wd) {
>> if (host->pdata->get_bus_wd(slot->id) >= 4)
>> mmc->caps |= MMC_CAP_4_BIT_DATA;
>> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
>> index 6c17282..8c4810a 100644
>> --- a/drivers/mmc/host/dw_mmc.h
>> +++ b/drivers/mmc/host/dw_mmc.h
>> @@ -203,6 +203,7 @@ extern int dw_mci_resume(struct dw_mci *host);
>> struct dw_mci_drv_data {
>> unsigned long ctrl_type;
>> unsigned long *caps;
>> + unsigned long *caps2;
>> };
>>
>> #endif /* _DW_MMC_H_ */
>> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
>> index 65c64ee..ab5c7f9 100644
>> --- a/include/linux/mmc/host.h
>> +++ b/include/linux/mmc/host.h
>> @@ -261,6 +261,7 @@ struct mmc_host {
>> #define MMC_CAP2_HC_ERASE_SZ (1 << 9)/* High-capacity erase size */
>> #define MMC_CAP2_CD_ACTIVE_HIGH (1 << 10) /* Card-detect signal
>> active high */
>> #define MMC_CAP2_RO_ACTIVE_HIGH (1 << 11) /* Write-protect
>> signal active high */
>> +#define MMC_CAP2_CONFIG_BROKEN (1 << 12) /* Broken Config
>> Register */
>>
>> mmc_pm_flag_t pm_caps;/* supported pm features */
>> unsigned intpower_notify_type;
>>
>
>
--
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: dwmmc: Add quirk for broken Hardware Config
On 16 July 2012 14:15, Girish K S wrote:
> In some Soc'S that integrate Designware mmc host controllers, the
> HCON register is broken. The hardware configuration is not
> updated. One specific usecase is the IDMAC. In Exysons5 SoC
> there exist a internal DMA, but the HCON register's DMA_INTERFACE
> field is not set to indicate its existance.
>
> This quirk can be used in such case to force the existance broken
> HCON field.
>
> Signed-off-by: Girish K S
> ---
This patch is based on Thomas Abraham's patch series for device tree support
> drivers/mmc/host/dw_mmc-pltfm.c |5 +
> drivers/mmc/host/dw_mmc.c | 11 ++-
> drivers/mmc/host/dw_mmc.h |1 +
> include/linux/mmc/host.h|1 +
> 4 files changed, 17 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
> index 900f412..24ea485 100644
> --- a/drivers/mmc/host/dw_mmc-pltfm.c
> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
> @@ -35,9 +35,14 @@ static unsigned long exynos5250_dwmmc_caps[4] = {
> MMC_CAP_CMD23,
> };
>
> +static unsigned long exynos5250_dwmmc_caps2[1] = {
> + MMC_CAP2_CONFIG_BROKEN,
> +};
> +
> static struct dw_mci_drv_data exynos5250_drv_data = {
> .ctrl_type = DW_MCI_TYPE_EXYNOS5250,
> .caps = exynos5250_dwmmc_caps,
> + .caps2 = exynos5250_dwmmc_caps2,
> };
>
> static const struct of_device_id dw_mci_pltfm_match[] = {
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 1a59a92..030224c 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -431,7 +431,13 @@ static int dw_mci_idmac_init(struct dw_mci *host)
> /* Check if Hardware Configuration Register has support for DMA */
> dma_support = (mci_readl(host, HCON) >> 16) & 0x3;
>
> - if (!dma_support || dma_support > 2) {
> + /*
> +* In Some of the Soc's the HCON Register is broken. Even though the
> +* Soc's has a internal DMA the HCON register's DMA field doesnt
> +* show it. So additional quirk is added for such Soc's
> +*/
> + if ((!dma_support || dma_support > 2) &&
> + !((u32)host->drv_data->caps2 & MMC_CAP2_CONFIG_BROKEN)) {
> dev_err(&host->dev,
> "Host Controller does not support IDMA Tx.\n");
> host->dma_ops = NULL;
> @@ -1957,6 +1963,9 @@ static int __init dw_mci_init_slot(struct dw_mci *host,
> unsigned int id)
> if (host->pdata->caps2)
> mmc->caps2 = host->pdata->caps2;
>
> + if (host->drv_data->caps2)
> + mmc->caps2 |= host->drv_data->caps2[ctrl_id];
> +
> if (host->pdata->get_bus_wd) {
> if (host->pdata->get_bus_wd(slot->id) >= 4)
> mmc->caps |= MMC_CAP_4_BIT_DATA;
> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
> index 6c17282..8c4810a 100644
> --- a/drivers/mmc/host/dw_mmc.h
> +++ b/drivers/mmc/host/dw_mmc.h
> @@ -203,6 +203,7 @@ extern int dw_mci_resume(struct dw_mci *host);
> struct dw_mci_drv_data {
> unsigned long ctrl_type;
> unsigned long *caps;
> + unsigned long *caps2;
> };
>
> #endif /* _DW_MMC_H_ */
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index 65c64ee..ab5c7f9 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -261,6 +261,7 @@ struct mmc_host {
> #define MMC_CAP2_HC_ERASE_SZ (1 << 9)/* High-capacity erase size */
> #define MMC_CAP2_CD_ACTIVE_HIGH(1 << 10) /* Card-detect signal
> active high */
> #define MMC_CAP2_RO_ACTIVE_HIGH(1 << 11) /* Write-protect
> signal active high */
> +#define MMC_CAP2_CONFIG_BROKEN (1 << 12) /* Broken Config Register */
>
> mmc_pm_flag_t pm_caps;/* supported pm features */
> unsigned intpower_notify_type;
> --
> 1.7.4.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
[PATCH] mmc: dwmmc: Add quirk for broken Hardware Config
In some Soc'S that integrate Designware mmc host controllers, the
HCON register is broken. The hardware configuration is not
updated. One specific usecase is the IDMAC. In Exysons5 SoC
there exist a internal DMA, but the HCON register's DMA_INTERFACE
field is not set to indicate its existance.
This quirk can be used in such case to force the existance broken
HCON field.
Signed-off-by: Girish K S
---
drivers/mmc/host/dw_mmc-pltfm.c |5 +
drivers/mmc/host/dw_mmc.c | 11 ++-
drivers/mmc/host/dw_mmc.h |1 +
include/linux/mmc/host.h|1 +
4 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index 900f412..24ea485 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -35,9 +35,14 @@ static unsigned long exynos5250_dwmmc_caps[4] = {
MMC_CAP_CMD23,
};
+static unsigned long exynos5250_dwmmc_caps2[1] = {
+ MMC_CAP2_CONFIG_BROKEN,
+};
+
static struct dw_mci_drv_data exynos5250_drv_data = {
.ctrl_type = DW_MCI_TYPE_EXYNOS5250,
.caps = exynos5250_dwmmc_caps,
+ .caps2 = exynos5250_dwmmc_caps2,
};
static const struct of_device_id dw_mci_pltfm_match[] = {
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1a59a92..030224c 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -431,7 +431,13 @@ static int dw_mci_idmac_init(struct dw_mci *host)
/* Check if Hardware Configuration Register has support for DMA */
dma_support = (mci_readl(host, HCON) >> 16) & 0x3;
- if (!dma_support || dma_support > 2) {
+ /*
+* In Some of the Soc's the HCON Register is broken. Even though the
+* Soc's has a internal DMA the HCON register's DMA field doesnt
+* show it. So additional quirk is added for such Soc's
+*/
+ if ((!dma_support || dma_support > 2) &&
+ !((u32)host->drv_data->caps2 & MMC_CAP2_CONFIG_BROKEN)) {
dev_err(&host->dev,
"Host Controller does not support IDMA Tx.\n");
host->dma_ops = NULL;
@@ -1957,6 +1963,9 @@ static int __init dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
if (host->pdata->caps2)
mmc->caps2 = host->pdata->caps2;
+ if (host->drv_data->caps2)
+ mmc->caps2 |= host->drv_data->caps2[ctrl_id];
+
if (host->pdata->get_bus_wd) {
if (host->pdata->get_bus_wd(slot->id) >= 4)
mmc->caps |= MMC_CAP_4_BIT_DATA;
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 6c17282..8c4810a 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -203,6 +203,7 @@ extern int dw_mci_resume(struct dw_mci *host);
struct dw_mci_drv_data {
unsigned long ctrl_type;
unsigned long *caps;
+ unsigned long *caps2;
};
#endif /* _DW_MMC_H_ */
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 65c64ee..ab5c7f9 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -261,6 +261,7 @@ struct mmc_host {
#define MMC_CAP2_HC_ERASE_SZ (1 << 9)/* High-capacity erase size */
#define MMC_CAP2_CD_ACTIVE_HIGH(1 << 10) /* Card-detect signal
active high */
#define MMC_CAP2_RO_ACTIVE_HIGH(1 << 11) /* Write-protect signal
active high */
+#define MMC_CAP2_CONFIG_BROKEN (1 << 12) /* Broken Config Register */
mmc_pm_flag_t pm_caps;/* supported pm features */
unsigned intpower_notify_type;
--
1.7.4.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 v3 5/6] mmc: dw_mmc: add device tree support
On 16 July 2012 09:45, Girish K S wrote: > On 12 July 2012 18:24, Thomas Abraham wrote: >> Add device tree based discovery support. >> >> Signed-off-by: Thomas Abraham >> --- >> .../devicetree/bindings/mmc/synposis-dw-mshc.txt | 108 +++ >> drivers/mmc/host/dw_mmc-pltfm.c| 24 +++ >> drivers/mmc/host/dw_mmc.c | 201 >> +++- >> drivers/mmc/host/dw_mmc.h |9 + >> include/linux/mmc/dw_mmc.h |2 + >> 5 files changed, 338 insertions(+), 6 deletions(-) >> create mode 100644 >> Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt >> >> diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt >> b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt >> new file mode 100644 >> index 000..3acd6c9 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt >> @@ -0,0 +1,108 @@ >> +* Synopsis Designware Mobile Storage Host Controller >> + >> +The Synopsis designware mobile storage host controller is used to interface >> +a SoC with storage medium such as eMMC or SD/MMC cards. >> + >> +Required Properties: >> + >> +* compatible: should be one of the following >> + - snps,dw-mshc: for controllers compliant with synopsis dw-mshc. >> + >> +* reg: physical base address of the dw-mshc controller and size of its >> memory >> + region. >> + >> +* interrupts: interrupt specifier for the controller. The format and value >> of >> + the interrupt specifier depends on the interrupt parent for the >> controller. >> + >> +* #address-cells: should be 1. >> + >> +* #size-cells: should be 0. >> + >> +# Slots: The slot specific information are contained within child-nodes with >> + each child-node representing a supported slot. There should be atleast one >> + child node representing a card slot. The name of the child node >> representing >> + the slot is recommended to be slot@n where n is the unique number of the >> slot >> + connnected to the controller. The following are optional properties which >> + can be included in the slot child node. >> + >> + * reg: specifies the physical slot number. The valid values of this >> + property is 0 to (num-slots -1), where num-slots is the value >> + specified by the num-slots property. >> + >> + * bus-width: specifies the width of the data bus connected from the >> + controller to the card slot. The value should be 1, 4 or 8. In case >> + this property is not specified, a default value of 1 is assumed for >> + this property. >> + >> + * cd-gpios: specifies the card detect gpio line. The format of the >> + gpio specifier depends on the gpio controller. >> + >> + * wp-gpios: specifies the write protect gpio line. The format of the >> + gpio specifier depends on the gpio controller. >> + >> + * gpios: specifies a list of gpios used for command, clock and data >> + bus. The first gpio is the command line and the second gpio is the >> + clock line. The rest of the gpios (depending on the bus-width >> + property) are the data lines in no particular order. The format of >> + the gpio specifier depends on the gpio controller. >> + >> +Optional properties: >> + >> +* num-slots: specifies the number of slots supported by the controller. >> + The number of physical slots actually used could be equal or less than the >> + value specified by num-slots. If this property is not specified, the value >> + of num-slot property is assumed to be 1. >> + >> +* fifo-depth: The maximum size of the tx/rx fifo's. If this property is not >> + specified, the default value of the fifo size is determined from the >> + controller registers. >> + >> +* card-detect-delay: Delay in milli-seconds before detecting card after card >> + insert event. The default value is 0. >> + >> +* supports-highspeed: Enables support for high speed cards (upto 50MHz) >> + >> +* card-detection-broken: The card detection functionality is not available >> on >> + any of the slots. >> + >> +* no-write-protect: The write protect pad of the controller is not connected >> + to the write protect pin on the slot. >> + >> +Aliases: >> + >> +- All the MSHC controller nodes should be represented in the aliases node >&
Re: [PATCH v3 5/6] mmc: dw_mmc: add device tree support
On 12 July 2012 18:24, Thomas Abraham wrote:
> Add device tree based discovery support.
>
> Signed-off-by: Thomas Abraham
> ---
> .../devicetree/bindings/mmc/synposis-dw-mshc.txt | 108 +++
> drivers/mmc/host/dw_mmc-pltfm.c| 24 +++
> drivers/mmc/host/dw_mmc.c | 201
> +++-
> drivers/mmc/host/dw_mmc.h |9 +
> include/linux/mmc/dw_mmc.h |2 +
> 5 files changed, 338 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
> b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
> new file mode 100644
> index 000..3acd6c9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
> @@ -0,0 +1,108 @@
> +* Synopsis Designware Mobile Storage Host Controller
> +
> +The Synopsis designware mobile storage host controller is used to interface
> +a SoC with storage medium such as eMMC or SD/MMC cards.
> +
> +Required Properties:
> +
> +* compatible: should be one of the following
> + - snps,dw-mshc: for controllers compliant with synopsis dw-mshc.
> +
> +* reg: physical base address of the dw-mshc controller and size of its memory
> + region.
> +
> +* interrupts: interrupt specifier for the controller. The format and value of
> + the interrupt specifier depends on the interrupt parent for the controller.
> +
> +* #address-cells: should be 1.
> +
> +* #size-cells: should be 0.
> +
> +# Slots: The slot specific information are contained within child-nodes with
> + each child-node representing a supported slot. There should be atleast one
> + child node representing a card slot. The name of the child node
> representing
> + the slot is recommended to be slot@n where n is the unique number of the
> slot
> + connnected to the controller. The following are optional properties which
> + can be included in the slot child node.
> +
> + * reg: specifies the physical slot number. The valid values of this
> + property is 0 to (num-slots -1), where num-slots is the value
> + specified by the num-slots property.
> +
> + * bus-width: specifies the width of the data bus connected from the
> + controller to the card slot. The value should be 1, 4 or 8. In case
> + this property is not specified, a default value of 1 is assumed for
> + this property.
> +
> + * cd-gpios: specifies the card detect gpio line. The format of the
> + gpio specifier depends on the gpio controller.
> +
> + * wp-gpios: specifies the write protect gpio line. The format of the
> + gpio specifier depends on the gpio controller.
> +
> + * gpios: specifies a list of gpios used for command, clock and data
> + bus. The first gpio is the command line and the second gpio is the
> + clock line. The rest of the gpios (depending on the bus-width
> + property) are the data lines in no particular order. The format of
> + the gpio specifier depends on the gpio controller.
> +
> +Optional properties:
> +
> +* num-slots: specifies the number of slots supported by the controller.
> + The number of physical slots actually used could be equal or less than the
> + value specified by num-slots. If this property is not specified, the value
> + of num-slot property is assumed to be 1.
> +
> +* fifo-depth: The maximum size of the tx/rx fifo's. If this property is not
> + specified, the default value of the fifo size is determined from the
> + controller registers.
> +
> +* card-detect-delay: Delay in milli-seconds before detecting card after card
> + insert event. The default value is 0.
> +
> +* supports-highspeed: Enables support for high speed cards (upto 50MHz)
> +
> +* card-detection-broken: The card detection functionality is not available on
> + any of the slots.
> +
> +* no-write-protect: The write protect pad of the controller is not connected
> + to the write protect pin on the slot.
> +
> +Aliases:
> +
> +- All the MSHC controller nodes should be represented in the aliases node
> using
> + the following format 'mshc{n}' where n is a unique number for the alias.
> +
> +
> +Example:
> +
> + The MSHC controller node can be split into two portions, SoC specific and
> + board specific portions as listed below.
> +
> + dwmmc0@1220 {
> + compatible = "snps,dw-mshc";
> + reg = <0x1220 0x1000>;
> + interrupts = <0 75 0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + dwmmc0@1220 {
> + num-slots = <1>;
> + supports-highspeed;
> + card-detection-broken;
> + no-write-protect;
> + fifo-depth = <0x80>;
> + card-detect-delay = <200>;
> +
> +
[PATCH] mmc: core: skip mmc_power_up call from start host
The call to the mmc_power_up during the mmc_start_host breaks the card
detection in design-ware host controller. This patch removes the call to
mmc_power_up function during host start.
This fix works fine with sdhci (sdhci compatilble host controller)
and dw_mmc (design-ware host controller). and has no side effect due to
this removal.
Tested on : origen-board and smdk-5250 board.
Signed-off-by: Girish K S
Cc: Ulf Hansson
---
drivers/mmc/core/core.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 9503cab..503aefc 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2108,7 +2108,6 @@ void mmc_start_host(struct mmc_host *host)
{
host->f_init = max(freqs[0], host->f_min);
host->rescan_disable = 0;
- mmc_power_up(host);
mmc_detect_change(host, 0);
}
--
1.7.4.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 v3 3/6] mmc: dw_mmc: lookup for optional biu and ciu clocks
On 12 July 2012 18:24, Thomas Abraham wrote:
> Some platforms allow for clock gating and control of bus interface unit clock
> and card interface unit clock. Add support for clock lookup of optional biu
> and ciu clocks for clock gating and clock speed determination.
>
> Signed-off-by: Abhilash Kesavan
> Signed-off-by: Thomas Abraham
> ---
> drivers/mmc/host/dw_mmc.c | 42 +++---
> include/linux/mmc/dw_mmc.h |4
> 2 files changed, 43 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index cd58063..679473c 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1953,18 +1953,38 @@ int dw_mci_probe(struct dw_mci *host)
> return -ENODEV;
> }
>
> - if (!host->pdata->bus_hz) {
> + host->biu_clk = clk_get(host->dev, "biu");
> + if (IS_ERR(host->biu_clk))
> + dev_dbg(host->dev, "biu clock not available\n");
> + else
> + clk_prepare_enable(host->biu_clk);
> +
> + host->ciu_clk = clk_get(host->dev, "ciu");
> + if (IS_ERR(host->ciu_clk))
> + dev_dbg(host->dev, "ciu clock not available\n");
> + else
> + clk_prepare_enable(host->ciu_clk);
> +
> + if (IS_ERR(host->ciu_clk))
> + host->bus_hz = host->pdata->bus_hz;
> + else
> + host->bus_hz = clk_get_rate(host->ciu_clk);
> +
> + if (!host->bus_hz) {
> dev_err(host->dev,
> "Platform data must supply bus speed\n");
> - return -ENODEV;
> + ret = -ENODEV;
> + goto err_clk;
> }
>
> - host->bus_hz = host->pdata->bus_hz;
> host->quirks = host->pdata->quirks;
>
> spin_lock_init(&host->lock);
> INIT_LIST_HEAD(&host->queue);
>
> + host->dma_ops = host->pdata->dma_ops;
> + dw_mci_init_dma(host);
This initialization is already done.
> +
> /*
> * Get the host data width - this assumes that HCON has been set with
> * the correct values.
> @@ -2109,6 +2129,16 @@ err_dmaunmap:
> regulator_disable(host->vmmc);
> regulator_put(host->vmmc);
> }
> +
> +err_clk:
> + if (!IS_ERR(host->ciu_clk)) {
> + clk_disable_unprepare(host->ciu_clk);
> + clk_put(host->ciu_clk);
> + }
> + if (!IS_ERR(host->biu_clk)) {
> + clk_disable_unprepare(host->biu_clk);
> + clk_put(host->biu_clk);
> + }
> return ret;
> }
> EXPORT_SYMBOL(dw_mci_probe);
> @@ -2142,6 +2172,12 @@ void dw_mci_remove(struct dw_mci *host)
> regulator_put(host->vmmc);
> }
>
> + if (!IS_ERR(host->ciu_clk))
> + clk_disable_unprepare(host->ciu_clk);
> + if (!IS_ERR(host->biu_clk))
> + clk_disable_unprepare(host->biu_clk);
> + clk_put(host->ciu_clk);
> + clk_put(host->biu_clk);
> }
> EXPORT_SYMBOL(dw_mci_remove);
>
> diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
> index a37a573..787ad56 100644
> --- a/include/linux/mmc/dw_mmc.h
> +++ b/include/linux/mmc/dw_mmc.h
> @@ -78,6 +78,8 @@ struct mmc_data;
> * @data_offset: Set the offset of DATA register according to VERID.
> * @dev: Device associated with the MMC controller.
> * @pdata: Platform data associated with the MMC controller.
> + * @biu_clk: Pointer to bus interface unit clock instance.
> + * @ciu_clk: Pointer to card interface unit clock instance.
> * @slot: Slots sharing this MMC controller.
> * @fifo_depth: depth of FIFO.
> * @data_shift: log2 of FIFO item size.
> @@ -158,6 +160,8 @@ struct dw_mci {
> u16 data_offset;
> struct device *dev;
> struct dw_mci_board *pdata;
> + struct clk *biu_clk;
> + struct clk *ciu_clk;
> struct dw_mci_slot *slot[MAX_MCI_SLOTS];
>
> /* FIFO push and pull */
> --
> 1.6.6.rc2
>
> --
> 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] mmc: dw-mmc: retry to send when inform ciu
On 13 July 2012 09:28, Jaehoon Chung wrote:
> As DesignWare spec, when inform ciu, waiting for clearing start_bit
> or HLE is set. In case of HLE, repeat the command.
>
> Before the patch, repeat the below message.
> mmc_host mmc0: Timeout sending command (cmd 0x202000 arg 0x0 status
> 0x80202000)
> If this message is produced, repeat the send command during 10 times.
I dont understand what the above message. its not clear. can you
please explain it
>
> Signed-off-by: Jaehoon Chung
> Signed-off-by: Kyungmin Park
> ---
> drivers/mmc/host/dw_mmc.c | 39 +++
> 1 files changed, 31 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 72dc3cd..bec1a67 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -603,7 +603,7 @@ static void dw_mci_submit_data(struct dw_mci *host,
> struct mmc_data *data)
> }
> }
>
> -static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg)
> +static int mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg)
> {
> struct dw_mci *host = slot->host;
> unsigned long timeout = jiffies + msecs_to_jiffies(500);
> @@ -616,11 +616,37 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32
> cmd, u32 arg)
> while (time_before(jiffies, timeout)) {
> cmd_status = mci_readl(host, CMD);
> if (!(cmd_status & SDMMC_CMD_START))
> - return;
> + return 0;
> }
> dev_err(&slot->mmc->class_dev,
> "Timeout sending command (cmd %#x arg %#x status %#x)\n",
> cmd, arg, cmd_status);
> +
> + return -ETIMEDOUT;
> +}
> +
> +static void dw_mci_inform_ciu(struct dw_mci_slot *slot)
> +{
> + struct dw_mci *host = slot->host;
> + unsigned long retry = 10;
> + int ret;
> + u32 ctrl;
> +
> + while (1) {
> + ret = mci_send_cmd(slot,
> +SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0);
> + if (!ret)
> + break;
the returned error type is timeout. Is it not necessary to read and
check the HLE bit here before resending.
> + ctrl = mci_readl(host, CTRL);
> + ctrl |= SDMMC_CTRL_RESET;
> + mci_writel(host, CTRL, ctrl);
> +
> + if (retry-- == 0) {
> + dev_err(&slot->mmc->class_dev,"Timeout inform CIU\n");
> + break;
> + } else
> + dev_info(&slot->mmc->class_dev,"Retry send
> command\n");
> + }
> }
>
> static void dw_mci_setup_bus(struct dw_mci_slot *slot)
> @@ -649,23 +675,20 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot)
> mci_writel(host, CLKSRC, 0);
>
> /* inform CIU */
> - mci_send_cmd(slot,
> -SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0);
> + dw_mci_inform_ciu(slot);
>
> /* 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);
> + dw_mci_inform_ciu(slot);
>
> /* enable clock */
> mci_writel(host, CLKENA, ((SDMMC_CLKEN_ENABLE |
>SDMMC_CLKEN_LOW_PWR) << slot->id));
>
> /* inform CIU */
> - mci_send_cmd(slot,
> -SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0);
> + dw_mci_inform_ciu(slot);
>
> host->current_speed = slot->clock;
> }
> --
> 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] mmc: core: Prevent eMMC VCC supply to be cut from late init
On 10 July 2012 23:02, Chris Ball wrote:
> Hi,
>
> On Tue, Jul 10 2012, Girish K S wrote:
>>> @@ -2063,7 +2074,8 @@ void mmc_rescan(struct work_struct *work)
>>>
>>> void mmc_start_host(struct mmc_host *host)
>>> {
>>> - mmc_power_off(host);
>>> + host->f_init = max(freqs[0], host->f_min);
>>> + mmc_power_up(host);
>>> mmc_detect_change(host, 0);
>>> }
>>>
>> sorry to comment late on this.
>> This patch breaks the card detect with the designware host controller.
>> Anybody using the same host controller please let me know.
>> The problem is caused by the power_up call from the mmc_start_host
>> function. If i comment this powerup then card detect is fine
>
> Thanks. Ulf, sounds like we should revert this for 3.5-rc (which would
> have to happen soon) while we investigate; let me know what you think.
power_up function in the mmc_start_host can be completely omitted as
it will be anyway called in the mmc_detect_change.
I will test this change on the available host controllers and will
publish the result. If this removal doesnt cause any side affect, will
post it as a patch.
Ulf,
waiting for your comments on the same
>
> - Chris.
> --
> Chris Ball <http://printf.net/>
> One Laptop Per Child
> --
> 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] mmc: core: Prevent eMMC VCC supply to be cut from late init
On 9 May 2012 19:45, Ulf Hansson wrote:
> From: Ulf Hansson
>
> For eMMC cards that has been initialized from a bootloader,
> the VCC voltage supply must not be cut in an uncontrolled
> manner, without first sending SLEEP or POWEROFF_NOTIFY.
>
> The regulator_init_complete late initcall, may cut the VCC
> regulator if it's reference counter is zero. To be able to
> prevent the regulator from being cut, mmc_start_host, which
> should execute at device init and thus before late init,
> calls mmc_power_up. Then the host driver is able to increase
> the reference to the regulator.
>
> Signed-off-by: Ulf Hansson
> ---
> drivers/mmc/core/core.c | 18 +++---
> 1 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index ba821fe..0b6141d 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -42,6 +42,7 @@
> #include "sdio_ops.h"
>
> static struct workqueue_struct *workqueue;
> +static const unsigned freqs[] = { 40, 30, 20, 10 };
>
> /*
> * Enabling software CRCs on the data blocks can be a significant (30%)
> @@ -1157,6 +1158,9 @@ static void mmc_power_up(struct mmc_host *host)
> {
> int bit;
>
> + if (host->ios.power_mode == MMC_POWER_ON)
> + return;
> +
> mmc_host_clk_hold(host);
>
> /* If ocr is set, we use it */
> @@ -1199,6 +1203,10 @@ static void mmc_power_up(struct mmc_host *host)
> void mmc_power_off(struct mmc_host *host)
> {
> int err = 0;
> +
> + if (host->ios.power_mode == MMC_POWER_OFF)
> + return;
> +
> mmc_host_clk_hold(host);
>
> host->ios.clock = 0;
> @@ -2005,7 +2013,6 @@ EXPORT_SYMBOL(mmc_detect_card_removed);
>
> void mmc_rescan(struct work_struct *work)
> {
> - static const unsigned freqs[] = { 40, 30, 20, 10 };
> struct mmc_host *host =
> container_of(work, struct mmc_host, detect.work);
> int i;
> @@ -2044,8 +2051,12 @@ void mmc_rescan(struct work_struct *work)
> */
> mmc_bus_put(host);
>
> - if (host->ops->get_cd && host->ops->get_cd(host) == 0)
> + if (host->ops->get_cd && host->ops->get_cd(host) == 0) {
> + mmc_claim_host(host);
> + mmc_power_off(host);
> + mmc_release_host(host);
> goto out;
> + }
>
> mmc_claim_host(host);
> for (i = 0; i < ARRAY_SIZE(freqs); i++) {
> @@ -2063,7 +2074,8 @@ void mmc_rescan(struct work_struct *work)
>
> void mmc_start_host(struct mmc_host *host)
> {
> - mmc_power_off(host);
> + host->f_init = max(freqs[0], host->f_min);
> + mmc_power_up(host);
> mmc_detect_change(host, 0);
> }
>
sorry to comment late on this.
This patch breaks the card detect with the designware host controller.
Anybody using the same host controller please let me know.
The problem is caused by the power_up call from the mmc_start_host
function. If i comment this powerup then card detect is fine
> --
> 1.7.9
>
> --
> 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 RESEND v7 1/2] block: ioctl support for sanitize in eMMC 4.5
On 28 June 2012 14:02, Yaniv Gardi wrote:
> Adding a new ioctl to support sanitize operation in eMMC
> cards version 4.5.
> The sanitize ioctl support helps performing this operation
> via user application.
>
> Signed-off-by: Yaniv Gardi
>
> ---
> block/blk-core.c | 15 ++--
> block/blk-lib.c | 51
> +
> block/blk-merge.c |4 +++
> block/elevator.c |2 +-
> block/ioctl.c |9
> include/linux/blk_types.h |5 +++-
> include/linux/blkdev.h|3 ++
> include/linux/fs.h|1 +
> kernel/trace/blktrace.c |2 +
> 9 files changed, 87 insertions(+), 5 deletions(-)
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 3c923a7..4a56102b 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -1641,7 +1641,7 @@ generic_make_request_checks(struct bio *bio)
> goto end_io;
> }
>
> - if (unlikely(!(bio->bi_rw & REQ_DISCARD) &&
> + if (unlikely(!(bio->bi_rw & (REQ_DISCARD | REQ_SANITIZE)) &&
> nr_sectors > queue_max_hw_sectors(q))) {
> printk(KERN_ERR "bio too big device %s (%u > %u)\n",
>bdevname(bio->bi_bdev, b),
> @@ -1689,6 +1689,14 @@ generic_make_request_checks(struct bio *bio)
> goto end_io;
> }
>
> + if ((bio->bi_rw & REQ_SANITIZE) &&
> + (!blk_queue_sanitize(q))) {
> + pr_info("%s - got a SANITIZE request but the queue "
> + "doesn't support sanitize requests", __func__);
> + err = -EOPNOTSUPP;
> + goto end_io;
> + }
> +
> if (blk_throtl_bio(q, bio))
> return false; /* throttled, will be resubmitted later */
>
> @@ -1794,7 +1802,8 @@ void submit_bio(int rw, struct bio *bio)
> * If it's a regular read/write or a barrier with data attached,
> * go through the normal accounting stuff before submission.
> */
> - if (bio_has_data(bio) && !(rw & REQ_DISCARD)) {
> + if (bio_has_data(bio) &&
> + (!(rw & (REQ_DISCARD | REQ_SANITIZE {
> if (rw & WRITE) {
> count_vm_events(PGPGOUT, count);
> } else {
> @@ -1840,7 +1849,7 @@ EXPORT_SYMBOL(submit_bio);
> */
> int blk_rq_check_limits(struct request_queue *q, struct request *rq)
> {
> - if (rq->cmd_flags & REQ_DISCARD)
> + if (rq->cmd_flags & (REQ_DISCARD | REQ_SANITIZE))
> return 0;
>
> if (blk_rq_sectors(rq) > queue_max_sectors(q) ||
> diff --git a/block/blk-lib.c b/block/blk-lib.c
> index 2b461b4..280d63e 100644
> --- a/block/blk-lib.c
> +++ b/block/blk-lib.c
> @@ -115,6 +115,57 @@ int blkdev_issue_discard(struct block_device *bdev,
> sector_t sector,
> EXPORT_SYMBOL(blkdev_issue_discard);
>
> /**
> + * blkdev_issue_sanitize - queue a sanitize request
> + * @bdev: blockdev to issue sanitize for
> + * @gfp_mask: memory allocation flags (for bio_alloc)
> + *
> + * Description:
> + *Issue a sanitize request for the specified block device
> + */
> +int blkdev_issue_sanitize(struct block_device *bdev, gfp_t gfp_mask)
> +{
> + DECLARE_COMPLETION_ONSTACK(wait);
> + struct request_queue *q = bdev_get_queue(bdev);
> + int type = REQ_WRITE | REQ_SANITIZE;
> + struct bio_batch bb;
> + struct bio *bio;
> + int ret = 0;
> +
> + if (!q)
> + return -ENXIO;
> +
> + if (!blk_queue_sanitize(q)) {
> + pr_err("%s - card doesn't support sanitize", __func__);
> + return -EOPNOTSUPP;
> + }
> +
> + bio = bio_alloc(gfp_mask, 1);
> + if (!bio)
> + return -ENOMEM;
> +
> + atomic_set(&bb.done, 1);
> + bb.flags = 1 << BIO_UPTODATE;
> + bb.wait = &wait;
> +
> + bio->bi_end_io = bio_batch_end_io;
> + bio->bi_bdev = bdev;
> + bio->bi_private = &bb;
> +
> + atomic_inc(&bb.done);
> + submit_bio(type, bio);
> +
> + /* Wait for bios in-flight */
> + if (!atomic_dec_and_test(&bb.done))
> + wait_for_completion(&wait);
> +
> + if (!test_bit(BIO_UPTODATE, &bb.flags))
> + ret = -EIO;
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(blkdev_issue_sanitize);
> +
> +/**
> * blkdev_issue_zeroout - generate number of zero filed write bios
> * @bdev: blockdev to issue
> * @sector:start sector
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index 160035f..7e24772 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -477,6 +477,10 @@ bool blk_rq_merge_ok(struct request *rq, struct bio *bio)
> if (!rq_mergeable(rq))
> return false;
>
> + /* don't merge file system requests and sanitize requests */
> + if ((req->cmd_flags & REQ_SANITIZE) != (next->cmd_flags &
> REQ_SANITIZE))
> + retu
Re: [PATCH RESEND v7 1/2] block: ioctl support for sanitize in eMMC 4.5
On 28 June 2012 14:02, Yaniv Gardi wrote:
> Adding a new ioctl to support sanitize operation in eMMC
> cards version 4.5.
> The sanitize ioctl support helps performing this operation
> via user application.
>
> Signed-off-by: Yaniv Gardi
>
> ---
> block/blk-core.c | 15 ++--
> block/blk-lib.c | 51
> +
> block/blk-merge.c |4 +++
> block/elevator.c |2 +-
> block/ioctl.c |9
> include/linux/blk_types.h |5 +++-
> include/linux/blkdev.h|3 ++
> include/linux/fs.h|1 +
> kernel/trace/blktrace.c |2 +
> 9 files changed, 87 insertions(+), 5 deletions(-)
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 3c923a7..4a56102b 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -1641,7 +1641,7 @@ generic_make_request_checks(struct bio *bio)
> goto end_io;
> }
>
> - if (unlikely(!(bio->bi_rw & REQ_DISCARD) &&
> + if (unlikely(!(bio->bi_rw & (REQ_DISCARD | REQ_SANITIZE)) &&
> nr_sectors > queue_max_hw_sectors(q))) {
> printk(KERN_ERR "bio too big device %s (%u > %u)\n",
>bdevname(bio->bi_bdev, b),
> @@ -1689,6 +1689,14 @@ generic_make_request_checks(struct bio *bio)
> goto end_io;
> }
>
> + if ((bio->bi_rw & REQ_SANITIZE) &&
> + (!blk_queue_sanitize(q))) {
> + pr_info("%s - got a SANITIZE request but the queue "
> + "doesn't support sanitize requests", __func__);
> + err = -EOPNOTSUPP;
> + goto end_io;
> + }
> +
> if (blk_throtl_bio(q, bio))
> return false; /* throttled, will be resubmitted later */
>
> @@ -1794,7 +1802,8 @@ void submit_bio(int rw, struct bio *bio)
> * If it's a regular read/write or a barrier with data attached,
> * go through the normal accounting stuff before submission.
> */
> - if (bio_has_data(bio) && !(rw & REQ_DISCARD)) {
> + if (bio_has_data(bio) &&
> + (!(rw & (REQ_DISCARD | REQ_SANITIZE {
> if (rw & WRITE) {
> count_vm_events(PGPGOUT, count);
> } else {
> @@ -1840,7 +1849,7 @@ EXPORT_SYMBOL(submit_bio);
> */
> int blk_rq_check_limits(struct request_queue *q, struct request *rq)
> {
> - if (rq->cmd_flags & REQ_DISCARD)
> + if (rq->cmd_flags & (REQ_DISCARD | REQ_SANITIZE))
> return 0;
>
> if (blk_rq_sectors(rq) > queue_max_sectors(q) ||
> diff --git a/block/blk-lib.c b/block/blk-lib.c
> index 2b461b4..280d63e 100644
> --- a/block/blk-lib.c
> +++ b/block/blk-lib.c
> @@ -115,6 +115,57 @@ int blkdev_issue_discard(struct block_device *bdev,
> sector_t sector,
> EXPORT_SYMBOL(blkdev_issue_discard);
>
> /**
> + * blkdev_issue_sanitize - queue a sanitize request
> + * @bdev: blockdev to issue sanitize for
> + * @gfp_mask: memory allocation flags (for bio_alloc)
> + *
> + * Description:
> + *Issue a sanitize request for the specified block device
> + */
> +int blkdev_issue_sanitize(struct block_device *bdev, gfp_t gfp_mask)
> +{
> + DECLARE_COMPLETION_ONSTACK(wait);
> + struct request_queue *q = bdev_get_queue(bdev);
> + int type = REQ_WRITE | REQ_SANITIZE;
> + struct bio_batch bb;
> + struct bio *bio;
> + int ret = 0;
> +
> + if (!q)
> + return -ENXIO;
> +
> + if (!blk_queue_sanitize(q)) {
> + pr_err("%s - card doesn't support sanitize", __func__);
> + return -EOPNOTSUPP;
> + }
> +
> + bio = bio_alloc(gfp_mask, 1);
> + if (!bio)
> + return -ENOMEM;
> +
> + atomic_set(&bb.done, 1);
> + bb.flags = 1 << BIO_UPTODATE;
> + bb.wait = &wait;
> +
> + bio->bi_end_io = bio_batch_end_io;
> + bio->bi_bdev = bdev;
> + bio->bi_private = &bb;
> +
> + atomic_inc(&bb.done);
> + submit_bio(type, bio);
> +
> + /* Wait for bios in-flight */
> + if (!atomic_dec_and_test(&bb.done))
> + wait_for_completion(&wait);
> +
> + if (!test_bit(BIO_UPTODATE, &bb.flags))
> + ret = -EIO;
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(blkdev_issue_sanitize);
> +
> +/**
> * blkdev_issue_zeroout - generate number of zero filed write bios
> * @bdev: blockdev to issue
> * @sector:start sector
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index 160035f..7e24772 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -477,6 +477,10 @@ bool blk_rq_merge_ok(struct request *rq, struct bio *bio)
> if (!rq_mergeable(rq))
> return false;
>
> + /* don't merge file system requests and sanitize requests */
> + if ((req->cmd_flags & REQ_SANITIZE) != (next->cmd_flags &
> REQ_SANITIZE))
this will not compile.
Re: [PATCH RESEND v7 1/2] block: ioctl support for sanitize in eMMC 4.5
On 28 June 2012 14:02, Yaniv Gardi wrote:
> Adding a new ioctl to support sanitize operation in eMMC
> cards version 4.5.
> The sanitize ioctl support helps performing this operation
> via user application.
>
> Signed-off-by: Yaniv Gardi
>
> ---
> block/blk-core.c | 15 ++--
> block/blk-lib.c | 51
> +
> block/blk-merge.c |4 +++
> block/elevator.c |2 +-
> block/ioctl.c |9
> include/linux/blk_types.h |5 +++-
> include/linux/blkdev.h|3 ++
> include/linux/fs.h|1 +
> kernel/trace/blktrace.c |2 +
> 9 files changed, 87 insertions(+), 5 deletions(-)
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 3c923a7..4a56102b 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -1641,7 +1641,7 @@ generic_make_request_checks(struct bio *bio)
> goto end_io;
> }
>
> - if (unlikely(!(bio->bi_rw & REQ_DISCARD) &&
> + if (unlikely(!(bio->bi_rw & (REQ_DISCARD | REQ_SANITIZE)) &&
> nr_sectors > queue_max_hw_sectors(q))) {
> printk(KERN_ERR "bio too big device %s (%u > %u)\n",
>bdevname(bio->bi_bdev, b),
> @@ -1689,6 +1689,14 @@ generic_make_request_checks(struct bio *bio)
> goto end_io;
> }
>
> + if ((bio->bi_rw & REQ_SANITIZE) &&
> + (!blk_queue_sanitize(q))) {
> + pr_info("%s - got a SANITIZE request but the queue "
> + "doesn't support sanitize requests", __func__);
> + err = -EOPNOTSUPP;
> + goto end_io;
> + }
> +
> if (blk_throtl_bio(q, bio))
> return false; /* throttled, will be resubmitted later */
>
> @@ -1794,7 +1802,8 @@ void submit_bio(int rw, struct bio *bio)
> * If it's a regular read/write or a barrier with data attached,
> * go through the normal accounting stuff before submission.
> */
> - if (bio_has_data(bio) && !(rw & REQ_DISCARD)) {
> + if (bio_has_data(bio) &&
> + (!(rw & (REQ_DISCARD | REQ_SANITIZE {
> if (rw & WRITE) {
> count_vm_events(PGPGOUT, count);
> } else {
> @@ -1840,7 +1849,7 @@ EXPORT_SYMBOL(submit_bio);
> */
> int blk_rq_check_limits(struct request_queue *q, struct request *rq)
> {
> - if (rq->cmd_flags & REQ_DISCARD)
> + if (rq->cmd_flags & (REQ_DISCARD | REQ_SANITIZE))
> return 0;
>
> if (blk_rq_sectors(rq) > queue_max_sectors(q) ||
> diff --git a/block/blk-lib.c b/block/blk-lib.c
> index 2b461b4..280d63e 100644
> --- a/block/blk-lib.c
> +++ b/block/blk-lib.c
> @@ -115,6 +115,57 @@ int blkdev_issue_discard(struct block_device *bdev,
> sector_t sector,
> EXPORT_SYMBOL(blkdev_issue_discard);
>
> /**
> + * blkdev_issue_sanitize - queue a sanitize request
> + * @bdev: blockdev to issue sanitize for
> + * @gfp_mask: memory allocation flags (for bio_alloc)
> + *
> + * Description:
> + *Issue a sanitize request for the specified block device
> + */
> +int blkdev_issue_sanitize(struct block_device *bdev, gfp_t gfp_mask)
> +{
> + DECLARE_COMPLETION_ONSTACK(wait);
> + struct request_queue *q = bdev_get_queue(bdev);
> + int type = REQ_WRITE | REQ_SANITIZE;
> + struct bio_batch bb;
> + struct bio *bio;
> + int ret = 0;
> +
> + if (!q)
> + return -ENXIO;
> +
> + if (!blk_queue_sanitize(q)) {
> + pr_err("%s - card doesn't support sanitize", __func__);
> + return -EOPNOTSUPP;
> + }
> +
> + bio = bio_alloc(gfp_mask, 1);
> + if (!bio)
> + return -ENOMEM;
> +
> + atomic_set(&bb.done, 1);
> + bb.flags = 1 << BIO_UPTODATE;
> + bb.wait = &wait;
> +
> + bio->bi_end_io = bio_batch_end_io;
> + bio->bi_bdev = bdev;
> + bio->bi_private = &bb;
> +
> + atomic_inc(&bb.done);
> + submit_bio(type, bio);
> +
> + /* Wait for bios in-flight */
> + if (!atomic_dec_and_test(&bb.done))
> + wait_for_completion(&wait);
> +
> + if (!test_bit(BIO_UPTODATE, &bb.flags))
> + ret = -EIO;
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(blkdev_issue_sanitize);
> +
> +/**
> * blkdev_issue_zeroout - generate number of zero filed write bios
> * @bdev: blockdev to issue
> * @sector:start sector
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index 160035f..7e24772 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -477,6 +477,10 @@ bool blk_rq_merge_ok(struct request *rq, struct bio *bio)
> if (!rq_mergeable(rq))
> return false;
>
> + /* don't merge file system requests and sanitize requests */
> + if ((req->cmd_flags & REQ_SANITIZE) != (next->cmd_flags &
> REQ_SANITIZE))
> + retu
Re: [PATCH v3 2/2] mmc: sdhci: A new flag SDHCI_USING_RETUNING_TIMER
if ((host->version >= SDHCI_SPEC_300) && host->tuning_count &&
> - (host->tuning_mode == SDHCI_TUNING_MODE_1))
> + if (host->flags & SDHCI_USING_RETUNING_TIMER)
> host->flags |= SDHCI_NEEDS_RETUNING;
>
> return ret;
> @@ -2508,8 +2506,7 @@ int sdhci_runtime_suspend_host(struct sdhci_host *host)
> int ret = 0;
>
> /* Disable tuning since we are suspending */
> - if (host->version >= SDHCI_SPEC_300 &&
> - host->tuning_mode == SDHCI_TUNING_MODE_1) {
> + if (host->flags & SDHCI_USING_RETUNING_TIMER) {
> del_timer_sync(&host->tuning_timer);
> host->flags &= ~SDHCI_NEEDS_RETUNING;
> }
> @@ -2550,8 +2547,7 @@ int sdhci_runtime_resume_host(struct sdhci_host *host)
> sdhci_do_enable_preset_value(host, true);
>
> /* Set the re-tuning expiration flag */
> - if ((host->version >= SDHCI_SPEC_300) && host->tuning_count &&
> - (host->tuning_mode == SDHCI_TUNING_MODE_1))
> + if (host->flags & SDHCI_USING_RETUNING_TIMER)
> host->flags |= SDHCI_NEEDS_RETUNING;
>
> spin_lock_irqsave(&host->lock, flags);
> @@ -3140,8 +3136,6 @@ void sdhci_remove_host(struct sdhci_host *host, int
> dead)
> free_irq(host->irq, host);
>
> del_timer_sync(&host->timer);
> - if (host->version >= SDHCI_SPEC_300)
> - del_timer_sync(&host->tuning_timer);
>
> tasklet_kill(&host->card_tasklet);
> tasklet_kill(&host->finish_tasklet);
> diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
> index d989b51..ac83b10 100644
> --- a/include/linux/mmc/sdhci.h
> +++ b/include/linux/mmc/sdhci.h
> @@ -122,6 +122,7 @@ struct sdhci_host {
> #define SDHCI_PV_ENABLED (1<<8) /* Preset value enabled */
> #define SDHCI_SDIO_IRQ_ENABLED (1<<9) /* SDIO irq enabled */
> #define SDHCI_HS200_NEEDS_TUNING (1<<10) /* HS200 needs tuning */
> +#define SDHCI_USING_RETUNING_TIMER (1<<11) /* Host is using a retuning
> timer for the card */
>
> unsigned int version; /* SDHCI spec. version */
Looks good to me
Reviewed By:- Girish K S
>
> --
> 1.7.11.1.3.g4c8a9db
>
> --
> 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 v2] mmc: sdhci: fix incorrect command used in tuning
On 3 July 2012 17:27, Girish K S wrote:
> On 3 July 2012 17:01, Aaron Lu wrote:
>> Hi,
>>
>> On Tue, Jul 03, 2012 at 03:28:28PM +0530, Girish K S wrote:
>>> On 3 July 2012 14:57, Aaron Lu wrote:
>>> > V2:
>>> > Fix for SDIO case: both SD and SDIO cards use cmd19 while eMMC use cmd21.
>>> >
>>> > V1:
>>> > For SD hosts using retuning mode 1, when retuning timer expired, it will
>>> > need to do retuning in sdhci_request before processing the actual
>>> > request. But the retuning command is fixed: cmd19 for SD card and cmd21
>>> > for eMMC card, so we can't use the original request's command to do the
>>> > tuning.
>>> >
>>> > And since the tuning command depends on the card type atteched to the
>>> > host, we will need to know the card type to use the correct tuning
>>> > command.
>>> >
>>> > Cc: stable [3.3+]
>>> > Signed-off-by: Aaron Lu
>>> > ---
>>> > drivers/mmc/host/sdhci.c | 8 +++-
>>> > 1 file changed, 7 insertions(+), 1 deletion(-)
>>> >
>>> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> > index f76736b..4e53e6b 100644
>>> > --- a/drivers/mmc/host/sdhci.c
>>> > +++ b/drivers/mmc/host/sdhci.c
>>> > @@ -27,6 +27,7 @@
>>> >
>>> > #include
>>> > #include
>>> > +#include
>>> >
>>> > #include "sdhci.h"
>>> >
>>> > @@ -1245,6 +1246,7 @@ static void sdhci_request(struct mmc_host *mmc,
>>> > struct mmc_request *mrq)
>>> > struct sdhci_host *host;
>>> > bool present;
>>> > unsigned long flags;
>>> > + u32 tuning_opcode;
>>> >
>>> > host = mmc_priv(mmc);
>>> >
>>> > @@ -1292,8 +1294,12 @@ static void sdhci_request(struct mmc_host *mmc,
>>> > struct mmc_request *mrq)
>>> > */
>>> > if ((host->flags & SDHCI_NEEDS_RETUNING) &&
>>> > !(present_state & (SDHCI_DOING_WRITE |
>>> > SDHCI_DOING_READ))) {
>>> > + /* eMMC uses cmd21 while sd and sdio use cmd19 */
>>> > + tuning_opcode = mmc->card->type == MMC_TYPE_MMC ?
>>> > + MMC_SEND_TUNING_BLOCK_HS200 :
>>> > + MMC_SEND_TUNING_BLOCK;
>>> > spin_unlock_irqrestore(&host->lock, flags);
>>> > - sdhci_execute_tuning(mmc, mrq->cmd->opcode);
>>> > + sdhci_execute_tuning(mmc, tuning_opcode);
>>> dont you think the previous implementation does the same. It is
>>> already handled by introducing the 2nd parameter.
>>
>> Suppose the following scenario:
>> mmc_start_request (e.g. mrq->cmd->opcode is 18 for this call)
>> -> host->ops->request
>> (sdhci's retuning timer expired, the flag SDHCI_NEEDS_RETUNING is set)
>> -> sdhci_request
>> -> sdhci_execute_tuning will be called before processing the
>> actual request due to retuning's requirement, but with the wrong command
>> opcode(cmd18) instead of cmd19 for sd/sdio or cmd21 for emmc.
>>
>> The problem is with retuning, for normal explicit calls of
>> sdhci_execute_tuning, there is no problem with the code. But when
>> retuning is required, sdhci_execute_retuning will be executed implicitly
>> to the above layer and we have to use the right tuning command instead of
>> the current processing command, which can be any of the valid sd/sdio/mmc
>> commands.
> Thanks for the explanation. is it possible to make a separate local
> function for this. Since mmc_host_ops has a member .execute_tuning
> which takes 2 parameters that are called from respective sd/mmc/sdio
> card files. there might be conflict
Sorry i just read it wrongly (function has only 1 param).
>>
>> -Aaron
>>
>>> > spin_lock_irqsave(&host->lock, flags);
>>> >
>>> > /* Restore original mmc_request structure */
>>> > --
>>> > 1.7.11.1.3.g4c8a9db
>>> >
>>> >
--
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: sdhci: fix incorrect command used in tuning
On 3 July 2012 17:27, Girish K S wrote:
> On 3 July 2012 17:01, Aaron Lu wrote:
>> Hi,
>>
>> On Tue, Jul 03, 2012 at 03:28:28PM +0530, Girish K S wrote:
>>> On 3 July 2012 14:57, Aaron Lu wrote:
>>> > V2:
>>> > Fix for SDIO case: both SD and SDIO cards use cmd19 while eMMC use cmd21.
>>> >
>>> > V1:
>>> > For SD hosts using retuning mode 1, when retuning timer expired, it will
>>> > need to do retuning in sdhci_request before processing the actual
>>> > request. But the retuning command is fixed: cmd19 for SD card and cmd21
>>> > for eMMC card, so we can't use the original request's command to do the
>>> > tuning.
>>> >
>>> > And since the tuning command depends on the card type atteched to the
>>> > host, we will need to know the card type to use the correct tuning
>>> > command.
>>> >
>>> > Cc: stable [3.3+]
>>> > Signed-off-by: Aaron Lu
>>> > ---
>>> > drivers/mmc/host/sdhci.c | 8 +++-
>>> > 1 file changed, 7 insertions(+), 1 deletion(-)
>>> >
>>> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> > index f76736b..4e53e6b 100644
>>> > --- a/drivers/mmc/host/sdhci.c
>>> > +++ b/drivers/mmc/host/sdhci.c
>>> > @@ -27,6 +27,7 @@
>>> >
>>> > #include
>>> > #include
>>> > +#include
>>> >
>>> > #include "sdhci.h"
>>> >
>>> > @@ -1245,6 +1246,7 @@ static void sdhci_request(struct mmc_host *mmc,
>>> > struct mmc_request *mrq)
>>> > struct sdhci_host *host;
>>> > bool present;
>>> > unsigned long flags;
>>> > + u32 tuning_opcode;
>>> >
>>> > host = mmc_priv(mmc);
>>> >
>>> > @@ -1292,8 +1294,12 @@ static void sdhci_request(struct mmc_host *mmc,
>>> > struct mmc_request *mrq)
>>> > */
>>> > if ((host->flags & SDHCI_NEEDS_RETUNING) &&
>>> > !(present_state & (SDHCI_DOING_WRITE |
>>> > SDHCI_DOING_READ))) {
>>> > + /* eMMC uses cmd21 while sd and sdio use cmd19 */
>>> > + tuning_opcode = mmc->card->type == MMC_TYPE_MMC ?
>>> > + MMC_SEND_TUNING_BLOCK_HS200 :
>>> > + MMC_SEND_TUNING_BLOCK;
>>> > spin_unlock_irqrestore(&host->lock, flags);
>>> > - sdhci_execute_tuning(mmc, mrq->cmd->opcode);
>>> > + sdhci_execute_tuning(mmc, tuning_opcode);
>>> dont you think the previous implementation does the same. It is
>>> already handled by introducing the 2nd parameter.
>>
>> Suppose the following scenario:
>> mmc_start_request (e.g. mrq->cmd->opcode is 18 for this call)
>> -> host->ops->request
>> (sdhci's retuning timer expired, the flag SDHCI_NEEDS_RETUNING is set)
>> -> sdhci_request
>> -> sdhci_execute_tuning will be called before processing the
>> actual request due to retuning's requirement, but with the wrong command
>> opcode(cmd18) instead of cmd19 for sd/sdio or cmd21 for emmc.
>>
>> The problem is with retuning, for normal explicit calls of
>> sdhci_execute_tuning, there is no problem with the code. But when
>> retuning is required, sdhci_execute_retuning will be executed implicitly
>> to the above layer and we have to use the right tuning command instead of
>> the current processing command, which can be any of the valid sd/sdio/mmc
>> commands.
> Thanks for the explanation. is it possible to make a separate local
> function for this. Since mmc_host_ops has a member .execute_tuning
> which takes 2 parameters that are called from respective sd/mmc/sdio
> card files. there might be conflict
sorry igonre it
>>
>> -Aaron
>>
>>> > spin_lock_irqsave(&host->lock, flags);
>>> >
>>> > /* Restore original mmc_request structure */
>>> > --
>>> > 1.7.11.1.3.g4c8a9db
>>> >
>>> >
--
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: sdhci: fix incorrect command used in tuning
On 3 July 2012 17:01, Aaron Lu wrote:
> Hi,
>
> On Tue, Jul 03, 2012 at 03:28:28PM +0530, Girish K S wrote:
>> On 3 July 2012 14:57, Aaron Lu wrote:
>> > V2:
>> > Fix for SDIO case: both SD and SDIO cards use cmd19 while eMMC use cmd21.
>> >
>> > V1:
>> > For SD hosts using retuning mode 1, when retuning timer expired, it will
>> > need to do retuning in sdhci_request before processing the actual
>> > request. But the retuning command is fixed: cmd19 for SD card and cmd21
>> > for eMMC card, so we can't use the original request's command to do the
>> > tuning.
>> >
>> > And since the tuning command depends on the card type atteched to the
>> > host, we will need to know the card type to use the correct tuning
>> > command.
>> >
>> > Cc: stable [3.3+]
>> > Signed-off-by: Aaron Lu
>> > ---
>> > drivers/mmc/host/sdhci.c | 8 +++-
>> > 1 file changed, 7 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> > index f76736b..4e53e6b 100644
>> > --- a/drivers/mmc/host/sdhci.c
>> > +++ b/drivers/mmc/host/sdhci.c
>> > @@ -27,6 +27,7 @@
>> >
>> > #include
>> > #include
>> > +#include
>> >
>> > #include "sdhci.h"
>> >
>> > @@ -1245,6 +1246,7 @@ static void sdhci_request(struct mmc_host *mmc,
>> > struct mmc_request *mrq)
>> > struct sdhci_host *host;
>> > bool present;
>> > unsigned long flags;
>> > + u32 tuning_opcode;
>> >
>> > host = mmc_priv(mmc);
>> >
>> > @@ -1292,8 +1294,12 @@ static void sdhci_request(struct mmc_host *mmc,
>> > struct mmc_request *mrq)
>> > */
>> > if ((host->flags & SDHCI_NEEDS_RETUNING) &&
>> > !(present_state & (SDHCI_DOING_WRITE |
>> > SDHCI_DOING_READ))) {
>> > + /* eMMC uses cmd21 while sd and sdio use cmd19 */
>> > + tuning_opcode = mmc->card->type == MMC_TYPE_MMC ?
>> > + MMC_SEND_TUNING_BLOCK_HS200 :
>> > + MMC_SEND_TUNING_BLOCK;
>> > spin_unlock_irqrestore(&host->lock, flags);
>> > - sdhci_execute_tuning(mmc, mrq->cmd->opcode);
>> > + sdhci_execute_tuning(mmc, tuning_opcode);
>> dont you think the previous implementation does the same. It is
>> already handled by introducing the 2nd parameter.
>
> Suppose the following scenario:
> mmc_start_request (e.g. mrq->cmd->opcode is 18 for this call)
> -> host->ops->request
> (sdhci's retuning timer expired, the flag SDHCI_NEEDS_RETUNING is set)
> -> sdhci_request
> -> sdhci_execute_tuning will be called before processing the
> actual request due to retuning's requirement, but with the wrong command
> opcode(cmd18) instead of cmd19 for sd/sdio or cmd21 for emmc.
>
> The problem is with retuning, for normal explicit calls of
> sdhci_execute_tuning, there is no problem with the code. But when
> retuning is required, sdhci_execute_retuning will be executed implicitly
> to the above layer and we have to use the right tuning command instead of
> the current processing command, which can be any of the valid sd/sdio/mmc
> commands.
Thanks for the explanation. is it possible to make a separate local
function for this. Since mmc_host_ops has a member .execute_tuning
which takes 2 parameters that are called from respective sd/mmc/sdio
card files. there might be conflict
>
> -Aaron
>
>> > spin_lock_irqsave(&host->lock, flags);
>> >
>> > /* Restore original mmc_request structure */
>> > --
>> > 1.7.11.1.3.g4c8a9db
>> >
>> >
--
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: sdhci: fix incorrect command used in tuning
On 3 July 2012 14:57, Aaron Lu wrote:
> V2:
> Fix for SDIO case: both SD and SDIO cards use cmd19 while eMMC use cmd21.
>
> V1:
> For SD hosts using retuning mode 1, when retuning timer expired, it will
> need to do retuning in sdhci_request before processing the actual
> request. But the retuning command is fixed: cmd19 for SD card and cmd21
> for eMMC card, so we can't use the original request's command to do the
> tuning.
>
> And since the tuning command depends on the card type atteched to the
> host, we will need to know the card type to use the correct tuning
> command.
>
> Cc: stable [3.3+]
> Signed-off-by: Aaron Lu
> ---
> drivers/mmc/host/sdhci.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index f76736b..4e53e6b 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -27,6 +27,7 @@
>
> #include
> #include
> +#include
>
> #include "sdhci.h"
>
> @@ -1245,6 +1246,7 @@ static void sdhci_request(struct mmc_host *mmc, struct
> mmc_request *mrq)
> struct sdhci_host *host;
> bool present;
> unsigned long flags;
> + u32 tuning_opcode;
>
> host = mmc_priv(mmc);
>
> @@ -1292,8 +1294,12 @@ static void sdhci_request(struct mmc_host *mmc, struct
> mmc_request *mrq)
> */
> if ((host->flags & SDHCI_NEEDS_RETUNING) &&
> !(present_state & (SDHCI_DOING_WRITE |
> SDHCI_DOING_READ))) {
> + /* eMMC uses cmd21 while sd and sdio use cmd19 */
> + tuning_opcode = mmc->card->type == MMC_TYPE_MMC ?
> + MMC_SEND_TUNING_BLOCK_HS200 :
> + MMC_SEND_TUNING_BLOCK;
> spin_unlock_irqrestore(&host->lock, flags);
> - sdhci_execute_tuning(mmc, mrq->cmd->opcode);
> + sdhci_execute_tuning(mmc, tuning_opcode);
dont you think the previous implementation does the same. It is
already handled by introducing the 2nd parameter.
> spin_lock_irqsave(&host->lock, flags);
>
> /* Restore original mmc_request structure */
> --
> 1.7.11.1.3.g4c8a9db
>
>
--
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: Re: [PATCH] mmc: core: Revert "skip card initialization if powerclass selection fails"
On 2 July 2012 16:50, Marc Dietrich wrote: > Am Montag, 2. Juli 2012, 14:28:37 schrieb Girish K S: >> On 2 July 2012 14:23, Girish K S wrote: >> > On 2 July 2012 14:13, Saugata Das wrote: >> >> On 2 July 2012 12:26, Venkatraman S wrote: >> >>> This reverts commit 3d93576e(skip card initialization if >> >>> power class selection fails). >> >>> Problem has been reported when this is used with eMMC4.41 >> >>> card with Tegra Platform. Till the issue is root caused, >> >>> bus width selection failure should not be treated as fatal. >> >> >> >> According to me, we need to find the root issue (which could be either >> >> host not able to provide enough current or faulty eMMC). Do we know, >> >> what could be the side effect of working on eMMC with less power than >> >> what it has requested in PWR_CL ? >> >> >> >> One known issue with the current power class selection is that we do >> >> not check the current requirement for a selected power class. It >> >> assumes that host is able to provide the maximum current needed at >> >> highest speed (> 800mA). Is it already checked on Tegra ? >> > >> > and at the least bus width i.e 1 bit mode. >> >> The MMC card spec has 2 max current values (power class) one for 4 bit >> mode and another for 8 bit mode at supported voltages. But the SDHCI >> spec has one MaxCur register for supported voltages but doesnt mention >> for which bus width. Any input on this is very helpful to resolve the >> powerclass issue that is pending > > the higher nibble is for 8 bit and the lower one for 4 bit. The power class is > same for both bus width on this toshiba device. This is true from device point of view. but my concern was with the host controller register of SDHCI Spec MAXCURRn where n is 1.8 / 3.3 /3.0. Each voltage supported is assigned 8 bits (values ranging from 0-255). which means there is no split in nibbles for 4-bit and 8-bit mode > > Marc > -- 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: Revert "skip card initialization if power class selection fails"
On 2 July 2012 14:23, Girish K S wrote:
> On 2 July 2012 14:13, Saugata Das wrote:
>> On 2 July 2012 12:26, Venkatraman S wrote:
>>> This reverts commit 3d93576e(skip card initialization if
>>> power class selection fails).
>>> Problem has been reported when this is used with eMMC4.41
>>> card with Tegra Platform. Till the issue is root caused,
>>> bus width selection failure should not be treated as fatal.
>>>
>>
>> According to me, we need to find the root issue (which could be either
>> host not able to provide enough current or faulty eMMC). Do we know,
>> what could be the side effect of working on eMMC with less power than
>> what it has requested in PWR_CL ?
>>
>> One known issue with the current power class selection is that we do
>> not check the current requirement for a selected power class. It
>> assumes that host is able to provide the maximum current needed at
>> highest speed (> 800mA). Is it already checked on Tegra ?
>>
> and at the least bus width i.e 1 bit mode.
>
The MMC card spec has 2 max current values (power class) one for 4 bit
mode and another for 8 bit mode at supported voltages. But the SDHCI
spec has one MaxCur register for supported voltages but doesnt mention
for which bus width. Any input on this is very helpful to resolve the
powerclass issue that is pending
>>> Reported-by: Marc Dietrich
>>> Signed-Off-by: Venkatraman S
>>> CC: Ulf Hansson
>>> CC: Subhash Jadavani
>>> CC: Saugata Das
>>> ---
>>> drivers/mmc/core/mmc.c | 18 +++---
>>> 1 file changed, 11 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>>> index 258b203..4f4489a 100644
>>> --- a/drivers/mmc/core/mmc.c
>>> +++ b/drivers/mmc/core/mmc.c
>>> @@ -717,10 +717,6 @@ static int mmc_select_powerclass(struct mmc_card *card,
>>> card->ext_csd.generic_cmd6_time);
>>> }
>>>
>>> - if (err)
>>> - pr_err("%s: power class selection for ext_csd_bus_width %d"
>>> - " failed\n", mmc_hostname(card->host), bus_width);
>>> -
>>> return err;
>>> }
>>>
>>> @@ -1104,7 +1100,9 @@ static int mmc_init_card(struct mmc_host *host, u32
>>> ocr,
>>> EXT_CSD_BUS_WIDTH_8 : EXT_CSD_BUS_WIDTH_4;
>>> err = mmc_select_powerclass(card, ext_csd_bits, ext_csd);
>>> if (err)
>>> - goto err;
>>> + pr_warning("%s: power class selection to bus width
>>> %d"
>>> + " failed\n", mmc_hostname(card->host),
>>> + 1 << bus_width);
>>> }
>>>
>>> /*
>>> @@ -1136,7 +1134,10 @@ static int mmc_init_card(struct mmc_host *host, u32
>>> ocr,
>>> err = mmc_select_powerclass(card,
>>> ext_csd_bits[idx][0],
>>> ext_csd);
>>> if (err)
>>> - goto err;
>>> + pr_warning("%s: power class selection to "
>>> + "bus width %d failed\n",
>>> + mmc_hostname(card->host),
>>> + 1 << bus_width);
>>>
>>> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>>> EXT_CSD_BUS_WIDTH,
>>> @@ -1164,7 +1165,10 @@ static int mmc_init_card(struct mmc_host *host, u32
>>> ocr,
>>> err = mmc_select_powerclass(card,
>>> ext_csd_bits[idx][1],
>>> ext_csd);
>>> if (err)
>>> - goto err;
>>> + pr_warning("%s: power class selection to "
>>> + "bus width %d ddr %d failed\n",
>>> + mmc_hostname(card->host),
>>> + 1 << bus_width, ddr);
>>>
>>> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>>> EXT_CSD_BUS_WIDTH,
>>> --
>>> 1.7.11.1.25.g0e18bef
>>>
--
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: Revert "skip card initialization if power class selection fails"
On 2 July 2012 14:13, Saugata Das wrote:
> On 2 July 2012 12:26, Venkatraman S wrote:
>> This reverts commit 3d93576e(skip card initialization if
>> power class selection fails).
>> Problem has been reported when this is used with eMMC4.41
>> card with Tegra Platform. Till the issue is root caused,
>> bus width selection failure should not be treated as fatal.
>>
>
> According to me, we need to find the root issue (which could be either
> host not able to provide enough current or faulty eMMC). Do we know,
> what could be the side effect of working on eMMC with less power than
> what it has requested in PWR_CL ?
>
> One known issue with the current power class selection is that we do
> not check the current requirement for a selected power class. It
> assumes that host is able to provide the maximum current needed at
> highest speed (> 800mA). Is it already checked on Tegra ?
>
and at the least bus width i.e 1 bit mode.
>> Reported-by: Marc Dietrich
>> Signed-Off-by: Venkatraman S
>> CC: Ulf Hansson
>> CC: Subhash Jadavani
>> CC: Saugata Das
>> ---
>> drivers/mmc/core/mmc.c | 18 +++---
>> 1 file changed, 11 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>> index 258b203..4f4489a 100644
>> --- a/drivers/mmc/core/mmc.c
>> +++ b/drivers/mmc/core/mmc.c
>> @@ -717,10 +717,6 @@ static int mmc_select_powerclass(struct mmc_card *card,
>> card->ext_csd.generic_cmd6_time);
>> }
>>
>> - if (err)
>> - pr_err("%s: power class selection for ext_csd_bus_width %d"
>> - " failed\n", mmc_hostname(card->host), bus_width);
>> -
>> return err;
>> }
>>
>> @@ -1104,7 +1100,9 @@ static int mmc_init_card(struct mmc_host *host, u32
>> ocr,
>> EXT_CSD_BUS_WIDTH_8 : EXT_CSD_BUS_WIDTH_4;
>> err = mmc_select_powerclass(card, ext_csd_bits, ext_csd);
>> if (err)
>> - goto err;
>> + pr_warning("%s: power class selection to bus width
>> %d"
>> + " failed\n", mmc_hostname(card->host),
>> + 1 << bus_width);
>> }
>>
>> /*
>> @@ -1136,7 +1134,10 @@ static int mmc_init_card(struct mmc_host *host, u32
>> ocr,
>> err = mmc_select_powerclass(card,
>> ext_csd_bits[idx][0],
>> ext_csd);
>> if (err)
>> - goto err;
>> + pr_warning("%s: power class selection to "
>> + "bus width %d failed\n",
>> + mmc_hostname(card->host),
>> + 1 << bus_width);
>>
>> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>> EXT_CSD_BUS_WIDTH,
>> @@ -1164,7 +1165,10 @@ static int mmc_init_card(struct mmc_host *host, u32
>> ocr,
>> err = mmc_select_powerclass(card,
>> ext_csd_bits[idx][1],
>> ext_csd);
>> if (err)
>> - goto err;
>> + pr_warning("%s: power class selection to "
>> + "bus width %d ddr %d failed\n",
>> + mmc_hostname(card->host),
>> + 1 << bus_width, ddr);
>>
>> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>> EXT_CSD_BUS_WIDTH,
>> --
>> 1.7.11.1.25.g0e18bef
>>
--
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 v5] MMC-4.5 Power OFF Notify Rework
On 14 June 2012 18:43, Per Forlin wrote:
> Hi Girish and Suagata,
>
> I have run some regression tests with this patch on our board (ux500
> family) running suspend and resume of the eMMC 4.41 device.
>
> The two patches I have looked at are:
> 1. "mmc: core: Fix PowerOff Notify suspend/resume" (merged)
> 2. " MMC-4.5 Power OFF Notify Rework"
>
> With only patch #1 the eMMC doesn't power up after in resume() after
> being suspended. The eMMC doesn't respond at all after suspend. It's
> not powered up.
> Running tests with #1 and #2, the card is powered up but it doesn't
> wake up after CMD5. Commands that arrive are after resume/CMD5
> timeouts. I even tried by increasing the awake timeout to 5 seconds
> but i didn't help.
>
> The eMMC on my board successfully suspends and resumes with patch #1
> and #2 if waking up the card using CMD0 (mmc_card_init()) instead of
> CMD5.
>
> Have anyone else seen the same issue?
> Have this patch been verified on a board together with eMMC 4.41 that
> supports card power off.
This rework patch is still under progress. we are modifying it. In our
earlier discussions subhash has posted the
same issue and a solution for this. we should save ios context before
sleep and restore ios before awake. soon rework patch will be
posted with the above recomenedded solution.
>
> BR
> Per
>
> On Tue, May 22, 2012 at 1:45 PM, Girish K S
> wrote:
>> From: Saugata Das
>>
>> This is a rework of the existing POWER OFF NOTIFY patch. The current problem
>> with the patch comes from the ambiguity on the usage of POWER OFF NOTIFY
>> together with SLEEP and misunderstanding on the usage of MMC_POWER_OFF
>> power_mode from mmc_set_ios in different host controller drivers.
>>
>> This new patch works around this problem by adding a new host CAP,
>> MMC_CAP2_POWER_OFF_VCCQ_DURING_SUSPEND, which when set sends a
>> POWER OFF NOTIFY from mmc_suspend instead of SLEEP. It is expected that host
>> controller drivers will set this CAP, if they switch off both Vcc and Vccq
>> from MMC_POWER_OFF condition within mmc_set_ios. However, note that there
>> is no harm in sending MMC_POWER_NOTIFY even if Vccq is not switched off.
>>
>> This patch also sends POWER OFF NOTIFY from power management routines (e.g.
>> mmc_power_save_host, mmc_pm_notify/PM_SUSPEND_PREPARE, mmc_stop_host), which
>> does reinitialization of the eMMC on the return path of the power management
>> routines (e.g. mmc_power_restore_host, mmc_pm_notify/PM_POST_RESTORE,
>> mmc_start_host).
>>
>> This patch sets POWER_OFF_NOTIFICATION to POWER_OFF_SHORT if it is sent from
>> the suspend sequence. If it is sent from shutdown sequence then it is set to
>> POWER_OFF_LONG.
>>
>> Earlier implementation of PowerOff Notify as a core function is replaced as
>> a device's bus operation.
>>
>> Signed-off-by: Saugata Das
>> Signed-off-by: Girish K S
>>
>> changes in v5:
>> modified the the handling of return value in mmc_poweroff_notify.
>> changes in v4:
>> As suggested in review,
>> - Moved mmc_can_poweroff_notify to core.c
>> - Moved mmc_claim_host, mmc_release_host outside mmc_poweroff_notify
>> - Added check for wrong initialization for poweroff_notify_type
>> - mmc_poweroff_notify is modified to take as 2nd parameter
>> changes in v3:
>> This version addresses the review comments given by Subhash and Ulf
>> changes in v2:
>> This version addresses the changes suggested by Ulf
>> ---
>> drivers/mmc/core/core.c | 108
>> ++--
>> drivers/mmc/core/core.h | 1 +
>> drivers/mmc/core/mmc.c | 56 ---
>> drivers/mmc/host/dw_mmc.c | 5 --
>> drivers/mmc/host/sdhci.c | 9
>> include/linux/mmc/card.h | 5 +-
>> include/linux/mmc/core.h | 1 +
>> include/linux/mmc/host.h | 5 +--
>> include/linux/mmc/mmc.h | 7 +++
>> 9 files changed, 104 insertions(+), 93 deletions(-)
>>
>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>> index 0b6141d..fe616b9 100644
>> --- a/drivers/mmc/core/core.c
>> +++ b/drivers/mmc/core/core.c
>> @@ -1101,48 +1101,6 @@ void mmc_set_driver_type(struct mmc_host *host,
>> unsigned int drv_type)
>> mmc_host_clk_release(host);
>> }
>>
>> -static void mmc_poweroff_notify(struct mmc_host *host)
>> -{
>> - struct mmc_card *card;
>> - unsigned int timeout;
>> - unsigned int notify_type = EXT_CSD_N
Re: [PATCH] mmc: dw_mmc: use the use_hold_reg bit in CMD register
On 30 September 2011 16:16, Jaehoon Chung wrote:
> This patch is added the use_hold_reg bit in CMD register.
>
> In 2.40a, bit[29] of CMD register is used the use_hold_reg.
> Some SoC is affected by this bit.
> (This bit means whether use hold register when send data and cmd.
> And related with cclk_in_drv phase)
> if set IMPLEMENT_HOLD_REG in HCON register, i think fine that set this
> bit by default.
>
> Signed-off-by: Jaehoon Chung
> Signed-off-by: Kyungmin Park
> ---
> drivers/mmc/host/dw_mmc.c | 9 +
> drivers/mmc/host/dw_mmc.h | 1 +
> include/linux/mmc/dw_mmc.h | 1 +
> 3 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 0ed1d28..544a616 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -276,6 +276,13 @@ static void dw_mci_start_command(struct dw_mci *host,
> mci_writel(host, CMDARG, cmd->arg);
> wmb();
>
> + /*
> + * If use HOLD register,
> + * CMD and DATA sent to card through HOLD register.
> + */
> + if (host->use_hold_reg)
> + cmd_flags |= SDMMC_CMD_USE_HOLD_REG;
> +
sorry for seeing the patch very late.
I think its not just enough to check the HCON register. it is also
necessary to check whether CLKSEL[18:16] field is not 0 in combination
with HCON
> mci_writel(host, CMD, cmd_flags | SDMMC_CMD_START);
> }
>
> @@ -1886,6 +1893,8 @@ static int dw_mci_probe(struct platform_device *pdev)
> host->data_shift = 2;
> }
>
> + host->use_hold_reg = (mci_readl(host, HCON) >> 22) & 0x1;
> +
> /* Reset all blocks */
> if (!mci_wait_reset(&pdev->dev, host)) {
> ret = -ENODEV;
> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
> index bfa3c1c..8c4edca 100644
> --- a/drivers/mmc/host/dw_mmc.h
> +++ b/drivers/mmc/host/dw_mmc.h
> @@ -102,6 +102,7 @@
> #define SDMMC_INT_ERROR 0xbfc2
> /* Command register defines */
> #define SDMMC_CMD_START BIT(31)
> +#define SDMMC_CMD_USE_HOLD_REG BIT(29)
> #define SDMMC_CMD_CCS_EXP BIT(23)
> #define SDMMC_CMD_CEATA_RD BIT(22)
> #define SDMMC_CMD_UPD_CLK BIT(21)
> diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
> index 6b46819..d6d1515 100644
> --- a/include/linux/mmc/dw_mmc.h
> +++ b/include/linux/mmc/dw_mmc.h
> @@ -147,6 +147,7 @@ struct dw_mci {
> u32 current_speed;
> u32 num_slots;
> u32 fifoth_val;
> + bool use_hold_reg;
> struct platform_device *pdev;
> struct dw_mci_board *pdata;
> struct dw_mci_slot *slot[MAX_MCI_SLOTS];
> --
> 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] mmc: dw_mmc: Add check for IDMAC configuration
On 12 June 2012 15:14, Will Newton wrote: > On Tue, Jun 12, 2012 at 10:40 AM, Girish K S > wrote: >> On 12 June 2012 15:05, Will Newton wrote: >>> On Tue, Jun 12, 2012 at 10:01 AM, Girish K S >>> wrote: >>>> On 12 June 2012 14:25, Will Newton wrote: >>>>> On Tue, Jun 12, 2012 at 5:21 AM, Girish K S >>>>> wrote: >>>>>> >>>>>> In the Current dwmmc driver there is support for selecting IDMAC from >>>>>> the menu config option. If the support for IDMAC is enabled in the menu >>>>>> config and Hardware configuration register's DMA_INTERFACE field is 0. >>>>>> Still the driver will try to do the DMA initialization. >>>>>> >>>>>> The dw_mci_idmac_init function currently implemented returns only success >>>>>> indicating that the DMA initialization is always successful. The current >>>>>> patch will add a ciheck for existance of the DMA IP and allow the >>>>>> DMA initialization. >>>>>> >>>>>> Signed-off-by: Girish K S >>>>>> --- >>>>>> drivers/mmc/host/dw_mmc.c | 11 ++- >>>>>> 1 files changed, 10 insertions(+), 1 deletions(-) >>>>> >>>>> This looks ok in principle. I'm wondering if we should only allow >>>>> dma_support == 0x01 (DW_DMA) in the IDMAC case? It's not clear from >>>>> the TRM what each of the DMA values means and I only have a system >>>>> with external DMA support at the moment. >>>> My understanding from the TRM >>>> if dma_support =1; then use designware dma ip for internal >>>> dma_support =2 then use any generic dma ip for internal dma tx >>>> this config is only for IDMA support. If there is a external DMA CTRL >>>> register should be used explicitly to enable DMA (there is no config >>>> available to tell external dma supported). correct me if i am wrong. >>> >>> That sounds like a reasonable interpretation of the TRM. ;-) >>> >>> Acked-by: Will Newton >> I will resend the patch with minor change so that kernel doesnt crash >> but use PIO mode and continue even if IDMAC is enabled accidentally. >> what s your say? > > Yes, let's make sure it is robust against errors in configuration. i have tested the resent patch. scenario: 1. If IDMAC is enabled and if hardware actually doesnt have DMA controller. In that case it uses the PIO mode. provided the host->ring_size is initialized. thats the reson for moving the check below the ring_size initialize -- 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
[RESEND PATCH] mmc: dw_mmc: Add check for IDMAC configuration
In the Current dwmmc driver there is support for selecting IDMAC from
the menu config option. If the support for IDMAC is enabled in the menu
config and Hardware configuration register's DMA_INTERFACE field is 0.
Still the driver will try to do the DMA initialization.
The dw_mci_idmac_init function currently implemented returns only success
indicating that the DMA initialization is always successful. The current
patch will add a ciheck for existance of the DMA IP and allow the
DMA initialization.
Signed-off-by: Girish K S
---
drivers/mmc/host/dw_mmc.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index cbd8f3d..c485d1b 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -405,11 +405,23 @@ static void dw_mci_idmac_start_dma(struct dw_mci *host,
unsigned int sg_len)
static int dw_mci_idmac_init(struct dw_mci *host)
{
struct idmac_desc *p;
- int i;
+ int i, dma_support;
/* Number of descriptors in the ring buffer */
host->ring_size = PAGE_SIZE / sizeof(struct idmac_desc);
+ /* Check if Hardware Configuration Register has support for DMA */
+ dma_support = (mci_readl(host, HCON) >> 16) & 0x3;
+
+ if (!dma_support || dma_support > 2) {
+ dev_err(&host->dev,
+ "Host Controller does not support IDMA Tx.\n");
+ host->dma_ops = NULL;
+ return -ENODEV;
+ }
+
+ dev_info(&host->dev, "Using internal DMA controller.\n");
+
/* Forward link the descriptor list */
for (i = 0, p = host->sg_cpu; i < host->ring_size - 1; i++, p++)
p->des3 = host->sg_dma + (sizeof(struct idmac_desc) * (i + 1));
@@ -1871,7 +1883,6 @@ static void dw_mci_init_dma(struct dw_mci *host)
/* Determine which DMA interface to use */
#ifdef CONFIG_MMC_DW_IDMAC
host->dma_ops = &dw_mci_idmac_ops;
- dev_info(&host->dev, "Using internal DMA controller.\n");
#endif
if (!host->dma_ops)
--
1.7.4.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: dw_mmc: Add check for IDMAC configuration
On 12 June 2012 15:05, Will Newton wrote: > On Tue, Jun 12, 2012 at 10:01 AM, Girish K S > wrote: >> On 12 June 2012 14:25, Will Newton wrote: >>> On Tue, Jun 12, 2012 at 5:21 AM, Girish K S >>> wrote: >>>> >>>> In the Current dwmmc driver there is support for selecting IDMAC from >>>> the menu config option. If the support for IDMAC is enabled in the menu >>>> config and Hardware configuration register's DMA_INTERFACE field is 0. >>>> Still the driver will try to do the DMA initialization. >>>> >>>> The dw_mci_idmac_init function currently implemented returns only success >>>> indicating that the DMA initialization is always successful. The current >>>> patch will add a ciheck for existance of the DMA IP and allow the >>>> DMA initialization. >>>> >>>> Signed-off-by: Girish K S >>>> --- >>>> drivers/mmc/host/dw_mmc.c | 11 ++- >>>> 1 files changed, 10 insertions(+), 1 deletions(-) >>> >>> This looks ok in principle. I'm wondering if we should only allow >>> dma_support == 0x01 (DW_DMA) in the IDMAC case? It's not clear from >>> the TRM what each of the DMA values means and I only have a system >>> with external DMA support at the moment. >> My understanding from the TRM >> if dma_support =1; then use designware dma ip for internal >> dma_support =2 then use any generic dma ip for internal dma tx >> this config is only for IDMA support. If there is a external DMA CTRL >> register should be used explicitly to enable DMA (there is no config >> available to tell external dma supported). correct me if i am wrong. > > That sounds like a reasonable interpretation of the TRM. ;-) > > Acked-by: Will Newton I will resend the patch with minor change so that kernel doesnt crash but use PIO mode and continue even if IDMAC is enabled accidentally. what s your say? -- 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: dw_mmc: Add check for IDMAC configuration
On 12 June 2012 14:25, Will Newton wrote: > On Tue, Jun 12, 2012 at 5:21 AM, Girish K S > wrote: >> >> In the Current dwmmc driver there is support for selecting IDMAC from >> the menu config option. If the support for IDMAC is enabled in the menu >> config and Hardware configuration register's DMA_INTERFACE field is 0. >> Still the driver will try to do the DMA initialization. >> >> The dw_mci_idmac_init function currently implemented returns only success >> indicating that the DMA initialization is always successful. The current >> patch will add a ciheck for existance of the DMA IP and allow the >> DMA initialization. >> >> Signed-off-by: Girish K S >> --- >> drivers/mmc/host/dw_mmc.c | 11 ++- >> 1 files changed, 10 insertions(+), 1 deletions(-) > > This looks ok in principle. I'm wondering if we should only allow > dma_support == 0x01 (DW_DMA) in the IDMAC case? It's not clear from > the TRM what each of the DMA values means and I only have a system > with external DMA support at the moment. My understanding from the TRM if dma_support =1; then use designware dma ip for internal dma_support =2 then use any generic dma ip for internal dma tx this config is only for IDMA support. If there is a external DMA CTRL register should be used explicitly to enable DMA (there is no config available to tell external dma supported). correct me if i am wrong. -- 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
[PATCH] mmc: dw_mmc: Add check for IDMAC configuration
In the Current dwmmc driver there is support for selecting IDMAC from
the menu config option. If the support for IDMAC is enabled in the menu
config and Hardware configuration register's DMA_INTERFACE field is 0.
Still the driver will try to do the DMA initialization.
The dw_mci_idmac_init function currently implemented returns only success
indicating that the DMA initialization is always successful. The current
patch will add a ciheck for existance of the DMA IP and allow the
DMA initialization.
Signed-off-by: Girish K S
---
drivers/mmc/host/dw_mmc.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index cbd8f3d..9821293 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -405,7 +405,16 @@ static void dw_mci_idmac_start_dma(struct dw_mci *host,
unsigned int sg_len)
static int dw_mci_idmac_init(struct dw_mci *host)
{
struct idmac_desc *p;
- int i;
+ int i, dma_support;
+
+ /* Check if Hardware Configuration Register has support for DMA */
+ dma_support = (mci_readl(host, HCON) >> 16) & 0x3;
+
+ if (!dma_support || dma_support > 2) {
+ dev_err(&host->dev,
+ "Host Controller does not support DMA Tx.\n");
+ return -ENODEV;
+ }
/* Number of descriptors in the ring buffer */
host->ring_size = PAGE_SIZE / sizeof(struct idmac_desc);
--
1.7.4.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: power class selection fails on 3.5-rc1
On 8 June 2012 18:11, S, Venkatraman wrote: > On Mon, Jun 4, 2012 at 10:05 PM, Marc Dietrich wrote: >> Hi, >> >> somehow I hope this would go away by itself, but it didn't :-( I reported >> this >> problem some time ago (see: http://www.mail-archive.com/linux- >> m...@vger.kernel.org/msg13688.html ) but got no clear answer or fix. >> >> In addition to the information I posted on the thread above, I also dumped >> the >> contents of the ext_csd register file (where reg values are not zero): >> >> reg Sandisk Toshiba >> 241 10 0x0a 50 0x32 >> 239 0 0x00 51 0x33 >> 238 0 0x00 119 0x77 >> 234 0 0x00 30 0x1e >> 232 1 0x01 4 0x04 >> 231 21 0x15 21 0x15 >> 230 150 0x96 16 0x10 >> 229 150 0x96 66 0x42 >> 228 1 0x01 7 0x07 >> 226 8 0x08 16 0x10 >> 225 6 0x06 7 0x07 >> 224 4 0x04 8 0x08 >> 223 1 0x01 2 0x02 >> 222 8 0x08 16 0x10 >> 221 16 0x10 1 0x01 >> 220 8 0x08 7 0x07 >> 219 7 0x07 7 0x07 >> 217 16 0x10 17 0x11 >> 215 1 0x01 0 0x00 >> 214 218 0xda 238 0xee >> 213 160 0xa0 128 0x80 >> 210 10 0x0a 0 0x00 >> 209 10 0x0a 60 0x3c >> 208 10 0x0a 0 0x00 >> 207 10 0x0a 60 0x3c >> 206 10 0x0a 0 0x00 >> 205 10 0x0a 30 0x1e >> 203 0 0x00 51 0x33 >> 202 0 0x00 51 0x33 >> 201 0 0x00 119 0x77 >> 200 0 0x00 119 0x77 >> 196 3 0x03 7 0x07 >> 194 2 0x02 2 0x02 >> 192 5 0x05 5 0x05 >> 185 1 0x01 1 0x01 >> 181 0 0x00 1 0x01 >> 179 0 0x00 1 0x01 >> 175 0 0x00 1 0x01 >> 169 1 0x01 0 0x00 >> 168 0 0x00 2 0x02 >> 160 3 0x03 3 0x03 >> 158 0 0x00 3 0x03 >> 157 237 0xed 186 0xba >> >> The second and the third column is from a device with a Sandisk eMCC which >> works fine, while the last two columns are from a Toshiba eMMC which shows >> the >> error. Looking into it, I found that only the Toshiba eMMC specifies a >> powerclass in registers 203-200 while Sandisk does not, so the powerclass is >> not changed in the latter case and the problem cannot be triggered there. >> >> I also attached a boot log with mmc debug enabled. I think there is not much >> I >> can do else. Either this eMMC is just bogus and needs blacklisting or there >> is >> some problem in the driver code. >> > I am a bit rusty here, so bear with me. > According to the ext_csd, the power class value that should be sent to > the card was 0x7. (Upper nibble of ext_csd[201]). > > What I saw in the attached debug Log: > [ 3.842390] mmc1: starting CMD6 arg 03bb0301 flags 049d > This means write 0x03 into 0xBB register, and not 0x7 which is what is needed. > > While Marc has tried all values from 0 to 10, this wouldn't be the > definite issue, but I am wondering is there is some other problem. > > Or have I got it all wrong ? > ~Venkat. i was forcing 0x7b (for 8 bit width) upper nibble and i get it correct as below i got [1.172784] mmc0: starting CMD6 arg 03bb0701 flags 049d [1.172799] mmc_host mmc0: Bus speed (slot 0) = 6600Hz (slot req 5200 [1.176925] mmc0: req done (CMD6): 0: 0900 may be something wrong > -- > 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: power class selection fails on 3.5-rc1
On 7 June 2012 15:53, Subhash Jadavani wrote: >> > Just for experiment, can we hack the value set to POWER_CLASS field to >> > 0x7 instead of 0x3? If this doesn't work, you may try other values >> > (starting from 1 till 15) to see setting any of the non-zero value > succeeds or >> not. >> >> I tried 1 to 10 (as this is a 4.41 card) and none of them worked > (including 7). > > Oh, that's not good. > > Girish / Saugata, > Do you have any comments on this? Can you please comment on what type of > testing was done when we had initially added this power class selection? Today i tried om the eMMC 4.5 sample. I forced the values from 1- 10 I was able to successfully set the power class value without any error return value. It failed for the for the value 0xf. > > Regards, > Subhash > >> -Original Message- >> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- >> ow...@vger.kernel.org] On Behalf Of Marc Dietrich >> Sent: Thursday, June 07, 2012 3:05 PM >> To: Subhash Jadavani >> Cc: 'Ulf Hansson'; Girish K S; saugata@linaro.org; linux- >> m...@vger.kernel.org >> Subject: Re: power class selection fails on 3.5-rc1 >> >> On Wednesday 06 June 2012 15:14:48 Subhash Jadavani wrote: >> > > On 06/04/2012 06:35 PM, Marc Dietrich wrote: >> > > > Hi, >> > > > >> > > > somehow I hope this would go away by itself, but it didn't :-( I >> > > > reported this problem some time ago (see: >> > > > http://www.mail-archive.com/linux- >> > > > m...@vger.kernel.org/msg13688.html ) but got no clear answer or fix. >> > > > >> > > > In addition to the information I posted on the thread above, I >> > > > also dumped the contents of the ext_csd register file (where reg >> > > > values are not zero): >> > > > >> > > > reg Sandisk Toshiba >> > > > 241 10 0x0a 50 0x32 >> > > > 239 0 0x00 51 0x33 >> > > > 238 0 0x00 119 0x77 >> > > > 234 0 0x00 30 0x1e >> > > > 232 1 0x01 4 0x04 >> > > > 231 21 0x15 21 0x15 >> > > > 230 150 0x96 16 0x10 >> > > > 229 150 0x96 66 0x42 >> > > > 228 1 0x01 7 0x07 >> > > > 226 8 0x08 16 0x10 >> > > > 225 6 0x06 7 0x07 >> > > > 224 4 0x04 8 0x08 >> > > > 223 1 0x01 2 0x02 >> > > > 222 8 0x08 16 0x10 >> > > > 221 16 0x10 1 0x01 >> > > > 220 8 0x08 7 0x07 >> > > > 219 7 0x07 7 0x07 >> > > > 217 16 0x10 17 0x11 >> > > > 215 1 0x01 0 0x00 >> > > > 214 218 0xda 238 0xee >> > > > 213 160 0xa0 128 0x80 >> > > > 210 10 0x0a 0 0x00 >> > > > 209 10 0x0a 60 0x3c >> > > > 208 10 0x0a 0 0x00 >> > > > 207 10 0x0a 60 0x3c >> > > > 206 10 0x0a 0 0x00 >> > > > 205 10 0x0a 30 0x1e >> > > > 203 0 0x00 51 0x33 >> > > > 202 0 0x00 51 0x33 >> > > > 201 0 0x00 119 0x77 >> > > > 200 0 0x00 119 0x77 >> > > > 196 3 0x03 7 0x07 >> > > > 194 2 0x02 2 0x02 >> > > > 192 5 0x05 5 0x05 >> > > > 185 1 0x01 1 0x01 >> > > > 181 0 0x00 1 0x01 >> > > > 179 0 0x00 1 0x01 >> > > > 175 0 0x00 1 0x01 >> > > > 169 1 0x01 0 0x00 >> > > > 168 0 0x00 2 0x02 >> > > > 160 3 0x03 3 0x03 >> > > > 158 0 0x00 3 0x03 >> > > > 157 237 0xed 186 0xba >> > > > >> > > > The second and the third column is from a device with a Sandisk >> > > > eMCC which works fine, while the last two columns are from a >> > > > Toshiba eMMC which shows th
Re: [PATCH v5] MMC-4.5 Power OFF Notify Rework
On 28 May 2012 16:33, Subhash Jadavani wrote:
> Hi Girish, Saugata,
>
> There is an issue with this patch during resume. Please find comments inline
> below:
This is a patch for poweroff_notification. If CAP2 is enabled with
CAP2_POWEROFF_NOTIFY, you never enter the sleep path.
>
>> -Original Message-----
>> From: Girish K S [mailto:girish.shivananja...@linaro.org]
>> Sent: Tuesday, May 22, 2012 5:15 PM
>> To: linux-mmc@vger.kernel.org
>> Cc: c...@laptop.org; patc...@linaro.org; ulf.hans...@stericsson.com;
>> saugata....@linaro.org; subha...@codeaurora.org; Girish K S
>> Subject: [PATCH v5] MMC-4.5 Power OFF Notify Rework
>>
>> From: Saugata Das
>>
>> This is a rework of the existing POWER OFF NOTIFY patch. The current
> problem
>> with the patch comes from the ambiguity on the usage of POWER OFF NOTIFY
>> together with SLEEP and misunderstanding on the usage of MMC_POWER_OFF
>> power_mode from mmc_set_ios in different host controller drivers.
>>
>> This new patch works around this problem by adding a new host CAP,
>> MMC_CAP2_POWER_OFF_VCCQ_DURING_SUSPEND, which when set sends a
>> POWER OFF NOTIFY from mmc_suspend instead of SLEEP. It is expected that
>> host controller drivers will set this CAP, if they switch off both Vcc and
> Vccq
>> from MMC_POWER_OFF condition within mmc_set_ios. However, note that
>> there is no harm in sending MMC_POWER_NOTIFY even if Vccq is not switched
>> off.
>>
>> This patch also sends POWER OFF NOTIFY from power management routines
>> (e.g.
>> mmc_power_save_host, mmc_pm_notify/PM_SUSPEND_PREPARE,
>> mmc_stop_host), which does reinitialization of the eMMC on the return path
> of
>> the power management routines (e.g. mmc_power_restore_host,
>> mmc_pm_notify/PM_POST_RESTORE, mmc_start_host).
>>
>> This patch sets POWER_OFF_NOTIFICATION to POWER_OFF_SHORT if it is sent
>> from the suspend sequence. If it is sent from shutdown sequence then it is
> set
>> to POWER_OFF_LONG.
>>
>> Earlier implementation of PowerOff Notify as a core function is replaced
> as a
>> device's bus operation.
>>
>> Signed-off-by: Saugata Das
>> Signed-off-by: Girish K S
>>
>> changes in v5:
>> modified the the handling of return value in mmc_poweroff_notify.
>> changes in v4:
>> As suggested in review,
>> - Moved mmc_can_poweroff_notify to core.c
>> - Moved mmc_claim_host, mmc_release_host outside
>> mmc_poweroff_notify
>> - Added check for wrong initialization for poweroff_notify_type
>> - mmc_poweroff_notify is modified to take as 2nd parameter changes
>> in v3:
>> This version addresses the review comments given by Subhash and Ulf
>> changes in v2:
>> This version addresses the changes suggested by Ulf
>> ---
>> drivers/mmc/core/core.c | 108
> ++--
>> drivers/mmc/core/core.h | 1 +
>> drivers/mmc/core/mmc.c | 56 ---
>> drivers/mmc/host/dw_mmc.c | 5 --
>> drivers/mmc/host/sdhci.c | 9
>> include/linux/mmc/card.h | 5 +-
>> include/linux/mmc/core.h | 1 +
>> include/linux/mmc/host.h | 5 +--
>> include/linux/mmc/mmc.h | 7 +++
>> 9 files changed, 104 insertions(+), 93 deletions(-)
>>
>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index
>> 0b6141d..fe616b9 100644
>> --- a/drivers/mmc/core/core.c
>> +++ b/drivers/mmc/core/core.c
>> @@ -1101,48 +1101,6 @@ void mmc_set_driver_type(struct mmc_host *host,
>> unsigned int drv_type)
>> mmc_host_clk_release(host);
>> }
>>
>> -static void mmc_poweroff_notify(struct mmc_host *host) -{
>> - struct mmc_card *card;
>> - unsigned int timeout;
>> - unsigned int notify_type = EXT_CSD_NO_POWER_NOTIFICATION;
>> - int err = 0;
>> -
>> - card = host->card;
>> - mmc_claim_host(host);
>> -
>> - /*
>> - * Send power notify command only if card
>> - * is mmc and notify state is powered ON
>> - */
>> - if (card && mmc_card_mmc(card) &&
>> - (card->poweroff_notify_state == MMC_POWERED_ON)) {
>> -
>> - if (host->power_notify_type ==
>> MMC_HOST_PW_NOTIFY_SHORT) {
>> - notify_type = EXT_CSD_POWER_OFF_SHORT;
>> - timeout = card->ext_csd.generic_cmd6_time;
>> - card->poweroff_notify_state =
>> MMC_POWEROFF_SHORT;
>> -
[PATCH v5] MMC-4.5 Power OFF Notify Rework
From: Saugata Das
This is a rework of the existing POWER OFF NOTIFY patch. The current problem
with the patch comes from the ambiguity on the usage of POWER OFF NOTIFY
together with SLEEP and misunderstanding on the usage of MMC_POWER_OFF
power_mode from mmc_set_ios in different host controller drivers.
This new patch works around this problem by adding a new host CAP,
MMC_CAP2_POWER_OFF_VCCQ_DURING_SUSPEND, which when set sends a
POWER OFF NOTIFY from mmc_suspend instead of SLEEP. It is expected that host
controller drivers will set this CAP, if they switch off both Vcc and Vccq
from MMC_POWER_OFF condition within mmc_set_ios. However, note that there
is no harm in sending MMC_POWER_NOTIFY even if Vccq is not switched off.
This patch also sends POWER OFF NOTIFY from power management routines (e.g.
mmc_power_save_host, mmc_pm_notify/PM_SUSPEND_PREPARE, mmc_stop_host), which
does reinitialization of the eMMC on the return path of the power management
routines (e.g. mmc_power_restore_host, mmc_pm_notify/PM_POST_RESTORE,
mmc_start_host).
This patch sets POWER_OFF_NOTIFICATION to POWER_OFF_SHORT if it is sent from
the suspend sequence. If it is sent from shutdown sequence then it is set to
POWER_OFF_LONG.
Earlier implementation of PowerOff Notify as a core function is replaced as
a device's bus operation.
Signed-off-by: Saugata Das
Signed-off-by: Girish K S
changes in v5:
modified the the handling of return value in mmc_poweroff_notify.
changes in v4:
As suggested in review,
- Moved mmc_can_poweroff_notify to core.c
- Moved mmc_claim_host, mmc_release_host outside mmc_poweroff_notify
- Added check for wrong initialization for poweroff_notify_type
- mmc_poweroff_notify is modified to take as 2nd parameter
changes in v3:
This version addresses the review comments given by Subhash and Ulf
changes in v2:
This version addresses the changes suggested by Ulf
---
drivers/mmc/core/core.c | 108 ++--
drivers/mmc/core/core.h |1 +
drivers/mmc/core/mmc.c| 56 ---
drivers/mmc/host/dw_mmc.c |5 --
drivers/mmc/host/sdhci.c |9
include/linux/mmc/card.h |5 +-
include/linux/mmc/core.h |1 +
include/linux/mmc/host.h |5 +--
include/linux/mmc/mmc.h |7 +++
9 files changed, 104 insertions(+), 93 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 0b6141d..fe616b9 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1101,48 +1101,6 @@ void mmc_set_driver_type(struct mmc_host *host, unsigned
int drv_type)
mmc_host_clk_release(host);
}
-static void mmc_poweroff_notify(struct mmc_host *host)
-{
- struct mmc_card *card;
- unsigned int timeout;
- unsigned int notify_type = EXT_CSD_NO_POWER_NOTIFICATION;
- int err = 0;
-
- card = host->card;
- mmc_claim_host(host);
-
- /*
-* Send power notify command only if card
-* is mmc and notify state is powered ON
-*/
- if (card && mmc_card_mmc(card) &&
- (card->poweroff_notify_state == MMC_POWERED_ON)) {
-
- if (host->power_notify_type == MMC_HOST_PW_NOTIFY_SHORT) {
- notify_type = EXT_CSD_POWER_OFF_SHORT;
- timeout = card->ext_csd.generic_cmd6_time;
- card->poweroff_notify_state = MMC_POWEROFF_SHORT;
- } else {
- notify_type = EXT_CSD_POWER_OFF_LONG;
- timeout = card->ext_csd.power_off_longtime;
- card->poweroff_notify_state = MMC_POWEROFF_LONG;
- }
-
- err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
-EXT_CSD_POWER_OFF_NOTIFICATION,
-notify_type, timeout);
-
- if (err && err != -EBADMSG)
- pr_err("Device failed to respond within %d poweroff "
- "time. Forcefully powering down the device\n",
- timeout);
-
- /* Set the card state to no notification after the poweroff */
- card->poweroff_notify_state = MMC_NO_POWER_NOTIFICATION;
- }
- mmc_release_host(host);
-}
-
/*
* Apply power to the MMC stack. This is a two-stage process.
* First, we enable power to the card without the clock running.
@@ -1202,8 +1160,6 @@ static void mmc_power_up(struct mmc_host *host)
void mmc_power_off(struct mmc_host *host)
{
- int err = 0;
-
if (host->ios.power_mode == MMC_POWER_OFF)
return;
@@ -1212,22 +1168,6 @@ void mmc_power_off(struct mmc_host *host)
host->ios.clock = 0;
host->ios.vdd = 0;
- /*
-* For eMMC 4.5 device send AWAKE command before
-* POWER_OFF_
[PATCH v3] MMC-4.5 Power OFF Notify Rework
From: Saugata Das
This is a rework of the existing POWER OFF NOTIFY patch. The current problem
with the patch comes from the ambiguity on the usage of POWER OFF NOTIFY
together with SLEEP and misunderstanding on the usage of MMC_POWER_OFF
power_mode from mmc_set_ios in different host controller drivers.
This new patch works around this problem by adding a new host CAP,
MMC_CAP2_POWER_OFF_VCCQ_DURING_SUSPEND, which when set sends a
POWER OFF NOTIFY from mmc_suspend instead of SLEEP. It is expected that host
controller drivers will set this CAP, if they switch off both Vcc and Vccq
from MMC_POWER_OFF condition within mmc_set_ios. However, note that there
is no harm in sending MMC_POWER_NOTIFY even if Vccq is not switched off.
This patch also sends POWER OFF NOTIFY from power management routines (e.g.
mmc_power_save_host, mmc_pm_notify/PM_SUSPEND_PREPARE, mmc_stop_host), which
does reinitialization of the eMMC on the return path of the power management
routines (e.g. mmc_power_restore_host, mmc_pm_notify/PM_POST_RESTORE,
mmc_start_host).
This patch sets POWER_OFF_NOTIFICATION to POWER_OFF_SHORT if it is sent from
the suspend sequence. If it is sent from shutdown sequence then it is set to
POWER_OFF_LONG.
Previuos implementation of PowerOff Notify as a core function is replaced as
a device's bus operation.
Signed-off-by: Saugata Das
Signed-off-by: Girish K S
changes in v4:
As suggested in review,
- Moved mmc_can_poweroff_notify to core.c
- Moved mmc_claim_host, mmc_release_host outside mmc_poweroff_notify
- Added check for wrong initialization for poweroff_notify_type
- mmc_poweroff_notify is modified to take as 2nd parameter
changes in v3:
This version addresses the review comments given by Subhash and Ulf
changes in v2:
This version addresses the changes suggested by Ulf
---
drivers/mmc/core/core.c | 106 ++---
drivers/mmc/core/core.h |1 +
drivers/mmc/core/mmc.c| 56 ---
drivers/mmc/host/dw_mmc.c |5 --
drivers/mmc/host/sdhci.c |9
include/linux/mmc/card.h |5 +-
include/linux/mmc/core.h |1 +
include/linux/mmc/host.h |5 +--
include/linux/mmc/mmc.h |7 +++
9 files changed, 102 insertions(+), 93 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 0b6141d..3011122 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1101,48 +1101,6 @@ void mmc_set_driver_type(struct mmc_host *host, unsigned
int drv_type)
mmc_host_clk_release(host);
}
-static void mmc_poweroff_notify(struct mmc_host *host)
-{
- struct mmc_card *card;
- unsigned int timeout;
- unsigned int notify_type = EXT_CSD_NO_POWER_NOTIFICATION;
- int err = 0;
-
- card = host->card;
- mmc_claim_host(host);
-
- /*
-* Send power notify command only if card
-* is mmc and notify state is powered ON
-*/
- if (card && mmc_card_mmc(card) &&
- (card->poweroff_notify_state == MMC_POWERED_ON)) {
-
- if (host->power_notify_type == MMC_HOST_PW_NOTIFY_SHORT) {
- notify_type = EXT_CSD_POWER_OFF_SHORT;
- timeout = card->ext_csd.generic_cmd6_time;
- card->poweroff_notify_state = MMC_POWEROFF_SHORT;
- } else {
- notify_type = EXT_CSD_POWER_OFF_LONG;
- timeout = card->ext_csd.power_off_longtime;
- card->poweroff_notify_state = MMC_POWEROFF_LONG;
- }
-
- err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
-EXT_CSD_POWER_OFF_NOTIFICATION,
-notify_type, timeout);
-
- if (err && err != -EBADMSG)
- pr_err("Device failed to respond within %d poweroff "
- "time. Forcefully powering down the device\n",
- timeout);
-
- /* Set the card state to no notification after the poweroff */
- card->poweroff_notify_state = MMC_NO_POWER_NOTIFICATION;
- }
- mmc_release_host(host);
-}
-
/*
* Apply power to the MMC stack. This is a two-stage process.
* First, we enable power to the card without the clock running.
@@ -1202,8 +1160,6 @@ static void mmc_power_up(struct mmc_host *host)
void mmc_power_off(struct mmc_host *host)
{
- int err = 0;
-
if (host->ios.power_mode == MMC_POWER_OFF)
return;
@@ -1212,22 +1168,6 @@ void mmc_power_off(struct mmc_host *host)
host->ios.clock = 0;
host->ios.vdd = 0;
- /*
-* For eMMC 4.5 device send AWAKE command before
-* POWER_OFF_NOTIFY command, because in sleep state
-* eMMC 4.5 devices respond to only RESE
Re: [PATCH v3 2/2] mmc4.5: host: poweroff notify rework
On 14 May 2012 14:26, Girish K S wrote:
> On 14 May 2012 12:50, Ulf Hansson wrote:
>> Hi Girish,
>>
>> In patch 1/2 you break the compilation of these host drivers. In this patch
>> 2/2 you fix it again. I would prefer you include these fixes in the same
>> patch instead of splitting them into two pieces.
> It is a patch series. I have no issue in making it as a single patch.
I will make the changes affecting the host as a separate patch.
>>
>> Kind regards
>> Ulf Hansson
>>
>>
>> On 05/07/2012 03:41 PM, Girish K S wrote:
>>>
>>> This patch changes the structure member name to maintain consistency
>>> of name for the poweroff notify feature
>>>
>>> Signed-off-by: Girish K S
>>> ---
>>> drivers/mmc/host/dw_mmc.c | 4 ++--
>>> drivers/mmc/host/sdhci.c | 4 ++--
>>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>> index ab3fc46..09ac734 100644
>>> --- a/drivers/mmc/host/dw_mmc.c
>>> +++ b/drivers/mmc/host/dw_mmc.c
>>> @@ -1791,9 +1791,9 @@ static int __init dw_mci_init_slot(struct dw_mci
>>> *host, unsigned int id)
>>> mmc->caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED;
>>>
>>> if (mmc->caps2& MMC_CAP2_POWEROFF_NOTIFY)
>>>
>>> - mmc->power_notify_type = MMC_HOST_PW_NOTIFY_SHORT;
>>> + mmc->poweroff_notify_type = MMC_HOST_PW_OFF_NOTIFY_SHORT;
>>> else
>>> - mmc->power_notify_type = MMC_HOST_PW_NOTIFY_NONE;
>>> + mmc->poweroff_notify_type = MMC_HOST_PW_OFF_NOTIFY_NONE;
>>>
>>> if (host->pdata->blk_settings) {
>>> mmc->max_segs = host->pdata->blk_settings->max_segs;
>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> index e626732..958e5fe 100644
>>> --- a/drivers/mmc/host/sdhci.c
>>> +++ b/drivers/mmc/host/sdhci.c
>>> @@ -2817,9 +2817,9 @@ int sdhci_add_host(struct sdhci_host *host)
>>> * set notify to short power off notify timeout value.
>>> */
>>> if (mmc->caps2& MMC_CAP2_POWEROFF_NOTIFY)
>>>
>>> - mmc->power_notify_type = MMC_HOST_PW_NOTIFY_SHORT;
>>> + mmc->poweroff_notify_type = MMC_HOST_PW_OFF_NOTIFY_SHORT;
>>> else
>>> - mmc->power_notify_type = MMC_HOST_PW_NOTIFY_NONE;
>>> + mmc->poweroff_notify_type = MMC_HOST_PW_OFF_NOTIFY_NONE;
>>>
>>> /* Initial value for re-tuning timer count */
>>> host->tuning_count = (caps[1]& SDHCI_RETUNING_TIMER_COUNT_MASK)>>
>>
>>
--
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 v3 2/2] mmc4.5: host: poweroff notify rework
On 14 May 2012 12:50, Ulf Hansson wrote:
> Hi Girish,
>
> In patch 1/2 you break the compilation of these host drivers. In this patch
> 2/2 you fix it again. I would prefer you include these fixes in the same
> patch instead of splitting them into two pieces.
It is a patch series. I have no issue in making it as a single patch.
>
> Kind regards
> Ulf Hansson
>
>
> On 05/07/2012 03:41 PM, Girish K S wrote:
>>
>> This patch changes the structure member name to maintain consistency
>> of name for the poweroff notify feature
>>
>> Signed-off-by: Girish K S
>> ---
>> drivers/mmc/host/dw_mmc.c | 4 ++--
>> drivers/mmc/host/sdhci.c | 4 ++--
>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index ab3fc46..09ac734 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -1791,9 +1791,9 @@ static int __init dw_mci_init_slot(struct dw_mci
>> *host, unsigned int id)
>> mmc->caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED;
>>
>> if (mmc->caps2& MMC_CAP2_POWEROFF_NOTIFY)
>>
>> - mmc->power_notify_type = MMC_HOST_PW_NOTIFY_SHORT;
>> + mmc->poweroff_notify_type = MMC_HOST_PW_OFF_NOTIFY_SHORT;
>> else
>> - mmc->power_notify_type = MMC_HOST_PW_NOTIFY_NONE;
>> + mmc->poweroff_notify_type = MMC_HOST_PW_OFF_NOTIFY_NONE;
>>
>> if (host->pdata->blk_settings) {
>> mmc->max_segs = host->pdata->blk_settings->max_segs;
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index e626732..958e5fe 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -2817,9 +2817,9 @@ int sdhci_add_host(struct sdhci_host *host)
>> * set notify to short power off notify timeout value.
>> */
>> if (mmc->caps2& MMC_CAP2_POWEROFF_NOTIFY)
>>
>> - mmc->power_notify_type = MMC_HOST_PW_NOTIFY_SHORT;
>> + mmc->poweroff_notify_type = MMC_HOST_PW_OFF_NOTIFY_SHORT;
>> else
>> - mmc->power_notify_type = MMC_HOST_PW_NOTIFY_NONE;
>> + mmc->poweroff_notify_type = MMC_HOST_PW_OFF_NOTIFY_NONE;
>>
>> /* Initial value for re-tuning timer count */
>> host->tuning_count = (caps[1]& SDHCI_RETUNING_TIMER_COUNT_MASK)>>
>
>
--
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
[PATCH v3 2/2] mmc4.5: host: poweroff notify rework
This patch changes the structure member name to maintain consistency
of name for the poweroff notify feature
Signed-off-by: Girish K S
---
drivers/mmc/host/dw_mmc.c |4 ++--
drivers/mmc/host/sdhci.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index ab3fc46..09ac734 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1791,9 +1791,9 @@ static int __init dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
mmc->caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED;
if (mmc->caps2 & MMC_CAP2_POWEROFF_NOTIFY)
- mmc->power_notify_type = MMC_HOST_PW_NOTIFY_SHORT;
+ mmc->poweroff_notify_type = MMC_HOST_PW_OFF_NOTIFY_SHORT;
else
- mmc->power_notify_type = MMC_HOST_PW_NOTIFY_NONE;
+ mmc->poweroff_notify_type = MMC_HOST_PW_OFF_NOTIFY_NONE;
if (host->pdata->blk_settings) {
mmc->max_segs = host->pdata->blk_settings->max_segs;
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index e626732..958e5fe 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2817,9 +2817,9 @@ int sdhci_add_host(struct sdhci_host *host)
* set notify to short power off notify timeout value.
*/
if (mmc->caps2 & MMC_CAP2_POWEROFF_NOTIFY)
- mmc->power_notify_type = MMC_HOST_PW_NOTIFY_SHORT;
+ mmc->poweroff_notify_type = MMC_HOST_PW_OFF_NOTIFY_SHORT;
else
- mmc->power_notify_type = MMC_HOST_PW_NOTIFY_NONE;
+ mmc->poweroff_notify_type = MMC_HOST_PW_OFF_NOTIFY_NONE;
/* Initial value for re-tuning timer count */
host->tuning_count = (caps[1] & SDHCI_RETUNING_TIMER_COUNT_MASK) >>
--
1.7.4.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
[PATCH v3 1/2] MMC-4.5 Power OFF Notify rework
This is a rework of the existing POWER OFF NOTIFY patch. The current problem
with the patch comes from the ambiguity on the usage of POWER OFF NOTIFY
together with SLEEP and misunderstanding on the usage of MMC_POWER_OFF
power_mode from mmc_set_ios in different host controller drivers.
This new patch works around this problem by adding a new host CAP,
MMC_CAP2_POWER_OFF_VCCQ_DURING_SUSPEND, which when set sends a
POWER OFF NOTIFY from mmc_suspend instead of SLEEP. It is expected that host
controller drivers will set this CAP, if they switch off both Vcc and Vccq
from MMC_POWER_OFF condition within mmc_set_ios. However, note that there
is no harm in sending MMC_POWER_NOTIFY even if Vccq is not switched off.
This patch also sends POWER OFF NOTIFY from power management routines (e.g.
mmc_power_save_host, mmc_pm_notify/PM_SUSPEND_PREPARE, mmc_stop_host), which
does reinitialization of the eMMC on the return path of the power management
routines (e.g. mmc_power_restore_host, mmc_pm_notify/PM_POST_RESTORE,
mmc_start_host).
This patch sets POWER_OFF_NOTIFICATION to POWER_OFF_SHORT if it is sent from
the suspend sequence. If it is sent from shutdown sequence then it is set to
POWER_OFF_LONG.
Previuos implementation of PowerOff Notify as a core function is replaced as
a device's bus operation.
Signed-off-by: Saugata Das
Signed-off-by: Girish K S
changes in v3:
This version addresses the review comments given by Subhash and Ulf
changes in v2:
This version addresses the changes suggested by Ulf
---
drivers/mmc/core/core.c | 98 +++---
drivers/mmc/core/core.h |1 +
drivers/mmc/core/mmc.c | 73 --
include/linux/mmc/card.h |8 +++-
include/linux/mmc/host.h |9 ++--
5 files changed, 105 insertions(+), 84 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index ba821fe..3db3b32 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1100,48 +1100,6 @@ void mmc_set_driver_type(struct mmc_host *host, unsigned
int drv_type)
mmc_host_clk_release(host);
}
-static void mmc_poweroff_notify(struct mmc_host *host)
-{
- struct mmc_card *card;
- unsigned int timeout;
- unsigned int notify_type = EXT_CSD_NO_POWER_NOTIFICATION;
- int err = 0;
-
- card = host->card;
- mmc_claim_host(host);
-
- /*
-* Send power notify command only if card
-* is mmc and notify state is powered ON
-*/
- if (card && mmc_card_mmc(card) &&
- (card->poweroff_notify_state == MMC_POWERED_ON)) {
-
- if (host->power_notify_type == MMC_HOST_PW_NOTIFY_SHORT) {
- notify_type = EXT_CSD_POWER_OFF_SHORT;
- timeout = card->ext_csd.generic_cmd6_time;
- card->poweroff_notify_state = MMC_POWEROFF_SHORT;
- } else {
- notify_type = EXT_CSD_POWER_OFF_LONG;
- timeout = card->ext_csd.power_off_longtime;
- card->poweroff_notify_state = MMC_POWEROFF_LONG;
- }
-
- err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
-EXT_CSD_POWER_OFF_NOTIFICATION,
-notify_type, timeout);
-
- if (err && err != -EBADMSG)
- pr_err("Device failed to respond within %d poweroff "
- "time. Forcefully powering down the device\n",
- timeout);
-
- /* Set the card state to no notification after the poweroff */
- card->poweroff_notify_state = MMC_NO_POWER_NOTIFICATION;
- }
- mmc_release_host(host);
-}
-
/*
* Apply power to the MMC stack. This is a two-stage process.
* First, we enable power to the card without the clock running.
@@ -1198,30 +1156,12 @@ static void mmc_power_up(struct mmc_host *host)
void mmc_power_off(struct mmc_host *host)
{
- int err = 0;
mmc_host_clk_hold(host);
host->ios.clock = 0;
host->ios.vdd = 0;
/*
-* For eMMC 4.5 device send AWAKE command before
-* POWER_OFF_NOTIFY command, because in sleep state
-* eMMC 4.5 devices respond to only RESET and AWAKE cmd
-*/
- if (host->card && mmc_card_is_sleep(host->card) &&
- host->bus_ops->resume) {
- err = host->bus_ops->resume(host);
-
- if (!err)
- mmc_poweroff_notify(host);
- else
- pr_warning("%s: error %d during resume "
- "(continue with poweroff sequence)\n",
- mmc_hostname(host), err);
- }
-
- /*
* Reset ocr mask to be
Re: [PATCH V2] MMC-4.5 Power OFF Notify rework
On 30 April 2012 18:39, Subhash Jadavani wrote:
> On 4/30/2012 11:44 AM, Girish K S wrote:
>>
>> This is a rework of the existing POWER OFF NOTIFY patch. The current
>> problem
>> with the patch comes from the ambiguity on the usage of POWER OFF NOTIFY
>> together with SLEEP and misunderstanding on the usage of MMC_POWER_OFF
>> power_mode from mmc_set_ios in different host controller drivers.
>>
>> This new patch works around this problem by adding a new host CAP,
>> MMC_CAP2_POWER_OFF_VCCQ_DURING_SUSPEND, which when set sends a
>> POWER OFF NOTIFY from mmc_suspend instead of SLEEP. It is expected that
>> host
>> controller drivers will set this CAP, if they switch off both Vcc and Vccq
>> from MMC_POWER_OFF condition within mmc_set_ios. However, note that there
>> is no harm in sending MMC_POWER_NOTIFY even if Vccq is not switched off.
>
> What the specification mandates? Does it expect the host to turn off both
> VCC and VCCQ rails after power off notification (short/long)? What if we
> send the power off notification (short/long) but still don't turn off either
> VCCQ or VCC or both?
>
>>
>> This patch also sends POWER OFF NOTIFY from power management routines
>> (e.g.
>> mmc_power_save_host, mmc_pm_notify/PM_SUSPEND_PREPARE, mmc_stop_host),
>> which
>> does reinitialization of the eMMC on the return path of the power
>> management
>> routines (e.g. mmc_power_restore_host, mmc_pm_notify/PM_POST_RESTORE,
>> mmc_start_host).
>>
>> This patch sets POWER_OFF_NOTIFICATION to POWER_OFF_SHORT if it is sent
>> from
>> the suspend sequence. If it is sent from shutdown sequence then it is set
>> to
>> POWER_OFF_LONG.
>>
>> Previuos implementation of PowerOff Notify as a core function is replaced
>> as
>> a device's bus operation.
>>
>> Signed-off-by: Saugata Das
>> Signed-off-by: Girish K S
>> ---
>> drivers/mmc/core/core.c | 95
>> +++--
>> drivers/mmc/core/core.h | 1 +
>> drivers/mmc/core/mmc.c | 76 +++--
>> include/linux/mmc/host.h | 1 +
>> 4 files changed, 98 insertions(+), 75 deletions(-)
>>
>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>> index ba821fe..7f5461e 100644
>> --- a/drivers/mmc/core/core.c
>> +++ b/drivers/mmc/core/core.c
>> @@ -1100,48 +1100,6 @@ void mmc_set_driver_type(struct mmc_host *host,
>> unsigned int drv_type)
>> mmc_host_clk_release(host);
>> }
>>
>> -static void mmc_poweroff_notify(struct mmc_host *host)
>> -{
>> - struct mmc_card *card;
>> - unsigned int timeout;
>> - unsigned int notify_type = EXT_CSD_NO_POWER_NOTIFICATION;
>> - int err = 0;
>> -
>> - card = host->card;
>> - mmc_claim_host(host);
>> -
>> - /*
>> - * Send power notify command only if card
>> - * is mmc and notify state is powered ON
>> - */
>> - if (card&& mmc_card_mmc(card)&&
>> - (card->poweroff_notify_state == MMC_POWERED_ON)) {
>> -
>> - if (host->power_notify_type == MMC_HOST_PW_NOTIFY_SHORT) {
>> - notify_type = EXT_CSD_POWER_OFF_SHORT;
>> - timeout = card->ext_csd.generic_cmd6_time;
>> - card->poweroff_notify_state = MMC_POWEROFF_SHORT;
>> - } else {
>> - notify_type = EXT_CSD_POWER_OFF_LONG;
>> - timeout = card->ext_csd.power_off_longtime;
>> - card->poweroff_notify_state = MMC_POWEROFF_LONG;
>> - }
>> -
>> - err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>> - EXT_CSD_POWER_OFF_NOTIFICATION,
>> - notify_type, timeout);
>> -
>> - if (err&& err != -EBADMSG)
>>
>> - pr_err("Device failed to respond within %d
>> poweroff "
>> - "time. Forcefully powering down the
>> device\n",
>> - timeout);
>> -
>> - /* Set the card state to no notification after the
>> poweroff */
>> - card->poweroff_notify_state = MMC_NO_POWER_NOTIFICATION;
>> - }
>> - mmc_release_host(host);
>> -}
>> -
>> /*
>> * Apply power to the MMC stack. This is a two-stag
