From: Marcus Folkesson <marcus.folkesson@gmail.com>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>,
Peter Rosin <peda@axentia.se>,
Michael Hennerich <michael.hennerich@analog.com>,
Bartosz Golaszewski <brgl@bgdev.pl>,
Andi Shyti <andi.shyti@kernel.org>,
Bartosz Golaszewski <brgl@kernel.org>
Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 0/5] I2C Mux per channel bus speed
Date: Thu, 12 Feb 2026 14:49:34 +0100 [thread overview]
Message-ID: <aY3aboaHYNPbXIbr@gmail.com> (raw)
In-Reply-To: <20260128-i2c-mux-v4-0-dee49ce276c0@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]
On Wed, Jan 28, 2026 at 10:54:26AM +0100, Marcus Folkesson wrote:
> This was a RFC on how to implement a feature to have different bus
> speeds on different channels with an I2C multiplexer/switch.
> As no major complaints on the design came up during the review, I
> decided to submit the series without the RFC tag.
>
> The benefit with this feature is that you may group devices after
> the fastest bus speed they can handle.
> A real-world example is that you could have e.g. a display running @400kHz
> and a smart battery running @100kHz using the same I2C controller.
>
> There are many corner cases where this may cause a problem for some
> hardware topologies. I've tried to describe those I could think of
> in the documentation, see Patch #5.
>
> E.g. one risk is that if the mux driver does not disconnect channels
> when Idle, this may cause a higher frequency to "leak" through to
> devices that are supposed to run at lower bus speed.
> This is not only a "problem" for changing bus speed but could also be
> an issue for potential address conflicts.
>
> This patchset has been used and tested heavily the last months
> on a custom board based on a da850 (DaVinci) platform.
>
> The implementation is split up into several patches:
>
> Patch #1 Introduce a callback for the i2c controller to set bus speed
> Patch #2 Introduce functionality to adjust bus speed depending on mux
> channel.
> Patch #3 Cleanup i2c-davinci driver a bit to prepare it for set_clk_freq
> Parch #4 Implement set_clk_freq for the i2c-davinci driver
> Parch #5 Update documentation with this feature
>
> Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Hi all,
A friently reminder to everyone out there who might be able to review this
patchset.
The patches has been tested and used for a long time on a custom board,
so I feel quite confident with the implementation.
It also should not affect existing code that not make use of the new
feature.
But it needs reviews.
Thank you in advance
Best regards,
Marcus Folkesson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2026-02-12 13:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-28 9:54 [PATCH v4 0/5] I2C Mux per channel bus speed Marcus Folkesson
2026-01-28 9:54 ` [PATCH v4 1/5] i2c: core: add callback to change bus frequency Marcus Folkesson
2026-01-28 9:54 ` [PATCH v4 2/5] i2c: mux: add support for per channel " Marcus Folkesson
2026-02-12 15:02 ` Peter Rosin
2026-02-12 21:47 ` Marcus Folkesson
2026-02-13 10:59 ` Marcus Folkesson
2026-02-13 11:37 ` Peter Rosin
2026-02-13 15:53 ` Marcus Folkesson
2026-01-28 9:54 ` [PATCH v4 3/5] i2c: davinci: calculate bus freq from Hz instead of kHz Marcus Folkesson
2026-01-28 9:54 ` [PATCH v4 4/5] i2c: davinci: add support for setting bus frequency Marcus Folkesson
2026-01-28 9:54 ` [PATCH v4 5/5] docs: i2c: i2c-topology: add section about bus speed Marcus Folkesson
2026-02-12 13:49 ` Marcus Folkesson [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=aY3aboaHYNPbXIbr@gmail.com \
--to=marcus.folkesson@gmail.com \
--cc=andi.shyti@kernel.org \
--cc=brgl@bgdev.pl \
--cc=brgl@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.hennerich@analog.com \
--cc=peda@axentia.se \
--cc=wsa+renesas@sang-engineering.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