HDA codec in embedded device

HDA codec in embedded device

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 684 bytes --]

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?

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: HDA codec in embedded device

[Takashi Iwai]

At Thu, 31 May 2012 08:13:02 +0200,
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.

The driver doesn't assume any "typical" ports.  It just looks at the
pin default configuration values, then defines the routes and assigns
the mixer elements.

> 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?

Give a more cocrete example which pin plays which role.
If the auto-parser doesn't provide the useful setup with that
configuration, we can either improve the auto-parser code or add a
static configuration like the earlier verison of the driver.


Takashi

Re: HDA codec in embedded device

[Stephen Warren]

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 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?

Re: HDA codec in embedded device

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 2476 bytes --]

* 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
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.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: 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