Received-SPF: pass (google.com: domain of linux-kernel+bounces-84499-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
From: "Ding, Shenghao" <shenghao-ding@ti.com>
To: Mark Brown <broonie@kernel.org>
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
Thread-Topic: [EXTERNAL] Re: [PATCH v6 1/4] ASoc: PCM6240: Create PCM6240
 Family driver code
Thread-Index: AQHaZlUvaWdne5oqDU27e+oocVjRwrEewCOAgABmq6A=
Date: Wed, 28 Feb 2024 04:20:16 +0000
Message-ID: <3e0ebab7835040ff81775f43b71d3b99@ti.com>
References: <20240223123809.503-1-shenghao-ding@ti.com>
 <0cba2632-5d79-488a-9eec-dbed4208971b@sirena.org.uk>
In-Reply-To: <0cba2632-5d79-488a-9eec-dbed4208971b@sirena.org.uk>
Accept-Language: en-US, zh-CN
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
MIME-Version: 1.0


> -----Original Message-----
> From: Mark Brown <broonie@kernel.org>
> Sent: Tuesday, February 27, 2024 11:46 PM
> To: Ding, Shenghao <shenghao-ding@ti.com>
> Cc: linux-kernel@vger.kernel.org; lgirdwood@gmail.com;
> robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org;
> conor+dt@kernel.org; linux-sound@vger.kernel.org;
> devicetree@vger.kernel.org; perex@perex.cz; tiwai@suse.com;
> 13916275206@139.com; Chawla, Mohit <mohit.chawla@ti.com>;
> soyer@irl.hu; Huang, Jonathan <jkhuang3@ti.com>; 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: [EXTERNAL] Re: [PATCH v6 1/4] ASoc: PCM6240: Create PCM6240
> Family driver code
>=20
> On Fri, Feb 23, 2024 at 08:38:04PM +0800, Shenghao Ding wrote:
>=20
> > +static const char *const pcmdev_ctrl_name[] =3D {
> > +	"%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",
> > +};
>=20
> 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 wit=
h a
> single I2C write.  However this is resulting in something that's really a=
wkward
> 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
> relevant outputs physically are.  We could require machines to provide
> names for everything but that's probably going to be a miserable experien=
ce
> on x86 and is unhelpful even with DT so having a default seems to make
> sense.
>=20
> I think these should look more like ALSA names, so "I2C %d Device %d..."
> though that does make things a bit longer.
Hi Mark
For only single one device, all these seems redundant and makes uncomfortab=
le
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 th=
e right channel.
>=20
> > +static const char *const pcmdev_ctrl_name_with_prefix[] =3D {
> > +	"%s-dev%d-ch%d-ana-gain",
> > +	"%s-dev%d-ch%d-digi-gain",
> > +	"%s-dev%d-ch%d-fine-gain",
> > +};
>=20
> For these I'm not clear why we don't just use the name, what's the goal i=
n
> having the device number in there?
>=20
> I think it would make sense to do a version the driver with no user visib=
le
> 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 g=
et
> reviewed and possibly merged separately to the complicated bit which woul=
d
> probably be easier.

You means to remove the kcontrols first. After the patch was accepted, add =
these
Kcontrols, right?
>=20
> Please also send the output of mixer-test from a machine with this driver=
 in it
> as part of the cover letter, it'll make it easier to tell what's going on=
.
>=20
> > +	if (comp->name_prefix) {
> > +	/* There's name_prefix defined in DTS. Bin file name will be
> > +	 * name_prefix.bin stores the firmware including register setting and
> > +	 * params for different filters inside chips, it must be copied into
>=20
> The comment should be indented like it's inside the if ().
>=20
> > +	} else {
> > +	/* There's NO name_prefix defined in DTS. Bin file name will be
> > +	 * device-name[defined in pcmdevice_i2c_id]-i2c-bus_id[0,1,...,N]-
> > +	 * sum[1,...,4]dev.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->bin_name,
> PCMDEVICE_BIN_FILENAME_LEN,
> > +			"%s-i2c-%d-%udev.bin", pcm_dev->dev_name, adap-
> >nr,
> > +			pcm_dev->ndev);
> > +	}
>=20
> You could also do this as a fallback (ie, try the specified name first th=
en fall
> bakc to the bus based numbering), that way if a name is added later it wo=
n't
> break people's installs on upgrade.
>=20
> > +static const struct regmap_config pcmdevice_i2c_regmap =3D {
> > +	.reg_bits =3D 8,
> > +	.val_bits =3D 8,
> > +	.cache_type =3D REGCACHE_MAPLE,
> > +	.ranges =3D pcmdevice_ranges,
> > +	.num_ranges =3D ARRAY_SIZE(pcmdevice_ranges),
> > +	.max_register =3D 256 * 128,
> > +};
>=20
> Shouldn't there be some volatile registers if we have interrupts?