OMAP (H4) and DaVinci

o Finally submitted pending keypad patch for H4.

Pending patches/work for H4 + some other modifications. Someone who wants to do in their free time.

o camera_core.c needs platform_driver_register structure.
o H4 camera
- David Cohen was working on that, and he had submitted patch to the list.
o H4 TSC2101 Driver
- As per the SPI framework.
- I am planning to work on this, as it can be done easily as per the new SPI framework.
o H4 TSC2101 with ALSA driver.
- Someone posted TSC2101 with ALSA driver effort on the linux-omap mailing list.
o H4 Menelaus RTC driver
- It should be implemented in the different file altogether from omap-rtc.c, as it is implemented using different chip (Menelaus).
o H4 video out driver
- As I have pointed earlier, this might take some time.
o H4 NAND Driver
- I had posted the patch on the list, but not tested fully. Kyungmin had commented on that patch, but I was not able to do followup on that.

MCBSP Framework.
----------------

- As of now, we can see that McBSP.c is becoming ugly day by day, we would appreciate if someone( or may be I) can work on ideas of writing a small framework, like SPI. I have already thought of something about it. I will down my ideas may be next week.

o Just think of adding DaVinci, OMAP2430, OMAP3430 McBSP additional code added to mcbsp.c ...and you will see that file more ugly than before :).

o Also it adds lots of #ifdefers in audio codecs chips drivers on selection of mcbsp instance, as different boards design use different instance altogether, which should ideally come from board-*.c files.

DaVinci
-------

Ah, I never wrote on this before. We/Community were supposed to get DaVinci tree code by end of Feb'06, as per some of the articles I read online.

As per my observation, GNU/Linux kernel porting for DaVinci must be going on by TI and MV from more than 8-9 months (I guess...), we can also see the name of the tree of DaVinci on source.mvista.com git trees owned by Kevin Hilman. (Do you remember this OMAP730 guy ?). But think that, if they have opened the tree to public by this now,

o they would have got early review of code they have developed
o A chance of getting free of charge patches (Yes, you do have to pay MV).
o A chance of getting a Free of Charge maintainer, who can sync it up with latest Linux kernel tree.
o A chance of getting up-to-date drivers, as you know about changing frameworks and more better code, considering that it is easy to add new custom/EVM board based on the same chip. (Think of LINUX-OMAP tree :)).
o Early decision to merge with LINUX OMAP tree, if we think that most of the code can stay common, even if both the processor series is being targetted to different customers (Think customers here as ODM/OEM guys please).

---Komal Shah