DMA: prep for F2 with new "tube" API.

To prepare for STM32F2/F4 DMA support, introduce a new libmaple DMA
API, and move some code around to make priority level and interrupt
handling more generic.

The new API is based on a new set of types (dma_tube, struct
dma_tube_reg_map, enum dma_request_src, enum dma_cfg_flags, and struct
dma_tube_config).

The central abstraction is the dma_tube type. STM32F2/F4 use DMA
streams to control dataflow, and STM32F1 uses channels. dma_tube
stands for whichever is appropriate for the current target. Dealing
with tubes allows for configuring and using DMA with opaque tube
values in the same source, instead of (as with ST's firmware)
requiring two separate codebases.

The new API is also more user-friendly, as it doesn't require knowing
which DMA address registers to set and which configuration register
flags go along with them. It now suffices to specify the source and
destination for the DMA transfer, along with their sizes. This avoids
confusion (e.g. for memory-to-memory transfers, data flows from the
peripheral address register to the memory register, which might be
surprising on F2, which has two memory address registers).

The old API (based on enum dma_mode_flags and dma_setup_transfer()) is
still available on F1, but deprecate it.

Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>

1 files changed, 35 insertions, 0 deletions

diff --git a/libmaple/dma.c b/libmaple/dma.c
index 6442e4d..d13de10 100644
--- a/libmaple/dma.c
+++ b/libmaple/dma.c
@@ -33,6 +33,8 @@
  */
 
 #include <libmaple/dma.h>
+#include "dma_private.h"
+#include "stm32_private.h"
 
 /*
  * Convenience routines
@@ -45,3 +47,36 @@
 void dma_init(dma_dev *dev) {
     rcc_clk_enable(dev->clk_id);
 }
+
+/*
+ * Private API
+ */
+
+enum dma_atype _dma_addr_type(__io void *addr) {
+    switch (stm32_block_purpose((void*)addr)) {
+    /* Notice we're treating the code block as memory here.  That's
+     * correct for addresses in Flash and in [0x0, 0x7FFFFFF]
+     * (provided that those addresses are aliased to Flash, SRAM, or
+     * FSMC, depending on BOOT[01] and possibly SYSCFG_MEMRMP). It's
+     * not correct for other addresses in the code block, but those
+     * will (hopefully) just fail-fast with transfer or bus errors. If
+     * lots of people get confused, it might be worth being more
+     * careful here. */
+    case STM32_BLOCK_CODE:      /* Fall through */
+    case STM32_BLOCK_SRAM:      /* ... */
+    case STM32_BLOCK_FSMC_1_2:  /* ... */
+    case STM32_BLOCK_FSMC_3_4:
+        return DMA_ATYPE_MEM;
+    case STM32_BLOCK_PERIPH:
+        return DMA_ATYPE_PER;
+    case STM32_BLOCK_FSMC_REG:        /* Fall through */
+        /* Is this right? I can't think of a reason to DMA into or out
+         * of the FSMC registers. [mbolivar]  */
+    case STM32_BLOCK_UNUSED:          /* ... */
+    case STM32_BLOCK_CORTEX_INTERNAL: /* ... */
+        return DMA_ATYPE_OTHER;
+    default:
+        ASSERT(0);              /* Can't happen */
+        return DMA_ATYPE_OTHER;
+    }
+}