On Thu, 31 Jul 2008, Jon Smirl wrote: > > Here's my idea: > > > > [EMAIL PROTECTED] { > > compatible = "fsl-i2c"; > > bus-frequency = <100000>; > > > > /* Either */ > > source-clock-frequency = <0>; > > /* OR */ > > source-clock = <&ccb>; > > }; > > Can't we hide a lot of this on platforms where the source clock is not > messed up? For example the mpc5200 doesn't need any of this, the > needed frequency is already available in mpc52xx_find_ipb_freq(). > mpc5200 doesn't need any uboot change. > > Next would be normal mpc8xxx platforms where i2c is driven by a single > clock, add a uboot filled in parameter in the root node (or I think it > can be computed off of the ones uboot is already filling in). make a > mpc8xxx_find_i2c_freq() function. May not need to change device tree > and uboot. > > Finally use this for those days when the tea leaves were especially > bad. Both a device tree and uboot change.
If you have to support clock speed in the i2c node anyway, what's the point of the other options? > > Except the i2c clock isn't always a based on an integer 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? > > If you get the CCB frequency from uboot and know the chip model, can't > you compute these in the platform code? Then make a > mpc8xxx_find_i2c_freq(cell_index). You need a bunch of random other device registers (SEC, ethernet, sdhc, etc.) too. > I don't see why we want to go through the trouble of having uboot tell > us things about a chip that are fixed in stone. Obviously something > like the frequency of the external crystal needs to be passed up, but > why pass up stuff that can be computed (or recovered by reading a > register)? One could also say that if U-boot has to have the code and already calculated the value, why duplicate the code and the calculation in Linux? _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev