Subject: [E3-hacking] External keyboard (mailboard) support for 2.6

From: Matt Callow <[email-masked]>
Date: Tue, 04 Apr 2006 12:56:53 +0100

I've been working on this for a while now, but I still cant get it to 
work reliably.  I have tried installing a interrupt handler and using 
code based on serio/parkbd.c. This tries to read 1 bit every interrupt 
and doesn't work very well.I've also tried polling the entire bitstream 
after the first interrupt, this works better, but still gives false 
data. If I press a key (e.g. space), I expect to get:

0x4b  // scancode for space
0xf0  // key released
0x4b // scancode for space

But I hardly every get the 2nd 0x4b, and I don't always get the first 2 
bytes correctly either. I think this is because I am missing some bits 
due to the interrupt processing latency. Cliff Lawson said in an earlier 
post that the bit stream is clocked at about 70kHz and apparently the 
5910 can only handle about 13k ints/second on linux.

Cliff said that Amstrad used a FIQ handler to read the keyboard in the 
2.4 kernel source. There does not seem to he a FIQ handler for omap in 
the 2.6 kernel but we do have most of the amstrad code available under 
GPL. (it's in arch/arm/kernel/fiq-qwerty.S and arch/arm/kernel/irq.c). 
As far as I can tell, this works as follows:

 * fiq handler is installed
 * gpio interrupt is changed to be a fiq
 * fiq handler is invoked when a gpio interrupt is raised (in the E3 
this may be either modem of mailboard)
 * If it's a modem interrupt, pass is on (more of that later)
 * If it's a mailboard interrupt, process the next bit in the bitstream, 
once a full character is recived, pass it on

The fiq handler passes requests to irq context by faking a 32kHz 
interrupt (this means that the 32kHz timer interrupt cannot be used for 
it's orginal purpose). The 32kHz interrupt handler then reads some 
shared memory to determine which gpio interrupt(s) occured and invokes 
the appropriate handler.

The end result is that a modem interrupt generates one fiq and one irq, 
whilst a mailboard interrupt generates one fiq for every bit in the 
keyboard data but an irq is only generated when a character has been 
recieved.

There is also some code (in irq.c) to check if the fiq handler is stuck, 
and inject a gpio interrupt if it is.

So, I'm begining to think that I'll need to re-implement most of this to 
get the mailboard to work. What do other people think? It looks like 
it's going to be a fair bit of work, but, I don't really see any other 
way of sucessfully capturing the serial keyboard data.

Matt

---

From: Cliff Lawson <[email-masked]>
Date: Wed, 5 Apr 2006 18:20:22 +0100

> -----Original Message-----
> From: Matt Callow [mailto:[email-masked]]
>
> it's still useful to have. Whilst looking at the code, I noticed that 
> the qwe interrupt handler writes to latch2 
> AMS_DELTA_HDW_OP_SCARD_2_MASK 
> (I'm assuming AMS_DELTA_HDW_OP_SCARD_2_MASK is 0x400), 
> setting it at the 
> start and clearing it at the end. Is this for debug purposes only? I 
> noticed a similar thing in the FIQ handler using GPIO6.

Yup I *think* they are just being used to tickle "spare" pins to trigger an
LA or a scope. I'm kind of surprised that hasn't been removed in fact though
I'm not sure of the vintage of the tree I have on my machine (and yes it's
0x400)
 
> I also notice that the driver has some code for writing to 
> the keyboard, 
> but data never seems to be sent. Is my understanding correct? 
> Does the 
> keyboard accept data?

Well the use of it we make is because the PS/2 keyboard controller has been
known to die (sometimes as often as about once every 5 minutes in fact) -
it's a standard, masked part that we have no control over - so what we do is
send it 0xEE commands and see if it echoes. If it does all is well, if it
doesn't we switch the 5V line to it to reset the chip. But we don't transmit
anything else to it as we're happy with the scanset and typematic rates it
defaults to.

Cliff

This e-mail and any attachments are confidential and intended exclusively for the addressee. If you are not the intended recipient please delete it from your system and notify the sender immediately. This message is attributed to the sender and may not necessarily reflect the views of Amstrad Plc or its subsidiaries.

For further information on Amstrad Plc please visit our website: www.amstrad.com

Amstrad Plc.
Brentwood House
169 Kings Road
Brentwood
Essex CM14 4EF
Registered in England : No. 955321