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

[Danielle Costantino]

I saw that this patch was marked as not applicable, but on most qoriq
devices the pre-scaler is 2 especially for p2020/p2010 devices
arch/powerpc/boot/dts/fsl/p2020si-post.dtsi

from the P2020 RM: p. 477
"Frequency divider ratio. Used to prescale the clock for bit rate
selection. The serial bit clock frequency of
SCL is equal to one half the platform ( CCB ) clock divided by the
designated divider ."

This means that the current dts for these devices are providing false
clock settings. I have a p2020 board and can take some scope
measurements next week to prove this. I think something should be
modified to address this.


On Tue, Nov 25, 2014 at 5:41 PM, Scott Wood <scottwood at freescale.com> 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.
>
> -Scott
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
- Danielle Costantino