Re: Suspend broken on 3.3?

[Kevin Hilman <khilman@ti.com>]

+Paul, NeilBrown who both have worked on/around recent UART breakage
 since v3.2

"Joe Woodward" <jw@terrafix.co.uk> writes:

[...]

> This patch fixes the suspend problem for me, but there is another UART issue...
>
> Basically I've got a fairly high speed data source (in UART terms,
> >900KBaud) pumping data to the OMAP (such as GPS positions).
>
> I don't want this to wake me when suspended (which this patch fixes).
>
> However, it seems on 3.3 that I get a lot of corruption/lost
> characters, which I'm assuming is because the UART is implementing
> runtime-PM.
>
> So my next question is: How do I disable runtime-PM/force-always-on
> for a given UART? Can this be done via the sysfs?

Yes, but the boot-time default for this is that the UARTs have runtime
PM disabled since the default autosuspend timeout is set to -1.

You must be setting an autosuspend timeout >0 if you're seeing runtime
PM kick in.

That being said, even with an autosuspend timeout enabled, you can
disable runtime PM by setting the /sys/devices/.../power/control knob to
'on' (instead of auto, which means it's controle by runtime PM):

  echo on > /sys/devices/platform/omap/omap_uart.2/power/control

That will disable runtime PM and leave the UARTs always clocked.

> Or where are the runtime-PM constraints set for the UART? 

Look for this in the driver:

	/* calculate wakeup latency constraint */
	up->calc_latency = (USEC_PER_SEC * up->port.fifosize) / (baud / 8);

> I'm guessing they'll work for 115200Baud, but my high speed UART fowls
> these?

The constraint calculations take into account baud rate, but are known
to be somewhat broken currently.

You might want to experiment with Paul's work on fixing up the QoS
contstraint calculation[1] to see if it helps as well.  That is available here

Kevin

[1] git://git.pwsan.com/linux-2.6 omap_serial_fix_pm_qos_formula_devel_3.4