[alsa-devel] HDA codec in embedded device

[Takashi Iwai]

At Thu, 31 May 2012 18:52:23 +0200,
Thierry Reding wrote:
> 
> * Stephen Warren wrote:
> > On 05/31/2012 12:13 AM, Thierry Reding wrote:
> > > Hi,
> > > 
> > > I work on an Atom-based platform that uses a Realtek ALC892 codec connected
> > > via HDA. The current code in patch_realtek.c seems to assume a standard
> > > desktop setup and maps the ports accordingly. The setup that I have is
> > > entirely different and involves, among other things, to reconfigure some of
> > > the ports typically used as outputs as inputs and vice versa. It'll also need
> > > to provide a way to pass through some inputs on the outputs without going
> > > through the DAC.
> > > 
> > > All of these features are supported by the ALC982, but I don't see how this
> > > could be implemented with the current driver. My question is how this could
> > > possibly be solved in a way acceptable for mainline?
> > 
> > The way I solved this was to add a machine-specific fixup rto
> > alc269_fixups[] that set up the pin default registers as required by the
> > HW prior to the parser interpreting those fields. I assume the same
> > would work on the alc982.
> 
> I've been discussing this with some people internally and we came to the
> conclusion that for embedded setups the best option might be to expose all
> possible controls and use something like the ALSA UCM to configure the
> codec to cover the different muxing options required by the setup.

Well, it's not clear to me why it must be so.
Really a bit more detailed description about your pin setups would be
helpful to understand better.

> > I think in general as Takashi mentioned, the driver assumes that the pin
> > default registers are already set up to values correct for the HW.
> > Typically, I believe this is done by the SBIOS or audio card BIOS prior
> > to the OS starting, or perhaps by EEPROM/straps in the HW. Is there a
> > way that can be made to happen?
> 
> Unfortunately we don't have access to the BIOS sources, and I believe there
> are no options to set them externally. I think the BIOS doesn't even do
> anything to those registers.

You can pass the pin default configs and other setups via "patch"
option of snd-hda-intel driver.  See
Documentation/sound/alsa/HD-Audio.txt.

> One other interesting option would be to encode this in the device tree. I've
> been investigating to use the device tree in order to describe carrier board
> differences to allow a single kernel to boot the same processor module on
> different carrier boards (the processor module could be different as well, of
> course).
> 
> This is obviously common practice on ARM but x86 is lacking a bit in this
> respect. I currently have a setup where I can associated device nodes with
> devices behind the PCI bus to configure I2C slaves and such. The same should
> be possible with HDA and codec configuration.

It's because HD-audio specification is designed to parse the pin
default config instead of passing the whole topology statically.
We've had static mapping in the past but this was a huge pain.

Of course, there might be some cases that don't match with the
standard parser.  But this doesn't mean that we need to move again to
the static mapping.  I guess it'd suffice to have some additional
codes to the codec auto-parser.


Takashi