Hi Pierre
Thanks for your comments, answers are inline
Looking forward to your comments.
> -----Original Message-----
> From: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx>
> Sent: Thursday, February 8, 2024 10:38 PM
> To: Ding, Shenghao <shenghao-ding@xxxxxx>; broonie@xxxxxxxxxx;
> conor+dt@xxxxxxxxxx; krzysztof.kozlowski@xxxxxxxxxx;
> devicetree@xxxxxxxxxxxxxxx; robh+dt@xxxxxxxxxx;
> andriy.shevchenko@xxxxxxxxxxxxxxx; linux-sound@xxxxxxxxxxxxxxx;
> liam.r.girdwood@xxxxxxxxx; lgirdwood@xxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx
> Cc: Lu, Kevin <kevin-lu@xxxxxx>; Xu, Baojun <baojun.xu@xxxxxx>; P O, Vijeth
> <v-po@xxxxxx>; Navada Kanyana, Mukund <navada@xxxxxx>;
> perex@xxxxxxxx; McPherson, Jeff <j-mcpherson@xxxxxx>;
> 13916275206@xxxxxxx; Chawla, Mohit <mohit.chawla@xxxxxx>;
> soyer@xxxxxx; Huang, Jonathan <jkhuang3@xxxxxx>; tiwai@xxxxxxx; Djuandi,
> Peter <pdjuandi@xxxxxx>; Agrawal, Manisha <manisha.agrawal@xxxxxx>;
> Hari, Raj <s-hari@xxxxxx>; Yashar, Avi <aviel@xxxxxx>; Nagalla, Hari
> <hnagalla@xxxxxx>; Bajjuri, Praneeth <praneeth@xxxxxx>
> Subject: Re: [PATCH v4 1/4] ASoc: PCM6240: Create PCM6240 Family driver
> code
>
>
>
>
> > +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.
>
> > + err = pcmdev_dev_update_bits(pcm_dev, dev_no, reg, val_mask, val);
> > + if (err)
> > + dev_err(pcm_dev->dev, "%s:update_bits, ERROR, E=%d\n",
> > + __func__, err);
>
> generic comment for this patch: you may want to follow the same
> convention for error log, sometimes it's %s, or %s: or no %s
>
Accept
>
> > +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.
>
> > +static int pcmdevice_set_dai_sysclk(struct snd_soc_dai *codec_dai,
> > + int clk_id, unsigned int freq, int dir) {
> > + struct pcmdevice_priv *pcm_dev =
> snd_soc_dai_get_drvdata(codec_dai);
> > +
> > + pcm_dev->sysclk = freq;
>
> check clock values?
>
> > +
> > + return 0;
> > +}
