Hello, On Mon Feb 19, 2024 at 3:29 PM CET, Théo Lebrun wrote: > On Mon Feb 19, 2024 at 3:06 PM CET, Linus Walleij wrote: > > On Fri, Feb 16, 2024 at 10:16 AM Théo Lebrun <theo.lebrun@xxxxxxxxxxx> wrote: > > > i2c-mpc (fsl,timeout) and i2c-gpio (i2c-gpio,timeout-ms). I agree this > > > prop has no reason to be compatible-specific. > > > > > > Feedback from dt-bindings and I2C host maintainers would be useful: what > > > should the property be named? Having the unit makes it self-descriptive, > > > which sounds like a good idea to me. timeout-usecs, timeout-us, another > > > option? > > > > Use i2c-transfer-timeout-ms in my opinion, so it us crystal clear > > what that property is for. > > Using µs (microseconds) would be OK? I'm not sure yet about the exact > timeout desired but a one millisecond granularity might not be enough > for the Mobileye usecase. > > Expect incoming patches to use the I2C controller in Fast Mode Plus > (1Mbps) and High Speed Mode (3.4Mbps). Gotta go fast! > > > As Rob mentioned this isn't in the kernel schemas but in dtschema, so > > you need to patch this: > > https://github.com/robherring/dt-schema > > Indeed. The other question if we do microseconds is the > suffix: -us, -usecs, -microseconds, etc? I picked -usecs for my v1, but > a grep tells me I am the only user of this suffix. -us is much more > common. > > BTW i2c-controller.yaml already has a µs timeout: > i2c-scl-clk-low-timeout-us Note: I've sent a draft patch to dt-schema. See: https://github.com/devicetree-org/dt-schema/pull/129 Feedback from I2C maintainers would confirm or infirm that this goes in the right direction. Thanks, -- Théo Lebrun, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
