From: Francesco Lavra <flavra@baylibre.com>
To: Andi Shyti <andi.shyti@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org
Subject: Re: [PATCH v2] i2c: Add FTDI FT4222H USB I2C adapter
Date: Tue, 27 Jan 2026 19:33:18 +0100 [thread overview]
Message-ID: <d821fb9296bb0084d7e1b7c9a600263084ee6012.camel@baylibre.com> (raw)
In-Reply-To: <aXH1fEkQWnekwSui@zenone.zhora.eu>
Hi Andi,
On Thu, 2026-01-22 at 11:37 +0100, Andi Shyti wrote:
> Hi Francesco,
>
> ...
>
> > +static int ft4222_i2c_get_status(struct ft4222_i2c *ftdi)
> > +{
> > + /*
> > + * Multiple retries are needed mostly when retrieving the
> > controller
> > + * status after doing a write with the I2C bus operating at a
> > low speed.
> > + * Empirical tests conducted at 100 kHz showed that after a
> > + * maximum-sized (512-byte) write, up to 11 retries are needed
> > before
> > + * the chip clears its CTRL_BUSY flag. But under certain
> > conditions more
> > + * retries may be needed: for example, when trying to do a
> > write after
> > + * disconnecting the SCL line from the I2C slave, tests showed
> > that up
> > + * to 64 retries are needed.
> > + */
> > + const int max_retries = 70;
> > + int retry;
> > + u8 status;
> > +
> > + for (retry = 0; retry < max_retries; retry++) {
> > + int ret = ft4222_cmd_get(ftdi, FT4222_CMD_I2C_STATUS,
> > &status);
> > +
> > + if (ret < 0)
> > + return ret;
> > + if (!(status & FT4222_I2C_CTRL_BUSY))
> > + break;
>
> How about adding a small delay here. Does it also help to reduce
> the maximum number of retries?
Yes, I tried adding a call to msleep(10) here, and with that delay I have
never seen the retry variable higher than 4 at the end of the loop.
So I will add msleep(10), and change the max_retries constant to something
like 5.
> > + }
>
> ...
>
> > + dev_dbg(&adapter->dev, "transfer with %d message(s)", num);
> > + for (i = 0; i < num; ++i) {
> > + const u8 addr = msg[i].addr;
> > + const u16 len = msg[i].len;
> > + u8 *buf = msg[i].buf;
> > + u8 flags;
> > +
> > + flags = ((i == 0) ? FT4222_FLAG_START :
> > FT4222_FLAG_RESTART);
> > + if (i == num - 1)
> > + flags |= FT4222_FLAG_STOP;
>
> Are we setting here both STOP and RESTART at the same time.
Yes, for each I2C message the driver must set the correct flags in order
for the adapter to create the appropriate I2C bus conditions.
So for example in a single-message transfer, we set (FT4222_FLAG_START |
FT4222_FLAG_STOP); in a 2-message transfer, we set (FT4222_FLAG_START) for
the first message and (FT4222_FLAG_RESTART | FT4222_FLAG_STOP) for the
second message.
> The rest looks good to me.
prev parent reply other threads:[~2026-01-27 18:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-16 10:18 Francesco Lavra
2026-01-22 10:37 ` Andi Shyti
2026-01-27 18:33 ` Francesco Lavra [this message]
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=d821fb9296bb0084d7e1b7c9a600263084ee6012.camel@baylibre.com \
--to=flavra@baylibre.com \
--cc=andi.shyti@kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@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
all inboxes | Powered by JetHome®