summaryrefslogtreecommitdiffstats
path: root/Documentation/arm/Sharp-LH/IOBarrier
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2011-03-16 19:05:40 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2011-03-16 19:05:40 -0700
commit63a93699c6a58795b854ff573542a08367684dae (patch)
tree057ab4cbde66862c51867dde030be69a2fa7073f /Documentation/arm/Sharp-LH/IOBarrier
parent16d8775700f1815076f879719ce14b33f50a3171 (diff)
parent21bd6d37cf23e643020bf28b41844ff0040c9393 (diff)
downloadop-kernel-dev-63a93699c6a58795b854ff573542a08367684dae.zip
op-kernel-dev-63a93699c6a58795b854ff573542a08367684dae.tar.gz
Merge branch 'remove' of master.kernel.org:/home/rmk/linux-2.6-arm
* 'remove' of master.kernel.org:/home/rmk/linux-2.6-arm: ARM: 6629/2: aaec2000: remove support for mach-aaec2000 ARM: lh7a40x: remove unmaintained platform support Fix up trivial conflicts in - arch/arm/mach-{aaec2000,lh7a40x}/include/mach/memory.h (removed) - drivers/usb/gadget/Kconfig (USB_[GADGET_]LH7A40X removed, others added)
Diffstat (limited to 'Documentation/arm/Sharp-LH/IOBarrier')
-rw-r--r--Documentation/arm/Sharp-LH/IOBarrier45
1 files changed, 0 insertions, 45 deletions
diff --git a/Documentation/arm/Sharp-LH/IOBarrier b/Documentation/arm/Sharp-LH/IOBarrier
deleted file mode 100644
index 2e953e2..0000000
--- a/Documentation/arm/Sharp-LH/IOBarrier
+++ /dev/null
@@ -1,45 +0,0 @@
-README on the IOBARRIER for CardEngine IO
-=========================================
-
-Due to an unfortunate oversight when the Card Engines were designed,
-the signals that control access to some peripherals, most notably the
-SMC91C9111 ethernet controller, are not properly handled.
-
-The symptom is that some back to back IO with the peripheral returns
-unreliable data. With the SMC chip, you'll see errors about the bank
-register being 'screwed'.
-
-The cause is that the AEN signal to the SMC chip does not transition
-for every memory access. It is driven through the CPLD from the CS7
-line of the CPU's static memory controller which is optimized to
-eliminate unnecessary transitions. Yet, the SMC requires a transition
-for every write access. The Sharp website has more information about
-the effect this power-conserving feature has on peripheral
-interfacing.
-
-The solution is to follow every write access to the SMC chip with an
-access to another memory region that will force the CPU to release the
-chip select line. It is important to guarantee that this access
-forces the CPU off-chip. We map a page of SDRAM as if it were an
-uncacheable IO device and read from it after every SMC IO write
-operation.
-
- SMC IO
- BARRIER IO
-
-Only this sequence is important. It does not matter that there is no
-BARRIER IO before the access to the SMC chip because the AEN latch
-only needs occurs after the SMC IO write cycle. The routines that
-implement this work-around make an additional concession which is to
-disable interrupts during the IO sequence. Other hardware devices
-(the LogicPD CPLD) have registers in the same physical memory
-region as the SMC chip. An interrupt might allow an access to one of
-those registers while SMC IO is being performed.
-
-You might be tempted to think that we have to access another device
-attached to the static memory controller, but the empirical evidence
-indicates that this is not so. Mapping 0x00000000 (flash) and
-0xc0000000 (SDRAM) appear to have the same effect. Using SDRAM seems
-to be faster. Choosing to access an undecoded memory region is not
-desirable as there is no way to know how that chip select will be used
-in the future.
OpenPOWER on IntegriCloud