On Fri, Feb 09, 2024 at 09:44:25AM -0600, Pierre-Louis Bossart wrote: > > > > +static const char *const pcmdev_ctrl_name[] = { > > > > + "%s-i2c-%d-dev%d-ch%d-ana-gain", > > > > + "%s-i2c-%d-dev%d-ch%d-digi-gain", > > > > + "%s-i2c-%d-dev%d-ch%d-fine-gain", > > > > +}; > > So far, I have no good way to handle the devices with multiple pcmdevices sitting in different i2c buses. > > As you know, the gain value highly depends on both the mic-phone position and the mic-phone's own > > characters. All these controls have to be open to the product developer or manufacturer. They might > > rename them per their products if they want. > > As to the stable, my customers and I had developed many productors on arm-based paltforms. At least, > > the i2c number is same as the one defined in dts. > IIRC there is a codec prefix that can be used to uniquify controls, that's > what we used when we have identical amplifier devices in the same system. > Using this prefix would avoid this sort of hard-coding of the control names > proper, in other words let the ASoC framework add a prefix if needed. Yes, that's the best approach here - this also lets people assign meaningful names which makes it easier for users to figure out which device is which. Set name_prefix when registering the device. > > In PC, hwid, subsysid and vendorid can help to identify the platform. TBH it's really not at all reliable for PCs either when you start looking at motherboards targeted at industrial systems and the like. There's an awful lot of machines out there that describe themslves as "To be set by OEM" or whatever sadly. > > But it seemed difficult to get platform id on non-PC system. More often, > > different productors from different customers might use the same platform. > > In my view, the products developer or manufacturer might rename the firmware > > per their products if they want, not limited to the platform. > It's not "might rename", it's "are required to rename". > Your solution works if everything is build and configured for ONE board. > That's pretty limiting, even for your own CI and tests. > Could we not add a prefix for the firmware path that either either set with > a subsys_id or vendor_id, and if it doesn't exist with a kernel parameter or > a quirk? > Renaming firmware files is a never-ending source of problems IMHO. It's true that vendors will frequently not bother changing the machine names or other descriptive information when deriving from a reference design but that's more their problem than upstream's, and the more that upstream uses the facilities that exist to describe boards the more likely it is that OEMs will start to pick up on the value of doing something sensible with them. Pierre is right here, we should just be using what we've got. We should probably add a helper that tries to figure out a machine name to try inserting into the filename for machine specific firmwares/coefficients. That's probably not even ASoC specific, there'll likely be other examples where it makes sense. Perhaps the firmware code might be a good home?
Attachment:
signature.asc
Description: PGP signature