The AD1888 driver itself is believed to be in good shape, other than testing that all unused parts of the chip have been correctly powered down.

There are two additional items:

o control of the hi-pass filter in the AD1888, which is under control of an undocumented bit in an undocumented register
o control of the capacitive coupling circuitry on the OLPC PC board that is under control of a GPIO pin of the ENE embedded controller.

The first of these is from mail from Miller Puckette:

Tonight I talked with Gero Leonardo at Analog Devices who told me

that there is indeed a high-pass filter in the AD1888 input chain.
There is, moreover, a bit in a testing register that can turn it
off. One sets bit 12 of register 5C (hex) to one to disable the
high-pass, and to zero to enable it (the default.) This is
the 0x1000 bit in C parlance. As usual, the

correct thing to do is to read the register, 'or' the bit in or

'and' it out, and rewrite.

I tried this and behold, DC voltage measurement works!

Gero warned me that the precision of DC measurement might be

substantially less than for AC, but at first glance it looks
fine for my purposes at least.

Change History (23)

These are the two commands to turn the bit on from user level:
(the first command is for the VREFD bit)
echo "76 6420" > /proc/asound/card0/codec97#0/ac97#0-0+regs
echo "5C 1000" > /proc/asound/card0/codec97#0/ac97#0-0+regs

Note that the AC97 driver has to be built in debug mode for this to work.

Mark, Jaya; IIRC, someone told me that some microphones liked having the
bias voltage applied, and some did not. Is my memory correct? Is there
an ALSA control for this bias voltage)

Yes. Please use the "V_REFOUT Enable" control, it is part of mainline,
it determines whether or not the bias voltage is applied. The
undocumented register in AD1888 "High Pass Filter Enable" is also part
of mainline.

sensor input mode seems to be working from reports gathered, I haven't tested it myself though.

Unless some code has magically written itself, the driver work is incomplete: Jaya Kumar wrote the Alsa control for analog input, but there is no support at a platform level to tell the EC (embedded controller) to disable/enable the capacitive input coupling.

I had a significant conversation today with Jaya about how adding the platform specific code might be added to the AD1888 driver cleanly. I suggest getting in contact with me/him to understand this issue fully.

Fundamentally, there are three parts to this:

an Alsa control for the analog in (done by Jaya Kumar)

support for disabling the high pass filter that the AD1888 has in a previously unknown bit in an undocumented (before above) register. (this may or may not be implemented)

What I suggested to Jaya today, was that our OLPC platform specific code call an entry point passing in function pointers to functions that will control the embedded controller's interface to the capacitive input, and then the driver, if these pointers are not null, will call back into the platform specific code to implement the disabling/input of the capacitive input coupling.

The GPIO for the capacitive coupling is changed on Btest!
The sequence of IO read/writes that Jaya described in later e-mail should be modified.
To hide the h/w implementation from s/w programming, I proposed attached EC commands 0x01 and 0x02 before.
This implementation will be EC released this weekend.

The GPIO pin assignment has changed for B2, so we need to modify the code that configures the MIC input for AC or DC coupling. The bypass switch used to be controlled by the EC, but as of B2 it is controlled by GPIO 01 on the 5536.
Therefore, it's no longer possible to use an EC command to switch it on and off.

To put it in DC coupled mode you now have to write 0x0002 the GPIO_OUT_VAL register,
and for AC coupled mode, you write 0x20000 to that same register.

This, of course, needs to be dependent on the board type. A-test and B1 use the EC
method, B2 uses the 5536 GPIO method.

Yes. There are two tasks pending in order to support analog input mode on B2. These are kernel support for board identification and a generic gpio subsystem. The latter is necessary, otherwise the different gpio users will have conflicts. Jordan Crouse's email from Jan 16 says he is working on both of these tasks. Once that's done, the audio driver can use that and analog input mode on B2 will be feasible.

MIC input. Record gain register (index 0x1c) set to 0 (== 0dB gain), mic boost off (no +20dB extra gain). Codec hipass filter off (0x1000 bit set in register 0x5c). DC coupled input (5536 GPIO01 high). Vrefout (MIC bias) on (2.3 V open circuit). I control the input voltage with a 26K POT from MICin to ground, measuring the voltage with 3-digit VOM and adjusting POT for various voltages. (The POT forms a voltage divider with the 3K MIC BIAS resistor). Using the OFW audio driver to capture 1/2 second of samples at 8000 samples/sec, calculating the average value of the left channel samples.

The digital output value is 0 at 1.18 V, -32768 at 0.41 V, +32768 at 1.96 V. Over most of that range, the analog-to-digital gain is 43000 counts/volt, and appears to be fairly linear within my measurement precision.

If I change the record gain register value to 0x808 (+12 dB, a voltage gain of 4), the 0 point remains at 1.18 V, and the range shrinks to 0.99 V .. 1.37 V, which is 1/4 the previous range.

A similar result hold for the maximum record gain setting - the range shrinks by the amount corresponding to the voltage gain equivalent of 22.5 dB.

Note that this input range (1.55 Vpp) is rather less than the AD1888 data sheet implies (2.83 Vpp), but that might be related to the fact that we are running with
Avdd = 3.3 V instead of the 5 V that the data sheet calls out.

The needed infrastructure is in the experimental kernel, and the audio driver has been patched to detect the board revision and use either the EC or GPIO pin as the case may be. The mixer seems to be behaving correctly - the GPIO pin gets correctly changed when I change the mixer setting, but obviously more testing is required.

Once we are reasonably happy with this, then it should be pulled into the stable tree (along with the infrastructure, of course).