mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®