From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Shenghao Ding <shenghao-ding@ti.com>,
broonie@kernel.org, conor+dt@kernel.org,
krzysztof.kozlowski@linaro.org, devicetree@vger.kernel.org,
robh+dt@kernel.org, andriy.shevchenko@linux.intel.com,
linux-sound@vger.kernel.org, liam.r.girdwood@intel.com,
lgirdwood@gmail.com, linux-kernel@vger.kernel.org
Cc: kevin-lu@ti.com, baojun.xu@ti.com, v-po@ti.com, navada@ti.com,
perex@perex.cz, j-mcpherson@ti.com, 13916275206@139.com,
mohit.chawla@ti.com, soyer@irl.hu, jkhuang3@ti.com,
tiwai@suse.de, pdjuandi@ti.com, manisha.agrawal@ti.com,
s-hari@ti.com, aviel@ti.com, hnagalla@ti.com, praneeth@ti.com
Subject: Re: [PATCH v4 1/4] ASoc: PCM6240: Create PCM6240 Family driver code
Date: Thu, 8 Feb 2024 08:38:04 -0600 [thread overview]
Message-ID: <160173b0-098e-493f-93b1-8b831838e0a0@linux.intel.com> (raw)
In-Reply-To: <20240208095255.1508-1-shenghao-ding@ti.com>
> +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?
> + 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
> +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.
> +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;
> +}
next prev parent reply other threads:[~2024-02-08 23:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-08 9:52 [PATCH v4 1/4] ASoc: PCM6240: Create PCM6240 Family driver code Shenghao Ding
2024-02-08 9:52 ` [PATCH v4 2/4] ASoc: PCM6240: Create header file for " Shenghao Ding
2024-02-08 9:52 ` [PATCH v4 3/4] ASoc: PCM6240: Add compile item for PCM6240 Family driver Shenghao Ding
2024-02-08 9:52 ` [PATCH v4 4/4] ASoc: dt-bindings: PCM6240: Add initial DT binding Shenghao Ding
2024-02-08 14:38 ` Pierre-Louis Bossart [this message]
2024-02-09 1:18 ` [PATCH v4 1/4] ASoc: PCM6240: Create PCM6240 Family driver code Ding, Shenghao
2024-02-09 15:44 ` Pierre-Louis Bossart
2024-02-09 16:23 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=160173b0-098e-493f-93b1-8b831838e0a0@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=13916275206@139.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=aviel@ti.com \
--cc=baojun.xu@ti.com \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=hnagalla@ti.com \
--cc=j-mcpherson@ti.com \
--cc=jkhuang3@ti.com \
--cc=kevin-lu@ti.com \
--cc=krzysztof.kozlowski@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=liam.r.girdwood@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=manisha.agrawal@ti.com \
--cc=mohit.chawla@ti.com \
--cc=navada@ti.com \
--cc=pdjuandi@ti.com \
--cc=perex@perex.cz \
--cc=praneeth@ti.com \
--cc=robh+dt@kernel.org \
--cc=s-hari@ti.com \
--cc=shenghao-ding@ti.com \
--cc=soyer@irl.hu \
--cc=tiwai@suse.de \
--cc=v-po@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).