Saw your messages in IRC. Once we newer kernel is pointed, I have Xorg 1.9 drivers we can use.
There's a new interface for the Tegra drivers that isn't in 2.6.32, hence the need for a newer kernel.
Yes.. I suspected that. Most people fail to see that there was a HUGE rewriting of the tegra hardware support from the .32 kernel to the .36 kernel. Specifically, the .32 version used a so called a proprietary NVODM/NVDDK software layer that does the actual hw interface of linux OS to the tegra SoC. And linux drivers simply call this software layer.
This "compatibility layer", i guess, allowed NVidia to write generic drivers, independant on the OS... so they use the same drivers for WinCe and also for Linux... But, that also implied that the drivers do not fully integrate into the linux kernel.. To make them generic, they had to factor out all the not shared features between wince and linux... And, as a curiosity, there are 3 build targets for that layer: WinCE (ARM), Linux (ARM), and X86(x86). I do suspect there were plans to produce a Tegra chip with an x86 compatible CPU... Just a curiosity.
Specially important, is/was power management for mobile devices... Something that can be much better implemented if writing native linux drivers. And, also, if nvidia wants to push tegra support into mainline, no such wrappers are allowed.
So, seems, Google and NVidia teamed to produce a new linux kernel, now based on .36 version, that does not use that "hardware abstraction layer", directly implementing all tegra support in native linux drivers.
In the process, they added several new drivers that were not in the .32 kernel, related to power management, and video and audio acceleration and 3d graphics.
Those new drivers are used by the new BSPs NVidia is providing, so, if we want improved graphics acceleration, improved video/audio decoding/encoding, and all new advantages of the new NVidia supplied BSPs (BSP if for me the user level drivers supplied by nvidia: OpenGL ES, OpenAL,accelerated video and audio encoding/decoding.. Flash support, etc), we need a kernel with the new interfaces.
But, here, there is a hole... NVidia/Google focused primarily on Stingray platform (the one used by Motorola Xoom), and added preliminary support for Harmony and Ventana... Preliminary means incomplete... Because Harmony and Ventana are hw/sw development systems comprised by a main board containing the tegra chip, and power sources, and several optional daughter boards containing video output/LCD output/SDIO/audio input and output. The same applies for Ventana development boards
But, NVidia/Google didn't implement support for any of those daughter boards. They JUST implemented support for Harmony/Ventana mainboard.
Our tablet (Advent Vega/Suttle/POV/several others based on P10AN01) are based on the Harmony design, but incorporate some of those dautherboards of Harmony/Ventana used to display video in an LCD/output audio, in the same main board.
So, if we use the Harmony target of the .36 board, we won't get neither input facilities, nor audio facilities working. But, the Tegra itself should try to boot (and probably, it won't succeed, as Harmony stock kernel has a different method of booting..) ... But, the HArmony target, even if useless as it is right now, still provides all the drivers required to use each and every internal peripheral of the tegra SoC, including Video and audio acceleration.
So, the question is ? - What is missing to make a useful kernel from what we have ? -- And the answer is... We need to write drivers for each and every external device to the Tegra SoC that was supported in the Harmony development system as a daughterboard... That means:
>Accelerometer (we have a .32 driver for it... BCM150, we must port it to .36, but make it support the standard linux input subsystem, and we have the datasheet of the chip)...
>Touchscreen: Seems there are 2 types.. One of them is based on IT7260...We have a driver for the .32 kernel that uses undocumented hacks to send commands through non standard means... The hacks must go away... and we have "something like" a datasheet of the chip... A text version of the PDF retrieved from google cache...
>SDIO (mmc card slot, AR6000 wireless
>Audio codec initialization (using an ALC5624)... We got a driver for that chip , but it is for the .22 kernel.. It must be ported to the .36 kernel...
>Bluetooth power management
>GSM/GSM/UTMS power management.
>Battery fuel gauge and charger.
>LCD configuration and backlight configuration
Well, we must write drivers/refactor existing drivers for each and every piece of that, plugging them into the .36 kernel. And also, fill in several tables describing the relationship between all those drivers, so the kernel knows how to configure each internal device of the Tegra SoC to support those external devices.
Then, if everything works, we will get a fully functional kernel for Vega.
Now, the state of things right now:
I have written/rewritten/refactored/ported each and every required driver, and i also wrote/filled in all the required tables to describe the vega hw. Each and every one of them. So you have an idea, it has taken so far more than 100 hours of continuous work.. Taking into account this is not my main job, and that i am doing it in my free time, and that i am not paid for doing it, it is a ver considerable effort i have put on this.
The only thing that is still pending is the refactoring of the audio codec driver. I have, in fact, started to port the .22 driver to the .36 driver, but there were lots of changes in the audio subsystem from .22 to .36, so it will take some time to check -- And that is exactly what i've been doing.. Still some things to check and refactor on that driver.
So, once the audio codec driver is done, i ll be able to compile the kernel and start debugging it. Hopefully, it won't take much time to have a fully working .36/.38 kernel for vega, as i do expect most written drivers will be already working.
So you know the state of things right now...