Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3180400ybt; Mon, 29 Jun 2020 17:58:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy0LMPu3xbCivXUf/FKpawUsFLTc8Moh8Ylm8GuVK924jjqY0Q1cMTxzKmFEcd5l9ka4odw X-Received: by 2002:a50:f385:: with SMTP id g5mr19699356edm.347.1593478735446; Mon, 29 Jun 2020 17:58:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593478735; cv=none; d=google.com; s=arc-20160816; b=IDHDS6393layu7MSxfeg9bgqaMMiXkWRTkefsS+RkUUa5ZzOZxCgIY6ImqGWB/U4yj 5IFBw4+1dqLg/oHDcrFxkR3DUtyx6hnV0JC4q3chipzXwgkLcdAaNizdUOj8EpMvVcbI Oj8W4iCT8ykG/uSUt87Vqt2RykeiafZE6pNk95mqbqVm2/QeKcVaBAY+5PidHU+nKrMa n04k9z1ApulBTlLOZwGnKhZmrJ3YvACMUhbQWSsWtxvKihRa7PrJ2GCXOyyT4kvSpgYH iuI5atiuStRn7n9mWIj2NDQYcejyrriweTcWcjNnFx78K/1Qksye3eOmjbUiDtZvZkPt s+SA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:subject:cc:to:from:message-id:date; bh=f+pXwyLXa3RJR4jMk3C3eCc+2j2RoqhdhBMscttJBHE=; b=RQ6bu2Dj03AAh2vmK8KlYgMJccS7qmYUv2IgV9NLEpmZQQfqgdB0pRneOvS2JhJSSo c+2zQuoGSK6KPRWTdwUTL3dIWWjra8rG0ZvzrzX3My3a1W+RJpuzf5P0Hq+YvLVj3J6d h0l60DVC7g1EeCU3YpSZ6C+h4plYcSxAZaLPOoOiKJpkHQIxQi8HkUtiiaEh3e1QpYFo 7jy0/7m3uGNxb4D11+GmL4LUcbXel+vifILPgMkwWXzyd/epiA83Gp8BAwqe+grWEhxF fA+KvkRz0DcbSOUtmDwhnqCx1oFiSP3weX/2T9C5NmytqEqDs4c7/PzWOsjDezTykFlC XZAg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t23si707668edw.49.2020.06.29.17.58.32; Mon, 29 Jun 2020 17:58:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726403AbgF3A4T (ORCPT + 99 others); Mon, 29 Jun 2020 20:56:19 -0400 Received: from relmlor1.renesas.com ([210.160.252.171]:40891 "EHLO relmlie5.idc.renesas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725998AbgF3A4T (ORCPT ); Mon, 29 Jun 2020 20:56:19 -0400 Date: 30 Jun 2020 09:56:17 +0900 X-IronPort-AV: E=Sophos;i="5.75,296,1589209200"; d="scan'208";a="50884743" Received: from unknown (HELO relmlir5.idc.renesas.com) ([10.200.68.151]) by relmlie5.idc.renesas.com with ESMTP; 30 Jun 2020 09:56:17 +0900 Received: from mercury.renesas.com (unknown [10.166.252.133]) by relmlir5.idc.renesas.com (Postfix) with ESMTP id 8FFB0400389E; Tue, 30 Jun 2020 09:56:17 +0900 (JST) Message-ID: <87o8p1z81b.wl-kuninori.morimoto.gx@renesas.com> From: Kuninori Morimoto To: Sameer Pujar Cc: , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v4 10/23] ASoC: simple-card: Wrong daifmt for CPU end of DPCM DAI link In-Reply-To: <6e27daa5-331e-968b-4027-2e30aeb7d382@nvidia.com> References: <1593233625-14961-1-git-send-email-spujar@nvidia.com> <1593233625-14961-11-git-send-email-spujar@nvidia.com> <877dvq1yhy.wl-kuninori.morimoto.gx@renesas.com> <6e27daa5-331e-968b-4027-2e30aeb7d382@nvidia.com> User-Agent: Wanderlust/2.15.9 Emacs/26.3 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sameer > snd_soc_runtime_set_dai_fmt() { > ... > > if (cpu_dai->component->driver->non_legacy_dai_naming) > fmt = inv_dai_fmt; > > ... > } > > Above flips polarity for 'cpu_dai' if 'non_legacy_dai_naming' flag is set. > > 1. Hence example mentioned in the commit message does not work if my 'cpu_dai' > driver does not have this flag set. ? Do you want fo flip it ? or don't flip? It is for Codec <-> Codec connection. > 2. While it is true that we consider reference of 'Codec' mode for simple CPU<-> > Codec DAI links, for DPCM this does not seem flexible. For DPCM links CPU and > Codec are not directly connected (CPU<->Dummy or Dummy<->Codec). Please > consider, for example, if the DAI link has multiple CPU/Codecs. Which 'Codec' > reference needs to be considered? Isn't it better if we explicitly mention which > DAI we want to operate as 'Master'? I think Lars-Peter has (had ?) plan for this SND_SOC_DAIFMT_CBx_CFx flag flexibility ? Yes maybe it is needed for multi CPU/Codec system. Thank you for your help !! Best regards --- Kuninori Morimoto