From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Charles Keepax <ckeepax@opensource.cirrus.com>, vkoul@kernel.org
Cc: yung-chuan.liao@linux.intel.com, sanyog.r.kale@intel.com,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
patches@opensource.cirrus.com
Subject: Re: [PATCH v2] soundwire: bus: Don't filter slave alerts
Date: Tue, 18 Apr 2023 10:45:53 -0500 [thread overview]
Message-ID: <3e1b86fb-0a3f-6dce-b3b4-6ee3971fb61d@linux.intel.com> (raw)
In-Reply-To: <20230418140650.297279-1-ckeepax@opensource.cirrus.com>
On 4/18/23 09:06, Charles Keepax wrote:
> It makes sense to have only a single point responsible for ensuring
> that all currently pending IRQs are handled. The current code in
> sdw_handle_slave_alerts confusingly splits this process in two. This
> code will loop until the asserted IRQs are cleared but it will only
> handle IRQs that were already asserted when it was called. This
> means the caller must also loop (either manually, or through its IRQ
> mechanism) until the IRQs are all handled. It makes sense to either do
> all the looping in sdw_handle_slave_alerts or do no looping there and
> let the host controller repeatedly call it until things are handled.
>
> There are realistically two sensible host controllers, those that
> will generate an IRQ when the alert status changes and those
> that will generate an IRQ continuously whilst the alert status
> is high. The current code will work fine for the second of those
> systems but not the first with out additional looping in the host
> controller. Removing the code that filters out new IRQs whilst
> the handler is running enables both types of host controller to be
> supported and simplifies the code. The code will still only loop up to
> SDW_READ_INTR_CLEAR_RETRY times, so it shouldn't be possible for it to
> get completely stuck handling IRQs forever, and if you are generating
> IRQs faster than you can handle them you likely have bigger problems
> anyway.
>
> This fixes an issue on the Cadence SoundWire IP, which only generates
> IRQs on an alert status change, where an alert which arrives whilst
> another alert is being handled will never be handled and will block
> all future alerts from being handled.
>
> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Makes sense to me, thanks for the patch.
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
> ---
>
> Changes since v1:
> - Update commit message
>
> Thanks,
> Charles
>
> drivers/soundwire/bus.c | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
> index 1ea6a64f8c4a5..338f4f0b5d0cc 100644
> --- a/drivers/soundwire/bus.c
> +++ b/drivers/soundwire/bus.c
> @@ -1588,7 +1588,7 @@ static int sdw_handle_slave_alerts(struct sdw_slave *slave)
> unsigned long port;
> bool slave_notify;
> u8 sdca_cascade = 0;
> - u8 buf, buf2[2], _buf, _buf2[2];
> + u8 buf, buf2[2];
> bool parity_check;
> bool parity_quirk;
>
> @@ -1745,9 +1745,9 @@ static int sdw_handle_slave_alerts(struct sdw_slave *slave)
> "SDW_SCP_INT1 recheck read failed:%d\n", ret);
> goto io_err;
> }
> - _buf = ret;
> + buf = ret;
>
> - ret = sdw_nread_no_pm(slave, SDW_SCP_INTSTAT2, 2, _buf2);
> + ret = sdw_nread_no_pm(slave, SDW_SCP_INTSTAT2, 2, buf2);
> if (ret < 0) {
> dev_err(&slave->dev,
> "SDW_SCP_INT2/3 recheck read failed:%d\n", ret);
> @@ -1765,12 +1765,8 @@ static int sdw_handle_slave_alerts(struct sdw_slave *slave)
> }
>
> /*
> - * Make sure no interrupts are pending, but filter to limit loop
> - * to interrupts identified in the first status read
> + * Make sure no interrupts are pending
> */
> - buf &= _buf;
> - buf2[0] &= _buf2[0];
> - buf2[1] &= _buf2[1];
> stat = buf || buf2[0] || buf2[1] || sdca_cascade;
>
> /*
next prev parent reply other threads:[~2023-04-18 16:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 14:06 [PATCH v2] soundwire: bus: Don't filter slave alerts Charles Keepax
2023-04-18 15:45 ` Pierre-Louis Bossart [this message]
2023-05-08 7:33 ` Vinod Koul
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=3e1b86fb-0a3f-6dce-b3b4-6ee3971fb61d@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=ckeepax@opensource.cirrus.com \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@opensource.cirrus.com \
--cc=sanyog.r.kale@intel.com \
--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