All of lore.kernel.org
 help / color / mirror / Atom feed
From: addy ke <addy.ke@rock-chips.com>
To: dianders@chromium.org
Cc: wsa@the-dreams.de, max.schwarz@online.de, heiko@sntech.de,
	olof@lixom.net, linux-i2c@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, cf@rock-chips.com,
	xjq@rock-chips.com, huangtao@rock-chips.com, zyw@rock-chips.com,
	yzq@rock-chips.com, hj@rock-chips.com, kever.yang@rock-chips.com,
	hl@rock-chips.com, caesar.wang@rock-chips.com,
	zhengsq@rock-chips.com
Subject: Re: [PATCH] i2c: rk3x: adjust the LOW divison based on characteristics of SCL
Date: Fri, 26 Sep 2014 10:40:41 +0800	[thread overview]
Message-ID: <5424D229.8040709@rock-chips.com> (raw)
In-Reply-To: <CAD=FV=WhBhmCO=GamNr7yyXvLmOFDro8zWVwrj1zQVYogzeyVA@mail.gmail.com>



On 2014/9/26 10:08, Doug Anderson wrote:
> Addy,
> 
> On Thu, Sep 25, 2014 at 6:40 PM, addy ke <addy.ke@rock-chips.com> wrote:
>> Hi, Doug
>>
>> On 2014/9/26 5:52, Doug Anderson wrote:
>>> Addy,
>>>
>>> On Wed, Sep 24, 2014 at 9:36 PM, Doug Anderson <dianders@chromium.org> wrote:
>>>> Addy,
>>>>
>>>> On Wed, Sep 24, 2014 at 6:56 PM, addy ke <addy.ke@rock-chips.com> 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.
> 
> Ah, I didn't know this.  Is that in the TRM somewhere?
> 
No, it was my test and confirmed by IC engineer.
You can find that there is a pulse at half of LOW period of the ninth SCL clock each bytes.

> ...so does it work to just replace:
> 
>     ideal_low_div = DIV_ROUND_UP(clk_rate * min_low_ns,
>                                  scl_rate * 8 * min_total_ns)
> 
> ...with:
> 
>     ideal_low_div = min_low_div
> 
> 
> That will assign all "extra" time to the "high" part.
> 
I Think it is more reasonable.
> -Doug
> 
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: addy.ke@rock-chips.com (addy ke)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] i2c: rk3x: adjust the LOW divison based on characteristics of SCL
Date: Fri, 26 Sep 2014 10:40:41 +0800	[thread overview]
Message-ID: <5424D229.8040709@rock-chips.com> (raw)
In-Reply-To: <CAD=FV=WhBhmCO=GamNr7yyXvLmOFDro8zWVwrj1zQVYogzeyVA@mail.gmail.com>



On 2014/9/26 10:08, Doug Anderson wrote:
> Addy,
> 
> On Thu, Sep 25, 2014 at 6:40 PM, addy ke <addy.ke@rock-chips.com> wrote:
>> Hi, Doug
>>
>> On 2014/9/26 5:52, Doug Anderson wrote:
>>> Addy,
>>>
>>> On Wed, Sep 24, 2014 at 9:36 PM, Doug Anderson <dianders@chromium.org> wrote:
>>>> Addy,
>>>>
>>>> On Wed, Sep 24, 2014 at 6:56 PM, addy ke <addy.ke@rock-chips.com> 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.
> 
> Ah, I didn't know this.  Is that in the TRM somewhere?
> 
No, it was my test and confirmed by IC engineer.
You can find that there is a pulse at half of LOW period of the ninth SCL clock each bytes.

> ...so does it work to just replace:
> 
>     ideal_low_div = DIV_ROUND_UP(clk_rate * min_low_ns,
>                                  scl_rate * 8 * min_total_ns)
> 
> ...with:
> 
>     ideal_low_div = min_low_div
> 
> 
> That will assign all "extra" time to the "high" part.
> 
I Think it is more reasonable.
> -Doug
> 
> 
> 

  reply	other threads:[~2014-09-26  2:40 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-24  1:55 [PATCH] i2c: rk3x: adjust the LOW divison based on characteristics of SCL Addy Ke
2014-09-24  1:55 ` Addy Ke
2014-09-24  1:55 ` Addy Ke
2014-09-24  4:10 ` Doug Anderson
2014-09-24  4:10   ` Doug Anderson
2014-09-24  8:23   ` addy ke
2014-09-24  8:23     ` addy ke
     [not found]     ` <54227F93.7000507-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2014-09-24 17:13       ` Doug Anderson
2014-09-24 17:13         ` Doug Anderson
2014-09-24 17:13         ` Doug Anderson
2014-09-25  1:56         ` addy ke
2014-09-25  1:56           ` addy ke
     [not found]           ` <5423765B.8000706-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2014-09-25  4:36             ` Doug Anderson
2014-09-25  4:36               ` Doug Anderson
2014-09-25  4:36               ` Doug Anderson
     [not found]               ` <CAD=FV=Uuk1zBYn4NgcpDSHVfKeyw3MONO7roUNVSPSDDEyD=8Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-25 21:52                 ` Doug Anderson
2014-09-25 21:52                   ` Doug Anderson
2014-09-25 21:52                   ` Doug Anderson
     [not found]                   ` <CAD=FV=UkAcR8b+T_Dvoy9STDfzyC8QVSawihoHLYyHFJ6bfXxQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-26  1:40                     ` addy ke
2014-09-26  1:40                       ` addy ke
2014-09-26  1:40                       ` addy ke
2014-09-26  2:08                       ` Doug Anderson
2014-09-26  2:08                         ` Doug Anderson
2014-09-26  2:40                         ` addy ke [this message]
2014-09-26  2:40                           ` addy ke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5424D229.8040709@rock-chips.com \
    --to=addy.ke@rock-chips.com \
    --cc=caesar.wang@rock-chips.com \
    --cc=cf@rock-chips.com \
    --cc=dianders@chromium.org \
    --cc=heiko@sntech.de \
    --cc=hj@rock-chips.com \
    --cc=hl@rock-chips.com \
    --cc=huangtao@rock-chips.com \
    --cc=kever.yang@rock-chips.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=max.schwarz@online.de \
    --cc=olof@lixom.net \
    --cc=wsa@the-dreams.de \
    --cc=xjq@rock-chips.com \
    --cc=yzq@rock-chips.com \
    --cc=zhengsq@rock-chips.com \
    --cc=zyw@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.