From: Sebastian Andrzej Siewior Date: Mon, 29 Sep 2014 18:06:41 +0000 (+0200) Subject: tty: serial: 8250_dma: keep own book keeping about RX transfers X-Git-Tag: omap-for-v3.19/fixes-rc1~86^2~151 X-Git-Url: http://git.openpandora.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=0fcb7901f9d61a325b4c5b88c600383bcbeb97fe;p=pandora-kernel.git tty: serial: 8250_dma: keep own book keeping about RX transfers After dmaengine_terminate_all() has been invoked then both DMA drivers (edma and omap-dma) do not invoke dma_cookie_complete() to mark the transfer as complete. This dma_cookie_complete() is performed by the Synopsys DesignWare driver which is probably the only one that is used by omap8250-dma and hence don't see following problem… …which is that once a RX transfer has been terminated then following query of channel status reports DMA_IN_PROGRESS (again: the actual transfer has been canceled, there is nothing going on anymore). This means that serial8250_rx_dma() never enqueues another DMA transfer because it (wrongly) assumes that there is a transer already pending. Vinod Koul refuses to accept a patch which adds this dma_cookie_complete() to both drivers and so dmaengine_tx_status() would report DMA_COMPLETE instead (and behave like the Synopsys DesignWare driver already does). He argues that I am not allowed to use the cookie to query the status and that the driver already cleaned everything up after the invokation of dmaengine_terminate_all(). To end this I add a bookkeeping whether or not a RX-transfer has been started to the 8250-dma code. It has already been done for the TX side. *Now* we learn about the RX status based on our bookkeeping and don't need dmaengine_tx_status() for this anymore. Cc: vinod.koul@intel.com Reviewed-by: Tony Lindgren Tested-by: Tony Lindgren Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman --- Reading git-diff-tree failed