I2C: Add real clock control

[omeh-a]

Currently the I2C driver has absolutely no idea how to set its timing. It depends on hard-coded constants to set clock dividers, and this means that the functionality of the I2C is now dependent on the system clocks being exactly what those hard-coded values are tuned for AND is fully insensitive to variations in device clocking.

This principally refers to the Meson I2C driver (as the only extant one), but this will be needed in general.

To solve this issue, a clock driver must be connected to I2C to allow it to detect the clock rate and tune itself OR the I2C must be given access to the relevant clocking hardware to set the divider values appropriately.

[terryzbai]

Now the clock driver #278 is ready to be used for dynamically configuring clock rates. As we don't have a complete clock management policy (e.g., which parent clock is better for the requested rate, what rate is compatible with multiple different requests, or what configurations would be beneficial for power saving) yet, the clients have to know which clock it wants to configure and the modification won't break other devices.

I saw the I2C clock is configured by setting QTR_CLK_DLY (i2c_regs->ctl) now. This should still be part of I2C driver, as the register is on I2C memory region and should not be touched by clock driver at all, but the rate ofclk81 (clock source of I2C clock) and the gate clock can be dynamically configured via clock driver.

[omeh-a]

Now the clock driver #278 is ready to be used for dynamically configuring clock rates. As we don't have a complete clock management policy (e.g., which parent clock is better for the requested rate, what rate is compatible with multiple different requests, or what configurations would be beneficial for power saving) yet, the clients have to know which clock it wants to configure and the modification won't break other devices.

I saw the I2C clock is configured by setting QTR_CLK_DLY (i2c_regs->ctl) now. This should still be part of I2C driver, as the register is on I2C memory region and should not be touched by clock driver at all, but the rate ofclk81 (clock source of I2C clock) and the gate clock can be dynamically configured via clock driver.

That's good news. Right now all that's needed is to have a known value of clk81 because all the clock divider values are completely arbitrary now based on the usual value set by U-boot. If we can read the rate, we can appropriately do the math to calculate the dividers properly

[terryzbai]

That's good news. Right now all that's needed is to have a known value of clk81 because all the clock divider values are completely arbitrary now based on the usual value set by U-boot. If we can read the rate, we can appropriately do the math to calculate the dividers properly

yea, the client interfaces (https://github.com/au-ts/sddf/blob/clk_driver/include/sddf/clk/client.h) are already provided to get/set rate. You can also check https://github.com/au-ts/sddf/blob/clk_driver/examples/clk/client.c to see how to use them.

[omeh-a]

Great. I can get onto solving this issue sometime next month unless somebody else gets it first

[terryzbai]

Great. I can get onto solving this issue sometime next month unless somebody else gets it first

I can replace clk81-related configurations with requests to clock driver now, so you will just need to do some math for I2C features.

[omeh-a]

Sure, just do so on a branch for this issue if you do please

[omeh-a]

Created 175-i2c-add-real-clock-control