Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3347979ybt; Mon, 29 Jun 2020 23:56:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyXv0Hh/pWWun+sC1C0Kz8FbKjGrqW9h1DQ+ChQR6vxKvB8kVzoSq+Y9yvNLVgK6LrBs2vs X-Received: by 2002:a17:906:2681:: with SMTP id t1mr15714598ejc.350.1593500194426; Mon, 29 Jun 2020 23:56:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593500194; cv=none; d=google.com; s=arc-20160816; b=1IRPYn8p/8VIBcdyJMN12FmRSpFkHUg4z72vNDfLMslD5Sl6oVsEUPyW/TRDT+cBeF FpIdfQEpukGP7UcmyuC1Zjo/yV1Dh806jdPX2W6BfuB9orq/gIIevFlKidAL1UxGR+kX 57KJDAfoFM4EB7V9TCtM7XFEXm0obowmAHcDEzQaEj/TdZwaFklFYaEEmJIITpDrzibx OabIo1J+gsWZUBtR6BfANkKLjwyQCThlA6qVqBfJnwyCQ73/Rw4V/Ynqcvrg7zomZ6Ly 6mY5JcXAvrmBApsLrRO4DNgC2pSzyhpKlm3FKHoSmZJN+FSMyGlo3GLiYGQJHQUpsFrg I9tQ== 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=ZIUDi4E2yHAg7VLurrsK8F+ejad1Aynkv8xZkRiAO0M=; b=lR/YMRcM2mPeZseprXGYL8xD2LPO0tNqLqam9+3wtghAioloARnMG30He0OJ/SfXfn PkGjpJCp7E5Wr0bGpMSOmT3FUbJ1lVExVIpF5yKoxfozdop+/CXr+Qxkb4N0t+WaxwF+ PA+Zqx+ArU5C3xkSkK2jLw91gXbyqE8Mw83KQuWtmkiw5dUkH7g0nQZM4FmquAbBRY1B yB8UJOtX/9z3eWYrmLYnb8MWLcgOAg1b4dSjzRmEEW431smobQWuagDILxdMfh+wKEWL ZEUG1/tWOpVu/w6hMW96qTxBgbKqaoieJ5xzHDVp7QCEyu/nqv+3MJkTDft5uHKeFhUR kVWA== 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 b4si1100945edk.454.2020.06.29.23.56.11; Mon, 29 Jun 2020 23:56:34 -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 S1730527AbgF3Gzm (ORCPT + 99 others); Tue, 30 Jun 2020 02:55:42 -0400 Received: from relmlor2.renesas.com ([210.160.252.172]:45097 "EHLO relmlie6.idc.renesas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730386AbgF3Gzm (ORCPT ); Tue, 30 Jun 2020 02:55:42 -0400 Date: 30 Jun 2020 15:55:40 +0900 X-IronPort-AV: E=Sophos;i="5.75,296,1589209200"; d="scan'208";a="50713470" Received: from unknown (HELO relmlir5.idc.renesas.com) ([10.200.68.151]) by relmlie6.idc.renesas.com with ESMTP; 30 Jun 2020 15:55:40 +0900 Received: from mercury.renesas.com (unknown [10.166.252.133]) by relmlir5.idc.renesas.com (Postfix) with ESMTP id 8ACCD4009408; Tue, 30 Jun 2020 15:55:40 +0900 (JST) Message-ID: <87ftadyrec.wl-kuninori.morimoto.gx@renesas.com> From: Kuninori Morimoto To: Sameer Pujar Cc: , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v4 12/23] ASoC: simple-card: Support DPCM DAI link with multiple Codecs In-Reply-To: <1d7888c7-a8cc-e891-01aa-016e31cc9113@nvidia.com> References: <1593233625-14961-1-git-send-email-spujar@nvidia.com> <1593233625-14961-13-git-send-email-spujar@nvidia.com> <874kqu1x70.wl-kuninori.morimoto.gx@renesas.com> <1e0cf6d1-bf4e-8808-5390-c8a3b7c7fe7e@nvidia.com> <87mu4lz6pt.wl-kuninori.morimoto.gx@renesas.com> <1d7888c7-a8cc-e891-01aa-016e31cc9113@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 Thank you for explaining detail at off-list mail. Your issue happen on (C) case, and you are tring to solve it. It is easy to understand if it was indicated at log area. I have imagined other system from "multiple CPU/Codec support". (A) (B) FE <-> BE (C) (D) BE <-> BE > > I'm not sure, this is just my guess. > > I'm happy if we can support it more easily :) > Right now I am trying re-use simple-card driver as much as possible > and still make it work for flexible sound cards. I will be happy to > discuss and improve the patch wherever necessary. Please help me > understand which part you think looks to be hacky. > > But, if it was difficult to keep compatibility on simple-card, > > we/you need to have new one. > Patch 17/23 and 18/23 introduce new compatible > 'simple-cc-audio-card'. Idea was to use component chaining which > allows connection of FE<->BE and multiple BE<->BE components along the > DAPM path (patch 16/23). Do you think it would be fine? This seems very complex system for current simple-card. "concept" of simple-card is simple (but "code" is not so simple...) Because of it, it doesn't assume flexible connection. Maybe your patch works for you, but might breaks other systems. Or, makes code or DT settings more complex/ununderstandable. Not sure, but my guess. Using cpu@0 node for BE is the 1st confusable point for me. Using fe/be instead of cpu/codec is easy to understand. Thank you for your help !! Best regards --- Kuninori Morimoto