No subject
Tue Aug 26 14:49:35 CEST 2008
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 <joerg at openmoko.org>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
>
------=_Part_20431_13705850.1223076336724
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<div dir="ltr">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.<br>
<br>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 <i>then</i> 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... <br>
<br>(<a href="http://wiki.openmoko.org/wiki/Image:WM8753_ALSA_Mapping.png">http://wiki.openmoko.org/wiki/Image:WM8753_ALSA_Mapping.png</a>) <--my only saving grace, but only for the controls listed on the diagram... <br>
<br>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.<br>
<br>I am using a GTA01v4- and can anyone recommend the best (most recent/stable) GTA01 standard image to use for (audio/BT) development?<br><br>-Kyle<br><br><br><br><div class="gmail_quote">On Fri, Oct 3, 2008 at 6:39 PM, Joerg Reisenweber <span dir="ltr"><<a href="mailto:joerg at openmoko.org">joerg at openmoko.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">Am Mi 1. Oktober 2008 schrieb Mark Brown:<br>
</div><div><div></div><div class="Wj3C7c">> On Wed, Oct 01, 2008 at 05:13:37PM +0200, Joerg Reisenweber wrote:<br>
><br>
> > I tried to find name of a registers this way, but this code is so nested<br>
and<br>
> > cryptic and poorly commented, I really didn't success to understand the<br>
logic<br>
> > behind the data structures and defines.<br>
><br>
> The actual register definitions are pretty direct AFAICS - the text<br>
> string with the user visible control name is immediately next to the<br>
> register names - for example:<br>
><br>
> SOC_DOUBLE_R_TLV("PCM Volume", WM8753_LDAC, WM8753_RDAC, 0, 255, 0,<br>
dac_tlv),<br>
><br>
> is a control callled "PCM Volume" at bit 0 with value up to 255 in the<br>
> LDAC and RDAC registers. Obviously, YMMV but it shouldn't be too hard<br>
> to find the user-visible name for a register bit or vice versa, I'd have<br>
> thought.<br>
<br>
</div></div>60sec reality check:<br>
PCF50633UM2.00.pdf -> search "RDAC" -> "error: no occurrence found"<br>
<br>
Also I'm pretty sure the "user visible control name" isn't exactly what you<br>
get to see in alsamixer for example. Furthermore they are often wrong as they<br>
don't regard our particular hw-setup, where GSM-mic sensitivity is something<br>
like "mono sidetone playback volume" or such weirdness.<br>
The situation resembles using a "genuine PS/2 mouse" driver for a synaptics<br>
touchpad. I really don't think there is any value or sane rationale behind<br>
using a generic upstream driver for a very OM-specific hw-design, the usual<br>
way for all hardware is manufacturer of device creates tailored-to-suit<br>
drivers for their product, admittedly based on chip manuf's generic chip<br>
driver sources usually.<br>
<font color="#888888"><br>
/jOERG<br>
</font></blockquote></div><br></div>
------=_Part_20431_13705850.1223076336724--
More information about the hardware
mailing list
