[PATCH v3 5/5] powerpc/85xx: i2c-mpc: use new I2C bindings for the Socates board

Wolfgang Grandegger wg at grandegger.com
Thu Apr 9 04:53:46 EST 2009

Kumar Gala wrote:
> On Apr 8, 2009, at 1:27 PM, Wolfgang Grandegger wrote:
>> Grant Likely wrote:
>>> On Wed, Apr 8, 2009 at 12:16 AM, Wolfgang Grandegger
>>> <wg at grandegger.com> wrote:
>>>> Grant Likely wrote:
>>>>> On Tue, Apr 7, 2009 at 1:20 AM, Wolfgang Grandegger
>>>>> <wg at grandegger.com> wrote:
>>>>>> Preserve I2C clock settings for the Socrates MPC8544 board.
>>>>> I had thought that the preserve-clocking property was intended for
>>>>> older boards that don't currently have any method of getting the clock
>>>>> setting out of u-boot.  Since Socrates is a new board, U-Boot should
>>>>> probably be made to fill in the real clock rate setting.
>>>> I'm not sure if I understand what you mean. If an old version of U-Boot
>>>> on an old board sets the I2C clock, it can be used (inherited) by Linux
>>>> using the property "preserve-clocking".
>>>> It is actually the customers choice to set the I2C clock in U-Boot and
>>>> re-use it by Linux.
>>> Setting it in the register != recording the value in the device tree.
>>> I'm saying that since Socrates is a new board it should not use the
>>> preserve-clocking dirty trick (and it is a dirty trick) because the
>>> correct clocking data can be passed via the device tree.
>> Why should an old board then use it. "fsl, preserve-clocking" is a new
>> feature, like using "clock-frequency" and you have the choice to
>> explicitly set the clocking via device tree or inherit it from the boot
>> loader. So far, a fixed FDR/DFRSS value (0x1031) was written to the
>> registers by Linux.
> I think Grant's point is socrates is a new board with a new u-boot. 
> That u-boot should be able to set the clock-frequency property in i2c. 
> One assumes if you a clock-frequency property you wouldn't use
> "fsl,preserve-clocking".  (However -- its feasible they are mutually
> exclusive).

OK, now it makes more sense to me even if I never thought that way. My
intention was to allow Linux to use a *different* frequency as the
bootloader by specifying the "clock-frequency" property. This would not
be possible with a fixup by the bootloader.


More information about the Linuxppc-dev mailing list