On 7/31/08, Grant Likely [off-list ref] wrote:

Your mixing up device tree layout with implementation details.  Device
 tree layout must come first.  mpc52xx_find_ipb_freq() is just a
 convenience function that walks up the device tree looking for a
 bus-frequency property.

 So, instead of making arguments based on available helper functions,
 make your arguments based on how data should be laid out in the device
 tree.  Currently mpc5200 bindings simply depend on finding a
 bus-frequency property in the parent node for determining the input
 clock and I don't see any pressing reason to change that (though it
 probably needs to be documented better).

 However, for the complex cases that Trent and Timur are talking about,
 it makes perfect sense to have an optional property in the i2c node
 itself that defines a different clock.  Once that decision has been made
 and documented, then the driver can be modified and the appropriate
 helper functions added to adapt the device tree data into something
 useful.

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.

The phandle in the mpc5200 case could be implicit since it is fixed in silicon.

Is this register in a system register bank or an i2c one?
gur->pordevsr2 & MPC85xx_PORDEVSR2_SEC_CFG

 Remember (and chant this to yourself).  The device tree describes
 *hardware*.  It does not describe Linux internal implementation details.


 g.

-- 
Jon Smirl
jonsmirl@gmail.com