-----Original Message----- From: Kevin Hilman <khil...@ti.com> To: "Joe Woodward" <j...@terrafix.co.uk> Cc: "Raja\, Govindraj" <govindraj.r...@ti.com>, linux-omap@vger.kernel.org, "Felipe Balbi" <ba...@ti.com>, Paul Walmsley <p...@pwsan.com>, ne...@suse.de Date: Wed, 28 Mar 2012 10:46:23 -0700 Subject: Re: Suspend broken on 3.3?
> +Paul, NeilBrown who both have worked on/around recent UART breakage > since v3.2 > > "Joe Woodward" <j...@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 > Right, First an apology... After checking /sys/devices/platform/omap/omap_uart.2/power/control I can see that runtime-PM is indeed disabled. After digging a bit further I found that the problem isn't lost characters or character corruption at all... The UART is actually at 430KBaud (not 900KBaud as I mentioned earlier). The data received is very bursty (i.e. sets of messages every second or so), containing a sync sequence to indicate a start of packet. The received bytes should be: 0x01, 0x52, 0x41 ....rest of packet. This works 100% of the time on 3.2, but on 3.3 I sometimes (but not always) get: 0x01, 0x00, 0x52, 0x41. i.e. there is a NULL/0x00 inserted after the first character. All this is tested using a very simple userspace application thats reads data from ttyO1. Any ideas? Should I kick open a new thread as it's not really to do with suspend anymore? Thanks, Joe > 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
