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 3BCD2C433F5 for ; Fri, 22 Apr 2022 12:36:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1447550AbiDVMjD (ORCPT ); Fri, 22 Apr 2022 08:39:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52798 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238288AbiDVMjD (ORCPT ); Fri, 22 Apr 2022 08:39:03 -0400 Received: from hutie.ust.cz (unknown [IPv6:2a03:3b40:fe:f0::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 46ACD54BCB; Fri, 22 Apr 2022 05:36:07 -0700 (PDT) Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cutebit.org; s=mail; t=1650630964; bh=OSdl6aaUeic9SF9BLtfTgFqL689pyLDLZc4/GdJKq8o=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=KOTSsrVYpbp9H5eGEznDOrhNsmP3WRoz8CT6HguROZySCUrsZqVTT44KHKkohBvsd e+qME5tm+XjxZ4vuL1KYQmlgCHruAzaW6CvVg1UJa3itnrutntNc5vnK3SEYU/nmJ3 tQziBxksfZFdSSzcb3CTR1FRn4UKO1OQJamlKnM0= Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Subject: Re: [RFC PATCH 0/5] Apple Macs machine-level ASoC driver From: =?utf-8?Q?Martin_Povi=C5=A1er?= In-Reply-To: Date: Fri, 22 Apr 2022 14:36:03 +0200 Cc: =?utf-8?Q?Martin_Povi=C5=A1er?= , Liam Girdwood , Rob Herring , Krzysztof Kozlowski , Jaroslav Kysela , Takashi Iwai , alsa-devel@alsa-project.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Mark Kettenis , Hector Martin , Sven Peter Content-Transfer-Encoding: quoted-printable Message-Id: <6F6130F3-381C-4AB7-B618-CDC4C4A37C9B@cutebit.org> References: <6D199EAB-FE14-4030-96A7-2E0E89D25FAB@cutebit.org> To: Mark Brown Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org > On 22. 4. 2022, at 14:22, Mark Brown wrote: >=20 > On Fri, Apr 22, 2022 at 01:44:06PM +0200, Martin Povi=C5=A1er wrote: >=20 >>> So previously each speaker would get two slots but now it just gets = one? >=20 >> No the other way around. Previously (with the driver as it is RFCed), >> each speaker gets a single slot, and 'Left', 'Right' and = =E2=80=98LeftRight' >> values of the routing control don't do anything different from each >> other (well except maybe 'LeftRight' lessens the volume due to how >> the chip handles the edge case of mixing down two channels from the >> same slot). >=20 >> With the new arrangement I am proposing, the two speakers in a = left-right >> pair get both the same two slots, meaning they get to choose one of = the >> two slots based on the 'Left' 'Right' value of their routing control. >=20 > Ah, I think the confusion here is that I'm using slot and channel > interchangably whereas you're saying that previously the driver would > allocate two channels to each speaker with duplicate data? I guess you could say that. Not that there=E2=80=99s duplicate data on = the I2S bus, but the speaker amp would previously be configured to look for the left and right channel in the same TDM slot (see e.g. set_tdm_slot of tas2770 [0]). (Each speaker amp drives a single speaker, but it still has a notion of left and right channel.) [0] = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/so= und/soc/codecs/tas2770.c#n416