Re: [PATCH] i2c-qoriq: modified compatibility for correct prescaler

[Valentin Longchamp <valentin.longchamp@keymile.com>]

Hi all,

Picking up this issue again.

On 11/26/2014 02:41 AM, Scott Wood wrote:
> On Tue, 2014-11-25 at 19:13 +0100, Wolfram Sang wrote:
>> On Mon, Nov 17, 2014 at 07:28:03PM -0600, Scott Wood wrote:
>>> On Fri, 2014-11-14 at 09:28 +0100, Wolfram Sang wrote:
>>>>>>
>>>>>> If we're going to change the device tree I'd rather just add a property
>>>>>> to say what the prescaler is.
>>>>>
>>>>>  We would however, leave the boards' device trees that use things like
>>>>> "fsl,mpc8543-i2c" as is and introduce the prescaler for the others requiring it.
>>>>>
>>>>>
>>>>> Now the drawback is that the driver would require a change, to parse this
>>>>> prescaler new prescaler property. Would this be OK from your point of view
>>>>> Wolfram ? If yes, I will send the patches for it.
>>>>
>>>> I don't think it is OK.
>>>
>>> Why?
>>
>> Because I thought it could be deduced. Then, a seperate property would
>> not be OK.
>>
>>>>  I'd think it can be deduced from the compatible property.
>>>
>>> For almost all existing device trees it cannot be.
>>
>> Pity :( If we do introduce a new property, it should probably be
>> "clock-div". Grepping through binding documentation, that seems
>> accepted. We should ask DT maintainers, too, to be safe.
>>
>>> If you want something that will work without changing device trees,
>>> you'll need to use SVR to identify the SoC.
>>
>> The driver is doing that already, see mpc_i2c_get_sec_cfg_8xxx(). Dunno
>> if it makes sense to add to it for consistency reasons?
> 
> That's not SVR, but sure.  Better to avoid messing with existing device
> trees.
> 

What is then the agreement here ? Add a clock-div to the device trees ? Or do
something similar to  mpc_i2c_get_sec_cfg_8xxx() ?

I think the clock-div property is better according to Freescale's AN 2919
section 3.1 Source clock. All the source clocks are fixed (with a clock-div of 2
in case of mpc8536/43/45/47/48/67/68/72, plus p2020) except for the mpc8533/44
where it can be 2 or 3, and that's what mpc_i2c_get_sec_cfg_8xxx() determines.

So mpc_i2c_get_sec_cfg_8xxx() should remain the exception and the other
prescaler values should be derived from an additional clock-div that must be
added in the respective device trees (at least for the qoriq devices, because
for instance mpc8543 already has the correct prescaler thanks to
mpc_i2c_data_8543 from i2c-mpc.c).

Valentin