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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ hardware mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/hardware
