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 X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 93CF8C54FCB for ; Wed, 22 Apr 2020 22:41:01 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1C5082074B for ; Wed, 22 Apr 2020 22:41:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="VknL3E27" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1C5082074B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 73297169C; Thu, 23 Apr 2020 00:40:09 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 73297169C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1587595259; bh=DY2zYIls/Nnn/qbge4Gm6+EobXCCM8lj6/K/Cti0b0s=; h=Subject:From:To:Date:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=VknL3E27iMZ0XVQasXKemcKg/xkhj7nD+uwXEz2uekJUOTvatnmBl5XuDQ2yoOeBg eTuiXZEmEYCba/D1YlYsJBc/ES4I9Kb36K6EBVVxL18xGIaY/J2KqrZ6OrO5MUHAIS Q4pHFeqZbBnJ4vYdmZBgHvcrZ3LGfW9aLq+Nv8vU= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id D10C6F80142; Thu, 23 Apr 2020 00:40:08 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id AF839F801D9; Thu, 23 Apr 2020 00:40:06 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id D97BCF800F2 for ; Thu, 23 Apr 2020 00:40:02 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz D97BCF800F2 IronPort-SDR: l887Bgr34Lm0KP7B9Z3gE0QEbg3ofYGXk4+w8bxtmfQLa2/yz1MlAi1lHlAqRgKyhfZBXvXaD+ oYwziO0nh83w== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Apr 2020 15:39:59 -0700 IronPort-SDR: 6KcZIDgHNFgXHvJepoRz7a8Ga3rtEvz1kejbSOwv81iDWhL8X5tYRaWuuUl3/EIag2LyP9KljY 0u7xm/wuIs/A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,304,1583222400"; d="scan'208";a="292088532" Received: from aacostaz-mobl.amr.corp.intel.com ([10.255.74.8]) by orsmga008.jf.intel.com with ESMTP; 22 Apr 2020 15:39:59 -0700 Message-ID: Subject: Re: [PATCH 0/4] ASoC:: don't use snd_soc_rtdcom_lookup() From: Ranjani Sridharan To: Kuninori Morimoto Date: Wed, 22 Apr 2020 15:39:58 -0700 In-Reply-To: <874ktbuq4j.wl-kuninori.morimoto.gx@renesas.com> References: <87d080unyx.wl-kuninori.morimoto.gx@renesas.com> <874ktbuq4j.wl-kuninori.morimoto.gx@renesas.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: Kate Stewart , Cezary Rojewski , Jie Yang , alsa-devel@alsa-project.org, Liam Girdwood , Richard Fontana , Shunli Wang , YueHaibing , Pierre-Louis Bossart , Jiaxin Yu , linux-arm-kernel@lists.infradead.org, Vijendar Mukunda , Stephen Boyd , Mark Brown , linux-mediatek@lists.infradead.org, Eason Yen , Matthias Brugger , Thomas Gleixner , Allison Randal , Takashi Iwai , Ravulapati Vishnu vardhan rao , Colin Ian King X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Thu, 2020-04-23 at 07:12 +0900, Kuninori Morimoto wrote: > Hi > > Hi Ranjani > > > > These patches are tring to not to use snd_soc_rtdcom_lookup() > > > function > > > on each drivers as much as possible, because we might have same > > > name > > > component under multi component situation. > > > It can't find correct component in such case. > > > > > > I tried to add new feature on each drivers to not to use it, > > > but I can't test. > > > Thus, these patches should get Acked-by or Tested-by from each > > > drivers > > > user/maintenor. Please test these. > > > > > > After these patches, Intel / SOF drivers are still using > > > snd_soc_rtdcom_lookup(). Because it is very complex, I couldn't > > > try > > > not to use it. > > > If possible, each drivers should try to not use it, > > > and it should be removed from ASoC. > > > > Morimoti-san, > > > > For my education, I understand the concept of multi-cpu/codec > > components, but when or who would need multiple platform > > components? > > This would help me able to remove the snd_soc_rtdcom_lookup() call > > in > > SOF. > > I don't know concrete system. > But it is "possible" today. > And, we don't know the future system, > having flexibility is good idea, I think. > > I'm thinking removing lookup function is nice idea, > but don't feel pressure to it. > "Now you know it" is very enough for me. I am having a hard time visualizing a scenario where we would have more than one platform component. And even if we did, I'd think that the driver registering these components would make sure to not duplicate the driver names. Of course, we dont really check if thats really the case. Do you think it makes sense to add that check when registering a component? If we do that, then keeping snd_soc_rtdcom_lookup() might not be such a bad idea. Thanks, Ranjani