mt9m111 support coming up

So after some minor mishaps involving a bug where all two byte writes to the sensor we're only written as a one byte we're finally getting somewhere on the mt9m111 support. As soon as I and my fellow tester, Andrea Mastellone find out a good probing sequence I aim to put the sensor into mainline.

New branch - m5602-po3030k

I received some usb snoops containing a sensor I haven't seen before using the 0xDC i2c address.
A new experiemental branch m5602-po3030k has been pushed and is currently worked. With a bit of luck we'll be able to push this one to the main m5602 branch quite quickly.

m5602 and libv4l

As noted in the last post I've been playing with the user-space libv4l library.
I've now reached some success which led me to remove a lot of complexity in the driver.

All post-processing is gone (color recovery, frame resizing) this also avoids some buffer memcopies which significally speeds up the driver. Color is much better and I've even got skype running with it.
Downsides are that it for is rather complicated to set up. You need to download the library and compile it, then either modify your LD paths to load the libraries or install them and play with /etc/ld.so.preload

I aim to soon publish this new driver together with instructions on how to properly install the driver as I really think this is the right direction to go.
Now we only need to fixup the s5k83a, s5k4aa mess and the mt9v111 sensor and we're ready to send this driver upstream.

Status on the m5602

This are the issues I'm currently working on with the m5602:

1) Removing the in kernel frame format conversion and frame resizing
Doing format conversion and resizing in the kernel is bad, as many drivers typically want to do the same kind of conversion this is better put in a user-space library.
Hans de Goede has developed the libv4l and I'm currently experimenting with it.
I have a local branch working quite fine with some applications and the image quality is better than with my own homebrewed in-kernel algorithms. One big problem that many v4l2-apps have bugs in them requiring patching for them to work with libv4l. As some applications are dead upstream (I'm looking at you XawTV) there are going to be some compatibility issues.
Another issue is that in-kernel frame resizing won't be supported as we need to bayer-decode before doing a frame resize.
A main goal is to get skype working with libv4l as this is heavily requested by the community, but so far I haven't got it working. I'm currently discussing this issue with Hans and hope that it's resolveable.

2) Sorting out the s5k83a, s5k4aa mess
I've been collecting usb snoops from various people with samsung sensors in hope of adding support for more machines. The current support is not good as it only covers a subset of cameras and with varying degrees of success. My current work flow has been to gather snoops and produce init sequences for different machines and letting the snoop submitter testing them out. S o far the success rate has been low and I'm currently trying to figure out why it doesn't work.
Initially my assumptions were that only one samsung sensor was used, the s5k83a, later research indicate the we're (at least) having two different sensors with the s5k4aa as the second. They seem to be somewhat similiar in setup but I think that we'll be best off having two different sensor setups for them both. The biggest issue is the lack of datasheets for these chips, making it almost impossible to figure out what the register writes are doing.
I have tried to request datasheets from Samsung but am sofar unsuccessful.

3) Reverse-engineering the actual m5602-chip
There haven't been much progress on this front. I know at least have a lot of different dumps from different sensors which gives more information on how to configure the chip. Trouble is that the most configuration seem static over the whole range of chips with no information on how to change frame encoding or frame size.