On Fri, 13 Jan 2012, Kevin Hilman wrote:
> Kevin Hilman <khil...@ti.com> writes:
>
> [...]
>
> >> From: Paul Walmsley <p...@pwsan.com>
> >> Date: Fri, 13 Jan 2012 02:10:30 -0700
> >> Subject: [PATCH] ARM: OMAP3: PM: allow MPU to enter low-power states even
> >> when the UART is active
> >>
> >> For some reason, both the existing OMAP3 PM code and the OMAP3 CPUIdle
> >> driver prevent the MPU powerdomain from entering low-power modes when
> >> any UART isn't asleep. Possibly it is intended to minimize the ARM
> >> wakeup latency when UART activity arrives, but the UART has a FIFO
> >> that should handle this for most cases, with no dropped characters. I
> >> may be forgetting something important, though. And CORE/PER low-power
> >> states are a different matter entirely.
> >
> > Just FYI... the UART can_sleep hackery was removed for v3.3 and replaced
> > by using a PM QoS constraint:
>
> However, looking closer I see now that the constraint being used in the
> mailine driver uses the CPU_DMA_LATENCY QoS constraint, which is preventing
> deeper C states as well just like the current code (before your patch),
> so an similar fix will still be needed for mainline.
Hmm. This is the following code in serial_omap_set_termios() ?
/* calculate wakeup latency constraint */
up->calc_latency = (1000000 * up->port.fifosize) /
(1000 * baud / 8);
up->latency = up->calc_latency;
schedule_work(&up->qos_work);
Let's work out this formula for 115.2kbps:
(1000000 * 16) / (1000 * 115200 / 8)
= 16000000 / 14400000
= 1.11... (presumably the unit here is milliseconds)
= 1 (since up->calc_latency is a u32)
Then up->calc_latency is passed to pm_qos_update_request(). According to
Documentation/power/pm_qos_interface.txt, it is expecting microseconds.
So that's one problem. To fix that it should be
up->calc_latency = (1000000 * up->port.fifosize) /
(baud / 8);
With that change, it should be possible to enter C3, with the timings that
are in the mainline cpuidle34xx.c.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
