On Thu, 31 Jul 2008, Grant Likely wrote: > On Thu, Jul 31, 2008 at 09:54:48PM +0200, Wolfgang Grandegger wrote: > > Thinking more about it, it would be best to add the property > > "i2c-clock-divider" to the soc node and implement fsl_get_i2c_freq() in > > a similar way: > > > > [EMAIL PROTECTED] { > > #address-cells = <1>; > > #size-cells = <1>; > > device_type = "soc"; > > ranges = <0x0 0xe0000000 0x100000>; > > reg = <0xe0000000 0x1000>; // CCSRBAR 1M > > bus-frequency = <0>; > > i2c-clock-divider = <2>; > > > > U-Boot could then fixup that value like bus-frequency() and the i2c-mpc > > driver simply calls fsl_get_i2c_freq().
Except the i2c clock isn't always a based on an interger divider of the CCB frequency. What's more, it's not always the same for both i2c controllers. Suppose i2c #1 uses CCB times 2/3 and i2c #2 uses CCB/2, how would fsl_get_i2c_freq() figure that out from bus-frequency and i2c-clock-divider? > Ugh. This is specifically related to the i2c device, so please place > the property in the i2c device. Remember, device tree design is not > about what will make the implementation simplest, but rather about what > describes the hardware in the best way. > Now, if you can argue that i2c-clock-frequency is actually a separate > clock domain defined at the SoC level, not the i2c device level, then I > will change my opinion. The i2c controller just uses some system clock that was handy. For each chip, the designers consult tea leaves to choose a system clock at random to connect to the i2c controller. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev