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

[Jon Smirl]

On 8/1/08, Timur Tabi <timur at freescale.com> wrote:
> On Thu, Jul 31, 2008 at 9:35 PM, Jon Smirl <jonsmirl at gmail.com> wrote:
>
>  > I've having trouble with whether these clocks are a system resource or
>  > something that belongs to i2c. If they are a system resource then we
>  > should make nodes in the root and use a phandle in the i2c node to
>  > link to them.
>
>
> I can't speak for 52xx, but for 8[356]xx, I would say the clocks
>  belong to the I2C devices.  The screwball determination of whether to
>  divide by 1, 2, or 3 only applies to the I2C device only.  The divider
>  itself is not used to drive a clock for any other device.  If you
>  disable I2C support, then you don't need to care about the divider (or
>  its output clock) at all.  That's why I think have the I2C clock in
>  the parent node is wrong, because it would only be used if you had I2C
>  child nodes.  If you didn't have any I2C nodes, then you would need to
>  delete the property from the parent node as well.

I see this as being one of three ways...

The source clocks belong to the platform and the clock messiness
belongs in the platform code.

The source clocks belong to i2c. The i2c driver needs to use platform
specific bindings like Grant proposed.

I don't like the third choice. Keep a simple Linux driver for i2c and
the platform, and then move all of the messy code into uboot.  BTW,
the messy code is about 10 lines. It's going to take more than 10
lines to hide those 10 lines.

I'm also of the view that all clocks are system resources. Linux is
designed to have clock domains, we just aren't using them on PowerPC.
Check out arch/powerpc/kernel/clock.c. They are mostly used on ARM.
Could we define domains I2C1, I2C2,.. and then implement them? That
implies using the root node to communicate the clock speeds to Linux.

-- 
Jon Smirl
jonsmirl at gmail.com