From: Mark Brown <broonie@kernel.org>
To: "Ding, Shenghao" <shenghao-ding@ti.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"krzysztof.kozlowski+dt@linaro.org"
<krzysztof.kozlowski+dt@linaro.org>,
"conor+dt@kernel.org" <conor+dt@kernel.org>,
"linux-sound@vger.kernel.org" <linux-sound@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"perex@perex.cz" <perex@perex.cz>,
"tiwai@suse.com" <tiwai@suse.com>,
"13916275206@139.com" <13916275206@139.com>,
"Chawla, Mohit" <mohit.chawla@ti.com>,
"soyer@irl.hu" <soyer@irl.hu>,
"Huang, Jonathan" <jkhuang3@ti.com>,
"tiwai@suse.de" <tiwai@suse.de>,
"Djuandi, Peter" <pdjuandi@ti.com>,
"Agrawal, Manisha" <manisha.agrawal@ti.com>,
"Hari, Raj" <s-hari@ti.com>, "Yashar, Avi" <aviel@ti.com>,
"Nagalla, Hari" <hnagalla@ti.com>,
"Bajjuri, Praneeth" <praneeth@ti.com>
Subject: Re: [EXTERNAL] Re: [PATCH v6 1/4] ASoc: PCM6240: Create PCM6240 Family driver code
Date: Wed, 28 Feb 2024 12:46:23 +0000 [thread overview]
Message-ID: <997ff4d2-e349-447c-bb21-5814ed544c30@sirena.org.uk> (raw)
In-Reply-To: <3e0ebab7835040ff81775f43b71d3b99@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]
On Wed, Feb 28, 2024 at 04:20:16AM +0000, Ding, Shenghao wrote:
> > From: Mark Brown <broonie@kernel.org>
> > On Fri, Feb 23, 2024 at 08:38:04PM +0800, Shenghao Ding 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, I see why you're doing this naming thing for the per-device controls
> > - the device can (and is designed to) allow controlling multiple amps with a
> > single I2C write. However this is resulting in something that's really awkward
> > from an ALSA point of view, the names that are being generated are very
> > much not idiomatic for control names and probably aren't going to be
> > terribly meaningful for end users since they're not associated with where the
> For only single one device, all these seems redundant and makes uncomfortable
> Many of my customers will have such cases as
> Four pieces of Pcm6240s and three pieces of pcm6360s in the same i2c bus.
> The chip name can help them identify the chip and set the right chip and the right channel.
The problem is not with having the names, the problem is that the names
look nothing like how normal ALSA names for deduplicating controls look
- normally these are specified by the board and are human legible rather
than based on the numbers of buses inside the system.
> > I think it would make sense to do a version the driver with no user visible
> > controls (or at least none that need this name generation stuff) and then
> > make the controls an incremental patch, the driver would obviously need
> > both bits to be properly useful but it'd mean that the simple bit could get
> > reviewed and possibly merged separately to the complicated bit which would
> > probably be easier.
> You means to remove the kcontrols first. After the patch was accepted, add these
> Kcontrols, right?
Yes, or even just split the controls out so they're a later patch in the
series - no need to wait before sending the code, just sort it after the
rest of the driver.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2024-02-28 12:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-23 12:38 [PATCH v6 1/4] ASoc: PCM6240: Create PCM6240 Family driver code Shenghao Ding
2024-02-23 12:38 ` [PATCH v6 2/4] ASoc: PCM6240: Create header file for " Shenghao Ding
2024-02-23 12:38 ` [PATCH v6 3/4] ASoc: PCM6240: Add compile item for PCM6240 Family driver Shenghao Ding
2024-02-23 12:38 ` [PATCH v6 4/4] ASoc: dt-bindings: PCM6240: Add initial DT binding Shenghao Ding
2024-02-27 15:46 ` [PATCH v6 1/4] ASoc: PCM6240: Create PCM6240 Family driver code Mark Brown
2024-02-28 4:20 ` [EXTERNAL] " Ding, Shenghao
2024-02-28 12:46 ` Mark Brown [this message]
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=997ff4d2-e349-447c-bb21-5814ed544c30@sirena.org.uk \
--to=broonie@kernel.org \
--cc=13916275206@139.com \
--cc=aviel@ti.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=hnagalla@ti.com \
--cc=jkhuang3@ti.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=manisha.agrawal@ti.com \
--cc=mohit.chawla@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.com \
--cc=tiwai@suse.de \
/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