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

[Kumar Gala]

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).

- k