<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/drivers/i2c/muxes/Makefile, branch master</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>i2c: muxes: Add PCA9541 i2c arbitrator driver</title>
<updated>2025-07-12T05:36:51+00:00</updated>
<author>
<name>Padmarao Begari</name>
<email>padmarao.begari@amd.com</email>
</author>
<published>2025-06-23T08:24:39+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=55d6d715a409c0938c33407eae2be9c3351f039d'/>
<id>55d6d715a409c0938c33407eae2be9c3351f039d</id>
<content type='text'>
Add a driver for the PCA9541 i2c bus arbitrator based
on the Linux driver for the same device.

Co-developed-by: Jonathan Stroud &lt;jonathan.stroud@amd.com&gt;
Signed-off-by: Jonathan Stroud &lt;jonathan.stroud@amd.com&gt;
Signed-off-by: Padmarao Begari &lt;padmarao.begari@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add a driver for the PCA9541 i2c bus arbitrator based
on the Linux driver for the same device.

Co-developed-by: Jonathan Stroud &lt;jonathan.stroud@amd.com&gt;
Signed-off-by: Jonathan Stroud &lt;jonathan.stroud@amd.com&gt;
Signed-off-by: Padmarao Begari &lt;padmarao.begari@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Link failure with CONFIG_SPL and CONFIG_I2C_MUX_PCA954x</title>
<updated>2020-08-25T04:25:42+00:00</updated>
<author>
<name>Trommel, Kees (Contractor)</name>
<email>kees.trommel.contractor@draeger.com</email>
</author>
<published>2020-08-03T14:49:47+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=660606091f12320210cb7ced018788b8028aab5f'/>
<id>660606091f12320210cb7ced018788b8028aab5f</id>
<content type='text'>
Fix for the case of a U-Boot configuration with CONFIG_SPL,
CONFIG_I2C_MUX, CONFIG_I2C_MUX_PCA954x, no CONFIG_SPL_DM and no
CONFIG_SPL_I2C_MUX. Without this fix linking of pca954x fails because
dm_write_i2c does not exist because CONFIG_SPL_DM is not defined.

Signed-off-by: Kees Trommel &lt;kees.trommel.contractor@draeger.com&gt;
Cc:  Heiko Schocher &lt;hs@denx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix for the case of a U-Boot configuration with CONFIG_SPL,
CONFIG_I2C_MUX, CONFIG_I2C_MUX_PCA954x, no CONFIG_SPL_DM and no
CONFIG_SPL_I2C_MUX. Without this fix linking of pca954x fails because
dm_write_i2c does not exist because CONFIG_SPL_DM is not defined.

Signed-off-by: Kees Trommel &lt;kees.trommel.contractor@draeger.com&gt;
Cc:  Heiko Schocher &lt;hs@denx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>SPDX: Convert all of our single license tags to Linux Kernel style</title>
<updated>2018-05-07T13:34:12+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2018-05-06T21:58:06+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=83d290c56fab2d38cd1ab4c4cc7099559c1d5046'/>
<id>83d290c56fab2d38cd1ab4c4cc7099559c1d5046</id>
<content type='text'>
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.

Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.

Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i2c: muxes: add i2c gpio multiplexer driver</title>
<updated>2017-08-23T05:04:56+00:00</updated>
<author>
<name>Peng Fan</name>
<email>peng.fan@nxp.com</email>
</author>
<published>2017-08-14T10:00:05+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=a430556ecb630d26880b34b914b6ec29f5454d01'/>
<id>a430556ecb630d26880b34b914b6ec29f5454d01</id>
<content type='text'>
Add an i2c mux driver providing access to i2c bus segments using a
hardware MUX sitting on a master bus and controlled through gpio pins.

E.G. something like:

         ----------              ----------  Bus segment 1   - - - - -
        |          | SCL/SDA    |          |-------------- |           |
        |          |------------|          |
        |          |            |          | Bus segment 2 |           |
        |  Linux   | GPIO 1..N  |   MUX    |---------------   Devices
        |          |------------|          |               |           |
        |          |            |          | Bus segment M
        |          |            |          |---------------|           |
         ----------              ----------                  - - - - -

SCL/SDA of the master I2C bus is multiplexed to bus segment 1..M
according to the settings of the GPIO pins 1..N.

Note commit log from kernel
commit 92ed1a76("i2c: Add generic I2C multiplexer using GPIO API")

Signed-off-by: Peng Fan &lt;peng.fan@nxp.com&gt;
Tested-by: Peng Fan &lt;peng.fan@nxp.com&gt; (i.MX6QP-Sabreauto)
Cc: Heiko Schocher &lt;hs@denx.de&gt;
Cc: Stefano Babic &lt;sbabic@denx.de&gt;
Cc: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add an i2c mux driver providing access to i2c bus segments using a
hardware MUX sitting on a master bus and controlled through gpio pins.

E.G. something like:

         ----------              ----------  Bus segment 1   - - - - -
        |          | SCL/SDA    |          |-------------- |           |
        |          |------------|          |
        |          |            |          | Bus segment 2 |           |
        |  Linux   | GPIO 1..N  |   MUX    |---------------   Devices
        |          |------------|          |               |           |
        |          |            |          | Bus segment M
        |          |            |          |---------------|           |
         ----------              ----------                  - - - - -

SCL/SDA of the master I2C bus is multiplexed to bus segment 1..M
according to the settings of the GPIO pins 1..N.

Note commit log from kernel
commit 92ed1a76("i2c: Add generic I2C multiplexer using GPIO API")

Signed-off-by: Peng Fan &lt;peng.fan@nxp.com&gt;
Tested-by: Peng Fan &lt;peng.fan@nxp.com&gt; (i.MX6QP-Sabreauto)
Cc: Heiko Schocher &lt;hs@denx.de&gt;
Cc: Stefano Babic &lt;sbabic@denx.de&gt;
Cc: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i2c: muxes: Add support for TI PCA954X mux</title>
<updated>2016-05-17T06:28:50+00:00</updated>
<author>
<name>Michal Simek</name>
<email>michal.simek@xilinx.com</email>
</author>
<published>2016-04-25T08:50:42+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d79ac324789839b4b10b37e2ff64dd9e4a92441e'/>
<id>d79ac324789839b4b10b37e2ff64dd9e4a92441e</id>
<content type='text'>
Add support for common TI i2c mux which is available on ZynqMP zcu102
board.
DM i2c mux core code is selecting/deselecting bus before/after
every command is performed that's why only one channel is active at a
time. That's also the reason why deselect is just disable all available
channels.

Signed-off-by: Michal Simek &lt;michal.simek@xilinx.com&gt;
Reviewed-by: Heiko Schocher &lt;hs@denx.de&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add support for common TI i2c mux which is available on ZynqMP zcu102
board.
DM i2c mux core code is selecting/deselecting bus before/after
every command is performed that's why only one channel is active at a
time. That's also the reason why deselect is just disable all available
channels.

Signed-off-by: Michal Simek &lt;michal.simek@xilinx.com&gt;
Reviewed-by: Heiko Schocher &lt;hs@denx.de&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dm: i2c: Allow muxes to be enabled for SPL separately</title>
<updated>2016-01-22T03:42:35+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2016-01-22T02:43:53+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=4082fce92498a64e5e543ad53a1ed5a5c02a64d1'/>
<id>4082fce92498a64e5e543ad53a1ed5a5c02a64d1</id>
<content type='text'>
Since I2C muxes are seldom needed in SPL, and the code for this increases
the size somewhat, add a separate option to enable I2C muxes for SPL.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since I2C muxes are seldom needed in SPL, and the code for this increases
the size somewhat, add a separate option to enable I2C muxes for SPL.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i2c: Add a mux for GPIO-based I2C bus arbitration</title>
<updated>2015-08-06T03:06:10+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2015-08-03T14:19:22+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=b725dc458f9db44957d4f541d05defe178dda7b5'/>
<id>b725dc458f9db44957d4f541d05defe178dda7b5</id>
<content type='text'>
While I2C supports multi-master buses this is difficult to get right.
The implementation on the master side in software is quite complex.
Clock-stretching and the arbitrary time that an I2C transaction can take
make it difficult to share the bus fairly in the face of high traffic.
When one or more masters can be reset independently part-way through a
transaction it is hard to know the state of the bus.

This driver provides a scheme based on two 'claim' GPIOs, one driven by the
AP (Application Processor, meaning the main CPU) and one driven by the EC
(Embedded Controller, a small CPU aimed at handling system tasks). With
these they can communicate and reliably share the bus. This scheme has
minimal overhead and involves very little code. It is used on snow to
permit the EC and the AP to share access to the main system PMIC and
battery. The scheme can survive reboots by either side without difficulty.
This scheme has been tested in the field with millions of devices.

Since U-Boot runs on the AP, the terminology used is 'our' claim GPIO,
meaning the AP's, and 'their' claim GPIO, meaning the EC's. This terminology
is used by the device tree bindings in Linux also.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While I2C supports multi-master buses this is difficult to get right.
The implementation on the master side in software is quite complex.
Clock-stretching and the arbitrary time that an I2C transaction can take
make it difficult to share the bus fairly in the face of high traffic.
When one or more masters can be reset independently part-way through a
transaction it is hard to know the state of the bus.

This driver provides a scheme based on two 'claim' GPIOs, one driven by the
AP (Application Processor, meaning the main CPU) and one driven by the EC
(Embedded Controller, a small CPU aimed at handling system tasks). With
these they can communicate and reliably share the bus. This scheme has
minimal overhead and involves very little code. It is used on snow to
permit the EC and the AP to share access to the main system PMIC and
battery. The scheme can survive reboots by either side without difficulty.
This scheme has been tested in the field with millions of devices.

Since U-Boot runs on the AP, the terminology used is 'our' claim GPIO,
meaning the AP's, and 'their' claim GPIO, meaning the EC's. This terminology
is used by the device tree bindings in Linux also.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dm: i2c: Add support for multiplexed I2C buses</title>
<updated>2015-08-06T03:06:10+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2015-08-03T14:19:21+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3d1957f0ea0133ec06f9c6fd85dc1acdf66ad29c'/>
<id>3d1957f0ea0133ec06f9c6fd85dc1acdf66ad29c</id>
<content type='text'>
Add a new I2C_MUX uclass. Devices in this class can multiplex between
several I2C buses, selecting them one at a time for use by the system.
The multiplexing mechanism is left to the driver to decide - it may be
controlled by GPIOs, for example.

The uclass supports only two methods: select() and deselect().

The current mux state is expected to be stored in the mux itself since
it is the only thing that knows how to make things work. The mux can
record the current state and then avoid switching unless it is necessary.
So select() can be skipped if the mux is already in the correct state.
Also deselect() can be made a nop if required.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add a new I2C_MUX uclass. Devices in this class can multiplex between
several I2C buses, selecting them one at a time for use by the system.
The multiplexing mechanism is left to the driver to decide - it may be
controlled by GPIOs, for example.

The uclass supports only two methods: select() and deselect().

The current mux state is expected to be stored in the mux itself since
it is the only thing that knows how to make things work. The mux can
record the current state and then avoid switching unless it is necessary.
So select() can be skipped if the mux is already in the correct state.
Also deselect() can be made a nop if required.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
