Since the last fixes to this driver ensure now the queue termination is
done correctly, we can finally disable the queue after a transfer
without problems. The gain is that it will only be reenabled after the
next transfer is fully set up. Before, the queue was running all the
time and if the setup of the next message was interrupted by another
thread, an incomplete buffer could have been sent, padded with zeroes.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
After an error interrupt setting cmd->err, I see another interrupt that
the data engine is empty which clears cmd->err before being processed.
So, clear cmd->err at the beginning of a transfer only to handle these
consecutive interrupts.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
The hardware generates an interrupt for every completed command in the
queue while the code assumed that it will only generate one interrupt
when the queue is empty. So, explicitly check if the queue is really
empty. This patch fixed problems which occurred due to high traffic on
the bus. While we are here, move the completion-initialization after the
parameter error checking.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Lothar Waßmann <LW@KARO-electronics.de>
Cc: stable@kernel.org
mxs_reset_block() clears the PIO_QUEUE_MODE bit. So we have
to set it again after a controller reset.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Currently only supporting the PIOQUEUE-mode, because DMA-support for
this platform is not yet in mainline. When it becomes available and
support has been added to this driver, it will also be suitable for
i.MX23 and STMP3xxx.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
