From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Charles Keepax <ckeepax@opensource.cirrus.com>,
broonie@kernel.org, lee@kernel.org, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
tglx@linutronix.de, maz@kernel.org, linus.walleij@linaro.org,
vkoul@kernel.org
Cc: lgirdwood@gmail.com, yung-chuan.liao@linux.intel.com,
sanyog.r.kale@intel.com, alsa-devel@alsa-project.org,
patches@opensource.cirrus.com, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-spi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/10] soundwire: bus: Allow SoundWire peripherals to register IRQ handlers
Date: Fri, 12 May 2023 08:45:51 -0500 [thread overview]
Message-ID: <0471f085-14bf-c159-9b92-62983af6c19a@linux.intel.com> (raw)
In-Reply-To: <20230512122838.243002-2-ckeepax@opensource.cirrus.com>
> @@ -1711,6 +1739,9 @@ static int sdw_handle_slave_alerts(struct sdw_slave *slave)
> struct device *dev = &slave->dev;
> struct sdw_driver *drv = drv_to_sdw_driver(dev->driver);
>
> + if (slave->prop.use_domain_irq && slave->irq)
> + handle_nested_irq(slave->irq);
> +
I am a bit lost here, I can understand that alerts would be handled by a
dedicated handler, but here the code continues and will call the
existing interrupt_callback.
Is this intentional? I wonder if there's a risk with two entities
dealing with the same event and programming the same registers.
Shouldn't there be some sort of 'either or' rule?
> if (drv->ops && drv->ops->interrupt_callback) {
> slave_intr.sdca_cascade = sdca_cascade;
> slave_intr.control_port = clear;
> diff --git a/drivers/soundwire/bus_type.c b/drivers/soundwire/bus_type.c
> index 1f43ee848eac8..fafbc284e82da 100644
> --- a/drivers/soundwire/bus_type.c
> +++ b/drivers/soundwire/bus_type.c
> @@ -122,6 +122,12 @@ static int sdw_drv_probe(struct device *dev)
> if (drv->ops && drv->ops->read_prop)
> drv->ops->read_prop(slave);
>
> + if (slave->prop.use_domain_irq) {
> + slave->irq = irq_create_mapping(slave->bus->domain, slave->dev_num);
> + if (!slave->irq)
> + dev_warn(dev, "Failed to map IRQ\n");
> + }
> +
> /* init the sysfs as we have properties now */
> ret = sdw_slave_sysfs_init(slave);
> if (ret < 0)
> @@ -166,7 +172,13 @@ static int sdw_drv_remove(struct device *dev)
> int ret = 0;
>
> mutex_lock(&slave->sdw_dev_lock);
> +
> slave->probed = false;
> +
> + if (slave->prop.use_domain_irq)
> + irq_dispose_mapping(irq_find_mapping(slave->bus->domain,
> + slave->dev_num));
> +
> mutex_unlock(&slave->sdw_dev_lock);
>
> if (drv->remove)
> diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h
> index ef645de13ae93..c3ab5e5f9cfa4 100644
> --- a/include/linux/soundwire/sdw.h
> +++ b/include/linux/soundwire/sdw.h
> @@ -5,6 +5,8 @@
> #define __SOUNDWIRE_H
>
> #include <linux/bug.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
> #include <linux/mod_devicetable.h>
> #include <linux/bitfield.h>
>
> @@ -369,6 +371,7 @@ struct sdw_dpn_prop {
> * @clock_reg_supported: the Peripheral implements the clock base and scale
> * registers introduced with the SoundWire 1.2 specification. SDCA devices
> * do not need to set this boolean property as the registers are required.
> + * @use_domain_irq: call actual IRQ handler on slave, as well as callback
what callback, the interrupt_callback? That would mean the interrupt is
handled twice?
I am probably missing something here?
> */
> struct sdw_slave_prop {
> u32 mipi_revision;
> @@ -393,6 +396,7 @@ struct sdw_slave_prop {
> u8 scp_int1_mask;
> u32 quirks;
> bool clock_reg_supported;
> + bool use_domain_irq;
> };
next prev parent reply other threads:[~2023-05-12 14:54 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-12 12:28 [PATCH 00/10] Add cs42l43 PC focused SoundWire CODEC Charles Keepax
2023-05-12 12:28 ` [PATCH 01/10] soundwire: bus: Allow SoundWire peripherals to register IRQ handlers Charles Keepax
2023-05-12 13:45 ` Pierre-Louis Bossart [this message]
2023-05-12 16:02 ` Charles Keepax
2023-05-12 16:34 ` Pierre-Louis Bossart
2023-05-12 16:43 ` Charles Keepax
2023-05-12 12:28 ` [PATCH 02/10] ASoC: soc-component: Add notify control helper function Charles Keepax
2023-05-12 12:28 ` [PATCH 03/10] ASoC: ak4118: Update to use new component control notify helper Charles Keepax
2023-05-12 13:48 ` Pierre-Louis Bossart
2023-05-12 15:42 ` Charles Keepax
2023-05-12 12:28 ` [PATCH 04/10] ASoC: wm_adsp: Update to use new component control notify helepr Charles Keepax
2023-05-12 12:28 ` [PATCH 05/10] dt-bindings: mfd: cirrus,cs42l43: Add initial DT binding Charles Keepax
2023-05-12 15:23 ` Krzysztof Kozlowski
2023-05-12 16:15 ` Charles Keepax
2023-05-13 18:05 ` Krzysztof Kozlowski
2023-05-12 15:25 ` Krzysztof Kozlowski
2023-05-12 16:18 ` Charles Keepax
2023-05-13 18:08 ` Krzysztof Kozlowski
2023-05-15 10:02 ` Charles Keepax
2023-05-12 12:28 ` [PATCH 06/10] mfd: cs42l43: Add support for cs42l43 core driver Charles Keepax
2023-05-12 14:52 ` Pierre-Louis Bossart
2023-05-18 10:05 ` Charles Keepax
2023-05-12 15:16 ` Krzysztof Kozlowski
2023-05-18 10:24 ` Charles Keepax
2023-05-18 15:16 ` Pierre-Louis Bossart
2023-05-18 16:15 ` Richard Fitzgerald
2023-05-18 16:47 ` Pierre-Louis Bossart
2023-05-19 9:24 ` Charles Keepax
2023-05-12 12:28 ` [PATCH 07/10] irqchip/cs42l43: Add support for the cs42l43 IRQs Charles Keepax
2023-05-12 15:10 ` Marc Zyngier
2023-05-12 15:39 ` Charles Keepax
2023-05-12 16:07 ` Marc Zyngier
2023-05-12 16:42 ` Charles Keepax
2023-05-15 1:08 ` Mark Brown
2023-05-15 9:57 ` Charles Keepax
2023-05-16 10:07 ` Lee Jones
2023-05-15 11:25 ` Lee Jones
2023-05-16 8:51 ` Marc Zyngier
2023-05-16 10:09 ` Lee Jones
2023-05-16 10:23 ` Marc Zyngier
2023-05-16 10:41 ` Charles Keepax
2023-05-12 15:27 ` Krzysztof Kozlowski
2023-05-12 12:28 ` [PATCH 08/10] pinctrl: cs42l43: Add support for the cs42l43 Charles Keepax
2023-05-12 15:30 ` Krzysztof Kozlowski
2023-05-12 15:54 ` Charles Keepax
2023-05-13 18:00 ` Krzysztof Kozlowski
2023-05-12 19:19 ` andy.shevchenko
2023-05-15 10:13 ` Charles Keepax
2023-05-16 19:03 ` Andy Shevchenko
2023-05-17 10:13 ` Charles Keepax
2023-05-17 13:59 ` Andy Shevchenko
2023-05-17 14:11 ` Pierre-Louis Bossart
2023-05-17 14:30 ` Mark Brown
2023-05-12 12:28 ` [PATCH 09/10] spi: cs42l43: Add SPI controller support Charles Keepax
2023-05-12 19:03 ` andy.shevchenko
2023-05-12 12:28 ` [PATCH 10/10] ASoC: cs42l43: Add support for the cs42l43 Charles Keepax
2023-05-15 15:21 ` (subset) [PATCH 00/10] Add cs42l43 PC focused SoundWire CODEC 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=0471f085-14bf-c159-9b92-62983af6c19a@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=ckeepax@opensource.cirrus.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lee@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=maz@kernel.org \
--cc=patches@opensource.cirrus.com \
--cc=robh+dt@kernel.org \
--cc=sanyog.r.kale@intel.com \
--cc=tglx@linutronix.de \
--cc=vkoul@kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).