All of lore.kernel.org
 help / color / mirror / Atom feed
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>,
	Andy Shevchenko <andriy.shevchenko@intel.com>,
	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 v9 0/5] I2C Mux per channel bus speed
Date: Mon, 13 Apr 2026 09:45:31 +0200	[thread overview]
Message-ID: <adyfG1jckNp3Sv2_@gmail.com> (raw)
In-Reply-To: <20260324-i2c-mux-v9-0-5292b0608243@gmail.com>

On Tue, Mar 24, 2026 at 02:54:14PM +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>
> ---

Any more feedback on this patchset is very welcome.

Thank you in advance,
Marcus


  parent reply	other threads:[~2026-04-13  7:45 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-24 13:54 [PATCH v9 0/5] I2C Mux per channel bus speed Marcus Folkesson
2026-03-24 13:54 ` [PATCH v9 1/5] i2c: core: add callback to change bus frequency Marcus Folkesson
2026-05-26 19:47   ` Wolfram Sang
2026-05-31 10:18     ` Marcus Folkesson
2026-03-24 13:54 ` [PATCH v9 2/5] i2c: mux: add support for per channel " Marcus Folkesson
2026-03-24 14:10   ` Andy Shevchenko
2026-03-26 11:39     ` Marcus Folkesson
2026-03-24 13:54 ` [PATCH v9 3/5] i2c: davinci: calculate bus freq from Hz instead of kHz Marcus Folkesson
2026-03-24 13:54 ` [PATCH v9 4/5] i2c: davinci: add support for setting bus frequency Marcus Folkesson
2026-03-24 13:54 ` [PATCH v9 5/5] docs: i2c: i2c-topology: add section about bus speed Marcus Folkesson
2026-05-26 19:48   ` Wolfram Sang
2026-05-30  6:54     ` Peter Rosin
2026-05-30  9:17       ` Wolfram Sang
2026-05-31 10:51         ` Marcus Folkesson
2026-05-31 10:42       ` Marcus Folkesson
2026-05-31 10:25     ` Marcus Folkesson
2026-03-26 12:17 ` [PATCH v9 0/5] I2C Mux per channel " Marcus Folkesson
2026-04-13  7:45 ` Marcus Folkesson [this message]
2026-05-08 13:14 ` Marcus Folkesson

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=adyfG1jckNp3Sv2_@gmail.com \
    --to=marcus.folkesson@gmail.com \
    --cc=andi.shyti@kernel.org \
    --cc=andriy.shevchenko@intel.com \
    --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 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.