On Thu, Jun 06, 2024 at 11:24:38AM -0500, Danny Kaehn wrote: > On Thu, Jun 06, 2024 at 09:18:59AM -0600, Rob Herring wrote: > > On Wed, Jun 05, 2024 at 06:12:44PM -0500, Danny Kaehn wrote: ... > > > + i2c: > > > + description: The SMBus/I2C controller node for the CP2112 > > > + $ref: /schemas/i2c/i2c-controller.yaml# > > > + unevaluatedProperties: false > > > + > > > + properties: > > > + sda-gpios: > > > + maxItems: 1 > > > + > > > + scl-gpios: > > > + maxItems: 1 > > > > These are because I2C can be on any of the pins? It's a bit odd if they > > aren't used as gpios. Probably should be pinmux, but that's overkill for > > 2 pins. > > > > I'm beginning to realize now that this may be a bit non-standard, but it > did solve a stuck bus issue under some conditions. > > The CP2112's I2C controller is self-contained and can only be on the > specific pins it is attached to (no pinmux, etc..). > > In this case, these properties are ment to specify additional gpio pins > which are connected to the SCL and SDA lines (this then also assumes those > are configured to be open drain / inputs to not interfere with the bus > during normal operation). This was inspired by what is done ini2c-imx.yaml, > but I realize this is a bit different due to using external pins rather > than pinmuxing to the GPIOs. > > How I used this was to actually connect some of the CP2112's own GPIO pins > to the SDA and SCL lines to be able to use those pins to recover the > bus. This was able to solve a stuck bus under some real-world cases with > the v2 of the CP2112 containing an errata which caused this > semi-frequently. Aren't they just for I²C recovery? -- With Best Regards, Andy Shevchenko
