Re: [PATCH] i2c: rk3x: adjust the LOW divison based on characteristics of SCL
From: addy ke
Date: Thu Sep 25 2014 - 21:41:36 EST
On 2014/9/26 5:52, Doug Anderson wrote:
> On Wed, Sep 24, 2014 at 9:36 PM, Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
>> On Wed, Sep 24, 2014 at 6:56 PM, addy ke <addy.ke@xxxxxxxxxxxxxx> wrote:
>>> In my measurement,all paramter but "Data hold time" are match the characteristics of SCL bus line.
>>> the measured value is 0.928us("data hold time on RK3X" ~= "the low period / 2")
>>> but the maximum value described in table is 0.9us
>>> About "Data hold time", there are described in I2C specification:
>>> - for CBUS compatible masters for I2C-bus deivices
>>> - the maximum data hold time has only be met if the device does not stretch the LOW period of the SCL signal.
>>> I have tested on RK3288-Pinky board, there are no error.
>>> But I don't known whether this paramter will affect i2c communications.
>> I'll have to spend more time tomorrow to really understand this, but
>> if changing the code to bias towards slightly longer "high" times
>> instead of "low" times helps fix it then that's fine with me.
> So what you're saying is that you're seeing a case where the clock
> goes low and the data is not valid until .928us. Is this data that is
> being driven by the master or data that is being driven by the slave?
It is driven by the master and will be release at half of LOW period in our IC design.
> Do you know why the data takes so long to be valid? Maybe you can
> email me some of the waveforms and I can try to help you debug it.
sure, I will email the I2C signal test report table right now.
> In any case it sounds like the the "data hold time" problem is
> unrelated to the clock ratio problem (right?), so maybe you could send
> out patch v2?
Ok, I will send patch v2 today.
> P.S. I checked the Rockchip TRM and it claims 400kHz maximum i2c. I
> think that means you can just remove all of the "fast mode plus" and
> "high speed mode" clock rates from your table.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/