mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Shenghao Ding <shenghao-ding@ti.com>,
	andriy.shevchenko@linux.intel.com, lgirdwood@gmail.com,
	perex@perex.cz, 13916275206@139.com, alsa-devel@alsa-project.org,
	linux-kernel@vger.kernel.org, liam.r.girdwood@intel.com,
	bard.liao@intel.com, yung-chuan.liao@linux.intel.com,
	kevin-lu@ti.com, tiwai@suse.de, baojun.xu@ti.com, soyer@irl.hu,
	Baojun.Xu@fpt.com, navada@ti.com, v-po@ti.com
Subject: Re: [PATCH v12] ASoc: tas2783: Add tas2783 codec driver
Date: Tue, 2 Apr 2024 18:59:33 +0100	[thread overview]
Message-ID: <630746e4-1172-4dbd-90c8-314cbab684b3@sirena.org.uk> (raw)
In-Reply-To: <df80758b-f3d6-4456-8600-1a19fab75407@linux.intel.com>

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

On Mon, Apr 01, 2024 at 08:50:24AM -0500, Pierre-Louis Bossart wrote:

> > +static int tasdevice_comp_probe(struct snd_soc_component *comp)
> > +{

> > +	ret = request_firmware(&fw_entry, dspfw_binaryname, tas_dev->dev);
> > +	if (ret) {
> > +		dev_err(tas_dev->dev,
> > +			"%s: request_firmware %x open status: %d.\n", __func__,
> > +			tas_dev->sdw_peripheral->id.unique_id, ret);
> > +		goto out;
> > +	}
> > +
> > +	tasdevice_dspfw_ready(fw_entry, tas_dev);

> Question: is there a specific reason why all this functionality needs to
> be done in a component probe instead of when the device reports as ATTACHED?

> Since you have an interaction with userspace for the firmware, and
> firmware download takes time, you would want to do this as early as
> possible.

> Usually the component probe is part of the card creation, so you could
> add card-related or control related things. Downloading firmware does
> not strike me as a card-related activity?

This does have the effect of ensuring that the card won't instantiate
without firmware.  Given how utterly dependent on firmware this device
seems to be I can see a case for blocking card registration until the
firmware is ready, there's a usability thing there but it feels like
there's a usability issue with any error handling for missing firmware
on these devices and not registering the card does seem like a valid
choice.  That said it would still be nicer to initiate the firmware
process earlier in order to minimise latency and then either defer
registration of the component until we've managed to load firmware or
have a check at component probe to make sure that the firmware is ready.

> Another question is whether the firmware needs to be downloaded again
> during system/pm_runtime resume? That may depend on how power is managed
> at the hardware level, but in theory an SDCA device should report to the
> host whether the firmware is still valid or needs to be downloaded.

That does seem like a concern too.

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

      reply	other threads:[~2024-04-02 17:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-31  2:14 Shenghao Ding
2024-04-01 13:50 ` Pierre-Louis Bossart
2024-04-02 17:59   ` Mark Brown [this message]

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=630746e4-1172-4dbd-90c8-314cbab684b3@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=13916275206@139.com \
    --cc=Baojun.Xu@fpt.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=baojun.xu@ti.com \
    --cc=bard.liao@intel.com \
    --cc=kevin-lu@ti.com \
    --cc=lgirdwood@gmail.com \
    --cc=liam.r.girdwood@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=navada@ti.com \
    --cc=perex@perex.cz \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=shenghao-ding@ti.com \
    --cc=soyer@irl.hu \
    --cc=tiwai@suse.de \
    --cc=v-po@ti.com \
    --cc=yung-chuan.liao@linux.intel.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

all inboxes | Powered by JetHome®