On Thu, Apr 12, 2012 at 3:19 AM, Kevin Hilman <khilman@xxxxxx> wrote:
> Grazvydas Ignotas <notasas@xxxxxxxxx> writes:
>
>> On Mon, Apr 9, 2012 at 10:03 PM, Kevin Hilman <khilman@xxxxxx> wrote:
>>> Grazvydas Ignotas <notasas@xxxxxxxxx> writes:
>>>> While SD card performance loss is not that bad (~7%), NAND one is
>>>> worrying (~39%). I've tried disabling/enabling CONFIG_CPU_IDLE, also
>>>> cpuidle states over sysfs, it did not have any significant effect. Is
>>>> there something else to try?
>>>
>>> Looks like we might need a PM QoS constraint when there is DMA activity
>>> in progress.
>>>
>>> You can try doing a pm_qos_add_request() for PM_QOS_CPU_DMA_LATENCY when
>>> DMA transfers are active and I suspect that will help.
>>
>> I've tried it and it didn't help much. It looks like the only thing it
>> does is limiting cpuidle c-states, I tried to set qos dma latency to 0
>> and it made it stay in C1 while transfer was ongoing (I watched
>> /sys/devices/system/cpu/cpu0/cpuidle/state*/usage), but performance
>> was still poor.
>
> Great, thanks for doing this experiment.
>
> Assuming we get to a C1 that's low-latency enough, we will still need
> this constraint to ensure C1 during transfers. But first we have to
> figure out what's going on with C1...
I've been working on this to collect more data, and noticed that PER
is often being put to RET even at C1, is that expected? There is some
additional work being done in that case, like putting GPIOs to sleep,
and it seems to be source of part of performance loss here as it
happens often during NAND transfers.
This can be reproduced while doing mmc transfers too and detected with this:
(not a valid patch, sorry, sending through gmail web)
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -87,6 +87,8 @@ static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
return 0;
}
+int is_c1;
+
static int __omap3_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
@@ -117,6 +120,7 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
cpu_pm_enter();
/* Execute ARM wfi */
+ is_c1 = (index == 0);
omap_sram_idle();
/*
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 703bd10..519ce9d 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -275,6 +275,7 @@ void omap_sram_idle(void)
int per_going_off;
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
+ extern int is_c1;
mpu_next_state = pwrdm_read_next_pwrst(mpu_pwrdm);
switch (mpu_next_state) {
@@ -299,6 +300,8 @@ void omap_sram_idle(void)
/* Enable IO-PAD and IO-CHAIN wakeups */
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
+if (is_c1 && (per_next_state != PWRDM_POWER_ON || core_next_state !=
PWRDM_POWER_ON))
+ printk(KERN_ERR "c1 core %d, per %d\n", per_next_state, core_next_state);
if (omap3_has_io_wakeup() &&
(per_next_state < PWRDM_POWER_ON ||
core_next_state < PWRDM_POWER_ON)) {
--
Gražvydas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
