Merge branch 'remove' of master.kernel.org:/home/rmk/linux-2.6-arm

README on the ADC/Touchscreen Controller

========================================

The LH79524 and LH7A404 include a built-in Analog to Digital

controller (ADC) that is used to process input from a touchscreen.

The driver only implements a four-wire touch panel protocol.

The touchscreen driver is maintenance free except for the pen-down or

touch threshold.  Some resistive displays and board combinations may

require tuning of this threshold.  The driver exposes some of its

internal state in the sys filesystem.  If the kernel is configured

with it, CONFIG_SYSFS, and sysfs is mounted at /sys, there will be a

directory

  /sys/devices/platform/adc-lh7.0

containing these files.

  -r--r--r--    1 root     root         4096 Jan  1 00:00 samples

  -rw-r--r--    1 root     root         4096 Jan  1 00:00 threshold

  -r--r--r--    1 root     root         4096 Jan  1 00:00 threshold_range

The threshold is the current touch threshold.  It defaults to 750 on

most targets.

  # cat threshold

 750

The threshold_range contains the range of valid values for the

threshold.  Values outside of this range will be silently ignored.

  # cat threshold_range

  0 1023

To change the threshold, write a value to the threshold file.

  # echo 500 > threshold

  # cat threshold

  500

The samples file contains the most recently sampled values from the

ADC.  There are 12.  Below are typical of the last sampled values when

the pen has been released.  The first two and last two samples are for

detecting whether or not the pen is down.  The third through sixth are

X coordinate samples.  The seventh through tenth are Y coordinate

samples.

  # cat samples

  1023 1023 0 0 0 0 530 529 530 529 1023 1023

To determine a reasonable threshold, press on the touch panel with an

appropriate stylus and read the values from samples.

  # cat samples

  1023 676 92 103 101 102 855 919 922 922 1023 679

The first and eleventh samples are discarded.  Thus, the important

values are the second and twelfth which are used to determine if the

pen is down.  When both are below the threshold, the driver registers

that the pen is down.  When either is above the threshold, it

registers then pen is up.

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.

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.

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.

README on the LCD Panels

========================

Configuration options for several LCD panels, available from Logic PD,

are included in the kernel source.  This README will help you

understand the configuration data and give you some guidance for

adding support for other panels if you wish.

lcd-panels.h

------------

There is no way, at present, to detect which panel is attached to the

system at runtime.  Thus the kernel configuration is static.  The file

arch/arm/mach-ld7a40x/lcd-panels.h (or similar) defines all of the

panel specific parameters.

It should be possible for this data to be shared among several device

families.  The current layout may be insufficiently general, but it is

amenable to improvement.

PIXEL_CLOCK

-----------

The panel data sheets will give a range of acceptable pixel clocks.

The fundamental LCDCLK input frequency is divided down by a PCD

constant in field '.tim2'.  It may happen that it is impossible to set

the pixel clock within this range.  A clock which is too slow will

tend to flicker.  For the highest quality image, set the clock as high

as possible.

MARGINS

-------

These values may be difficult to glean from the panel data sheet.  In

the case of the Sharp panels, the upper margin is explicitly called

out as a specific number of lines from the top of the frame.  The

other values may not matter as much as the panels tend to

automatically center the image.

Sync Sense

----------

The sense of the hsync and vsync pulses may be called out in the data

sheet.  On one panel, the sense of these pulses determine the height

of the visible region on the panel.  Most of the Sharp panels use

negative sense sync pulses set by the TIM2_IHS and TIM2_IVS bits in

'.tim2'.

Pel Layout

----------

The Sharp color TFT panels are all configured for 16 bit direct color

modes.  The amba-lcd driver sets the pel mode to 565 for 5 bits of

each red and blue and 6 bits of green.