From: Andrew Jeffery <andrew@codeconstruct.com.au>
To: Quan Nguyen <quan@os.amperecomputing.com>,
Brendan Higgins <brendan.higgins@linux.dev>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Joel Stanley <joel@jms.id.au>,
Andi Shyti <andi.shyti@kernel.org>, Wolfram Sang <wsa@kernel.org>,
Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>,
Guenter Roeck <linux@roeck-us.net>,
linux-i2c@vger.kernel.org, openbmc@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org
Cc: Cosmo Chou <chou.cosmo@gmail.com>,
Open Source Submission <patches@amperecomputing.com>,
Phong Vo <phong@os.amperecomputing.com>,
"Thang Q . Nguyen" <thang@os.amperecomputing.com>
Subject: Re: [PATCH v2 RESEND 2/2] i2c: aspeed: Acknowledge Tx done with and without ACK irq late
Date: Wed, 29 Nov 2023 11:03:39 +1030 [thread overview]
Message-ID: <2186c3b9ac92f03c68e8a2dd9fda871f80a6d664.camel@codeconstruct.com.au> (raw)
In-Reply-To: <20231128075236.2724038-3-quan@os.amperecomputing.com>
On Tue, 2023-11-28 at 14:52 +0700, Quan Nguyen wrote:
> Commit 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in
> interrupt handler") acknowledges most interrupts early before the slave
> irq handler is executed, except for the "Receive Done Interrupt status"
> which is acknowledged late in the interrupt.
> However, it is observed that the early acknowledgment of "Transmit Done
> Interrupt Status" (with ACK or NACK) often causes the interrupt to be
> raised in READ REQUEST state, resulting in "Unexpected ACK on read
> request." complaint messages.
>
> Assuming that the "Transmit Done" interrupt should only be acknowledged
> once it is truly processed, this commit fixes this issue by acknowledging
> this interrupt for both ACK and NACK cases late in the interrupt handler
> also.
>
> Fixes: 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in interrupt handler")
> Signed-off-by: Quan Nguyen <quan@os.amperecomputing.com>
> ---
> v2:
> + Split to separate series [Joel]
> + Added the Fixes line [Joel]
> + Fixed multiline comment [Joel]
> + Refactor irq clearing code [Joel, Guenter]
> + Revised commit message [Joel]
> + Revised commit message [Quan]
> + About a note to remind why the readl() should immediately follow the
> writel() to fix the race condition when clearing irq status from commit
> c926c87b8e36 ("i2c: aspeed: Avoid i2c interrupt status clear race
> condition"), I think it looks straight forward in this patch and decided
> not to add that note. [Joel]
>
> v1:
> + First introduced in
> https://lore.kernel.org/all/20210519074934.20712-1-quan@os.amperecomputing.com/
> ---
> drivers/i2c/busses/i2c-aspeed.c | 17 +++++++++--------
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
> index 79476b46285b..3231f430e335 100644
> --- a/drivers/i2c/busses/i2c-aspeed.c
> +++ b/drivers/i2c/busses/i2c-aspeed.c
> @@ -611,8 +611,9 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void *dev_id)
>
> spin_lock(&bus->lock);
> irq_received = readl(bus->base + ASPEED_I2C_INTR_STS_REG);
> - /* Ack all interrupts except for Rx done */
> - writel(irq_received & ~ASPEED_I2CD_INTR_RX_DONE,
> + /* Ack all interrupts except for Rx done and Tx done with/without ACK */
I'm not a huge fan of this comment, it just says what the code does. It
would be much better to explain *why* the code does what it does.
I realise describing what the code does was already the gist of the
comment and that you're just updating it to match the change to the
code, but that's my entire problem with it. We'd be better off deleting
it if we're not going to explain why the masking is necessary.
> + writel(irq_received &
> + ~(ASPEED_I2CD_INTR_RX_DONE | ASPEED_I2CD_INTR_TX_ACK | ASPEED_I2CD_INTR_TX_NAK),
> bus->base + ASPEED_I2C_INTR_STS_REG);
> readl(bus->base + ASPEED_I2C_INTR_STS_REG);
> irq_received &= ASPEED_I2CD_INTR_RECV_MASK;
> @@ -657,12 +658,12 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void *dev_id)
> "irq handled != irq. expected 0x%08x, but was 0x%08x\n",
> irq_received, irq_handled);
>
> - /* Ack Rx done */
> - if (irq_received & ASPEED_I2CD_INTR_RX_DONE) {
> - writel(ASPEED_I2CD_INTR_RX_DONE,
> - bus->base + ASPEED_I2C_INTR_STS_REG);
> - readl(bus->base + ASPEED_I2C_INTR_STS_REG);
> - }
> + /* Ack Rx done and Tx done with/without ACK */
> + writel(irq_received &
> + (ASPEED_I2CD_INTR_RX_DONE | ASPEED_I2CD_INTR_TX_ACK | ASPEED_I2CD_INTR_TX_NAK),
> + bus->base + ASPEED_I2C_INTR_STS_REG);
> + readl(bus->base + ASPEED_I2C_INTR_STS_REG);
I'm not sure why the write was conditional, but I'm not sure that
making it unconditional is valid either? Why the change? Why not add
the extra interrupt bits to the condition in addition to the value mask
for the write?
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-11-29 0:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-28 7:52 [PATCH v2 RESEND 0/2] i2c: aspeed: Late ack Tx done irqs and fix unhandled Tx done with NAK Quan Nguyen
2023-11-28 7:52 ` [PATCH v2 RESEND 1/2] i2c: aspeed: Fix " Quan Nguyen
2023-11-29 0:19 ` Andrew Jeffery
2023-11-29 9:03 ` Quan Nguyen
2023-11-30 1:20 ` Andrew Jeffery
2023-11-30 6:52 ` Quan Nguyen
2023-11-29 0:35 ` Andi Shyti
2023-11-29 9:03 ` Quan Nguyen
2023-11-29 21:25 ` Andi Shyti
2023-11-30 6:53 ` Quan Nguyen
2023-11-28 7:52 ` [PATCH v2 RESEND 2/2] i2c: aspeed: Acknowledge Tx done with and without ACK irq late Quan Nguyen
2023-11-29 0:33 ` Andrew Jeffery [this message]
2023-11-29 9:02 ` Quan Nguyen
2023-11-29 22:44 ` Andrew Jeffery
2023-11-30 6:53 ` Quan Nguyen
2023-11-29 0:45 ` Andi Shyti
2023-11-29 9:05 ` Quan Nguyen
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=2186c3b9ac92f03c68e8a2dd9fda871f80a6d664.camel@codeconstruct.com.au \
--to=andrew@codeconstruct.com.au \
--cc=andi.shyti@kernel.org \
--cc=benh@kernel.crashing.org \
--cc=brendan.higgins@linux.dev \
--cc=chou.cosmo@gmail.com \
--cc=jae.hyun.yoo@linux.intel.com \
--cc=joel@jms.id.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=openbmc@lists.ozlabs.org \
--cc=patches@amperecomputing.com \
--cc=phong@os.amperecomputing.com \
--cc=quan@os.amperecomputing.com \
--cc=thang@os.amperecomputing.com \
--cc=wsa@kernel.org \
/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