Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp790493ybx; Tue, 5 Nov 2019 05:41:05 -0800 (PST) X-Google-Smtp-Source: APXvYqwfzdK8Xc3IYRJSCuBhc9xRApICmKrAq0tCgeebpwnobHwfiaG2A7jYo/bsPJDuzTQgRA1P X-Received: by 2002:a17:906:1d59:: with SMTP id o25mr7927136ejh.17.1572961265777; Tue, 05 Nov 2019 05:41:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572961265; cv=none; d=google.com; s=arc-20160816; b=j1EO0ao/QiRRLwxTmmyL6g3vydTmDHHqKBT2ICDwTMcPZap+0ZVYJj+oWvdSVzavvg UEFzU21+W36Pi7mfAtqQ9ObFDPH2N40EGpX3sRJHPLvenSY4MB3XmW+BgIO/mJ3XzlS8 fnETEG+PrF2GzzuZEqauFPgdiJtVPsqA/u/khqETwCs8+W4RARqYWwL5P0kioXyLrYV9 Cq0jMlzm3nghSl+1mSxCO8utTwYTCZmUlhnlL50fKJgBJ30H8QUfqnu6do7q8q3oXIdt Ne1eY/YrKjWppx9rVTQQondh14Z1hEfaYHuq29/gKAukHKillRRyIQ+7JgRW1al04YFC W2ew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=Cf5DENZQ1cK82DPhS6AFVL2QEMgBu6tYQtkG3nCsnl8=; b=kqnn9rkrDkdMPAzhKH3g6wfJjwKRfOCOLNYO98wNDL0pbv3f8ScNSTpurkCZAjaPRk 3rgbssdm7BH2USApgiSHM2sxymLnbFleOGfaoqHHb7saitF7wPVZmE450voJcSIA9E8O 88cLuC3xjDPuEPWvH5N0S5Ye69zYXkCHbH0aYguA5BNFPrJ8tsJUis/Z+ZbbkJzFIir5 N7xRmi3B2OABanKqcikpLtvzW/3pDs0XMvCD5mzy92AVdBUpHnMPoAFS+dFHxLfjbYKB SCzlc4+duHTdgcLiW0grVliOaLUa0D7OfPk7zp1rBuR6ME+2wyW484DUg0lvzekjcnSm Z+3A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id gx24si6478799ejb.429.2019.11.05.05.40.41; Tue, 05 Nov 2019 05:41:05 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389127AbfKENha (ORCPT + 99 others); Tue, 5 Nov 2019 08:37:30 -0500 Received: from mga09.intel.com ([134.134.136.24]:19235 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387880AbfKENha (ORCPT ); Tue, 5 Nov 2019 08:37:30 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2019 05:37:29 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,271,1569308400"; d="scan'208";a="403353670" Received: from nvavanes-mobl.amr.corp.intel.com (HELO [10.254.182.110]) ([10.254.182.110]) by fmsmga006.fm.intel.com with ESMTP; 05 Nov 2019 05:37:28 -0800 Subject: Re: [alsa-devel] [PATCH] ASoC: bdw-rt5677: enable runtime channel merge To: "Lu, Brent" , "alsa-devel@alsa-project.org" Cc: "Rojewski, Cezary" , Kuninori Morimoto , "linux-kernel@vger.kernel.org" , Jie Yang , Takashi Iwai , Liam Girdwood , "Zavras, Alexios" , Mark Brown , Thomas Gleixner References: <1570007072-23049-1-git-send-email-brent.lu@intel.com> <63da3995-b807-f9e6-6f09-a90e6b8e8e53@linux.intel.com> From: Pierre-Louis Bossart Message-ID: <9abda4e6-7a85-50e3-ca09-7029fe5a0d7a@linux.intel.com> Date: Tue, 5 Nov 2019 06:48:38 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/5/19 12:03 AM, Lu, Brent wrote: >>>> In the DAI link "Capture PCM", the FE DAI "Capture Pin" supports >>>> 4-channel capture but the BE DAI supports only 2-channel capture. To >>>> fix the channel mismatch, we need to enable the runtime channel merge >> for this DAI link. >>>> >>> >>> Hi Pierre, >>> >>> This patch is for the same issue discussed in the following thread: >>> https://patchwork.kernel.org/patch/11134167/ >>> >>> We enable the runtime channel merge for the DMIC DAI instead of adding >>> a machine driver constraint. It's working good on chrome's 3.14 branch >>> (which requires some backport for the runtime channel merge feature). >>> Please let me know if this implementation is correct for the FE/BE mismatch >> problem. >> >> Sorry, I don't fully understand your points, and it's the first time I see anyone >> use this .dpcm_merged_chan field for an Intel platform. >> >> If I look at the code I see that the core would limit the number of channels to >> two. But that code needs the CPU_DAI to use 2 channels, which I don't see. >> So is this patch self-contained or do we need an additional constraint on the >> FE? >> >> Thanks >> -Pierre > > Hi Pierre, > > We don't need constraint on FE because dpcm_runtime_merge_chan() modifies > the channel number of snd_pcm_hardware structure directly. The structure will > be used to initialize the snd_pcm_hw_constraints structure later in the > snd_pcm_hw_constraints_complete() function. Since the channel number is already > modified, we don't need a constraint to install an extra rule for it. > > The result of using dpcm_merged_chan flag and machine driver constraint should > be the same when user space programs calling HW_REFINE ioctl call but I think the > flag is more elegant for machine driver code. I could use the opposite argument: by using a capability that no one else uses, you make the solution more obscure and less intuitive. All other machine drivers use constraints, so if the two solutions are equivalent let's follow the more common solution.