[PATCH/RFC] i2c: sh_mobile: Switch R-Mobile A1/APE6 and SH-Mobile AG5 to new frequency calculation

Switch the R-Mobile A1, R-Mobile APE6, and SH-Mobile AG5 SoCs to the new
frequency calculation formula, to (a) avoid running the I2C bus too fast,
and (b) bring the low/high ratio closer to the recommended ratio 5/4.

Measurement results on R-Mobile APE6 and SH-Mobile AG5 (fck=104 MHz,
clks_per_count=2):
  100 kHz: 106 kHz LH=1.12 before, 99.6 kHz L/H=1.22 after
  400 kHz: 384 kHz LH=1.67 before, 392 kHz L/H=1.27 after

Measurement results on R-Mobile A1 (fck=49.5 MHz, clks_per_count=1):
  100 kHz: 106 kHz L/H=1.09 before, 99.6 kHz L/H=1.20 after

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Measurements after applying "[PATCH 1/3] ARM: dts: renesas: r8a73a4: Fix
external clocks and clock rate"[1].  Before, the clock rates were even
4% higher.

Notes:
  - fast_clock_dt_config is now unused, so I guess we should drop it,
    and rename v2_freq_calc_dt_config to fast_clock_dt_config?
  - The formulas in the documentation for R-Mobile A1 do not include the
    "-1" and "-5", presumably this is for rounding?
  - The formulas in the documentation for SH-Mobile AG5 include
    the "-1" and "-5" in the example for 400 kHz, but not in the example
    for 100 kHz.
  - The SH-Mobile AG5 documentation suggests to use an L/H ratio of 5/3
    instead of 5/4 for 400 kHz, which means the old formula is better
    for 400 kHz?
  - Remaining users of the old formula are sh7343, sh7366, and sh772[234].
    At least for sh772[234], the "Transfer Rate" formula in the
    documentation is the same as for R-Mobile A1.  Hence probably we
    should switch the default_dt_config and the default fallback to the
    "v2" formula, too?
  - I am still a bit puzzled, as the "v2" formula introduced in commit
    4ecfb9d3b229fff5 ("i2c: sh_mobile: add new frequency calculation for
    later SoC") is basically what the driver did before commit
    23a612916a51cc37 ("i2c: i2c-sh_mobile: optimize ICCH/ICCL values
    according to I2C bus speed")?

[1] https://lore.kernel.org/r/1692bc8cd465d62168cbf110522ad62a7af3f606.1705315614.git.geert+renesas@glider.be
---
 drivers/i2c/busses/i2c-sh_mobile.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Hi Geert,

On Mon, Jan 15, 2024 at 02:18:12PM +0100, Geert Uytterhoeven wrote:
> Switch the R-Mobile A1, R-Mobile APE6, and SH-Mobile AG5 SoCs to the new
> frequency calculation formula, to (a) avoid running the I2C bus too fast,
> and (b) bring the low/high ratio closer to the recommended ratio 5/4.
> 
> Measurement results on R-Mobile APE6 and SH-Mobile AG5 (fck=104 MHz,
> clks_per_count=2):
>   100 kHz: 106 kHz LH=1.12 before, 99.6 kHz L/H=1.22 after
>   400 kHz: 384 kHz LH=1.67 before, 392 kHz L/H=1.27 after
> 
> Measurement results on R-Mobile A1 (fck=49.5 MHz, clks_per_count=1):
>   100 kHz: 106 kHz L/H=1.09 before, 99.6 kHz L/H=1.20 after
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Looks good to me, and it seems to comply with the datasheets? (I haven't
checked)

> Notes:
>   - fast_clock_dt_config is now unused, so I guess we should drop it,
>     and rename v2_freq_calc_dt_config to fast_clock_dt_config?

Yes, we can (and should do that).

>   - The formulas in the documentation for R-Mobile A1 do not include the
>     "-1" and "-5", presumably this is for rounding?

Sounds reasonable. The formulas evolved over time :)

>   - The formulas in the documentation for SH-Mobile AG5 include
>     the "-1" and "-5" in the example for 400 kHz, but not in the example
>     for 100 kHz.

*shrug*

>   - The SH-Mobile AG5 documentation suggests to use an L/H ratio of 5/3
>     instead of 5/4 for 400 kHz, which means the old formula is better
>     for 400 kHz?

Both ratios are within the I2C specifications for minimum SCL lo/hi
time. 5/3 is a little further away from the minimum requirements, so
maybe a tad more robust. But both should work(tm).

>   - Remaining users of the old formula are sh7343, sh7366, and sh772[234].
>     At least for sh772[234], the "Transfer Rate" formula in the
>     documentation is the same as for R-Mobile A1.  Hence probably we
>     should switch the default_dt_config and the default fallback to the
>     "v2" formula, too?

I think we could. But touching old systems without testing and a need is
more risky than leaving them alone.

>   - I am still a bit puzzled, as the "v2" formula introduced in commit
>     4ecfb9d3b229fff5 ("i2c: sh_mobile: add new frequency calculation for
>     later SoC") is basically what the driver did before commit
>     23a612916a51cc37 ("i2c: i2c-sh_mobile: optimize ICCH/ICCL values
>     according to I2C bus speed")?

Interesting. I can't recall that I analyzed the back then existing
formula when I implemented v2. I recall that I used R-Car Gen2
datasheets as the reference. I probably thought those are the "new"
algorithms. I likely didn't have the old datasheets back then. Still,
my memory is not clear about this.

Obvious to say, this I2C core is not used anymore in newer R-Car SoCs.
So, I won't dive too deep into it...

Happy hacking,

   Wolfram