Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34;
Message-ID: <9b94488e-206d-419b-92ed-e70aab11907b@linux.intel.com>
Date:   Mon, 30 Oct 2023 12:40:58 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] ASoC: tas2783: Add source files for tas2783 driver.
Content-Language: en-US
To:     Mark Brown <broonie@kernel.org>
Cc:     Baojun Xu <baojun.xu@ti.com>, lgirdwood@gmail.com, perex@perex.cz,
        alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
        kevin-lu@ti.com, shenghao-ding@ti.com, peeyush@ti.com,
        navada@ti.com, tiwai@suse.de
References: <20231028092409.96813-1-baojun.xu@ti.com>
 <7f4465c1-5e8e-4c5f-bbff-d2c930326986@linux.intel.com>
 <9d922584-288a-4b73-83ef-477d1bc58521@sirena.org.uk>
From:   Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
In-Reply-To: <9d922584-288a-4b73-83ef-477d1bc58521@sirena.org.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 10/30/23 12:20, Mark Brown wrote:
> On Mon, Oct 30, 2023 at 11:05:39AM -0500, Pierre-Louis Bossart wrote:
> 
>>> +static bool tas2783_readable_register(struct device *dev, unsigned int reg)
>>> +{
>>> +	switch (reg) {
>>> +	case 0x000 ... 0x080:	/* Data port 0. */
> 
>> No, this is wrong. All the data port 'standard' registers are "owned" by
>> the SoundWire core and handled during the port prepare/configure/bank
>> switch routines. Do not use them for regmap.
> 
>> In other words, you *shall* only define vendor-specific registers in
>> this codec driver.
> 
> This seems to come up a moderate amount and is an understandable thing
> to do - could you (or someone else who knows SoundWire) perhaps send a
> patch for the regmap SoundWire integration which does some validation
> here during registration and at least prints a warning?

Good suggestion, we could indeed check that the registers are NOT in the
range [0,0xBF] for all ports - only the range [0xC0..FF] is allowed for
implementation-defined values. I'll try to cook something up.

> Also worth noting that the default is going to be that the registers are
> readable if the driver doesn't configure anything at all so perhaps at
> least for just readability this might be worth revisiting.

Having the interrupt registers as readable could be problematic, there's
a known race condition where the drivers need to do a read after a
write, and I am a bit worried if we have two agents reading the same
thing. It's the only case I am aware of where a read establishes a state.

>>> +static const struct snd_soc_dapm_widget tasdevice_dapm_widgets[] = {
>>> +	SND_SOC_DAPM_AIF_IN("ASI", "ASI Playback", 0, SND_SOC_NOPM, 0, 0),
>>> +	SND_SOC_DAPM_AIF_OUT("ASI OUT", "ASI Capture", 0, SND_SOC_NOPM,
>>> +		0, 0),
>>> +	SND_SOC_DAPM_SPK("SPK", NULL),
>>> +	SND_SOC_DAPM_OUTPUT("OUT"),
>>> +	SND_SOC_DAPM_INPUT("DMIC")
>>> +};
> 
>> Can you clarify what "ASI" is?
> 
> ASI seems to be a fairly commonly used name in TI devices...  In general
> naming that corresponds to the datasheet should be fine, especially for
> internal only things like this sort of DAPM widget.  I'd guess it's
> something like Audio Serial Interface but not actually gone and looked.

I was only asking was the acronym stood for to make it easier to
look-up. Not asking for any technical details.