[ARM PATCH] 1818/1: lh7a40x #2 (3/7) doc

Patch from Marc Singer

Documentation for the Sharp-LH machines.

Documentation/arm/Sharp-LH/CompactFlash

+README on the Compact Flash for Card Engines
+============================================
+
+There are three challenges in supporting the CF interface of the Card
+Engines.  First, every IO operation must be followed with IO to
+another memory region.  Second, the slot is wired for one-to-one
+address mapping *and* it is wired for 16 bit access only.  Second, the
+interrupt request line from the CF device isn't wired.
+
+The IOBARRIER issue is covered in README.IOBARRIER.  This isn't an
+onerous problem.  Enough said here.
+
+The addressing issue is solved in the
+arch/arm/mach-lh7a40x/ide-lpd7a40x.c file with some awkward
+work-arounds.  We implement a special SELECT_DRIVE routine that is
+called before the IDE driver performs its own SELECT_DRIVE.  Our code
+recognizes that the SELECT register cannot be modified without also
+writing a command.  It send an IDLE_IMMEDIATE command on selecting a
+drive.  The function also prevents drive select to the slave drive
+since there can be only one.  The awkward part is that the IDE driver,
+even though we have a select procedure, also attempts to change the
+drive by writing directly the SELECT register.  This attempt is
+explicitly blocked by the OUTB function--not pretty, but effective.
+
+The lack of interrupts is a more serious problem.  Even though the CF
+card is fast when compared to a normal IDE device, we don't know that
+the CF is really flash.  A user could use one of the very small hard
+drives being shipped with a CF interface.  The IDE code includes a
+check for interfaces that lack an IRQ.  In these cases, submitting a
+command to the IDE controller is followed by a call to poll for
+completion.  If the device isn't immediately ready, it schedules a
+timer to poll again later.

Documentation/arm/Sharp-LH/IOBarrier

+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 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 access.  The Sharp website has more information on the
+effect of this power conservation feature on peripheral interfacing.
+
+The solution is to follow every access to the SMC chip with an access
+to another memory region that will force the CPU to release the chip
+select line.  Note that it is important to guarantee that the access
+will force 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 operation.
+
+  SMC IO
+  BARRIER IO
+
+You might be tempted to believe that we must 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.

Documentation/arm/Sharp-LH/KEV7A400

+README on Implementing Linux for Sharp's KEV7a400
+=================================================
+
+This product has been discontinued by Sharp.  For the time being, the
+partially implemented code remains in the kernel.  At some point in
+the future, either the code will be finished or it will be removed
+completely.  This depends primarily on how many of the development
+boards are in the field.

Documentation/arm/Sharp-LH/LPD7A400

+README on Implementing Linux for the Logic PD LPD7A400-10
+=========================================================
+
+- CPLD memory mapping
+
+  The board designers chose to use high address lines for controlling
+  access to the CPLD registers.  It turns out to be a big waste
+  because we're using an MMU and must map IO space into virtual
+  memory.  The result is that we have to make a mapping for every
+  register.
+
+- Serial Console
+
+  It may be OK not to use the serial console option if the user passes
+  the console device name to the kernel.  This deserves some exploration.

Documentation/arm/Sharp-LH/LPD7A40X

+README on Implementing Linux for the Logic PD LPD7A40X-10
+=========================================================
+
+- CPLD memory mapping
+
+  The board designers chose to use high address lines for controlling
+  access to the CPLD registers.  It turns out to be a big waste
+  because we're using an MMU and must map IO space into virtual
+  memory.  The result is that we have to make a mapping for every
+  register.
+
+- Serial Console
+
+  It may be OK not to use the serial console option if the user passes
+  the console device name to the kernel.  This deserves some exploration.
+

Documentation/arm/Sharp-LH/VectoredInterruptController

+README on the Vectored Interrupt Controller of the LH7A404
+==========================================================
+
+The 404 revision of the LH7A40X series comes with two vectored
+interrupts controllers.  While the kernel does use some of the
+features of these devices, it is far from the purpose for which they
+were designed.
+
+When this README was written, the implementation of the VICs was in
+flux.  It is possible that some details, especially with priorities,
+will change.
+
+The VIC support code is inspired by routines written by Sharp.
+
+
+Priority Control
+----------------
+
+The significant reason for using the VIC's vectoring is to control
+interrupt priorities.  There are two tables in
+arch/arm/mach-lh7a40x/irq-lh7a404.c that look something like this.
+
+  static unsigned char irq_pri_vic1[] = { IRQ_GPIO3INTR, };
+  static unsigned char irq_pri_vic2[] = {
+	IRQ_T3UI, IRQ_GPIO7INTR,
+	IRQ_UART1INTR, IRQ_UART2INTR, IRQ_UART3INTR, };
+
+The initialization code reads these tables and inserts a vector
+address and enable for each indicated IRQ.  Vectored interrupts have
+higher priority than non-vectored interrupts.  So, on VIC1,
+IRQ_GPIO3INTR will be served before any other non-FIQ interrupt.  Due
+to the way that the vectoring works, IRQ_T3UI is the next highest
+priority followed by the other vectored interrupts on VIC2.  After
+that, the non-vectored interrupts are scanned in VIC1 then in VIC2.
+
+
+ISR
+---
+
+The interrupt service routine macro get_irqnr() in
+arch/arm/kernel/entry-armv.S scans the VICs for the next active
+interrupt.  The vectoring makes this code somewhat larger than it was
+before using vectoring (refer to the LH7A400 implementation).  In the
+case where an interrupt is vectored, the implementation will tend to
+be faster than the non-vectored version.  However, the worst-case path
+is longer.
+
+It is worth noting that at present, there is no need to read
+VIC2_VECTADDR because the register appears to be shared between the
+controllers.  The code is written such that if this changes, it ought
+to still work properly.
+
+
+Vector Addresses
+----------------
+
+The proper use of the vectoring hardware would jump to the ISR
+specified by the vectoring address.  Linux isn't structured to take
+advantage of this feature, though it might be possible to change
+things to support it.
+
+In this implementation, the vectoring address is used to speed the
+search for the active IRQ.  The address is coded such that the lowest
+6 bits store the IRQ number for vectored interrupts.  These numbers
+correspond to the bits in the interrupt status registers.  IRQ zero is
+the lowest interrupt bit in VIC1.  IRQ 32 is the lowest interrupt bit
+in VIC2.  Because zero is a valid IRQ number and because we cannot
+detect whether or not there is a valid vectoring address if that
+address is zero, the eigth bit (0x100) is set for vectored interrupts.
+The address for IRQ 0x18 (VIC2) is 0x118.  Only the ninth bit is set
+for the default handler on VIC1 and only the tenth bit is set for the
+default handler on VIC2.
+
+In other words.
+
+  0x000		- no active interrupt
+  0x1ii		- vectored interrupt 0xii
+  0x2xx		- unvectored interrupt on VIC1 (xx is don't care)
+  0x4xx		- unvectored interrupt on VIC2 (xx is don't care)
+