[PATCH 2/2] mmc: sdhci: Defer probe if regulator_get fails
vmmc and vqmmc regulators control the voltage to
the host and device. Defer the probe if either of
them is not registered.
Signed-off-by: Pavan Kunapuli pkunap...@nvidia.com
---
drivers/mmc/host/sdhci.c | 25 ++---
1 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 7922adb..925c403 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2844,11 +2844,17 @@ int sdhci_add_host(struct sdhci_host *host)
!(host-mmc-caps MMC_CAP_NONREMOVABLE))
mmc-caps |= MMC_CAP_NEEDS_POLL;
- /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
+ /*
+* If vqmmc regulator and no 1.8V signalling, then there's no UHS.
+* vqmmc regulator should be present. If it's not present,
+* assume the regulator driver registration is not yet done and
+* defer the probe.
+*/
host-vqmmc = regulator_get(mmc_dev(mmc), vqmmc);
if (IS_ERR(host-vqmmc)) {
- pr_info(%s: no vqmmc regulator found\n, mmc_hostname(mmc));
+ pr_err(%s: no vqmmc regulator found\n, mmc_hostname(mmc));
host-vqmmc = NULL;
+ return -EPROBE_DEFER;
}
else if (regulator_is_supported_voltage(host-vqmmc, 180, 180))
regulator_enable(host-vqmmc);
@@ -2903,10 +2909,17 @@ int sdhci_add_host(struct sdhci_host *host)
ocr_avail = 0;
+ /*
+* vmmc regulator should be present. If it's not present,
+* assume the regulator driver registration is not yet done
+* and defer the probe.
+*/
host-vmmc = regulator_get(mmc_dev(mmc), vmmc);
if (IS_ERR(host-vmmc)) {
- pr_info(%s: no vmmc regulator found\n, mmc_hostname(mmc));
+ pr_err(%s: no vmmc regulator found\n, mmc_hostname(mmc));
host-vmmc = NULL;
+ ret = -EPROBE_DEFER;
+ goto vmmc_err;
} else
regulator_enable(host-vmmc);
@@ -3121,7 +3134,13 @@ reset:
untasklet:
tasklet_kill(host-card_tasklet);
tasklet_kill(host-finish_tasklet);
+vmmc_err:
+ if (host-vqmmc) {
+ if (regulator_is_enabled(host-vqmmc))
+ regulator_disable(host-vqmmc);
+ regulator_put(host-vqmmc);
+ }
return ret;
}
--
1.7.1.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 0/2] mmc: sdhci: Defer probe if regulators are not registered
Regulator driver registration may sometimes be done after mmc driver registration. In such cases, defer mmc probe to obtain vmmc and vmmcq regulators. Added vmmc and vmmcq supplies to tegra dt files. Pavan Kunapuli (2): ARM: dt: tegra: Add sdhci regulators mmc: sdhci: Defer probe if regulator_get fails arch/arm/boot/dts/tegra20-harmony.dts| 27 - arch/arm/boot/dts/tegra20-paz00.dts | 24 +++- arch/arm/boot/dts/tegra20-seaboard.dts | 35 - arch/arm/boot/dts/tegra20-tamonten.dtsi | 10 arch/arm/boot/dts/tegra20-ventana.dts| 36 - arch/arm/boot/dts/tegra20-whistler.dts |9 +- arch/arm/boot/dts/tegra30-cardhu-a02.dts |2 + arch/arm/boot/dts/tegra30-cardhu-a04.dts |2 + arch/arm/boot/dts/tegra30-cardhu.dtsi| 19 ++- drivers/mmc/host/sdhci.c | 25 ++-- 10 files changed, 176 insertions(+), 13 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: process hangs on do_exit when oom happens
This process was moved to RT-priority queue when global oom-killer happened to boost the recovery of the system.. but it wasn't get properily dealt with. I still have no idea why where the problem is .. On Tue, Oct 23, 2012 at 12:40 PM, Balbir Singh bsinghar...@gmail.com wrote: On Tue, Oct 23, 2012 at 9:05 AM, Qiang Gao gaoqiangs...@gmail.com wrote: information about the system is in the attach file information.txt I can not reproduce it in the upstream 3.6.0 kernel.. On Sat, Oct 20, 2012 at 12:04 AM, Michal Hocko mho...@suse.cz wrote: On Wed 17-10-12 18:23:34, gaoqiang wrote: I looked up nothing useful with google,so I'm here for help.. when this happens: I use memcg to limit the memory use of a process,and when the memcg cgroup was out of memory, the process was oom-killed however,it cannot really complete the exiting. here is the some information How many tasks are in the group and what kind of memory do they use? Is it possible that you were hit by the same issue as described in 79dfdacc memcg: make oom_lock 0 and 1 based rather than counter. OS version: centos6.22.6.32.220.7.1 Your kernel is quite old and you should be probably asking your distribution to help you out. There were many fixes since 2.6.32. Are you able to reproduce the same issue with the current vanila kernel? /proc/pid/stack --- [810597ca] __cond_resched+0x2a/0x40 [81121569] unmap_vmas+0xb49/0xb70 [8112822e] exit_mmap+0x7e/0x140 [8105b078] mmput+0x58/0x110 [81061aad] exit_mm+0x11d/0x160 [81061c9d] do_exit+0x1ad/0x860 [81062391] do_group_exit+0x41/0xb0 [81077cd8] get_signal_to_deliver+0x1e8/0x430 [8100a4c4] do_notify_resume+0xf4/0x8b0 [8100b281] int_signal+0x12/0x17 [] 0x This looks strange because this is just an exit part which shouldn't deadlock or anything. Is this stack stable? Have you tried to take check it more times? Looking at information.txt, I found something interesting rt_rq[0]:/1314 .rt_nr_running : 1 .rt_throttled : 1 .rt_time : 0.856656 .rt_runtime: 0.00 cfs_rq[0]:/1314 .exec_clock: 8738.133429 .MIN_vruntime : 0.01 .min_vruntime : 8739.371271 .max_vruntime : 0.01 .spread: 0.00 .spread0 : -9792.24 .nr_spread_over: 1 .nr_running: 0 .load : 0 .load_avg : 7376.722880 .load_period : 7.203830 .load_contrib : 1023 .load_tg : 1023 .se-exec_start: 282004.715064 .se-vruntime : 18435.664560 .se-sum_exec_runtime : 8738.133429 .se-wait_start: 0.00 .se-sleep_start : 0.00 .se-block_start : 0.00 .se-sleep_max : 0.00 .se-block_max : 0.00 .se-exec_max : 77.977054 .se-slice_max : 0.00 .se-wait_max : 2.664779 .se-wait_sum : 29.970575 .se-wait_count: 102 .se-load.weight : 2 So 1314 is a real time process and cpu.rt_period_us: 100 -- cpu.rt_runtime_us: 0 When did tt move to being a Real Time process (hint: see nr_running and nr_throttled)? Balbir -- 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 1/2] ARM: dt: tegra: Add sdhci regulators
Adding vmmc and vmmcq supplies for sdhci nodes
in tegra dt files.
Signed-off-by: Pavan Kunapuli pkunap...@nvidia.com
---
arch/arm/boot/dts/tegra20-harmony.dts| 27 -
arch/arm/boot/dts/tegra20-paz00.dts | 24 +++-
arch/arm/boot/dts/tegra20-seaboard.dts | 35 -
arch/arm/boot/dts/tegra20-tamonten.dtsi | 10
arch/arm/boot/dts/tegra20-ventana.dts| 36 -
arch/arm/boot/dts/tegra20-whistler.dts |9 +-
arch/arm/boot/dts/tegra30-cardhu-a02.dts |2 +
arch/arm/boot/dts/tegra30-cardhu-a04.dts |2 +
arch/arm/boot/dts/tegra30-cardhu.dtsi| 19 ++-
9 files changed, 154 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-harmony.dts
b/arch/arm/boot/dts/tegra20-harmony.dts
index 74b8a47..5b02afe 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -419,7 +419,8 @@
status = okay;
cd-gpios = gpio 69 0; /* gpio PI5 */
wp-gpios = gpio 57 0; /* gpio PH1 */
- power-gpios = gpio 155 0; /* gpio PT3 */
+ vmmc-supply = vddio_sd_reg;
+ vqmmc-supply = vddio_sd_reg;
bus-width = 4;
};
@@ -427,7 +428,8 @@
status = okay;
cd-gpios = gpio 58 0; /* gpio PH2 */
wp-gpios = gpio 59 0; /* gpio PH3 */
- power-gpios = gpio 70 0; /* gpio PI6 */
+ vmmc-supply = vddio_sdmmc_reg;
+ vqmmc-supply = vddio_sdmmc_reg;
bus-width = 8;
};
@@ -495,6 +497,27 @@
gpio = gpio 176 0; /* gpio PW0 */
enable-active-high;
};
+
+ vddio_sdmmc_reg: regulator@6 {
+ compatible = regulator-fixed;
+ reg = 6;
+ regulator-name = vddio_sdmmc;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio 70 0; /* gpio PW0 */
+ enable-active-high;
+ };
+
+ vddio_sd_reg: regulator@7 {
+ compatible = regulator-fixed;
+ reg = 7;
+ regulator-name = vddio_sd;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio 155 0; /* gpio PW0 */
+ enable-active-high;
+ };
+
};
sound {
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
b/arch/arm/boot/dts/tegra20-paz00.dts
index 6a93d14..e161b65 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -422,13 +422,17 @@
status = okay;
cd-gpios = gpio 173 0; /* gpio PV5 */
wp-gpios = gpio 57 0; /* gpio PH1 */
- power-gpios = gpio 169 0; /* gpio PV1 */
bus-width = 4;
+ vmmc-supply = vddio_sd_reg;
+ vqmmc-supply = vddio_sd_reg;
+
};
sdhci@c8000600 {
status = okay;
bus-width = 8;
+ vmmc-supply = vddio_sdmmc_reg;
+ vqmmc-supply = vddio_sdmmc_reg;
};
gpio-keys {
@@ -465,6 +469,24 @@
regulator-max-microvolt = 500;
regulator-always-on;
};
+
+ vddio_sd_reg: regulator@1 {
+ compatible = regulator-fixed;
+ reg = 1;
+ regulator-name = vddio_sd;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ enable-active-high;
+ gpio = gpio 169 0; /* gpio PV1 */
+ };
+
+ vddio_sdmmc_reg: regulator@2 {
+ compatible = regulator-fixed;
+ reg = 2;
+ regulator-name = vddio_sdmmc;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
};
sound {
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts
b/arch/arm/boot/dts/tegra20-seaboard.dts
index eafeca6..1b7d692 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -450,7 +450,7 @@
regulator-always-on;
};
- ldo5 {
+ ldo5_reg: ldo5 {
regulator-name = vdd_ldo5,vcore_mmc;
regulator-min-microvolt = 285;
[PATCH 0/2] mmc: sdhci: Defer probe if regulators are not registered
Regulator driver registration may sometimes be done after mmc driver registration. In such cases, defer mmc probe to obtain vmmc and vmmcq regulators. Added vmmc and vmmcq supplies to tegra dt files. Pavan Kunapuli (2): ARM: dt: tegra: Add sdhci regulators mmc: sdhci: Defer probe if regulator_get fails arch/arm/boot/dts/tegra20-harmony.dts| 27 - arch/arm/boot/dts/tegra20-paz00.dts | 24 +++- arch/arm/boot/dts/tegra20-seaboard.dts | 35 - arch/arm/boot/dts/tegra20-tamonten.dtsi | 10 arch/arm/boot/dts/tegra20-ventana.dts| 36 - arch/arm/boot/dts/tegra20-whistler.dts |9 +- arch/arm/boot/dts/tegra30-cardhu-a02.dts |2 + arch/arm/boot/dts/tegra30-cardhu-a04.dts |2 + arch/arm/boot/dts/tegra30-cardhu.dtsi| 19 ++- drivers/mmc/host/sdhci.c | 25 ++-- 10 files changed, 176 insertions(+), 13 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dt: tegra: Add sdhci regulators
Adding vmmc and vmmcq supplies for sdhci nodes
in tegra dt files.
Signed-off-by: Pavan Kunapuli pkunap...@nvidia.com
---
arch/arm/boot/dts/tegra20-harmony.dts| 27 -
arch/arm/boot/dts/tegra20-paz00.dts | 24 +++-
arch/arm/boot/dts/tegra20-seaboard.dts | 35 -
arch/arm/boot/dts/tegra20-tamonten.dtsi | 10
arch/arm/boot/dts/tegra20-ventana.dts| 36 -
arch/arm/boot/dts/tegra20-whistler.dts |9 +-
arch/arm/boot/dts/tegra30-cardhu-a02.dts |2 +
arch/arm/boot/dts/tegra30-cardhu-a04.dts |2 +
arch/arm/boot/dts/tegra30-cardhu.dtsi| 19 ++-
9 files changed, 154 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-harmony.dts
b/arch/arm/boot/dts/tegra20-harmony.dts
index 74b8a47..5b02afe 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -419,7 +419,8 @@
status = okay;
cd-gpios = gpio 69 0; /* gpio PI5 */
wp-gpios = gpio 57 0; /* gpio PH1 */
- power-gpios = gpio 155 0; /* gpio PT3 */
+ vmmc-supply = vddio_sd_reg;
+ vqmmc-supply = vddio_sd_reg;
bus-width = 4;
};
@@ -427,7 +428,8 @@
status = okay;
cd-gpios = gpio 58 0; /* gpio PH2 */
wp-gpios = gpio 59 0; /* gpio PH3 */
- power-gpios = gpio 70 0; /* gpio PI6 */
+ vmmc-supply = vddio_sdmmc_reg;
+ vqmmc-supply = vddio_sdmmc_reg;
bus-width = 8;
};
@@ -495,6 +497,27 @@
gpio = gpio 176 0; /* gpio PW0 */
enable-active-high;
};
+
+ vddio_sdmmc_reg: regulator@6 {
+ compatible = regulator-fixed;
+ reg = 6;
+ regulator-name = vddio_sdmmc;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio 70 0; /* gpio PW0 */
+ enable-active-high;
+ };
+
+ vddio_sd_reg: regulator@7 {
+ compatible = regulator-fixed;
+ reg = 7;
+ regulator-name = vddio_sd;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio 155 0; /* gpio PW0 */
+ enable-active-high;
+ };
+
};
sound {
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
b/arch/arm/boot/dts/tegra20-paz00.dts
index 6a93d14..e161b65 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -422,13 +422,17 @@
status = okay;
cd-gpios = gpio 173 0; /* gpio PV5 */
wp-gpios = gpio 57 0; /* gpio PH1 */
- power-gpios = gpio 169 0; /* gpio PV1 */
bus-width = 4;
+ vmmc-supply = vddio_sd_reg;
+ vqmmc-supply = vddio_sd_reg;
+
};
sdhci@c8000600 {
status = okay;
bus-width = 8;
+ vmmc-supply = vddio_sdmmc_reg;
+ vqmmc-supply = vddio_sdmmc_reg;
};
gpio-keys {
@@ -465,6 +469,24 @@
regulator-max-microvolt = 500;
regulator-always-on;
};
+
+ vddio_sd_reg: regulator@1 {
+ compatible = regulator-fixed;
+ reg = 1;
+ regulator-name = vddio_sd;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ enable-active-high;
+ gpio = gpio 169 0; /* gpio PV1 */
+ };
+
+ vddio_sdmmc_reg: regulator@2 {
+ compatible = regulator-fixed;
+ reg = 2;
+ regulator-name = vddio_sdmmc;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
};
sound {
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts
b/arch/arm/boot/dts/tegra20-seaboard.dts
index eafeca6..1b7d692 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -450,7 +450,7 @@
regulator-always-on;
};
- ldo5 {
+ ldo5_reg: ldo5 {
regulator-name = vdd_ldo5,vcore_mmc;
regulator-min-microvolt = 285;
[PATCH 2/2] mmc: sdhci: Defer probe if regulator_get fails
vmmc and vqmmc regulators control the voltage to
the host and device. Defer the probe if either of
them is not registered.
Signed-off-by: Pavan Kunapuli pkunap...@nvidia.com
---
drivers/mmc/host/sdhci.c | 25 ++---
1 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 7922adb..925c403 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2844,11 +2844,17 @@ int sdhci_add_host(struct sdhci_host *host)
!(host-mmc-caps MMC_CAP_NONREMOVABLE))
mmc-caps |= MMC_CAP_NEEDS_POLL;
- /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
+ /*
+* If vqmmc regulator and no 1.8V signalling, then there's no UHS.
+* vqmmc regulator should be present. If it's not present,
+* assume the regulator driver registration is not yet done and
+* defer the probe.
+*/
host-vqmmc = regulator_get(mmc_dev(mmc), vqmmc);
if (IS_ERR(host-vqmmc)) {
- pr_info(%s: no vqmmc regulator found\n, mmc_hostname(mmc));
+ pr_err(%s: no vqmmc regulator found\n, mmc_hostname(mmc));
host-vqmmc = NULL;
+ return -EPROBE_DEFER;
}
else if (regulator_is_supported_voltage(host-vqmmc, 180, 180))
regulator_enable(host-vqmmc);
@@ -2903,10 +2909,17 @@ int sdhci_add_host(struct sdhci_host *host)
ocr_avail = 0;
+ /*
+* vmmc regulator should be present. If it's not present,
+* assume the regulator driver registration is not yet done
+* and defer the probe.
+*/
host-vmmc = regulator_get(mmc_dev(mmc), vmmc);
if (IS_ERR(host-vmmc)) {
- pr_info(%s: no vmmc regulator found\n, mmc_hostname(mmc));
+ pr_err(%s: no vmmc regulator found\n, mmc_hostname(mmc));
host-vmmc = NULL;
+ ret = -EPROBE_DEFER;
+ goto vmmc_err;
} else
regulator_enable(host-vmmc);
@@ -3121,7 +3134,13 @@ reset:
untasklet:
tasklet_kill(host-card_tasklet);
tasklet_kill(host-finish_tasklet);
+vmmc_err:
+ if (host-vqmmc) {
+ if (regulator_is_enabled(host-vqmmc))
+ regulator_disable(host-vqmmc);
+ regulator_put(host-vqmmc);
+ }
return ret;
}
--
1.7.1.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] powerpc/esdhc: enable the card insert/remove interrupt
From: Jerry Huang chang-ming.hu...@freescale.com
The current eSDHC driver use the poll mode to detect
if the SD/MMC card is inserted or removed, which will generate
many interrupts and impact the performance.
Therefore, change the default card detect to interrupt mode,
if the board can't support this mode, we still use the poll mode.
Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com
CC: Anton Vorontsov cbouatmai...@gmail.com
CC: Chris Ball c...@laptop.org
---
drivers/mmc/host/sdhci-of-esdhc.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
b/drivers/mmc/host/sdhci-of-esdhc.c
index ffc1226..5dc362f 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -196,6 +196,11 @@ static void esdhc_of_detect_limitation(struct
platform_device *pdev,
if (vvn == VENDOR_V_22)
pdata-quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
+ /* P4080DS and MPC837XMDS board don't support interrupt mode */
+ if (of_machine_is_compatible(fsl,mpc837xmds) ||
+ of_machine_is_compatible(fsl,P4080DS))
+ pdata-quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;
+
iounmap(ioaddr);
end:
return;
@@ -223,7 +228,7 @@ static struct sdhci_pltfm_data sdhci_esdhc_pdata = {
* card detection could be handled via GPIO
* eSDHC cannot support End Attribute in NOP ADMA descriptor
*/
- .quirks = ESDHC_DEFAULT_QUIRKS | SDHCI_QUIRK_BROKEN_CARD_DETECTION
+ .quirks = ESDHC_DEFAULT_QUIRKS
| SDHCI_QUIRK_NO_CARD_NO_RESET
| SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC,
.ops = sdhci_esdhc_ops,
--
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 2/2] mmc: sdhci: Defer probe if regulator_get fails
Am Dienstag, den 23.10.2012, 12:49 +0530 schrieb Pavan Kunapuli:
vmmc and vqmmc regulators control the voltage to
the host and device. Defer the probe if either of
them is not registered.
Does this work with boards where we don't have any MMC supplies? Or are
we just deferring the probe indefinitely there?
For boards that power MMC unconditionally, are we supposed to add dummy
regulators to make them work with this patchset?
Signed-off-by: Pavan Kunapuli pkunap...@nvidia.com
---
drivers/mmc/host/sdhci.c | 25 ++---
1 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 7922adb..925c403 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2844,11 +2844,17 @@ int sdhci_add_host(struct sdhci_host *host)
!(host-mmc-caps MMC_CAP_NONREMOVABLE))
mmc-caps |= MMC_CAP_NEEDS_POLL;
- /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
+ /*
+ * If vqmmc regulator and no 1.8V signalling, then there's no UHS.
+ * vqmmc regulator should be present. If it's not present,
+ * assume the regulator driver registration is not yet done and
+ * defer the probe.
+ */
host-vqmmc = regulator_get(mmc_dev(mmc), vqmmc);
if (IS_ERR(host-vqmmc)) {
- pr_info(%s: no vqmmc regulator found\n, mmc_hostname(mmc));
+ pr_err(%s: no vqmmc regulator found\n, mmc_hostname(mmc));
host-vqmmc = NULL;
+ return -EPROBE_DEFER;
}
else if (regulator_is_supported_voltage(host-vqmmc, 180, 180))
regulator_enable(host-vqmmc);
@@ -2903,10 +2909,17 @@ int sdhci_add_host(struct sdhci_host *host)
ocr_avail = 0;
+ /*
+ * vmmc regulator should be present. If it's not present,
+ * assume the regulator driver registration is not yet done
+ * and defer the probe.
+ */
host-vmmc = regulator_get(mmc_dev(mmc), vmmc);
if (IS_ERR(host-vmmc)) {
- pr_info(%s: no vmmc regulator found\n, mmc_hostname(mmc));
+ pr_err(%s: no vmmc regulator found\n, mmc_hostname(mmc));
host-vmmc = NULL;
+ ret = -EPROBE_DEFER;
+ goto vmmc_err;
} else
regulator_enable(host-vmmc);
@@ -3121,7 +3134,13 @@ reset:
untasklet:
tasklet_kill(host-card_tasklet);
tasklet_kill(host-finish_tasklet);
+vmmc_err:
+ if (host-vqmmc) {
+ if (regulator_is_enabled(host-vqmmc))
+ regulator_disable(host-vqmmc);
+ regulator_put(host-vqmmc);
+ }
return ret;
}
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] mmc: sdhci: Defer probe if regulator_get fails
Does this work with boards where we don't have any MMC supplies? Or are we
just deferring the probe indefinitely there?
The probe will be deferred indefinitely.
For boards that power MMC unconditionally, are we supposed to add dummy
regulators to make them work with this patchset?
Yes. We need to add dummy regulators for boards that power MMC unconditionally.
I am not sure if there is any other solution other than using deferred probe
that would guarantee regulators availability.
-Original Message-
From: Lucas Stach [mailto:d...@lynxeye.de]
Sent: 23 October 2012 13:27
To: Pavan Kunapuli
Cc: swar...@wwwdotorg.org; li...@arm.linux.org.uk; c...@laptop.org;
linux-te...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
linux-ker...@vger.kernel.org; linux-mmc@vger.kernel.org
Subject: Re: [PATCH 2/2] mmc: sdhci: Defer probe if regulator_get fails
Am Dienstag, den 23.10.2012, 12:49 +0530 schrieb Pavan Kunapuli:
vmmc and vqmmc regulators control the voltage to the host and device.
Defer the probe if either of them is not registered.
Does this work with boards where we don't have any MMC supplies? Or are we just
deferring the probe indefinitely there?
For boards that power MMC unconditionally, are we supposed to add dummy
regulators to make them work with this patchset?
Signed-off-by: Pavan Kunapuli pkunap...@nvidia.com
---
drivers/mmc/host/sdhci.c | 25 ++---
1 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index
7922adb..925c403 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2844,11 +2844,17 @@ int sdhci_add_host(struct sdhci_host *host)
!(host-mmc-caps MMC_CAP_NONREMOVABLE))
mmc-caps |= MMC_CAP_NEEDS_POLL;
- /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
+ /*
+ * If vqmmc regulator and no 1.8V signalling, then there's no UHS.
+ * vqmmc regulator should be present. If it's not present,
+ * assume the regulator driver registration is not yet done and
+ * defer the probe.
+ */
host-vqmmc = regulator_get(mmc_dev(mmc), vqmmc);
if (IS_ERR(host-vqmmc)) {
- pr_info(%s: no vqmmc regulator found\n, mmc_hostname(mmc));
+ pr_err(%s: no vqmmc regulator found\n, mmc_hostname(mmc));
host-vqmmc = NULL;
+ return -EPROBE_DEFER;
}
else if (regulator_is_supported_voltage(host-vqmmc, 180, 180))
regulator_enable(host-vqmmc);
@@ -2903,10 +2909,17 @@ int sdhci_add_host(struct sdhci_host *host)
ocr_avail = 0;
+ /*
+ * vmmc regulator should be present. If it's not present,
+ * assume the regulator driver registration is not yet done
+ * and defer the probe.
+ */
host-vmmc = regulator_get(mmc_dev(mmc), vmmc);
if (IS_ERR(host-vmmc)) {
- pr_info(%s: no vmmc regulator found\n, mmc_hostname(mmc));
+ pr_err(%s: no vmmc regulator found\n, mmc_hostname(mmc));
host-vmmc = NULL;
+ ret = -EPROBE_DEFER;
+ goto vmmc_err;
} else
regulator_enable(host-vmmc);
@@ -3121,7 +3134,13 @@ reset:
untasklet:
tasklet_kill(host-card_tasklet);
tasklet_kill(host-finish_tasklet);
+vmmc_err:
+ if (host-vqmmc) {
+ if (regulator_is_enabled(host-vqmmc))
+ regulator_disable(host-vqmmc);
+ regulator_put(host-vqmmc);
+ }
return ret;
}
Re: process hangs on do_exit when oom happens
On Tue 23-10-12 11:35:52, Qiang Gao wrote: I'm sure this is a global-oom,not cgroup-oom. [the dmesg output in the end] Yes this is the global oom killer because: cglimit -M 700M ./tt then after global-oom,the process hangs.. 179184 pages RAM So you have ~700M of RAM so the memcg limit is basically pointless as it cannot be reached... -- Michal Hocko SUSE Labs -- 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
Anton,
could you give some comment about this patch?
Reviewed by Girish last month.
Best Regards
Jerry Huang
-Original Message-
From: Huang Changming-R66093
Sent: Monday, October 15, 2012 11:07 AM
To: Huang Changming-R66093; Anton Vorontsov; Chris Ball
Cc: linux-mmc@vger.kernel.org; Xie Shaohui-B21989; Girish K S
Subject: RE: [PATCH v5] powerpc/esdhc: disable CMD23 for some Freescale
SoCs
Anton,
Have you any comment about this patch?
Best Regards
Jerry Huang
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Huang Changming-R66093
Sent: Tuesday, October 09, 2012 2:24 PM
To: Anton Vorontsov; Chris Ball
Cc: linux-mmc@vger.kernel.org; Xie Shaohui-B21989; Girish K S
Subject: RE: [PATCH v5] powerpc/esdhc: disable CMD23 for some
Freescale SoCs
Hi, Anto and Chris
This version was created with the feedback from Kumar and all of you.
Have you any comment about this patch?
Could it be merged into kernel?
Best Regards
Jerry Huang
-Original Message-
From: Girish K S [mailto:girish.shivananja...@linaro.org]
Sent: Wednesday, September 26, 2012 9:04 PM
To: Huang Changming-R66093
Cc: linux-mmc@vger.kernel.org; Huang Changming-R66093; Xie
Shaohui-B21989; Anton Vorontsov; Chris Ball
Subject: Re: [PATCH v5] powerpc/esdhc: disable CMD23 for some
Freescale SoCs
Looks good
Reviewed By:- Girish K S girish.shivananja...@linaro.org
On 26 September 2012 15:02, r66...@freescale.com wrote:
From: Jerry Huang chang-ming.hu...@freescale.com
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 chang-ming.hu...@freescale.com
Signed-off-by: Shaohui Xie shaohui@freescale.com
CC: Anton Vorontsov cbouatmai...@gmail.com
CC: Chris Ball c...@laptop.org
---
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
Re: process hangs on do_exit when oom happens
On 10/23/2012 11:35 AM, Qiang Gao wrote: information about the system is in the attach file information.txt I can not reproduce it in the upstream 3.6.0 kernel.. On Sat, Oct 20, 2012 at 12:04 AM, Michal Hockomho...@suse.cz wrote: On Wed 17-10-12 18:23:34, gaoqiang wrote: I looked up nothing useful with google,so I'm here for help.. when this happens: I use memcg to limit the memory use of a process,and when the memcg cgroup was out of memory, the process was oom-killed however,it cannot really complete the exiting. here is the some information How many tasks are in the group and what kind of memory do they use? Is it possible that you were hit by the same issue as described in 79dfdacc memcg: make oom_lock 0 and 1 based rather than counter. OS version: centos6.22.6.32.220.7.1 Your kernel is quite old and you should be probably asking your distribution to help you out. There were many fixes since 2.6.32. Are you able to reproduce the same issue with the current vanila kernel? /proc/pid/stack --- [810597ca] __cond_resched+0x2a/0x40 [81121569] unmap_vmas+0xb49/0xb70 [8112822e] exit_mmap+0x7e/0x140 [8105b078] mmput+0x58/0x110 [81061aad] exit_mm+0x11d/0x160 [81061c9d] do_exit+0x1ad/0x860 [81062391] do_group_exit+0x41/0xb0 [81077cd8] get_signal_to_deliver+0x1e8/0x430 [8100a4c4] do_notify_resume+0xf4/0x8b0 [8100b281] int_signal+0x12/0x17 [] 0x This looks strange because this is just an exit part which shouldn't deadlock or anything. Is this stack stable? Have you tried to take check it more times? Does the machine only have about 700M memory? I also find something in the log file: Node 0 DMA free:2772kB min:72kB low:88kB high:108kB present:15312kB.. lowmem_reserve[]: 0 674 674 674 Node 0 DMA32 free:*3172kB* min:3284kB low:4104kB high:4924kB present:690712kB .. lowmem_reserve[]: 0 0 0 0 0 pages in swap cache Swap cache stats: add 0, delete 0, find 0/0 Free swap = 0kB Total swap = 0kB 179184 pages RAM == 179184 * 4 / 1024 = *700M* 6773 pages reserved Note that the free memory of DMA32(3172KB) is lower than min watermark, which means the global is under pressure now. What's more the swap is off, so the global oom is normal behavior. Thanks, Sha -- 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: process hangs on do_exit when oom happens
this is just an example to show how to reproduce. actually,the first time I saw this situation was on a machine with 288G RAM with many tasks running and we limit 30G for each. but finanlly, no one exceeds this limit the the system oom. On Tue, Oct 23, 2012 at 4:35 PM, Michal Hocko mho...@suse.cz wrote: On Tue 23-10-12 11:35:52, Qiang Gao wrote: I'm sure this is a global-oom,not cgroup-oom. [the dmesg output in the end] Yes this is the global oom killer because: cglimit -M 700M ./tt then after global-oom,the process hangs.. 179184 pages RAM So you have ~700M of RAM so the memcg limit is basically pointless as it cannot be reached... -- Michal Hocko SUSE Labs -- 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: process hangs on do_exit when oom happens
global-oom is the right thing to do. but oom-killed-process hanging on do_exit is not the normal behavior On Tue, Oct 23, 2012 at 5:01 PM, Sha Zhengju handai@gmail.com wrote: On 10/23/2012 11:35 AM, Qiang Gao wrote: information about the system is in the attach file information.txt I can not reproduce it in the upstream 3.6.0 kernel.. On Sat, Oct 20, 2012 at 12:04 AM, Michal Hockomho...@suse.cz wrote: On Wed 17-10-12 18:23:34, gaoqiang wrote: I looked up nothing useful with google,so I'm here for help.. when this happens: I use memcg to limit the memory use of a process,and when the memcg cgroup was out of memory, the process was oom-killed however,it cannot really complete the exiting. here is the some information How many tasks are in the group and what kind of memory do they use? Is it possible that you were hit by the same issue as described in 79dfdacc memcg: make oom_lock 0 and 1 based rather than counter. OS version: centos6.22.6.32.220.7.1 Your kernel is quite old and you should be probably asking your distribution to help you out. There were many fixes since 2.6.32. Are you able to reproduce the same issue with the current vanila kernel? /proc/pid/stack --- [810597ca] __cond_resched+0x2a/0x40 [81121569] unmap_vmas+0xb49/0xb70 [8112822e] exit_mmap+0x7e/0x140 [8105b078] mmput+0x58/0x110 [81061aad] exit_mm+0x11d/0x160 [81061c9d] do_exit+0x1ad/0x860 [81062391] do_group_exit+0x41/0xb0 [81077cd8] get_signal_to_deliver+0x1e8/0x430 [8100a4c4] do_notify_resume+0xf4/0x8b0 [8100b281] int_signal+0x12/0x17 [] 0x This looks strange because this is just an exit part which shouldn't deadlock or anything. Is this stack stable? Have you tried to take check it more times? Does the machine only have about 700M memory? I also find something in the log file: Node 0 DMA free:2772kB min:72kB low:88kB high:108kB present:15312kB.. lowmem_reserve[]: 0 674 674 674 Node 0 DMA32 free:*3172kB* min:3284kB low:4104kB high:4924kB present:690712kB .. lowmem_reserve[]: 0 0 0 0 0 pages in swap cache Swap cache stats: add 0, delete 0, find 0/0 Free swap = 0kB Total swap = 0kB 179184 pages RAM == 179184 * 4 / 1024 = *700M* 6773 pages reserved Note that the free memory of DMA32(3172KB) is lower than min watermark, which means the global is under pressure now. What's more the swap is off, so the global oom is normal behavior. Thanks, Sha -- 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: process hangs on do_exit when oom happens
On Tue 23-10-12 17:08:40, Qiang Gao wrote: this is just an example to show how to reproduce. actually,the first time I saw this situation was on a machine with 288G RAM with many tasks running and we limit 30G for each. but finanlly, no one exceeds this limit the the system oom. Yes but mentioning memory controller then might be misleading... It seems that the only factor in your load is the cpu controller. And please stop top-posting. It makes the discussion messy. -- Michal Hocko SUSE Labs -- 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: process hangs on do_exit when oom happens
On Tue 23-10-12 15:18:48, Qiang Gao wrote: This process was moved to RT-priority queue when global oom-killer happened to boost the recovery of the system.. Who did that? oom killer doesn't boost the priority (scheduling class) AFAIK. but it wasn't get properily dealt with. I still have no idea why where the problem is .. Well your configuration says that there is no runtime reserved for the group. Please refer to Documentation/scheduler/sched-rt-group.txt for more information. On Tue, Oct 23, 2012 at 12:40 PM, Balbir Singh bsinghar...@gmail.com wrote: On Tue, Oct 23, 2012 at 9:05 AM, Qiang Gao gaoqiangs...@gmail.com wrote: information about the system is in the attach file information.txt I can not reproduce it in the upstream 3.6.0 kernel.. On Sat, Oct 20, 2012 at 12:04 AM, Michal Hocko mho...@suse.cz wrote: On Wed 17-10-12 18:23:34, gaoqiang wrote: I looked up nothing useful with google,so I'm here for help.. when this happens: I use memcg to limit the memory use of a process,and when the memcg cgroup was out of memory, the process was oom-killed however,it cannot really complete the exiting. here is the some information How many tasks are in the group and what kind of memory do they use? Is it possible that you were hit by the same issue as described in 79dfdacc memcg: make oom_lock 0 and 1 based rather than counter. OS version: centos6.22.6.32.220.7.1 Your kernel is quite old and you should be probably asking your distribution to help you out. There were many fixes since 2.6.32. Are you able to reproduce the same issue with the current vanila kernel? /proc/pid/stack --- [810597ca] __cond_resched+0x2a/0x40 [81121569] unmap_vmas+0xb49/0xb70 [8112822e] exit_mmap+0x7e/0x140 [8105b078] mmput+0x58/0x110 [81061aad] exit_mm+0x11d/0x160 [81061c9d] do_exit+0x1ad/0x860 [81062391] do_group_exit+0x41/0xb0 [81077cd8] get_signal_to_deliver+0x1e8/0x430 [8100a4c4] do_notify_resume+0xf4/0x8b0 [8100b281] int_signal+0x12/0x17 [] 0x This looks strange because this is just an exit part which shouldn't deadlock or anything. Is this stack stable? Have you tried to take check it more times? Looking at information.txt, I found something interesting rt_rq[0]:/1314 .rt_nr_running : 1 .rt_throttled : 1 .rt_time : 0.856656 .rt_runtime: 0.00 cfs_rq[0]:/1314 .exec_clock: 8738.133429 .MIN_vruntime : 0.01 .min_vruntime : 8739.371271 .max_vruntime : 0.01 .spread: 0.00 .spread0 : -9792.24 .nr_spread_over: 1 .nr_running: 0 .load : 0 .load_avg : 7376.722880 .load_period : 7.203830 .load_contrib : 1023 .load_tg : 1023 .se-exec_start: 282004.715064 .se-vruntime : 18435.664560 .se-sum_exec_runtime : 8738.133429 .se-wait_start: 0.00 .se-sleep_start : 0.00 .se-block_start : 0.00 .se-sleep_max : 0.00 .se-block_max : 0.00 .se-exec_max : 77.977054 .se-slice_max : 0.00 .se-wait_max : 2.664779 .se-wait_sum : 29.970575 .se-wait_count: 102 .se-load.weight : 2 So 1314 is a real time process and cpu.rt_period_us: 100 -- cpu.rt_runtime_us: 0 When did tt move to being a Real Time process (hint: see nr_running and nr_throttled)? Balbir -- To unsubscribe from this list: send the line unsubscribe cgroups in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Michal Hocko SUSE Labs -- 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] mm: make zone_pcp_reset independ on MEMORY_HOTREMOVE
At 10/23/2012 05:37 PM, Michal Hocko Wrote:
340175b7 (mm/hotplug: free zone-pageset when a zone becomes empty)
introduced zone_pcp_reset and hided it inside CONFIG_MEMORY_HOTREMOVE.
The function is since 506e5fb7 (memory-hotplug: allocate zone's pcp
before onlining pages) called also called from online_pages which
This patch is still in -mm tree, and I have received a report from
Liu Yuanhan.
is called outside CONFIG_MEMORY_HOTREMOVE which causes a linkage error.
The function, although not used outside of MEMORY_{HOTPLUT,HOTREMOVE},
seems like universal enough so let's keep it at its current location
and only remove the HOTREMOVE guard.
Signed-off-by: Michal Hocko mho...@suse.cz
Cc: David Rientjes rient...@google.com
Cc: Jiang Liu liu...@gmail.com
Cc: Len Brown len.br...@intel.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
Cc: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Cc: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Cc: Dave Hansen d...@linux.vnet.ibm.com
Cc: Mel Gorman m...@csn.ul.ie
---
mm/page_alloc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e29912e..30e359c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5981,7 +5981,6 @@ void __meminit zone_pcp_update(struct zone *zone)
}
#endif
-#ifdef CONFIG_MEMORY_HOTREMOVE
void zone_pcp_reset(struct zone *zone)
{
unsigned long flags;
@@ -6001,6 +6000,7 @@ void zone_pcp_reset(struct zone *zone)
local_irq_restore(flags);
}
+#ifdef CONFIG_MEMORY_HOTREMOVE
/*
* All pages in the range must be isolated before calling this.
*/
This patch looks find to me.
Reviewed-by: Wen Congyang we...@cn.fujitsu.com
--
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: process hangs on do_exit when oom happens
On Tue, Oct 23, 2012 at 5:50 PM, Michal Hocko mho...@suse.cz wrote: On Tue 23-10-12 15:18:48, Qiang Gao wrote: This process was moved to RT-priority queue when global oom-killer happened to boost the recovery of the system.. Who did that? oom killer doesn't boost the priority (scheduling class) AFAIK. but it wasn't get properily dealt with. I still have no idea why where the problem is .. Well your configuration says that there is no runtime reserved for the group. Please refer to Documentation/scheduler/sched-rt-group.txt for more information. On Tue, Oct 23, 2012 at 12:40 PM, Balbir Singh bsinghar...@gmail.com wrote: On Tue, Oct 23, 2012 at 9:05 AM, Qiang Gao gaoqiangs...@gmail.com wrote: information about the system is in the attach file information.txt I can not reproduce it in the upstream 3.6.0 kernel.. On Sat, Oct 20, 2012 at 12:04 AM, Michal Hocko mho...@suse.cz wrote: On Wed 17-10-12 18:23:34, gaoqiang wrote: I looked up nothing useful with google,so I'm here for help.. when this happens: I use memcg to limit the memory use of a process,and when the memcg cgroup was out of memory, the process was oom-killed however,it cannot really complete the exiting. here is the some information How many tasks are in the group and what kind of memory do they use? Is it possible that you were hit by the same issue as described in 79dfdacc memcg: make oom_lock 0 and 1 based rather than counter. OS version: centos6.22.6.32.220.7.1 Your kernel is quite old and you should be probably asking your distribution to help you out. There were many fixes since 2.6.32. Are you able to reproduce the same issue with the current vanila kernel? /proc/pid/stack --- [810597ca] __cond_resched+0x2a/0x40 [81121569] unmap_vmas+0xb49/0xb70 [8112822e] exit_mmap+0x7e/0x140 [8105b078] mmput+0x58/0x110 [81061aad] exit_mm+0x11d/0x160 [81061c9d] do_exit+0x1ad/0x860 [81062391] do_group_exit+0x41/0xb0 [81077cd8] get_signal_to_deliver+0x1e8/0x430 [8100a4c4] do_notify_resume+0xf4/0x8b0 [8100b281] int_signal+0x12/0x17 [] 0x This looks strange because this is just an exit part which shouldn't deadlock or anything. Is this stack stable? Have you tried to take check it more times? Looking at information.txt, I found something interesting rt_rq[0]:/1314 .rt_nr_running : 1 .rt_throttled : 1 .rt_time : 0.856656 .rt_runtime: 0.00 cfs_rq[0]:/1314 .exec_clock: 8738.133429 .MIN_vruntime : 0.01 .min_vruntime : 8739.371271 .max_vruntime : 0.01 .spread: 0.00 .spread0 : -9792.24 .nr_spread_over: 1 .nr_running: 0 .load : 0 .load_avg : 7376.722880 .load_period : 7.203830 .load_contrib : 1023 .load_tg : 1023 .se-exec_start: 282004.715064 .se-vruntime : 18435.664560 .se-sum_exec_runtime : 8738.133429 .se-wait_start: 0.00 .se-sleep_start : 0.00 .se-block_start : 0.00 .se-sleep_max : 0.00 .se-block_max : 0.00 .se-exec_max : 77.977054 .se-slice_max : 0.00 .se-wait_max : 2.664779 .se-wait_sum : 29.970575 .se-wait_count: 102 .se-load.weight : 2 So 1314 is a real time process and cpu.rt_period_us: 100 -- cpu.rt_runtime_us: 0 When did tt move to being a Real Time process (hint: see nr_running and nr_throttled)? Balbir -- To unsubscribe from this list: send the line unsubscribe cgroups in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ maybe this is not a upstream-kernel bug. the centos/redhat kernel would boost the process to RT prio when the process was selected by oom-killer. I think I should report this to redhat/centos.thanks for your attention -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo
Re: [PATCH 2/2] mmc: sdhci: Defer probe if regulator_get fails
I didn't understand why defer the probe?
I think that some board can't control vqmmc or vmmc.
Best Regards,
Jaehoon Chung
On 10/23/2012 04:18 PM, Pavan Kunapuli wrote:
vmmc and vqmmc regulators control the voltage to
the host and device. Defer the probe if either of
them is not registered.
Signed-off-by: Pavan Kunapuli pkunap...@nvidia.com
---
drivers/mmc/host/sdhci.c | 25 ++---
1 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 7922adb..925c403 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2844,11 +2844,17 @@ int sdhci_add_host(struct sdhci_host *host)
!(host-mmc-caps MMC_CAP_NONREMOVABLE))
mmc-caps |= MMC_CAP_NEEDS_POLL;
- /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
+ /*
+ * If vqmmc regulator and no 1.8V signalling, then there's no UHS.
+ * vqmmc regulator should be present. If it's not present,
+ * assume the regulator driver registration is not yet done and
+ * defer the probe.
+ */
host-vqmmc = regulator_get(mmc_dev(mmc), vqmmc);
if (IS_ERR(host-vqmmc)) {
- pr_info(%s: no vqmmc regulator found\n, mmc_hostname(mmc));
+ pr_err(%s: no vqmmc regulator found\n, mmc_hostname(mmc));
host-vqmmc = NULL;
+ return -EPROBE_DEFER;
}
else if (regulator_is_supported_voltage(host-vqmmc, 180, 180))
regulator_enable(host-vqmmc);
@@ -2903,10 +2909,17 @@ int sdhci_add_host(struct sdhci_host *host)
ocr_avail = 0;
+ /*
+ * vmmc regulator should be present. If it's not present,
+ * assume the regulator driver registration is not yet done
+ * and defer the probe.
+ */
host-vmmc = regulator_get(mmc_dev(mmc), vmmc);
if (IS_ERR(host-vmmc)) {
- pr_info(%s: no vmmc regulator found\n, mmc_hostname(mmc));
+ pr_err(%s: no vmmc regulator found\n, mmc_hostname(mmc));
host-vmmc = NULL;
+ ret = -EPROBE_DEFER;
+ goto vmmc_err;
} else
regulator_enable(host-vmmc);
@@ -3121,7 +3134,13 @@ reset:
untasklet:
tasklet_kill(host-card_tasklet);
tasklet_kill(host-finish_tasklet);
+vmmc_err:
+ if (host-vqmmc) {
+ if (regulator_is_enabled(host-vqmmc))
+ regulator_disable(host-vqmmc);
+ regulator_put(host-vqmmc);
+ }
return ret;
}
--
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: process hangs on do_exit when oom happens
On Tue 23-10-12 18:10:33, Qiang Gao wrote: On Tue, Oct 23, 2012 at 5:50 PM, Michal Hocko mho...@suse.cz wrote: On Tue 23-10-12 15:18:48, Qiang Gao wrote: This process was moved to RT-priority queue when global oom-killer happened to boost the recovery of the system.. Who did that? oom killer doesn't boost the priority (scheduling class) AFAIK. but it wasn't get properily dealt with. I still have no idea why where the problem is .. Well your configuration says that there is no runtime reserved for the group. Please refer to Documentation/scheduler/sched-rt-group.txt for more information. [...] maybe this is not a upstream-kernel bug. the centos/redhat kernel would boost the process to RT prio when the process was selected by oom-killer. This still looks like your cpu controller is misconfigured. Even if the task is promoted to be realtime. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] mmc: sdhci: Defer probe if regulator_get fails
For platforms where the board can control vmmc or vqmmc, if the regulator
supplies registration is not done before sdhci probe, deferring sdhci probe
would ensure that the regulators are available the next time around. For
platforms where the board can't control vmmc or vqmmc, we can have a dummy
regulator to make sure probe will never get deferred.
-Original Message-
From: Jaehoon Chung [mailto:jh80.ch...@samsung.com]
Sent: 23 October 2012 15:41
To: Pavan Kunapuli
Cc: swar...@wwwdotorg.org; li...@arm.linux.org.uk; c...@laptop.org;
linux-ker...@vger.kernel.org; linux-mmc@vger.kernel.org
Subject: Re: [PATCH 2/2] mmc: sdhci: Defer probe if regulator_get fails
I didn't understand why defer the probe?
I think that some board can't control vqmmc or vmmc.
Best Regards,
Jaehoon Chung
On 10/23/2012 04:18 PM, Pavan Kunapuli wrote:
vmmc and vqmmc regulators control the voltage to the host and device.
Defer the probe if either of them is not registered.
Signed-off-by: Pavan Kunapuli pkunap...@nvidia.com
---
drivers/mmc/host/sdhci.c | 25 ++---
1 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index
7922adb..925c403 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2844,11 +2844,17 @@ int sdhci_add_host(struct sdhci_host *host)
!(host-mmc-caps MMC_CAP_NONREMOVABLE))
mmc-caps |= MMC_CAP_NEEDS_POLL;
- /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
+ /*
+ * If vqmmc regulator and no 1.8V signalling, then there's no UHS.
+ * vqmmc regulator should be present. If it's not present,
+ * assume the regulator driver registration is not yet done and
+ * defer the probe.
+ */
host-vqmmc = regulator_get(mmc_dev(mmc), vqmmc);
if (IS_ERR(host-vqmmc)) {
- pr_info(%s: no vqmmc regulator found\n, mmc_hostname(mmc));
+ pr_err(%s: no vqmmc regulator found\n, mmc_hostname(mmc));
host-vqmmc = NULL;
+ return -EPROBE_DEFER;
}
else if (regulator_is_supported_voltage(host-vqmmc, 180, 180))
regulator_enable(host-vqmmc);
@@ -2903,10 +2909,17 @@ int sdhci_add_host(struct sdhci_host *host)
ocr_avail = 0;
+ /*
+ * vmmc regulator should be present. If it's not present,
+ * assume the regulator driver registration is not yet done
+ * and defer the probe.
+ */
host-vmmc = regulator_get(mmc_dev(mmc), vmmc);
if (IS_ERR(host-vmmc)) {
- pr_info(%s: no vmmc regulator found\n, mmc_hostname(mmc));
+ pr_err(%s: no vmmc regulator found\n, mmc_hostname(mmc));
host-vmmc = NULL;
+ ret = -EPROBE_DEFER;
+ goto vmmc_err;
} else
regulator_enable(host-vmmc);
@@ -3121,7 +3134,13 @@ reset:
untasklet:
tasklet_kill(host-card_tasklet);
tasklet_kill(host-finish_tasklet);
+vmmc_err:
+ if (host-vqmmc) {
+ if (regulator_is_enabled(host-vqmmc))
+ regulator_disable(host-vqmmc);
+ regulator_put(host-vqmmc);
+ }
return ret;
}
--
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] mm: make zone_pcp_reset independ on MEMORY_HOTREMOVE
On Tue 23-10-12 18:14:28, Wen Congyang wrote:
At 10/23/2012 05:37 PM, Michal Hocko Wrote:
340175b7 (mm/hotplug: free zone-pageset when a zone becomes empty)
introduced zone_pcp_reset and hided it inside CONFIG_MEMORY_HOTREMOVE.
The function is since 506e5fb7 (memory-hotplug: allocate zone's pcp
before onlining pages) called also called from online_pages which
This patch is still in -mm tree, and I have received a report from
Liu Yuanhan.
Yes you are right. I will resend it and ask Andrew to fold it into the
offending patch. Thanks for catching that!
is called outside CONFIG_MEMORY_HOTREMOVE which causes a linkage error.
The function, although not used outside of MEMORY_{HOTPLUT,HOTREMOVE},
seems like universal enough so let's keep it at its current location
and only remove the HOTREMOVE guard.
Signed-off-by: Michal Hocko mho...@suse.cz
Cc: David Rientjes rient...@google.com
Cc: Jiang Liu liu...@gmail.com
Cc: Len Brown len.br...@intel.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
Cc: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Cc: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Cc: Dave Hansen d...@linux.vnet.ibm.com
Cc: Mel Gorman m...@csn.ul.ie
---
mm/page_alloc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e29912e..30e359c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5981,7 +5981,6 @@ void __meminit zone_pcp_update(struct zone *zone)
}
#endif
-#ifdef CONFIG_MEMORY_HOTREMOVE
void zone_pcp_reset(struct zone *zone)
{
unsigned long flags;
@@ -6001,6 +6000,7 @@ void zone_pcp_reset(struct zone *zone)
local_irq_restore(flags);
}
+#ifdef CONFIG_MEMORY_HOTREMOVE
/*
* All pages in the range must be isolated before calling this.
*/
This patch looks find to me.
Reviewed-by: Wen Congyang we...@cn.fujitsu.com
--
Michal Hocko
SUSE Labs
--
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] mm: make zone_pcp_reset independ on MEMORY_HOTREMOVE
2012/10/23 18:37, Michal Hocko wrote:
340175b7 (mm/hotplug: free zone-pageset when a zone becomes empty)
introduced zone_pcp_reset and hided it inside CONFIG_MEMORY_HOTREMOVE.
The function is since 506e5fb7 (memory-hotplug: allocate zone's pcp
before onlining pages) called also called from online_pages which
is called outside CONFIG_MEMORY_HOTREMOVE which causes a linkage error.
The function, although not used outside of MEMORY_{HOTPLUT,HOTREMOVE},
seems like universal enough so let's keep it at its current location
and only remove the HOTREMOVE guard.
Signed-off-by: Michal Hocko mho...@suse.cz
Cc: David Rientjes rient...@google.com
Cc: Jiang Liu liu...@gmail.com
Cc: Len Brown len.br...@intel.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
Cc: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Cc: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Looks goot to me.
Reviewd-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Thanks,
Yasuki Ishimatsu
Cc: Dave Hansen d...@linux.vnet.ibm.com
Cc: Mel Gorman m...@csn.ul.ie
---
mm/page_alloc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e29912e..30e359c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5981,7 +5981,6 @@ void __meminit zone_pcp_update(struct zone *zone)
}
#endif
-#ifdef CONFIG_MEMORY_HOTREMOVE
void zone_pcp_reset(struct zone *zone)
{
unsigned long flags;
@@ -6001,6 +6000,7 @@ void zone_pcp_reset(struct zone *zone)
local_irq_restore(flags);
}
+#ifdef CONFIG_MEMORY_HOTREMOVE
/*
* All pages in the range must be isolated before calling this.
*/
--
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: sh_mmcif: fix use after free
A recent commit mmc: sh_mmcif: fix clock management has introduced a use after free bug in sh_mmcif.c: in sh_mmcif_remove() the call to mmc_free_host() frees private driver data, therefore using it afterwards is a bug. Revert that hunk. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Chris, the offending patch appeared in 3.6, so, this has to go to 3.6.stable, as well as to 3.7-rc. drivers/mmc/host/sh_mmcif.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c index 11d2bc3..d25bc97 100644 --- a/drivers/mmc/host/sh_mmcif.c +++ b/drivers/mmc/host/sh_mmcif.c @@ -1466,9 +1466,9 @@ static int __devexit sh_mmcif_remove(struct platform_device *pdev) platform_set_drvdata(pdev, NULL); + clk_disable(host-hclk); mmc_free_host(host-mmc); pm_runtime_put_sync(pdev-dev); - clk_disable(host-hclk); pm_runtime_disable(pdev-dev); return 0; -- 1.7.2.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 2/2] mmc: sdhci: Defer probe if regulator_get fails
On 23 Oct 2012, at 09:19, Pavan Kunapuli pkunap...@nvidia.com wrote:
vmmc and vqmmc regulators control the voltage to
the host and device. Defer the probe if either of
them is not registered.
Signed-off-by: Pavan Kunapuli pkunap...@nvidia.com
---
drivers/mmc/host/sdhci.c | 25 ++---
1 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 7922adb..925c403 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2844,11 +2844,17 @@ int sdhci_add_host(struct sdhci_host *host)
!(host-mmc-caps MMC_CAP_NONREMOVABLE))
mmc-caps |= MMC_CAP_NEEDS_POLL;
- /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
+ /*
+ * If vqmmc regulator and no 1.8V signalling, then there's no UHS.
+ * vqmmc regulator should be present. If it's not present,
+ * assume the regulator driver registration is not yet done and
+ * defer the probe.
+ */
host-vqmmc = regulator_get(mmc_dev(mmc), vqmmc);
if (IS_ERR(host-vqmmc)) {
- pr_info(%s: no vqmmc regulator found\n, mmc_hostname(mmc));
+ pr_err(%s: no vqmmc regulator found\n, mmc_hostname(mmc));
host-vqmmc = NULL;
+ return -EPROBE_DEFER;
Some systems exist where vmmc regulator exists and vqmmc regulator does not.
The vmmc regular is fixed at 3.3v.
Deferring the probe will cause issues.
}
else if (regulator_is_supported_voltage(host-vqmmc, 180, 180))
regulator_enable(host-vqmmc);
@@ -2903,10 +2909,17 @@ int sdhci_add_host(struct sdhci_host *host)
ocr_avail = 0;
+ /*
+ * vmmc regulator should be present. If it's not present,
+ * assume the regulator driver registration is not yet done
+ * and defer the probe.
+ */
host-vmmc = regulator_get(mmc_dev(mmc), vmmc);
if (IS_ERR(host-vmmc)) {
- pr_info(%s: no vmmc regulator found\n, mmc_hostname(mmc));
+ pr_err(%s: no vmmc regulator found\n, mmc_hostname(mmc));
host-vmmc = NULL;
+ ret = -EPROBE_DEFER;
+ goto vmmc_err;
} else
regulator_enable(host-vmmc);
@@ -3121,7 +3134,13 @@ reset:
untasklet:
tasklet_kill(host-card_tasklet);
tasklet_kill(host-finish_tasklet);
+vmmc_err:
+ if (host-vqmmc) {
+ if (regulator_is_enabled(host-vqmmc))
+ regulator_disable(host-vqmmc);
+ regulator_put(host-vqmmc);
+ }
return ret;
}
--
1.7.1.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
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mmc: sdhci: Defer probe if regulator_get fails
On Tue, Oct 23, 2012 at 03:21:58PM +0200, Philip Rakity wrote:
On 23 Oct 2012, at 09:19, Pavan Kunapuli pkunap...@nvidia.com wrote:
- /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
+ /*
+* If vqmmc regulator and no 1.8V signalling, then there's no UHS.
+* vqmmc regulator should be present. If it's not present,
+* assume the regulator driver registration is not yet done and
+* defer the probe.
+*/
host-vqmmc = regulator_get(mmc_dev(mmc), vqmmc);
if (IS_ERR(host-vqmmc)) {
- pr_info(%s: no vqmmc regulator found\n, mmc_hostname(mmc));
+ pr_err(%s: no vqmmc regulator found\n, mmc_hostname(mmc));
host-vqmmc = NULL;
+ return -EPROBE_DEFER;
Some systems exist where vmmc regulator exists and vqmmc regulator does not.
The vmmc regular is fixed at 3.3v.
Deferring the probe will cause issues.
That's one of the issues of deferred probing: you don't know if one of the
_get() functions failed because it just isn't present, or whether it's
failed because it hasn't been registered yet.
The two conditions are indistinguishable from the driver point of view.
The solution to it is to ensure that those drivers where hardware resource
X is optional provide a dummy resource to the driver when the hardware
resource is not available. That means, as far as the driver is concerned,
that it will always expect to get a full set of resources whether or not
the hardware has them.
If drivers care about such stuff, then we should have xxx_is_dummy()
functions (eg, clk_is_dummy(clk)) which return TRUE when the hardware
resource is not available. (which we could use NULL to indicate and
would be in keeping with the specified IS_ERR() usage of these APIs.)
--
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] ARM: dt: tegra: Add sdhci regulators
On 10/23/2012 01:18 AM, Pavan Kunapuli wrote: Adding vmmc and vmmcq supplies for sdhci nodes in tegra dt files. As I already mentioned downstream, this patch is invalid because it will cause runtime failures if applied before the second patch in this series. Please see the more detailed explanation I sent downstream. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mmc: sdhci: Defer probe if regulator_get fails
On 10/23/2012 01:18 AM, Pavan Kunapuli wrote:
vmmc and vqmmc regulators control the voltage to
the host and device. Defer the probe if either of
them is not registered.
Signed-off-by: Pavan Kunapuli pkunap...@nvidia.com
---
drivers/mmc/host/sdhci.c | 25 ++---
1 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 7922adb..925c403 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2844,11 +2844,17 @@ int sdhci_add_host(struct sdhci_host *host)
!(host-mmc-caps MMC_CAP_NONREMOVABLE))
mmc-caps |= MMC_CAP_NEEDS_POLL;
- /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
+ /*
+ * If vqmmc regulator and no 1.8V signalling, then there's no UHS.
+ * vqmmc regulator should be present. If it's not present,
+ * assume the regulator driver registration is not yet done and
+ * defer the probe.
+ */
host-vqmmc = regulator_get(mmc_dev(mmc), vqmmc);
if (IS_ERR(host-vqmmc)) {
- pr_info(%s: no vqmmc regulator found\n, mmc_hostname(mmc));
+ pr_err(%s: no vqmmc regulator found\n, mmc_hostname(mmc));
host-vqmmc = NULL;
+ return -EPROBE_DEFER;
}
Right now, the regulator is optional, and any failure to acquire the
regulator is just ignored.
Instead, I think the behaviour we want is:
Attempt to get regulator.
1) If no error - OK
2) If deferred probe error - return -EPROBE_DEFER
3) If any other error - ignore it
Assuming that regulator_get() can explicitly detect and return the
difference between cases (1) and (2) above. If it can't, it seems like
it should be able to.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mmc: sdhci: Defer probe if regulator_get fails
On 10/23/2012 01:57 AM, Lucas Stach wrote: Am Dienstag, den 23.10.2012, 12:49 +0530 schrieb Pavan Kunapuli: vmmc and vqmmc regulators control the voltage to the host and device. Defer the probe if either of them is not registered. Does this work with boards where we don't have any MMC supplies? Or are we just deferring the probe indefinitely there? For boards that power MMC unconditionally, are we supposed to add dummy regulators to make them work with this patchset? I believe that dummy (fixed) regulators are supposed to be provided in all cases where the platform doesn't actually have one. The fact that everything worked OK without them before this patch was most likely a mistake/accident. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mmc: sdhci: Defer probe if regulator_get fails
On Tue, Oct 23, 2012 at 10:29:41AM -0600, Stephen Warren wrote: On 10/23/2012 01:57 AM, Lucas Stach wrote: Does this work with boards where we don't have any MMC supplies? Or are we just deferring the probe indefinitely there? For boards that power MMC unconditionally, are we supposed to add dummy regulators to make them work with this patchset? I believe that dummy (fixed) regulators are supposed to be provided in all cases where the platform doesn't actually have one. The fact that everything worked OK without them before this patch was most likely a mistake/accident. That's the general idea; clearly there *are* supplies here, they're just not software controlled supplies. signature.asc Description: Digital signature
Re: process hangs on do_exit when oom happens
On Tue, Oct 23, 2012 at 3:45 PM, Michal Hocko mho...@suse.cz wrote: On Tue 23-10-12 18:10:33, Qiang Gao wrote: On Tue, Oct 23, 2012 at 5:50 PM, Michal Hocko mho...@suse.cz wrote: On Tue 23-10-12 15:18:48, Qiang Gao wrote: This process was moved to RT-priority queue when global oom-killer happened to boost the recovery of the system.. Who did that? oom killer doesn't boost the priority (scheduling class) AFAIK. but it wasn't get properily dealt with. I still have no idea why where the problem is .. Well your configuration says that there is no runtime reserved for the group. Please refer to Documentation/scheduler/sched-rt-group.txt for more information. [...] maybe this is not a upstream-kernel bug. the centos/redhat kernel would boost the process to RT prio when the process was selected by oom-killer. This still looks like your cpu controller is misconfigured. Even if the task is promoted to be realtime. Precisely! You need to have rt bandwidth enabled for RT tasks to run, as a workaround please give the groups some RT bandwidth and then work out the migration to RT and what should be the defaults on the distro. Balbir -- 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] ARM: dt: tegra: Add sdhci regulators
Pavan,
On Tuesday 23 October 2012 12:48:59 Pavan Kunapuli wrote:
Adding vmmc and vmmcq supplies for sdhci nodes
in tegra dt files.
...
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
b/arch/arm/boot/dts/tegra20-paz00.dts index 6a93d14..e161b65 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -422,13 +422,17 @@
status = okay;
cd-gpios = gpio 173 0; /* gpio PV5 */
wp-gpios = gpio 57 0; /* gpio PH1 */
- power-gpios = gpio 169 0; /* gpio PV1 */
bus-width = 4;
+ vmmc-supply = vddio_sd_reg;
+ vqmmc-supply = vddio_sd_reg;
};
sdhci@c8000600 {
status = okay;
bus-width = 8;
+ vmmc-supply = vddio_sdmmc_reg;
+ vqmmc-supply = vddio_sdmmc_reg;
to make it better, this should be:
vmmc-supply = vcore_mmc_reg; and
vqmmc-supply = vddio_nand_reg;
with vcore_mmc_reg is ldo5 and vddio_nand_reg is the fixed regulator below.
By doing so, I get sdhci-tegra sdhci-tegra.3: could not set regulator OCR
(-1). MMC subsys wants to set ldo5 to 3.3V but it is fixed. I guess that's
harmless for now.
};
gpio-keys {
@@ -465,6 +469,24 @@
regulator-max-microvolt = 500;
regulator-always-on;
};
+
+ vddio_sd_reg: regulator@1 {
+ compatible = regulator-fixed;
+ reg = 1;
+ regulator-name = vddio_sd;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ enable-active-high;
+ gpio = gpio 169 0; /* gpio PV1 */
+ };
+
+ vddio_sdmmc_reg: regulator@2 {
^^ vddio_nand_reg acording to schematics
+ compatible = regulator-fixed;
+ reg = 2;
+ regulator-name = vddio_sdmmc;
also here
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
};
sound {
--
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] ARM: dt: tegra: Add sdhci regulators
On 10/23/2012 12:07 PM, Marc Dietrich wrote:
Pavan,
On Tuesday 23 October 2012 12:48:59 Pavan Kunapuli wrote:
Adding vmmc and vmmcq supplies for sdhci nodes
in tegra dt files.
...
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
b/arch/arm/boot/dts/tegra20-paz00.dts index 6a93d14..e161b65 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -422,13 +422,17 @@
status = okay;
cd-gpios = gpio 173 0; /* gpio PV5 */
wp-gpios = gpio 57 0; /* gpio PH1 */
-power-gpios = gpio 169 0; /* gpio PV1 */
bus-width = 4;
+vmmc-supply = vddio_sd_reg;
+vqmmc-supply = vddio_sd_reg;
};
sdhci@c8000600 {
status = okay;
bus-width = 8;
+vmmc-supply = vddio_sdmmc_reg;
+vqmmc-supply = vddio_sdmmc_reg;
to make it better, this should be:
vmmc-supply = vcore_mmc_reg; and
vqmmc-supply = vddio_nand_reg;
with vcore_mmc_reg is ldo5 and vddio_nand_reg is the fixed regulator below.
I think for the eMMC (not SD card), the core supply is actually +3vs_s3,
and hence fixed; it looks like LDO5 used to be used, but they changed
it. See the note for the VCC connections on the eMMC chip.
By doing so, I get sdhci-tegra sdhci-tegra.3: could not set regulator OCR
(-1). MMC subsys wants to set ldo5 to 3.3V but it is fixed. I guess that's
harmless for now.
What I mention above might end up fixing that?
--
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] ARM: dt: tegra: Add sdhci regulators
On Tuesday 23 October 2012 12:42:11 Stephen Warren wrote:
On 10/23/2012 12:07 PM, Marc Dietrich wrote:
Pavan,
On Tuesday 23 October 2012 12:48:59 Pavan Kunapuli wrote:
Adding vmmc and vmmcq supplies for sdhci nodes
in tegra dt files.
...
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
b/arch/arm/boot/dts/tegra20-paz00.dts index 6a93d14..e161b65 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -422,13 +422,17 @@
status = okay;
cd-gpios = gpio 173 0; /* gpio PV5 */
wp-gpios = gpio 57 0; /* gpio PH1 */
- power-gpios = gpio 169 0; /* gpio PV1 */
bus-width = 4;
+ vmmc-supply = vddio_sd_reg;
+ vqmmc-supply = vddio_sd_reg;
};
sdhci@c8000600 {
status = okay;
bus-width = 8;
+ vmmc-supply = vddio_sdmmc_reg;
+ vqmmc-supply = vddio_sdmmc_reg;
to make it better, this should be:
vmmc-supply = vcore_mmc_reg; and
vqmmc-supply = vddio_nand_reg;
with vcore_mmc_reg is ldo5 and vddio_nand_reg is the fixed regulator
below.
I think for the eMMC (not SD card), the core supply is actually +3vs_s3,
and hence fixed; it looks like LDO5 used to be used, but they changed
it. See the note for the VCC connections on the eMMC chip.
yes, you are right. The schematic had a comment that this was changed.
By doing so, I get sdhci-tegra sdhci-tegra.3: could not set regulator OCR
(-1). MMC subsys wants to set ldo5 to 3.3V but it is fixed. I guess
that's
harmless for now.
What I mention above might end up fixing that?
yes, it does.
So the original patch is just fine. Sorry for the noise.
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 2/2] mmc: core: Power cycle card on voltage switch fail
Hi Johan,
On Thu, Sep 20 2012, Johan Rudholm wrote:
Signed-off-by: Johan Rudholm johan.rudh...@stericsson.com
---
drivers/mmc/core/core.c |2 +-
drivers/mmc/core/core.h |1 +
drivers/mmc/core/sd.c |8 ++--
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 3779431..671986a 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1346,7 +1346,7 @@ static void mmc_poweroff_notify(struct mmc_host *host)
* If a host does all the power sequencing itself, ignore the
* initial MMC_POWER_UP stage.
*/
-static void mmc_power_up(struct mmc_host *host)
+void mmc_power_up(struct mmc_host *host)
{
int bit;
diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index 3bdafbc..5a5170d 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -45,6 +45,7 @@ int mmc_set_signal_voltage(struct mmc_host *host, int
signal_voltage,
void mmc_set_timing(struct mmc_host *host, unsigned int timing);
void mmc_set_driver_type(struct mmc_host *host, unsigned int drv_type);
void mmc_power_off(struct mmc_host *host);
+void mmc_power_up(struct mmc_host *host);
static inline void mmc_delay(unsigned int ms)
{
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 74972c2..9a165451 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -720,6 +720,7 @@ int mmc_sd_get_cid(struct mmc_host *host, u32 ocr, u32
*cid, u32 *rocr)
* state. We wait 1ms to give cards time to
* respond.
*/
+try_again:
mmc_go_idle(host);
/*
@@ -748,7 +749,6 @@ int mmc_sd_get_cid(struct mmc_host *host, u32 ocr, u32
*cid, u32 *rocr)
if (max_current 150)
ocr |= SD_OCR_XPC;
-try_again:
err = mmc_send_app_op_cond(host, ocr, rocr);
if (err)
return err;
@@ -761,7 +761,11 @@ try_again:
((*rocr 0x4100) == 0x4100)) {
err = mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_180,
true);
if (err) {
- ocr = ~SD_OCR_S18R;
+ /* Power cycle card */
+ pr_warning(%s: Signal voltage switch failed,
+ power cycling card\n, mmc_hostname(host));
+ mmc_power_off(host);
+ mmc_power_up(host);
goto try_again;
}
}
Hasn't the card already been power-cycled inside mmc_set_signal_voltage's
call to sdhci_do_start_signal_voltage_switch()?
/*
* If we are here, that means the switch to 1.8V signaling
* failed. We power cycle the card, and retry initialization
* sequence by setting S18R to 0.
*/
pwr = sdhci_readb(host, SDHCI_POWER_CONTROL);
pwr = ~SDHCI_POWER_ON;
sdhci_writeb(host, pwr, SDHCI_POWER_CONTROL);
(If you're going to do it here instead, should we remove this code from
sdhci.c?)
Dan, maybe you could see if this patch (there's a 1/2 patch too) solves
your UHS problem?
Thanks,
- Chris.
--
Chris Ball c...@laptop.org 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
Re: [PATCH] mmc: dw_mmc: convert the variable type of irq
Hi, On Fri, Sep 28 2012, Will Newton wrote: On Fri, Sep 28, 2012 at 6:21 AM, Seungwon Jeon tgih@samsung.com wrote: Even though platform_get_irq returns error, 'host-irq' always has an unsigned value. Less-than-zero comparison of an unsigned value is never true. Type of 'unsigned int' will be changed for 'int'. Signed-off-by: Seungwon Jeon tgih@samsung.com --- include/linux/mmc/dw_mmc.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Acked-by: Will Newton will.new...@imgtec.com Thanks, pushed to mmc-next for 3.8. - Chris. -- Chris Ball c...@laptop.org 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
Re: [PATCH] mmc: sdhci-s3c: use clk_prepare_enable and clk_disable_unprepare
Hi, On Tue, Oct 02 2012, Thomas Abraham wrote: Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare calls as required by common clock framework. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org Thanks, pushed to mmc-next for 3.8. - Chris. -- Chris Ball c...@laptop.org 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
Re: [PATCHv2] mmc: dw_mmc: use __devexit_p macro for .remove()
Hi, On Thu, Oct 04 2012, Will Newton wrote: On Wed, Oct 3, 2012 at 2:45 PM, Andy Shevchenko andriy.shevche...@linux.intel.com wrote: Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com --- drivers/mmc/host/dw_mmc-pci.c |2 +- drivers/mmc/host/dw_mmc-pltfm.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Acked-by: Will Newton will.new...@imgtec.com Thanks, pushed to mmc-next for 3.8 - Chris. -- Chris Ball c...@laptop.org 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
Re: [PATCH 2/2] mmc: dw_mmc: use helper macro module_platform_driver()
Hi, On Thu, Oct 04 2012, Will Newton wrote: On Wed, Oct 3, 2012 at 2:26 PM, Andy Shevchenko andriy.shevche...@linux.intel.com 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 andriy.shevche...@linux.intel.com --- drivers/mmc/host/dw_mmc-pltfm.c | 14 ++ 1 file changed, 2 insertions(+), 12 deletions(-) Acked-by: Will Newton will.new...@imgtec.com Thanks, pushed to mmc-next for 3.8. - Chris. -- Chris Ball c...@laptop.org 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
Re: [PATCH] mmc: dw_mmc: enable controller interrupt before calling mmc_start_host
Hi, On Mon, Oct 08 2012, 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 yuvaraj...@samsung.com Is Yuvaraj CD your legal name? We should use your full name so that we can track copyright attribution properly. Thanks! - Chris. -- Chris Ball c...@laptop.org 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
Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()
On Fri, Oct 19, 2012 at 3:51 AM, Matt Porter mpor...@ti.com wrote:
Add a dmaengine API to retrieve per channel capabilities.
Currently, only channel ops and SG segment limitations are
implemented caps.
The API is optionally implemented by drivers and when
unimplemented will return a NULL pointer. It is intended
to be executed after a channel has been requested and, if
the channel is intended to be used with slave SG transfers,
then it may only be called after dmaengine_slave_config()
has executed. The slave driver provides parameters such as
burst size and address width which may be necessary for
the dmaengine driver to use in order to properly return SG
segment limit caps.
Suggested-by: Vinod Koul vinod.k...@intel.com
Signed-off-by: Matt Porter mpor...@ti.com
Looks okay to me. Minor comment below...
+/**
+ * dma_get_channel_caps - flush pending transactions to HW
+ * @chan: target DMA channel
+ * @dir: direction of transfer
+ *
+ * Get the channel-specific capabilities. If the dmaengine
+ * driver does not implement per channel capbilities then
+ * NULL is returned.
+ */
+static inline struct dmaengine_chan_caps
+*dma_get_channel_caps(struct dma_chan *chan, enum dma_transfer_direction dir)
Looks to me like the returned pointer be a const. Ditto for the
callback prototype in the dma_device structure.
+{
+ if (chan-device-device_channel_caps)
+ return chan-device-device_channel_caps(chan, dir);
+ return NULL;
+}
+
enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie);
#ifdef CONFIG_DMA_ENGINE
enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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 3/3] mmc: davinci: get SG segment limits with dma_get_channel_caps()
On Fri, Oct 19, 2012 at 3:51 AM, Matt Porter mpor...@ti.com wrote:
Replace the hardcoded values used to set max_segs/max_seg_size with
a dma_get_channel_caps() query to the dmaengine driver.
Signed-off-by: Matt Porter mpor...@ti.com
Series looks reasonable to me.
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/mmc/host/davinci_mmc.c| 66
+
include/linux/platform_data/mmc-davinci.h |3 --
2 files changed, 21 insertions(+), 48 deletions(-)
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index f5d46ea..d1efacc 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -145,18 +145,6 @@
/* MMCSD Init clock in Hz in opendrain mode */
#define MMCSD_INIT_CLOCK 20
-/*
- * One scatterlist dma segment is at most MAX_CCNT rw_threshold units,
- * and we handle up to MAX_NR_SG segments. MMC_BLOCK_BOUNCE kicks in only
- * for drivers with max_segs == 1, making the segments bigger (64KB)
- * than the page or two that's otherwise typical. nr_sg (passed from
- * platform data) == 16 gives at least the same throughput boost, using
- * EDMA transfer linkage instead of spending CPU time copying pages.
- */
-#define MAX_CCNT ((1 16) - 1)
-
-#define MAX_NR_SG 16
-
static unsigned rw_threshold = 32;
module_param(rw_threshold, uint, S_IRUGO);
MODULE_PARM_DESC(rw_threshold,
@@ -217,8 +205,6 @@ struct mmc_davinci_host {
u8 version;
/* for ns in one cycle calculation */
unsigned ns_in_one_cycle;
- /* Number of sg segments */
- u8 nr_sg;
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
#endif
@@ -422,16 +408,7 @@ static int mmc_davinci_send_dma_request(struct
mmc_davinci_host *host,
int ret = 0;
if (host-data_dir == DAVINCI_MMC_DATADIR_WRITE) {
- struct dma_slave_config dma_tx_conf = {
- .direction = DMA_MEM_TO_DEV,
- .dst_addr = host-mem_res-start + DAVINCI_MMCDXR,
- .dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
- .dst_maxburst =
- rw_threshold / DMA_SLAVE_BUSWIDTH_4_BYTES,
- };
chan = host-dma_tx;
- dmaengine_slave_config(host-dma_tx, dma_tx_conf);
-
desc = dmaengine_prep_slave_sg(host-dma_tx,
data-sg,
host-sg_len,
@@ -444,16 +421,7 @@ static int mmc_davinci_send_dma_request(struct
mmc_davinci_host *host,
goto out;
}
} else {
- struct dma_slave_config dma_rx_conf = {
- .direction = DMA_DEV_TO_MEM,
- .src_addr = host-mem_res-start + DAVINCI_MMCDRR,
- .src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
- .src_maxburst =
- rw_threshold / DMA_SLAVE_BUSWIDTH_4_BYTES,
- };
chan = host-dma_rx;
- dmaengine_slave_config(host-dma_rx, dma_rx_conf);
-
desc = dmaengine_prep_slave_sg(host-dma_rx,
data-sg,
host-sg_len,
@@ -1166,6 +1134,7 @@ static int __init davinci_mmcsd_probe(struct
platform_device *pdev)
struct resource *r, *mem = NULL;
int ret = 0, irq = 0;
size_t mem_size;
+ struct dmaengine_chan_caps *dma_chan_caps;
/* REVISIT: when we're fully converted, fail if pdata is NULL */
@@ -1215,12 +1184,6 @@ static int __init davinci_mmcsd_probe(struct
platform_device *pdev)
init_mmcsd_host(host);
- if (pdata-nr_sg)
- host-nr_sg = pdata-nr_sg - 1;
-
- if (host-nr_sg MAX_NR_SG || !host-nr_sg)
- host-nr_sg = MAX_NR_SG;
-
host-use_dma = use_dma;
host-mmc_irq = irq;
host-sdio_irq = platform_get_irq(pdev, 1);
@@ -1249,14 +1212,27 @@ static int __init davinci_mmcsd_probe(struct
platform_device *pdev)
mmc-caps |= pdata-caps;
mmc-ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
- /* With no iommu coalescing pages, each phys_seg is a hw_seg.
-* Each hw_seg uses one EDMA parameter RAM slot, always one
-* channel and then usually some linked slots.
-*/
- mmc-max_segs = MAX_NR_SG;
+ {
+ struct dma_slave_config dma_txrx_conf = {
+ .src_addr = host-mem_res-start + DAVINCI_MMCDRR,
+ .src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
+ .src_maxburst =
+ rw_threshold / DMA_SLAVE_BUSWIDTH_4_BYTES,
+ .dst_addr = host-mem_res-start + DAVINCI_MMCDXR,
+
Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()
On Fri, Oct 19, 2012 at 3:51 AM, Matt Porter mpor...@ti.com wrote:
Add a dmaengine API to retrieve per channel capabilities.
Currently, only channel ops and SG segment limitations are
implemented caps.
The API is optionally implemented by drivers and when
unimplemented will return a NULL pointer. It is intended
to be executed after a channel has been requested and, if
the channel is intended to be used with slave SG transfers,
then it may only be called after dmaengine_slave_config()
has executed. The slave driver provides parameters such as
burst size and address width which may be necessary for
the dmaengine driver to use in order to properly return SG
segment limit caps.
Suggested-by: Vinod Koul vinod.k...@intel.com
Signed-off-by: Matt Porter mpor...@ti.com
---
include/linux/dmaengine.h | 52
+
1 file changed, 52 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 11d9e25..0181887 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -371,6 +371,38 @@ struct dma_slave_config {
unsigned int slave_id;
};
+enum dmaengine_apis {
+ DMAENGINE_MEMCPY= 0x0001,
+ DMAENGINE_XOR = 0x0002,
+ DMAENGINE_XOR_VAL = 0x0004,
+ DMAENGINE_PQ= 0x0008,
+ DMAENGINE_PQ_VAL= 0x0010,
+ DMAENGINE_MEMSET= 0x0020,
+ DMAENGINE_SLAVE = 0x0040,
+ DMAENGINE_CYCLIC= 0x0080,
+ DMAENGINE_INTERLEAVED = 0x0100,
+ DMAENGINE_SG= 0x0200,
+};
Actually, one more comment. Why the new enum? Why can't the
dma_transaction_type enum be used directly along with dma_cap_mask_t?
+
+/* struct dmaengine_chan_caps - expose capability of a channel
+ * Note: each channel can have same or different capabilities
+ *
+ * This primarily classifies capabilities into
+ * a) APIs/ops supported
+ * b) channel physical capabilities
+ *
+ * @ops: or'ed api capability
+ * @seg_nr: maximum number of SG segments supported on a SG/SLAVE
+ * channel (0 for no maximum or not a SG/SLAVE channel)
+ * @seg_len: maximum length of SG segments supported on a SG/SLAVE
+ * channel (0 for no maximum or not a SG/SLAVE channel)
+ */
+struct dmaengine_chan_caps {
+ enum dmaengine_apis ops;
+ int seg_nr;
+ int seg_len;
+};
+
static inline const char *dma_chan_name(struct dma_chan *chan)
{
return dev_name(chan-dev-device);
@@ -534,6 +566,7 @@ struct dma_tx_state {
* struct with auxiliary transfer status information, otherwise the call
* will just return a simple status code
* @device_issue_pending: push pending transactions to hardware
+ * @device_channel_caps: return the channel capabilities
*/
struct dma_device {
@@ -602,6 +635,8 @@ struct dma_device {
dma_cookie_t cookie,
struct dma_tx_state *txstate);
void (*device_issue_pending)(struct dma_chan *chan);
+ struct dmaengine_chan_caps *(*device_channel_caps)(
+ struct dma_chan *chan, enum dma_transfer_direction direction);
};
static inline int dmaengine_device_control(struct dma_chan *chan,
@@ -969,6 +1004,23 @@ dma_set_tx_state(struct dma_tx_state *st, dma_cookie_t
last, dma_cookie_t used,
}
}
+/**
+ * dma_get_channel_caps - flush pending transactions to HW
+ * @chan: target DMA channel
+ * @dir: direction of transfer
+ *
+ * Get the channel-specific capabilities. If the dmaengine
+ * driver does not implement per channel capbilities then
+ * NULL is returned.
+ */
+static inline struct dmaengine_chan_caps
+*dma_get_channel_caps(struct dma_chan *chan, enum dma_transfer_direction dir)
+{
+ if (chan-device-device_channel_caps)
+ return chan-device-device_channel_caps(chan, dir);
+ return NULL;
+}
+
enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie);
#ifdef CONFIG_DMA_ENGINE
enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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 1/3] dmaengine: add dma_get_channel_caps()
On Thu, Oct 18, 2012 at 7:51 PM, Matt Porter mpor...@ti.com wrote:
Add a dmaengine API to retrieve per channel capabilities.
Currently, only channel ops and SG segment limitations are
implemented caps.
The API is optionally implemented by drivers and when
unimplemented will return a NULL pointer. It is intended
to be executed after a channel has been requested and, if
the channel is intended to be used with slave SG transfers,
then it may only be called after dmaengine_slave_config()
has executed. The slave driver provides parameters such as
burst size and address width which may be necessary for
the dmaengine driver to use in order to properly return SG
segment limit caps.
Suggested-by: Vinod Koul vinod.k...@intel.com
Signed-off-by: Matt Porter mpor...@ti.com
---
include/linux/dmaengine.h | 52
+
1 file changed, 52 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 11d9e25..0181887 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -371,6 +371,38 @@ struct dma_slave_config {
unsigned int slave_id;
};
+enum dmaengine_apis {
+ DMAENGINE_MEMCPY= 0x0001,
+ DMAENGINE_XOR = 0x0002,
+ DMAENGINE_XOR_VAL = 0x0004,
+ DMAENGINE_PQ= 0x0008,
+ DMAENGINE_PQ_VAL= 0x0010,
+ DMAENGINE_MEMSET= 0x0020,
+ DMAENGINE_SLAVE = 0x0040,
+ DMAENGINE_CYCLIC= 0x0080,
+ DMAENGINE_INTERLEAVED = 0x0100,
+ DMAENGINE_SG= 0x0200,
+};
+
+/* struct dmaengine_chan_caps - expose capability of a channel
+ * Note: each channel can have same or different capabilities
+ *
+ * This primarily classifies capabilities into
+ * a) APIs/ops supported
+ * b) channel physical capabilities
+ *
+ * @ops: or'ed api capability
+ * @seg_nr: maximum number of SG segments supported on a SG/SLAVE
+ * channel (0 for no maximum or not a SG/SLAVE channel)
+ * @seg_len: maximum length of SG segments supported on a SG/SLAVE
+ * channel (0 for no maximum or not a SG/SLAVE channel)
+ */
+struct dmaengine_chan_caps {
+ enum dmaengine_apis ops;
+ int seg_nr;
+ int seg_len;
+};
This makes sense for the potentially dynamic capability properties
that get set after configuration, but why do we need the operation
types here? They can be retrieved from the parent device.
--
Dan
--
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 1/3] dmaengine: add dma_get_channel_caps()
On Tue, 2012-10-23 at 15:54 -0700, Dan Williams wrote:
+struct dmaengine_chan_caps {
+ enum dmaengine_apis ops;
+ int seg_nr;
+ int seg_len;
+};
This makes sense for the potentially dynamic capability properties
that get set after configuration, but why do we need the operation
types here? They can be retrieved from the parent device.
I was thinking that each channel can have different capabilities.
You can assign one channel for mempcy operations exclusively and some
others for slave usage exclusively.
I believe some h/w do have such assignment so would help in doing that.
--
Vinod Koul
Intel Corp.
--
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 1/3] dmaengine: add dma_get_channel_caps()
On Tue, 2012-10-23 at 23:49 +0100, Grant Likely wrote:
+enum dmaengine_apis {
+ DMAENGINE_MEMCPY= 0x0001,
+ DMAENGINE_XOR = 0x0002,
+ DMAENGINE_XOR_VAL = 0x0004,
+ DMAENGINE_PQ= 0x0008,
+ DMAENGINE_PQ_VAL= 0x0010,
+ DMAENGINE_MEMSET= 0x0020,
+ DMAENGINE_SLAVE = 0x0040,
+ DMAENGINE_CYCLIC= 0x0080,
+ DMAENGINE_INTERLEAVED = 0x0100,
+ DMAENGINE_SG= 0x0200,
+};
Actually, one more comment. Why the new enum? Why can't the
dma_transaction_type enum be used directly along with dma_cap_mask_t?
Some of the capabilities above are not there in dma_caps_t like DMA_SG.
Also DMA_INTERRUPT and DMA_PRIVATE would not make much sense here.
BUT would help to keep things simpler if have one definition which
includes all.
--
Vinod Koul
Intel Corp.
--
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: process hangs on do_exit when oom happens
On Wed, Oct 24, 2012 at 1:43 AM, Balbir Singh bsinghar...@gmail.com wrote: On Tue, Oct 23, 2012 at 3:45 PM, Michal Hocko mho...@suse.cz wrote: On Tue 23-10-12 18:10:33, Qiang Gao wrote: On Tue, Oct 23, 2012 at 5:50 PM, Michal Hocko mho...@suse.cz wrote: On Tue 23-10-12 15:18:48, Qiang Gao wrote: This process was moved to RT-priority queue when global oom-killer happened to boost the recovery of the system.. Who did that? oom killer doesn't boost the priority (scheduling class) AFAIK. but it wasn't get properily dealt with. I still have no idea why where the problem is .. Well your configuration says that there is no runtime reserved for the group. Please refer to Documentation/scheduler/sched-rt-group.txt for more information. [...] maybe this is not a upstream-kernel bug. the centos/redhat kernel would boost the process to RT prio when the process was selected by oom-killer. This still looks like your cpu controller is misconfigured. Even if the task is promoted to be realtime. Precisely! You need to have rt bandwidth enabled for RT tasks to run, as a workaround please give the groups some RT bandwidth and then work out the migration to RT and what should be the defaults on the distro. Balbir see https://patchwork.kernel.org/patch/719411/ -- 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
