Describe what needs to be consideraed and taken into account
when using different bus speeds for different mux channels.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
---
Documentation/i2c/i2c-topology.rst | 176 +++++++++++++++++++++++++++++++++++++
1 file changed, 176 insertions(+)
diff --git a/Documentation/i2c/i2c-topology.rst b/Documentation/i2c/i2c-topology.rst
index 48fce0f7491b..2c4a1364ce82 100644
--- a/Documentation/i2c/i2c-topology.rst
+++ b/Documentation/i2c/i2c-topology.rst
@@ -367,6 +367,182 @@ 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
+================================
+
+I2C bus multiplexers allows 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 use the upstream
+clock and data lines to communicate with the downstream devices. The speed
+is therfor 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.
+
+Bus speed
+----------
+
+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 D2 can operate at 400kHz. When D1 is selected, the bus speed of the
+root adapter would have to be is set to 400kHz, a speed that D2 may not support.
+
+This topology is therefor 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
+-------------------
+
+The preferred topology when using different bus speeds is to have the multiplexer
+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 parallell is 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
+--------
+
+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
+--------------------------
+
+When multiple muxes are used in series the same rules applies.
+
+Transfers to D3 may interleave between select-transfer-deselect to D1, which
+results 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.
+
+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 parallell
+----------------------------
+
+When multiple muxes are used in parallell 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
+-----------
+
+Muxes have an idle state, which is the state the channels is 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 D1. Set predefined channel
+ to D2 as D2 may handle 400kHz.
+
+Supported controllers
+-----------------------
+
+Not all I2C controllers support setting the bus speed dynamically.
+At the time of writint, the following controllers has support:
+
+============================ =============================================
+i2c-davinci Supports dynamic bus speed
+============================ =============================================
Mux type of existing device drivers
===================================
--
2.52.0Hi Marcus, kernel test robot noticed the following build warnings: [auto build test WARNING on 1f97d9dcf53649c41c33227b345a36902cbb08ad] url: https://github.com/intel-lab-lkp/linux/commits/Marcus-Folkesson/i2c-core-add-callback-to-change-bus-frequency/20260213-191801 base: 1f97d9dcf53649c41c33227b345a36902cbb08ad patch link: https://lore.kernel.org/r/20260213-i2c-mux-v5-5-fb2cbf9979b3%40gmail.com patch subject: [PATCH v5 5/5] docs: i2c: i2c-topology: add section about bus speed compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261) docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux) reproduce: (https://download.01.org/0day-ci/archive/20260213/202602131725.COjgPVue-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202602131725.COjgPVue-lkp@intel.com/ All warnings (new ones prefixed by >>): The parent of level 2 sections cannot be reached. The parser is at section level 2 but the current node has only 0 parent section(s). One reason may be a high level section used in a directive that parses its content into a base node not attached to the document (up to Docutils 0.21, these sections were silently dropped). [docutils] >> Documentation/i2c/i2c-topology.rst:436: WARNING: Literal block ends without a blank line; unexpected unindent. [docutils] Documentation/i2c/i2c-topology.rst:531: ERROR: Unexpected indentation. [docutils] >> Documentation/i2c/i2c-topology.rst:532: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils] vim +436 Documentation/i2c/i2c-topology.rst 429 430 .----------. 100kHz .--------. 431 .--------. 400kHz | mux- |--------| dev D2 | 432 | root |--+-----| locked | '--------' 433 '--------' | mux M1 |--. 400kHz .--------. 434 '----------' '--------| dev D1 | 435 '--------' > 436 Locking 437 -------- 438 439 If the multiplexer is mux-locked, transfers to D3 may interleave between the 440 select-transfer-deselect to D1 or D2. 441 This results in a situation where the bus speed to D3 may be lower than it 442 is supposed to be. This is usually not a problem. 443 444 This topology is allowed but some transfers to D3 may be at 100kHz: :: 445 446 .----------. 100kHz .--------. 447 .--------. 400kHz | mux- |--------| dev D1 | 448 | root |--+-----| locked | '--------' 449 '--------' | | mux M1 |--. 400kHz .--------. 450 | '----------' '--------| dev D2 | 451 | .--------. '--------' 452 '--| dev D3 | 453 '--------' 454 455 Multiple muxes in series 456 -------------------------- 457 458 When multiple muxes are used in series the same rules applies. 459 460 Transfers to D3 may interleave between select-transfer-deselect to D1, which 461 results that the bus speed to D2 or D3 will be at 100KHz. 462 463 Transfers to D2 may interleave between select-transfer-deselect to D1, which 464 results in that the bus speed to D1 may be at 400kHz as the transfer to D2 465 will set the bus speed to before the transfer to D1 starts. 466 467 This is probably a bad topology :: 468 469 .----------. 400kHz .----------. 100kHz .--------. 470 .--------.400kHz | mux- |--------| mux- |--------| dev D1 | 471 | root |--+----| locked | 400kHz | locked | '--------' 472 '--------' | | mux M1 |--. | mux M2 | 473 | '----------' | '----------' 474 | .--------. | .--------. 475 '--| dev D3 | '--| dev D2 | 476 '--------' '--------' 477 478 Multiple muxes in parallell 479 ---------------------------- 480 481 When multiple muxes are used in parallell all access to other muxes are locked out 482 so this is not a problem. 483 484 If the muxes are mux-locked, access to D3 may still interleave though. 485 486 In the example below, D3 may not interleave between select-transfer-deselect for D1 487 or D2 as both muxes are parent-locked: :: 488 489 490 .----------. 100kHz .--------. 491 | parent- |----------| dev D1 | 492 .--| locked | '--------' 493 | | mux M1 | 494 | '----------' 495 | .----------. 400KHz .--------. 496 .--------. 400kHz | parent- |---------| dev D2 | 497 | root |--+------| locked | '--------' 498 '--------' | | mux M2 | 499 | '----------' 500 | .--------. 501 '--| dev D3 | 502 '--------' 503 504 Idle state 505 ----------- 506 507 Muxes have an idle state, which is the state the channels is put into when no channel 508 is active. The state is typically one of the following: 509 510 - All channels are disconnected 511 - The last selected channel is left as-is 512 - A predefined channel is selected 513 514 Muxes that support an idle state where all channels are disconnected are preferred when using 515 different bus speeds. Otherwise high bus speeds may "leak" through to devices that 516 may not support that higher speed. 517 518 Consider the following example: :: 519 520 .----------. 100kHz .--------. 521 .--------. 400kHz | mux- |--------| dev D1 | 522 | root |--+-----| locked | '--------' 523 '--------' | | mux M1 |--. 400kHz .--------. 524 | '----------' '--------| dev D2 | 525 | .--------. '--------' 526 '--| dev D3 | 527 '--------' 528 529 If the idle state of M1 is: 530 - All channels disconnected: No problem, D1 and D2 are not affected by communication 531 to D3. > 532 - Last selected channel: Problem if D1 was the last selected channel. High speed 533 communication to D3 will be "leaked" to D1. 534 - Predefined channel: Problem, if the predefined channel D1. Set predefined channel 535 to D2 as D2 may handle 400kHz. 536 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
© 2016 - 2026 Red Hat, Inc.