Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755774AbbHFMbg (ORCPT ); Thu, 6 Aug 2015 08:31:36 -0400 Received: from www.linutronix.de ([62.245.132.108]:45638 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755143AbbHFMbe (ORCPT ); Thu, 6 Aug 2015 08:31:34 -0400 Message-ID: <55C3539F.4070403@linutronix.de> Date: Thu, 06 Aug 2015 14:31:27 +0200 From: Sebastian Andrzej Siewior User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Peter Hurley CC: John Ogness , linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Tony Lindgren , linux-omap@vger.kernel.org, nsekhar@ti.com, nm@ti.com, linux-serial@vger.kernel.org, Heikki Krogerus Subject: Re: [PATCH 3/3] serial: 8250: omap: restore registers on shutdown References: <87egjp2r4a.fsf@linutronix.de> <55BAC67E.1010400@hurleysoftware.com> <20150803160937.GA26497@linutronix.de> <55BF980E.20908@hurleysoftware.com> <55BF9CE0.4080107@linutronix.de> <55BFC1BA.5020605@hurleysoftware.com> <55C0A8F4.4010204@linutronix.de> <55C352A8.3070102@hurleysoftware.com> In-Reply-To: <55C352A8.3070102@hurleysoftware.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1988 Lines: 52 On 08/06/2015 02:27 PM, Peter Hurley wrote: > Hi Sebastian, Hi Peter, > On 08/04/2015 07:58 AM, Sebastian Andrzej Siewior wrote: >> On 08/03/2015 09:32 PM, Peter Hurley wrote: >> >>>> You mean a function in 8250-dma API which does what I did just here >>>> with the wait_event() and the wake_up in the callback? That way I could >>>> move the termios_wait into the dma struct instead of keeping in the >>>> omap specific part. I am also not sure if OMAP is the only one that may >>>> hang here or the other people just didn't notice it yet. >>> >>> Exactly; and we need to fix DMA wrt x_char anyway. >>> >>> Going back to the dmaengine api, I think something like this might work >>> (as a first approximation): >>> >>> dma_sync_wait(dma->txchan, dma->tx_cookie); >>> dmaengine_pause(dma->txchan); >>> >>> /* remainder of set_termios */ >>> >>> dmaengine_resume(dma->txchan); >>> >>> We could require 8250 core dma to support pause/resume. >> >> I would prefer the waitqueue approach. >> You can't do this while holding the port lock. The lock is taken with >> irqs off so may not see the transfer completing. >> Why do you pause the channel? It may not work without an active >> descriptor and a start without "resume" should work. Also you must >> ensure that DMA's complete callback does not start another transfer if >> there is something queued up (that is why I had the tx_running dance). >> I am not sure if a transfer that is active and then paused will not >> trigger the hang bug if we change the termios in between. > > I'll look at/test this this weekend, ok? Sure. I'm currently re-spinning the patches so have everything in proper pieces. While at it I will take a look at x_char. > Regards, > Peter Hurley > Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/