edma3: reduce some strict binding to EDMA3 LLD 3.40.00.00_eng
authorChris Ring <cring@ti.com>
Thu, 11 Sep 2014 22:20:45 +0000 (15:20 -0700)
committerChris Ring <cring@ti.com>
Thu, 11 Sep 2014 22:41:39 +0000 (15:41 -0700)
commit5dc5d0fba773e5e51da6c6517a8e25bc2459a253
tree5b4f5d613b4664fa386e3a30f306c7e84cfa15eb
parentbde6b3fa72617361d2883bfda0c7f35504007ae2
edma3: reduce some strict binding to EDMA3 LLD

When updating to a recent EDMA3 LLD release, some of the #defines have
changed their 'unsigned number' definition usage from little-u to
big-U (e.g. "#define foo (1u)" was changed to "define foo (1U)").

This causes build issues in FC since FC redefines some of these
definitions (exactly how previous EDMA3 LLD releases did, using
little-u).  When the #defines were identical (FC used little-u, EDMA3
LLD used little-u), there was no issue.  They were redundant
definitions, but they were identical.  But with the EDMA3 LLD change,
the following warning (or error, depending on your compile flags) is
reported (for several definitions):

   warning #48-D: incompatible redefinition of macro
   "EDMA3_MAX_DMA_CH"

With this commit, only define the preprocessor definitions if they
haven't already been defined.  EDMA3 LLD-based users should #include
the EDMA3 LLD headers first, then ti/sdo/fc/edma3/edma3_config.h,
which will now detect that EDMA3 LLD has already made these
definitions and will no longer redundantly define them.

The reality is that the EDMA3 LLD is present in all current
FC-supported environments.  Historically FC supported Linux ARM which
EDMA3 LLD didn't, but FC dropped Linux support a while ago.  So a
potentially better solution would be to _always_ depend on EDMA3 LLD.

Signed-off-by: Chris Ring <cring@ti.com>
packages/ti/sdo/fc/edma3/edma3_config.c
packages/ti/sdo/fc/edma3/edma3_config.h