[i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT

[Trent Piepho]

On Thu, 31 Jul 2008, Jon Smirl wrote:
> >  Here's my idea:
> >
> >         i2c at 0 {
> >                 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?