On 08/29/2014 12:54 AM, Tony Lindgren wrote: > * Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> [140828 12:37]: >> On 08/28/2014 06:46 PM, Tony Lindgren wrote: >>> >>> Sounds like there should be some way to clear that state.. I wonder >>> if omap-serial.c had something before it's DMA support was removed? >> >> Its DMA was removed? Like there was DMA support? > > Yeah see commit 494574304711a333386e7dd5fd3ebbc3b7024994... Interesting. I've been browsing that file and checking other trees and never noticed that it was there at some point. I only saw the pieces which looked it was there. > OK thanks, I'm seeing the same issue as you. And the idlest registers > don't show any blockers. Looking at the errata docs, seems like > "Usage Note 2.7" in sprz318f.pdf says: > > Details When configured for DMA operations using smartidle mode (SYSC[4:3].IDLEMODE = > 0x2), the UART module will not acknowledge incoming idle requests. As a consequence, > it can prevent L4 from going to idle. > When there are additional expected transfers, the UART should be placed in force-idle > mode. Ehm. So I haven't found an errata document for omap3630, there is nothing like that in that one I have for am335x or dra7. The document you mentioned is for AM3715. Interesting… > So I've added also Paul to Cc, he may have better suggestions for the > hwmod flags to use. The experimental patch below seems to allow idling > for me, care to give it a try? Yep, this one works. And I see DMA transfers (for RX side) after the core hit idle so it seems to look good :) > > Regards, > > Tony Sebastian -- 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