[PATCH] mmc: debugfs: Fix incorrect size of string allocation
It is usually accepted that code should explain itself. The max size of string is 1025(512*2 + 1) bytes so there is no point to add one more byte for string allocation. This patch is intended to fix incorrect size for string allocation and make code more readable. Signed-off-by: Kyungsik Lee kyungsik@lge.com --- drivers/mmc/core/debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c index 35c2f85..5008149 100644 --- a/drivers/mmc/core/debugfs.c +++ b/drivers/mmc/core/debugfs.c @@ -281,7 +281,7 @@ static int mmc_ext_csd_open(struct inode *inode, struct file *filp) u8 *ext_csd; int err, i; - buf = kmalloc(EXT_CSD_STR_LEN + 1, GFP_KERNEL); + buf = kmalloc(EXT_CSD_STR_LEN, GFP_KERNEL); if (!buf) return -ENOMEM; -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] mmc: core: Add support for idle time BKOPS
On 3 December 2012 10:49, me...@codeaurora.org wrote: Hi Jaehoon, With this patch we don't expect to see any degradation. Thanks for verifying that. The test plan would be to run the lmdd and iozone benchmarks with this patch and verify that the performance is not degraded. I verified it with the msm_sdcc controller. Chris - We do expect it to influence the battery consumption, since we now delay getting into suspend (since mmc_start_bkops which is called after the delayed work is executed claims the host). The solution for that should be done by the controller which can shorten the timeout given to pm_schedule_suspend by the periodic BKOPS idle time. Does it make sense to you? Thanks, Maya On Thu, November 29, 2012 4:40 am, Jaehoon Chung wrote: Hi Maya, Thank you a lot for working idle time BKOPS. I tested with this patch. It's working fine.(Suspend/resume is also working well.) Test controller is sdhci controller. When i tested the performance with iozone, i didn't find that performance is decreased. Well, as Chris is mentioned, do you have any test plan? So I will test more with this patch, because i want to test with dw-mmc controller, too. On 11/25/2012 08:56 PM, Maya Erez wrote: Devices have various maintenance operations need to perform internally. In order to reduce latencies during time critical operations like read and write, it is better to execute maintenance operations in other times - when the host is not being serviced. Such operations are called Background operations (BKOPS). The device notifies the status of the BKOPS need by updating BKOPS_STATUS (EXT_CSD byte [246]). According to the standard a host that supports BKOPS shall check the status periodically and start background operations as needed, so that the device has enough time for its maintenance operations. This patch adds support for this periodic check of the BKOPS status. Since foreground operations are of higher priority than background operations the host will check the need for BKOPS when it is idle, and in case of an incoming request the BKOPS operation will be interrupted. When the mmcqd thread is idle, a delayed work is created to check the need for BKOPS. The time to start the delayed work is calculated based on the host controller suspend timeout, in case it was set. If not, a default time is used. What host controller suspend timeout are you referring to here? If you are thinking of the runtime PM autosuspend timeout used in many host driver, then you might have missunderstand how runtime PM is used in host drivers. This has nothing to do with BKOPS as such, unless you think that the card must be kept clocked during BKOPS operations, but then this needs to be stated somewhere in this patch and that is not the case. Moreover, I could not find any new timeout added for the _host_ struct in this patch. If BKOPS are required in level 1, which is non-blocking, there will be polling of the card status to wait for the BKOPS completion and prevent suspend that will interrupt the BKOPS. Not sure of what suspend you are talking about here. But for sure BKOPS must _never_ prevent a system suspend. You might want to prevent a host from being runtime suspended though, but that is not accomplished in this patch. If the card raised an exception, the need for urgent BKOPS (level 2/3) will be checked immediately and if needed, the BKOPS will be performed without waiting for the next idle time. Signed-off-by: Maya Erez me...@codeaurora.org --- This patch is based on the periodic BKOPS implementation in version 8 of support BKOPS feature for eMMC patch. The patch was modified to answer the following issues: - In order to prevent a race condition between going into suspend and starting BKOPS, the suspend timeout of the host controller is taking into accound in determination of the start time of the delayed work - Since mmc_start_bkops is called from two contexts now, mmc_claim_host was moved to the beginning of the function - Also, the check of doing_bkops should be protected when determing if an HPI is needed due to the same reason. Changes in v3: - Move the call to stop_bkops to block.c. This allows us to remove the mmc_claim_host from inside the function and doesn't cause additional degradation due to un-neccessary calim host operation Changes in v2: - Check the number of written / discarded sectors as the trigger for checking the BKOPS need. - Code review fixes --- drivers/mmc/card/block.c |8 ++- drivers/mmc/card/queue.c |2 + drivers/mmc/core/core.c | 178 +++--- drivers/mmc/core/mmc.c | 23 ++ include/linux/mmc/card.h | 35 + include/linux/mmc/core.h |3 + 6 files changed, 237 insertions(+), 12 deletions(-) diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c index 172a768..40b4ae3 100644 ---
[PATCH v1 0/3] SDIO fixes
This patch-series is having 1 fix for SDIO resume and 2 fixes related to SDIO3.0 card detection Subhash Jadavani (2): mmc: sdio: fix resume failure mmc: sdio: print correct UHS mode during card detection Sujit Reddy Thumma (1): mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence drivers/mmc/core/sdio.c | 33 - include/linux/mmc/host.h |8 2 files changed, 28 insertions(+), 13 deletions(-) -- -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 1/3] mmc: sdio: fix resume failure
If SDIO keep power flag (MMC_PM_KEEP_POWER) is not set, card would
be reinitialized during resume but as we are not resetting
(CMD52 reset) the SDIO card during this reinitialization, card may
fail to respond back to subsequent commands (CMD5 etc...).
This change resets the card before the reinitialization of card
during resume.
Signed-off-by: Subhash Jadavani subha...@codeaurora.org
---
drivers/mmc/core/sdio.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 2273ce6..34ad4c8 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -937,10 +937,12 @@ static int mmc_sdio_resume(struct mmc_host *host)
mmc_claim_host(host);
/* No need to reinitialize powered-resumed nonremovable cards */
- if (mmc_card_is_removable(host) || !mmc_card_keep_power(host))
+ if (mmc_card_is_removable(host) || !mmc_card_keep_power(host)) {
+ sdio_reset(host);
+ mmc_go_idle(host);
err = mmc_sdio_init_card(host, host-ocr, host-card,
mmc_card_keep_power(host));
- else if (mmc_card_keep_power(host) mmc_card_wake_sdio_irq(host)) {
+ } else if (mmc_card_keep_power(host) mmc_card_wake_sdio_irq(host)) {
/* We may have switched to 1-bit mode during suspend */
err = sdio_enable_4bit_bus(host-card);
if (err 0) {
--
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence
From: Sujit Reddy Thumma sthu...@codeaurora.org
According to UHS-I initialization sequence for SDIO 3.0 cards,
the host must set bit[24] (S18R) of OCR register during OCR
handshake to know whether the SDIO card is capable of doing
1.8V I/O.
Signed-off-by: Sujit Reddy Thumma sthu...@codeaurora.org
Signed-off-by: Subhash Jadavani subha...@codeaurora.org
---
drivers/mmc/core/sdio.c | 22 +++---
include/linux/mmc/host.h |8
2 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 34ad4c8..9565d38 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -157,10 +157,7 @@ static int sdio_read_cccr(struct mmc_card *card, u32 ocr)
if (ret)
goto out;
- if (card-host-caps
- (MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 |
-MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR104 |
-MMC_CAP_UHS_DDR50)) {
+ if (mmc_host_uhs(card-host)) {
if (data SDIO_UHS_DDR50)
card-sw_caps.sd3_bus_mode
|= SD_MODE_UHS_DDR50;
@@ -478,8 +475,7 @@ static int sdio_set_bus_speed_mode(struct mmc_card *card)
* If the host doesn't support any of the UHS-I modes, fallback on
* default speed.
*/
- if (!(card-host-caps (MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 |
- MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR104 | MMC_CAP_UHS_DDR50)))
+ if (!mmc_host_uhs(card-host))
return 0;
bus_speed = SDIO_SPEED_SDR12;
@@ -645,11 +641,7 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32
ocr,
* systems that claim 1.8v signalling in fact do not support
* it.
*/
- if ((ocr R4_18V_PRESENT)
- (host-caps
- (MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 |
-MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR104 |
-MMC_CAP_UHS_DDR50))) {
+ if ((ocr R4_18V_PRESENT) mmc_host_uhs(host)) {
err = mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_180,
true);
if (err) {
@@ -1022,6 +1014,10 @@ static int mmc_sdio_power_restore(struct mmc_host *host)
goto out;
}
+ if (mmc_host_uhs(host))
+ /* to query card if 1.8V signalling is supported */
+ host-ocr |= R4_18V_PRESENT;
+
ret = mmc_sdio_init_card(host, host-ocr, host-card,
mmc_card_keep_power(host));
if (!ret host-sdio_irqs)
@@ -1087,6 +1083,10 @@ int mmc_attach_sdio(struct mmc_host *host)
/*
* Detect and init the card.
*/
+ if (mmc_host_uhs(host))
+ /* to query card if 1.8V signalling is supported */
+ host-ocr |= R4_18V_PRESENT;
+
err = mmc_sdio_init_card(host, host-ocr, NULL, 0);
if (err) {
if (err == -EAGAIN) {
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 23df21e..9be0440 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -433,6 +433,14 @@ static inline int mmc_boot_partition_access(struct
mmc_host *host)
return !(host-caps2 MMC_CAP2_BOOTPART_NOACC);
}
+static inline int mmc_host_uhs(struct mmc_host *host)
+{
+ return host-caps
+ (MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 |
+MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR104 |
+MMC_CAP_UHS_DDR50);
+}
+
#ifdef CONFIG_MMC_CLKGATE
void mmc_host_clk_hold(struct mmc_host *host);
void mmc_host_clk_release(struct mmc_host *host);
--
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 3/3] mmc: sdio: print correct UHS mode during card detection
When SDIO3.0 card is detected, incorrect bus speed mode
is printed as part of card detection print in kernel logs.
This change fixes it so that user won't be confused by
looking at incorrect card detection message in logs.
Signed-off-by: Subhash Jadavani subha...@codeaurora.org
---
drivers/mmc/core/sdio.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 9565d38..3a64933 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -485,23 +485,27 @@ static int sdio_set_bus_speed_mode(struct mmc_card *card)
bus_speed = SDIO_SPEED_SDR104;
timing = MMC_TIMING_UHS_SDR104;
card-sw_caps.uhs_max_dtr = UHS_SDR104_MAX_DTR;
+ card-sd_bus_speed = UHS_SDR104_BUS_SPEED;
} else if ((card-host-caps MMC_CAP_UHS_DDR50)
(card-sw_caps.sd3_bus_mode SD_MODE_UHS_DDR50)) {
bus_speed = SDIO_SPEED_DDR50;
timing = MMC_TIMING_UHS_DDR50;
card-sw_caps.uhs_max_dtr = UHS_DDR50_MAX_DTR;
+ card-sd_bus_speed = UHS_DDR50_BUS_SPEED;
} else if ((card-host-caps (MMC_CAP_UHS_SDR104 |
MMC_CAP_UHS_SDR50)) (card-sw_caps.sd3_bus_mode
SD_MODE_UHS_SDR50)) {
bus_speed = SDIO_SPEED_SDR50;
timing = MMC_TIMING_UHS_SDR50;
card-sw_caps.uhs_max_dtr = UHS_SDR50_MAX_DTR;
+ card-sd_bus_speed = UHS_SDR50_BUS_SPEED;
} else if ((card-host-caps (MMC_CAP_UHS_SDR104 |
MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR25))
(card-sw_caps.sd3_bus_mode SD_MODE_UHS_SDR25)) {
bus_speed = SDIO_SPEED_SDR25;
timing = MMC_TIMING_UHS_SDR25;
card-sw_caps.uhs_max_dtr = UHS_SDR25_MAX_DTR;
+ card-sd_bus_speed = UHS_SDR25_BUS_SPEED;
} else if ((card-host-caps (MMC_CAP_UHS_SDR104 |
MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR25 |
MMC_CAP_UHS_SDR12)) (card-sw_caps.sd3_bus_mode
@@ -509,6 +513,7 @@ static int sdio_set_bus_speed_mode(struct mmc_card *card)
bus_speed = SDIO_SPEED_SDR12;
timing = MMC_TIMING_UHS_SDR12;
card-sw_caps.uhs_max_dtr = UHS_SDR12_MAX_DTR;
+ card-sd_bus_speed = UHS_SDR12_BUS_SPEED;
}
err = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_SPEED, 0, speed);
--
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] mmc: sdhci-s3c: Fix compilation warning
'sc' is used only when CONFIG_PM_RUNTIME is defined. Hence define it
conditionally.
Silences the following warning:
drivers/mmc/host/sdhci-s3c.c: In function ‘sdhci_s3c_notify_change’:
drivers/mmc/host/sdhci-s3c.c:378:20: warning: unused variable ‘sc’
[-Wunused-variable]
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/mmc/host/sdhci-s3c.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 7ea3aea..82a8de1 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -375,7 +375,9 @@ static struct sdhci_ops sdhci_s3c_ops = {
static void sdhci_s3c_notify_change(struct platform_device *dev, int state)
{
struct sdhci_host *host = platform_get_drvdata(dev);
+#ifdef CONFIG_PM_RUNTIME
struct sdhci_s3c *sc = sdhci_priv(host);
+#endif
unsigned long flags;
if (host) {
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] Fix fixed regulators support
Hello, Commit f0f98b19e23d4426ca185e3d4ca80e6aff5ef51b revealed that the support for fixed regulators in SDHCI driver was working only by pure luck. My previous patch set for fixing this issue resulted in a discussion, which has been concluded that this issue should by fixed by extending regulators core by regualtor_can_change_voltage() function and using it in the mmc/sdhci drivers. For more information, please refer to the following threads: http://thread.gmane.org/gmane.linux.kernel.mmc/17643 https://patchwork.kernel.org/patch/1739061/ Best regards Marek Szyprowski Samsung Poland RD Center Patch summary: Marek Szyprowski (3): regulators: add regulator_can_change_voltage() function mmc: use regulator_can_change_voltage() instead of regulator_count_voltages() hacks mmc: sdhci: check voltage range only on regulators aware of voltage value drivers/mmc/core/core.c|2 +- drivers/mmc/host/sdhci.c |6 +- drivers/regulator/core.c | 22 ++ include/linux/regulator/consumer.h |1 + 4 files changed, 29 insertions(+), 2 deletions(-) -- 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
[PATCH 1/3] regulators: add regulator_can_change_voltage() function
Introduce a regulator_can_change_voltage() function for the subsytems or
drivers which might check if applying voltage change is possible and use
special workaround code when the driver is used with fixed regulators or
regulators with disabled ability to change the voltage.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/regulator/core.c | 22 ++
include/linux/regulator/consumer.h |1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 5c4829c..24623b8 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1861,6 +1861,28 @@ int regulator_is_enabled(struct regulator *regulator)
EXPORT_SYMBOL_GPL(regulator_is_enabled);
/**
+ * regulator_can_change_voltage - check if regulator can change voltage
+ * @regulator: regulator source
+ *
+ * Returns positive if the regulator driver backing the source/client
+ * can change its voltage, false otherwise. Usefull for detecting fixed
+ * or dummy regulators and disabling voltage change logic in the client
+ * driver.
+ */
+int regulator_can_change_voltage(struct regulator *regulator)
+{
+ struct regulator_dev*rdev = regulator-rdev;
+
+ if (rdev-constraints
+ rdev-constraints-valid_ops_mask REGULATOR_CHANGE_VOLTAGE
+ rdev-desc-n_voltages 1)
+ return 1;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(regulator_can_change_voltage);
+
+/**
* regulator_count_voltages - count regulator_list_voltage() selectors
* @regulator: regulator source
*
diff --git a/include/linux/regulator/consumer.h
b/include/linux/regulator/consumer.h
index c43cd35..5d0f7c1 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -160,6 +160,7 @@ int regulator_bulk_force_disable(int num_consumers,
void regulator_bulk_free(int num_consumers,
struct regulator_bulk_data *consumers);
+int regulator_can_change_voltage(struct regulator *regulator);
int regulator_count_voltages(struct regulator *regulator);
int regulator_list_voltage(struct regulator *regulator, unsigned selector);
int regulator_is_supported_voltage(struct regulator *regulator,
--
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
[PATCH 2/3] mmc: use regulator_can_change_voltage() instead of regulator_count_voltages() hacks
mmc_regulator_set_ocr() depends on the ability of regulator to change the voltage value. When regulator cannot change its voltage output, some code is skipped to avoid reporting false errors on some boards, which use MMC hosts with fixed regulators (example: Samsung Goni and UniversalC210 boards). This patch replaces a hacky workaround based on regulator_count_voltages() value with the correct call to recently introduced regulator_can_change_voltage() function in regulators core. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com --- drivers/mmc/core/core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index aaed768..f5a0493 100644 --- a/drivers/mmc/core/core.c +++ b/drivers/mmc/core/core.c @@ -1137,7 +1137,7 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc, */ voltage = regulator_get_voltage(supply); - if (regulator_count_voltages(supply) == 1) + if (!regulator_can_change_voltage(supply)) min_uV = max_uV = voltage; if (voltage 0) -- 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
[PATCH 3/3] mmc: sdhci: check voltage range only on regulators aware of voltage value
Some regulators don't report any voltage values, so checking supported
voltage range results in disabling all SDHCI_CAN_VDD_* flags and
registration failure. This patch finally provides a correct fix for the
registration of SDHCI driver with all possible voltage regulators:
dummy, fixed and regulated without using regulator_count_voltages()
hacks.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/mmc/host/sdhci.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index a9ad2cd..d244dc0 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2930,7 +2930,11 @@ int sdhci_add_host(struct sdhci_host *host)
}
#ifdef CONFIG_REGULATOR
- if (host-vmmc regulator_count_voltages(host-vmmc) 1) {
+ /*
+* Voltage range check makes sense only if regulator reports
+* any voltage value.
+*/
+ if (host-vmmc regulator_get_voltage(host-vmmc) 0) {
ret = regulator_is_supported_voltage(host-vmmc, 270,
360);
if ((ret = 0) || (!(caps[0] SDHCI_CAN_VDD_330)))
--
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: FW: [PATCH v2] mmc: sdhci: apply voltage range check only for non-fixed regulators
Hello, On 11/30/2012 5:48 PM, Chris Ball wrote: On Tue, Nov 20 2012, Marek Szyprowski wrote: The problem with dummy regulator is the fact that it can be enabled only globally for all devices in the system. I think that the best solution would be to introduce regulator_can_change_voltage() as Mark suggested. I will post patches soon. Does this mean that I shouldn't merge either yours or Kevin's patch for 3.8, while we wait for this? Any ETA on it? I've just posted an updated patches to solve those issues. I'm sorry for the delay as I was terribly busy with other stuff. Kevin's patch is still required and it should stay in the tree because it indeed fixes other, in some cases related issues. However my earlier patch mmc: sdhci: apply voltage range check only for non-fixed regulators can be replaced with the new patches from the [PATCH v2 0/3] Fix fixed regulators support thread posted a few minutes ago (those patches are based on mmc-next branch). Best regards -- Marek Szyprowski Samsung Poland RD Center -- 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 3/3] mmc: sdhci: check voltage range only on regulators aware of voltage value
2012/12/4 Marek Szyprowski m.szyprow...@samsung.com:
Some regulators don't report any voltage values, so checking supported
voltage range results in disabling all SDHCI_CAN_VDD_* flags and
registration failure. This patch finally provides a correct fix for the
registration of SDHCI driver with all possible voltage regulators:
dummy, fixed and regulated without using regulator_count_voltages()
hacks.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/mmc/host/sdhci.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index a9ad2cd..d244dc0 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2930,7 +2930,11 @@ int sdhci_add_host(struct sdhci_host *host)
}
#ifdef CONFIG_REGULATOR
- if (host-vmmc regulator_count_voltages(host-vmmc) 1) {
+ /*
+* Voltage range check makes sense only if regulator reports
+* any voltage value.
+*/
+ if (host-vmmc regulator_get_voltage(host-vmmc) 0) {
ret = regulator_is_supported_voltage(host-vmmc, 270,
360);
if ((ret = 0) || (!(caps[0] SDHCI_CAN_VDD_330)))
Good idea. But how about the regulator is disabled at this point? So I
suggest to change to
if (host-vmmc regulator_get_voltage(host-vmmc) = 0)
Thanks
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] mmc: add a card-event host operation
Some hosts need to perform additional actions upon card insertion or
ejection. Add a host operation to be called from card detection handlers.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
include/linux/mmc/host.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 7abb0e1..79ead24 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -136,6 +136,7 @@ struct mmc_host_ops {
void(*enable_preset_value)(struct mmc_host *host, bool enable);
int (*select_drive_strength)(unsigned int max_dtr, int host_drv,
int card_drv);
void(*hw_reset)(struct mmc_host *host);
+ void(*card_event)(struct mmc_host *host);
};
struct mmc_card;
--
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
[PATCH 0/3] mmc: add a card-event host call-back
In a recent thread [1] an extension to the slot-gpio MMC API, adding a host call-back for card detection events, has been proposed. This extension shall be used by the SDHCI driver to reset the host if the card is ejected during a running request. These patches add such a call-back. Thanks Guennadi [1] http://thread.gmane.org/gmane.linux.kernel.mmc/17924/focus=17927 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 2/3] mmc: extend the slot-gpio card-detection to use host's .card_event() method
The slot-gpio API provides a generic card-detection handler. To support a
wider range of hosts it has to call the host's card-event callback, if
implemented. Also increase the debounce interval to 200ms to match the
SDHCI driver.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/mmc/core/slot-gpio.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
index 08c6b3d..16a1c0b 100644
--- a/drivers/mmc/core/slot-gpio.c
+++ b/drivers/mmc/core/slot-gpio.c
@@ -27,7 +27,13 @@ struct mmc_gpio {
static irqreturn_t mmc_gpio_cd_irqt(int irq, void *dev_id)
{
/* Schedule a card detection after a debounce timeout */
- mmc_detect_change(dev_id, msecs_to_jiffies(100));
+ struct mmc_host *host = dev_id;
+
+ if (host-ops-card_event)
+ host-ops-card_event(host);
+
+ mmc_detect_change(host, msecs_to_jiffies(200));
+
return IRQ_HANDLED;
}
--
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
[PATCH 3/3] mmc: sdhci: implement the .card_event() method
Extracting a part of the SDHCI card tasklet into a .card_event()
implementation allows SDHCI hosts to use generic card-detection
services, e.g. the GPIO slot function.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/mmc/host/sdhci.c | 48 +
1 files changed, 27 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index c7851c0..2323553 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1994,30 +1994,11 @@ static void sdhci_enable_preset_value(struct mmc_host
*mmc, bool enable)
sdhci_runtime_pm_put(host);
}
-static const struct mmc_host_ops sdhci_ops = {
- .request= sdhci_request,
- .set_ios= sdhci_set_ios,
- .get_ro = sdhci_get_ro,
- .hw_reset = sdhci_hw_reset,
- .enable_sdio_irq = sdhci_enable_sdio_irq,
- .start_signal_voltage_switch= sdhci_start_signal_voltage_switch,
- .execute_tuning = sdhci_execute_tuning,
- .enable_preset_value= sdhci_enable_preset_value,
-};
-
-/*\
- * *
- * Tasklets *
- * *
-\*/
-
-static void sdhci_tasklet_card(unsigned long param)
+static void sdhci_card_event(struct mmc_host *mmc)
{
- struct sdhci_host *host;
+ struct sdhci_host *host = mmc_priv(mmc);
unsigned long flags;
- host = (struct sdhci_host*)param;
-
spin_lock_irqsave(host-lock, flags);
/* Check host-mrq first in case we are runtime suspended */
@@ -2036,6 +2017,31 @@ static void sdhci_tasklet_card(unsigned long param)
}
spin_unlock_irqrestore(host-lock, flags);
+}
+
+static const struct mmc_host_ops sdhci_ops = {
+ .request= sdhci_request,
+ .set_ios= sdhci_set_ios,
+ .get_ro = sdhci_get_ro,
+ .hw_reset = sdhci_hw_reset,
+ .enable_sdio_irq = sdhci_enable_sdio_irq,
+ .start_signal_voltage_switch= sdhci_start_signal_voltage_switch,
+ .execute_tuning = sdhci_execute_tuning,
+ .enable_preset_value= sdhci_enable_preset_value,
+ .card_event = sdhci_card_event,
+};
+
+/*\
+ * *
+ * Tasklets *
+ * *
+\*/
+
+static void sdhci_tasklet_card(unsigned long param)
+{
+ struct sdhci_host *host = (struct sdhci_host*)param;
+
+ sdhci_card_event(host-mmc);
mmc_detect_change(host-mmc, msecs_to_jiffies(200));
}
--
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 3/3] MMC: sdhci-dove: allow GPIOs to be used for card detection on Dove
Hi Chris On Mon, 3 Dec 2012, Chris Ball wrote: Hi Guennadi, On Mon, Nov 26 2012, Guennadi Liakhovetski wrote: Guennadi, what are your thoughts about consolidating this reset logic between the sdhci tasklet and slot-gpio? It would certainly be nice to use slot-gpio in cases like this one, so it's worth fixing. Sure, this can be added. As for how - I see at least two possibilities: (1) put the complete above block in a new mmc host operation and just call it from the GPIO card-detect ISR, (2) taking into account, that many (nearly all? all?) host drivers keep a pointer to the current mrq in their private data struct, we could instead add such a pointer to struct mmc_host, then the check request in progress could also be generalised, and the operation would just have to reset the host and complete the request (in the sdhci case schedule the task). They both sound pretty attractive. Maybe we start out with (1), which would create a patch we could more reasonably send to stable@ to get slot-gpio handling the reset during transfers properly in older kernels, and then refactor into (2) later? Just posted 3 patches for this, have a look if that's what you were thinking about. Not sure though why this is needed for stable, but I'm probably just missing some crucial information on the topic. Thanks Guennadi Note, that there's already a .hw_reset() operation, used by sdhci-pci only so far, still, it seems we cannot (easily) hijack it. That one's implementing an eMMC 4.5 spec feature, not related to this kind of reset. Thanks! - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 3/3] MMC: sdhci-dove: allow GPIOs to be used for card detection on Dove
Hi Guennadi, On Tue, Dec 04 2012, Guennadi Liakhovetski wrote: They both sound pretty attractive. Maybe we start out with (1), which would create a patch we could more reasonably send to stable@ to get slot-gpio handling the reset during transfers properly in older kernels, and then refactor into (2) later? Just posted 3 patches for this, have a look if that's what you were thinking about. Not sure though why this is needed for stable, but I'm probably just missing some crucial information on the topic. Thanks! I'll take a look. I agree that this isn't definitely needed in -stable, but I'm glad we have the option if someone finds that their host isn't functioning after card removal during a transfer. Russell, are you happy with switching sdhci-dove over to slot-gpio with this patchset? 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 3/3] MMC: sdhci-dove: allow GPIOs to be used for card detection on Dove
On Tue, Dec 04, 2012 at 11:06:39AM -0500, Chris Ball wrote: Hi Guennadi, On Tue, Dec 04 2012, Guennadi Liakhovetski wrote: They both sound pretty attractive. Maybe we start out with (1), which would create a patch we could more reasonably send to stable@ to get slot-gpio handling the reset during transfers properly in older kernels, and then refactor into (2) later? Just posted 3 patches for this, have a look if that's what you were thinking about. Not sure though why this is needed for stable, but I'm probably just missing some crucial information on the topic. Thanks! I'll take a look. I agree that this isn't definitely needed in -stable, but I'm glad we have the option if someone finds that their host isn't functioning after card removal during a transfer. Russell, are you happy with switching sdhci-dove over to slot-gpio with this patchset? I'd rather not until I've moved my cubox kernel tree to v3.7 (when it's out.) Keeping stuff straight between that tree and mainline is far from easy - I'm having to maintain two independent patches for each change, one against each kernel tree, one gets tested (the one in the cubox tree) the other (against mainline) does not. -- 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 3/3] MMC: sdhci-dove: allow GPIOs to be used for card detection on Dove
Hi, On Tue, Dec 04 2012, Russell King - ARM Linux wrote: Russell, are you happy with switching sdhci-dove over to slot-gpio with this patchset? I'd rather not until I've moved my cubox kernel tree to v3.7 (when it's out.) Keeping stuff straight between that tree and mainline is far from easy - I'm having to maintain two independent patches for each change, one against each kernel tree, one gets tested (the one in the cubox tree) the other (against mainline) does not. Okay -- I'll take the patchset as-is for 3.8, with a plan to move to slot-gpio after you're caught up. 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 v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence
Hi, From: Sujit Reddy Thumma sthu...@codeaurora.org According to UHS-I initialization sequence for SDIO 3.0 cards, the host must set bit[24] (S18R) of OCR register during OCR handshake to know whether the SDIO card is capable of doing 1.8V I/O. In SDIO 2.0 spec, bit[24] is reserved, shall be set to 0. Setting it to 1 might cause side effect to 2.0 cards. Perhaps using a quirk for S18R is more suitable for all combinations. Regards, Bing Signed-off-by: Sujit Reddy Thumma sthu...@codeaurora.org Signed-off-by: Subhash Jadavani subha...@codeaurora.org --- drivers/mmc/core/sdio.c | 22 +++--- include/linux/mmc/host.h |8 2 files changed, 19 insertions(+), 11 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: [PATCH v3] mmc: core: Add support for idle time BKOPS
Hi Ulf, Let me try to better explain: The idea behind the periodic BKOPS is to check the card's need for BKOPS periodically in order to prevent an urgent BKOPS need by the card. In order to actually manage to prevent the urgent BKOPS need, the host should give the card enough time to perform the BKOPS (when it recognizes BKOPS need), otherwise there is no point in having the periodic BKOPS. The above results in the following: 1. After starting non-urgent BKOPS we delay getting into suspend by polling on the card's status (explanation below), in order to give the card time to perform the BKOPS. This has no effect on the power consumption since the same BKOPS operations that were performed after the foregound operation just moved to another location, meaning before going into suspend. 2. Using PM_SUSPEND_PREPARE instead of the workqueue would not be efficient since we don't want to wait until the host is ready to get into suspend and then prevent him from suspending by doing BKOPS operations that can take a long time. It is better to start the BKOPS earlier. I am not too familiar with the controllers code and also my understanding in runtime suspend is very basic, so feel free to correct me if I'm wrong here or the behavior in other controllers is different from msm_sdcc. mmc_claim_host calls host-ops-enable. This API is implemented per controller but as far as I understand it, this API must prevent suspend, otherwise we might go into suspend while there is bus activity. By doing get_card_status we call mmc_claim_host and this call is the one that delays getting into suspend. If this is not the case in other controllers than the BKOPS will not prevent the suspend and BKOPS will be interrupted. As for the effect on the battery consumption, this is probably something specific to our controller, so sorry if I created a confusion. Additional comments inline. Thanks, Maya On Tue, December 4, 2012 1:52 am, Ulf Hansson wrote: On 3 December 2012 10:49, me...@codeaurora.org wrote: Hi Jaehoon, With this patch we don't expect to see any degradation. Thanks for verifying that. The test plan would be to run the lmdd and iozone benchmarks with this patch and verify that the performance is not degraded. I verified it with the msm_sdcc controller. Chris - We do expect it to influence the battery consumption, since we now delay getting into suspend (since mmc_start_bkops which is called after the delayed work is executed claims the host). The solution for that should be done by the controller which can shorten the timeout given to pm_schedule_suspend by the periodic BKOPS idle time. Does it make sense to you? Thanks, Maya On Thu, November 29, 2012 4:40 am, Jaehoon Chung wrote: Hi Maya, Thank you a lot for working idle time BKOPS. I tested with this patch. It's working fine.(Suspend/resume is also working well.) Test controller is sdhci controller. When i tested the performance with iozone, i didn't find that performance is decreased. Well, as Chris is mentioned, do you have any test plan? So I will test more with this patch, because i want to test with dw-mmc controller, too. On 11/25/2012 08:56 PM, Maya Erez wrote: Devices have various maintenance operations need to perform internally. In order to reduce latencies during time critical operations like read and write, it is better to execute maintenance operations in other times - when the host is not being serviced. Such operations are called Background operations (BKOPS). The device notifies the status of the BKOPS need by updating BKOPS_STATUS (EXT_CSD byte [246]). According to the standard a host that supports BKOPS shall check the status periodically and start background operations as needed, so that the device has enough time for its maintenance operations. This patch adds support for this periodic check of the BKOPS status. Since foreground operations are of higher priority than background operations the host will check the need for BKOPS when it is idle, and in case of an incoming request the BKOPS operation will be interrupted. When the mmcqd thread is idle, a delayed work is created to check the need for BKOPS. The time to start the delayed work is calculated based on the host controller suspend timeout, in case it was set. If not, a default time is used. What host controller suspend timeout are you referring to here? If you are thinking of the runtime PM autosuspend timeout used in many host driver, then you might have missunderstand how runtime PM is used in host drivers. This has nothing to do with BKOPS as such, unless you think that the card must be kept clocked during BKOPS operations, but then this needs to be stated somewhere in this patch and that is not the case. Moreover, I could not find any new timeout added for the _host_ struct in this patch. Yes, I was referring to the runtime PM autosuspend timeout. Since we want to give the BKOPS time to be performed before going into
Re: [PATCH 3/3] mmc: sdhci: check voltage range only on regulators aware of voltage value
On Tue, Dec 04, 2012 at 10:50:03PM +0800, Kevin Liu wrote:
2012/12/4 Marek Szyprowski m.szyprow...@samsung.com:
+ if (host-vmmc regulator_get_voltage(host-vmmc) 0) {
ret = regulator_is_supported_voltage(host-vmmc, 270,
360);
if ((ret = 0) || (!(caps[0] SDHCI_CAN_VDD_330)))
Good idea. But how about the regulator is disabled at this point? So I
suggest to change to
if (host-vmmc regulator_get_voltage(host-vmmc) = 0)
I'd not expect regulator_get_voltage() to return 0 for disabled
regulators, I'd expect it to return the voltage the regulator will have
when enabled.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence
Hi Bing, The function mmc_host_uhs() will return false and never set bit[24] (S18R) for SDIO 2.0 cards. Thanks, Jackey -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Bing Zhao Sent: Wednesday, December 05, 2012 5:14 AM To: Subhash Jadavani; linux-mmc@vger.kernel.org Cc: linux-arm-...@vger.kernel.org; Sujit Reddy Thumma Subject: RE: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence Hi, From: Sujit Reddy Thumma sthu...@codeaurora.org According to UHS-I initialization sequence for SDIO 3.0 cards, the host must set bit[24] (S18R) of OCR register during OCR handshake to know whether the SDIO card is capable of doing 1.8V I/O. In SDIO 2.0 spec, bit[24] is reserved, shall be set to 0. Setting it to 1 might cause side effect to 2.0 cards. Perhaps using a quirk for S18R is more suitable for all combinations. Regards, Bing Signed-off-by: Sujit Reddy Thumma sthu...@codeaurora.org Signed-off-by: Subhash Jadavani subha...@codeaurora.org --- drivers/mmc/core/sdio.c | 22 +++--- include/linux/mmc/host.h |8 2 files changed, 19 insertions(+), 11 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 -- 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
