All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David.Wu" <david.wu@rock-chips.com>
To: Doug Anderson <dianders@chromium.org>
Cc: "Heiko Stübner" <heiko@sntech.de>,
	"Wolfram Sang" <wsa@the-dreams.de>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Andy Shevchenko" <andy.shevchenko@gmail.com>,
	"Pawel Moll" <pawel.moll@arm.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Ian Campbell" <ijc+devicetree@hellion.org.uk>,
	"Kumar Gala" <galak@codeaurora.org>,
	"Brian Norris" <briannorris@google.com>,
	"David Riley" <davidriley@google.com>,
	"Tao Huang" <huangtao@rock-chips.com>,
	"Lin Huang" <hl@rock-chips.com>,
	"Jianqun Xu" <xjq@rock-chips.com>, Chris <zyw@rock-chips.com>,
	"Eddie Cai" <cf@rock-chips.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v7 6/9] i2c: rk3x: Move spec timing data to "static const" structs
Date: Fri, 6 May 2016 12:55:15 +0800	[thread overview]
Message-ID: <572C23B3.6090702@rock-chips.com> (raw)
In-Reply-To: <CAD=FV=Vg+umhA73uR66AdFmaNKhpyXCYojqE9kZJqkTOsyK_Jg@mail.gmail.com>

Hi Doug,

在 2016/5/6 6:58, Doug Anderson 写道:
> David,
>
> On Wed, May 4, 2016 at 7:34 AM, David Wu <david.wu@rock-chips.com> wrote:
>> Signed-off-by: David Wu <david.wu@rock-chips.com>
>
> As you can probably guess, again a description would be nice.  Like maybe:
>
> The i2c timing specs are really just constant data.  There's no reason
> to write code to init them, so move them out to structures.  This not
> only is a cleaner solution but it will reduce code duplication when we
> introduce a new variant of rk3x_i2c_calc_divs() in a future patch.
>
> That helps someone reading the patch understand the motivation.
>
>
>> @@ -76,6 +76,51 @@ enum {
>>   #define DEFAULT_SCL_RATE  (100 * 1000) /* Hz */
>>
>>   /**
>> + * struct i2c_spec_values:
>> + * @min_hold_start_ns: min hold time (repeated) START condition
>> + * @min_low_ns: min LOW period of the SCL clock
>> + * @min_high_ns: min HIGH period of the SCL cloc
>> + * @min_setup_start_ns: min set-up time for a repeated START conditio
>> + * @max_data_hold_ns: max data hold time
>> + * @min_data_setup_ns: min data set-up time
>> + * @min_setup_stop_ns: min set-up time for STOP condition
>> + * @min_hold_buffer_ns: min bus free time between a STOP and
>> + * START condition
>> + */
>> +struct i2c_spec_values {
>> +       unsigned long min_hold_start_ns;
>> +       unsigned long min_low_ns;
>> +       unsigned long min_high_ns;
>> +       unsigned long min_setup_start_ns;
>> +       unsigned long max_data_hold_ns;
>> +       unsigned long min_data_setup_ns;
>> +       unsigned long min_setup_stop_ns;
>> +       unsigned long min_hold_buffer_ns;
>> +};
>> +
>> +static const struct i2c_spec_values standard_mode_spec = {
>> +       .min_hold_start_ns = 4000,
>> +       .min_low_ns = 4700,
>> +       .min_high_ns = 4000,
>> +       .min_setup_start_ns = 4700,
>> +       .max_data_hold_ns = 3450,
>> +       .min_data_setup_ns = 250,
>> +       .min_setup_stop_ns = 4000,
>> +       .min_hold_buffer_ns = 4700,
>
> There are more spec values than are currently used in this patch.
> Personally I'm OK with that, but if you wanted to be totally clean
> this patch would only include the spec values that were needed, then
> introduce the additional values in the rk3399 patch.
>
>
>> @@ -492,6 +548,8 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
>>          unsigned long min_div_for_hold, min_total_div;
>>          unsigned long extra_div, extra_low_div, ideal_low_div;
>>
>> +       unsigned long data_hold_buffer_ns = 50;
>
> aside (feel free to ignore): Gosh, I kinda forgot what the heck this
> value was for.  I guess it's not anything in the spec.  I have a
> feeling it was some sort of slop value that someone felt was
> necessary, but I don't quite remember.  Oh well, I guess we leave it
> there since I'd rather not mess with timings on old hardware that are
> apparently working for everyone.  :-P
>
>

I thing it was a tuning value for max_t_low_ns. :-P

> In any case, aside from the missing description:
>
> Suggested-by: Douglas Anderson <dianders@chromium.org>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
>
> IMHO this can be applied any time independent of any earlier patches.
>
>
> -Doug
>
>
>

WARNING: multiple messages have this Message-ID (diff)
From: david.wu@rock-chips.com (David.Wu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 6/9] i2c: rk3x: Move spec timing data to "static const" structs
Date: Fri, 6 May 2016 12:55:15 +0800	[thread overview]
Message-ID: <572C23B3.6090702@rock-chips.com> (raw)
In-Reply-To: <CAD=FV=Vg+umhA73uR66AdFmaNKhpyXCYojqE9kZJqkTOsyK_Jg@mail.gmail.com>

Hi Doug,

? 2016/5/6 6:58, Doug Anderson ??:
> David,
>
> On Wed, May 4, 2016 at 7:34 AM, David Wu <david.wu@rock-chips.com> wrote:
>> Signed-off-by: David Wu <david.wu@rock-chips.com>
>
> As you can probably guess, again a description would be nice.  Like maybe:
>
> The i2c timing specs are really just constant data.  There's no reason
> to write code to init them, so move them out to structures.  This not
> only is a cleaner solution but it will reduce code duplication when we
> introduce a new variant of rk3x_i2c_calc_divs() in a future patch.
>
> That helps someone reading the patch understand the motivation.
>
>
>> @@ -76,6 +76,51 @@ enum {
>>   #define DEFAULT_SCL_RATE  (100 * 1000) /* Hz */
>>
>>   /**
>> + * struct i2c_spec_values:
>> + * @min_hold_start_ns: min hold time (repeated) START condition
>> + * @min_low_ns: min LOW period of the SCL clock
>> + * @min_high_ns: min HIGH period of the SCL cloc
>> + * @min_setup_start_ns: min set-up time for a repeated START conditio
>> + * @max_data_hold_ns: max data hold time
>> + * @min_data_setup_ns: min data set-up time
>> + * @min_setup_stop_ns: min set-up time for STOP condition
>> + * @min_hold_buffer_ns: min bus free time between a STOP and
>> + * START condition
>> + */
>> +struct i2c_spec_values {
>> +       unsigned long min_hold_start_ns;
>> +       unsigned long min_low_ns;
>> +       unsigned long min_high_ns;
>> +       unsigned long min_setup_start_ns;
>> +       unsigned long max_data_hold_ns;
>> +       unsigned long min_data_setup_ns;
>> +       unsigned long min_setup_stop_ns;
>> +       unsigned long min_hold_buffer_ns;
>> +};
>> +
>> +static const struct i2c_spec_values standard_mode_spec = {
>> +       .min_hold_start_ns = 4000,
>> +       .min_low_ns = 4700,
>> +       .min_high_ns = 4000,
>> +       .min_setup_start_ns = 4700,
>> +       .max_data_hold_ns = 3450,
>> +       .min_data_setup_ns = 250,
>> +       .min_setup_stop_ns = 4000,
>> +       .min_hold_buffer_ns = 4700,
>
> There are more spec values than are currently used in this patch.
> Personally I'm OK with that, but if you wanted to be totally clean
> this patch would only include the spec values that were needed, then
> introduce the additional values in the rk3399 patch.
>
>
>> @@ -492,6 +548,8 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
>>          unsigned long min_div_for_hold, min_total_div;
>>          unsigned long extra_div, extra_low_div, ideal_low_div;
>>
>> +       unsigned long data_hold_buffer_ns = 50;
>
> aside (feel free to ignore): Gosh, I kinda forgot what the heck this
> value was for.  I guess it's not anything in the spec.  I have a
> feeling it was some sort of slop value that someone felt was
> necessary, but I don't quite remember.  Oh well, I guess we leave it
> there since I'd rather not mess with timings on old hardware that are
> apparently working for everyone.  :-P
>
>

I thing it was a tuning value for max_t_low_ns. :-P

> In any case, aside from the missing description:
>
> Suggested-by: Douglas Anderson <dianders@chromium.org>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
>
> IMHO this can be applied any time independent of any earlier patches.
>
>
> -Doug
>
>
>

  reply	other threads:[~2016-05-06  4:55 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-04 14:13 [PATCH v7 0/9] add i2c driver supported for rk3399 David Wu
2016-05-04 14:13 ` David Wu
2016-05-04 14:13 ` David Wu
2016-05-04 14:13 ` [PATCH v7 1/9] i2c: rk3x: add documentation to fields in "struct rk3x_i2c" David Wu
2016-05-04 14:13   ` David Wu
     [not found]   ` <1462371194-5809-2-git-send-email-david.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2016-05-04 23:45     ` Doug Anderson
2016-05-04 23:45       ` Doug Anderson
2016-05-04 23:45       ` Doug Anderson
2016-05-04 23:50       ` Doug Anderson
2016-05-04 23:50         ` Doug Anderson
2016-05-04 14:13 ` [PATCH v7 2/9] i2c: rk3x: use struct "rk3x_i2c_calced_timings" David Wu
2016-05-04 14:13   ` David Wu
     [not found]   ` <1462371194-5809-3-git-send-email-david.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2016-05-05 22:55     ` Doug Anderson
2016-05-05 22:55       ` Doug Anderson
2016-05-05 22:55       ` Doug Anderson
2016-05-06  2:19       ` David.Wu
2016-05-06  2:19         ` David.Wu
2016-05-04 14:13 ` [PATCH v7 3/9] i2c: rk3x: Remove redundant rk3x_i2c_clean_ipd() David Wu
2016-05-04 14:13   ` David Wu
2016-05-05 22:55   ` Doug Anderson
2016-05-05 22:55     ` Doug Anderson
2016-05-04 14:13 ` [PATCH v7 4/9] i2c: rk3x: Move setting STATE_START and add STATE_SETUP David Wu
2016-05-04 14:13   ` David Wu
2016-05-05 22:56   ` Doug Anderson
2016-05-05 22:56     ` Doug Anderson
2016-05-06  3:20     ` David.Wu
2016-05-06  3:20       ` David.Wu
2016-05-04 14:33 ` [PATCH v7 5/9] i2c: rk3x: Change SoC data to not use array David Wu
2016-05-04 14:33   ` David Wu
     [not found]   ` <1462372418-6349-1-git-send-email-david.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2016-05-05 21:36     ` Heiko Stübner
2016-05-05 21:36       ` Heiko Stübner
2016-05-05 21:36       ` Heiko Stübner
2016-05-05 22:57     ` Doug Anderson
2016-05-05 22:57       ` Doug Anderson
2016-05-05 22:57       ` Doug Anderson
2016-05-04 14:34 ` [PATCH v7 6/9] i2c: rk3x: Move spec timing data to "static const" structs David Wu
2016-05-04 14:34   ` David Wu
2016-05-05 22:58   ` Doug Anderson
2016-05-05 22:58     ` Doug Anderson
2016-05-06  4:55     ` David.Wu [this message]
2016-05-06  4:55       ` David.Wu
2016-05-04 14:35 ` [PATCH v7 7/9] dt-bindings: i2c: rk3x: add support for rk3399 David Wu
2016-05-04 14:35   ` David Wu
2016-05-05 22:12   ` Rob Herring
2016-05-05 22:12     ` Rob Herring
2016-05-06  6:09     ` David.Wu
2016-05-06  6:09       ` David.Wu
2016-05-05 22:59   ` Doug Anderson
2016-05-05 22:59     ` Doug Anderson
2016-05-04 14:36 ` [PATCH v7 8/9] i2c: rk3x: add i2c support for rk3399 soc David Wu
2016-05-04 14:36   ` David Wu
     [not found]   ` <1462372609-6535-1-git-send-email-david.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2016-05-05 23:00     ` Doug Anderson
2016-05-05 23:00       ` Doug Anderson
2016-05-05 23:00       ` Doug Anderson
2016-05-06  9:32       ` David.Wu
2016-05-06  9:32         ` David.Wu
2016-05-06 18:00         ` Doug Anderson
2016-05-06 18:00           ` Doug Anderson
2016-05-04 14:37 ` [PATCH v7 9/9] i2c: rk3x: support fast-mode plus for rk3399 David Wu
2016-05-04 14:37   ` David Wu
2016-05-05 23:02   ` Doug Anderson
2016-05-05 23:02     ` Doug Anderson
2016-05-06  2:12     ` David.Wu
2016-05-06  2:12       ` David.Wu

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=572C23B3.6090702@rock-chips.com \
    --to=david.wu@rock-chips.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=briannorris@google.com \
    --cc=cf@rock-chips.com \
    --cc=davidriley@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=galak@codeaurora.org \
    --cc=heiko@sntech.de \
    --cc=hl@rock-chips.com \
    --cc=huangtao@rock-chips.com \
    --cc=ijc+devicetree@hellion.org.uk \
    --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=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=wsa@the-dreams.de \
    --cc=xjq@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.