On Thu, Jul 31, 2008 at 01:35:51PM -0500, Timur Tabi wrote:
> Grant Likely wrote:
>
> > No it doesn't, it depends on the register interface to decide
> > compatibility. Clock interface is part of that.
>
> I don't think so. The interface for programming the clock registers is
> identical on all 8[356]xx parts. The only thing that matters is what specific
> values to put in the FDR and DFSR registers to get a desired I2C bus speed.
> That answer is dependent on the actual clock input to the device, which is
> external to the device. I wouldn't call the input frequency a property of the
> I2C device.
Okay, I accept that argument. Make input frequency a property and be
done with it.
> > I suggested encoding
> > the clock divider directly in compatible (implicit in the SoC version),
> > but it doesn't have to be that way. If clock freq is obtained from
> > another property or some other method then that is okay too.
>
> I think we agree on that.
indeed.
> > There is nothing wrong with it (as long as we agree and it gets
> > documented). I certainly don't have a problem with doing it this way.
>
> I propose the property "clock-frequency", like this:
>
> [EMAIL PROTECTED] {
> #address-cells = <1>;
> #size-cells = <0>;
> cell-index = <0>;
> compatible = "fsl-i2c";
> reg = <0x3000 0x100>;
> interrupts = <14 0x8>;
> interrupt-parent = <&ipic>;
> dfsrr;
> clock-frequency = <0xblablabla>; <-- added by U-Boot
> };
I'm okay with this.
> Note that the dfsrr property already differentiates between 8xxx and 52xx, so
> maybe we don't need any other device tree changes.
The whole dfsrr property is a really bad idea, and it just replaces the
equally bad idea of an "mpc5200-clocking" property which is currently in
use. This bit should definitely be determined via compatible.
g.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
