From: "Holalu Yogendra, Niranjan" <niranjan.hy@ti.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"broonie@kernel.org" <broonie@kernel.org>,
"ckeepax@opensource.cirrus.com" <ckeepax@opensource.cirrus.com>,
"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
"perex@perex.cz" <perex@perex.cz>,
"tiwai@suse.com" <tiwai@suse.com>,
"cezary.rojewski@intel.com" <cezary.rojewski@intel.com>,
"peter.ujfalusi@linux.intel.com" <peter.ujfalusi@linux.intel.com>,
"yung-chuan.liao@linux.intel.com"
<yung-chuan.liao@linux.intel.com>,
"ranjani.sridharan@linux.intel.com"
<ranjani.sridharan@linux.intel.com>,
"linux-sound@vger.kernel.org" <linux-sound@vger.kernel.org>,
"kai.vehmanen@linux.intel.com" <kai.vehmanen@linux.intel.com>,
"Xu, Baojun" <baojun.xu@ti.com>,
"Ding, Shenghao" <shenghao-ding@ti.com>,
"Kasargod, Sandeep" <sandeepk@ti.com>,
"Hampiholi, Vallabha" <v-hampiholi@ti.com>
Subject: Re: [PATCH v11 2/4] ASoC: tac5xx2-sdw: add soundwire based codec driver
Date: Wed, 29 Apr 2026 04:06:46 +0000 [thread overview]
Message-ID: <d624812fe0f54563a2e628dbf1a428e3@ti.com> (raw)
In-Reply-To: <7137df6a-5e49-4516-a356-3414f7d14c33@linux.dev>
> On 01:28-20260429, Pierre-Louis Bossart wrote:
> Subject: Re: [PATCH v11 2/4] ASoC: tac5xx2-sdw: add soundwire based codec driver
> > +struct tac5xx2_prv {
> > + struct snd_soc_component *component;
> > + struct sdw_slave *sdw_peripheral;
> > + struct sdca_function_data *sa_func_data;
> > + struct sdca_function_data *sm_func_data;
> > + struct sdca_function_data *uaj_func_data;
> > + struct sdca_function_data *hid_func_data;
> > + enum sdw_slave_status status;
> > + /* serialize potential concurrent uaj detection in .hw_params
> > + * during playback session and .interrupt_callback.
> > + */
> > + struct mutex uaj_lock;
>
> is this uaj_lock really needed, if you look below at hw_params there's nothing
> that looks even remotely tied to jack detection...
I think comment needs update to remove the hw_params related description here. ...
> > +static int tac_sdw_hw_params(struct snd_pcm_substream *substream,
> > + struct snd_pcm_hw_params *params,
> > + struct snd_soc_dai *dai)
> > +{
> > + struct snd_soc_component *component = dai->component;
> > + struct tac5xx2_prv *tac_dev =
> > + return ret;
>
> so as I said above there's nothing here that might conflict with the interrupt
> callback?
> What am I missing?
... uaj_lock is still needed to handle potential race condition in case .set_jack is called with jack as NULL
(potentially to disable the jack functionality ) when the interrupt is being handled.
This was suggested in earlier review comment and it made sense to me as well
> > +static const struct snd_soc_dai_ops tac_dai_ops = {
> > + .hw_params = tac_sdw_hw_params,
> > + .hw_free = tac_sdw_pcm_hw_free,
> > + .set_stream = tac_set_sdw_stream,
> > + .shutdown = tac_sdw_shutdown,
>
> so set_jack is now dynamically added...
>
> > +};
> > +
>
> > +static int tac5xx2_sdca_headset_detect(struct tac5xx2_prv *tac_dev)
> > +{
> > + int val, ret;
> > +
> > + if (!tac_has_uaj_support(tac_dev))
> > + return 0;
>
> ... but here the test for uaj_support is still there? Is this needed?
I will drop this.
> > +static int tac5xx2_set_jack(struct snd_soc_component *component,
> > + struct snd_soc_jack *hs_jack, void *data)
> > +{
> > + struct tac5xx2_prv *tac_dev =
> snd_soc_component_get_drvdata(component);
> > + int ret;
> > +
> > + guard(mutex)(&tac_dev->uaj_lock);
> > + if (!hs_jack) {
> > + if (tac_dev->hs_jack) {
> > + tac_dev->hs_jack = NULL;
> > + ret = 0;
> > + goto disable_interrupts;
> > + }
> > + return 0;
> > + }
> > +
> > + tac_dev->hs_jack = hs_jack;
> > + if (!tac_dev->hw_init) {
> > + dev_err(tac_dev->dev, "jack init failed, hw not initialized");
> > + return 0;
> > + }
>
> should this test go up to the start of the function?
> And isn't there a case where .set_jack can be invoked before the device is fully
> initialized?
>
> I have a vague memory this was the case with other codecs, please double-
> check.
I have already dropped this in v12 patch to remove the hw_init check and let regcache handle this.
> > +
> > +static int tac_interrupt_callback(struct sdw_slave *slave,
> > + struct sdw_slave_intr_status *status)
> > +{
> > + struct tac5xx2_prv *tac_dev = dev_get_drvdata(&slave->dev);
> > + struct device *dev = &slave->dev;
> > + int ret = 0;
> > + int btn_type = 0;
> > + unsigned int sdca_int2, sdca_int3, jack_report_mask = 0;
> > +
> > + guard(mutex)(&tac_dev->uaj_lock);
>
> again what does this uaj_lock protect?
commented above.
> > +
> > +static s32 tac5xx2_sdca_dev_resume(struct device *dev)
> > +{
> > + struct sdw_slave *slave = dev_to_sdw_dev(dev);
> > + struct tac5xx2_prv *tac_dev = dev_get_drvdata(dev);
> > + unsigned long t;
> > + int ret;
> > + bool had_unattached = false;
> > +
> > + if (!tac_dev->first_hw_init) {
> > + dev_dbg(dev, "Device not initialized yet, skipping resume
> sync\n");
> > + return 0;
> > + }
> > +
> > + if (!slave->unattach_request)
> > + goto regmap_sync;
> > +
> > + had_unattached = true;
> > + t = wait_for_completion_timeout(&slave->initialization_complete,
> > +
> msecs_to_jiffies(TAC5XX2_PROBE_TIMEOUT_MS));
> > + if (!t) {
> > + dev_err(&slave->dev, "resume: initialization timed out\n");
> > + sdw_show_ping_status(slave->bus, true);
> > + return -ETIMEDOUT;
> > + }
> > + slave->unattach_request = 0;
> > + dev_dbg(tac_dev->dev, "%s wait for resume complete, starting
> writes\n", __func__);
> > +
> > + /* Detect and set jack type for UAJ path before playback.
> > + * This is required as jack detection does not trigger interrupt
> > + * when device is in runtime_pm suspend with bus in clock stop mode.
> > + */
> > + mutex_lock(&tac_dev->uaj_lock);
> > + tac5xx2_sdca_headset_detect(tac_dev);
> > + mutex_unlock(&tac_dev->uaj_lock);
>
> again what does this mutex protect? there is no interrupt so there cannot be
> any conflict/race with the interrupt callback and even less with hw_params.
commented above
>
> > +static struct pci_dev *tac_get_pci_dev(struct sdw_slave *peripheral)
> > +{
> > + struct device *dev = &peripheral->dev;
> > +
> > + for (; dev; dev = dev->parent) {
> > + if (dev_is_pci(dev))
> > + return to_pci_dev(dev);
>
> I find this surprising, what is the purpose of going up in the device hierarchy to
> find a PCI device?
> Why would this driver care?
For Speaker protection modules running on the firmware based devices, we need to have
different firmware for different projects as there are firmware differences.
We need a way to uniquely identify firmware for each of these projects.
Currently this is done through the "subsystem id" which is part of the pci device.
So we find the pci bus and then identify the subsystem id.
I see similar changes in class driver as well sound/soc/sdca/sdca_fdl.c.
> > +static int tac_update_status(struct sdw_slave *slave,
> > + enum sdw_slave_status status)
> > +{
> > + int ret;
> > + bool first = false;
> > + struct tac5xx2_prv *tac_dev = dev_get_drvdata(&slave->dev);
> > + struct device *dev = &slave->dev;
> > +
> > + tac_dev->status = status;
> > + if (status == SDW_SLAVE_UNATTACHED) {
> > + tac_dev->hw_init = false;
> > + tac_dev->fw_dl_success = false;
> > + }
> > +
> > + if (tac_dev->hw_init || tac_dev->status != SDW_SLAVE_ATTACHED) {
> > + dev_dbg(dev, "%s: early return, hw_init=%d, status=%d",
> > + __func__, tac_dev->hw_init, tac_dev->status);
> > + return 0;
> > + }
> > +
> > + if (!tac_dev->first_hw_init) {
> > + pm_runtime_set_autosuspend_delay(tac_dev->dev, 3000);
> > + pm_runtime_use_autosuspend(tac_dev->dev);
> > + pm_runtime_mark_last_busy(tac_dev->dev);
> > + pm_runtime_set_active(tac_dev->dev);
> > + pm_runtime_enable(tac_dev->dev);
>
> I suggest you look at other codec drivers, all the pm_runtime configuration is
> done in the .probe callback and only set_active done upon a change in status.
I thought I will keep it here so that all pm_runtime_* initializations are in one place.
> > +
> > +static int tac5xx2_sdw_clk_stop(struct sdw_slave *peripheral,
> > + enum sdw_clk_stop_mode mode,
> > + enum sdw_clk_stop_type type)
> > +{
> > + struct tac5xx2_prv *tac_dev = dev_get_drvdata(&peripheral->dev);
> > +
> > + dev_dbg(tac_dev->dev, "%s: mode:%d type:%d", __func__, mode,
> type);
> > + return 0;
>
> this looks rather useless, no?
Yes, currently only required in case of debugging.
> > +static void tac_sdw_remove(struct sdw_slave *peripheral)
> > +{
> > + struct tac5xx2_prv *tac_dev = dev_get_drvdata(&peripheral->dev);
> > +
> > + mutex_destroy(&tac_dev->uaj_lock);
> > + dev_set_drvdata(&peripheral->dev, NULL);
>
> if you move all the runtime_pm stuff to the probe above, this remove() would
> also need to be modified to add a pm_runtime_disable()
Already taken care in v12.
Thanks
Regards
Niranjan
next prev parent reply other threads:[~2026-04-29 4:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-27 8:23 [PATCH v11 1/4] ASoC: SDCA: Add PDE verification reusable helper Niranjan H Y
2026-04-27 8:23 ` [PATCH v11 2/4] ASoC: tac5xx2-sdw: add soundwire based codec driver Niranjan H Y
2026-04-28 0:52 ` Mark Brown
2026-04-28 19:57 ` Pierre-Louis Bossart
2026-04-29 4:06 ` Holalu Yogendra, Niranjan [this message]
2026-04-27 8:24 ` [PATCH v11 3/4] ASoC: sdw_utils: TI amp utility for tac5xx2 family Niranjan H Y
2026-04-27 8:24 ` [PATCH v11 4/4] ASoC: tac5xx2-sdw: ACPI match for intel mtl platform Niranjan H Y
2026-04-27 8:47 ` [PATCH v11 1/4] ASoC: SDCA: Add PDE verification reusable helper Charles Keepax
2026-04-28 0:45 ` Mark Brown
2026-04-28 12:05 ` Charles Keepax
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=d624812fe0f54563a2e628dbf1a428e3@ti.com \
--to=niranjan.hy@ti.com \
--cc=baojun.xu@ti.com \
--cc=broonie@kernel.org \
--cc=cezary.rojewski@intel.com \
--cc=ckeepax@opensource.cirrus.com \
--cc=kai.vehmanen@linux.intel.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=peter.ujfalusi@linux.intel.com \
--cc=pierre-louis.bossart@linux.dev \
--cc=ranjani.sridharan@linux.intel.com \
--cc=sandeepk@ti.com \
--cc=shenghao-ding@ti.com \
--cc=tiwai@suse.com \
--cc=v-hampiholi@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