Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754139Ab3JBObj (ORCPT ); Wed, 2 Oct 2013 10:31:39 -0400 Received: from cantor2.suse.de ([195.135.220.15]:49282 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754084Ab3JBObf (ORCPT ); Wed, 2 Oct 2013 10:31:35 -0400 Date: Wed, 02 Oct 2013 16:34:11 +0200 Message-ID: From: Takashi Iwai To: Anssi Hannula Cc: alsa-devel@alsa-project.org, Peter =?UTF-8?B?RnLDvGhiZXJnZXI=?= , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , Olivier Langlois , linux-kernel@vger.kernel.org Subject: Re: [RFC/RFT v2 0/4] ALSA: hda - hdmi: ATI/AMD multi-channel and HBR support In-Reply-To: <1380659456-3746-1-git-send-email-anssi.hannula@iki.fi> References: <1380659456-3746-1-git-send-email-anssi.hannula@iki.fi> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5248 Lines: 126 At Tue, 1 Oct 2013 23:30:52 +0300, Anssi Hannula wrote: > > Hi all! > > Here is a second revision of the ATI/AMD multichannel patch, now a > patchset. > > Since the last revision from a bit over the week ago, AMD has released > more documentation ( http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf ), > so the patchset contains new additions: > > - HBR bitstreaming support (HD passthrough, for DTS-HD and Dolby TrueHD) > o This completes the set, now we have HBR on NVIDIA, Intel and AMD :) > > - More complete ELD emulation on revision 3+ (0x100300) codecs > o Untested, though from what I can see the newly added fields may not > be filled in yet by the radeon driver. > > - Ramp up/down configuration according to non-pcm bit on rev3+ > o I guess this means gradual fade-in/out? Untested. > > Other changes since the previous post: > - ELD emulation moved to hda_eld.c and cleaned up a bit > - Some fixes to hdmi_chmap_ctl_tlv() changes > (and maybe something else I forgot - if so, sorry) > > Also, the pairwise channel mapping code has been tested to work with > custom channel maps. The TLV contents are shown as follows by amixer: > | chmap-paired=FL,FR > | chmap-paired=FL,FR,NA,LFE > | chmap-paired=FL,FR,FC,NA > | chmap-paired=FL,FR,RL,RR > | chmap-paired=FL,FR,FC,LFE > | chmap-paired=FL,FR,NA,LFE,RL,RR > | chmap-paired=FL,FR,FC,NA,RL,RR > [etc] > > Rafał, do you know about the missing (AFAICS) support for lipsync (F7B) > and sink information (F81) in radeon driver? > > This patchset requires at least more testing before it should be applied. > > A few other somewhat open things: > - I named everything ati/ATI except for is_amdhdmi_rev3() and > has_amd_full_remap_support() that are AMD-only, though AMD-only verbs > I still named ATI to have similar names to other verbs. Does that > seem sensible or how should this be done? > - Currently setup_audio_infoframe() writes the channel mapping every > time for ATI/AMD, should we try to avoid that? If so, any > suggestions? > (argh, just noticed this is broken for manual channel maps on non-ATI; > if just the chmap is changed, channel mapping is not updated; > so this requires fixes in the generic side as well) > > I'm especially interested in testers with: > > - Older codecs other than 0x1002aa01. My best guess still is that the > new code works on them as well. > o On these I'd like to know if multichannel and the new formats > work, i.e. e.g. > speaker-test -D hdmi:CARD=Generic,DEV=0 -c8 -r192000 -F S32_LE > > - Codec 0x1002aa01 revisions 0x100300 (Rev ID 3) or later (see > /proc/asound/cardX/codec#Y). These are HD7750+ I think. Stuff to be > tested on these: > o The ramp up/down stuff, i.e. patch 4. Is there any difference seen > with these, in the beginning/end (i.e. fade-out/in): > speaker-test -D hdmi:CARD=Generic,DEV=0,AES0=0x04 -c2 -r48000 > speaker-test -D hdmi:CARD=Generic,DEV=0,AES0=0x06 -c2 -r48000 > Also, is there a difference in the beginning of these > (maybe garbage sound and/or slightly slower startup?): > aplay -Dhdmi:CARD=Generic,DEV=0,AES0=4 -r44100 -f s16_le -c2 testi.dts.cut.spdif > aplay -Dhdmi:CARD=Generic,DEV=0,AES0=6 -r44100 -f s16_le -c2 testi.dts.cut.spdif > > o Contents of /proc/asound/cardX/eld#0. I'd like to see the contents > both with radeon and with the proprietary fglrx driver in use > > Olivier, can you test again on your rev3 hw? :) > > The patchset can be found in combined form (for e.g. testing purposes) at: > http://onse.fi/files/atihdmi5.patch > > The test file referenced above can be found at: > http://onse.fi/files/testi.dts.cut.spdif.gz (just regular DTS) > > Anssi Hannula (4): > ALSA: hda - hdmi: Add ATI/AMD multi-channel audio support > ALSA: hda - hdmi: Add ELD emulation for ATI/AMD codecs > ALSA: hda - hdmi: Add HBR bitstreaming support for ATI/AMD HDMI codecs > ALSA: hda - hdmi: Disable ramp-up/down for non-PCM on AMD codecs The patches generally look good, but I'm thinking whether it's cleaner to create a new ops items. Maybe it can be specific to HDMI codec, e.g. struct hda_hdmi_ops { int (*get_chan_slot)(struct hda_codec *codec, hda_nid_t pin, int slot); int (*set_chan_slot)(struct hda_codec *codec, hda_nid_t pin, int setup); int (*set_ca)(struct hda_codec *codec, hda_nid_t pin, int ca); .... } It's not sexy to have a thing like is_atihdmi() in the common header and see it in everywhere. thanks, Takashi > > sound/pci/hda/hda_eld.c | 157 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > sound/pci/hda/hda_local.h | 5 +++ > sound/pci/hda/patch_hdmi.c | 424 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------ > 3 files changed, 547 insertions(+), 39 deletions(-) > > -- > Anssi Hannula > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/