Messages in this thread | | | From | "Ding, Shenghao" <> | Subject | RE: [EXTERNAL] Re: [PATCH v9] ASoc: tas2783: Add tas2783 codec driver | Date | Tue, 27 Feb 2024 02:52:00 +0000 |
| |
> -----Original Message----- > From: Mark Brown <broonie@kernel.org> > Sent: Saturday, February 24, 2024 1:20 AM > To: Ding, Shenghao <shenghao-ding@ti.com> > Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>; > andriy.shevchenko@linux.intel.com; lgirdwood@gmail.com; perex@perex.cz; > 13916275206@139.com; alsa-devel@alsa-project.org; linux- > kernel@vger.kernel.org; liam.r.girdwood@intel.com; bard.liao@intel.com; > mengdong.lin@intel.com; yung-chuan.liao@linux.intel.com; Xu, Baojun > <baojun.xu@ti.com>; Lu, Kevin <kevin-lu@ti.com>; tiwai@suse.de; > soyer@irl.hu > Subject: Re: [EXTERNAL] Re: [PATCH v9] ASoc: tas2783: Add tas2783 codec > driver > > 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. > > 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? Thanks for your comments, Mark & Pierre. I will discuss with my customers on how to find a compromise between new solution and current solution already released to market.
| |