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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




+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.





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux