Subject: Designing a keyboard controller

From: "J.D. Bakker" <[email-masked]>
Date: Mon, 13 Sep 1999 23:55:36 +0200

[Hope this is not too off-topic...]

Hi all,

I'm designing an embedded StrongARM-based system[1] that I want to use with
Linux. I need to design a keyboard/mouse interface for this beast, and
going by the kernel sources PS/2 seems the way to go (I'd really like to
use commodity hardware to talk to X and friends).

I've since found notes on how to capture a PS/2 stream with a
microcontroller, but I don't know what the best interface is to offer
Linux, ie what should the hardware look like when seen from the kernel .
I'd rather not use an 8042 ;-), but I'm open for other suggestions. The
StrongARM has an I/O space that is almost but not entirely unlike ISA, and
I have some GP I/O pins to spare. Does anyone have an idea what the best
interface would be ?

Sincerely,

Jan-Derk Bakker

[1] the Linux Advanced Radio Terminal or LART; 32MB, >200MIPS, <1W,
pictures at http://www-ict.its.tudelft.nl/~erik/open-source/LART/ . I'd
like to release the hardware design under a GPL-like license; please
contact me off-list if you have any suggestions on the legalese that is
unavoidably involved.

--
"... I've seen Sun monitors on fire off the side of the multimedia lab.
 I've seen NTU lights glitter in the dark near the Mail Gate.
 All these things will be lost in time, like the root partition last week.
 Time... to die...". - Peter Gutmann in the scary devil monastery

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Nicolas Pitre <[email-masked]>
Date: Mon, 13 Sep 1999 20:51:33 -0400 (EDT)

> I have some GP I/O pins to spare. Does anyone have an idea what the best

Whatever hardware you need, the best is really to use something that can
be atached to the so called pcmcia bus on the SA1100.  You might need some
logic to decode the address and activate a chip-enable signal if you have
more than one port to address.  A GPIO, preferably between 0 and 10, can
be used as interrupt line.

With such a setup around the SA1100, current ISA drivers can be used with
very minimal modifications as long as they aren't using DMA.  The kernel
code for the SA1100 already provides access to that bus through the
in*()/out*() macros.  You then have plenty of choice for an interface 
chip.

Nicolas Pitre
[email-masked]
[email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Tue, 14 Sep 1999 10:35:39 +0100

>That looks like a good solution. The question remains then: what does an
>8042 'look like', as seen from Linux ?

Just a set of data and status registers really.  See drivers/char/pc_keyb.c, 
or the RiscPC keyboard driver for another way of doing things (the Acorn 
hardware provides its own PS/2 interface).

>A semi-related question: is it possible for multiple different devices on
>an ISA-ish bus to share an interrupt *on the processor side* ? For example,
>say I have a custom PIC which multiplexes (logic OR) the interrupt output
>of a keyboard controller with the interrupt output of an IDE controller
>onto one interrupt line for the processor. Does this work, or do I break
>any hidden assumptions in either the keyboard or the IDE driver ?

That should be fine.  The IDE driver can already share interrupts; not sure 
about the keyboard driver but it could be taught to do so easily enough.

p.

---

From: "J.D. Bakker" <[email-masked]>
Date: Tue, 14 Sep 1999 09:41:01 +0200

[designing a keyboard controller to work with Linux]

That looks like a good solution. The question remains then: what does an
8042 'look like', as seen from Linux ? I want to mimic the ISA side of a
regular keyboard controller (without actually cramming a 40pin DIL chip on
my 7.5x10cm PCB :-P). Does anyone have pointers to documents on this ?

Sincerely,

JDB.

--
Jan-Derk Bakker, [email-masked]

The lazy man's proverb:
    'There's no business like slow business !'

---

From: Nicolas Pitre <[email-masked]>
Date: Tue, 14 Sep 1999 09:00:14 -0400 (EDT)

> any hidden assumptions in either the keyboard or the IDE driver ?

Some drivers are able to share interrupts.  However you might consider
using multiple GPIOs for each device IRQs if performance is critical.

Note that if you use GPIOs above 10, they will all trigger the IRQ 11 in
the CPU which requires all drivers to share IRQ 11, even if the GEDR show
them separately.

Nicolas Pitre
[email-masked]
[email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Tue, 14 Sep 1999 20:28:23 +0100

>Shared IRQs only work if all devices on the IRQ line agree to be sharable.
>The way the IDE driver currently works in Linux is that it's IRQ is only
>sharable if and only if it's "chipset" is on PCI.

Oh yeah.  Well, the change to make it share irqs on other systems looks like 
it should be trivial enough.  Ditto the keyboard driver actually, from a quick 
glance at it the irq routine will safely do nothing if it gets unexpected 
interrupts.

p.

---

From: [email-masked]
Date: Tue, 14 Sep 1999 19:49:33 +0100 (BST)

> about the keyboard driver but it could be taught to do so easily enough.

Sorry to drop in some bad news, but it seems that some people have a
misunderstanding of the shared IRQ system.

Therefore, you would have to teach the IDE and the keyboard driver to
share interrupts.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Robert Kondner <[email-masked]>
Date: Tue, 14 Sep 1999 21:27:51 -0400

Hi,

  Some years ago I wrote a keyboard driver using 2 parallel IO 
bits. These were in a FPGA, logic allowed one line (KBCLK) to generate
interrupts when it changed states. I decoded Scan Code Set 2. I think
the PS/2 format is Scan Code Set 3, and it would be easier. This was
about 5 weeks of code, and required lots of tweaking with various
keyboards. Various keyboards do things a little different, ACK timeing,
Reset Functions were real problems. Newer keyboards (>1997) seemed 
more consistent.

  If you have specific question give me a shout. I suggest a small
FPGA to unload the ARM. There were a number of timing function that
were done in software. During some exception it took 100's of microsecs
in the ISR. The FPGA logic would off load this.

  Having done it the hard way those 8042 devices look real nice. I have
a real respect for the code in those things.

Bob Kondner