One of the fundamental interfaces on the Motorola EZX phones is SPI, which interconnects (among others) the PCAP2 peripheral with the PXA270. Motorola ships their 2.4.20 kernel with some ugly piece of spaghetti code driver for it. Apparently they've had difficulties driving the PXA27x SPI controller, and in the end decided to just 'bit-bang' the signals over GPIO. Obviously that's inefficient and CPU-intensive. I hope there is no real hardware problem preventing the use of the embedded SPI controllers.
First I started writing a driver against arch/arm/mach-pxa/ssp.c, only to discover later that this code actually predates (and therefore doesn't use) the generic drivers/spi/ interface. Since I'm a fan of generic interfaces, I chose to write a PXA generic driver for the drivers/spi interface, plus some EZX specific glue code for it.
One of the interesting bits is that the PCAP2 can interrupt the PXA, and it then acts as an external interrupt controller, whose registers you can access over SPI. So a PCAP2 interrupt can mean that some touch-screen event happened, that the headphone, USB or microphone jack state has changed, etc. All those various real interrupt sources need to be fed to individual distinct drivers (audio, touch-screen, USB). The Motorola kernel uses an ugly kludge of callback functions that those drivers can register with the SSP/SPI driver.
So in my new driver, I choose to actually model that bit of PCAP2 functionality as an external interrupt controller. This way the actual sound/touch-screen driver can just do request_interrupt() like they usually do. However, this means that I need to access SPI from within hardirq context, which again doesn't mix well with the architecture of the drivers/spi code (which is asynchronous and queues requests). So I need to implement a couple of synchronous SPI functions in addition to that.
This is now a lot of code, and I'm about to test and debug it, which is expected to be time-consuming and boring. I'll post a status update as soon as there's more information.