Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp942558pxb; Fri, 22 Apr 2022 14:58:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxTERLRbuwyboeBw27uwZ1YjXfClfjKyCfZbwHXb6lTyBI1EJD+Nf83HW3EJmw9upqk14I2 X-Received: by 2002:a17:903:32c5:b0:15c:9b35:fd28 with SMTP id i5-20020a17090332c500b0015c9b35fd28mr3338923plr.54.1650664729109; Fri, 22 Apr 2022 14:58:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650664729; cv=none; d=google.com; s=arc-20160816; b=Tlx4cPImtkdJf1PeNGknBN80saXPQAKdfDiRCmVWuksEkWvaZ5//B+KP3E5A3EeJWV UlRmA0U5K1asO5qyOItUM35Yk9DYzd7lLpCMwALHSdLkL7kPNLZueHibuJ2RnrlANENK 2/3f2WtBnTEn5tHfgv1v5dljkhG09ONMMEDAfUkIRWcfJhmjqpvI2cunPZnAzxliPqQz 4nbJ4aIqlVwfMb1dBsN4hNbghOs0eV2dzp+in1HpbOAKTweoYgcrkWgB3q42rkgmsELN XWae58V62sF1eRIZiLgPb8FydeXdhvnufiqsdOQaZiSaJQ6rEbCETlWNaaOYL06CWzts +fZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=4zKNiCJ9mR8YNKg4xV+9DRTe5znRz0G2bXHhsbBhsuc=; b=liZZSdWx0Y3yGv8ORKPIVQopCuDBj2wEhdSV/Hjlvq4qWUlOQkLa7mHaZo99GQgnJQ Jgm7UiR9dg5LipOTlwAjGeFJ5TGLaVvwKkv3894POubVhubnaE9oeowAp8aEdRqH38kO fcXM1/xMpIWIkiCwAyjESsxNY6kpZYRO+WAMFCU2eQ5v3bAwHbm2fnR+EhLgEDaMQrNU j7+pCBjtrmuTDJkmaCUvBIx3QjYYWI+J3zbBx/8dsjmqeaUjhHOrQ8EcYvmxq2b7QlL0 tIoYqiMN1hzKgfdAg2Lmnz85NMWnVi1vFA8lqE/5KyfsFAUBYSrb1VnDM0+w/TbSv7L1 3Abg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cutebit.org header.s=mail header.b=rbvLx9uV; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=cutebit.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id c12-20020a170902724c00b00158f3ba81ffsi8678249pll.127.2022.04.22.14.58.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 14:58:49 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@cutebit.org header.s=mail header.b=rbvLx9uV; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=cutebit.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5A5B636C90F; Fri, 22 Apr 2022 13:06:57 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349975AbiDVKqf (ORCPT + 99 others); Fri, 22 Apr 2022 06:46:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1446828AbiDVKqa (ORCPT ); Fri, 22 Apr 2022 06:46:30 -0400 Received: from hutie.ust.cz (unknown [IPv6:2a03:3b40:fe:f0::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EA6BE27FC0; Fri, 22 Apr 2022 03:43:35 -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=1650624211; bh=4zKNiCJ9mR8YNKg4xV+9DRTe5znRz0G2bXHhsbBhsuc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=rbvLx9uVaZ9KLhaZck/JuJlU9H9gFERagLBhE3o2ytCZKQ11iJiiO/8KqezzNuSTn pQCc4HfjB8ZDB11RdeTfmScFbabJXyS6U+rAc6/SCe8v9PGAjQPSd/0lUJEYEhBJb/ DAcjFfxZ553jXRIzeWyzghfGmwfRSlnEi3hT8HRc= 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 12:43:30 +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: References: <20220331000449.41062-1-povik+lin@cutebit.org> <6D199EAB-FE14-4030-96A7-2E0E89D25FAB@cutebit.org> To: Mark Brown X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On 31. 3. 2022, at 17:36, Mark Brown wrote: >=20 > On Thu, Mar 31, 2022 at 05:04:32PM +0200, Martin Povi=C5=A1er wrote: >>> On 31. 3. 2022, at 16:18, Mark Brown wrote: >=20 >>> Yes, having two devices driving the bus at the same time wouldn't be >>> great. How is the TDM slot selection for the signals done in the >>> hardware, I'm not seeing anything immediately obvious in the driver? >>> I'd have thought that things would be implemented such that you = could >>> implement speaker protection on all speakers simultaneously but = perhaps >>> not. >=20 >> I don=E2=80=99t know. I would have to go study the details of this. = Should I see >> if I can find a combination of =E2=80=98ASI1 Sel=E2=80=99 = =E2=80=98VSENSE=E2=80=99 =E2=80=98ISENSE=E2=80=99 settings >> that would lead to driver conflict on one of the models, or is there >> a chance we could hide those controls just on the basis of =E2=80=98it = doesn=E2=80=99t >> do anything usable and is possibly dangerous=E2=80=99? >=20 > If ISENSE and VSENSE output are controlled by the same mux as routing > then we should lock one of the controls out for at least stereo = devices > (it might be a good idea to check if the output is actually high Z = when > ISENSE and VSENSE are off rather than just driving zeros, if not it > definitely has to be the routing control). My instinct is that it's > better to preserve the ability to implement speaker protection in = future > since that is something that'd be broadly useful, especially if = someone > comes up with a generic speaker protection implementation in which = case > there should be an awful lot of systems out there which could benefit.=20= Sorry for having put this on hold for a while. I looked in the TAS2770 and TAS2764 drivers/datasheets, and to answer the questions we had: * VSENSE/ISENSE output slots are configured independently of audio = samples routing. Kernel drivers configure the slots based on the = 'ti,imon-slot-no' and 'ti,vmon-slot-no' properties of devicetree. * By default codecs transmit Hi-Z for duration of unused slots. So once we supply the devicetree props it should be electrically sound under any configuration of userspace knobs. One final thought on the playback routing controls: On systems with >2 speakers, the codecs need to be assigned slots through set_tdm_slot. The macaudio driver RFCed here assigns a single slot to each speaker, making the effect of each speaker's routing control this: 'I2C offset' -- uses a random slot 'Left' 'Right' 'LeftRight' -- uses the single slot we configured I suppose I better assign two slots to speakers in each left-right pair of the same kind (e.g. woofer 1, woofer 2, tweeter). This way the routing control will mimic its behavior from simple stereo systems but replicated within each left-right pair. (I would prefer to hide the controls altogether, but as I learned that hiding things unless proven dangerous is an ASoC non-goal, this way I can make the controls do something interesting.) Martin