[alsa-devel] HDA codec in embedded device
thierry.reding at avionic-design.de
Thu May 31 18:52:23 CEST 2012
* 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.
> 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.
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20120531/12f76f37/attachment-0001.sig
More information about the Alsa-devel