| Message ID | 20241125-fpc202-v3-1-34e86bcb5b56@bootlin.com |
|---|---|
| State | New |
| Headers | show |
| Series | misc: Support TI FPC202 dual-port controller | expand |
Hello Conor, On lundi 25 novembre 2024 19:26:35 heure normale d’Europe centrale Conor Dooley wrote: > On Mon, Nov 25, 2024 at 09:45:15AM +0100, Romain Gantois wrote: > > The FPC202 dual port controller serves as a low speed signal aggregator > > for ... > > + > > +required: > > + - compatible > > + - gpio-controller > > + - "#gpio-cells" > > + - reg > > + - "#address-cells" > > + - "#size-cells" > > + - i2c@0 > > + - i2c@1 > > btw, why are both downstream ports required? It's because both downstream ports are always present in an FPC202 unit so in my opinion, it doesn't make sense to describe an FPC202 with only one downstream port. I suppose you could also consider that ports would only be described in the DT if they were connected to something in the hardware, but I don't think it would make sense to use an FPC202 in this way. After all, the whole point of this component is to act as an I2C ATR and low-speed signal aggregator for downstream devices which would have address collisions if you placed them on the same I2C bus. But then again, you could consider that DT bindings should only describe what is possible, and not only what makes sense as a use case. I don't really know how to answer this question myself, so I'll refer to the maintainers' opinions. Best Regards,
On Tue, Nov 26, 2024 at 09:05:42AM +0100, Romain Gantois wrote: > Hello Conor, > > On lundi 25 novembre 2024 19:26:35 heure normale d’Europe centrale Conor Dooley wrote: > > On Mon, Nov 25, 2024 at 09:45:15AM +0100, Romain Gantois wrote: > > > The FPC202 dual port controller serves as a low speed signal aggregator > > > for > ... > > > + > > > +required: > > > + - compatible > > > + - gpio-controller > > > + - "#gpio-cells" > > > + - reg > > > + - "#address-cells" > > > + - "#size-cells" > > > + - i2c@0 > > > + - i2c@1 > > > > btw, why are both downstream ports required? > > It's because both downstream ports are always present in an FPC202 unit > so in my opinion, it doesn't make sense to describe an FPC202 with only one > downstream port. > > I suppose you could also consider that ports would only be described in the DT > if they were connected to something in the hardware, but I don't think it would > make sense to use an FPC202 in this way. After all, the whole point of this > component is to act as an I2C ATR and low-speed signal aggregator for > downstream devices which would have address collisions if you placed them > on the same I2C bus. > > But then again, you could consider that DT bindings should only describe what is > possible, and not only what makes sense as a use case. I don't really know how to > answer this question myself, so I'll refer to the maintainers' opinions. I don't really know what how this device works, which is why I am asking questions. If there is no use case were someone would only wire up one of the downstream ports then making both required is fine. I was just thinking that someone might only hook devices up to one side of it and leave the other unused entirely. Seemed like it could serve its role without both sides being used based on the diagram in https://docs.kernel.org/i2c/i2c-address-translators.html unless it is not possible for the atr to share the "parent" i2c bus with other devices?
On mardi 26 novembre 2024 19:09:43 heure normale d’Europe centrale Conor Dooley wrote: > On Tue, Nov 26, 2024 at 09:05:42AM +0100, Romain Gantois wrote: > > Hello Conor, ... > > > > But then again, you could consider that DT bindings should only describe > > what is possible, and not only what makes sense as a use case. I don't > > really know how to answer this question myself, so I'll refer to the > > maintainers' opinions. > I don't really know what how this device works, which is why I am asking > questions. If there is no use case were someone would only wire up one > of the downstream ports then making both required is fine. I was just > thinking that someone might only hook devices up to one side of it and > leave the other unused entirely. Seemed like it could serve its role > without both sides being used based on the diagram in > https://docs.kernel.org/i2c/i2c-address-translators.html > unless it is not possible for the atr to share the "parent" i2c bus with > other devices? It is possible for the FPC202 to share it's parent bus with other devices. And I guess you could wire up only one port and use the component as a simple address translator and GPIO aggregator. So indeed, requiring both ports to be described seems unnecessary. Thanks,
diff --git a/Documentation/devicetree/bindings/misc/ti,fpc202.yaml b/Documentation/devicetree/bindings/misc/ti,fpc202.yaml new file mode 100644 index 0000000000000000000000000000000000000000..d0464a77cabed81301e27ac2fd4e7f943a027f2a --- /dev/null +++ b/Documentation/devicetree/bindings/misc/ti,fpc202.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/misc/ti,fpc202.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI FPC202 dual port controller with expanded IOs + +maintainers: + - Romain Gantois <romain.gantois@bootlin.com> + +allOf: + - $ref: /schemas/i2c/i2c-atr.yaml# + +properties: + compatible: + const: ti,fpc202 + + reg: + maxItems: 1 + + gpio-controller: true + + "#gpio-cells": + const: 2 + + enable-gpios: + description: + Specifier for the GPIO connected to the EN pin. + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + "^i2c@[0-1]$": + $ref: /schemas/i2c/i2c-controller.yaml + description: Downstream device ports 0 and 1 + + properties: + reg: + maxItems: 1 + description: + Downstream port ID + + required: + - "#address-cells" + - "#size-cells" + - reg + + unevaluatedProperties: false + +required: + - compatible + - gpio-controller + - "#gpio-cells" + - reg + - "#address-cells" + - "#size-cells" + - i2c@0 + - i2c@1 + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + i2c-atr@f { + compatible = "ti,fpc202"; + reg = <0xf>; + #address-cells = <1>; + #size-cells = <0>; + + gpio-controller; + #gpio-cells = <2>; + + i2c@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + }; + + i2c@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + }; + }; + }; +... diff --git a/MAINTAINERS b/MAINTAINERS index b878ddc99f94e7f6e8fa2c479c5a3f846c514730..8e702cefd2070790330eebf6d2a2b592cadb682d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -23181,6 +23181,12 @@ F: drivers/misc/tifm* F: drivers/mmc/host/tifm_sd.c F: include/linux/tifm.h +TI FPC202 DUAL PORT CONTROLLER +M: Romain Gantois <romain.gantois@bootlin.com> +L: linux-kernel@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/misc/ti,fpc202.yaml + TI FPD-LINK DRIVERS M: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> L: linux-media@vger.kernel.org
The FPC202 dual port controller serves as a low speed signal aggregator for common port types, notably SFP. It provides access to I2C and low-speed GPIO signals of a downstream device through a single upstream control interface. Up to two logical I2C addresses can be accessed on each of the FPC202's ports. The port controller acts as an I2C translator (ATR). It converts addresses of incoming and outgoing I2C transactions. One use case of this is accessing two SFP modules at logical address 0x50 from the same upstream I2C controller, using two different client aliases. Signed-off-by: Romain Gantois <romain.gantois@bootlin.com> --- .../devicetree/bindings/misc/ti,fpc202.yaml | 96 ++++++++++++++++++++++ MAINTAINERS | 6 ++ 2 files changed, 102 insertions(+)