Re: [PATCH v4 1/4] ASoc: PCM6240: Create PCM6240 Family driver code

[Pierre-Louis Bossart]

> > > +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",
> > > +};
> >
> > Controls are exposed to user-space, and it helps if it's easy to identify which
> > device is which.
> >
> > But below you are using the I2C address, is this 'stable' enough so that
> > userspace can still identify the controls and set them accordingly with amixer
> > or UCM?
> 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.

> > > +static int pcmdevice_codec_probe(struct snd_soc_component *codec) {
> > > +	struct pcmdevice_priv *pcm_dev =
> > snd_soc_component_get_drvdata(codec);
> > > +	struct i2c_adapter *adap = pcm_dev->client->adapter;
> > > +	int ret, i, j;
> > > +
> > > +	mutex_lock(&pcm_dev->codec_lock);
> > > +	pcm_dev->component = codec;
> > > +	pcm_dev->fw_state = PCMDEVICE_FW_LOAD_OK;
> > > +
> > > +	for (i = 0; i < pcm_dev->ndev; i++) {
> > > +		for (j = 0; j < 2; j++) {
> > > +			ret = pcmdev_gain_ctrl_add(pcm_dev, i, j);
> > > +			if (ret < 0)
> > > +				goto out;
> > > +		}
> > > +	}
> > > +
> > > +	/* device-name[defined in pcmdevice_i2c_id]-i2c-bus_id[0,1,...,N]-
> > > +	 * sum[1,2,...,4]dev-reg.bin stores the firmware including register
> > > +	 * setting and params for different filters inside chips, it must be
> > > +	 * copied into firmware folder. The same types of pcmdevices sitting
> > > +	 * on the same i2c bus will be aggregated as one single codec,
> > > +	 * all of them share the same bin file.
> > > +	 */
> > > +	scnprintf(pcm_dev->regbin_name,
> > PCMDEVICE_REGBIN_FILENAME_LEN,
> > > +		"%s-i2c-%d-%udev-reg.bin", pcm_dev->dev_name, adap->nr,
> > > +		pcm_dev->ndev);
> > > +
> > > +	ret = request_firmware_nowait(THIS_MODULE,
> > FW_ACTION_UEVENT,
> > > +		pcm_dev->regbin_name, pcm_dev->dev, GFP_KERNEL,
> > pcm_dev,
> > > +		pcmdev_regbin_ready);
> >
> > I already had a question early on whether these addresses are 'stable', but
> > here the device address is used to fetch firmware, and there is no prefix or
> > directory to identify platform-specific settings.
> >
> > I don't know how this might work for a distribution. There needs to be a way
> > to detect what system this is at run-time, and make sure we don't use
> > settings for platform XYZ on platform ABC.
> In PC, hwid, subsysid and vendorid can help to identify the platform.
>   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.