From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: warp5tw@gmail.com
Cc: avifishman70@gmail.com, tmaimon77@gmail.com,
tali.perry1@gmail.com, venture@google.com, yuenn@google.com,
benjaminfair@google.com, andi.shyti@kernel.org, wsa@kernel.org,
rand.sec96@gmail.com, wsa+renesas@sang-engineering.com,
tali.perry@nuvoton.com, Avi.Fishman@nuvoton.com,
tomer.maimon@nuvoton.com, KWLIU@nuvoton.com, JJLIU0@nuvoton.com,
kfting@nuvoton.com, openbmc@lists.ozlabs.org,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 5/6] i2c: npcm: use i2c frequency table
Date: Fri, 13 Sep 2024 13:39:29 +0300 [thread overview]
Message-ID: <ZuQWYabomv_xyYyj@smile.fi.intel.com> (raw)
In-Reply-To: <20240913101445.16513-6-kfting@nuvoton.com>
On Fri, Sep 13, 2024 at 06:14:45PM +0800, warp5tw@gmail.com wrote:
> From: Tyrone Ting <kfting@nuvoton.com>
>
> Modify i2c frequency from table parameters
> for NPCM i2c modules.
>
> Supported frequencies are:
>
> 1. 100KHz
> 2. 400KHz
> 3. 1MHz
>
> The original equations were tested on a variety of chips and base clocks.
> Since we added devices that use higher frequencies of the module we
> saw that there is a mismatch between the equation and the actual
> results on the bus itself, measured on scope.
>
> Meanwhile, the equations were not accurate to begin with.
> They are an approximation of the ideal value. The ideal value is
> calculated per frequency of the core module.
>
> So instead of using the equations we did an optimization per module
> frequency, verified on a device.
>
> Most of the work was focused on the rise time of the SCL and SDA,
> which depends on external load of the bus and PU.
>
> Different PCB designs, or specifically to this case: the number
> and type of targets on the bus, impact the required values for
> the timing registers.
>
> Users can recalculate the numbers for each bus and get an even better
> optimization, but our users chose not to.
>
> We manually picked values per frequency that match the entire valid
> range of targets (from 1 to max number). Then we check against the
> AMR described in SMB spec and make sure that none of the values
> is exceeding.
>
> This process was led by the chip architect and included a lot of testing.
...
> + {.core_clk = 100000000, .hldt = 0x2A, .dbcnt = 0x4, .sclfrq = 0xFB, .scllt = 0x0,
> + .sclht = 0x0, .fast_mode = false },
It seems you have no leading space, while having trailing one. Also the split
seems a bit illogical to me, I would rather do like
{
.core_clk = 100000000, .hldt = 0x2A, .dbcnt = 0x4,
.sclfrq = 0xFB, .scllt = 0x0, .sclht = 0x0,
.fast_mode = false,
},
Yes, this takes more lines, but also more flexible to the updates in the
future. Also mind the trailing comma at the last member assignment.
...
> + for (scl_table_cnt = 0 ; scl_table_cnt < table_size ; scl_table_cnt++)
Extra spaces...
> + if (bus->apb_clk >= smb_timing[scl_table_cnt].core_clk)
> + break;
...
> /* bits [8:7] are in I2CCTL3 reg */
> - iowrite8(fast_mode | FIELD_PREP(I2CCTL3_SCLFRQ8_7, (sclfrq >> 7) & 0x3),
> + iowrite8(fast_mode | FIELD_PREP(I2CCTL3_SCLFRQ8_7, (smb_timing[scl_table_cnt].sclfrq >> 7)
> + & 0x3),
> bus->reg + NPCM_I2CCTL3);
This has broken (illogical) indentation. Consider
iowrite8(FIELD_PREP(I2CCTL3_SCLFRQ8_7, (smb_timing[scl_table_cnt].sclfrq >> 7) & 0x3) |
fast_mode,
bus->reg + NPCM_I2CCTL3);
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2024-09-13 10:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-13 10:14 [PATCH v3 0/6] i2c: npcm: Bug fixes read/write operation, checkpatch warp5tw
2024-09-13 10:14 ` [PATCH v3 1/6] i2c: npcm: correct the read/write operation procedure warp5tw
2024-09-13 10:14 ` [PATCH v3 2/6] i2c: npcm: use a software flag to indicate a BER condition warp5tw
2024-09-13 10:14 ` [PATCH v3 3/6] i2c: npcm: Modify timeout evaluation mechanism warp5tw
2024-09-13 10:14 ` [PATCH v3 4/6] i2c: npcm: Modify the client address assignment warp5tw
2024-09-13 10:32 ` Andy Shevchenko
2024-09-16 1:37 ` Tyrone Ting
2024-09-13 10:14 ` [PATCH v3 5/6] i2c: npcm: use i2c frequency table warp5tw
2024-09-13 10:39 ` Andy Shevchenko [this message]
2024-09-16 1:39 ` Tyrone Ting
2024-09-13 10:30 ` [PATCH v3 0/6] i2c: npcm: Bug fixes read/write operation, checkpatch Andy Shevchenko
2024-09-16 1:37 ` Tyrone Ting
2024-09-13 10:31 ` Andy Shevchenko
2024-09-16 1:35 ` Tyrone Ting
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=ZuQWYabomv_xyYyj@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=Avi.Fishman@nuvoton.com \
--cc=JJLIU0@nuvoton.com \
--cc=KWLIU@nuvoton.com \
--cc=andi.shyti@kernel.org \
--cc=avifishman70@gmail.com \
--cc=benjaminfair@google.com \
--cc=kfting@nuvoton.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=openbmc@lists.ozlabs.org \
--cc=rand.sec96@gmail.com \
--cc=tali.perry1@gmail.com \
--cc=tali.perry@nuvoton.com \
--cc=tmaimon77@gmail.com \
--cc=tomer.maimon@nuvoton.com \
--cc=venture@google.com \
--cc=warp5tw@gmail.com \
--cc=wsa+renesas@sang-engineering.com \
--cc=wsa@kernel.org \
--cc=yuenn@google.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