[alsa-devel] [PATCH 1/3] ARM: dt: tegra: Enable device tree audio on PAZ00 board.
leon at leon.nu
Fri Jan 27 18:03:50 CET 2012
On Fri, Jan 27, 2012 at 18:45, Stephen Warren <swarren at nvidia.com> wrote:
> Leon Romanovsky wrote at Friday, January 27, 2012 9:02 AM:
>> On Thu, Jan 26, 2012 at 00:21, Stephen Warren <swarren at nvidia.com> wrote:
>> > Leon Romanovsky wrote at Wednesday, January 25, 2012 11:49 AM:
>> >> This patch adds initial device tree support of ALC5632 sound codec and
>> >> machine driver for PAZ00 board. The implementation is based on the WM8903 codec.
>> >> +++ b/Documentation/devicetree/bindings/sound/tegra-audio-alc5632.txt
>> >> @@ -0,0 +1,55 @@
>> >> +NVIDIA Tegra audio complex
>> >> +
>> >> +Required properties:
>> >> +- compatible : "nvidia,tegra-audio-alc5632"
>> >> +- nvidia,model : The user-visible name of this sound complex.
>> >> +- nvidia,audio-routing : A list of the connections between audio components.
>> >> + Each entry is a pair of strings, the first being the connection's sink,
>> >> + the second being the connection's source. Valid names for sources and
>> >> + sinks are the ALC5632's pins:
>> >> +
>> >> + ALC5632 pins:
>> >> +
>> >> + * SPKOUT
>> >> + * SPKOUTN
>> >> + * HPL
>> >> + * HPR
>> >> + * AUXOUT
>> > My copy of the ALC5632 datasheet indicates there are both AUX_OUT_P and
>> > AUX_OUTN pins. Are they always used together such that it makes sense to
>> > group them together in the device tree binding?
>> You are right, it must be the same as SPKOUT
> I think the opposite; AUXOUT and SPKOUT aren't the same pin. I meant
> that AUX_OUT_P and AUX_OUT_N are different pins, so I'm asking why they're
> a single pin in the above pin list (and in the ASoC codec driver). In
> contrast, SPKOUT is represented explicitly as two pins which seems to make
> more sense.
Sorry for the misunderstanding, This is what i wanted to say.
>> >> + * LINEINL
>> >> + * LINEINR
>> >> + * PHONEP
>> >> + * PHONEP
>> > PHONEN
>> >> + * MIC1
>> >> + * MIC2
>> > Same as above; the datasheet lists MIC1_P, MIC1_N, MIC2_P, MIC2_N.
>> >> + * MICBIAS1
>> >> + * MICBIAS2
>> > I only see MICBIAS1 in the datasheet, not MICBIAS2.
>> You are right if you are looking on function block only (page 3), but
>> in register description you can find reference to MICBIAS2 (reg 22h,
>> microphone control).
> I do see that register bit, but the pinout doesn't include it in the
> codec's own datasheet nor the AC100 schematics. I suspect that there
> really is no MICBIAS2 feature and the register documentation is simply
> incorrect, perhaps a carry-over from some other codec? Still, I suppose
> that just in case the signal really is routed to one of the pins labeled
> "NC" in the datasheet, there isn't too much harm including it in the
> driver, and this binding.
>> >> + Board connectors:
>> > Don't you need "Headset Mic" in the list too?
>> >> + nvidia,audio-routing =
>> >> + "MIC1", "MICBIAS1",
>> >> + "MICBIAS1", "Headset Mic",
>> > I think those last two lines should read:
>> > "Headset Mic", "MICBIAS1",
>> > "MIC1", " Headset Mic",
>> > The DAPM route table in the driver probably needs updating to say the
>> > same thing too.
>> Microphone is not tested at all, so you probably right. I prefer to be
>> close as possible to previous board implementation and provide
>> followup patches to clean the microphone path.
> I guess that doesn't actually affect the structure of the binding, just
> the data contained in the properties, so it's not a big deal if it goes
> in like this. Mark might have a different opinion though, since it's
> a simple fix...
Leon Romanovsky | Independent Linux Consultant
www.leon.nu | leon at leon.nu
More information about the Alsa-devel