From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AB135C54EE9 for ; Tue, 13 Sep 2022 05:40:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230079AbiIMFkl (ORCPT ); Tue, 13 Sep 2022 01:40:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230053AbiIMFkj (ORCPT ); Tue, 13 Sep 2022 01:40:39 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9CE51564FD; Mon, 12 Sep 2022 22:40:38 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 574873473C; Tue, 13 Sep 2022 05:40:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1663047637; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LL+0QmFDBXrLM+is61xFAGwnXTKxqNCWgAvg8pawgpY=; b=EaU+gESL3xtq/aEen3T6blqRalP6siQO2A4hDwumO3toCWNH7t2ywz+PKGUn/lOXzilCIV 5PsLQJfv25g4NppsZt9HuSNBzaiwQlfd8/TVLTyGwmJXBsgTr0w32V7Kpfd8r6VPBtoStx 1+jSWvNsB3iGv0XW2pORS86S0AW8XPk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1663047637; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LL+0QmFDBXrLM+is61xFAGwnXTKxqNCWgAvg8pawgpY=; b=NBwRBC0kBCjLONgs8/lnfMfslVYqM9MnUtIIK0MSn+b3kqNiBG+3TkO3PvwHE6q7J/Xswx wW7Tt3hIOaoYXYCw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 31A3613A86; Tue, 13 Sep 2022 05:40:37 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 4lN6C9UXIGMlWgAAMHmgww (envelope-from ); Tue, 13 Sep 2022 05:40:37 +0000 Date: Tue, 13 Sep 2022 07:40:36 +0200 Message-ID: <87fsgvhlwr.wl-tiwai@suse.de> From: Takashi Iwai To: Mohan Kumar Cc: , , , , , , Subject: Re: [PATCH] ALSA: hda: Fix tegra hda dp infoframe struct In-Reply-To: <20220913034410.17502-1-mkumard@nvidia.com> References: <20220913034410.17502-1-mkumard@nvidia.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 13 Sep 2022 05:44:10 +0200, Mohan Kumar wrote: > > Tegra HDA HW expects infoframe data bytes order same for both > HDMI and DP i.e infoframe data starts from 5th bytes offset. > This hw behavior mandates to have dummy bytes for dp infoframe > structure for Tegra. > > Signed-off-by: Mohan Kumar > --- > sound/pci/hda/patch_hdmi.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c > index 6c209cd26c0c..a52e764db2e0 100644 > --- a/sound/pci/hda/patch_hdmi.c > +++ b/sound/pci/hda/patch_hdmi.c > @@ -218,6 +218,9 @@ struct dp_audio_infoframe { > u8 type; /* 0x84 */ > u8 len; /* 0x1b */ > u8 ver; /* 0x11 << 2 */ > +#if IS_ENABLED(CONFIG_SND_HDA_TEGRA) > + u8 checksum; /* Tegra HW expects infoframe bytes from 5th offset */ > +#endif I'm afraid that we can't use ifdef here, as this is another module that is used not only by snd-hda-tegra. In theory, snd-hda-intel can run on Arm using the same codec driver. That is, the check has to be dynamically. Maybe we need to set a flag at tegra_hdmi_init(). If I understand correctly, Tegra uses the same byte layout for both DP and HDMI? If so, the patch like below should work instead. Of course, if that's really specific to Tegra, not generically for Nvidia graphics, the flag has to be set in a different way... thanks, Takashi -- 8< -- --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -171,6 +171,7 @@ struct hdmi_spec { /* hdmi interrupt trigger control flag for Nvidia codec */ bool hdmi_intr_trig_ctrl; bool intel_hsw_fixup; /* apply Intel platform-specific fixups */ + bool tegra_dp_workaround; /* workaround DP audio infoframe for Tegra */ /* * Non-generic VIA/NVIDIA specific */ @@ -679,15 +680,24 @@ static void hdmi_pin_setup_infoframe(struct hda_codec *codec, int ca, int active_channels, int conn_type) { + struct hdmi_spec *spec = codec->spec; union audio_infoframe ai; memset(&ai, 0, sizeof(ai)); - if (conn_type == 0) { /* HDMI */ + if (conn_type == 0 || /* HDMI */ + /* DisplayPort for Tegra: Tegra HW expects same layout as HDMI */ + (conn_type == 1 && spec->tegra_dp_workaround)) { struct hdmi_audio_infoframe *hdmi_ai = &ai.hdmi; - hdmi_ai->type = 0x84; - hdmi_ai->ver = 0x01; - hdmi_ai->len = 0x0a; + if (conn_type == 0) { /* HDMI */ + hdmi_ai->type = 0x84; + hdmi_ai->ver = 0x01; + hdmi_ai->len = 0x0a; + } else { /* Tegra DP */ + hdmi_ai->type = 0x84; + hdmi_ai->len = 0x1b; + hdmi_ai->ver = 0x11 << 2; + } hdmi_ai->CC02_CT47 = active_channels - 1; hdmi_ai->CA = ca; hdmi_checksum_audio_infoframe(hdmi_ai); @@ -3992,6 +4002,7 @@ static int tegra_hdmi_init(struct hda_codec *codec) spec->chmap.ops.chmap_cea_alloc_validate_get_type = nvhdmi_chmap_cea_alloc_validate_get_type; spec->chmap.ops.chmap_validate = nvhdmi_chmap_validate; + spec->tegra_dp_workaround = true; return 0; }