>From the last few days of hacking around with the system, I was able to make some sense of the information. Along with what Joerg had said, the state files can be a pain to sift through because they are generic or used differently in the openmoko configuration.
My largest concern is attempting to make sense of the controls, because the only way I was able to re-map them was to search the source for the generic "name" string, then look up what the register they modified was in the datasheet, and *then* determine what function the control has. It seems to be a clouded way to work with the system, considering all the documentation is generic, minus that block diagram I've been using... (http://wiki.openmoko.org/wiki/Image:WM8753_ALSA_Mapping.png) <--my only saving grace, but only for the controls listed on the diagram... It would be very helpful if I had information about how the controls are interfaced for GTA01/02, or what each of the 95 controls logically changed in GTA01/02. In addition, its difficult to determeine the funcation of controls such as #90, most capture controls due to the ambiguity. I am using a GTA01v4- and can anyone recommend the best (most recent/stable) GTA01 standard image to use for (audio/BT) development? -Kyle On Fri, Oct 3, 2008 at 6:39 PM, Joerg Reisenweber <[EMAIL PROTECTED]>wrote: > Am Mi 1. Oktober 2008 schrieb Mark Brown: > > On Wed, Oct 01, 2008 at 05:13:37PM +0200, Joerg Reisenweber wrote: > > > > > I tried to find name of a registers this way, but this code is so > nested > and > > > cryptic and poorly commented, I really didn't success to understand the > logic > > > behind the data structures and defines. > > > > The actual register definitions are pretty direct AFAICS - the text > > string with the user visible control name is immediately next to the > > register names - for example: > > > > SOC_DOUBLE_R_TLV("PCM Volume", WM8753_LDAC, WM8753_RDAC, 0, 255, 0, > dac_tlv), > > > > is a control callled "PCM Volume" at bit 0 with value up to 255 in the > > LDAC and RDAC registers. Obviously, YMMV but it shouldn't be too hard > > to find the user-visible name for a register bit or vice versa, I'd have > > thought. > > 60sec reality check: > PCF50633UM2.00.pdf -> search "RDAC" -> "error: no occurrence found" > > Also I'm pretty sure the "user visible control name" isn't exactly what you > get to see in alsamixer for example. Furthermore they are often wrong as > they > don't regard our particular hw-setup, where GSM-mic sensitivity is > something > like "mono sidetone playback volume" or such weirdness. > The situation resembles using a "genuine PS/2 mouse" driver for a synaptics > touchpad. I really don't think there is any value or sane rationale behind > using a generic upstream driver for a very OM-specific hw-design, the usual > way for all hardware is manufacturer of device creates tailored-to-suit > drivers for their product, admittedly based on chip manuf's generic chip > driver sources usually. > > /jOERG >
_______________________________________________ hardware mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/hardware
