summaryrefslogtreecommitdiffstats
path: root/sound/pci/hda/patch_cmedia.c
diff options
context:
space:
mode:
authorStephen Warren <swarren@nvidia.com>2011-06-01 11:14:17 -0600
committerTakashi Iwai <tiwai@suse.de>2011-06-06 12:48:59 +0200
commit7c9359762797ba7a70bbaa6364aaecc16786ac83 (patch)
tree82830d36c0bc7d934deed1e99b9c4bb80f404b11 /sound/pci/hda/patch_cmedia.c
parentc3d52105753dafdf2d993e540cc3192f23447dac (diff)
downloadblackbird-op-linux-7c9359762797ba7a70bbaa6364aaecc16786ac83.tar.gz
blackbird-op-linux-7c9359762797ba7a70bbaa6364aaecc16786ac83.zip
ALSA: hda: Allow multple SPDIF controls per codec
Currently, the data that backs the kcontrols created by snd_hda_create_spdif_out_ctls is stored directly in struct hda_codec. When multiple sets of these controls are stored, they will all manipulate the same data, causing confusion. Instead, store an array of this data, one copy per converter, to isolate the controls. This patch would cause a behavioural change in the case where snd_hda_create_spdif_out_ctls was called multiple times for a single codec. As best I can tell, this is never the case for any codec. This will be relevant at least for some HDMI audio codecs, such as the NVIDIA GeForce 520 and Intel Ibex Peak. A future change will modify the driver's handling of those codecs to create multiple PCMs per codec. Note that this issue isn't affected by whether one creates a PCM-per-converter or PCM-per-pin; there are multiple of both within a single codec in both of those codecs. Note that those codecs don't currently create multiple PCMs for the codec due to the default HW mux state of all pins being to point at the same converter, hence there is only a single converter routed to any pin, and hence only a single PCM. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Diffstat (limited to 'sound/pci/hda/patch_cmedia.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud