From: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
To: Charles Keepax <ckeepax@opensource.cirrus.com>, broonie@kernel.org
Cc: lgirdwood@gmail.com, linux-sound@vger.kernel.org,
patches@opensource.cirrus.com, yung-chuan.liao@linux.intel.com,
peter.ujfalusi@linux.intel.com
Subject: Re: [PATCH 7/7] ASoC: SDCA: Add some initial IRQ handlers
Date: Tue, 10 Jun 2025 11:07:00 +0200 [thread overview]
Message-ID: <283bafe1-136d-46f4-a83b-7467d0344fd4@linux.dev> (raw)
In-Reply-To: <20250609123936.292827-8-ckeepax@opensource.cirrus.com>
> +static irqreturn_t function_status_handler(int irq, void *data)
> +{
> + struct sdca_interrupt *interrupt = data;
> + struct device *dev = interrupt->component->dev;
> + unsigned int reg, val;
> + unsigned long status;
> + unsigned int mask;
> + int ret;
> +
> + reg = SDW_SDCA_CTL(interrupt->function->desc->adr, interrupt->entity->id,
> + interrupt->control->sel, 0);
> +
> + ret = regmap_read(interrupt->component->regmap, reg, &val);
> + if (ret < 0) {
> + dev_err(dev, "failed to read function status: %d\n", ret);
> + return IRQ_NONE;
usually when a read fails, the entire device is in the weeds. Not sure squelching the interrupts is wise, something more drastic should happen.
> + }
> +
> + dev_dbg(dev, "function status: %#x\n", val);
> +
> + status = val;
> + for_each_set_bit(mask, &status, BITS_PER_BYTE) {
> + mask = 1 << mask;
> +
> + switch (mask) {
> + case SDCA_CTL_ENTITY_0_FUNCTION_NEEDS_INITIALIZATION:
> + //FIXME: Add init writes
> + break;
between here...
> + case SDCA_CTL_ENTITY_0_FUNCTION_FAULT:
> + dev_err(dev, "function fault\n");
> + break;
> + case SDCA_CTL_ENTITY_0_UMP_SEQUENCE_FAULT:
> + dev_err(dev, "ump sequence fault\n");
> + break;
> + case SDCA_CTL_ENTITY_0_DEVICE_NEWLY_ATTACHED:
> + case SDCA_CTL_ENTITY_0_INTS_DISABLED_ABNORMALLY:
> + case SDCA_CTL_ENTITY_0_STREAMING_STOPPED_ABNORMALLY:
> + case SDCA_CTL_ENTITY_0_FUNCTION_HAS_BEEN_RESET:
... and here, the status bit essentially mean the Function isn't working as expected. I really don't see the point of attempting to write a register below, we'd need something that essentially resets the SoundWire device to restart from a known position.
> + case SDCA_CTL_ENTITY_0_FUNCTION_BUSY:
> + break;
Conversely this one seems harmless, FUNCTION_BUSY only impacts specific SDCA registers and this status cannot have any bearing on how to deal with interrupts.
> + }
> + }
> +
> + ret = regmap_write(interrupt->component->regmap, reg, val);
> + if (ret < 0) {
> + dev_err(dev, "failed to clear function status: %d\n", ret);
> + return IRQ_NONE;
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t detected_mode_handler(int irq, void *data)
> +{
> + struct sdca_interrupt *interrupt = data;
> + struct snd_soc_component *component = interrupt->component;
> + struct device *dev = component->dev;
> + struct snd_soc_card *card = component->card;
> + struct rw_semaphore *rwsem = &card->snd_card->controls_rwsem;
> + struct snd_kcontrol *kctl = interrupt->priv;
> + struct snd_ctl_elem_value ucontrol;
> + struct soc_enum *soc_enum;
> + unsigned int reg, val;
> + int ret;
> +
> + if (!kctl) {
> + const char *name __free(kfree) = kasprintf(GFP_KERNEL, "%s %s",
> + interrupt->entity->label,
> + SDCA_CTL_SELECTED_MODE_NAME);
> +
> + if (!name)
> + return -ENOMEM;
> +
> + kctl = snd_soc_component_get_kcontrol(component, name);
> + if (!kctl) {
> + dev_dbg(dev, "control not found: %s\n", name);
> + return IRQ_NONE;
> + }
> +
> + interrupt->priv = kctl;
> + }
> +
> + soc_enum = (struct soc_enum *)kctl->private_value;
> +
> + reg = SDW_SDCA_CTL(interrupt->function->desc->adr, interrupt->entity->id,
> + interrupt->control->sel, 0);
Humm, I have to walk back what I wrote above, if FUNCTION_BUSY is set the read below can be problematic, no?
> + ret = regmap_read(component->regmap, reg, &val);
> + if (ret < 0) {
> + dev_err(dev, "failed to read detected mode: %d\n", ret);
> + return IRQ_NONE;
> + }
> +
> + switch (val) {
> + case SDCA_DETECTED_MODE_DETECTION_IN_PROGRESS:
> + case SDCA_DETECTED_MODE_JACK_UNKNOWN:
> + reg = SDW_SDCA_CTL(interrupt->function->desc->adr,
> + interrupt->entity->id,
> + SDCA_CTL_GE_SELECTED_MODE, 0);
> +
> + /*
> + * Selected mode is not typically a volatile register, but
> + * force a read from the hardware in the case detected mode
> + * is unknown to see what the device selected as a "safe"
> + * option.
> + */
I am not sure this explanation is correct. I was my understanding that when there's a jack interrupt, both the DETECTED and SELECTED values are set by hardware, but SELECTED can be overridden by higher-level software or user interaction. DETECTED is RO, SELECTED is R/W IIRC.
> + regcache_drop_region(component->regmap, reg, reg);
> +
> + ret = regmap_read(component->regmap, reg, &val);
> + if (ret) {
> + dev_err(dev, "failed to re-check selected mode: %d\n", ret);
> + return IRQ_NONE;
> + }
> + break;
> + default:
> + break;
> + }
> +
> + dev_dbg(dev, "%s: %#x\n", interrupt->name, val);
> +
> + ucontrol.value.enumerated.item[0] = snd_soc_enum_val_to_item(soc_enum, val);
> +
> + down_write(rwsem);
> + ret = kctl->put(kctl, &ucontrol);
> + up_write(rwsem);
> + if (ret < 0) {
> + dev_err(dev, "failed to update selected mode: %d\n", ret);
> + return IRQ_NONE;
> + }
> +
> + snd_ctl_notify(card->snd_card, SNDRV_CTL_EVENT_MASK_VALUE, &kctl->id);
> +
> + return IRQ_HANDLED;
> +}
> +
> static int sdca_irq_request_locked(struct device *dev,
> struct sdca_interrupt_info *info,
> int sdca_irq, const char *name,
> @@ -202,6 +339,7 @@ int sdca_irq_populate(struct sdca_function_data *function,
> struct sdca_control *control = &entity->controls[j];
> int irq = control->interrupt_position;
> struct sdca_interrupt *interrupt;
> + irq_handler_t handler;
> const char *name;
> int ret;
>
> @@ -226,8 +364,23 @@ int sdca_irq_populate(struct sdca_function_data *function,
> if (ret)
> return ret;
>
> + handler = base_handler;
> +
> + switch (entity->type) {
> + case SDCA_ENTITY_TYPE_ENTITY_0:
> + if (control->sel == SDCA_CTL_ENTITY_0_FUNCTION_STATUS)
> + handler = function_status_handler;
> + break;
> + case SDCA_ENTITY_TYPE_GE:
> + if (control->sel == SDCA_CTL_GE_DETECTED_MODE)
> + handler = detected_mode_handler;
> + break;
> + default:
> + break;
> + }
> +
> ret = sdca_irq_request_locked(dev, info, irq, interrupt->name,
> - base_handler, interrupt);
> + handler, interrupt);
> if (ret) {
> dev_err(dev, "failed to request irq %s: %d\n",
> name, ret);
next prev parent reply other threads:[~2025-06-10 9:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-09 12:39 [PATCH 0/7] Add SDCA IRQ support and some misc fixups Charles Keepax
2025-06-09 12:39 ` [PATCH 1/7] MAINTAINERS: Add SDCA maintainers entry Charles Keepax
2025-06-09 12:39 ` [PATCH 2/7] ASoC: SDCA: Add missing default in switch in entity_pde_event() Charles Keepax
2025-06-09 12:39 ` [PATCH 3/7] ASoC: SDCA: Fixup some kernel doc errors Charles Keepax
2025-06-09 12:39 ` [PATCH 4/7] ASoC: SDCA: Minor selected/detected mode control fixups Charles Keepax
2025-06-09 12:39 ` [PATCH 5/7] ASoC: SDCA: Add flag for unused IRQs Charles Keepax
2025-06-09 12:39 ` [PATCH 6/7] ASoC: SDCA: Generic interrupt support Charles Keepax
2025-06-10 8:52 ` Pierre-Louis Bossart
2025-06-10 10:21 ` Charles Keepax
2025-06-10 17:55 ` Pierre-Louis Bossart
2025-06-17 9:30 ` Charles Keepax
2025-06-26 11:47 ` Pierre-Louis Bossart
2025-06-09 12:39 ` [PATCH 7/7] ASoC: SDCA: Add some initial IRQ handlers Charles Keepax
2025-06-10 9:07 ` Pierre-Louis Bossart [this message]
2025-06-10 12:26 ` Mark Brown
2025-06-10 12:29 ` Charles Keepax
2025-06-10 1:32 ` [PATCH 0/7] Add SDCA IRQ support and some misc fixups Liao, Bard
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=283bafe1-136d-46f4-a83b-7467d0344fd4@linux.dev \
--to=pierre-louis.bossart@linux.dev \
--cc=broonie@kernel.org \
--cc=ckeepax@opensource.cirrus.com \
--cc=lgirdwood@gmail.com \
--cc=linux-sound@vger.kernel.org \
--cc=patches@opensource.cirrus.com \
--cc=peter.ujfalusi@linux.intel.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