linux-i2c.vger.kernel.org archive mirror
 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
> 
> 
> 

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

Thread overview: 10+ 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  4:10 ` Doug Anderson
2014-09-24  8:23   ` addy ke
     [not found]     ` <54227F93.7000507-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2014-09-24 17:13       ` Doug Anderson
2014-09-25  1:56         ` addy ke
     [not found]           ` <5423765B.8000706-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
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
     [not found]                   ` <CAD=FV=UkAcR8b+T_Dvoy9STDfzyC8QVSawihoHLYyHFJ6bfXxQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-26  1:40                     ` addy ke
2014-09-26  2:08                       ` Doug Anderson
2014-09-26  2:40                         ` addy ke [this message]

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).