[PATCH 0/2] Add support for setting MUX for I2C lines

[PATCH 0/2] Add support for setting MUX for I2C lines

[Jayesh Choudhary]

These 2 patches add support for mux-controller for I2C lines as required
in TI SoC J721S2 for main_i2c3 instance where the I2C lines after coming
out of SoC are routed through a MUX which is controlled by WKUP_GPIO54:

______                     MUX FOR I2C
      | SOM_I2C3_SCL    __ FOR DATA AND CLK LANES
 S    |----------------|  |--------------+-------------+-----I2C3_SCL
 O    |----------------|__|------------+-|-----------+-|-----I2C3_SDA
 M    | SOM_I2C3_SDA    |              | |           | |
______|                 |              | |           | |
                        |              | |           | |
                   WKUP_GPIO0_54     __|_|__       __|_|__
                                    |       |     |       |
                                    |       |     |       |
                                    |_______|     |_______|
                                     TCA6408       PCM3168

Setting GPIO hog for WKUP_GPIO54 is not enough as I2C and TCA6408 drivers
probe before the GPIO is hogged and since the I2C lines are not actually
high, I2C transactions for PCA953X driver fail which in turns result in
deferred probe for other peripherals like audio. I2C recovers after this
failed transaction but PCA953X is not probed again.

We get the following errors:

[...]

[    1.293131] pca953x 2-0020: supply vcc not found, using dummy regulator
[    1.299971] pca953x 2-0020: using no AI
[    1.318993] pca953x 2-0020: failed writing register: -121
[    1.324599] pca953x 2-0020: probe with driver pca953x failed with error -121

[...]

[   21.191584] i2c 2-0044: deferred probe pending: i2c: supplier 2-0020 not ready
[   21.198855] platform sound: deferred probe pending: j721e-audio: devm_snd_soc_register_card() failed: -517

So add mux-control in I2C driver to defer the I2C probe till WKUP_GPIO54 is
hogged to desired state and then continue with I2C probe.

Jayesh Choudhary (2):
  dt-bindings: i2c: omap: Add mux-states property
  i2c: omap: Add support for setting mux

 .../devicetree/bindings/i2c/ti,omap4-i2c.yaml |  6 +++++
 drivers/i2c/busses/Kconfig                    |  1 +
 drivers/i2c/busses/i2c-omap.c                 | 22 +++++++++++++++++++
 3 files changed, 29 insertions(+)

-- 
2.34.1

[PATCH 1/2] dt-bindings: i2c: omap: Add mux-states property

[Jayesh Choudhary]

Add mux controller support for when the I2C lines are muxed after
signals come out of SoC and before they go to any client.

Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
---
 Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml b/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml
index 8c2e35fabf5b..58d32ceeacfc 100644
--- a/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml
@@ -47,6 +47,11 @@ properties:
     $ref: /schemas/types.yaml#/definitions/string
     deprecated: true
 
+  mux-states:
+    description:
+      mux controller node to route the I2C signals from SoC to clients.
+    maxItems: 1
+
 required:
   - compatible
   - reg
@@ -87,4 +92,5 @@ examples:
         interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>;
         #address-cells = <1>;
         #size-cells = <0>;
+        mux-states = <&i2c_mux 1>;
     };
-- 
2.34.1

[PATCH 2/2] i2c: omap: Add support for setting mux

[Jayesh Choudhary]

Some SoCs require muxes in the routing for SDA and SCL lines.
Therefore, add support for setting the mux by reading the mux-states
property from the dt-node.

Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
---
 drivers/i2c/busses/Kconfig    |  1 +
 drivers/i2c/busses/i2c-omap.c | 22 ++++++++++++++++++++++
 2 files changed, 23 insertions(+)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index fc438f445771..0648e58b083e 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -940,6 +940,7 @@ config I2C_OMAP
 	tristate "OMAP I2C adapter"
 	depends on ARCH_OMAP || ARCH_K3 || COMPILE_TEST
 	default MACH_OMAP_OSK
+	select MULTIPLEXER
 	help
 	  If you say yes to this option, support will be included for the
 	  I2C interface on the Texas Instruments OMAP1/2 family of processors.
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f18c3e74b076..16afb9ca19bb 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -24,6 +24,7 @@
 #include <linux/platform_device.h>
 #include <linux/clk.h>
 #include <linux/io.h>
+#include <linux/mux/consumer.h>
 #include <linux/of.h>
 #include <linux/slab.h>
 #include <linux/platform_data/i2c-omap.h>
@@ -211,6 +212,7 @@ struct omap_i2c_dev {
 	u16			syscstate;
 	u16			westate;
 	u16			errata;
+	struct mux_state	*mux_state;
 };
 
 static const u8 reg_map_ip_v1[] = {
@@ -1452,6 +1454,23 @@ omap_i2c_probe(struct platform_device *pdev)
 				       (1000 * omap->speed / 8);
 	}
 
+	if (of_property_read_bool(node, "mux-states")) {
+		struct mux_state *mux_state;
+
+		mux_state = devm_mux_state_get(&pdev->dev, NULL);
+		if (IS_ERR(mux_state)) {
+			r = PTR_ERR(mux_state);
+			dev_dbg(&pdev->dev, "failed to get I2C mux: %d\n", r);
+			goto err_disable_pm;
+		}
+		omap->mux_state = mux_state;
+		r = mux_state_select(omap->mux_state);
+		if (r) {
+			dev_err(&pdev->dev, "failed to select I2C mux: %d\n", r);
+			goto err_disable_pm;
+		}
+	}
+
 	/* reset ASAP, clearing any IRQs */
 	omap_i2c_init(omap);
 
@@ -1511,6 +1530,9 @@ static void omap_i2c_remove(struct platform_device *pdev)
 
 	i2c_del_adapter(&omap->adapter);
 
+	if (omap->mux_state)
+		mux_state_deselect(omap->mux_state);
+
 	ret = pm_runtime_get_sync(&pdev->dev);
 	if (ret < 0)
 		dev_err(omap->dev, "Failed to resume hardware, skip disable\n");
-- 
2.34.1

Re: [PATCH 1/2] dt-bindings: i2c: omap: Add mux-states property

[Ing. Josua Mayer]

Hi Jayesh,

Am 18.03.25 um 11:36 schrieb Jayesh Choudhary:
> Add mux controller support for when the I2C lines are muxed after
> signals come out of SoC and before they go to any client.
> 
> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
> ---
>   Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml | 6 ++++++
>   1 file changed, 6 insertions(+)

Is there any chance for this to be generic across any i2c controller
regardless of SoC in use?
Is this perhaps also generic to any device in dts,
similar to assigned-clocks?

E.g. in k3-am642-hummingboard-t-{pcie,usb3}.dts we have a mux on the 
carrier board switching a serdes lane between two different connectors.
It would make sense for pcie and usb phy nodes to delay probe in a 
similar fashion.
The same may hold true for other buses muxed at boot-time or based on 
assembly options or extension cards.

sincerely
Josua Mayer

Re: [PATCH 1/2] dt-bindings: i2c: omap: Add mux-states property

[Rob Herring]

On Tue, Mar 18, 2025 at 2:55 PM Ing. Josua Mayer <josua.mayer@jm0.eu> wrote:
>
> Hi Jayesh,
>
> Am 18.03.25 um 11:36 schrieb Jayesh Choudhary:
> > Add mux controller support for when the I2C lines are muxed after
> > signals come out of SoC and before they go to any client.
> >
> > Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
> > ---
> >   Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml | 6 ++++++
> >   1 file changed, 6 insertions(+)
>
> Is there any chance for this to be generic across any i2c controller
> regardless of SoC in use?
> Is this perhaps also generic to any device in dts,
> similar to assigned-clocks?

$ git grep assigned-clocks arch/ | wc -l
2097

>
> E.g. in k3-am642-hummingboard-t-{pcie,usb3}.dts we have a mux on the
> carrier board switching a serdes lane between two different connectors.
> It would make sense for pcie and usb phy nodes to delay probe in a
> similar fashion.
> The same may hold true for other buses muxed at boot-time or based on
> assembly options or extension cards.

$ git grep mux-states arch/
arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts:
mux-states = <&mux0 1>;
arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts:
mux-states = <&mux0 1>;
arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts:
mux-states = <&mux1 1>;
arch/arm64/boot/dts/ti/k3-j784s4-j742s2-evm-common.dtsi:
 mux-states = <&mux1 1>;

I'm not convinced it is common enough to allow everywhere.

Rob

Re: [PATCH 1/2] dt-bindings: i2c: omap: Add mux-states property

[Rob Herring]

On Tue, Mar 18, 2025 at 5:36 AM Jayesh Choudhary <j-choudhary@ti.com> wrote:
>
> Add mux controller support for when the I2C lines are muxed after
> signals come out of SoC and before they go to any client.
>
> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
> ---
>  Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

Re: [PATCH 0/2] Add support for setting MUX for I2C lines

[Andi Shyti]

Hi Jayesh,

> Jayesh Choudhary (2):
>   dt-bindings: i2c: omap: Add mux-states property
>   i2c: omap: Add support for setting mux

merged to i2c/i2c-host.

Thanks,
Andi

Re: [PATCH 1/2] dt-bindings: i2c: omap: Add mux-states property

[Andreas Kemnade]

Am Tue, 18 Mar 2025 17:18:29 -0500
schrieb Rob Herring <robh@kernel.org>:

> On Tue, Mar 18, 2025 at 2:55 PM Ing. Josua Mayer <josua.mayer@jm0.eu> wrote:
> >
> > Hi Jayesh,
> >
> > Am 18.03.25 um 11:36 schrieb Jayesh Choudhary:  
> > > Add mux controller support for when the I2C lines are muxed after
> > > signals come out of SoC and before they go to any client.
> > >
> > > Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
> > > ---
> > >   Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml | 6 ++++++
> > >   1 file changed, 6 insertions(+)  
> >
> > Is there any chance for this to be generic across any i2c controller
> > regardless of SoC in use?
> > Is this perhaps also generic to any device in dts,
> > similar to assigned-clocks?  
> 
> $ git grep assigned-clocks arch/ | wc -l
> 2097
> 
> >
> > E.g. in k3-am642-hummingboard-t-{pcie,usb3}.dts we have a mux on the
> > carrier board switching a serdes lane between two different connectors.
> > It would make sense for pcie and usb phy nodes to delay probe in a
> > similar fashion.
> > The same may hold true for other buses muxed at boot-time or based on
> > assembly options or extension cards.  
> 
> $ git grep mux-states arch/
> arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts:
> mux-states = <&mux0 1>;
> arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts:
> mux-states = <&mux0 1>;
> arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts:
> mux-states = <&mux1 1>;
> arch/arm64/boot/dts/ti/k3-j784s4-j742s2-evm-common.dtsi:
>  mux-states = <&mux1 1>;
> 
> I'm not convinced it is common enough to allow everywhere.
> 
strange logic. It is not in there, because it is not allowed/supported
and some quirk maybe is added elsewhere, e.g. in bootloader or private
kernel branch.
So you cannot say whether such a case is common engough by looking what
is *now* in the dtb.

Regards,
Andreas