Re: [PATCH 2/3] tmio_mmc / PM: Use PM QoS latency constraint
On 08/03/12 01:29, Rafael J. Wysocki wrote: From: Rafael J. Wysocki r...@sisk.pl Make tmio_mmc call dev_pm_qos_expose_latency_limit() to expose the PM QoS latency limit to user space and specify the initial value of it as 100 microseconds. Signed-off-by: Rafael J. Wysocki r...@sisk.pl --- drivers/mmc/host/tmio_mmc_pio.c |5 + 1 file changed, 5 insertions(+) Index: linux/drivers/mmc/host/tmio_mmc_pio.c === --- linux.orig/drivers/mmc/host/tmio_mmc_pio.c +++ linux/drivers/mmc/host/tmio_mmc_pio.c @@ -39,6 +39,7 @@ #include linux/module.h #include linux/pagemap.h #include linux/platform_device.h +#include linux/pm_qos.h #include linux/pm_runtime.h #include linux/scatterlist.h #include linux/spinlock.h @@ -955,6 +956,8 @@ int __devinit tmio_mmc_host_probe(struct mmc_add_host(mmc); + dev_pm_qos_expose_latency_limit(pdev-dev, 100); + /* Unmask the IRQs we want to know about */ if (!_host-chan_rx) irq_mask |= TMIO_MASK_READOP; @@ -993,6 +996,8 @@ void tmio_mmc_host_remove(struct tmio_mm || host-mmc-caps MMC_CAP_NONREMOVABLE) pm_runtime_get_sync(pdev-dev); + dev_pm_qos_hide_latency_limit(pdev-dev); Is it really necessary to hide the latency limit before destroying the device? Presumably QoS code could (or does) take care of it. + mmc_remove_host(host-mmc); cancel_work_sync(host-done); cancel_delayed_work_sync(host-delayed_reset_work); -- 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 0/4] mmc: sdhci-s3c: use the sdhci-pltfm.c and move the header file
On Thu, Mar 08, 2012 at 02:35:53PM +0900, Jaehoon Chung wrote: So i think no problem that removed #include plat/regs-sdhci.h. is it wrong? Just touching the setup-gpio- files is problem? It should be fine, like I say I didn't really read the patches in enough detail as the diffstat set off alarm bells. signature.asc Description: Digital signature
Re: [PATCH 3/3] sh_mmcif / PM: Use PM QoS latency constraint
On Thu, Mar 08, 2012 at 12:30:28AM +0100, Rafael J. Wysocki wrote: + dev_pm_qos_hide_latency_limit(pdev-dev); + Shouldn't the core be able to cope with cleaning things up by itself here? It seems like it'd be easier/less error prone to do that. signature.asc Description: Digital signature
Re: [PATCH v2 0/6] mmc: omap_hsmmc: Clean up use/abuse of pdev-id
Hi Chris, On Wednesday 07 March 2012 08:29 PM, Chris Ball wrote: Hi Rajendra, On Wed, Mar 07 2012, Rajendra Nayak wrote: Chris, Ping. I am basing my DT support patches on top of these cleanups. Would be great if you can have a look and pull them in. Chris, just realized the last two requests from me to get this merged weren't addressed to you directly, but instead you were copied. Resending with you in 'To', hope this lands in your inbox :) Sorry for the delay, thanks for the ping; I've pushed these to mmc-next for 3.4 now. There's just one other cleanup patch here [1] to convert all pr_* prints in the driver to dev_*. Would be great if you can pick that as well. Thanks, Rajendra [1] http://marc.info/?l=linux-mmcm=132999677405098w=3 Thanks, - Chris. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] mmc: core: Clean up after mmc_pre_req if card was removed
Hi Jaehoon,
Thanks a lot for your assistance; great to hear that the problem was solved.
Thanks!
Br
Uffe
On 03/07/2012 06:24 AM, Jaehoon Chung wrote:
Hi Ulf.
I tested with patch-v2, i didn't found the other problem.
It looks good.
Tested-by: Jaehoon Chungjh80.ch...@samsung.com
Best Regards,
Jaehoon Chung
On 03/07/2012 01:26 AM, Ulf Hansson wrote:
Hi Jaehoon,
I would be very interested to hear if you still encounter any problems with
this V2 patch? If you are able to do a test it would be highly appreciated. :-)
Just for reference, I were able to reproduce problems similar to what you have
for the V1 patch.
Thanks!
Best regards
Ulf Hansson
On 03/05/2012 03:52 PM, Ulf HANSSON wrote:
Make sure mmc_start_req cancel the prepared job, if the request
was prevented to be started due to the card has been removed.
This bug was introduced in commit:
mmc: allow upper layers to know immediately if card has been removed
Signed-off-by: Ulf Hanssonulf.hans...@stericsson.com
Reviewed-by: Per Forlinper.for...@stericsson.com
---
Changes in v2:
- Maintain handling of host-areq (host-areq must not be NULL when
start_err), to make sure the block layer is able to respond to all
of the started requests.
---
drivers/mmc/core/core.c | 35 +++
1 files changed, 15 insertions(+), 20 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index faa0af1..56b7a24 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -249,16 +249,17 @@ static void mmc_wait_done(struct mmc_request *mrq)
complete(mrq-completion);
}
-static void __mmc_start_req(struct mmc_host *host, struct mmc_request *mrq)
+static int __mmc_start_req(struct mmc_host *host, struct mmc_request *mrq)
{
init_completion(mrq-completion);
mrq-done = mmc_wait_done;
if (mmc_card_removed(host-card)) {
mrq-cmd-error = -ENOMEDIUM;
complete(mrq-completion);
-return;
+return -ENOMEDIUM;
}
mmc_start_request(host, mrq);
+return 0;
}
static void mmc_wait_for_req_done(struct mmc_host *host,
@@ -342,6 +343,7 @@ struct mmc_async_req *mmc_start_req(struct mmc_host *host,
struct mmc_async_req *areq, int *error)
{
int err = 0;
+int start_err = 0;
struct mmc_async_req *data = host-areq;
/* Prepare a new request */
@@ -351,30 +353,23 @@ struct mmc_async_req *mmc_start_req(struct mmc_host *host,
if (host-areq) {
mmc_wait_for_req_done(host, host-areq-mrq);
err = host-areq-err_check(host-card, host-areq);
-if (err) {
-/* post process the completed failed request */
-mmc_post_req(host, host-areq-mrq, 0);
-if (areq)
-/*
- * Cancel the new prepared request, because
- * it can't run until the failed
- * request has been properly handled.
- */
-mmc_post_req(host, areq-mrq, -EINVAL);
-
-host-areq = NULL;
-goto out;
-}
}
-if (areq)
-__mmc_start_req(host, areq-mrq);
+if (!err areq)
+start_err = __mmc_start_req(host, areq-mrq);
if (host-areq)
mmc_post_req(host, host-areq-mrq, 0);
-host-areq = areq;
- out:
+ /* Cancel a prepared request if it was not started. */
+if ((err || start_err) areq)
+mmc_post_req(host, areq-mrq, -EINVAL);
+
+if (err)
+host-areq = NULL;
+else
+host-areq = areq;
+
if (error)
*error = err;
return data;
--
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
[PATCH] mmc: omap4: hsmmc: fix module re-insertion
OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset. Addng the offset to platform_device resource structure increments the start address for every insmod operation. MMC command fails on re-insertion as module due to incorrect register base. Fix this by updating the ioremap base address only. Signed-off-by: Balaji T K balaj...@ti.com --- drivers/mmc/host/omap_hsmmc.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index e550170..102425c 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1741,8 +1741,6 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) if (res == NULL || irq 0) return -ENXIO; - res-start += pdata-reg_offset; - res-end += pdata-reg_offset; res = request_mem_region(res-start, resource_size(res), pdev-name); if (res == NULL) return -EBUSY; @@ -1766,7 +1764,7 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) host-dma_ch= -1; host-irq = irq; host-slot_id = 0; - host-mapbase = res-start; + host-mapbase = res-start + pdata-reg_offset; host-base = ioremap(host-mapbase, SZ_4K); host-power_mode = MMC_POWER_OFF; host-next_data.cookie = 1; -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree
On 03/07/2012 09:46 PM, Rajendra Nayak wrote:
Hi Rob/Grant,
On Thursday 23 February 2012 05:31 PM, Rajendra Nayak wrote:
Define dt bindings for the ti-omap-hsmmc, and adapt
the driver to extract data (which was earlier passed as
platform_data) from device tree.
Any comments on these bindings for omap hsmmc? All the dependent
patches/series on which this series was based have now made it to
the respective -next of Mark and Chris.
Acked-by: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Rajendra Nayakrna...@ti.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 31 +
drivers/mmc/host/omap_hsmmc.c | 68
2 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
new file mode 100644
index 000..e4fa8f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -0,0 +1,31 @@
+* TI Highspeed MMC host controller for OMAP
+
+The Highspeed MMC Host Controller on TI OMAP family
+provides an interface for MMC, SD, and SDIO types of memory cards.
+
+Required properties:
+- compatible:
+ Should be ti,omap2-hsmmc, for OMAP2/3 controllers
+ Should be ti,omap4-hsmmc, for OMAP4 controllers
+- ti,hwmods: Must be mmcn, n is controller instance starting 1
+- reg : should contain hsmmc registers location and length
+
+Optional properties:
+ti,dual-volt: boolean, supports dual voltage cards
+supply-name-supply: phandle to the regulator device tree node
+supply-name examples are vmmc, vmmc_aux etc
+ti,bus-width: Number of data lines, default assumed is 1 if the
property is missing.
+cd-gpios: GPIOs for card detection
+wp-gpios: GPIOs for write protection
+ti,non-removable: non-removable slot (like eMMC)
+
+Example:
+mmc1: mmc@0x4809c000 {
+compatible = ti,omap4-hsmmc;
+reg =0x4809c000 0x400;
+ti,hwmods = mmc1;
+ti,dual-volt;
+ti,bus-width =4;
+vmmc-supply =vmmc; /* phandle to regulator node */
+ti,non-removable;
+};
diff --git a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
index 35f6dc1..0c93d58 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -26,6 +26,9 @@
#includelinux/platform_device.h
#includelinux/timer.h
#includelinux/clk.h
+#includelinux/of.h
+#includelinux/of_gpio.h
+#includelinux/of_device.h
#includelinux/mmc/host.h
#includelinux/mmc/core.h
#includelinux/mmc/mmc.h
@@ -1718,6 +1721,46 @@ static void omap_hsmmc_debugfs(struct mmc_host
*mmc)
#endif
+#ifdef CONFIG_OF
+static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct
device *dev)
+{
+struct omap_mmc_platform_data *pdata;
+struct device_node *np = dev-of_node;
+u32 bus_width;
+
+pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+if (!pdata)
+return NULL; /* out of memory */
+
+if (of_find_property(np, ti,dual-volt, NULL))
+pdata-controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT;
+
+/* This driver only supports 1 slot */
+pdata-nr_slots = 1;
+pdata-slots[0].switch_pin = of_get_named_gpio(np, cd-gpios, 0);
+pdata-slots[0].gpio_wp = of_get_named_gpio(np, wp-gpios, 0);
+
+if (of_find_property(np, ti,non-removable, NULL)) {
+pdata-slots[0].nonremovable = true;
+pdata-slots[0].no_regulator_off_init = true;
+}
+of_property_read_u32(np, ti,bus-width,bus_width);
+if (bus_width == 4)
+pdata-slots[0].caps |= MMC_CAP_4_BIT_DATA;
+else if (bus_width == 8)
+pdata-slots[0].caps |= MMC_CAP_8_BIT_DATA;
+return pdata;
+}
+#else
+static inline struct omap_mmc_platform_data
+*of_get_hsmmc_pdata(struct device *dev)
+{
+return NULL;
+}
+#endif
+
+static const struct of_device_id omap_mmc_of_match[];
+
static int __init omap_hsmmc_probe(struct platform_device *pdev)
{
struct omap_mmc_platform_data *pdata = pdev-dev.platform_data;
@@ -1725,6 +1768,14 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
struct omap_hsmmc_host *host = NULL;
struct resource *res;
int ret, irq;
+const struct of_device_id *match;
+
+match = of_match_device(omap_mmc_of_match,pdev-dev);
+if (match) {
+pdata = of_get_hsmmc_pdata(pdev-dev);
+if (match-data)
+pdata-reg_offset = *(u16 *)match-data;
+}
if (pdata == NULL) {
dev_err(pdev-dev, Platform Data is missing\n);
@@ -2120,12 +2171,29 @@ static struct dev_pm_ops omap_hsmmc_dev_pm_ops
= {
.runtime_resume = omap_hsmmc_runtime_resume,
};
+#if defined(CONFIG_OF)
+static u16 omap4_reg_offset = 0x100;
+
+static const struct of_device_id omap_mmc_of_match[] = {
Re: [PATCH 4/4] mmc: omap_hsmmc: Simplify init for twl6030 MMC card detect
On Wed, Mar 7, 2012 at 9:12 PM, Chris Ball c...@laptop.org wrote: Hi Balaji, On Wed, Mar 07 2012, T Krishnamoorthy, Balaji wrote: OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset. Addng the offset to platform_device resource structure increments the start address for every insmod operation. MMC command fails on re-insertion as module due incorrect register base. Fix this by updating the ioremap base address only. Signed-off-by: Balaji T K balaj...@ti.com Is this a regression, or has it never worked in mainline? Not a regression introduced in current merge window. It happens on re-insertion of module. will post a patch with $SUBJECT Note: eMMC detection is still failing on resertion due to card vcc power off on rmmod And this? This issue was hidden and uncovered after this fix. This problem is Vcc being powered off without sleep command. 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 1/3] PM / QoS: Make it possible to expose PM QoS latency constraints
Rafael J. Wysocki r...@sisk.pl writes: From: Rafael J. Wysocki r...@sisk.pl A runtime suspend of a device (e.g. an MMC controller) belonging to a power domain or, in a more complicated scenario, a runtime suspend of another device in the same power domain, may cause power to be removed from the entire domain. In that case, the amount of time necessary to runtime-resume the given device (e.g. the MMC controller) is often substantially greater than the time needed to run its driver's runtime resume callback. That may hurt performance in some situations, because user data may need to wait for the device to become operational, so we should make it possible to prevent that from happening. For this reason, introduce a new sysfs attribute for devices, power/pm_qos_latency_us, allowing user space to specify the upper If we're expecting to have more of these knobs, maybe having a pm_qos subdir under power will keep down the clutter in /sys/devices/.../power. This knob would then be /sys/devices/.../power/pm_qos/pm_qos_latency_us. I think 'latency' alone is a bit too vague (wakeup latency? interrupt latency? I think wakeup latency is clearer. Another possibility is resume latency, IMO, that will lead to confusion about whether this field also affects system suspend/resume. That brings up another point: I think the docs should be very clear about how this affects system suspend/resume. From my understanding, it is only intended to affect runtime suspend/resume but I think the docs/comments need to be very clear about this since as you know the overlap between system PM and runtime PM has been a source of confusion. bound of the time necessary to bring the (runtime-suspended) device up after the resume of it has been requested. However, make that attribute appear ony for the devices whose drivers declare support s/ony/only/ for by calling the (new) dev_pm_qos_expose_latency_limit() helper function with the appropriate initial value of the attribute. Yes. I really like the ability to hide/expose this feature, and that the default is that it's hidden. That feature addresses my primary concern about exposing too much to userspace for certain subsystems. Signed-off-by: Rafael J. Wysocki r...@sisk.pl Since I've objected to this kind of feature in the past, I'll just say for the record that I'm fine with selectively exposing this particular knob. Reviewed-by: Kevin Hilman khil...@ti.com Kevin -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] PM / QoS: Make it possible to expose PM QoS latency constraints
On Thu, Mar 08, 2012 at 09:49:24AM -0800, Kevin Hilman wrote: Since I've objected to this kind of feature in the past, I'll just say for the record that I'm fine with selectively exposing this particular knob. Reviewed-by: Kevin Hilman khil...@ti.com I agree with everything Kevin said: Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com signature.asc Description: Digital signature
Re: [PATCH] mmc: omap_hsmmc: Fix Unbalanced pm_runtime_enable warning
Chris, On 03/05/2012 04:09 PM, Kevin Hilman wrote: Tony Lindgrent...@atomide.com writes: mmc: omap_hsmmc: Fix Unbalanced pm_runtime_enable warning Otherwise we can get following warning when re-loading the omap_hsmmc driver module when gpio_twl4030 module is not loaded: omap_hsmmc omap_hsmmc.0: Unbalanced pm_runtime_enable! omap_hsmmc omap_hsmmc.0: Unable to grab MMC CD IRQ omap_hsmmc: probe of omap_hsmmc.0 failed with error -22 Signed-off-by: Tony Lindgrent...@atomide.com --- Kevin, maybe take a look and see if this is correct and fits into your PM branches? Looks right to me: Acked-by: Kevin Hilmankhil...@ti.com But this is a fix to the driver itself, so Chris should queue this in mmc-next. Chris, can you take this one? just checking on this to be sure it can make it for v3.4. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some help for eMMC 8bit SDMA in sdhci_imx for i:MX25
On Tue, Feb 28, 2012 at 08:24:00AM +0100, Ulrich Prinz wrote: Used kernel ist 2.6.39. Could you try to reproduce that on top-of-tree? I don't think it makes much sense to search for problems on such an old kernel. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] PM / QoS: Make it possible to expose PM QoS latency constraints
On Thu, 8 Mar 2012, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: From: Rafael J. Wysocki r...@sisk.pl A runtime suspend of a device (e.g. an MMC controller) belonging to a power domain or, in a more complicated scenario, a runtime suspend of another device in the same power domain, may cause power to be removed from the entire domain. In that case, the amount of time necessary to runtime-resume the given device (e.g. the MMC controller) is often substantially greater than the time needed to run its driver's runtime resume callback. That may hurt performance in some situations, because user data may need to wait for the device to become operational, so we should make it possible to prevent that from happening. For this reason, introduce a new sysfs attribute for devices, power/pm_qos_latency_us, allowing user space to specify the upper If we're expecting to have more of these knobs, maybe having a pm_qos subdir under power will keep down the clutter in /sys/devices/.../power. This knob would then be /sys/devices/.../power/pm_qos/pm_qos_latency_us. If this change does have to be made, I'd propose .../power/qos/latency... removing redundancy. Thanks Guennadi --- 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 1/3] PM / QoS: Make it possible to expose PM QoS latency constraints
On Thursday, March 08, 2012, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: From: Rafael J. Wysocki r...@sisk.pl A runtime suspend of a device (e.g. an MMC controller) belonging to a power domain or, in a more complicated scenario, a runtime suspend of another device in the same power domain, may cause power to be removed from the entire domain. In that case, the amount of time necessary to runtime-resume the given device (e.g. the MMC controller) is often substantially greater than the time needed to run its driver's runtime resume callback. That may hurt performance in some situations, because user data may need to wait for the device to become operational, so we should make it possible to prevent that from happening. For this reason, introduce a new sysfs attribute for devices, power/pm_qos_latency_us, allowing user space to specify the upper If we're expecting to have more of these knobs, maybe having a pm_qos subdir under power will keep down the clutter in /sys/devices/.../power. This knob would then be /sys/devices/.../power/pm_qos/pm_qos_latency_us. I'm not sure how difficult it is to create a subdir in sysfs under something that is not a kobject. Besides, this follows the convention already used by wakeup and runtime PM attributes that don't have their own subdirs (although there may be a number of them in each category). I think 'latency' alone is a bit too vague (wakeup latency? interrupt latency? I think wakeup latency is clearer. Another possibility is resume latency, IMO, that will lead to confusion about whether this field also affects system suspend/resume. I think wakeup latency will lead to more confusion because of the wakeup-related attributes. I'll go for resume_latency if you don't mind. :-) That brings up another point: I think the docs should be very clear about how this affects system suspend/resume. From my understanding, it is only intended to affect runtime suspend/resume That's correct. but I think the docs/comments need to be very clear about this since as you know the overlap between system PM and runtime PM has been a source of confusion. OK bound of the time necessary to bring the (runtime-suspended) device up after the resume of it has been requested. However, make that attribute appear ony for the devices whose drivers declare support s/ony/only/ Yup, thanks. for by calling the (new) dev_pm_qos_expose_latency_limit() helper function with the appropriate initial value of the attribute. Yes. I really like the ability to hide/expose this feature, and that the default is that it's hidden. That feature addresses my primary concern about exposing too much to userspace for certain subsystems. Signed-off-by: Rafael J. Wysocki r...@sisk.pl Since I've objected to this kind of feature in the past, I'll just say for the record that I'm fine with selectively exposing this particular knob. Reviewed-by: Kevin Hilman khil...@ti.com Thanks! I'll update the patches and post a new version shortly. Rafael -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] PM / QoS: Make it possible to expose PM QoS latency constraints
On Thursday, March 08, 2012, Mark Brown wrote: On Thu, Mar 08, 2012 at 09:49:24AM -0800, Kevin Hilman wrote: Since I've objected to this kind of feature in the past, I'll just say for the record that I'm fine with selectively exposing this particular knob. Reviewed-by: Kevin Hilman khil...@ti.com I agree with everything Kevin said: Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com Thanks! Rafael -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] tmio_mmc / PM: Use PM QoS latency constraint
On Thursday, March 08, 2012, Adrian Hunter wrote: On 08/03/12 01:29, Rafael J. Wysocki wrote: From: Rafael J. Wysocki r...@sisk.pl Make tmio_mmc call dev_pm_qos_expose_latency_limit() to expose the PM QoS latency limit to user space and specify the initial value of it as 100 microseconds. Signed-off-by: Rafael J. Wysocki r...@sisk.pl --- drivers/mmc/host/tmio_mmc_pio.c |5 + 1 file changed, 5 insertions(+) Index: linux/drivers/mmc/host/tmio_mmc_pio.c === --- linux.orig/drivers/mmc/host/tmio_mmc_pio.c +++ linux/drivers/mmc/host/tmio_mmc_pio.c @@ -39,6 +39,7 @@ #include linux/module.h #include linux/pagemap.h #include linux/platform_device.h +#include linux/pm_qos.h #include linux/pm_runtime.h #include linux/scatterlist.h #include linux/spinlock.h @@ -955,6 +956,8 @@ int __devinit tmio_mmc_host_probe(struct mmc_add_host(mmc); + dev_pm_qos_expose_latency_limit(pdev-dev, 100); + /* Unmask the IRQs we want to know about */ if (!_host-chan_rx) irq_mask |= TMIO_MASK_READOP; @@ -993,6 +996,8 @@ void tmio_mmc_host_remove(struct tmio_mm || host-mmc-caps MMC_CAP_NONREMOVABLE) pm_runtime_get_sync(pdev-dev); + dev_pm_qos_hide_latency_limit(pdev-dev); Is it really necessary to hide the latency limit before destroying the device? Presumably QoS code could (or does) take care of it. Yes, it can do that. I'll modify patch [1/3] this way. Thanks, Rafael -- 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] sh_mmcif / PM: Use PM QoS latency constraint
On Thursday, March 08, 2012, Mark Brown wrote: On Thu, Mar 08, 2012 at 12:30:28AM +0100, Rafael J. Wysocki wrote: + dev_pm_qos_hide_latency_limit(pdev-dev); + Shouldn't the core be able to cope with cleaning things up by itself here? It seems like it'd be easier/less error prone to do that. Yes, I think this is a fairly reasonable expectation. :-) -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] PM / QoS: Make it possible to expose PM QoS latency constraints
Rafael J. Wysocki r...@sisk.pl writes: On Thursday, March 08, 2012, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: From: Rafael J. Wysocki r...@sisk.pl A runtime suspend of a device (e.g. an MMC controller) belonging to a power domain or, in a more complicated scenario, a runtime suspend of another device in the same power domain, may cause power to be removed from the entire domain. In that case, the amount of time necessary to runtime-resume the given device (e.g. the MMC controller) is often substantially greater than the time needed to run its driver's runtime resume callback. That may hurt performance in some situations, because user data may need to wait for the device to become operational, so we should make it possible to prevent that from happening. For this reason, introduce a new sysfs attribute for devices, power/pm_qos_latency_us, allowing user space to specify the upper If we're expecting to have more of these knobs, maybe having a pm_qos subdir under power will keep down the clutter in /sys/devices/.../power. This knob would then be /sys/devices/.../power/pm_qos/pm_qos_latency_us. I'm not sure how difficult it is to create a subdir in sysfs under something that is not a kobject. Besides, this follows the convention already used by wakeup and runtime PM attributes that don't have their own subdirs (although there may be a number of them in each category). OK I think 'latency' alone is a bit too vague (wakeup latency? interrupt latency? I think wakeup latency is clearer. Another possibility is resume latency, IMO, that will lead to confusion about whether this field also affects system suspend/resume. I think wakeup latency will lead to more confusion because of the wakeup-related attributes. What confusion? All of those are related to device wakeups from some low power state, and so is this proposed latency attribute. So I don't understand the potential confusion. I'll go for resume_latency if you don't mind. :-) Most people think of resume as coming back from system PM. If this is called resume_latency, I would expect confusion about why setting this attribute has no effect on how fast their system returns from system suspend. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] PM / QoS: Make it possible to expose PM QoS latency constraints
On Thursday, March 08, 2012, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: On Thursday, March 08, 2012, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: From: Rafael J. Wysocki r...@sisk.pl A runtime suspend of a device (e.g. an MMC controller) belonging to a power domain or, in a more complicated scenario, a runtime suspend of another device in the same power domain, may cause power to be removed from the entire domain. In that case, the amount of time necessary to runtime-resume the given device (e.g. the MMC controller) is often substantially greater than the time needed to run its driver's runtime resume callback. That may hurt performance in some situations, because user data may need to wait for the device to become operational, so we should make it possible to prevent that from happening. For this reason, introduce a new sysfs attribute for devices, power/pm_qos_latency_us, allowing user space to specify the upper If we're expecting to have more of these knobs, maybe having a pm_qos subdir under power will keep down the clutter in /sys/devices/.../power. This knob would then be /sys/devices/.../power/pm_qos/pm_qos_latency_us. I'm not sure how difficult it is to create a subdir in sysfs under something that is not a kobject. Besides, this follows the convention already used by wakeup and runtime PM attributes that don't have their own subdirs (although there may be a number of them in each category). OK I think 'latency' alone is a bit too vague (wakeup latency? interrupt latency? I think wakeup latency is clearer. Another possibility is resume latency, IMO, that will lead to confusion about whether this field also affects system suspend/resume. I think wakeup latency will lead to more confusion because of the wakeup-related attributes. What confusion? All of those are related to device wakeups from some low power state, and so is this proposed latency attribute. So I don't understand the potential confusion. The word wakeup may refer to many different things, as well as the word resume. :-) I'll go for resume_latency if you don't mind. :-) Most people think of resume as coming back from system PM. If this is called resume_latency, I would expect confusion about why setting this attribute has no effect on how fast their system returns from system suspend. I'll make it depend on CONFIG_PM_RUNTIME _and_ write in the documentation that this attribute has no effect on system-wide suspend/resume. That should be sufficient for the majority of people and if it's not for someone, well, I guess that's really a problem of that person. :-) Thanks, Rafael -- 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
[Update][PATCH 3/3] sh_mmcif / PM: Use PM QoS latency constraint
From: Rafael J. Wysocki r...@sisk.pl Make sh_mmcif call dev_pm_qos_expose_latency_limit() to expose the PM QoS latency limit to user space and specify the initial value of it as 100 microseconds. Signed-off-by: Rafael J. Wysocki r...@sisk.pl --- drivers/mmc/host/sh_mmcif.c |5 + 1 file changed, 5 insertions(+) Index: linux/drivers/mmc/host/sh_mmcif.c === --- linux.orig/drivers/mmc/host/sh_mmcif.c +++ linux/drivers/mmc/host/sh_mmcif.c @@ -56,6 +56,7 @@ #include linux/mmc/sh_mmcif.h #include linux/pagemap.h #include linux/platform_device.h +#include linux/pm_qos.h #include linux/pm_runtime.h #include linux/spinlock.h #include linux/module.h @@ -1346,6 +1347,8 @@ static int __devinit sh_mmcif_probe(stru if (ret 0) goto clean_up5; + dev_pm_qos_expose_latency_limit(pdev-dev, 100); + dev_info(pdev-dev, driver version %s\n, DRIVER_VERSION); dev_dbg(pdev-dev, chip ver H'%04x\n, sh_mmcif_readl(host-addr, MMCIF_CE_VERSION) 0x); @@ -1376,6 +1379,8 @@ static int __devexit sh_mmcif_remove(str host-dying = true; pm_runtime_get_sync(pdev-dev); + dev_pm_qos_hide_latency_limit(pdev-dev); + mmc_remove_host(host-mmc); sh_mmcif_writel(host-addr, MMCIF_CE_INT_MASK, MASK_ALL); -- 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
[Update][PATCH 0/3] PM: Make it possible to expose PM QoS latency constraints
Hi all, On Thursday, March 08, 2012, Rafael J. Wysocki wrote: On Sunday, March 04, 2012, Rafael J. Wysocki wrote: On Sunday, March 04, 2012, Rafael J. Wysocki wrote: The goal of this patchset is to allow user space to control the responsiveness of the MMC stack related to runtime power management. Namely, on systems that contain power domains, the time necessary to bring an MMC host up after it has been runtime-suspended may depend not only on the MMC core and host driver, but also on the platform and other devices in the same power domain(s) that contain(s) the MMC host. Although that obviously may influence the MMC performance, currently, there is no way to control it through the MMC subsystem. Moreover, the only available way to control it at all is by using PM QoS latency requests, so it is necessary to add some kind of support for that to MMC. Patch [1/3] adds PM QoS-related fields to struct mmc_host and introduces a new sysfs attribute for MMC hosts, pm_latency_limit_ms, allowing user space to influence the MMC host's runtime PM via PM QoS. Whether or not this attribute will be created (and PM QoS will be used for the given host) depends on the host driver, so host drivers that don't (plan) to support PM QoS don't need to do anything about that. Patches [2/3] and [3/3] add the corresponding host driver bits to the tmio_mmc and sh_mmcif drivers, respectively. After posting the patches I noticed that the changelog of patch [1/3] and the documentation of the new sysfs attribute were not 100% accurate, because the PM QoS request really applies to the time between a resume request and the moment the device is operational again and not the time from runtime suspend (the latter would imply some kind of autoresume mechanism, which isn't there). I also thought it would be cleaner to allocate the val and attr fields along with the request, because in the previous version of the patchset they weren't used when req was NULL, resulting in (a little) wasted memory. Updated patches follow. Taking the feedback so far into account, I decided to move the exposing of the PM QoS latency limit from the MMC layer to the PM core sysfs code, so that every driver (not only MMC host drivers) can use it. New patches follow, details are in the changelogs: [1/3] - Make it possible to expose PM QoS latency constraints [2/3] - Make tmio_mmc use the new interface. [3/3] - Make sh_mmcif use the new interface. Taking the latest feedback into account I reworked patch [1/3] in the following way: - The new attribute is now called pm_qos_resume_latency_us. - It depends on CONFIG_PM_RUNTIME and the documentation says it doesn't has an effect on system-wide suspend/resume. - The new attribute is hidden automatically by dev_pm_qos_constraints_destroy() if still exposed at this point, so the drivers that exposed it don't have to hide it explicitly on removal (although they still can do that). However, I still think that it is appropriate for the MMC drivers to hide it on _their_ removal, because otherwise the device would be left with the meaningless attribute after that point. So, I haven't modified patches [2-3/3], but they follow for completness. I've added the Reviewed-by tags from Kevin and Mark to patch [1/3], becuase the changes made generally follow their suggestions. Thanks, Rafael -- 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
[Update][PATCH 2/3] tmio_mmc / PM: Use PM QoS latency constraint
From: Rafael J. Wysocki r...@sisk.pl Make tmio_mmc call dev_pm_qos_expose_latency_limit() to expose the PM QoS latency limit to user space and specify the initial value of it as 100 microseconds. Signed-off-by: Rafael J. Wysocki r...@sisk.pl --- drivers/mmc/host/tmio_mmc_pio.c |5 + 1 file changed, 5 insertions(+) Index: linux/drivers/mmc/host/tmio_mmc_pio.c === --- linux.orig/drivers/mmc/host/tmio_mmc_pio.c +++ linux/drivers/mmc/host/tmio_mmc_pio.c @@ -39,6 +39,7 @@ #include linux/module.h #include linux/pagemap.h #include linux/platform_device.h +#include linux/pm_qos.h #include linux/pm_runtime.h #include linux/scatterlist.h #include linux/spinlock.h @@ -955,6 +956,8 @@ int __devinit tmio_mmc_host_probe(struct mmc_add_host(mmc); + dev_pm_qos_expose_latency_limit(pdev-dev, 100); + /* Unmask the IRQs we want to know about */ if (!_host-chan_rx) irq_mask |= TMIO_MASK_READOP; @@ -993,6 +996,8 @@ void tmio_mmc_host_remove(struct tmio_mm || host-mmc-caps MMC_CAP_NONREMOVABLE) pm_runtime_get_sync(pdev-dev); + dev_pm_qos_hide_latency_limit(pdev-dev); + mmc_remove_host(host-mmc); cancel_work_sync(host-done); cancel_delayed_work_sync(host-delayed_reset_work); -- 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
[Update][PATCH 1/3] PM / QoS: Make it possible to expose PM QoS latency constraints
From: Rafael J. Wysocki r...@sisk.pl
A runtime suspend of a device (e.g. an MMC controller) belonging to
a power domain or, in a more complicated scenario, a runtime suspend
of another device in the same power domain, may cause power to be
removed from the entire domain. In that case, the amount of time
necessary to runtime-resume the given device (e.g. the MMC
controller) is often substantially greater than the time needed to
run its driver's runtime resume callback. That may hurt performance
in some situations, because user data may need to wait for the
device to become operational, so we should make it possible to
prevent that from happening.
For this reason, introduce a new sysfs attribute for devices,
power/pm_qos_resume_latency_us, allowing user space to specify the
upper bound of the time necessary to bring the (runtime-suspended)
device up after the resume of it has been requested. However, make
that attribute appear only for the devices whose drivers declare
support for it by calling the (new) dev_pm_qos_expose_latency_limit()
helper function with the appropriate initial value of the attribute.
Signed-off-by: Rafael J. Wysocki r...@sisk.pl
Reviewed-by: Kevin Hilman khil...@ti.com
Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
Documentation/ABI/testing/sysfs-devices-power | 18 +++
drivers/base/power/power.h|4 +
drivers/base/power/qos.c | 62 ++
drivers/base/power/sysfs.c| 47 +++
include/linux/pm.h|1
include/linux/pm_qos.h|9 +++
6 files changed, 141 insertions(+)
Index: linux/include/linux/pm.h
===
--- linux.orig/include/linux/pm.h
+++ linux/include/linux/pm.h
@@ -546,6 +546,7 @@ struct dev_pm_info {
unsigned long accounting_timestamp;
ktime_t suspend_time;
s64 max_time_suspended_ns;
+ struct dev_pm_qos_request *pq_req;
#endif
struct pm_subsys_data *subsys_data; /* Owned by the subsystem. */
struct pm_qos_constraints *constraints;
Index: linux/drivers/base/power/sysfs.c
===
--- linux.orig/drivers/base/power/sysfs.c
+++ linux/drivers/base/power/sysfs.c
@@ -5,6 +5,7 @@
#include linux/device.h
#include linux/string.h
#include linux/export.h
+#include linux/pm_qos.h
#include linux/pm_runtime.h
#include linux/atomic.h
#include linux/jiffies.h
@@ -217,6 +218,31 @@ static ssize_t autosuspend_delay_ms_stor
static DEVICE_ATTR(autosuspend_delay_ms, 0644, autosuspend_delay_ms_show,
autosuspend_delay_ms_store);
+static ssize_t pm_qos_latency_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, %d\n, dev-power.pq_req-node.prio);
+}
+
+static ssize_t pm_qos_latency_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t n)
+{
+ s32 value;
+ int ret;
+
+ if (kstrtos32(buf, 0, value))
+ return -EINVAL;
+
+ if (value 0)
+ return -EINVAL;
+
+ ret = dev_pm_qos_update_request(dev-power.pq_req, value);
+ return ret 0 ? ret : n;
+}
+
+static DEVICE_ATTR(pm_qos_resume_latency_us, 0644,
+ pm_qos_latency_show, pm_qos_latency_store);
#endif /* CONFIG_PM_RUNTIME */
#ifdef CONFIG_PM_SLEEP
@@ -510,6 +536,17 @@ static struct attribute_group pm_runtime
.attrs = runtime_attrs,
};
+static struct attribute *pm_qos_attrs[] = {
+#ifdef CONFIG_PM_RUNTIME
+ dev_attr_pm_qos_resume_latency_us.attr,
+#endif /* CONFIG_PM_RUNTIME */
+ NULL,
+};
+static struct attribute_group pm_qos_attr_group = {
+ .name = power_group_name,
+ .attrs = pm_qos_attrs,
+};
+
int dpm_sysfs_add(struct device *dev)
{
int rc;
@@ -550,6 +587,16 @@ void wakeup_sysfs_remove(struct device *
sysfs_unmerge_group(dev-kobj, pm_wakeup_attr_group);
}
+int pm_qos_sysfs_add(struct device *dev)
+{
+ return sysfs_merge_group(dev-kobj, pm_qos_attr_group);
+}
+
+void pm_qos_sysfs_remove(struct device *dev)
+{
+ sysfs_unmerge_group(dev-kobj, pm_qos_attr_group);
+}
+
void rpm_sysfs_remove(struct device *dev)
{
sysfs_unmerge_group(dev-kobj, pm_runtime_attr_group);
Index: linux/drivers/base/power/power.h
===
--- linux.orig/drivers/base/power/power.h
+++ linux/drivers/base/power/power.h
@@ -71,6 +71,8 @@ extern void dpm_sysfs_remove(struct devi
extern void rpm_sysfs_remove(struct device *dev);
extern int wakeup_sysfs_add(struct device *dev);
extern void wakeup_sysfs_remove(struct device *dev);
+extern int pm_qos_sysfs_add(struct
Re: [PATCH 1/3] PM / QoS: Make it possible to expose PM QoS latency constraints
Rafael J. Wysocki r...@sisk.pl writes: On Thursday, March 08, 2012, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: On Thursday, March 08, 2012, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: From: Rafael J. Wysocki r...@sisk.pl A runtime suspend of a device (e.g. an MMC controller) belonging to a power domain or, in a more complicated scenario, a runtime suspend of another device in the same power domain, may cause power to be removed from the entire domain. In that case, the amount of time necessary to runtime-resume the given device (e.g. the MMC controller) is often substantially greater than the time needed to run its driver's runtime resume callback. That may hurt performance in some situations, because user data may need to wait for the device to become operational, so we should make it possible to prevent that from happening. For this reason, introduce a new sysfs attribute for devices, power/pm_qos_latency_us, allowing user space to specify the upper If we're expecting to have more of these knobs, maybe having a pm_qos subdir under power will keep down the clutter in /sys/devices/.../power. This knob would then be /sys/devices/.../power/pm_qos/pm_qos_latency_us. I'm not sure how difficult it is to create a subdir in sysfs under something that is not a kobject. Besides, this follows the convention already used by wakeup and runtime PM attributes that don't have their own subdirs (although there may be a number of them in each category). OK I think 'latency' alone is a bit too vague (wakeup latency? interrupt latency? I think wakeup latency is clearer. Another possibility is resume latency, IMO, that will lead to confusion about whether this field also affects system suspend/resume. I think wakeup latency will lead to more confusion because of the wakeup-related attributes. What confusion? All of those are related to device wakeups from some low power state, and so is this proposed latency attribute. So I don't understand the potential confusion. The word wakeup may refer to many different things, as well as the word resume. :-) Yes, but what's the confusion in this case? IMO, The existing /sys/devices/.../power/wakeup* meaning is the same meaning as as for the wakeup latency in this patch, so I don't understand where the confusion would be. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] PM / QoS: Make it possible to expose PM QoS latency constraints
On Friday, March 09, 2012, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: On Thursday, March 08, 2012, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: On Thursday, March 08, 2012, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: From: Rafael J. Wysocki r...@sisk.pl A runtime suspend of a device (e.g. an MMC controller) belonging to a power domain or, in a more complicated scenario, a runtime suspend of another device in the same power domain, may cause power to be removed from the entire domain. In that case, the amount of time necessary to runtime-resume the given device (e.g. the MMC controller) is often substantially greater than the time needed to run its driver's runtime resume callback. That may hurt performance in some situations, because user data may need to wait for the device to become operational, so we should make it possible to prevent that from happening. For this reason, introduce a new sysfs attribute for devices, power/pm_qos_latency_us, allowing user space to specify the upper If we're expecting to have more of these knobs, maybe having a pm_qos subdir under power will keep down the clutter in /sys/devices/.../power. This knob would then be /sys/devices/.../power/pm_qos/pm_qos_latency_us. I'm not sure how difficult it is to create a subdir in sysfs under something that is not a kobject. Besides, this follows the convention already used by wakeup and runtime PM attributes that don't have their own subdirs (although there may be a number of them in each category). OK I think 'latency' alone is a bit too vague (wakeup latency? interrupt latency? I think wakeup latency is clearer. Another possibility is resume latency, IMO, that will lead to confusion about whether this field also affects system suspend/resume. I think wakeup latency will lead to more confusion because of the wakeup-related attributes. What confusion? All of those are related to device wakeups from some low power state, and so is this proposed latency attribute. So I don't understand the potential confusion. The word wakeup may refer to many different things, as well as the word resume. :-) Yes, but what's the confusion in this case? IMO, The existing /sys/devices/.../power/wakeup* meaning is the same meaning as as for the wakeup latency in this patch, No, it is not. They refer to system wakeup. :-) so I don't understand where the confusion would be. See above. ;-) Rafael -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] PM / QoS: Make it possible to expose PM QoS latency constraints
Rafael J. Wysocki r...@sisk.pl writes: On Friday, March 09, 2012, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: On Thursday, March 08, 2012, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: On Thursday, March 08, 2012, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: From: Rafael J. Wysocki r...@sisk.pl A runtime suspend of a device (e.g. an MMC controller) belonging to a power domain or, in a more complicated scenario, a runtime suspend of another device in the same power domain, may cause power to be removed from the entire domain. In that case, the amount of time necessary to runtime-resume the given device (e.g. the MMC controller) is often substantially greater than the time needed to run its driver's runtime resume callback. That may hurt performance in some situations, because user data may need to wait for the device to become operational, so we should make it possible to prevent that from happening. For this reason, introduce a new sysfs attribute for devices, power/pm_qos_latency_us, allowing user space to specify the upper If we're expecting to have more of these knobs, maybe having a pm_qos subdir under power will keep down the clutter in /sys/devices/.../power. This knob would then be /sys/devices/.../power/pm_qos/pm_qos_latency_us. I'm not sure how difficult it is to create a subdir in sysfs under something that is not a kobject. Besides, this follows the convention already used by wakeup and runtime PM attributes that don't have their own subdirs (although there may be a number of them in each category). OK I think 'latency' alone is a bit too vague (wakeup latency? interrupt latency? I think wakeup latency is clearer. Another possibility is resume latency, IMO, that will lead to confusion about whether this field also affects system suspend/resume. I think wakeup latency will lead to more confusion because of the wakeup-related attributes. What confusion? All of those are related to device wakeups from some low power state, and so is this proposed latency attribute. So I don't understand the potential confusion. The word wakeup may refer to many different things, as well as the word resume. :-) Yes, but what's the confusion in this case? IMO, The existing /sys/devices/.../power/wakeup* meaning is the same meaning as as for the wakeup latency in this patch, No, it is not. They refer to system wakeup. :-) OK, now I'm confused (again). I thought those could be used for runtime PM wakeups also. At least I was planning on using them for any kind of wakeup. so I don't understand where the confusion would be. See above. ;-) Sheesh, this is getting ugly. So wakeup* attributes refer to system resume and resume* attribues refer to runtime PM. Yuck. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] gpiolib: Add gpiochip_find_by_name() and gpio_find_by_chip_name()
On Fri, 2 Mar 2012 11:06:15 -0800, Tony Lindgren t...@atomide.com wrote:
* Grant Likely grant.lik...@secretlab.ca [120302 10:16]:
On Fri, 2 Mar 2012 10:08:48 -0800, Tony Lindgren t...@atomide.com wrote:
* Tony Lindgren t...@atomide.com [120302 08:31]:
* Grant Likely grant.lik...@secretlab.ca [120302 01:00]:
On Thu, 01 Mar 2012 10:55:24 -0800, Tony Lindgren t...@atomide.com
wrote:
+
+/**
+ * gpiochip_find_by_name() - iterator for locating a gpio_chip by
name
+ * @name: name of the gpio_chip
+ *
+ * Similar to bus_find_device_by_name. It returns a reference to
the
+ * first gpio_chip with matching name. It ignores NULL and empty
names.
+ * If you need to do something more complex, then use
gpiochip_find.
+ */
+struct gpio_chip *gpiochip_find_by_name(const char *name)
+{
+ if (!name || !strcmp(name, ))
+ return NULL;
+
+ return gpiochip_find((void *)name, match_name);
Nasty cast. Can the signature for gpiochip_find be changed to accept
a (const void *)?
I think so, this too comes from the bus code.
Looks like it can't be const as of_node_to_gpiochip uses it with
a struct device_node * that for of_get_named_gpio_flags comes from
of_parse_phandle_with_args.
Really? It sees to work fine here:
Hmm right you are. I must have missed adding the const to
of_gpiochip_is_match, that's good news :)
Want to do that as a separate patch or want me to fold it in?
I've got it as a separate commit in my gpio/next branch.
g.
---
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d773540..e633a2a 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1152,8 +1152,9 @@ EXPORT_SYMBOL_GPL(gpiochip_remove);
* non-zero, this function will return to the caller and not iterate over
any
* more gpio_chips.
*/
-struct gpio_chip *gpiochip_find(void *data,
- int (*match)(struct gpio_chip *chip, void
*data))
+struct gpio_chip *gpiochip_find(const void *data,
+ int (*match)(struct gpio_chip *chip,
+const void *data))
{
struct gpio_chip *chip = NULL;
unsigned long flags;
diff --git a/drivers/of/gpio.c b/drivers/of/gpio.c
index e034b38..bba8121 100644
--- a/drivers/of/gpio.c
+++ b/drivers/of/gpio.c
@@ -229,7 +229,7 @@ void of_gpiochip_remove(struct gpio_chip *chip)
}
/* Private function for resolving node pointer to gpio_chip */
-static int of_gpiochip_is_match(struct gpio_chip *chip, void *data)
+static int of_gpiochip_is_match(struct gpio_chip *chip, const void *data)
{
return chip-of_node == data;
}
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 1ff4e22..5f52690 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -142,9 +142,9 @@ extern int __must_check gpiochip_reserve(int start, int
ngpio);
/* add/remove chips */
extern int gpiochip_add(struct gpio_chip *chip);
extern int __must_check gpiochip_remove(struct gpio_chip *chip);
-extern struct gpio_chip *gpiochip_find(void *data,
+extern struct gpio_chip *gpiochip_find(const void *data,
int (*match)(struct gpio_chip *chip,
-void *data));
+const void *data));
/* Always use the library code for GPIO management calls,
--
email sent from notmuch.vim plugin
--
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 0/4] mmc: sdhci-s3c: use the sdhci-pltfm.c and move the header file
On 03/08/2012 08:01 PM, Mark Brown wrote: On Thu, Mar 08, 2012 at 02:35:53PM +0900, Jaehoon Chung wrote: So i think no problem that removed #include plat/regs-sdhci.h. is it wrong? Just touching the setup-gpio- files is problem? It should be fine, like I say I didn't really read the patches in enough detail as the diffstat set off alarm bells. If you have any opinions, let me know. I believe that these patches can be maintain more efficiently for eMMC Best Regards, Jaehoon Chung -- 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/4] gpiolib: Add gpiochip_find_by_name() and gpio_find_by_chip_name()
* Grant Likely grant.lik...@secretlab.ca [120308 17:08]:
On Fri, 2 Mar 2012 11:06:15 -0800, Tony Lindgren t...@atomide.com wrote:
Want to do that as a separate patch or want me to fold it in?
I've got it as a separate commit in my gpio/next branch.
OK great, below is my patch updated against gpio/next if you
want to pick it up.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Fri, 2 Mar 2012 11:30:23 -0800
Subject: [PATCH] gpiolib: Add gpiochip_find_by_name() and
gpio_find_by_chip_name()
Currently there is no way for drivers to request a GPIO on a particular
gpio chip using platform data. This makes it hard to support multiple
GPIO controllers with platform driver with dynamic GPIO and interrupt
numbering, such as with CONFIG_SPARSE_IRQ.
Let's make it easier for platform device drivers to find GPIOs on a
specific gpio_chip by adding two functions: gpiochip_find_by_name()
and gpio_find_by_chip_name().
Note that these functions should not be used with device tree as
pointed out by Grant Likely grant.lik...@secretlab.ca as the names
are instantiated from device tree.
As gpiochip_find() is already exported, we may as well export
gpiochip_find_by_name() too.
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Linus Walleij linus.wall...@stericsson.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1178,6 +1178,51 @@ struct gpio_chip *gpiochip_find(const void *data,
}
EXPORT_SYMBOL_GPL(gpiochip_find);
+static int gpiochip_match_name(struct gpio_chip *chip, const void *name)
+{
+ return !strcmp(name, chip-label);
+}
+
+/**
+ * gpiochip_find_by_name() - iterator for locating a gpio_chip by name
+ * @name: name of the gpio_chip
+ *
+ * Similar to bus_find_device_by_name. It returns a reference to the
+ * first gpio_chip with matching name. It ignores NULL and empty names.
+ * If you need to do something more complex, then use gpiochip_find.
+ */
+struct gpio_chip *gpiochip_find_by_name(const char *name)
+{
+ if (!name || !strcmp(name, ))
+ return NULL;
+
+ return gpiochip_find(name, gpiochip_match_name);
+}
+EXPORT_SYMBOL_GPL(gpiochip_find_by_name);
+
+/**
+ * gpio_find_by_chip_name() - find a gpio on a specific gpio_chip
+ * @chip_name: name of the gpio_chip
+ * @gpio_offset: offset of the gpio on the gpio_chip
+ *
+ * Note that gpiochip_find_by_name returns the first matching
+ * gpio_chip name. For more complex matching, see gpio_find.
+ */
+int gpio_find_by_chip_name(const char *chip_name, unsigned gpio_offset)
+{
+ struct gpio_chip *chip;
+ int gpio;
+
+ chip = gpiochip_find_by_name(chip_name);
+ if (!chip)
+ return -ENODEV;
+
+ gpio = chip-base + gpio_offset;
+
+ return gpio;
+}
+EXPORT_SYMBOL_GPL(gpio_find_by_chip_name);
+
/* These optional allocation calls help prevent drivers from stomping
* on each other, and help provide better diagnostics in debugfs.
* They're called even less than the set direction calls.
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -145,7 +145,8 @@ extern int __must_check gpiochip_remove(struct gpio_chip
*chip);
extern struct gpio_chip *gpiochip_find(const void *data,
int (*match)(struct gpio_chip *chip,
const void *data));
-
+extern struct gpio_chip *gpiochip_find_by_name(const char *name);
+extern int gpio_find_by_chip_name(const char *chip_name, unsigned gpio_offset);
/* Always use the library code for GPIO management calls,
* or when sleeping may be involved.
--
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 00/10 v3] mmc: tmio/sdhi: hotplug PM
Hi Guennadi, On Thu, Feb 09 2012, Guennadi Liakhovetski wrote: This is v3 of a patch series, that uses the recently committed generic GPIO card hotplug handler, fixes minor PM issues, adds some cosmetic clean up. The series applies on top of mmc-next of 09 Feb. 2012. Guennadi Liakhovetski (10): mmc: simplify mmc_cd_gpio_request() by removing two parameters mmc: tmio: calculate the native hotplug condition only once mmc: tmio_mmc: support the generic MMC GPIO card hotplug helper mmc: sh_mobile_sdhi: pass card hotplug GPIO number to TMIO MMC ARM: mach-shmobile: convert mackerel to use the generic MMC GPIO hotplug helper ARM: mach-shmobile: convert ag5evm to use the generic MMC GPIO hotplug helper mmc: tmio_mmc: power status flag doesn't have to be exposed in platform data mmc: tmio_mmc: remove unused sdio_irq_enabled flag 3C mmc: sh_mobile_sdhi: do not manage PM clocks manually mmc: tmio: cosmetic: prettify the tmio_mmc_set_ios() function Looks like you didn't get any ACKs for these, and the ARM patches no longer apply -- would you like me to take all but the two ARM patches and leave those to you? (Does that result in working systems?) 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] drivers/mmc/host/sdhci-s3c.c: use devm_ functions
Hi Julia, On Sat, Feb 18 2012, Julia Lawall wrote: From: Julia Lawall julia.law...@lip6.fr The various devm_ functions allocate memory that is released when a driver detaches. This patch uses these functions for data that is allocated in the probe function of a platform device and is only freed in the remove function. By using devm_ioremap, it also removes a potential memory leak, because there was no call to iounmap in the probe function. The call to platform_get_resource was moved just to make it closer to the place where its result it used. Signed-off-by: Julia Lawall julia.law...@lip6.fr Thanks very much, pushed to mmc-next for 3.4. - 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: tmio_mmc: do not enable card hotplug interrupts, if unused
Hi Guennadi, On Wed, Feb 22 2012, Guennadi Liakhovetski wrote: If TMIO MMC is used in polling mode, or the card is non-removable, or card-detection is performed, using an external interrupt, there is no need to enable controller native card hotplug interrupts. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Thanks, pushed to mmc-next for 3.4. - 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/spear: add pm callbacks to support hibernation
Hi Viresh,
On Fri, Feb 24 2012, Viresh Kumar wrote:
From: Shiraz Hashim shiraz.has...@st.com
Signed-off-by: Shiraz Hashim shiraz.has...@st.com
---
drivers/mmc/host/sdhci-spear.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/sdhci-spear.c b/drivers/mmc/host/sdhci-spear.c
index b7f8b33..6dfa82e 100644
--- a/drivers/mmc/host/sdhci-spear.c
+++ b/drivers/mmc/host/sdhci-spear.c
@@ -300,20 +300,15 @@ static int sdhci_resume(struct device *dev)
return sdhci_resume_host(host);
}
-
-const struct dev_pm_ops sdhci_pm_ops = {
- .suspend= sdhci_suspend,
- .resume = sdhci_resume,
-};
#endif
+static SIMPLE_DEV_PM_OPS(sdhci_pm_ops, sdhci_suspend, sdhci_resume);
+
static struct platform_driver sdhci_driver = {
.driver = {
.name = sdhci,
.owner = THIS_MODULE,
-#ifdef CONFIG_PM
.pm = sdhci_pm_ops,
-#endif
},
.probe = sdhci_probe,
.remove = __devexit_p(sdhci_remove),
Thanks, pushed to mmc-next for 3.4.
- 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 V2 1/1] mmc: start removing enable / disable API
Hi Adrian, On Wed, Feb 29 2012, Adrian Hunter wrote: Most parts of the enable / disable API are no longer used and can be removed. Cc: Rajendra Nayak rna...@ti.com Cc: Venkatraman S svenk...@ti.com Cc: Kukjin Kim kgene@samsung.com Cc: Thomas Abraham thomas.abra...@linaro.org Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Sekhar Nori nsek...@ti.com Cc: Kevin Hilman khil...@ti.com Signed-off-by: Adrian Hunter adrian.hun...@intel.com Thanks very much, pushed to mmc-next for 3.4 (with Tested-by from Venkatraman and Jaehoon). - 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: omap_hsmmc: set dto to 14 for all devices
Hi Chase, On Thu, Mar 01 2012, Chase Maupin wrote: * With certain SD cards timeouts like the following have been seen due to an improper calculation of the dto value: mmcblk0: error -110 transferring data, sector 4126233, nr 8, card status 0xc00 * By removing the dto calculation and setting the timeout value to the maximum specified by the SD card specification part A2 section 2.2.15 these timeouts can be avoided. * This change has been used by beagleboard users as well as the Texas Instruments SDK without a negative impact. * There are multiple discussion threads about this but the most relevant ones are: * http://talk.maemo.org/showthread.php?p=1000707#post1000707 * http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42213.html * Original proposal for this fix was done by Sukumar Ghoral of Texas Instruments * Tested using a Texas Instruments AM335x EVM Signed-off-by: Chase Maupin chase.mau...@ti.com Thanks, I've pushed this to mmc-next for 3.4. (With a trivial indentation fix, below.) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 82b400793..9d4ce1c 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1360,7 +1360,7 @@ static void set_data_timeout(struct omap_hsmmc_host *host) if (clkd == 0) clkd = 1; -/* Use the maximum timeout value allowed in the standard of 14 or 0xE */ + /* Use the maximum timeout value allowed in the standard of 14 or 0xE */ dto = 14; reg = ~DTO_MASK; - 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 V2] mmc: core: Clean up after mmc_pre_req if card was removed
Hi Ulf, On Mon, Mar 05 2012, Ulf Hansson wrote: Make sure mmc_start_req cancel the prepared job, if the request was prevented to be started due to the card has been removed. This bug was introduced in commit: mmc: allow upper layers to know immediately if card has been removed Signed-off-by: Ulf Hansson ulf.hans...@stericsson.com Reviewed-by: Per Forlin per.for...@stericsson.com Thanks, pushed to mmc-next for 3.4 with Jaehoon's Tested-by. - 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: omap_hsmmc: Fix Unbalanced pm_runtime_enable warning
Hi, On Thu, Mar 08 2012, Kevin Hilman wrote: Tony Lindgrent...@atomide.com writes: mmc: omap_hsmmc: Fix Unbalanced pm_runtime_enable warning Otherwise we can get following warning when re-loading the omap_hsmmc driver module when gpio_twl4030 module is not loaded: omap_hsmmc omap_hsmmc.0: Unbalanced pm_runtime_enable! omap_hsmmc omap_hsmmc.0: Unable to grab MMC CD IRQ omap_hsmmc: probe of omap_hsmmc.0 failed with error -22 Signed-off-by: Tony Lindgrent...@atomide.com --- Kevin, maybe take a look and see if this is correct and fits into your PM branches? Looks right to me: Acked-by: Kevin Hilmankhil...@ti.com But this is a fix to the driver itself, so Chris should queue this in mmc-next. Chris, can you take this one? just checking on this to be sure it can make it for v3.4. Thanks, I've pushed this to mmc-next for 3.4 now. - 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 v2 1/1] mmc: core: hs200 fixes
Hi,
On Tue, Mar 06 2012, Girish K S wrote:
On 6 March 2012 17:59, Subhash Jadavani subha...@codeaurora.org wrote:
This patch fixes following issues when HS200 is enabled:
1. If executing_tuning() host ops is called without mmc_host_clk_hold(),
card clocks might get turned off (if MMC_CLK_GATING is enabled)
while execute_tuning() is in progress. So this patch makes sure
that execute_tuning() is called with mmc_host_clk_hold().
2. If host timing mode is set to HS200 mode, there should not be
any communication with the card until execute_tuning() is completed.
But there is a chance that CMD6 might be sent to enable set HPI_EN
(of HPI_MGMT field in EXT_CSD) before execute_tuning() is called.
So this patch moves this operation after execute_tuning() is completed.
Signed-off-by: Subhash Jadavani subha...@codeaurora.org
---
drivers/mmc/core/mmc.c | 38 +-
1 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index a480663..d36d2c4 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1030,22 +1030,6 @@ static int mmc_init_card(struct mmc_host
*host, u32 ocr,
}
/*
- * Enable HPI feature (if supported)
- */
- if (card-ext_csd.hpi) {
- err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
- EXT_CSD_HPI_MGMT, 1, 0);
- if (err err != -EBADMSG)
- goto free_card;
- if (err) {
- pr_warning(%s: Enabling HPI failed\n,
- mmc_hostname(card-host));
- err = 0;
- } else
- card-ext_csd.hpi_en = 1;
- }
-
- /*
* Compute bus speed.
*/
max_dtr = (unsigned int)-1;
@@ -1094,9 +1078,12 @@ static int mmc_init_card(struct mmc_host
*host, u32 ocr,
* 4. execute tuning for HS200
*/
if ((host-caps2 MMC_CAP2_HS200)
- card-host-ops-execute_tuning)
+ card-host-ops-execute_tuning) {
+ mmc_host_clk_hold(card-host);
err = card-host-ops-execute_tuning(card-host,
MMC_SEND_TUNING_BLOCK_HS200);
+ mmc_host_clk_release(card-host);
+ }
if (err) {
pr_warning(%s: tuning execution failed\n,
mmc_hostname(card-host));
@@ -1216,6 +1203,23 @@ static int mmc_init_card(struct mmc_host
*host, u32 ocr,
}
/*
+ * Enable HPI feature (if supported)
+ */
+ if (card-ext_csd.hpi) {
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+ EXT_CSD_HPI_MGMT, 1,
+ card-ext_csd.generic_cmd6_time);
+ if (err err != -EBADMSG)
+ goto free_card;
+ if (err) {
+ pr_warning(%s: Enabling HPI failed\n,
+ mmc_hostname(card-host));
+ err = 0;
+ } else
+ card-ext_csd.hpi_en = 1;
+ }
+
+ /*
* If cache size is higher than 0, this indicates
* the existence of cache and it can be turned on.
*/
Reviewed-By: girish.shivananja...@linaro.org
Thanks, pushed to mmc-next for 3.4.
- 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 RESEND] mmc: sh_mmcif: fix MMC_GEN_CMD setting
Hi, On Wed, Mar 07 2012, Shimoda, Yoshihiro wrote: The MMC_GEN_CMD (CMD56) doesn't need to check busy signal. So, the patch fixes the setting. Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com --- drivers/mmc/host/sh_mmcif.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c index 4a2c5b2..e8b70e3 100644 --- a/drivers/mmc/host/sh_mmcif.c +++ b/drivers/mmc/host/sh_mmcif.c @@ -745,7 +745,6 @@ static u32 sh_mmcif_set_cmd(struct sh_mmcif_host *host, case MMC_SET_WRITE_PROT: case MMC_CLR_WRITE_PROT: case MMC_ERASE: - case MMC_GEN_CMD: tmp |= CMD_SET_RBSY; break; } @@ -828,7 +827,6 @@ static void sh_mmcif_start_cmd(struct sh_mmcif_host *host, case MMC_SET_WRITE_PROT: case MMC_CLR_WRITE_PROT: case MMC_ERASE: - case MMC_GEN_CMD: mask = MASK_START_CMD | MASK_MRBSYE; break; default: Thanks, pushed to mmc-next for 3.4. - 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 v2 0/6] mmc: omap_hsmmc: Clean up use/abuse of pdev-id
Hi, On Thu, Mar 08 2012, Rajendra Nayak wrote: There's just one other cleanup patch here [1] to convert all pr_* prints in the driver to dev_*. Would be great if you can pick that as well. Thanks, Rajendra [1] http://marc.info/?l=linux-mmcm=132999677405098w=3 Thanks, I've pushed this to mmc-next for 3.4 now too. - 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 1/2] mmc: sdhci-s3c: Use CONFIG_PM_SLEEP to ifdef system suspend
Hi Mark,
On Fri, Mar 02 2012, Mark Brown wrote:
This matches current best practice as one can have runtime PM enabled
without system sleep and CONFIG_PM is defined for both.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/mmc/host/sdhci-s3c.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index ea0767e..46152d6 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -22,6 +22,7 @@
#include linux/module.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/pm.h
#include linux/mmc/host.h
@@ -807,8 +808,7 @@ static int __devexit sdhci_s3c_remove(struct
platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
-
+#ifdef CONFIG_PM_SLEEP
static int sdhci_s3c_suspend(struct device *dev)
{
struct sdhci_host *host = dev_get_drvdata(dev);
@@ -822,10 +822,11 @@ static int sdhci_s3c_resume(struct device *dev)
return sdhci_resume_host(host);
}
+#endif
+#ifdef CONFIG_PM
static const struct dev_pm_ops sdhci_s3c_pmops = {
- .suspend= sdhci_s3c_suspend,
- .resume = sdhci_s3c_resume,
+ SET_SYSTEM_SLEEP_PM_OPS(sdhci_s3c_suspend, sdhci_s3c_resume)
};
#define SDHCI_S3C_PMOPS (sdhci_s3c_pmops)
Thanks, pushed to mmc-next for 3.4 with Jaehoon's ACK.
- 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: sdhci-s3c: Enable runtime power management
Hi Mark,
On Fri, Mar 02 2012, Mark Brown wrote:
Since most of the work is already done by the core we just need to add
runtime suspend methods and tell the PM core that runtime PM is enabled
for this device.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/mmc/host/sdhci-s3c.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 46152d6..6926ac9 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -23,6 +23,7 @@
#include linux/of.h
#include linux/of_gpio.h
#include linux/pm.h
+#include linux/pm_runtime.h
#include linux/mmc/host.h
@@ -721,6 +722,11 @@ static int __devinit sdhci_s3c_probe(struct
platform_device *pdev)
if (pdata-host_caps2)
host-mmc-caps2 |= pdata-host_caps2;
+ pm_runtime_enable(pdev-dev);
+ pm_runtime_set_autosuspend_delay(pdev-dev, 50);
+ pm_runtime_use_autosuspend(pdev-dev);
+ pm_suspend_ignore_children(pdev-dev, 1);
+
ret = sdhci_add_host(host);
if (ret) {
dev_err(dev, sdhci_add_host() failed\n);
@@ -740,6 +746,8 @@ static int __devinit sdhci_s3c_probe(struct
platform_device *pdev)
err_add_host:
release_resource(sc-ioarea);
+ pm_runtime_forbid(pdev-dev);
+ pm_runtime_get_noresume(pdev-dev);
kfree(sc-ioarea);
err_req_regs:
@@ -784,6 +792,8 @@ static int __devexit sdhci_s3c_remove(struct
platform_device *pdev)
sdhci_remove_host(host, 1);
+ pm_runtime_disable(pdev-dev);
+
for (ptr = 0; ptr 3; ptr++) {
if (sc-clk_bus[ptr]) {
clk_disable(sc-clk_bus[ptr]);
@@ -824,9 +834,27 @@ static int sdhci_s3c_resume(struct device *dev)
}
#endif
+#ifdef CONFIG_PM_RUNTIME
+static int sdhci_s3c_runtime_suspend(struct device *dev)
+{
+ struct sdhci_host *host = dev_get_drvdata(dev);
+
+ return sdhci_runtime_suspend_host(host);
+}
+
+static int sdhci_s3c_runtime_resume(struct device *dev)
+{
+ struct sdhci_host *host = dev_get_drvdata(dev);
+
+ return sdhci_runtime_resume_host(host);
+}
+#endif
+
#ifdef CONFIG_PM
static const struct dev_pm_ops sdhci_s3c_pmops = {
SET_SYSTEM_SLEEP_PM_OPS(sdhci_s3c_suspend, sdhci_s3c_resume)
+ SET_RUNTIME_PM_OPS(sdhci_s3c_runtime_suspend, sdhci_s3c_runtime_resume,
+NULL)
};
#define SDHCI_S3C_PMOPS (sdhci_s3c_pmops)
Thanks, pushed to mmc-next for 3.4 with Jaehoon's ACK.
- 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: sdhci-s3c: Enable runtime power management
Hi,
On Fri, Mar 02 2012, Mark Brown wrote:
Since most of the work is already done by the core we just need to add
runtime suspend methods and tell the PM core that runtime PM is enabled
for this device.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/mmc/host/sdhci-s3c.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 46152d6..6926ac9 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -23,6 +23,7 @@
#include linux/of.h
#include linux/of_gpio.h
#include linux/pm.h
+#include linux/pm_runtime.h
#include linux/mmc/host.h
@@ -721,6 +722,11 @@ static int __devinit sdhci_s3c_probe(struct
platform_device *pdev)
if (pdata-host_caps2)
host-mmc-caps2 |= pdata-host_caps2;
+ pm_runtime_enable(pdev-dev);
+ pm_runtime_set_autosuspend_delay(pdev-dev, 50);
+ pm_runtime_use_autosuspend(pdev-dev);
+ pm_suspend_ignore_children(pdev-dev, 1);
+
ret = sdhci_add_host(host);
if (ret) {
dev_err(dev, sdhci_add_host() failed\n);
@@ -740,6 +746,8 @@ static int __devinit sdhci_s3c_probe(struct
platform_device *pdev)
err_add_host:
release_resource(sc-ioarea);
+ pm_runtime_forbid(pdev-dev);
+ pm_runtime_get_noresume(pdev-dev);
kfree(sc-ioarea);
err_req_regs:
@@ -784,6 +792,8 @@ static int __devexit sdhci_s3c_remove(struct
platform_device *pdev)
sdhci_remove_host(host, 1);
+ pm_runtime_disable(pdev-dev);
+
for (ptr = 0; ptr 3; ptr++) {
if (sc-clk_bus[ptr]) {
clk_disable(sc-clk_bus[ptr]);
@@ -824,9 +834,27 @@ static int sdhci_s3c_resume(struct device *dev)
}
#endif
+#ifdef CONFIG_PM_RUNTIME
+static int sdhci_s3c_runtime_suspend(struct device *dev)
+{
+ struct sdhci_host *host = dev_get_drvdata(dev);
+
+ return sdhci_runtime_suspend_host(host);
+}
+
+static int sdhci_s3c_runtime_resume(struct device *dev)
+{
+ struct sdhci_host *host = dev_get_drvdata(dev);
+
+ return sdhci_runtime_resume_host(host);
+}
+#endif
+
#ifdef CONFIG_PM
static const struct dev_pm_ops sdhci_s3c_pmops = {
SET_SYSTEM_SLEEP_PM_OPS(sdhci_s3c_suspend, sdhci_s3c_resume)
+ SET_RUNTIME_PM_OPS(sdhci_s3c_runtime_suspend, sdhci_s3c_runtime_resume,
+NULL)
};
#define SDHCI_S3C_PMOPS (sdhci_s3c_pmops)
I had to rework this patch to avoid a conflict with Julia Lawall's patch
mmc: sdhci-s3c: use devm_ functions: https://lkml.org/lkml/2012/2/18/76
The reworked patch is below, please let me know if it looks incorrect:
From: Mark Brown broo...@opensource.wolfsonmicro.com
Subject: [PATCH] mmc: sdhci-s3c: Enable runtime power management
Since most of the work is already done by the core we just need to add
runtime suspend methods and tell the PM core that runtime PM is enabled
for this device.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
Acked-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Chris Ball c...@laptop.org
---
drivers/mmc/host/sdhci-s3c.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 9683322..312aaf4 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -23,6 +23,7 @@
#include linux/of.h
#include linux/of_gpio.h
#include linux/pm.h
+#include linux/pm_runtime.h
#include linux/mmc/host.h
@@ -705,9 +706,16 @@ static int __devinit sdhci_s3c_probe(struct
platform_device *pdev)
if (pdata-host_caps)
host-mmc-caps |= pdata-host_caps;
+ pm_runtime_enable(pdev-dev);
+ pm_runtime_set_autosuspend_delay(pdev-dev, 50);
+ pm_runtime_use_autosuspend(pdev-dev);
+ pm_suspend_ignore_children(pdev-dev, 1);
+
ret = sdhci_add_host(host);
if (ret) {
dev_err(dev, sdhci_add_host() failed\n);
+ pm_runtime_forbid(pdev-dev);
+ pm_runtime_get_noresume(pdev-dev);
goto err_req_regs;
}
@@ -764,6 +772,8 @@ static int __devexit sdhci_s3c_remove(struct
platform_device *pdev)
sdhci_remove_host(host, 1);
+ pm_runtime_disable(pdev-dev);
+
for (ptr = 0; ptr 3; ptr++) {
if (sc-clk_bus[ptr]) {
clk_disable(sc-clk_bus[ptr]);
@@ -800,9 +810,27 @@ static int sdhci_s3c_resume(struct device *dev)
}
#endif
+#ifdef CONFIG_PM_RUNTIME
+static int sdhci_s3c_runtime_suspend(struct device *dev)
+{
+ struct sdhci_host *host = dev_get_drvdata(dev);
+
+ return sdhci_runtime_suspend_host(host);
+}
+
+static int sdhci_s3c_runtime_resume(struct device *dev)
+{
+ struct sdhci_host *host = dev_get_drvdata(dev);
+
+ return sdhci_runtime_resume_host(host);
+}
Re: [PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree
On Thu, 23 Feb 2012 17:31:27 +0530, Rajendra Nayak rna...@ti.com wrote:
Define dt bindings for the ti-omap-hsmmc, and adapt
the driver to extract data (which was earlier passed as
platform_data) from device tree.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 31 +
drivers/mmc/host/omap_hsmmc.c | 68
2 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
new file mode 100644
index 000..e4fa8f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -0,0 +1,31 @@
+* TI Highspeed MMC host controller for OMAP
+
+The Highspeed MMC Host Controller on TI OMAP family
+provides an interface for MMC, SD, and SDIO types of memory cards.
+
+Required properties:
+- compatible:
+ Should be ti,omap2-hsmmc, for OMAP2/3 controllers
+ Should be ti,omap4-hsmmc, for OMAP4 controllers
+- ti,hwmods: Must be mmcn, n is controller instance starting 1
+- reg : should contain hsmmc registers location and length
+
+Optional properties:
+ti,dual-volt: boolean, supports dual voltage cards
+supply-name-supply: phandle to the regulator device tree node
+supply-name examples are vmmc, vmmc_aux etc
+ti,bus-width: Number of data lines, default assumed is 1 if the property is
missing.
+cd-gpios: GPIOs for card detection
+wp-gpios: GPIOs for write protection
+ti,non-removable: non-removable slot (like eMMC)
Binding looks okay. A couple comments below...
[...]
+static const struct of_device_id omap_mmc_of_match[];
If you move the omap_mmc_of_match[] table up to here then there is no
need for the forward declaration.
+
static int __init omap_hsmmc_probe(struct platform_device *pdev)
{
struct omap_mmc_platform_data *pdata = pdev-dev.platform_data;
@@ -1725,6 +1768,14 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
struct omap_hsmmc_host *host = NULL;
struct resource *res;
int ret, irq;
+ const struct of_device_id *match;
+
+ match = of_match_device(omap_mmc_of_match, pdev-dev);
+ if (match) {
+ pdata = of_get_hsmmc_pdata(pdev-dev);
+ if (match-data)
+ pdata-reg_offset = *(u16 *)match-data;
Blech on the ugly cast. It is slightly safer to do thusly:
u16 *offsetp = match-data;
pdata-reg_offset = *offsetp
+ }
if (pdata == NULL) {
dev_err(pdev-dev, Platform Data is missing\n);
@@ -2120,12 +2171,29 @@ static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
.runtime_resume = omap_hsmmc_runtime_resume,
};
+#if defined(CONFIG_OF)
+static u16 omap4_reg_offset = 0x100;
+
+static const struct of_device_id omap_mmc_of_match[] = {
+ {
+ .compatible = ti,omap2-hsmmc,
+ },
+ {
+ .compatible = ti,omap4-hsmmc,
+ .data = omap4_reg_offset,
+ },
+ {},
+}
+MODULE_DEVICE_TABLE(of, omap_mmc_of_match);
+#endif
+
static struct platform_driver omap_hsmmc_driver = {
.remove = omap_hsmmc_remove,
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
.pm = omap_hsmmc_dev_pm_ops,
+ .of_match_table = of_match_ptr(omap_mmc_of_match),
},
};
--
1.7.1
___
linaro-dev mailing list
linaro-...@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
--
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: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data
On Fri, 24 Feb 2012 10:49:00 -0800, Tony Lindgren t...@atomide.com wrote:
* Rajendra Nayak rna...@ti.com [120223 19:29]:
On Friday 24 February 2012 12:27 AM, Tony Lindgren wrote:
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,5 +113,31 @@
#size-cells =0;
ti,hwmods = i2c3;
};
+
+ mmc1: mmc@1 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ };
+
+ mmc2: mmc@2 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc2;
+ };
+
+ mmc3: mmc@3 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc3;
+ };
+
+ mmc4: mmc@4 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc4;
+ };
+
+ mmc5: mmc@5 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc5;
+ };
};
};
These all should all be ti,omap3-hsmmc I guess?
Well, I defined the binding such that both omap2 and omap3
can use the same compatible ti,omap2-hsmmc since there is
no difference in the way they are defined or handled. If thats
confusing, I can have separate compatibles.
Btw, I guess we do the same with a few other re-used IPs as well,
I just checked and mcpsi does the same.
Yeah let's use separate compatibles to avoid confusion.
For omap2 we also have the ti,omap2-mmc in addition to
ti,omap2-hsmmc..
Yes, absolutely use separate compatible values. It is always important
to be specific as to the silicon implementing the IP. The omap3 instance
can also carry the omap2 string in its compatible list:
compatible = ti,omap3-hsmmc, ti,omap2-hsmmc;
g.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data
On Thu, 8 Mar 2012, Grant Likely wrote: Yes, absolutely use separate compatible values. It is always important to be specific as to the silicon implementing the IP. In that case, it is probably best to use the full chip name in the compatible string, e.g., omap2420 or omap2430 rather than just omap2. Particularly in the case of OMAP3, which is a largely meaningless group these days with AM33xx, OMAP34xx, OMAP36xx, and AM3517, many of which are quite different from each other... - Paul -- 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
