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: Fri, 8 May 2026 15:14:31 +0200	[thread overview]
Message-ID: <af3ht8OX_VUYVAgg@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>
> ---
> Changes in v9:
> - Fix stray blank line
> - Link to v8: https://lore.kernel.org/r/20260314-i2c-mux-v8-0-fb1738a4df0a@gmail.com
> 
> Changes in v8:
> - Fix gramatics and change %d to %u were appropriate
> - Link to v7: https://lore.kernel.org/r/20260223-i2c-mux-v7-0-ec75b214718a@gmail.com
> 
> Changes in v7:
> - Remove code for finding first mux-locked ancestor
> - Introduce a unlocked (i2c_adapter_set_clk_freq) and unlocked
>   (__i2c_adapter_set_clk_freq) variant
> - Let the locking be handled in __i2c_adapter_set_clk_freq
> - Use I2C_MAX_STANDARD_MODE_FREQ instead of magic numbers where
>   appropriate 
> - Link to v6: https://lore.kernel.org/r/20260216-i2c-mux-v6-0-9be28ecfd7e3@gmail.com
> 
> Changes in v6:
> - Change logic to find which ancestor to lock with I2C_LOCK_ROOT_ADAPTER
>   It now find the first mux-locked ancestor and then lock its parent.
> 
> - Remove bus_freq_hz in i2c-davinci and only use clock_hz instead
> - Mention in commit message that clock_hz can be used to store frequency in an uniform way
> 
> - Swap order for change freq/deselect to keep symmetry
> - Only allow bus frequency to be lowered in select()
>   This to not allow an intermediate frequency to be set when it is not
>   supposed to
> 
> - check if(ret) instead of ret(<0) where appropriate
> - Fix typos in documentation
> - Change i2c_adapter.clock_hz from int to u32
> - Simplify i2c_adapter_set_clk_freq() by removing 'ret'
> - Link to v5: https://lore.kernel.org/r/20260213-i2c-mux-v5-0-fb2cbf9979b3@gmail.com
> 
> Changes in v5:
> - Take the lock of the top-most mutex locked mux to make sure that the
>   root is locked
> - Link to v4: https://lore.kernel.org/r/20260128-i2c-mux-v4-0-dee49ce276c0@gmail.com
> 
> Changes in v4:
> - Rebase on master
> - Swap order for printing warning about "channel %u is slower than
>   parent on a non parent-locked mux\n"
> - Fix typo in comment, adaper->adapter
> - Link to v3: https://lore.kernel.org/r/20251020-i2c-mux-v3-0-908ac5cf9223@gmail.com
> 
> Changes in v3:
> - Return -EINVAL if channel is faster than parent (kernel test robot)
> - Link to v2: https://lore.kernel.org/r/20251002-i2c-mux-v2-0-b698564cd956@gmail.com
> 
> Changes in v2:
> - Changed bus_freq field to bus_freq_hz in davinci_i2c_dev (Bartosz Golaszewski)
> - Removed idle_state from mux core (Peter Rosin)
> - Link to v1: https://lore.kernel.org/r/20250922-i2c-mux-v1-0-28c94a610930@gmail.com
> 
> ---

Friendly ping on this series.

Thanks,

Med vänliga hälsningar / Best regards
Marcus Folkesson


      parent reply	other threads:[~2026-05-08 13:14 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
2026-05-08 13:14 ` 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=af3ht8OX_VUYVAgg@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.