kernel/linux/Documentation/arm/Sharp-LH/IOBarrier

   1 README on the IOBARRIER for CardEngine IO
   2 =========================================
   3
   4 Due to an unfortunate oversight when the Card Engines were designed,
   5 the signals that control access to some peripherals, most notably the
   6 SMC91C9111 ethernet controller, are not properly handled.
   7
   8 The symptom is that back to back IO with the peripheral returns
   9 unreliable data.  With the SMC chip, you'll see errors about the bank
  10 register being 'screwed'.
  11
  12 The cause is that the AEN signal to the SMC chip does not transition
  13 for every memory access.  It is driven through the CPLD from the CS7
  14 line of the CPU's static memory controller which is optimized to
  15 eliminate unnecessary transitions.  Yet, the SMC requires a transition
  16 for every access.  The Sharp website has more information on the
  17 effect of this power conservation feature on peripheral interfacing.
  18
  19 The solution is to follow every access to the SMC chip with an access
  20 to another memory region that will force the CPU to release the chip
  21 select line.  Note that it is important to guarantee that the access
  22 will force the CPU off-chip.  We map a page of SDRAM as if it were an
  23 uncacheable IO device and read from it after every SMC IO operation.
  24
  25   SMC IO
  26   BARRIER IO
  27
  28 You might be tempted to believe that we must access another device
  29 attached to the static memory controller, but the empirical evidence
  30 indicates that this is not so.  Mapping 0x00000000 (flash) and
  31 0xc0000000 (SDRAM) appear to have the same effect.  Using SDRAM seems
  32 to be faster.