public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Sen Wang <sen@ti.com>
Cc: linux-sound@vger.kernel.org, lgirdwood@gmail.com,
	robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org, perex@perex.cz, tiwai@suse.com,
	shenghao-ding@ti.com, kevin-lu@ti.com, baojun.xu@ti.com,
	niranjan.hy@ti.com, l-badrinarayanan@ti.com, devarsht@ti.com,
	v-singh1@ti.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/4] ASoC: codecs: Add TAS67524 quad-channel audio amplifier driver
Date: Wed, 8 Apr 2026 16:41:31 +0100	[thread overview]
Message-ID: <588c699e-7ad0-4f71-9727-56e8a3c78805@sirena.org.uk> (raw)
In-Reply-To: <20260408053149.1369350-3-sen@ti.com>

[-- Attachment #1: Type: text/plain, Size: 2697 bytes --]

On Wed, Apr 08, 2026 at 12:31:46AM -0500, Sen Wang wrote:

> +static int tas675x_dsp_mem_write(struct tas675x_priv *tas, u8 page, u8 reg, u32 val)
> +{

> +out:
> +	__tas675x_select_book(tas, TAS675X_BOOK_DEFAULT);
> +	mutex_unlock(&tas->io_lock);

Do we really need to restore the book here?  The book select register is
marked as volatile so regmap will figure things out if it's the next
thing to write, and anything else will need to set whatever it wants
anyway.  Alternatively if the book register were cached (which wouldn't
be a bad idea) then we'd need to restore whatever the cache has or
invalidate the cache.

> +static int tas675x_dsp_mem_read(struct tas675x_priv *tas, u8 page, u8 reg, u32 *val)
> +{

> +out:
> +	__tas675x_select_book(tas, TAS675X_BOOK_DEFAULT);
> +	mutex_unlock(&tas->io_lock);

Same here

> +static int tas675x_rtldg_thresh_info(struct snd_kcontrol *kcontrol,
> +				     struct snd_ctl_elem_info *uinfo)
> +{
> +	uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
> +	uinfo->count = 1;
> +	uinfo->value.integer.min = 0;
> +	/* Accepts 32-bit values, even though 8bit MSB is ignored */
> +	uinfo->value.integer.max = 0xFFFFFFFF;

This is going to break on 32 bit architectures since long is a 32 bit
signed value.  You want LONG_MAX, or to restrict the value (which would
be more friendly to mixer-test!).

> +static int tas675x_set_dcldg_trigger(struct snd_kcontrol *kcontrol,
> +				     struct snd_ctl_elem_value *ucontrol)
> +{

> +	/* Wait for LOAD_DIAG to exit */
> +	regmap_read_poll_timeout(tas->regmap, TAS675X_STATE_REPORT_CH1_CH2_REG,
> +				 state, (state & 0x0F) != TAS675X_STATE_LOAD_DIAG &&
> +					(state >> 4) != TAS675X_STATE_LOAD_DIAG,
> +				 TAS675X_POLL_INTERVAL_US,
> +				 TAS675X_STATE_TRANSITION_TIMEOUT_US);
> +	regmap_read_poll_timeout(tas->regmap, TAS675X_STATE_REPORT_CH3_CH4_REG,
> +				 state34, (state34 & 0x0F) != TAS675X_STATE_LOAD_DIAG &&
> +					  (state34 >> 4) != TAS675X_STATE_LOAD_DIAG,
> +				 TAS675X_POLL_INTERVAL_US,
> +				 TAS675X_STATE_TRANSITION_TIMEOUT_US);

Don't know how likely it is in practice but we ignore any timeout
failures in this function.

> +static irqreturn_t tas675x_irq_handler(int irq, void *data)
> +{
> +	struct tas675x_priv *tas = data;
> +
> +	if (!tas675x_check_faults(tas))
> +		return IRQ_NONE;
> +
> +	regmap_write(tas->regmap, TAS675X_RESET_REG, TAS675X_FAULT_CLEAR);
> +	return IRQ_HANDLED;
> +}

This probably ought to take a runtime PM reference to ensure the I2C
controller is woken up, and in case in future you get regulator support.
Even if the device itself shouldn't be generating interrupts while it's
idle the interrupt might be shared or something might fire for some
other reason.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2026-04-08 15:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-08  5:31 [PATCH v4 0/4] ASoC: Add TAS67524 quad-channel Class-D amplifier driver Sen Wang
2026-04-08  5:31 ` [PATCH v4 1/4] ASoC: dt-bindings: Add ti,tas67524 Sen Wang
2026-04-08  7:13   ` Krzysztof Kozlowski
2026-04-08  5:31 ` [PATCH v4 2/4] ASoC: codecs: Add TAS67524 quad-channel audio amplifier driver Sen Wang
2026-04-08  7:14   ` Krzysztof Kozlowski
2026-04-08 15:41   ` Mark Brown [this message]
2026-04-09 15:26     ` Wang, Sen
2026-04-09 15:41       ` Mark Brown
2026-04-08  5:31 ` [PATCH v4 3/4] Documentation: sound: Add TAS675x codec mixer controls documentation Sen Wang
2026-04-08  5:31 ` [PATCH v4 4/4] MAINTAINERS: add entry for TAS67524 audio amplifier Sen Wang

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=588c699e-7ad0-4f71-9727-56e8a3c78805@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=baojun.xu@ti.com \
    --cc=conor+dt@kernel.org \
    --cc=devarsht@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=kevin-lu@ti.com \
    --cc=krzk+dt@kernel.org \
    --cc=l-badrinarayanan@ti.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=niranjan.hy@ti.com \
    --cc=perex@perex.cz \
    --cc=robh@kernel.org \
    --cc=sen@ti.com \
    --cc=shenghao-ding@ti.com \
    --cc=tiwai@suse.com \
    --cc=v-singh1@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