From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Marcus Folkesson <marcus.folkesson@gmail.com>
Cc: 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>,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 2/5] i2c: mux: add support for per channel bus frequency
Date: Fri, 13 Feb 2026 12:21:42 +0100 [thread overview]
Message-ID: <aY8JRikJpM4v5BcM@black.igk.intel.com> (raw)
In-Reply-To: <20260213-i2c-mux-v5-2-fb2cbf9979b3@gmail.com>
On Fri, Feb 13, 2026 at 12:06:51PM +0100, Marcus Folkesson wrote:
> There may be several reasons why you may need to use a certain speed
> on an I2C bus. E.g.
>
> - When several devices are attached to the bus, the speed must be
> selected according to the slowest device.
>
> - Electrical conditions may limit the usuable speed on the bus for
> different reasons.
>
> With an I2C multiplexer, it is possible to group the attached devices
> after their preferred speed by e.g. put all "slow" devices on a separate
> channel on the multiplexer.
>
> Consider the following topology:
>
> .----------. 100kHz .--------.
> .--------. 400kHz | |--------| dev D1 |
> | root |--+-----| I2C MUX | '--------'
> '--------' | | |--. 400kHz .--------.
> | '----------' '-------| dev D2 |
> | .--------. '--------'
> '--| dev D3 |
> '--------'
>
> One requirement with this design is that a multiplexer may only use the
> same or lower bus speed as its parent.
> Otherwise, if the multiplexer would have to increase the bus frequency,
> then all siblings (D3 in this case) would run into a clock speed it may
> not support.
>
> The bus frequency for each channel is set in the devicetree. As the
> i2c-mux bindings import the i2c-controller schema, the clock-frequency
> property is already allowed.
> If no clock-frequency property is set, the channel inherit their parent
> bus speed.
...
> +static int i2c_mux_select_chan(struct i2c_adapter *adap, u32 chan_id)
> +{
> + struct i2c_mux_priv *priv = adap->algo_data;
> + struct i2c_mux_core *muxc = priv->muxc;
> + struct i2c_adapter *parent = muxc->parent;
> + struct i2c_mux_core *mux_locked_ancestor = NULL;
> + struct i2c_adapter *root;
> + int ret;
> +
> + if (priv->adap.clock_hz && priv->adap.clock_hz != parent->clock_hz) {
> + mux_locked_ancestor = i2c_mux_topmost_mux_locked(adap);
> + root = i2c_root_adapter(&adap->dev);
> +
> + /*
> + * If there's a mux-locked mux in our ancestry, lock the parent
> + * of the topmost one. Mux-locked muxes don't propagate locking
> + * to their parents, so we must explicitly acquire the lock above
> + * the highest mux-locked ancestor to reach the root adapter.
> + */
> + if (mux_locked_ancestor)
> + i2c_lock_bus(mux_locked_ancestor->parent, I2C_LOCK_ROOT_ADAPTER);
> +
> + ret = i2c_adapter_set_clk_freq(root, priv->adap.clock_hz);
> +
> + if (mux_locked_ancestor)
> + i2c_unlock_bus(mux_locked_ancestor->parent, I2C_LOCK_ROOT_ADAPTER);
> + if (ret < 0) {
Would it (ever) have any positive returned values?
Ditto for other similar cases.
> + dev_err(&adap->dev,
> + "Failed to set clock frequency %dHz on root adapter %s: %d\n",
> + priv->adap.clock_hz, root->name, ret);
> +
> + return ret;
> + }
> + }
> +
> + return muxc->select(muxc, priv->chan_id);
> +}
...
> @@ -223,6 +317,7 @@ struct i2c_adapter *i2c_root_adapter(struct device *dev)
> }
> EXPORT_SYMBOL_GPL(i2c_root_adapter);
>
> +
> struct i2c_mux_core *i2c_mux_alloc(struct i2c_adapter *parent,
Stray and unneeded change.
> struct device *dev, int max_adapters,
> int sizeof_priv, u32 flags,
...
> + of_property_read_u32(child, "clock-frequency", &priv->adap.clock_hz);
Why OF-centric APIs? Muxes may and do appear on other systems as well.
Okay, this function seems fully OF-centric :-(
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2026-02-13 11:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-13 11:06 [PATCH v5 0/5] I2C Mux per channel bus speed Marcus Folkesson
2026-02-13 11:06 ` [PATCH v5 1/5] i2c: core: add callback to change bus frequency Marcus Folkesson
2026-02-13 11:14 ` Andy Shevchenko
2026-02-16 9:22 ` Marcus Folkesson
2026-02-16 9:31 ` Andy Shevchenko
2026-02-13 11:06 ` [PATCH v5 2/5] i2c: mux: add support for per channel " Marcus Folkesson
2026-02-13 11:21 ` Andy Shevchenko [this message]
2026-02-14 12:30 ` Marcus Folkesson
2026-02-14 18:32 ` Andy Shevchenko
2026-02-13 11:48 ` Peter Rosin
2026-02-13 16:05 ` Marcus Folkesson
2026-02-13 16:35 ` Peter Rosin
2026-02-13 11:06 ` [PATCH v5 3/5] i2c: davinci: calculate bus freq from Hz instead of kHz Marcus Folkesson
2026-02-13 11:06 ` [PATCH v5 4/5] i2c: davinci: add support for setting bus frequency Marcus Folkesson
2026-02-13 11:06 ` [PATCH v5 5/5] docs: i2c: i2c-topology: add section about bus speed Marcus Folkesson
2026-02-13 16:07 ` kernel test robot
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=aY8JRikJpM4v5BcM@black.igk.intel.com \
--to=andriy.shevchenko@intel.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=marcus.folkesson@gmail.com \
--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.