Received-SPF: pass (google.com: domain of linux-kernel+bounces-81863-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <2c7e33e5-6904-467d-9912-417bab95e517@linux.intel.com>
Date: Mon, 26 Feb 2024 10:56:41 -0500
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [EXTERNAL] Re: [PATCH v9] ASoc: tas2783: Add tas2783 codec driver
To: Mark Brown <broonie@kernel.org>, "Ding, Shenghao" <shenghao-ding@ti.com>
Cc: "andriy.shevchenko@linux.intel.com" <andriy.shevchenko@linux.intel.com>,
 "lgirdwood@gmail.com" <lgirdwood@gmail.com>, "perex@perex.cz"
 <perex@perex.cz>, "13916275206@139.com" <13916275206@139.com>,
 "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 "liam.r.girdwood@intel.com" <liam.r.girdwood@intel.com>,
 "bard.liao@intel.com" <bard.liao@intel.com>,
 "mengdong.lin@intel.com" <mengdong.lin@intel.com>,
 "yung-chuan.liao@linux.intel.com" <yung-chuan.liao@linux.intel.com>,
 "Xu, Baojun" <baojun.xu@ti.com>, "Lu, Kevin" <kevin-lu@ti.com>,
 "tiwai@suse.de" <tiwai@suse.de>, "soyer@irl.hu" <soyer@irl.hu>
References: <20240222074000.659-1-shenghao-ding@ti.com>
 <10f53a13-a0ff-40f9-b089-f5baacdb76b6@linux.intel.com>
 <5c7127256bf54fcd921fc1ec83f3e527@ti.com>
 <ZdjTyccCDoD9QYpi@finisterre.sirena.org.uk>
Content-Language: en-US
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
In-Reply-To: <ZdjTyccCDoD9QYpi@finisterre.sirena.org.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2/23/24 12:20 PM, Mark Brown wrote:
> On Fri, Feb 23, 2024 at 10:12:49AM +0000, Ding, Shenghao wrote:
>> Hi Pierre-Louis
>>
>>> In the SoundWire spec, the unique_id is *LINK SPECIFIC*, and only used at
>>> the bus level within the context of a link to help avoid enumeration
>>> conflicts
> 
>>> If you are using the unique_id as a SYSTEM-UNIQUE value to lookup EFI
>>> data, this is a TI-specific requirement that needs to be documented.
>>> That also means you need to double-check for errors so make sure there
>>> are no board configurations where the same unique_id is used in multiple
>>> links, or by devices other than tas2783.
> 
>> This code only covers the tas2783s sitting in the same bus link. As to cases of the
>> different SWD links, customer will be required to have the secondary development
>> on current code. I'm sure my customers have much knowledge to handle this.

PC OEMs don't usually have a Linux team capable of handling this sort of 
low-level plumbing, so the burden of this "secondary development" will 
come back at you...

> As Pierre says I think we really should have some sort of defensive
> programming here, even if you're going to leave multi-link systems to
> future work people will still have older versions in distributions or
> whtaever.  While I'm not sure the consequences of getting things wrong
> are likely to be that bad (I'm expecting bad quality audio) it's also
> going to be kind of hard to figure out if we just silently pick the
> wrong calibration, especially if it's actually a valid calibration for
> another device in the system.  Other vendors (eg, Cirrus) seem to have
> figured out a scheme here?

Leaving multi-link aside has to be seen as as temporary step, there are 
a number of electrical issues that will prevent more than 4 amps to be 
placed on the same link. And indeed this "secondary development" has to 
be backwards compatible with initial calibration schemes.