From: warp5tw@gmail.com
To: avifishman70@gmail.com, tmaimon77@gmail.com,
tali.perry1@gmail.com, venture@google.com, yuenn@google.com,
benjaminfair@google.com, andi.shyti@kernel.org,
andriy.shevchenko@linux.intel.com, wsa@kernel.org,
rand.sec96@gmail.com, wsa+renesas@sang-engineering.com,
warp5tw@gmail.com, tali.perry@nuvoton.com,
Avi.Fishman@nuvoton.com, tomer.maimon@nuvoton.com,
KWLIU@nuvoton.com, JJLIU0@nuvoton.com, kfting@nuvoton.com
Cc: openbmc@lists.ozlabs.org, linux-i2c@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH v4 1/6] i2c: npcm: correct the read/write operation procedure
Date: Fri, 20 Sep 2024 18:18:15 +0800 [thread overview]
Message-ID: <20240920101820.44850-2-kfting@nuvoton.com> (raw)
In-Reply-To: <20240920101820.44850-1-kfting@nuvoton.com>
From: Tyrone Ting <kfting@nuvoton.com>
From: Tyrone Ting <kfting@nuvoton.com>
Originally the driver uses the XMIT bit in SMBnST register to decide
the upcoming i2c transaction. If XMIT bit is 1, then it will be an i2c
write operation. If it's 0, then a read operation will be executed.
In slave mode the XMIT bit can simply be used directly to set the state.
XMIT bit can be used as an indication to the current state of the state
machine during slave operation. (meaning XMIT = 1 during writing and
XMIT = 0 during reading).
In master operation XMIT is valid only if there are no bus errors.
For example: in a multi master where the same module is switching from
master to slave at runtime, and there are collisions, the XMIT bit
cannot be trusted.
However the maser already "knows" what the bus state is, so this bit
is not needed and the driver can just track what it is currently doing.
Signed-off-by: Tyrone Ting <kfting@nuvoton.com>
Reviewed-by: Tali Perry <tali.perry1@gmail.com>
---
drivers/i2c/busses/i2c-npcm7xx.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-npcm7xx.c b/drivers/i2c/busses/i2c-npcm7xx.c
index bbcb4d6668ce..2b76dbfba438 100644
--- a/drivers/i2c/busses/i2c-npcm7xx.c
+++ b/drivers/i2c/busses/i2c-npcm7xx.c
@@ -1628,13 +1628,10 @@ static void npcm_i2c_irq_handle_sda(struct npcm_i2c *bus, u8 i2cst)
npcm_i2c_wr_byte(bus, bus->dest_addr | BIT(0));
/* SDA interrupt, after start\restart */
} else {
- if (NPCM_I2CST_XMIT & i2cst) {
- bus->operation = I2C_WRITE_OPER;
+ if (bus->operation == I2C_WRITE_OPER)
npcm_i2c_irq_master_handler_write(bus);
- } else {
- bus->operation = I2C_READ_OPER;
+ else if (bus->operation == I2C_READ_OPER)
npcm_i2c_irq_master_handler_read(bus);
- }
}
}
--
2.34.1
next prev parent reply other threads:[~2024-09-20 10:18 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-20 10:18 [PATCH v4 0/6] i2c: npcm: read/write operation, checkpatch warp5tw
2024-09-20 10:18 ` warp5tw [this message]
2024-09-20 14:30 ` [PATCH v4 1/6] i2c: npcm: correct the read/write operation procedure Andy Shevchenko
2024-09-23 1:51 ` Tyrone Ting
2024-09-25 20:19 ` Andi Shyti
2024-09-27 1:59 ` Tyrone Ting
2024-09-20 10:18 ` [PATCH v4 2/6] i2c: npcm: use a software flag to indicate a BER condition warp5tw
2024-09-25 20:22 ` Andi Shyti
2024-09-27 2:01 ` Tyrone Ting
2024-09-20 10:18 ` [PATCH v4 3/6] i2c: npcm: Modify timeout evaluation mechanism warp5tw
2024-09-25 20:24 ` Andi Shyti
2024-09-27 2:03 ` Tyrone Ting
2024-09-20 10:18 ` [PATCH v4 4/6] i2c: npcm: Modify the client address assignment warp5tw
2024-09-20 14:32 ` Andy Shevchenko
2024-09-23 1:59 ` Tyrone Ting
2024-09-23 8:25 ` Andy Shevchenko
2024-09-20 10:18 ` [PATCH v4 5/6] i2c: npcm: use i2c frequency table warp5tw
2024-09-20 10:18 ` [PATCH v4 6/6] i2c: npcm: Enable slave in eob interrupt warp5tw
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=20240920101820.44850-2-kfting@nuvoton.com \
--to=warp5tw@gmail.com \
--cc=Avi.Fishman@nuvoton.com \
--cc=JJLIU0@nuvoton.com \
--cc=KWLIU@nuvoton.com \
--cc=andi.shyti@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=avifishman70@gmail.com \
--cc=benjaminfair@google.com \
--cc=kfting@nuvoton.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=openbmc@lists.ozlabs.org \
--cc=rand.sec96@gmail.com \
--cc=tali.perry1@gmail.com \
--cc=tali.perry@nuvoton.com \
--cc=tmaimon77@gmail.com \
--cc=tomer.maimon@nuvoton.com \
--cc=venture@google.com \
--cc=wsa+renesas@sang-engineering.com \
--cc=wsa@kernel.org \
--cc=yuenn@google.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