From: Wolfram Sang <wsa@kernel.org>
To: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
Cc: "linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
"devicetree-spec@vger.kernel.org"
<devicetree-spec@vger.kernel.org>,
Andi Shyti <andi.shyti@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Subject: Re: dtschema: i2c: messy situation about timeouts
Date: Mon, 26 Feb 2024 22:24:53 +0100 [thread overview]
Message-ID: <Zd0Bpa2ciMHmSQrS@shikoro> (raw)
In-Reply-To: <ccb58633-5981-4b91-a6ca-a57ea1ce5e40@alliedtelesis.co.nz>
[-- Attachment #1: Type: text/plain, Size: 1955 bytes --]
Hi Chris,
> > - "i2c-scl-has-clk-low-timeout"
> >
> > AFAIU this binding tells that the controller can do clock stretching.
> > But what for? I don't see why this is important for clients. If
> > anything, then it would be interesting if the *client* can do clock
> > stretching and if the controller can actually handle that. But no need
> > to describe it in DT, we have this as an adapter quirk already
> > 'I2C_AQ_NO_CLK_STRETCH'.
>
> Hmm I know of a few adapters that should probably set
> I2C_AQ_NO_CLK_STRETCH based on some Errata. Probably just a
That would be helpful if you could add that. I always guessed there
should be more controllers needing the flag but never encountered them
personally.
> documentation exercise. It would be nice to reject clients that need to
> do clock stretching but often it happens as a side effect rather than
> being intentional (I've seen this with i2c clients implemented in
> microcontrollers).
I guess the way forward with that is we add a flag like
I2C_CLIENT_CLK_STRETCH and let the core figure out if controller and
client are compatible. Dunno what to do if not, though. Reject? Throw a
warning that there might be problems? Probably reject by default unless
overridden by something-meaning-i-know-the-risks.
> > Suggestion: let's remove this binding and conver i2c-mpc to
> > "i2c-transfer-timeout-us". Yes, not nice to have two deprecated
> > bindings, but things happened.
>
> Sounds like a good idea. We'd obviously need to keep support for the
> existing property but it wouldn't be hard to add
> "i2c-transfer-timeout-us". I'll try to whip up a patch for that sometime
> this week, just need to dust off my Freescale boards.
Please wait a little with the implementation. I want to try Rob's idea
to let the core set the timeout flag initially. Dusting off the boards
for testing would be awesome, though :)
Happy hacking,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-02-26 21:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-26 10:08 dtschema: i2c: messy situation about timeouts Wolfram Sang
2024-02-26 14:45 ` Rob Herring
2024-02-26 21:16 ` Wolfram Sang
2024-02-26 20:20 ` Chris Packham
2024-02-26 21:24 ` Wolfram Sang [this message]
2024-02-27 0:03 ` Andi Shyti
2024-02-27 7:12 ` Wolfram Sang
2024-02-27 12:57 ` Wolfram Sang
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=Zd0Bpa2ciMHmSQrS@shikoro \
--to=wsa@kernel.org \
--cc=Chris.Packham@alliedtelesis.co.nz \
--cc=andi.shyti@kernel.org \
--cc=devicetree-spec@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-i2c@vger.kernel.org \
--cc=robh+dt@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.