[alsa-devel] HDA codec in embedded device
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
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
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?
* 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
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
participants (3)
-
Stephen Warren -
Takashi Iwai -
Thierry Reding