These drivers set the DMA_INTERRUPT capability bit when requesting a DMA
controller channel. This was historical, and is no longer needed.

Recent changes to the drivers/dma/fsldma.c driver have removed support
for this flag. This makes the carma drivers unable to find a DMA channel
with the required capabilities.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NIra W. Snyder <iws@ovro.caltech.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When the system is under heavy load, we occasionally saw a problem where
the system would get a legitimate interrupt when they should be
disabled.

This was caused by the data_dma_cb() DMA callback unconditionally
re-enabling FPGA interrupts even when data dumping is disabled. When
data dumping was re-enabled, the irq handler would fire while a DMA was
in progress. The "BUG_ON(priv->inflight != NULL);" during the second
invocation of the DMA callback caused the system to crash.

To fix the issue, the priv->enabled boolean is moved under the
protection of the priv->lock spinlock. The DMA callback checks the
boolean to know whether to re-enable FPGA interrupts before it returns.

Now that it is fixed, the driver keeps FPGA interrupts disabled when it
expects that they are disabled, fixing the bug.
Signed-off-by: NIra W. Snyder <iws@ovro.caltech.edu>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Lockdep occasionally complains with the message:
INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected

This is caused by calling videobuf_dma_unmap() under spin_lock_irq(). To
fix the warning, we drop the lock before unmapping and freeing the
buffer.
Signed-off-by: NIra W. Snyder <iws@ovro.caltech.edu>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

This patch converts the drivers in drivers/misc/* to use the
module_platform_driver() macro which makes the code smaller and a bit
simpler.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NIra W. Snyder <iws@ovro.caltech.edu>
Cc: Pavan Savoy <pavan_savoy@ti.com>
Cc: Donggeun Kim <dg77.kim@samsung.com>
Acked-By: NPratyush Anand <pratyush.anand@st.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

... by 6 months
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

This driver allows userspace to access the data processing FPGAs on the
OVRO CARMA board. It has two modes of operation:

1) random access

This allows users to poke any DATA-FPGA registers by using mmap to map
the address region directly into their memory map.

2) correlation dumping

When correlating, the DATA-FPGA's have special requirements for getting
the data out of their memory before the next correlation. This nominally
happens at 64Hz (every 15.625ms). If the data is not dumped before the
next correlation, data is lost.

The data dumping driver handles buffering up to 1 second worth of
correlation data from the FPGAs. This lowers the realtime scheduling
requirements for the userspace process reading the device.
Signed-off-by: NIra W. Snyder <iws@ovro.caltech.edu>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>