summaryrefslogtreecommitdiffstats
path: root/Documentation/ABI/testing/sysfs-driver-ppi
diff options
context:
space:
mode:
authorAnssi Hannula <anssi.hannula@iki.fi>2013-10-24 21:10:38 +0300
committerTakashi Iwai <tiwai@suse.de>2013-10-24 22:57:32 +0200
commit84d69e790f48ff2e8472a8cf602243e43683eaf0 (patch)
tree0596400b25c81148cf416c84d840d23b8cec1bcc /Documentation/ABI/testing/sysfs-driver-ppi
parent461cf6b39dded3ddb15a2300a534aba039870e5f (diff)
downloadlinux-84d69e790f48ff2e8472a8cf602243e43683eaf0.tar.bz2
ALSA: hda - hdmi: Disable ramp-up/down for non-PCM on AMD codecs
Recent AMD HDMI codecs (revision ID 3 and later, 0x100300 as reported by procfs codec#0) have a configurable ramp-up/down functionality. The documentation ( http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf ) specifies that 180 ("180/256 =~ 0.7") is recommended for PCM and 0 for non-PCM. Apply the recommended values according to provided S/PDIF AES0 settings since ramp-up/down does not make sense for non-PCM. v2: adapted to hdmi_ops infrastructure * More note from Anssi: actually, re-reading mails reveals that Olivier didn't find the expected difference with this setting, except for "maybe slightly slower startup with AES0=6" (i.e. value 0, which is unexpected). So maybe a) it makes too unnoticiable a difference, or b) only affects certain hardware (card and/or sink), or c) ramp-up/down is only triggered with the MUTE bit of ATI_VERB_SET_MULTICHANNEL_xx which is also rev3+ specific, but is not presently used by the driver, or something else. So there's a significant chance setting ramp rate is useless for us ATM, but probably does not do actual harm either. Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Tested-by: Olivier Langlois <olivier@trillion01.com> # v1 Signed-off-by: Takashi Iwai <tiwai@suse.de>
Diffstat (limited to 'Documentation/ABI/testing/sysfs-driver-ppi')
0 files changed, 0 insertions, 0 deletions