From: "Xu, Baojun" <baojun.xu@ti.com>
To: Mark Brown <broonie@kernel.org>
Cc: "tiwai@suse.de" <tiwai@suse.de>,
"andriy.shevchenko@linux.intel.com"
<andriy.shevchenko@linux.intel.com>,
"13916275206@139.com" <13916275206@139.com>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"Ding, Shenghao" <shenghao-ding@ti.com>,
"linux-sound@vger.kernel.org" <linux-sound@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Yi, Ken" <k-yi@ti.com>, "Lo, Henry" <henry.lo@ti.com>,
"Chen, Robin" <robinchen@ti.com>,
"Holalu Yogendra, Niranjan" <niranjan.hy@ti.com>,
"pin-hao.huang@hp.com" <pin-hao.huang@hp.com>,
"Syed.SabaKareem@amd.com" <Syed.SabaKareem@amd.com>
Subject: Re: [EXTERNAL] Re: [PATCH v5] ASoC: tas2783-sdw: add firmware download status check
Date: Mon, 21 Sep 2026 09:22:23 +0000 [thread overview]
Message-ID: <1c8da29a1fac4435a59783ab9fe7f68b@ti.com> (raw)
In-Reply-To: <arDujlvvKixE6ifp@sirena.co.uk>
Hi,
> From: Mark Brown <broonie@kernel.org>
> Sent: 21 September 2026 16:45
> To: Xu, Baojun
> Cc: tiwai@suse.de; andriy.shevchenko@linux.intel.com; 13916275206@139.com; alsa-devel@alsa-project.org; Ding, Shenghao; linux-sound@vger.kernel.org; linux-kernel@vger.kernel.org; Yi, Ken; Lo, Henry; Chen, Robin; Holalu Yogendra, Niranjan; pin-hao.huang@hp.com; Syed.SabaKareem@amd.com
> Subject: [EXTERNAL] Re: [PATCH v5] ASoC: tas2783-sdw: add firmware download status check
>
> On Mon, Sep 21, 2026 at 02:40:53PM +0800, Baojun Xu wrote:
> > Currently, the firmware download is unnecessarily triggered on every
> > system resume from suspend, causing significant wake-up latency. However,
> > this step is redundant if the AMP remains powered on.
> > Furthermore, PRAM access is skipped if the firmware version read from
> > registers matches the expected value, indicating that the memory content
> > was retained across the AMP reset.
>
> > @@ -431,6 +432,8 @@ static int tas2783_sdca_mbq_size(struct device *dev, u32 reg)
> >
> > case SDW_SDCA_CTL(1, TAS2783_SDCA_ENT_XU22, 0x12, 0):
> > case SDW_SDCA_CTL(1, TAS2783_SDCA_ENT_XU22, 0x13, 0):
> > + case PRAM_ADDR_START ... PRAM_ADDR_END:
> > + case YRAM_ADDR_START ... YRAM_ADDR_END:
> > return 4;
>
> Are you sure these are MBQ registers?
Not, will remove in next version.
>
> > @@ -794,6 +803,13 @@ static void tas2783_fw_ready(const struct firmware *fmw, void *context)
> > file->version, file->length,
> > file->dest_addr, file->fw_data);
> >
> > + if (tas_dev->fw_version == fw_version &&
> > + file->dest_addr >= PRAM_ADDR_START &&
> > + (file->dest_addr + file->length) <= PRAM_ADDR_END) {
> > + cur_file++;
> > + dev_dbg(tas_dev->dev, "Ignore PRAM block");
> > + continue;
> > + }
> > ret = sdw_nwrite_no_pm(tas_dev->sdw_peripheral,
> > file->dest_addr,
> > file->length,
>
> This could skip blocks unintentionally if the verison happens to be 0.
It will be non-zero value after reset, and the firmware version is also non-zero value.
>
> > + * failed after Power-On.
> > + */
> > + ret = sdw_nwrite_no_pm(tas_dev->sdw_peripheral,
> > + file->dest_addr,
> > + file->length,
> > + file->fw_data);
> > + if (ret < 0) {
> > + dev_err(tas_dev->dev,
> > + "FW download failed again: %d", ret);
> > + break;
> > + }
>
> This logs an error and gives up on the download...
Yes, re-try will work for this case. If re-try still failed, should be other
fatal problem, will quit with failed.
>
> > if (cur_file == 0) {
> > dev_err(tas_dev->dev, "fw with no files");
> > ret = -EINVAL;
> > } else {
> > tas2783_update_calibdata(tas_dev);
> > + ret = regmap_bulk_read(tas_dev->regmap, TAS2783_FW_VERSION,
> > + &val, 4);
> > + tas_dev->fw_version = (val[0] << 24) | (val[1] << 16) |
> > + (val[2] << 8) | val[3];
>
> ...then we do another read and overwrite the return value, potentially
> we might have a successful read.
Yes, read it with correct value after firmware downloaded. And save it for
compare in next firmware download.
>
> > @@ -951,7 +984,7 @@ static s32 tas_sdw_hw_params(struct snd_pcm_substream *substream,
> > TAS2783_SDCA_POW_STATE_ON);
> > if (!ret)
> > break;
> > - usleep_range(2000, 2200);
> > + fsleep(2200);
> > } while (retry--);
> > }
>
> This should be a separate patch.
Yes, will remove it in next version.
>
> > @@ -962,30 +995,6 @@ static s32 tas_sdw_hw_params(struct snd_pcm_substream *substream,
> > snd_sdw_params_to_config(substream, params,
> > &stream_config, &port_config);
> >
> > - /*
> > - * The two mono amps each render one channel of the stereo stream:
> > - * snd_sdw_params_to_config() hands every codec the full mask for
> > - * playback, which leaves the pair in mirror mode and one channel
> > - * unreproduced. Claim a single channel instead, keyed off the
> > - * machine-assigned component prefix rather than the SoundWire
> > - * address, which is board-specific: soc_sdw_ti_amp.c names the amps
> > - * tas2783-1..4.
> > - *
> > - * Which side an amp then renders does not follow from the bit that
> > - * is set - sdw_compute_slave_ports() advances the payload offset by
> > - * the popcount of ch_mask and never looks at which bit it is - but
> > - * from the amp's position in the codec order of the DAI link, which
> > - * on these boards matches the prefix numbering.
> > - */
> > - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK &&
> > - params_channels(params) == 2 && component->name_prefix) {
> > - const char *idx_str = strrchr(component->name_prefix, '-');
> > - unsigned long idx;
> > -
> > - if (idx_str && !kstrtoul(idx_str + 1, 10, &idx) && idx)
> > - port_config.ch_mask = (idx & 1) ? BIT(0) : BIT(1);
> > - }
> > -
> > /* port 1 for playback */
> > if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
> > port_config.num = 1;
>
> This looks like a rebasing mistake?
It should be different on 4-AMPs project, I will create separate patch for those issues.
>
> > @@ -1207,25 +1216,30 @@ static s32 tas_fw_load(struct tas2783_prv *tas_dev, struct sdw_slave *slave)
> > static s32 tas_io_init(struct device *dev, struct sdw_slave *slave)
> > {
> > struct tas2783_prv *tas_dev = dev_get_drvdata(dev);
> > + uint val;
>
> unsigned int.
OK, will update in next version.
>
> > + /* Check if the AMP is in reset status. */
> > + if (val == 0x20) {
> > + tas_dev->fw_dl_success = false;
> >
>
> I'm still not seeing where fw_dl_success gets set to true if the
> download was skipped.
If download was skipped, it should be true.
>
> > @@ -1437,6 +1454,7 @@ static void tas_sdw_remove(struct sdw_slave *peripheral)
> > struct tas2783_prv *tas_dev = dev_get_drvdata(&peripheral->dev);
> >
> > pm_runtime_disable(tas_dev->dev);
> > + regmap_write(tas_dev->regmap, TAS2783_SW_RESET, 0x1);
> > tas_remove(tas_dev);
> > mutex_destroy(&tas_dev->calib_lock);
> > mutex_destroy(&tas_dev->pde_lock);
>
> We need to make sure the regmap is not in cache only mode to do that
> reset, or make the register volatile.
Will remove it in next version.
Best Regards
Jim
next prev parent reply other threads:[~2026-09-21 9:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 6:40 [PATCH v5] ASoC: tas2783-sdw: add firmware download status check Baojun Xu
2026-09-21 8:45 ` Mark Brown
2026-09-21 9:22 ` Xu, Baojun [this message]
2026-09-21 9:27 ` [EXTERNAL] " Mark Brown
2026-09-21 10:08 ` Xu, Baojun
2026-09-21 10:14 ` 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=1c8da29a1fac4435a59783ab9fe7f68b@ti.com \
--to=baojun.xu@ti.com \
--cc=13916275206@139.com \
--cc=Syed.SabaKareem@amd.com \
--cc=alsa-devel@alsa-project.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=broonie@kernel.org \
--cc=henry.lo@ti.com \
--cc=k-yi@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=niranjan.hy@ti.com \
--cc=pin-hao.huang@hp.com \
--cc=robinchen@ti.com \
--cc=shenghao-ding@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.