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. 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
