From mboxrd@z Thu Jan 1 00:00:00 1970 From: "David.Wu" Subject: Re: [PATCH v7 9/9] i2c: rk3x: support fast-mode plus for rk3399 Date: Fri, 6 May 2016 10:12:04 +0800 Message-ID: <572BFD74.9080200@rock-chips.com> References: <1462371194-5809-1-git-send-email-david.wu@rock-chips.com> <1462372668-6583-1-git-send-email-david.wu@rock-chips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from lucky1.263xmail.com ([211.157.147.133]:49611 "EHLO lucky1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754684AbcEFCLx (ORCPT ); Thu, 5 May 2016 22:11:53 -0400 In-Reply-To: Sender: linux-i2c-owner@vger.kernel.org List-Id: linux-i2c@vger.kernel.org To: Doug Anderson Cc: =?UTF-8?Q?Heiko_St=c3=bcbner?= , Wolfram Sang , Rob Herring , Andy Shevchenko , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Brian Norris , David Riley , Tao Huang , Lin Huang , Jianqun Xu , Chris , Eddie Cai , "linux-arm-kernel@lists.infradead.org" , "open list:ARM/Rockchip SoC..." , "linux-i2c@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Hi Doug, =E5=9C=A8 2016/5/6 7:02, Doug Anderson =E5=86=99=E9=81=93: > David, > > On Wed, May 4, 2016 at 7:37 AM, David Wu wr= ote: >> Signed-off-by: David Wu >> --- >> drivers/i2c/busses/i2c-rk3x.c | 21 +++++++++++++++++---- >> 1 file changed, 17 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-= rk3x.c >> index 47368c4..c66cc39 100644 >> --- a/drivers/i2c/busses/i2c-rk3x.c >> +++ b/drivers/i2c/busses/i2c-rk3x.c >> @@ -124,6 +124,17 @@ static const struct i2c_spec_values fast_mode_s= pec =3D { >> .min_hold_buffer_ns =3D 1300, >> }; >> >> +static const struct i2c_spec_values fast_mode_plus_spec =3D { >> + .min_hold_start_ns =3D 260, >> + .min_low_ns =3D 500, >> + .min_high_ns =3D 260, >> + .min_setup_start_ns =3D 260, >> + .max_data_hold_ns =3D 400, > > I'm curious where you got the data_hold_ns. I can't quite remember > what this parameter does / how the timing function works anymore, but > the doc I have (search for UM10204 and click the first link) shows > values for Standard-mode and Fast-mode but not Fast-mode Plus. It > seems to imply that this is a bit of a bogus number anyway because it > only matters if we don't stretch the tLOW to go along with the longer > data hold. > > As I have said in the previous patch, how all this stuff works has > totally left my brain, so if you understand it that's probably good > enough. If you feel like I should try to re-understand this again so > I can review it more deeply, let me know. > > Yes, I could not get the description of fast-mode plus data_hold_ns, bu= t=20 I saw that the maximum tHD;DAT must be less than the maximum of=20 tVD;DATor tVD;ACKby for Standard-mode and Fast-mode. So I think the maximum tHD;DAT for Fast-mode Plus should be less than=20 the maximum of tVD;DATor tVD;ACKby too, the maximum of tVD;DATor=20 tVD;ACKby is 450ns, and 400ns is my taking a conservative value. Description form UM10204 [4] The maximum tHD;DATcould be 3.45=CE=BCs and 0.9=CE=BCs for Standard= -mode and=20 =46ast-mode, but must be less than the maximum of tVD;DATor tVD;ACKby a= =20 transition time. This maximum must only be met if the device does not=20 stretch the LOW period (tLOW) of the SCL signal. If the clock stretches= =20 the SCL, the data must be valid by the set-up time before it releases the clock. > Since I assume that you had some sane reason to include max_data_hold= _ns: > > Reviewed-by: Douglas Anderson > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: david.wu@rock-chips.com (David.Wu) Date: Fri, 6 May 2016 10:12:04 +0800 Subject: [PATCH v7 9/9] i2c: rk3x: support fast-mode plus for rk3399 In-Reply-To: References: <1462371194-5809-1-git-send-email-david.wu@rock-chips.com> <1462372668-6583-1-git-send-email-david.wu@rock-chips.com> Message-ID: <572BFD74.9080200@rock-chips.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Doug, ? 2016/5/6 7:02, Doug Anderson ??: > David, > > On Wed, May 4, 2016 at 7:37 AM, David Wu wrote: >> Signed-off-by: David Wu >> --- >> drivers/i2c/busses/i2c-rk3x.c | 21 +++++++++++++++++---- >> 1 file changed, 17 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c >> index 47368c4..c66cc39 100644 >> --- a/drivers/i2c/busses/i2c-rk3x.c >> +++ b/drivers/i2c/busses/i2c-rk3x.c >> @@ -124,6 +124,17 @@ static const struct i2c_spec_values fast_mode_spec = { >> .min_hold_buffer_ns = 1300, >> }; >> >> +static const struct i2c_spec_values fast_mode_plus_spec = { >> + .min_hold_start_ns = 260, >> + .min_low_ns = 500, >> + .min_high_ns = 260, >> + .min_setup_start_ns = 260, >> + .max_data_hold_ns = 400, > > I'm curious where you got the data_hold_ns. I can't quite remember > what this parameter does / how the timing function works anymore, but > the doc I have (search for UM10204 and click the first link) shows > values for Standard-mode and Fast-mode but not Fast-mode Plus. It > seems to imply that this is a bit of a bogus number anyway because it > only matters if we don't stretch the tLOW to go along with the longer > data hold. > > As I have said in the previous patch, how all this stuff works has > totally left my brain, so if you understand it that's probably good > enough. If you feel like I should try to re-understand this again so > I can review it more deeply, let me know. > > Yes, I could not get the description of fast-mode plus data_hold_ns, but I saw that the maximum tHD;DAT must be less than the maximum of tVD;DATor tVD;ACKby for Standard-mode and Fast-mode. So I think the maximum tHD;DAT for Fast-mode Plus should be less than the maximum of tVD;DATor tVD;ACKby too, the maximum of tVD;DATor tVD;ACKby is 450ns, and 400ns is my taking a conservative value. Description form UM10204 [4] The maximum tHD;DATcould be 3.45?s and 0.9?s for Standard-mode and Fast-mode, but must be less than the maximum of tVD;DATor tVD;ACKby a transition time. This maximum must only be met if the device does not stretch the LOW period (tLOW) of the SCL signal. If the clock stretches the SCL, the data must be valid by the set-up time before it releases the clock. > Since I assume that you had some sane reason to include max_data_hold_ns: > > Reviewed-by: Douglas Anderson > > >