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.