RE: [EXTERNAL] Re: [PATCH v9] ASoc: tas2783: Add tas2783 codec driver

[Ding, Shenghao]

> -----Original Message-----
> From: Mark Brown <broonie@xxxxxxxxxx>
> Sent: Saturday, February 24, 2024 1:20 AM
> To: Ding, Shenghao <shenghao-ding@xxxxxx>
> Cc: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx>;
> andriy.shevchenko@xxxxxxxxxxxxxxx; lgirdwood@xxxxxxxxx; perex@xxxxxxxx;
> 13916275206@xxxxxxx; alsa-devel@xxxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; liam.r.girdwood@xxxxxxxxx; bard.liao@xxxxxxxxx;
> mengdong.lin@xxxxxxxxx; yung-chuan.liao@xxxxxxxxxxxxxxx; Xu, Baojun
> <baojun.xu@xxxxxx>; Lu, Kevin <kevin-lu@xxxxxx>; tiwai@xxxxxxx;
> soyer@xxxxxx
> 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.