Scott Wood wrote: > Timur Tabi wrote: >> Scott Wood wrote: >>> A clock-frequency property is OK, and is in line with what we do in >>> other types of nodes. However, in the long run it might be nice to >>> introduce some sort of clock binding where, for example, the i2c node >>> can point to a clock elsewhere in the device tree as an input clock. >> The only problem with that is that the actual input clock to the I2C device >> is >> not the same as any other device. It's a unique clock. Look at the code I >> had >> to write to figure out this clock just on 85xx: > > IIRC, only the divider is unique, and the divider that is applied to the > input clock can be specified in the i2c node (either implicitly in > compatible, or explicitly via a property).
True, but I'd rather we have a real clock-frequency property that contains the calculated I2C input frequency, than a divider. It's more consistent with other properties, and it hides the complicated nature of I2C clocking. -- Timur Tabi Linux kernel developer at Freescale _______________________________________________ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
