* [PATCH 06/13] mmc: core: move the cookie's enum values from sdhci.h to mmc.h
From: Jaehoon Chung @ 2016-11-03 6:21 UTC (permalink / raw)
To: linux-mmc
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-rockchip, ulf.hansson, robh+dt, krzk, heiko, shawn.lin,
Jaehoon Chung
In-Reply-To: <20161103062135.10697-1-jh80.chung@samsung.com>
It's not for only sdhci controller.
So it can be moved from sdhci.h to mmc.h. And renamed from sdhci_cookie
to mmc_cookie.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
---
drivers/mmc/host/sdhci.h | 6 ------
include/linux/mmc/core.h | 6 ++++++
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 766df17..325663b 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -321,12 +321,6 @@ struct sdhci_adma2_64_desc {
/* Allow for a a command request and a data request at the same time */
#define SDHCI_MAX_MRQS 2
-enum sdhci_cookie {
- COOKIE_UNMAPPED,
- COOKIE_PRE_MAPPED, /* mapped by sdhci_pre_req() */
- COOKIE_MAPPED, /* mapped by sdhci_prepare_data() */
-};
-
struct sdhci_host {
/* Data set by hardware interface driver */
const char *hw_name; /* Hardware bus name */
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index 2b953eb..d23a675 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -106,6 +106,12 @@ struct mmc_command {
struct mmc_request *mrq; /* associated request */
};
+enum mmc_cookie {
+ COOKIE_UNMAPPED,
+ COOKIE_PRE_MAPPED, /* mapped by pre_req() of controller */
+ COOKIE_MAPPED, /* mapped by prepare_data() of controller */
+};
+
struct mmc_data {
unsigned int timeout_ns; /* data timeout (in ns, max 80ms) */
unsigned int timeout_clks; /* data timeout (in clocks) */
--
2.10.1
^ permalink raw reply related
* [PATCH 04/13] mmc: dw_mmc: use the hold register when send stop command
From: Jaehoon Chung @ 2016-11-03 6:21 UTC (permalink / raw)
To: linux-mmc
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-rockchip, ulf.hansson, robh+dt, krzk, heiko, shawn.lin,
Jaehoon Chung
In-Reply-To: <20161103062135.10697-1-jh80.chung@samsung.com>
If DW_MMC_CARD_NO_USE_HOLD isn't set, it's usesd by default.
Enve if SDMMC_CMD_USB_HOLD_REG is set in prepare_command(), but it
doesn't set in pre_stop_abort().
To maintain the consistency, add the checking condition for this.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
---
drivers/mmc/host/dw_mmc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 6ccb817..23fc505 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -337,6 +337,9 @@ static u32 dw_mci_prep_stop_abort(struct dw_mci *host, struct mmc_command *cmd)
cmdr = stop->opcode | SDMMC_CMD_STOP |
SDMMC_CMD_RESP_CRC | SDMMC_CMD_RESP_EXP;
+ if (!test_bit(DW_MMC_CARD_NO_USE_HOLD, &host->cur_slot->flags))
+ cmdr |= SDMMC_CMD_USE_HOLD_REG;
+
return cmdr;
}
--
2.10.1
^ permalink raw reply related
* [PATCH 00/13] mmc: dw_mmc: cleans the codes for dwmmc controller
From: Jaehoon Chung @ 2016-11-03 6:21 UTC (permalink / raw)
To: linux-mmc
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-rockchip, ulf.hansson, robh+dt, krzk, heiko, shawn.lin,
Jaehoon Chung
This patchset is modified the some minor fixing and cleaning code.
If needs to split the patches, i will re-send the patches.
* Major changes
- Use the cookie enum values like sdhci controller.
- Remove the unnecessary codes and use stop_abort() by default.
- Remove the obsoleted property "supports-highspeed"
- Remove the "clock-freq-min-max" property. Instead, use "max-frequency"
- Minimum clock value is set to 100K by default.
Jaehoon Chung (13):
mmc: dw_mmc: display the real register value on debugfs
mmc: dw_mmc: fix the debug message for checking card's present
mmc: dw_mmc: change the DW_MCI_FREQ_MIN from 400K to 100K
mmc: dw_mmc: use the hold register when send stop command
mmc: dw_mmc: call the dw_mci_prep_stop_abort() by default
mmc: core: move the cookie's enum values from sdhci.h to mmc.h
mmc: dw_mmc: use the cookie's enum values for post/pre_req()
mmc: dw_mmc: remove the unnecessary mmc_data structure
mmc: dw_mmc: remove the "clock-freq-min-max" property
ARM: dts: exynos: replace to "max-frequecy" instead of
"clock-freq-min-max"
ARM: dts: rockchip: replace to "max-frequency" instead of
"clock-freq-min-max"
ARM64: dts: rockchip: replace to "max-frequency" instead of
"clock-freq-min-max"
Documentation: synopsys-dw-mshc: remove the unused properties
.../devicetree/bindings/mmc/synopsys-dw-mshc.txt | 8 --
arch/arm/boot/dts/exynos3250-artik5-eval.dts | 2 +-
arch/arm/boot/dts/exynos3250-artik5.dtsi | 2 +-
arch/arm/boot/dts/exynos3250-monk.dts | 2 +-
arch/arm/boot/dts/exynos3250-rinato.dts | 2 +-
arch/arm/boot/dts/rk3036.dtsi | 6 +-
arch/arm/boot/dts/rk322x.dtsi | 2 +-
arch/arm/boot/dts/rk3288.dtsi | 8 +-
.../boot/dts/rockchip/rk3368-orion-r68-meta.dts | 2 +-
arch/arm64/boot/dts/rockchip/rk3368.dtsi | 6 +-
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 +-
drivers/mmc/host/dw_mmc.c | 99 ++++++++++------------
drivers/mmc/host/sdhci.h | 6 --
include/linux/mmc/core.h | 6 ++
14 files changed, 68 insertions(+), 87 deletions(-)
--
2.10.1
^ permalink raw reply
* [PATCH 13/13] Documentation: synopsys-dw-mshc: remove the unused properties
From: Jaehoon Chung @ 2016-11-03 6:21 UTC (permalink / raw)
To: linux-mmc
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-rockchip, ulf.hansson, robh+dt, krzk, heiko, shawn.lin,
Jaehoon Chung
In-Reply-To: <20161103062135.10697-1-jh80.chung@samsung.com>
"support-highspeed" was the obsoleted property.
And "broken-cd" is not synopsys specific property.
It can be referred to mmc.txt binding Documentation.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
---
Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 5 -----
1 file changed, 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
index 21c8251..3dd2849 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
@@ -68,11 +68,6 @@ Optional properties:
* card-detect-delay: Delay in milli-seconds before detecting card after card
insert event. The default value is 0.
-* supports-highspeed (DEPRECATED): Enables support for high speed cards (up to 50MHz)
- (use "cap-mmc-highspeed" or "cap-sd-highspeed" instead)
-
-* broken-cd: as documented in mmc core bindings.
-
* vmmc-supply: The phandle to the regulator to use for vmmc. If this is
specified we'll defer probe until we can find this regulator.
--
2.10.1
^ permalink raw reply related
* [PATCH 12/13] ARM64: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max"
From: Jaehoon Chung @ 2016-11-03 6:21 UTC (permalink / raw)
To: linux-mmc
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-rockchip, ulf.hansson, robh+dt, krzk, heiko, shawn.lin,
Jaehoon Chung
In-Reply-To: <20161103062135.10697-1-jh80.chung@samsung.com>
In drivers/mmc/core/host.c, there is "max-freqeuncy" property.
It should be same behavior, So Use the "max-frequency" instead of
"clock-freq-min-max".
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
---
arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts | 2 +-
arch/arm64/boot/dts/rockchip/rk3368.dtsi | 6 +++---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts b/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
index 5797933..0acf8a2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
@@ -347,7 +347,7 @@
&sdmmc {
bus-width = <4>;
clock-frequency = <50000000>;
- clock-freq-min-max = <400000 50000000>;
+ max-frequency = <50000000>;
cap-sd-highspeed;
card-detect-delay = <200>;
keep-power-in-suspend;
diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index 0fcb214..79e7c88 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -231,7 +231,7 @@
sdmmc: dwmmc@ff0c0000 {
compatible = "rockchip,rk3368-dw-mshc", "rockchip,rk3288-dw-mshc";
reg = <0x0 0xff0c0000 0x0 0x4000>;
- clock-freq-min-max = <400000 150000000>;
+ max-frequency = <150000000>;
clocks = <&cru HCLK_SDMMC>, <&cru SCLK_SDMMC>,
<&cru SCLK_SDMMC_DRV>, <&cru SCLK_SDMMC_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
@@ -243,7 +243,7 @@
sdio0: dwmmc@ff0d0000 {
compatible = "rockchip,rk3368-dw-mshc", "rockchip,rk3288-dw-mshc";
reg = <0x0 0xff0d0000 0x0 0x4000>;
- clock-freq-min-max = <400000 150000000>;
+ max-frequency = <150000000>;
clocks = <&cru HCLK_SDIO0>, <&cru SCLK_SDIO0>,
<&cru SCLK_SDIO0_DRV>, <&cru SCLK_SDIO0_SAMPLE>;
clock-names = "biu", "ciu", "ciu_drv", "ciu_sample";
@@ -255,7 +255,7 @@
emmc: dwmmc@ff0f0000 {
compatible = "rockchip,rk3368-dw-mshc", "rockchip,rk3288-dw-mshc";
reg = <0x0 0xff0f0000 0x0 0x4000>;
- clock-freq-min-max = <400000 150000000>;
+ max-frequency = <150000000>;
clocks = <&cru HCLK_EMMC>, <&cru SCLK_EMMC>,
<&cru SCLK_EMMC_DRV>, <&cru SCLK_EMMC_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index b65c193..b1c011d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -235,7 +235,7 @@
"rockchip,rk3288-dw-mshc";
reg = <0x0 0xfe310000 0x0 0x4000>;
interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH 0>;
- clock-freq-min-max = <400000 150000000>;
+ max-frequency = <150000000>;
clocks = <&cru HCLK_SDIO>, <&cru SCLK_SDIO>,
<&cru SCLK_SDIO_DRV>, <&cru SCLK_SDIO_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
@@ -248,7 +248,7 @@
"rockchip,rk3288-dw-mshc";
reg = <0x0 0xfe320000 0x0 0x4000>;
interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH 0>;
- clock-freq-min-max = <400000 150000000>;
+ max-frequency = <150000000>;
clocks = <&cru HCLK_SDMMC>, <&cru SCLK_SDMMC>,
<&cru SCLK_SDMMC_DRV>, <&cru SCLK_SDMMC_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
--
2.10.1
^ permalink raw reply related
* [PATCH 11/13] ARM: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max"
From: Jaehoon Chung @ 2016-11-03 6:21 UTC (permalink / raw)
To: linux-mmc
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-rockchip, ulf.hansson, robh+dt, krzk, heiko, shawn.lin,
Jaehoon Chung
In-Reply-To: <20161103062135.10697-1-jh80.chung@samsung.com>
In drivers/mmc/core/host.c, there is "max-frequency" property.
It should be same behavior. So use the "max-frequency" instead of
"clock-freq-min-max".
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
---
arch/arm/boot/dts/rk3036.dtsi | 6 +++---
arch/arm/boot/dts/rk322x.dtsi | 2 +-
arch/arm/boot/dts/rk3288.dtsi | 8 ++++----
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index a935523..d3fb323 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -244,7 +244,7 @@
compatible = "rockchip,rk3036-dw-mshc", "rockchip,rk3288-dw-mshc";
reg = <0x10214000 0x4000>;
clock-frequency = <37500000>;
- clock-freq-min-max = <400000 37500000>;
+ max-frequency = <37500000>;
clocks = <&cru HCLK_SDMMC>, <&cru SCLK_SDMMC>;
clock-names = "biu", "ciu";
fifo-depth = <0x100>;
@@ -255,7 +255,7 @@
sdio: dwmmc@10218000 {
compatible = "rockchip,rk3036-dw-mshc", "rockchip,rk3288-dw-mshc";
reg = <0x10218000 0x4000>;
- clock-freq-min-max = <400000 37500000>;
+ max-frequency = <37500000>;
clocks = <&cru HCLK_SDIO>, <&cru SCLK_SDIO>,
<&cru SCLK_SDIO_DRV>, <&cru SCLK_SDIO_SAMPLE>;
clock-names = "biu", "ciu", "ciu_drv", "ciu_sample";
@@ -271,7 +271,7 @@
bus-width = <8>;
cap-mmc-highspeed;
clock-frequency = <37500000>;
- clock-freq-min-max = <400000 37500000>;
+ max-frequency = <37500000>;
clocks = <&cru HCLK_EMMC>, <&cru SCLK_EMMC>,
<&cru SCLK_EMMC_DRV>, <&cru SCLK_EMMC_SAMPLE>;
clock-names = "biu", "ciu", "ciu_drv", "ciu_sample";
diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index 9e6bf0e..8c2e360 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -402,7 +402,7 @@
reg = <0x30020000 0x4000>;
interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <37500000>;
- clock-freq-min-max = <400000 37500000>;
+ max-frequency = <37500000>;
clocks = <&cru HCLK_EMMC>, <&cru SCLK_EMMC>,
<&cru SCLK_EMMC_DRV>, <&cru SCLK_EMMC_SAMPLE>;
clock-names = "biu", "ciu", "ciu_drv", "ciu_sample";
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 17ec2e2..65b60b7 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -227,7 +227,7 @@
sdmmc: dwmmc@ff0c0000 {
compatible = "rockchip,rk3288-dw-mshc";
- clock-freq-min-max = <400000 150000000>;
+ max-frequency = <150000000>;
clocks = <&cru HCLK_SDMMC>, <&cru SCLK_SDMMC>,
<&cru SCLK_SDMMC_DRV>, <&cru SCLK_SDMMC_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
@@ -239,7 +239,7 @@
sdio0: dwmmc@ff0d0000 {
compatible = "rockchip,rk3288-dw-mshc";
- clock-freq-min-max = <400000 150000000>;
+ max-frequency = <150000000>;
clocks = <&cru HCLK_SDIO0>, <&cru SCLK_SDIO0>,
<&cru SCLK_SDIO0_DRV>, <&cru SCLK_SDIO0_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
@@ -251,7 +251,7 @@
sdio1: dwmmc@ff0e0000 {
compatible = "rockchip,rk3288-dw-mshc";
- clock-freq-min-max = <400000 150000000>;
+ max-frequency = <150000000>;
clocks = <&cru HCLK_SDIO1>, <&cru SCLK_SDIO1>,
<&cru SCLK_SDIO1_DRV>, <&cru SCLK_SDIO1_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
@@ -263,7 +263,7 @@
emmc: dwmmc@ff0f0000 {
compatible = "rockchip,rk3288-dw-mshc";
- clock-freq-min-max = <400000 150000000>;
+ max-frequency = <150000000>;
clocks = <&cru HCLK_EMMC>, <&cru SCLK_EMMC>,
<&cru SCLK_EMMC_DRV>, <&cru SCLK_EMMC_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
--
2.10.1
^ permalink raw reply related
* [PATCH 10/13] ARM: dts: exynos: replace to "max-frequecy" instead of "clock-freq-min-max"
From: Jaehoon Chung @ 2016-11-03 6:21 UTC (permalink / raw)
To: linux-mmc
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-rockchip, ulf.hansson, robh+dt, krzk, heiko, shawn.lin,
Jaehoon Chung
In-Reply-To: <20161103062135.10697-1-jh80.chung@samsung.com>
In drivers/mmc/core/host.c, there is "max-frequency" property.
It should be same behavior. So Use the "max-frequency" instead of
"clock-freq-min-max".
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
---
arch/arm/boot/dts/exynos3250-artik5-eval.dts | 2 +-
arch/arm/boot/dts/exynos3250-artik5.dtsi | 2 +-
arch/arm/boot/dts/exynos3250-monk.dts | 2 +-
arch/arm/boot/dts/exynos3250-rinato.dts | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250-artik5-eval.dts b/arch/arm/boot/dts/exynos3250-artik5-eval.dts
index be4d6aa..4bd2ee8 100644
--- a/arch/arm/boot/dts/exynos3250-artik5-eval.dts
+++ b/arch/arm/boot/dts/exynos3250-artik5-eval.dts
@@ -28,7 +28,7 @@
vqmmc-supply = <&ldo3_reg>;
card-detect-delay = <200>;
clock-frequency = <100000000>;
- clock-freq-min-max = <400000 100000000>;
+ max-frequency = <100000000>;
samsung,dw-mshc-ciu-div = <1>;
samsung,dw-mshc-sdr-timing = <0 1>;
samsung,dw-mshc-ddr-timing = <1 2>;
diff --git a/arch/arm/boot/dts/exynos3250-artik5.dtsi b/arch/arm/boot/dts/exynos3250-artik5.dtsi
index a70819b..59c89d7 100644
--- a/arch/arm/boot/dts/exynos3250-artik5.dtsi
+++ b/arch/arm/boot/dts/exynos3250-artik5.dtsi
@@ -310,7 +310,7 @@
card-detect-delay = <200>;
vmmc-supply = <&ldo12_reg>;
clock-frequency = <100000000>;
- clock-freq-min-max = <400000 100000000>;
+ max-frequency = <100000000>;
samsung,dw-mshc-ciu-div = <1>;
samsung,dw-mshc-sdr-timing = <0 1>;
samsung,dw-mshc-ddr-timing = <1 2>;
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts b/arch/arm/boot/dts/exynos3250-monk.dts
index 66f04f6..cccfe4b 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -435,7 +435,7 @@
card-detect-delay = <200>;
vmmc-supply = <&vemmc_reg>;
clock-frequency = <100000000>;
- clock-freq-min-max = <400000 100000000>;
+ max-frequency = <100000000>;
samsung,dw-mshc-ciu-div = <1>;
samsung,dw-mshc-sdr-timing = <0 1>;
samsung,dw-mshc-ddr-timing = <1 2>;
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts b/arch/arm/boot/dts/exynos3250-rinato.dts
index 3967ee5..548413e 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -649,7 +649,7 @@
card-detect-delay = <200>;
vmmc-supply = <&ldo12_reg>;
clock-frequency = <100000000>;
- clock-freq-min-max = <400000 100000000>;
+ max-frequency = <100000000>;
samsung,dw-mshc-ciu-div = <1>;
samsung,dw-mshc-sdr-timing = <0 1>;
samsung,dw-mshc-ddr-timing = <1 2>;
--
2.10.1
^ permalink raw reply related
* [PATCH 08/13] mmc: dw_mmc: remove the unnecessary mmc_data structure
From: Jaehoon Chung @ 2016-11-03 6:21 UTC (permalink / raw)
To: linux-mmc
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-rockchip, ulf.hansson, robh+dt, krzk, heiko, shawn.lin,
Jaehoon Chung
In-Reply-To: <20161103062135.10697-1-jh80.chung@samsung.com>
Remove the unnecessary mmc_data structure.
Instead, cmd->data can be used.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
---
drivers/mmc/host/dw_mmc.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index df151c8..bd8c5ea 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -236,7 +236,6 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg);
static u32 dw_mci_prepare_command(struct mmc_host *mmc, struct mmc_command *cmd)
{
- struct mmc_data *data;
struct dw_mci_slot *slot = mmc_priv(mmc);
struct dw_mci *host = slot->host;
u32 cmdr;
@@ -291,10 +290,9 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc, struct mmc_command *cmd)
if (cmd->flags & MMC_RSP_CRC)
cmdr |= SDMMC_CMD_RESP_CRC;
- data = cmd->data;
- if (data) {
+ if (cmd->data) {
cmdr |= SDMMC_CMD_DAT_EXP;
- if (data->flags & MMC_DATA_WRITE)
+ if (cmd->data->flags & MMC_DATA_WRITE)
cmdr |= SDMMC_CMD_DAT_WR;
}
--
2.10.1
^ permalink raw reply related
* [PATCH 07/13] mmc: dw_mmc: use the cookie's enum values for post/pre_req()
From: Jaehoon Chung @ 2016-11-03 6:21 UTC (permalink / raw)
To: linux-mmc
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-rockchip, ulf.hansson, robh+dt, krzk, heiko, shawn.lin,
Jaehoon Chung
In-Reply-To: <20161103062135.10697-1-jh80.chung@samsung.com>
This patch removed the meaningless value. Instead, use the cookie's enum
values for executing correctly.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
---
drivers/mmc/host/dw_mmc.c | 39 +++++++++++++++++++--------------------
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 16df93b..df151c8 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -414,12 +414,13 @@ static void dw_mci_dma_cleanup(struct dw_mci *host)
{
struct mmc_data *data = host->data;
- if (data)
- if (!data->host_cookie)
- dma_unmap_sg(host->dev,
- data->sg,
- data->sg_len,
- dw_mci_get_dma_dir(data));
+ if (data && data->host_cookie == COOKIE_MAPPED) {
+ dma_unmap_sg(host->dev,
+ data->sg,
+ data->sg_len,
+ dw_mci_get_dma_dir(data));
+ data->host_cookie = COOKIE_UNMAPPED;
+ }
}
static void dw_mci_idmac_reset(struct dw_mci *host)
@@ -850,13 +851,13 @@ static const struct dw_mci_dma_ops dw_mci_edmac_ops = {
static int dw_mci_pre_dma_transfer(struct dw_mci *host,
struct mmc_data *data,
- bool next)
+ int cookie)
{
struct scatterlist *sg;
unsigned int i, sg_len;
- if (!next && data->host_cookie)
- return data->host_cookie;
+ if (data->host_cookie == COOKIE_PRE_MAPPED)
+ return data->sg_len;
/*
* We don't do DMA on "complex" transfers, i.e. with
@@ -881,8 +882,7 @@ static int dw_mci_pre_dma_transfer(struct dw_mci *host,
if (sg_len == 0)
return -EINVAL;
- if (next)
- data->host_cookie = sg_len;
+ data->host_cookie = cookie;
return sg_len;
}
@@ -897,13 +897,12 @@ static void dw_mci_pre_req(struct mmc_host *mmc,
if (!slot->host->use_dma || !data)
return;
- if (data->host_cookie) {
- data->host_cookie = 0;
- return;
- }
+ /* This data might be unmapped at this time */
+ data->host_cookie = COOKIE_UNMAPPED;
- if (dw_mci_pre_dma_transfer(slot->host, mrq->data, 1) < 0)
- data->host_cookie = 0;
+ if (dw_mci_pre_dma_transfer(slot->host, mrq->data,
+ COOKIE_PRE_MAPPED) < 0)
+ data->host_cookie = COOKIE_UNMAPPED;
}
static void dw_mci_post_req(struct mmc_host *mmc,
@@ -916,12 +915,12 @@ static void dw_mci_post_req(struct mmc_host *mmc,
if (!slot->host->use_dma || !data)
return;
- if (data->host_cookie)
+ if (data->host_cookie != COOKIE_UNMAPPED)
dma_unmap_sg(slot->host->dev,
data->sg,
data->sg_len,
dw_mci_get_dma_dir(data));
- data->host_cookie = 0;
+ data->host_cookie = COOKIE_UNMAPPED;
}
static void dw_mci_adjust_fifoth(struct dw_mci *host, struct mmc_data *data)
@@ -1027,7 +1026,7 @@ static int dw_mci_submit_data_dma(struct dw_mci *host, struct mmc_data *data)
if (!host->use_dma)
return -ENODEV;
- sg_len = dw_mci_pre_dma_transfer(host, data, 0);
+ sg_len = dw_mci_pre_dma_transfer(host, data, COOKIE_MAPPED);
if (sg_len < 0) {
host->dma_ops->stop(host);
return sg_len;
--
2.10.1
^ permalink raw reply related
* [PATCH 05/13] mmc: dw_mmc: call the dw_mci_prep_stop_abort() by default
From: Jaehoon Chung @ 2016-11-03 6:21 UTC (permalink / raw)
To: linux-mmc
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-rockchip, ulf.hansson, robh+dt, krzk, heiko, shawn.lin,
Jaehoon Chung
In-Reply-To: <20161103062135.10697-1-jh80.chung@samsung.com>
stop_cmdr should be set to values relevant to stop command.
It migth be assigned to values whatever there is mrq->stop or not.
Then it doesn't need to use dw_mci_prepare_command().
It's enough to use the prep_stop_abort for preparing stop command.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
---
drivers/mmc/host/dw_mmc.c | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 23fc505..16df93b 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -385,7 +385,7 @@ static void dw_mci_start_command(struct dw_mci *host,
static inline void send_stop_abort(struct dw_mci *host, struct mmc_data *data)
{
- struct mmc_command *stop = data->stop ? data->stop : &host->stop_abort;
+ struct mmc_command *stop = &host->stop_abort;
dw_mci_start_command(host, stop, host->stop_cmdr);
}
@@ -1277,10 +1277,7 @@ static void __dw_mci_start_request(struct dw_mci *host,
spin_unlock_irqrestore(&host->irq_lock, irqflags);
}
- if (mrq->stop)
- host->stop_cmdr = dw_mci_prepare_command(slot->mmc, mrq->stop);
- else
- host->stop_cmdr = dw_mci_prep_stop_abort(host, cmd);
+ host->stop_cmdr = dw_mci_prep_stop_abort(host, cmd);
}
static void dw_mci_start_request(struct dw_mci *host,
@@ -1890,8 +1887,7 @@ static void dw_mci_tasklet_func(unsigned long priv)
if (test_and_clear_bit(EVENT_DATA_ERROR,
&host->pending_events)) {
dw_mci_stop_dma(host);
- if (data->stop ||
- !(host->data_status & (SDMMC_INT_DRTO |
+ if (!(host->data_status & (SDMMC_INT_DRTO |
SDMMC_INT_EBE)))
send_stop_abort(host, data);
state = STATE_DATA_ERROR;
@@ -1927,8 +1923,7 @@ static void dw_mci_tasklet_func(unsigned long priv)
if (test_and_clear_bit(EVENT_DATA_ERROR,
&host->pending_events)) {
dw_mci_stop_dma(host);
- if (data->stop ||
- !(host->data_status & (SDMMC_INT_DRTO |
+ if (!(host->data_status & (SDMMC_INT_DRTO |
SDMMC_INT_EBE)))
send_stop_abort(host, data);
state = STATE_DATA_ERROR;
@@ -2004,7 +1999,7 @@ static void dw_mci_tasklet_func(unsigned long priv)
host->cmd = NULL;
host->data = NULL;
- if (mrq->stop)
+ if (!mrq->sbc && mrq->stop)
dw_mci_command_complete(host, mrq->stop);
else
host->cmd_status = 0;
--
2.10.1
^ permalink raw reply related
* [PATCH 03/13] mmc: dw_mmc: change the DW_MCI_FREQ_MIN from 400K to 100K
From: Jaehoon Chung @ 2016-11-03 6:21 UTC (permalink / raw)
To: linux-mmc
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-rockchip, ulf.hansson, robh+dt, krzk, heiko, shawn.lin,
Jaehoon Chung
In-Reply-To: <20161103062135.10697-1-jh80.chung@samsung.com>
If there is no property "clock-freq-min-max", mmc->f_min should be set
to 400K by default. But Some SoC can be used 100K.
When 100K is used, MMC core will try to check from 400K to 100K.
Reported-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
---
drivers/mmc/host/dw_mmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1e71fd4..6ccb817 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -54,7 +54,7 @@
#define DW_MCI_DMA_THRESHOLD 16
#define DW_MCI_FREQ_MAX 200000000 /* unit: HZ */
-#define DW_MCI_FREQ_MIN 400000 /* unit: HZ */
+#define DW_MCI_FREQ_MIN 100000 /* unit: HZ */
#define IDMAC_INT_CLR (SDMMC_IDMAC_INT_AI | SDMMC_IDMAC_INT_NI | \
SDMMC_IDMAC_INT_CES | SDMMC_IDMAC_INT_DU | \
--
2.10.1
^ permalink raw reply related
* [PATCH 02/13] mmc: dw_mmc: fix the debug message for checking card's present
From: Jaehoon Chung @ 2016-11-03 6:21 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
heiko-4mtYJXux2i+zQB+pC5nmwQ, shawn.lin-TNX95d0MmH7DzftRWevZcw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, krzk-DgEjT+Ai2ygdnm+yROfE0A,
Jaehoon Chung, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161103062135.10697-1-jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
If display the debug message, this message should be spamming.
If flags is maintained the previous value, didn't display the debug
message.
Signed-off-by: Jaehoon Chung <jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
drivers/mmc/host/dw_mmc.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index b87dd07..1e71fd4 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1537,13 +1537,10 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
== 0 ? 1 : 0;
spin_lock_bh(&host->lock);
- if (present) {
- set_bit(DW_MMC_CARD_PRESENT, &slot->flags);
+ if (present && !test_and_set_bit(DW_MMC_CARD_PRESENT, &slot->flags))
dev_dbg(&mmc->class_dev, "card is present\n");
- } else {
- clear_bit(DW_MMC_CARD_PRESENT, &slot->flags);
+ else if (!test_and_clear_bit(DW_MMC_CARD_PRESENT, &slot->flags))
dev_dbg(&mmc->class_dev, "card is not present\n");
- }
spin_unlock_bh(&host->lock);
return present;
--
2.10.1
^ permalink raw reply related
* [PATCH 01/13] mmc: dw_mmc: display the real register value on debugfs
From: Jaehoon Chung @ 2016-11-03 6:21 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
heiko-4mtYJXux2i+zQB+pC5nmwQ, shawn.lin-TNX95d0MmH7DzftRWevZcw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, krzk-DgEjT+Ai2ygdnm+yROfE0A,
Jaehoon Chung, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161103062135.10697-1-jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Developer wants to see the real register value, not register offset.
This patch fixed to display the real value of register.
Signed-off-by: Jaehoon Chung <jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
drivers/mmc/host/dw_mmc.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1c9ee36..b87dd07 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -165,12 +165,14 @@ static const struct file_operations dw_mci_req_fops = {
static int dw_mci_regs_show(struct seq_file *s, void *v)
{
- seq_printf(s, "STATUS:\t0x%08x\n", SDMMC_STATUS);
- seq_printf(s, "RINTSTS:\t0x%08x\n", SDMMC_RINTSTS);
- seq_printf(s, "CMD:\t0x%08x\n", SDMMC_CMD);
- seq_printf(s, "CTRL:\t0x%08x\n", SDMMC_CTRL);
- seq_printf(s, "INTMASK:\t0x%08x\n", SDMMC_INTMASK);
- seq_printf(s, "CLKENA:\t0x%08x\n", SDMMC_CLKENA);
+ struct dw_mci *host = s->private;
+
+ seq_printf(s, "STATUS:\t0x%08x\n", mci_readl(host, STATUS));
+ seq_printf(s, "RINTSTS:\t0x%08x\n", mci_readl(host, RINTSTS));
+ seq_printf(s, "CMD:\t0x%08x\n", mci_readl(host, CMD));
+ seq_printf(s, "CTRL:\t0x%08x\n", mci_readl(host, CTRL));
+ seq_printf(s, "INTMASK:\t0x%08x\n", mci_readl(host, INTMASK));
+ seq_printf(s, "CLKENA:\t0x%08x\n", mci_readl(host, CLKENA));
return 0;
}
--
2.10.1
^ permalink raw reply related
* [GIT PULL] DWMMC controller fixes
From: Jaehoon Chung @ 2016-11-03 5:25 UTC (permalink / raw)
To: linux-mmc@vger.kernel.org; +Cc: Ulf Hansson
Dear Ulf,
Could you pull these patches on your fixes branch?
The following changes since commit d1f63f0c81c22ba705fcd149a1fcec37b734d818:
mmc: sdhci-msm: Fix error return code in sdhci_msm_probe() (2016-10-27 09:43:01 +0200)
are available in the git repository at:
https://github.com/jh80chung/dw-mmc.git fixes
for you to fetch changes up to 5c3d7c7ed1e676d7fa1c9222d9a46c5d09b9fe97:
mmc: dw_mmc: add the "reset" as name of reset controller (2016-11-03 14:11:59 +0900)
----------------------------------------------------------------
DWMMC core:
- Add the "reset" as "#reset-names" property for preventing wrong operation.
----------------------------------------------------------------
Jaehoon Chung (2):
Documentation: synopsys-dw-mshc: add binding for reset-names
mmc: dw_mmc: add the "reset" as name of reset controller
Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 5 +++++
drivers/mmc/host/dw_mmc.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
Best Regards,
Jaehoon Chung
^ permalink raw reply
* Re: [PATCH 0/2] mmc: dw_mmc: fix the wrong operation for reset controller
From: Jaehoon Chung @ 2016-11-03 5:19 UTC (permalink / raw)
To: John Stultz
Cc: linux-mmc,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Ulf Hansson, Rob Herring, Mark Rutland, lkml, Guodong Xu, Leo Yan,
Vincent Guittot
In-Reply-To: <CALAqxLXs704Y-TGAQsggSnDohyFDYvQw=zYuiHRu9UKgHEfbFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On 11/02/2016 06:56 AM, John Stultz wrote:
> On Sun, Oct 30, 2016 at 7:49 PM, Jaehoon Chung <jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
>> This patch adds the "reset-names" as reset controller for dwmmc controller.
>> Linaro guys had reported the issue about booting stuck.
>>
>> Some SoCs are enabled the CONFIG_RESET_CONTROLLER.
>> then dwmmc controller are waiting for getting reset controller.
>> But if doesn't define "resets" property in device-tree, it should be stuck.
>>
>> If use the reset-names as reset controller for dwmmc controller,
>> it's more stable than now.
>> This commit is related with the below commit.
>>
>> Fixes: d6786fefe816 ("mmc: dw_mmc: add reset support to dwmmc host controller")
>
> So I wasn't hit by the issue, as I don't tend to boot from SD on my
> hikey, but I did run these patches and I'm not seeing any issues with
> my Android environment.
>
> So for what its worth:
> Acked-by: John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Applied on my repository (fixes branch).
Best Regards,
Jaehoon Chung
>
> thanks
> -john
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Regression after "do not use CMD13 to get status after speed mode switch"
From: Chaotian Jing @ 2016-11-03 3:39 UTC (permalink / raw)
To: Adrian Hunter
Cc: Ulf Hansson, Linus Walleij, linux-mmc@vger.kernel.org,
linux-arm-msm@vger.kernel.org, Bjorn Andersson, Stephen Boyd,
Andy Gross
In-Reply-To: <a8f3cb19-a64e-624d-43f2-44986e430c48@intel.com>
On Wed, 2016-11-02 at 14:51 +0200, Adrian Hunter wrote:
> On 02/11/16 12:28, Chaotian Jing wrote:
> > On Wed, 2016-11-02 at 10:19 +0200, Adrian Hunter wrote:
> >> On 01/11/16 03:43, Chaotian Jing wrote:
> >>> On Mon, 2016-10-31 at 15:09 +0200, Adrian Hunter wrote:
> >>>> On 27/10/16 13:04, Ulf Hansson wrote:
> >>>>> On 20 October 2016 at 09:06, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >>>>>> On 20 October 2016 at 04:22, Chaotian Jing <chaotian.jing@mediatek.com> wrote:
> >>>>>>> On Wed, 2016-10-19 at 18:41 +0200, Ulf Hansson wrote:
> >>>>>>>> Adrian, Linus,
> >>>>>>>>
> >>>>>>>> Thanks for looking into this and reporting!
> >>>>>>>>
> >>>>>>>> On 18 October 2016 at 15:23, Adrian Hunter <adrian.hunter@intel.com> wrote:
> >>>>>>>>> On 18/10/16 11:36, Linus Walleij wrote:
> >>>>>>>>>> On Mon, Oct 17, 2016 at 4:32 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Before this patch the eMMC is detected and all partitions enumerated
> >>>>>>>>>>> immediately, but after the patch it doesn't come up at all, except
> >>>>>>>>>>> sometimes, when it appears minutes (!) after boot, all of a sudden.
> >>>>>>>>>>
> >>>>>>>>>> FYI this is what it looks like when it eventually happens:
> >>>>>>>>>> root@msm8660:/ [ 627.710175] mmc0: new high speed MMC card at address 0001
> >>>>>>>>>> [ 627.711641] mmcblk0: mmc0:0001 SEM04G 3.69 GiB
> >>>>>>>>>> [ 627.715485] mmcblk0boot0: mmc0:0001 SEM04G partition 1 1.00 MiB
> >>>>>>>>>> [ 627.736654] mmcblk0boot1: mmc0:0001 SEM04G partition 2 1.00 MiB
> >>>>>>>>>> [ 627.747397] mmcblk0rpmb: mmc0:0001 SEM04G partition 3 128 KiB
> >>>>>>>>>> [ 627.756326] mmcblk0: p1 p2 p3 p4 < p5 p6 p7 p8 p9 p10 p11 p12 p13
> >>>>>>>>>> p14 p15 p16 p17 p18 p19 p20 p21 >
> >>>>>>>>>>
> >>>>>>>>>> So after 627 seconds, a bit hard for users to wait this long for their
> >>>>>>>>>> root filesystem.
> >>>>>>>>>
> >>>>>>>>> If the driver does not support busy detection and the eMMC card provides
> >>>>>>>>> zero as the cmd6 generic timeout (which it may especially as cmd6 generic
> >>>>>>>>> timeout wasn't added until eMMCv4.5), then __mmc_switch() defaults to
> >>>>>>>>> waiting 10 minutes i.e.
> >>>>>>>>>
> >>>>>>>>> #define MMC_OPS_TIMEOUT_MS (10 * 60 * 1000) /* 10 minute timeout */
> >>>>>>>>
> >>>>>>>> Urgh! Yes, I have verified that this is exactly what happens.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> So removal of CMD13 polling for HS mode (as per commit
> >>>>>>>>> 08573eaf1a70104f83fdbee9b84e5be03480e9ed) is going to be a problem for some
> >>>>>>>>> combinations of eMMC cards and host drivers.
> >>>>>>>>
> >>>>>>>> I was looking in the __mmc_switch() function, it's just a pain to walk
> >>>>>>>> trough it :-) So first out I decided to clean it up and factor out the
> >>>>>>>> polling parts. I will post the patches first out tomorrow morning,
> >>>>>>>> running some final test right now.
> >>>>>>>>
> >>>>>>>> Although, that of course doesn't solve our problem. As I see it we
> >>>>>>>> only have a few options here.
> >>>>>>>>
> >>>>>>>> 1) In case when cmd6 generic timeout isn't available, let's assign
> >>>>>>>> another empirically selected value.
> >>>>>>>> 2) Use a specific timeout when switching to HS mode.
> >>>>>>>> 3) Even if we deploy 1 (and 2), perhaps we still should allow polling
> >>>>>>>> with CMD13 for switching to HS mode - unless it causes issues for some
> >>>>>>>> cards/drivers combination?
> >>>>>>>>
> >>>>>>>> BTW, I already tried 2) and it indeed solves the problem, although
> >>>>>>>> depending on the selected timeout, it might delay the card detection
> >>>>>>>> to process.
> >>>>>>>>
> >>>>>>>> Thoughts?
> >>>>>>>
> >>>>>>> I just have a try of switching to HS mode with Hynix EMMC, the first
> >>>>>>> CMD13 gets response of 0x900, but the EMMC is still pull-low DAT0. so
> >>>>>>> that CMD13 cannot indicate current card status in this case.
> >>>>>>
> >>>>>> Thanks for sharing that. Okay, so clearly we have some cards that
> >>>>>> don't supports polling with CMD13 when switching to HS mode.
> >>>>>> One could of course add quirks for these kind of cards and do a fixed
> >>>>>> delay for them, but then to find out which these cards are is going to
> >>>>>> be hard.
> >>>>>>
> >>>>>> It seems like we are left with using a fixed delay. Any ideas of what
> >>>>>> such delay should be? And should we have one specific for switch to
> >>>>>> the various speed modes and a different one that overrides the CMD6
> >>>>>> generic timout, when it doesn't exist?
> >>>>>>
> >>>>>
> >>>>> Replying to my own earlier response, as I believe the problem could
> >>>>> also be related to another old commit, see below.
> >>>>>
> >>>>> commit a27fbf2f067b0cd6f172c8b696b9a44c58bfaa7a
> >>>>> Author: Seungwon Jeon <tgih.jun@samsung.com>
> >>>>> Date: Wed Sep 4 21:21:05 2013 +0900
> >>>>>
> >>>>> mmc: add ignorance case for CMD13 CRC error
> >>>>>
> >>>>> While speed mode is changed, CMD13 cannot be guaranteed.
> >>>>> According to the spec., it is not recommended to use CMD13
> >>>>> to check the busy completion of the timing change.
> >>>>> If CMD13 is used in this case, CRC error must be ignored.
> >>>>>
> >>>>> Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
> >>>>> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
> >>>>> Signed-off-by: Chris Ball <cjb@laptop.org>
> >>>>>
> >>>>>
> >>>>> The intent with this commit was not really correct. We don't want to
> >>>>> ignore CRC errors, but instead we should *re-try* sending CMD13 once
> >>>>> we get a CRC error.
> >>>>>
> >>>>> Unfortunate since this commit, instead we tell the host driver to
> >>>>> *ignore* CRC errors and instead reads the status and returns 0
> >>>>> (indicating success). In the mmc core, in __mmc_switch(), it will thus
> >>>>> parse the status reply, even for a reply that might have been received
> >>>>> with a CRC error. Not good!
> >>>>
> >>>> I agree: ignoring CRC errors and then expecting the status in the response
> >>>> to be correct doesn't make sense.
> >>>>
> >>>> However, it raises the question of what to do if there are always CRC errors
> >>>> e.g. if it only works without CRC errors once the mode and frequency are
> >>>> changed in the host controller.
> >>>>
> >>>>> I am wondering whether this actually is the main problem to why we
> >>>>> think polling isn't working for some cases. And perhaps that was the
> >>>>> original problem Chaotian was trying to solve?
> >>>>>
> >>>>> Thoughts?
> >>>>
> >>>> Does Chaotian have a real problem since his driver has busy detection anyway?
> >>>
> >>> In fact, I have not encounter CRC errors of CMD13, I have tried several
> >>> eMMC cards, after mode switch, CMD13 will only gets 0x800 response and
> >>> we don't know if card is busy by 0x800 response.
> >>
> >> Does it change to 0x900 when it is not busy?
> >>
> > No, it will not change to 0x900 when it is not busy.
> >
> >> But anyway the question was: do you have busy detection in your driver?
> >>
> > driver has busy detection ops->card_busy() but seems it's MMC core
> > layer's responsibility to ensure that card is not busy when driver
> > starts to issue commands.
>
> I tried a card here. The time between HS switch response and busy
> de-assertion was only 58us i.e. practically instant. The CMD6 response was
> 0x800 but the subsequent CMD13 response was 0x900.
>
> How long does it take your failing card to switch to HS?
>
It depends on EMMC chip type, some are very fast and some are take
several ms. I just test Sandisk-SDIN9D-S2, CMD13 also gets 0x800
response after busy-deassert.
^ permalink raw reply
* Re: [PATCH] sdhci-esdhc-imx: fix bus-width for 1-bit operation.
From: Stefan Agner @ 2016-11-02 16:40 UTC (permalink / raw)
To: Dong Aisheng
Cc: Leonardo G. Veiga, Ulf Hansson, linux-mmc, linux-kernel,
raul.munoz, leonardo.veiga, Haibo Chen
In-Reply-To: <CAA+hA=SMgEM_UVt2=3-Kx23fG0epMJv3mt7ZEPo=Eo5ib7Lj=w@mail.gmail.com>
On 2016-11-02 01:42, Dong Aisheng wrote:
> Hi Leonardo,
>
> On Tue, Nov 1, 2016 at 11:58 PM, Leonardo G. Veiga <leogveiga@gmail.com> wrote:
>> From: Leonardo Graboski Veiga <leonardo.veiga@toradex.com>
>>
>> The 1-bit operation mode, enabled by seeting the 'bus-width' property of
>> the device tree 'esdhc' node to <1>, not work while using SD card.
>>
>> The behavior is only noticed when only the data pin 0 is connected to the
>> hardware. A series of kernel errors are printed to the console, all of them
>> returning the following error message followed by some explanation:
>> mmcblk0: error -84 transferring data
>>
>> If four data lines are connected, it ignores the device-tree
>> property and works in 4-bit mode of operation without errors. The hardware
>> used for testing does not support 8-bit mode.
>>
>> Check the 'bus-width' property and if set to <1>, enable the
>> SDHCI_QUIRK_FORCE_1_BIT_DATA quirk.
>>
>> Signed-off-by: Leonardo Graboski Veiga <leonardo.veiga@toradex.com>
>> ---
>> drivers/mmc/host/sdhci-esdhc-imx.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
>> index c9fbc4c3..88d7d22 100644
>> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
>> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
>> @@ -1003,6 +1003,10 @@ sdhci_esdhc_imx_probe_dt(struct platform_device *pdev,
>> host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
>> }
>>
>> + if (!of_property_read_u32(np, "bus-width", &boarddata->max_bus_width)
>> + && boarddata->max_bus_width == 1)
>> + host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA;
>> +
>
> This looks like a common SDHCI driver issue that it assumes the default
> bus-width as 4 bit if no SDHCI_QUIRK_FORCE_1_BIT_DATA specified.
> if (!(host->quirks & SDHCI_QUIRK_FORCE_1_BIT_DATA))
> mmc->caps |= MMC_CAP_4_BIT_DATA;
>
> And I'm not sure Andrian or Ulf would like to see people keep using this quirk.
> IMHO we probably could totally remove it since bus-width already tells
> what the driver needs.
Hm, I see what you are saying, the problem is that the core
(sdhci_setup_host) falls back to 4-bit if SDHCI_QUIRK_FORCE_1_BIT_DATA
is not set... Removing that should be fine for DT enabled SDHC drivers,
since mmc_of_parse sets MMC_CAP_4_BIT_DATA. But not sure about drivers
which parse dt on their own or still support platform data.... Those
might rely on MMC_CAP_4_BIT_DATA being set by default...
--
Stefan
>
> Andrian & Ulf,
> Comments?
>
>> /* call to generic mmc_of_parse to support additional capabilities */
>> ret = mmc_of_parse(host->mmc);
>> if (ret)
>> --
>> 2.7.4
>>
>
> Regards
> Dong Aisheng
^ permalink raw reply
* RE: [PATCH] sdhci-esdhc-imx: fix bus-width for 1-bit operation.
From: Bough Chen @ 2016-11-02 4:27 UTC (permalink / raw)
To: Leonardo G. Veiga, ulf.hansson@linaro.org, A.S. Dong
Cc: linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
stefan@agner.ch, raul.munoz@toradex.com,
leonardo.veiga@toradex.com
In-Reply-To: <1478015905-31262-1-git-send-email-leogveiga@gmail.com>
+Aisheng.
Best Regards
Haibo Chen
> -----Original Message-----
> From: linux-mmc-owner@vger.kernel.org [mailto:linux-mmc-
> owner@vger.kernel.org] On Behalf Of Leonardo G. Veiga
> Sent: Tuesday, November 01, 2016 11:58 PM
> To: ulf.hansson@linaro.org
> Cc: linux-mmc@vger.kernel.org; linux-kernel@vger.kernel.org;
> stefan@agner.ch; raul.munoz@toradex.com; leonardo.veiga@toradex.com
> Subject: [PATCH] sdhci-esdhc-imx: fix bus-width for 1-bit operation.
>
> From: Leonardo Graboski Veiga <leonardo.veiga@toradex.com>
>
> The 1-bit operation mode, enabled by seeting the 'bus-width' property of the
> device tree 'esdhc' node to <1>, not work while using SD card.
>
> The behavior is only noticed when only the data pin 0 is connected to the
> hardware. A series of kernel errors are printed to the console, all of them
> returning the following error message followed by some explanation:
> mmcblk0: error -84 transferring data
>
> If four data lines are connected, it ignores the device-tree property and works
> in 4-bit mode of operation without errors. The hardware used for testing does
> not support 8-bit mode.
>
> Check the 'bus-width' property and if set to <1>, enable the
> SDHCI_QUIRK_FORCE_1_BIT_DATA quirk.
>
> Signed-off-by: Leonardo Graboski Veiga <leonardo.veiga@toradex.com>
> ---
> drivers/mmc/host/sdhci-esdhc-imx.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-
> esdhc-imx.c
> index c9fbc4c3..88d7d22 100644
> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> @@ -1003,6 +1003,10 @@ sdhci_esdhc_imx_probe_dt(struct platform_device
> *pdev,
> host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
> }
>
> + if (!of_property_read_u32(np, "bus-width", &boarddata-
> >max_bus_width)
> + && boarddata->max_bus_width == 1)
> + host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA;
> +
> /* call to generic mmc_of_parse to support additional capabilities */
> ret = mmc_of_parse(host->mmc);
> if (ret)
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 1/2] mmc: sdhci: dt: Add device tree properties sdhci-caps and sdhci-caps-mask
From: Zach Brown @ 2016-11-02 15:26 UTC (permalink / raw)
To: ulf.hansson
Cc: adrian.hunter, robh+dt, mark.rutland, linux-mmc, devicetree,
linux-kernel, zach.brown
In-Reply-To: <1478100376-602-1-git-send-email-zach.brown@ni.com>
On some systems the sdhci capabilty register is incorrect for one
reason or another.
The sdhci-caps-mask property specifies which bits in the register
are incorrect and should be turned off before using sdhci-caps to turn
on bits.
The sdhci-caps property specifies which bits should be turned on.
Signed-off-by: Zach Brown <zach.brown@ni.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/mmc/sdhci.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci.txt
diff --git a/Documentation/devicetree/bindings/mmc/sdhci.txt b/Documentation/devicetree/bindings/mmc/sdhci.txt
new file mode 100644
index 0000000..0f4f1bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci.txt
@@ -0,0 +1,14 @@
+The properties specific for SD host controllers. For properties shared by MMC
+host controllers refer to the mmc[1] bindings.
+
+ [1] Documentation/devicetree/bindings/mmc/mmc.txt
+
+Optional properties:
+- sdhci-caps-mask: The sdhci capabilities register is incorrect. This 64bit
+ property corresponds to the bits in the sdhci capabilty register. If the bit
+ is on in the mask then the bit is incorrect in the register and should be
+ turned off, before applying sdhci-caps.
+- sdhci-caps: The sdhci capabilities register is incorrect. This 64bit
+ property corresponds to the bits in the sdhci capability register. If the
+ bit is on in the property then the bit should be turned on.
+
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/2] mmc: sdhci: Use sdhci-caps-mask and sdhci-caps to change the caps read during __sdhci_read_caps
From: Zach Brown @ 2016-11-02 15:26 UTC (permalink / raw)
To: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A
Cc: adrian.hunter-ral2JQCrhuEAvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, zach.brown-acOepvfBmUk
In-Reply-To: <1478100376-602-1-git-send-email-zach.brown-acOepvfBmUk@public.gmane.org>
The sdhci capabilities register can be incorrect. The sdhci-caps-mask
and sdhci-caps dt properties specify which bits of the register are
incorrect and what their values should be. This patch makes the sdhci
driver use those properties to correct the caps during
__sdhci_read_caps.
During __sdhci_read_caps
Use the sdhci-caps-mask property to turn off the incorrect bits of the
sdhci register after reading them.
Use the sdhci-caps to turn on bits after using sdhci-caps-mask to turn
off the incorrect ones.
Signed-off-by: Zach Brown <zach.brown-acOepvfBmUk@public.gmane.org>
Acked-by: Adrian Hunter <adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
drivers/mmc/host/sdhci.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1e25b01..eba5f39 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -22,6 +22,7 @@
#include <linux/scatterlist.h>
#include <linux/regulator/consumer.h>
#include <linux/pm_runtime.h>
+#include <linux/of.h>
#include <linux/leds.h>
@@ -2991,6 +2992,8 @@ static int sdhci_set_dma_mask(struct sdhci_host *host)
void __sdhci_read_caps(struct sdhci_host *host, u16 *ver, u32 *caps, u32 *caps1)
{
u16 v;
+ u64 dt_caps_mask = 0;
+ u64 dt_caps = 0;
if (host->read_caps)
return;
@@ -3005,18 +3008,35 @@ void __sdhci_read_caps(struct sdhci_host *host, u16 *ver, u32 *caps, u32 *caps1)
sdhci_do_reset(host, SDHCI_RESET_ALL);
+ of_property_read_u64(mmc_dev(host->mmc)->of_node,
+ "sdhci-caps-mask", &dt_caps_mask);
+ of_property_read_u64(mmc_dev(host->mmc)->of_node,
+ "sdhci-caps", &dt_caps);
+
v = ver ? *ver : sdhci_readw(host, SDHCI_HOST_VERSION);
host->version = (v & SDHCI_SPEC_VER_MASK) >> SDHCI_SPEC_VER_SHIFT;
if (host->quirks & SDHCI_QUIRK_MISSING_CAPS)
return;
- host->caps = caps ? *caps : sdhci_readl(host, SDHCI_CAPABILITIES);
+ if (caps) {
+ host->caps = *caps;
+ } else {
+ host->caps = sdhci_readl(host, SDHCI_CAPABILITIES);
+ host->caps &= ~lower_32_bits(dt_caps_mask);
+ host->caps |= lower_32_bits(dt_caps);
+ }
if (host->version < SDHCI_SPEC_300)
return;
- host->caps1 = caps1 ? *caps1 : sdhci_readl(host, SDHCI_CAPABILITIES_1);
+ if (caps1) {
+ host->caps1 = *caps1;
+ } else {
+ host->caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
+ host->caps1 &= ~upper_32_bits(dt_caps_mask);
+ host->caps1 |= upper_32_bits(dt_caps);
+ }
}
EXPORT_SYMBOL_GPL(__sdhci_read_caps);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 0/2] mmc: sdhci: Fix sdhci caps register bits with corrections provided by dt
From: Zach Brown @ 2016-11-02 15:26 UTC (permalink / raw)
To: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A
Cc: adrian.hunter-ral2JQCrhuEAvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, zach.brown-acOepvfBmUk
For various reasons the sdhci caps register can be incorrect. This patch set
introduces a general way to correct the bits when they are read to accurately
reflect the capabilties of the controller/board combo.
The first patch creates sdhci-caps and sdhci-caps-mask dt properties that
combined represent the correction to the sdhci caps register.
The second patch uses the new dt properties to correct the caps from the
register as they read during __sdhci_read_caps.
Changes from RFC:
* /s/registers/register
* Moved sdhci dt properties into new documentation file sdhci.txt
v2:
* Fixed style issue, all branches of 'if' should have {}
Zach Brown (2):
mmc: sdhci: dt: Add device tree properties sdhci-caps and
sdhci-caps-mask
mmc: sdhci: Use sdhci-caps-mask and sdhci-caps to change the caps read
during __sdhci_read_caps
Documentation/devicetree/bindings/mmc/sdhci.txt | 14 ++++++++++++++
drivers/mmc/host/sdhci.c | 24 ++++++++++++++++++++++--
2 files changed, 36 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci.txt
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 4/4] mmc: sdhci: Fix missing enhanced strobe setting during runtime resume
From: Adrian Hunter @ 2016-11-02 13:49 UTC (permalink / raw)
To: Ulf Hansson; +Cc: linux-mmc, Harjani Ritesh
In-Reply-To: <1478094551-24819-1-git-send-email-adrian.hunter@intel.com>
Restore enhanced strobe setting during runtime resume.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
---
drivers/mmc/host/sdhci.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index f8cb9a958738..146f442de1ad 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2921,6 +2921,10 @@ int sdhci_runtime_resume_host(struct sdhci_host *host)
spin_unlock_irqrestore(&host->lock, flags);
}
+ if ((mmc->caps2 & MMC_CAP2_HS400_ES) &&
+ mmc->ops->hs400_enhanced_strobe)
+ mmc->ops->hs400_enhanced_strobe(mmc, &mmc->ios);
+
spin_lock_irqsave(&host->lock, flags);
host->runtime_suspended = false;
--
1.9.1
^ permalink raw reply related
* [PATCH 3/4] mmc: sdhci: Reset cmd and data circuits after tuning failure
From: Adrian Hunter @ 2016-11-02 13:49 UTC (permalink / raw)
To: Ulf Hansson; +Cc: linux-mmc, Harjani Ritesh
In-Reply-To: <1478094551-24819-1-git-send-email-adrian.hunter@intel.com>
To prevent subsequent commands failing, ensure the cmd and data circuits
are reset after a tuning timeout.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
---
drivers/mmc/host/sdhci.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index e7e1a70645e3..f8cb9a958738 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2083,6 +2083,10 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
if (!host->tuning_done) {
pr_info(DRIVER_NAME ": Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock\n");
+
+ sdhci_do_reset(host, SDHCI_RESET_CMD);
+ sdhci_do_reset(host, SDHCI_RESET_DATA);
+
ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
ctrl &= ~SDHCI_CTRL_TUNED_CLK;
ctrl &= ~SDHCI_CTRL_EXEC_TUNING;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/4] mmc: sdhci: Fix unexpected data interrupt handling
From: Adrian Hunter @ 2016-11-02 13:49 UTC (permalink / raw)
To: Ulf Hansson; +Cc: linux-mmc, Harjani Ritesh
In-Reply-To: <1478094551-24819-1-git-send-email-adrian.hunter@intel.com>
In the busy response case (i.e. !host->data), an unexpected data interrupt
would result in clearing the data command as though it had completed but
without informing the upper layers and thus resulting in a hang. Fix by
only clearing the data command for data interrupts that are expected.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.8+
---
drivers/mmc/host/sdhci.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index ad135d4449e6..e7e1a70645e3 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2518,9 +2518,6 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 intmask)
if (!host->data) {
struct mmc_command *data_cmd = host->data_cmd;
- if (data_cmd)
- host->data_cmd = NULL;
-
/*
* The "data complete" interrupt is also used to
* indicate that a busy state has ended. See comment
@@ -2528,11 +2525,13 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 intmask)
*/
if (data_cmd && (data_cmd->flags & MMC_RSP_BUSY)) {
if (intmask & SDHCI_INT_DATA_TIMEOUT) {
+ host->data_cmd = NULL;
data_cmd->error = -ETIMEDOUT;
sdhci_finish_mrq(host, data_cmd->mrq);
return;
}
if (intmask & SDHCI_INT_DATA_END) {
+ host->data_cmd = NULL;
/*
* Some cards handle busy-end interrupt
* before the command completed, so make
--
1.9.1
^ permalink raw reply related
* [PATCH 1/4] mmc: sdhci: Fix CMD line reset interfering with ongoing data transfer
From: Adrian Hunter @ 2016-11-02 13:49 UTC (permalink / raw)
To: Ulf Hansson; +Cc: linux-mmc, Harjani Ritesh
In-Reply-To: <1478094551-24819-1-git-send-email-adrian.hunter@intel.com>
CMD line reset during an ongoing data transfer can cause the data transfer
to hang. Fix by delaying the reset until the data transfer is finished.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.8+
---
drivers/mmc/host/sdhci.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1e25b01600e1..ad135d4449e6 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2283,10 +2283,8 @@ static bool sdhci_request_done(struct sdhci_host *host)
for (i = 0; i < SDHCI_MAX_MRQS; i++) {
mrq = host->mrqs_done[i];
- if (mrq) {
- host->mrqs_done[i] = NULL;
+ if (mrq)
break;
- }
}
if (!mrq) {
@@ -2317,6 +2315,17 @@ static bool sdhci_request_done(struct sdhci_host *host)
* upon error conditions.
*/
if (sdhci_needs_reset(host, mrq)) {
+ /*
+ * Do not finish until command and data lines are available for
+ * reset. Note there can only be one other mrq, so it cannot
+ * also be in mrqs_done, otherwise host->cmd and host->data_cmd
+ * would both be null.
+ */
+ if (host->cmd || host->data_cmd) {
+ spin_unlock_irqrestore(&host->lock, flags);
+ return true;
+ }
+
/* Some controllers need this kick or reset won't work here */
if (host->quirks & SDHCI_QUIRK_CLOCK_BEFORE_RESET)
/* This is to force an update */
@@ -2324,10 +2333,8 @@ static bool sdhci_request_done(struct sdhci_host *host)
/* Spec says we should do both at the same time, but Ricoh
controllers do not like that. */
- if (!host->cmd)
- sdhci_do_reset(host, SDHCI_RESET_CMD);
- if (!host->data_cmd)
- sdhci_do_reset(host, SDHCI_RESET_DATA);
+ sdhci_do_reset(host, SDHCI_RESET_CMD);
+ sdhci_do_reset(host, SDHCI_RESET_DATA);
host->pending_reset = false;
}
@@ -2335,6 +2342,8 @@ static bool sdhci_request_done(struct sdhci_host *host)
if (!sdhci_has_requests(host))
sdhci_led_deactivate(host);
+ host->mrqs_done[i] = NULL;
+
mmiowb();
spin_unlock_irqrestore(&host->lock, flags);
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox