From: Aniket RANDIVE <aniket.randive@oss.qualcomm.com>
To: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com>,
Andi Shyti <andi.shyti@kernel.org>,
Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v6 0/2] i2c: Add dynamic transfer timeout based on message length and frequency
Date: Fri, 24 Jul 2026 17:26:06 +0530 [thread overview]
Message-ID: <23edc4b0-c5cc-4c54-91ed-a7bea945e680@oss.qualcomm.com> (raw)
In-Reply-To: <e1e38c71-5f79-406e-821c-ce37904102ba@oss.qualcomm.com>
On 7/22/2026 10:55 AM, Mukesh Savaliya wrote:
>
>
> On 7/20/2026 5:11 PM, Aniket Randive wrote:
>> The I2C core and most controller drivers use a static 1-second timeout
>> for all transfers regardless of message length or bus frequency. This
>> causes unnecessarily long delays on error paths for short transfers, and
>> may be tight for very long transfers at low bus frequencies.
>>
> OR can be more than 1 sec for big transfer at low frequency. Hence
> better to make it generic saying depends on data length and frequency
> which you have mentioned. So limit it that.
>> This series introduces a generic helper in i2c-core that computes a
> generic helper function
I will update the comment.
Thanks,
Aniket
>> transfer-specific timeout and stores it in the standard adap->timeout
>> field, making the dynamic value visible to the core retry loop in
>> __i2c_transfer() as well as to the driver's own wait sites.
>>
>> The helper accepts a safety coefficient and a minimum floor as parameters
> what's the policy to accept ? i think should explain here.
> read from dtsi or hard coded ?
Agreed.
The policy is still being discussed (hard-coded vs driver-supplied vs DT
based values). Once we converge on an approach with the other reviewers
and maintainers, I'll update the commit message to reflect the final
decision and rationale.
Thanks,
Aniket
>> so each driver retains control over its own timing policy without those
>> values becoming public API.
>>
>> The second patch converts the Qualcomm GENI I2C controller to use this
>> helper. The 10x safety margin over the theoretical wire time and the
>> 300ms minimum floor (to budget for clock stretching) remain private to
>> the qcom-geni driver.
> geni i2c driver
I will update the comment.
Thanks,
Aniket
>>
>> Changes in v6:
>> - Split into two patches: core helper + driver consumer
>> - Moved timeout calculation to i2c-core as i2c_update_timeout(), which
>> writes directly into adap->timeout so all consumers of that field
>> (including the __i2c_transfer() retry loop) benefit automatically
> please Add suggested-by: dmitry guzman < >
> Also add reviewer into to/cc list specifically.
I will add the tag in next patch.
Thanks,
Aniket
>> - Driver supplies safety coefficient and minimum floor as parameters,
>> keeping I2C_TIMEOUT_SAFETY_COEFFICIENT and I2C_TIMEOUT_MIN_USEC
>> internal to i2c-qcom-geni.c
>> - Compute timeout once per batch in geni_i2c_xfer() using max message
>> length, all internal wait sites read adap->timeout directly
>>
>> Link: https://lore.kernel.org/r/20260715101805.3615166-1-
>> aniket.randive@oss.qualcomm.com
>>
>> Signed-off-by: Aniket Randive <aniket.randive@oss.qualcomm.com>
>> ---
>
> [...]
>>
>
prev parent reply other threads:[~2026-07-24 11:56 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 11:41 Aniket Randive
2026-07-20 11:41 ` [PATCH v6 1/2] i2c: core: Add i2c_update_timeout() helper for dynamic transfer timeouts Aniket Randive
2026-07-22 5:25 ` Mukesh Savaliya
2026-07-24 11:46 ` Aniket RANDIVE
2026-07-26 20:11 ` Andi Shyti
2026-07-27 4:15 ` Mukesh Savaliya
2026-07-27 20:42 ` Andi Shyti
2026-07-28 4:56 ` Mukesh Savaliya
2026-07-28 9:42 ` Wolfram Sang
2026-07-28 10:14 ` Mukesh Savaliya
2026-07-29 15:19 ` Wolfram Sang
2026-07-30 11:53 ` Aniket RANDIVE
2026-07-30 20:23 ` Wolfram Sang
2026-08-01 21:02 ` Wolfram Sang
2026-08-03 10:53 ` Aniket RANDIVE
2026-08-03 11:52 ` Mukesh Savaliya
2026-07-20 11:41 ` [PATCH v6 2/2] i2c: qcom-geni: Add dynamic transfer timeout based on transfer length and frequency Aniket Randive
2026-07-22 5:26 ` Mukesh Savaliya
2026-07-24 11:51 ` Aniket RANDIVE
2026-07-22 5:25 ` [PATCH v6 0/2] i2c: Add dynamic transfer timeout based on message " Mukesh Savaliya
2026-07-24 11:56 ` Aniket RANDIVE [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=23edc4b0-c5cc-4c54-91ed-a7bea945e680@oss.qualcomm.com \
--to=aniket.randive@oss.qualcomm.com \
--cc=andi.shyti@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mukesh.savaliya@oss.qualcomm.com \
--cc=viken.dadhaniya@oss.qualcomm.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
all inboxes | Powered by JetHome®