- Passing platform_data to devices attached to AC97 bus
This is actually the most revolutionary change. It allows passing platform_data (values like IRQ line, sampling frequency and many others) to devices connected to AC97 bus. This wasn't previously possible and the values were mostly hardcoded into the drivers or were using helper functions to pass the platform_data (which is not nice, but was inevitable). With this change, you can now easily set up a structure containing the parameters for your AC97 device inside your platform definition file and pass it to the AC97 device.
Also, I converted the wm97xx-battery driver to utilize this change and prepared a patch that converts all platforms using this driver to pass the platform_data properly.
Another change related to this are cleanups in the wm97xx-battery driver, but also there's a patch queued that adds IRQ-driven charger detection. This means the driver doesn't have to poll the charger state anymore.
Also, I'm planning to convert the Mainstone Accelerated Touch driver to use this patch as it contains hardcoded values.
There's also one more patch related to the sound part of wm97xx, but this time it's Palm-specific. I converted palm27x-asoc driver to use jack detection api. With this change I could have removed all the buggy GPIO handling code from there and leave the jack detection to the subsystem which is passing it to the userspace as a keypress event. I also used this pxa27x-asoc hacking opportunity to fix a few minor issues in there.
The above patches are pretty much ready and should hit 2.6.32
- Fix broken pxaficp-ir driver and improve it
This driver wasn't probably tested for a long time, therefore noone noticed the breakage. Since I was tinkering with kbdd and needed IrDA working on the Palm, I noticed this. The fix was fairy simple and is already submitted to kernel mailing list.
Hand in hand with this goes another patch, a patch that removes redundant code from platform definition files concerning pxaficp-ir. I noticed most of the platforms used very similar initialization, controlling and shutdown routines where often a particular GPIO was requested in the initialization routine, toggled according to IrDA mode in the controlling routine and freed in the shutdown routine. Therefore I took all this, put it into pxaficp-ir, added two more entries (.gpio_pwdown, .gpio_pwdown_inverted) into pxaficp platform_data structure and converted all the platforms in question to use this. This also fixed a few oversights in the code. Though some platforms still has to use the old way (mainstone, lubbock to name a few) since their IrDA routines are much more complicated then toggling a GPIO.
Actually, this GPIO toggling thing is happening because most of the IrDA transceivers have around 5 pins, those are Vcc, GND, TXD, RXD, PWDOWN. The PWDOWN pin is interesting, since by pulling it high it blocks the transceiver (disconnects the logic) so it can't either transmit or receive anything. This approach is used on pretty much everything (not only PXA board) since it's cheapest and easiest to do.
Those two will hopefully hit 2.6.32 as well.
- I put together NAND driver for Palm T|X
This driver uses the gen_nand driver, therefore all of the controlling routines are implemented in platform definition file. So far so good. The really bad part is Palm hardware engineering squad probably had some issues (better leave it at this since I don't want to insult anyone). They connected the NAND flash in very obscure way. As you can see on the schematic*, the CLE (Command Latch Enable) and ALE (Address Latch Enable) lines of NAND are connected to pretty high MA (memory address) lines of CPU. This makes allocating two memory regions a must to drive those pins. Allocating one continuous region would be unthinkable. Actually, vast majority of hardware manufacturers wire the ALE and CLE pins of NAND flash to low memory addresses. But otherwise the wiring is quite fine.
* this is available thanks to Ales 'snua12' Snuparek who took apart broken Palm T|X and gave me a board with no components on it so I can trace the connections from CPU to NAND
- I added Palm Universal Wireless Support into kbdd
This was quite a quick hack. I had to switch the pxaficp-ir off in kernel in the end though, reconfigure the ttyS2 port as STUART and toggle the PWDOWN GPIO using the GPIO API through sysfs since pxaficp-ir is a network device and the keyboard surely doesn't speak ethernet frames, therefore all what the keyboard generated was dropped even before it entered the network stack. I think we might need some middle layer here, between where RAW IrDA frames are unpacked and network layer, from which we can get raw keyboard data, but that's not important now and needs to be properly thought through. Well since I has the port in STUART mode, I had to implement cruncher for IrDA frames. They are pretty simple so it wasn't a problem. Otherwise the keyboard protocol was simple. What the keyboard actually says is 6 byte sequence: [XBOF][BOF][keycode, highest bit (7) is indicating keypress][previous byte, but bit-inverted][probably CRC, no idea][EOF].
This patch, if wasn't already applied will be applied soon.
- LMS283GF05 LCD SPI controller driver
This hit mainline through the -mm tree. There's an article about this driver earlier this month.
- The never ending tale of serial port power management hook goes on
But this time it actually moved somewhere. Russell came up with some vast patch for selectively registering UARTs on PXA from platform definition files. If this patch will be combined with mine, which adds the hook, this tale might actually have a happy ending meaning we will finally be able to switch the level shifters and similar chips attached to UARTs on and off without pain.
- UCB1400 touchscreen shivering
Today, a friend of mine reported me that ucb1400_ts driver pretty much sucks. I gave it a go and he was right. Therefore we had two absolutely different platforms, but the same problem, the touchscreen was barely usable because of the shivering. The cursor was jumping like crazy even if the touchscreen was properly calibrated and all. He also suggested to check the ADCSYNC pin as it might help. So I started investigating around that. Not too long after that I noticed a kernel parameter which was set to 0 by default and which enables utilization of ADCSYNC pin by the touchscreen driver. Setting that to 1 made the touchscreen calm down and with that it works beautifully. I'm thinking of setting it to 1 be default in kernel and using the kernel parameter to set it to 0 since most platforms, if not all, have that pin connected (it's necessary to sync the touchscreen with LCD as not being in sync is the cause of shivering).
- Updates to Palm Tungsten|C patches
I also updated to Palm Tungsten|C patchset to incorporate the ucb1400 change as well as a few other fixes.