On Tue, 6 Mar 2012, Rafael J. Wysocki wrote: > On Tuesday, March 06, 2012, Guennadi Liakhovetski wrote: > > On Sun, 4 Mar 2012, Rafael J. Wysocki wrote: > > > > > From: Rafael J. Wysocki <r...@sisk.pl> > > > > > > Make tmio_mmc populate the pm_qos member of struct mmc_host, to > > > let the core know that it should create the pm_latency_limit_ms > > > host attribute for it, and set the default value of that attribute > > > to 100 ms. > > > > > > Signed-off-by: Rafael J. Wysocki <r...@sisk.pl> > > > --- > > > drivers/mmc/host/tmio_mmc_pio.c | 8 ++++++++ > > > 1 file changed, 8 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 > > > @@ -918,6 +918,12 @@ int __devinit tmio_mmc_host_probe(struct > > > if (ret < 0) > > > goto pm_disable; > > > > > > + mmc->pm_qos = kzalloc(sizeof(*mmc->pm_qos), GFP_KERNEL); > > > > Why don't you just add pm_qos to struct tmio_mmc_host? > > Because the core has to see it.
Yes, I understand that. So, you just assign a pointer to it to mmc->pm_qos, just avoiding an extra allocation / freeing / error handling. > > > + if (mmc->pm_qos) > > > + mmc->pm_qos->val = 100; > > > > 100ms... that seems way too long for me, wouldn't that allow the > > runtime-pm to power down and up the domain on each request?... > > That should be 100 us, sorry for the confusion. 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
