Fix ENC28J60 chip enable issue

git-svn-id: https://nuttx.svn.sourceforge.net/svnroot/nuttx/trunk@5153 7fd9a85b-ad96-42d3-883c-3090e2eb8679

nuttx/mm/README.txt

@@ -46,8 +46,8 @@ This directory contains the NuttX memory management logic.  This include:
 
 3) Granule Allocator.  A non-standard granule allocator is also available
    in this directory  The granule allocator allocates memory in units
-   of a fixed sized block ("granule").  All memory is aligned to the size
-   of one granule.
+   of a fixed sized block ("granule").  Allocations may be aligned to a user-
+   provided address boundary.
 
    The granule allocator interfaces are defined in nuttx/include/nuttx/gran.h.
    The granule allocator consists of these files in this directory:
@@ -59,13 +59,34 @@ This directory contains the NuttX memory management logic.  This include:
    as of this writing.  The intent of the granule allocator is to provide
    a tool to support platform-specific management of aligned DMA memory.
 
-   NOTE: Because each granule is aligned to the granule size and each
-   allocations is in units of the granule size, selection of the granule
-   size is important:  Larger granules will give better performance and
-   less overhead but more losses of memory due to alignment and quantization
-   waste.
+   NOTE: Because each granule may be aligned and each allocation is in
+   units of the granule size, selection of the granule size is important:
+   Larger granules will give better performance and less overhead but more
+   losses of memory due to quantization waste.  Additional memory waste
+   can occur from alignment;  Of course, heap alignment should no be
+   used unless (a) you are using the granule allocator to manage DMA memory
+   and (b) your hardware has specific memory alignment requirements.
 
    The current implementation also restricts the maximum allocation size
    to 32 granules.  That restriction could be eliminated with some
    additional coding effort, but currently requires larger granule
    sizes for larger allocations.
+
+  Geneneral Usage Example.  This is an example using the GCC section
+  attribute to position a DMA heap in memory (logic in the linker script
+  would assign the section .dmaheap to the DMA memory.
+ 
+    FAR uint32_t g_dmaheap[DMAHEAP_SIZE] __attribute__((section(.dmaheap)));
+ 
+  The heap is created by calling gran_initialize.  Here the granual size
+  is set to 64 bytes and the alignment to 16 bytes:
+ 
+    GRAN_HANDLE handle = gran_initialize(g_dmaheap, DMAHEAP_SIZE, 6, 4);
+ 
+  Then the GRAN_HANDLE can be used to allocate memory (There is no
+  GRAN_HANDLE if CONFIG_GRAN_SINGLE=y):
+ 
+    FAR uint8_t *dma_memory = (FAR uint8_t *)gran_alloc(handle, 47);
+ 
+  The actual memory allocates will be 64 byte (wasting 17 bytes) and
+  will be aligned at least to (1 << log2align).

nuttx/mm/mm_graninit.c

@@ -158,11 +158,10 @@ gran_common_initialize(FAR void *heapstart, size_t heapsize, uint8_t log2gran,
  *   Set up one granule allocator instance.  Allocations will be aligned to
  *   the alignment size (log2align; allocations will be in units of the
  *   granule size (log2gran). Larger granules will give better performance
- *   and less overhead but more losses of memory due to alignment
- *   quantization waste.  Additional memory waste can occur form alignment;
- *   log2align should be set to 0 unless you are using the granule allocator
- *   to manage DMA memory and your hardware has specific memory alignment
- *   requirements.
+ *   and less overhead but more losses of memory due to quantization waste.
+ *   Additional memory waste can occur from alignment; log2align should be
+ *   set to 0 unless you are using the granule allocator to manage DMA memory
+ *   and your hardware has specific memory alignment requirements.
  *
  *   Geneneral Usage Summary.  This is an example using the GCC section
  *   attribute to position a DMA heap in memory (logic in the linker script