Re: [PATCH v12 7/7] docs: i2c: i2c-topology: add section about bus speed

From: Peter Rosin

Date: Thu Jul 23 2026 - 07:19:15 EST


Hi!

On 2026-07-19 16:59, Marcus Folkesson wrote:
> Describe what needs to be consideraed and taken into account

considered

> when using different bus speeds for different mux channels.
>
> Signed-off-by: Marcus Folkesson <marcus.folkesson@xxxxxxxxx>
> ---
> Documentation/i2c/i2c-topology.rst | 178 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 178 insertions(+)
>
> diff --git a/Documentation/i2c/i2c-topology.rst b/Documentation/i2c/i2c-topology.rst
> index 48fce0f7491b..1ee0de6dbcb4 100644
> --- a/Documentation/i2c/i2c-topology.rst
> +++ b/Documentation/i2c/i2c-topology.rst
> @@ -367,6 +367,184 @@ When D1 or D2 are accessed, accesses to D3 and D4 are locked out while
> accesses to D5 may interleave. When D3 or D4 are accessed, accesses to
> all other devices are locked out.
>
> +Bus Speed and I2C Multiplexers
> +================================

Too many equal signs.

> +
> +I2C bus multiplexers allow multiple downstream channels to be exposed
> +as separate I2C adapters which also could set their own bus speed.
> +
> +The multiplexer itself cannot change the bus speed as it uses the upstream
> +clock and data lines to communicate with the downstream devices. The speed
> +is therefore changed in the root adapter resulting in that the whole bus is
> +affected.
> +
> +This increases the complexity of the topology and some considerations must
> +be taken into account.
> +
> +Bus speed
> +----------

Too many dashes.

> +
> +Downstream channels of an I2C multiplexer can only operate at the same or
> +lower bus speed as the upstream bus. This is because the upstream bus may
> +have devices that cannot operate at higher speeds and those will be affected
> +by the speed change.
> +
> +The example below illustrates the problem.
> +The root adapter is operating at 100kHz. D2 can only operate with 100kHz,
> +but D1 can operate at 400kHz. When D1 is selected, the bus speed of the
> +root adapter would have to be set to 400kHz, a speed that D2 may not support.

would have been set

> +
> +This topology is therefore not allowed: ::
> +
> + .----------. 400kHz .--------.
> + .--------. 100kHz | mux- |--------| dev D1 |
> + | root |--+-----| locked | '--------'
> + '--------' | | mux M1 |
> + | '----------'
> + | .--------.
> + '--| dev D2 |
> + '--------'
> +
> +
> +This topology is allowed: ::
> +
> + .----------. 100kHz .--------.
> + .--------. 400kHz | mux- |--------| dev D2 |
> + | root |--+-----| locked | '--------'
> + '--------' | mux M1 |--. 400kHz .--------.
> + '----------' '--------| dev D1 |
> + '--------'
> +
> +Preferred topology
> +-------------------

Too many dashes.

> +
> +The preferred topology when using different bus speeds is to have the multiplexer

There are many over-long lines in this patch.

> +connected directly to the root adapter without any devices as siblings.
> +By this arrangement, the bus speed can be changed without affecting any other devices
> +and many of the caveats are avoided.
> +
> +Other multiplexers in parallel are still okay as those are locked out during transfers.
> +
> +This is the preferred topology: ::
> +
> + .----------. 100kHz .--------.
> + .--------. 400kHz | mux- |--------| dev D2 |
> + | root |--+-----| locked | '--------'
> + '--------' | mux M1 |--. 400kHz .--------.
> + '----------' '--------| dev D1 |
> + '--------'
> +
> +Locking
> +--------

Too many dashes.

> +
> +If the multiplexer is mux-locked, transfers to D3 may interleave between the
> +select-transfer-deselect to D1 or D2.
> +This results in a situation where the bus speed to D3 may be lower than it
> +is supposed to be. This is usually not a problem.
> +
> +This topology is allowed but some transfers to D3 may be at 100kHz: ::
> +
> + .----------. 100kHz .--------.
> + .--------. 400kHz | mux- |--------| dev D1 |
> + | root |--+-----| locked | '--------'
> + '--------' | | mux M1 |--. 400kHz .--------.
> + | '----------' '--------| dev D2 |
> + | .--------. '--------'
> + '--| dev D3 |
> + '--------'
> +
> +Multiple muxes in series
> +--------------------------

Too many dashes.

> +
> +When multiple muxes are used in series the same rules apply.
> +
> +Transfers to D3 may interleave between select-transfer-deselect to D1, which
> +results in that the bus speed to D2 or D3 will be at 100KHz.
> +
> +Transfers to D2 may interleave between select-transfer-deselect to D1, which
> +results in that the bus speed to D1 may be at 400kHz as the transfer to D2
> +will set the bus speed to before the transfer to D1 starts.

There is a missing word or something? I suggest this:

Transfers to D2 may interleave between select-transfer-deselect to D1,
which may result in a bus speed to D1 at 400kHz as the transfer to D2 may
clobber the bus speed before the transfer to D1 starts.

> +
> +This is probably a bad topology ::
> +
> + .----------. 400kHz .----------. 100kHz .--------.
> + .--------.400kHz | mux- |--------| mux- |--------| dev D1 |
> + | root |--+----| locked | 400kHz | locked | '--------'
> + '--------' | | mux M1 |--. | mux M2 |
> + | '----------' | '----------'
> + | .--------. | .--------.
> + '--| dev D3 | '--| dev D2 |
> + '--------' '--------'
> +
> +Multiple muxes in parallel
> +----------------------------

Too many dashes.

> +
> +When multiple muxes are used in parallel all access to other muxes are locked out
> +so this is not a problem.
> +
> +If the muxes are mux-locked, access to D3 may still interleave though.
> +
> +In the example below, D3 may not interleave between select-transfer-deselect for D1
> +or D2 as both muxes are parent-locked: ::
> +
> +
> + .----------. 100kHz .--------.
> + | parent- |----------| dev D1 |
> + .--| locked | '--------'
> + | | mux M1 |
> + | '----------'
> + | .----------. 400KHz .--------.
> + .--------. 400kHz | parent- |---------| dev D2 |
> + | root |--+------| locked | '--------'
> + '--------' | | mux M2 |
> + | '----------'
> + | .--------.
> + '--| dev D3 |
> + '--------'
> +
> +Idle state
> +-----------

Too many dashes.

> +
> +Muxes have an idle state, which is the state the channels are put into when no channel
> +is active. The state is typically one of the following:
> +
> +- All channels are disconnected
> +- The last selected channel is left as-is
> +- A predefined channel is selected
> +
> +Muxes that support an idle state where all channels are disconnected are preferred when using
> +different bus speeds. Otherwise high bus speeds may "leak" through to devices that
> +may not support that higher speed.
> +
> +Consider the following example: ::
> +
> + .----------. 100kHz .--------.
> + .--------. 400kHz | mux- |--------| dev D1 |
> + | root |--+-----| locked | '--------'
> + '--------' | | mux M1 |--. 400kHz .--------.
> + | '----------' '--------| dev D2 |
> + | .--------. '--------'
> + '--| dev D3 |
> + '--------'
> +
> +If the idle state of M1 is:
> +
> +- All channels disconnected: No problem, D1 and D2 are not affected by communication
> + to D3.
> +- Last selected channel: Problem if D1 was the last selected channel. High speed
> + communication to D3 will be "leaked" to D1.
> +- Predefined channel: Problem if the predefined channel is D1. Set predefined channel
> + to D2 as D2 may handle 400kHz.
> +
> +Supported controllers
> +-----------------------

Too many dashes.

Cheers,
Peter

> +
> +Not all I2C controllers support setting the bus speed dynamically.
> +At the time of writing, the following controllers have support:
> +
> +============================ =============================================
> +i2c-davinci Supports dynamic bus speed
> +============================ =============================================
>
> Mux type of existing device drivers
> ===================================
>