From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Cc: linux-renesas-soc@vger.kernel.org, linux-i2c@vger.kernel.org,
linux-kernel@vger.kernel.org,
Geert Uytterhoeven <geert+renesas@glider.be>,
Bhuvanesh Surachari <bhuvanesh_surachari@mentor.com>
Subject: Re: [PATCH v2] i2c: rcar: add SMBus block read support
Date: Thu, 17 Feb 2022 20:44:51 +0100 [thread overview]
Message-ID: <Yg6ls0zyTDe7LQbK@kunai> (raw)
In-Reply-To: <20211006182314.10585-1-andrew_gabbasov@mentor.com>
[-- Attachment #1: Type: text/plain, Size: 2999 bytes --]
Hi Andrew,
first sorry that it took so long. The reason here is that my original
plan was to add 256-byte support to RECV_LEN in the I2C core and enable
it on R-Car afterwards. Sadly, I never found the time to drive this
forward. So, all RECV_LEN things got stuck for a while :(
> This patch (adapted) was tested with v4.14, but due to lack of real
> hardware with SMBus block read operations support, using "simulation",
> that is manual analysis of data, read from plain I2C devices with
> SMBus block read request.
You could wire up two R-Car I2C instances, set up one as an I2C slave
handled by the I2C testunit and then use the other instance with
SMBUS_BLOCK_PROC_CALL which also needs RECV_LEN. Check
Documentation/i2c/slave-testunit-backend.rst for details.
I wonder a bit about the complexity of your patch. In my WIP-branch for
256-byte transfers, I have the following patch. It is only missing the
range check for the received byte, but that it easy to add. Do you see
anything else missing? If not, I prefer this simpler version because it
is less intrusive and the state machine is a bit fragile (due to HW
issues with old HW).
From: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date: Sun, 2 Aug 2020 00:24:52 +0200
Subject: [PATCH] i2c: rcar: add support for I2C_M_RECV_LEN
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
drivers/i2c/busses/i2c-rcar.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 217def2d7cb4..e473f5c0a708 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -528,6 +528,7 @@ static void rcar_i2c_irq_send(struct rcar_i2c_priv *priv, u32 msr)
static void rcar_i2c_irq_recv(struct rcar_i2c_priv *priv, u32 msr)
{
struct i2c_msg *msg = priv->msg;
+ bool recv_len_init = priv->pos == 0 && msg->flags & I2C_M_RECV_LEN;
/* FIXME: sometimes, unknown interrupt happened. Do nothing */
if (!(msr & MDR))
@@ -542,11 +543,13 @@ static void rcar_i2c_irq_recv(struct rcar_i2c_priv *priv, u32 msr)
} else if (priv->pos < msg->len) {
/* get received data */
msg->buf[priv->pos] = rcar_i2c_read(priv, ICRXTX);
+ if (recv_len_init)
+ msg->len += msg->buf[0];
priv->pos++;
}
/* If next received data is the _LAST_, go to new phase. */
- if (priv->pos + 1 == msg->len) {
+ if (priv->pos + 1 == msg->len && !recv_len_init) {
if (priv->flags & ID_LAST_MSG) {
rcar_i2c_write(priv, ICMCR, RCAR_BUS_PHASE_STOP);
} else {
@@ -889,7 +892,7 @@ static u32 rcar_i2c_func(struct i2c_adapter *adap)
* I2C_M_IGNORE_NAK (automatically sends STOP after NAK)
*/
u32 func = I2C_FUNC_I2C | I2C_FUNC_SLAVE |
- (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK);
+ (I2C_FUNC_SMBUS_EMUL_ALL & ~I2C_FUNC_SMBUS_QUICK);
if (priv->flags & ID_P_HOST_NOTIFY)
func |= I2C_FUNC_SMBUS_HOST_NOTIFY;
Happy hacking,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-02-17 19:51 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-22 16:06 [PATCH] i2c: rcar: add SMBus block read support Andrew Gabbasov
2021-10-05 13:31 ` Geert Uytterhoeven
2021-10-06 18:11 ` Andrew Gabbasov
2021-10-06 18:23 ` [PATCH v2] " Andrew Gabbasov
2022-02-17 19:44 ` Wolfram Sang [this message]
2022-02-18 11:02 ` Gabbasov, Andrew
2022-03-15 10:45 ` Surachari, Bhuvanesh
2022-03-30 11:04 ` Wolfram Sang
2022-04-01 16:27 ` Wolfram Sang
2022-04-01 16:29 ` Wolfram Sang
2022-03-23 21:52 ` Eugeniu Rosca
2022-03-30 10:58 ` Wolfram Sang
2022-03-30 11:09 ` Wolfram Sang
2022-03-31 16:02 ` Eugeniu Rosca
2022-04-01 16:38 ` Wolfram Sang
2022-04-05 9:30 ` Eugeniu Rosca
2022-04-05 9:43 ` Wolfram Sang
2022-04-06 17:32 ` Eugeniu Rosca
2022-04-06 19:44 ` Wolfram Sang
2021-11-18 10:35 ` [PATCH] " Andrew Gabbasov
2022-01-09 19:20 ` Andrew Gabbasov
2022-01-25 6:45 ` Andrew Gabbasov
2022-02-17 14:40 ` Andrew Gabbasov
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=Yg6ls0zyTDe7LQbK@kunai \
--to=wsa+renesas@sang-engineering.com \
--cc=andrew_gabbasov@mentor.com \
--cc=bhuvanesh_surachari@mentor.com \
--cc=geert+renesas@glider.be \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.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;
as well as URLs for NNTP newsgroup(s).