> From: Paul Walmsley [mailto:paul@xxxxxxxxx] > Sent: Friday, February 03, 2012 7:00 PM > > One irritation was some internal interrupt sources were not linked to > > low power wakeup events. If you were in interrupt mode and got > > characters below watermark you could sleep before interrupt status > > showed up (as you had to wait several frame times before functional > > interrupt asserted) but there was no wake at anticipated frame timeout > > because lack of linking of internal event to wake event. > > Indeed, it seems that we are just now working around these wakeup-related > bugs. Kind of surprising that no errata showed up for them. There have been errata over time in this area. Several I hit were updated at 3630 time. UART did get IER2 but I don't recall all details for UART. Probably that is not being used. > What's particularly remarkable is that it looks like the UARTs will > idle-ack while their transmit FIFOs have data in them (!) Generally a module can ACK its ICLK if it is not used internally. The FCLK can push data out with out ICLK and is controlled separately always (omap4 changed encoding, to optional clock). This allows interconnect to idle during tx to save power. The trick is to ensure all module wakeup plumbing is enabled so a functional tx irq will flow. Audits last showed several drivers missing steps (omap specific). Some drivers seemed to rely on static dependencies or coincident neighbor activity to allow their functional interrupt to flow... to many interdependent custom details... and yes some errata. Anyway, even with all SOC specific wake bits you may lose the character with latency of restart. Point I was raising was external chip hook can not be neglected as its part of equation. Regards, Richard W. -- 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
