| Message ID | 20250318103622.29979-1-j-choudhary@ti.com |
|---|---|
| Headers | show |
| Series | Add support for setting MUX for I2C lines | expand |
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
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>
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
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
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(+)