On 7/31/08, Grant Likely <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
