+Paul, NeilBrown who both have worked on/around recent UART breakage since v3.2 "Joe Woodward" <jw@xxxxxxxxxxxxxx> 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 -- 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
