summaryrefslogtreecommitdiff
path: root/drivers/i2c/busses/i2c-designware-common.c
diff options
context:
space:
mode:
authorMichael Wu <michael.wu@kneron.us>2024-10-03 19:15:24 +0800
committerWolfram Sang <wsa+renesas@sang-engineering.com>2024-11-24 16:03:51 +0100
commit61ab42c7f32d6d881a62e5cf76c46f95cb7ca2bd (patch)
treeb067991424cb40f340524d17870b8cdaff87e5f8 /drivers/i2c/busses/i2c-designware-common.c
parentbbc89a6e837f291e7ad04cea50915c71110e781a (diff)
i2c: designware: determine HS tHIGH and tLOW based on HW parameters
In commit 35eba185fd1a ("i2c: designware: Calculate SCL timing parameter for High Speed Mode") the SCL high period count and low period count for high speed mode are calculated based on fixed tHIGH = 160 and tLOW = 120. However, the set of two fixed values is only applicable to the combination of hardware parameters IC_CAP_LOADING is 400 and IC_CLK_FREQ_OPTIMIZATION is true. Outside of this combination, the SCL frequency may not reach 3.4 MHz because the fixed tHIGH and tLOW are not small enough. If IC_CAP_LOADING is 400, it means the bus capacitance is 400pF; Otherwise, 100 pF. If IC_CLK_FREQ_OPTIMIZATION is true, it means that the hardware reduces its internal clock frequency by reducing the internal latency required to generate the high period and low period of the SCL line. Section 3.15.4.5 in DesignWare DW_apb_i2b Databook v2.03 says that when IC_CLK_FREQ_OPTIMIZATION = 0, MIN_SCL_HIGHtime = 60 ns for 3.4 Mbps, bus loading = 100pF = 120 ns for 3.4 Mbps, bus loading = 400pF MIN_SCL_LOWtime = 160 ns for 3.4 Mbps, bus loading = 100pF = 320 ns for 3.4 Mbps, bus loading = 400pF and section 3.15.4.6 says that when IC_CLK_FREQ_OPTIMIZATION = 1, MIN_SCL_HIGHtime = 60 ns for 3.4 Mbps, bus loading = 100pF = 160 ns for 3.4 Mbps, bus loading = 400pF MIN_SCL_LOWtime = 120 ns for 3.4 Mbps, bus loading = 100pF = 320 ns for 3.4 Mbps, bus loading = 400pF In order to calculate more accurate SCL high period count and low period count for high speed mode, two hardware parameters IC_CAP_LOADING and IC_CLK_FREQ_OPTIMIZATION must be considered together. Since there're no registers controlliing these these two hardware parameters, users can declare them in the device tree so that the driver can obtain them. Signed-off-by: Michael Wu <michael.wu@kneron.us> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Diffstat (limited to 'drivers/i2c/busses/i2c-designware-common.c')
-rw-r--r--drivers/i2c/busses/i2c-designware-common.c5
1 files changed, 5 insertions, 0 deletions
diff --git a/drivers/i2c/busses/i2c-designware-common.c b/drivers/i2c/busses/i2c-designware-common.c
index 443f946acf36..857783d458fb 100644
--- a/drivers/i2c/busses/i2c-designware-common.c
+++ b/drivers/i2c/busses/i2c-designware-common.c
@@ -382,6 +382,11 @@ int i2c_dw_fw_parse_and_configure(struct dw_i2c_dev *dev)
i2c_parse_fw_timings(device, t, false);
+ if (device_property_read_u32(device, "snps,bus-capacitance-pf", &dev->bus_capacitance_pF))
+ dev->bus_capacitance_pF = 100;
+
+ dev->clk_freq_optimized = device_property_read_bool(device, "snps,clk-freq-optimized");
+
i2c_dw_adjust_bus_speed(dev);
if (is_of_node(fwnode))