On Thu, Jul 31, 2008 at 01:35:51PM -0500, Timur Tabi wrote: > Grant Likely wrote: > > > No it doesn't, it depends on the register interface to decide > > compatibility. Clock interface is part of that. > > I don't think so. The interface for programming the clock registers is > identical on all 8[356]xx parts. The only thing that matters is what specific > values to put in the FDR and DFSR registers to get a desired I2C bus speed. > That answer is dependent on the actual clock input to the device, which is > external to the device. I wouldn't call the input frequency a property of the > I2C device.
Okay, I accept that argument. Make input frequency a property and be done with it. > > I suggested encoding > > the clock divider directly in compatible (implicit in the SoC version), > > but it doesn't have to be that way. If clock freq is obtained from > > another property or some other method then that is okay too. > > I think we agree on that. indeed. > > There is nothing wrong with it (as long as we agree and it gets > > documented). I certainly don't have a problem with doing it this way. > > I propose the property "clock-frequency", like this: > > [EMAIL PROTECTED] { > #address-cells = <1>; > #size-cells = <0>; > cell-index = <0>; > compatible = "fsl-i2c"; > reg = <0x3000 0x100>; > interrupts = <14 0x8>; > interrupt-parent = <&ipic>; > dfsrr; > clock-frequency = <0xblablabla>; <-- added by U-Boot > }; I'm okay with this. > Note that the dfsrr property already differentiates between 8xxx and 52xx, so > maybe we don't need any other device tree changes. The whole dfsrr property is a really bad idea, and it just replaces the equally bad idea of an "mpc5200-clocking" property which is currently in use. This bit should definitely be determined via compatible. g. _______________________________________________ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c