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

[Wolfram Sang <wsa+renesas@sang-engineering.com>]

[-- Attachment #1: Type: text/plain, Size: 2953 bytes --]

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]