| Message ID | 20190619205009.4176588-1-taoren@fb.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] i2c: aspeed: allow to customize base clock divisor | expand |
On Wed, Jun 19, 2019 at 2:00 PM Tao Ren <taoren@fb.com> wrote: > > Some intermittent I2C transaction failures are observed on Facebook CMM and > Minipack (ast2500) BMC platforms, because slave devices (such as CPLD, BIC > and etc.) NACK the address byte sometimes. The issue can be resolved by > increasing base clock divisor which affects ASPEED I2C Controller's base > clock and other AC timing parameters. > > This patch allows to customize ASPEED I2C Controller's base clock divisor > in device tree. First off, are you sure you actually need this? You should be able to achieve an effectively equivalent result by just lowering the `bus-frequency` property specified in the DT. The `bus-frequency` property ultimately determines all the register values, and you should be able to set it to whatever you want by refering to the Aspeed documentation. Nevertheless, the code that determines the correct dividers from the frequency is based on the tables in the Aspeed documentation. I don't think the equation makes sense when the base_clk_divisor is fixed; I mean it will probably just set the other divisor to max or min depending on the values chosen. I think if someone really wants to program this parameter manually, they probably want to set the other parameters manually too. [snip]
On 6/19/19 2:25 PM, Brendan Higgins wrote: > On Wed, Jun 19, 2019 at 2:00 PM Tao Ren <taoren@fb.com> wrote: >> >> Some intermittent I2C transaction failures are observed on Facebook CMM and >> Minipack (ast2500) BMC platforms, because slave devices (such as CPLD, BIC >> and etc.) NACK the address byte sometimes. The issue can be resolved by >> increasing base clock divisor which affects ASPEED I2C Controller's base >> clock and other AC timing parameters. >> >> This patch allows to customize ASPEED I2C Controller's base clock divisor >> in device tree. > > First off, are you sure you actually need this? > > You should be able to achieve an effectively equivalent result by just > lowering the `bus-frequency` property specified in the DT. The > `bus-frequency` property ultimately determines all the register > values, and you should be able to set it to whatever you want by > refering to the Aspeed documentation. > > Nevertheless, the code that determines the correct dividers from the > frequency is based on the tables in the Aspeed documentation. I don't > think the equation makes sense when the base_clk_divisor is fixed; I > mean it will probably just set the other divisor to max or min > depending on the values chosen. I think if someone really wants to > program this parameter manually, they probably want to set the other > parameters manually too. Thank you for the quick response, Brendan. Aspeed I2C bus frequency is defined by 3 parameters (base_clk_divisor, clk_high_width, clk_low_width), and I choose base_clk_divisor because it controls all the Aspeed I2C timings (such as setup time and hold time). Once base_clk_divisor is decided (either by the current logic in i2c-aspeed driver or manually set in device tree), clk_high_width and clk_low_width will be calculated by i2c-aspeed driver to meet the specified I2C bus speed. For example, by setting I2C bus frequency to 100KHz on AST2500 platform, (base_clock_divisor, clk_high_width, clk_low_width) is set to (3, 15, 14) by our driver. But some slave devices (on CMM i2c-8 and Minipack i2c-0) NACK byte transactions with the default timing setting: the issue can be resolved by setting base_clk_divisor to 4, and (clk_high_width, clk_low_width) will be set to (7, 7) by our i2c-aspeed driver to achieve similar I2C bus speed. Not sure if my answer helps to address your concerns, but kindly let me know if you have further questions/suggestions. Thanks, Tao
On Wed, 2019-06-19 at 22:32 +0000, Tao Ren wrote: > Thank you for the quick response, Brendan. > > Aspeed I2C bus frequency is defined by 3 parameters > (base_clk_divisor, clk_high_width, clk_low_width), and I choose > base_clk_divisor because it controls all the Aspeed I2C timings (such > as setup time and hold time). Once base_clk_divisor is decided > (either by the current logic in i2c-aspeed driver or manually set in > device tree), clk_high_width and clk_low_width will be calculated by > i2c-aspeed driver to meet the specified I2C bus speed. > > For example, by setting I2C bus frequency to 100KHz on AST2500 > platform, (base_clock_divisor, clk_high_width, clk_low_width) is set > to (3, 15, 14) by our driver. But some slave devices (on CMM i2c-8 > and Minipack i2c-0) NACK byte transactions with the default timing > setting: the issue can be resolved by setting base_clk_divisor to 4, > and (clk_high_width, clk_low_width) will be set to (7, 7) by our i2c- > aspeed driver to achieve similar I2C bus speed. > > Not sure if my answer helps to address your concerns, but kindly let > me know if you have further questions/suggestions. Did you look at the resulting output on a scope ? I'm curious what might be wrong.... CCing Ryan from Aspeed, he might have some idea. Could it be that with some specific dividers you have more jitter ? Still, i2c devices tend to be rather robust vs crappy clocks unless you are massively out of bounds, which makes me wonder whether something else might be wrong in your setup. Cheers, Ben.
On 6/19/19 4:02 PM, Benjamin Herrenschmidt wrote: > On Wed, 2019-06-19 at 22:32 +0000, Tao Ren wrote: >> Thank you for the quick response, Brendan. >> >> Aspeed I2C bus frequency is defined by 3 parameters >> (base_clk_divisor, clk_high_width, clk_low_width), and I choose >> base_clk_divisor because it controls all the Aspeed I2C timings (such >> as setup time and hold time). Once base_clk_divisor is decided >> (either by the current logic in i2c-aspeed driver or manually set in >> device tree), clk_high_width and clk_low_width will be calculated by >> i2c-aspeed driver to meet the specified I2C bus speed. >> >> For example, by setting I2C bus frequency to 100KHz on AST2500 >> platform, (base_clock_divisor, clk_high_width, clk_low_width) is set >> to (3, 15, 14) by our driver. But some slave devices (on CMM i2c-8 >> and Minipack i2c-0) NACK byte transactions with the default timing >> setting: the issue can be resolved by setting base_clk_divisor to 4, >> and (clk_high_width, clk_low_width) will be set to (7, 7) by our i2c- >> aspeed driver to achieve similar I2C bus speed. >> >> Not sure if my answer helps to address your concerns, but kindly let >> me know if you have further questions/suggestions. > > Did you look at the resulting output on a scope ? I'm curious what > might be wrong.... > > CCing Ryan from Aspeed, he might have some idea. > > Could it be that with some specific dividers you have more jitter ? > Still, i2c devices tend to be rather robust vs crappy clocks unless you > are massively out of bounds, which makes me wonder whether something > else might be wrong in your setup. > > Cheers, > Ben. I've reached out to hardware team to see if they can provide more inputs (such as protocol decoder output) but so far I don't have such data. I'm suspecting it's caused by I2C timing mainly because: 1) the intermittent i2c transaction failures always happen to slave devices which are furthest away from ASPEED chip. 2) As the i2c-aspeed driver in my kernel 4.1 tree (derived from ASPEED SDK) works properly, and I copied I2CD04 (Clock and AC Timing Control) register value from kernel 4.1 and applied to the latest upstream driver: the transaction failure is fixed :) Thank you Ben for looking into the issue and involving more experts (Ryan) for discussion. I have been suffering from the problem for several months and I'm looking forward for proper/right solutions. Cheers, Tao
Hello Tao, Our recommend about clk divider setting is follow the datasheet clock setting table for clock divisor. Ryan -----Original Message----- From: Linux-aspeed [mailto:linux-aspeed-bounces+ryan_chen=aspeedtech.com@lists.ozlabs.org] On Behalf Of Tao Ren Sent: Thursday, June 20, 2019 6:33 AM To: Brendan Higgins <brendanhiggins@google.com> Cc: Mark Rutland <mark.rutland@arm.com>; devicetree <devicetree@vger.kernel.org>; linux-aspeed@lists.ozlabs.org; OpenBMC Maillist <openbmc@lists.ozlabs.org>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Rob Herring <robh+dt@kernel.org>; Linux ARM <linux-arm-kernel@lists.infradead.org>; linux-i2c@vger.kernel.org Subject: Re: [PATCH 1/2] i2c: aspeed: allow to customize base clock divisor On 6/19/19 2:25 PM, Brendan Higgins wrote: > On Wed, Jun 19, 2019 at 2:00 PM Tao Ren <taoren@fb.com> wrote: >> >> Some intermittent I2C transaction failures are observed on Facebook >> CMM and Minipack (ast2500) BMC platforms, because slave devices (such >> as CPLD, BIC and etc.) NACK the address byte sometimes. The issue can >> be resolved by increasing base clock divisor which affects ASPEED I2C >> Controller's base clock and other AC timing parameters. >> >> This patch allows to customize ASPEED I2C Controller's base clock >> divisor in device tree. > > First off, are you sure you actually need this? > > You should be able to achieve an effectively equivalent result by just > lowering the `bus-frequency` property specified in the DT. The > `bus-frequency` property ultimately determines all the register > values, and you should be able to set it to whatever you want by > refering to the Aspeed documentation. > > Nevertheless, the code that determines the correct dividers from the > frequency is based on the tables in the Aspeed documentation. I don't > think the equation makes sense when the base_clk_divisor is fixed; I > mean it will probably just set the other divisor to max or min > depending on the values chosen. I think if someone really wants to > program this parameter manually, they probably want to set the other > parameters manually too. Thank you for the quick response, Brendan. Aspeed I2C bus frequency is defined by 3 parameters (base_clk_divisor, clk_high_width, clk_low_width), and I choose base_clk_divisor because it controls all the Aspeed I2C timings (such as setup time and hold time). Once base_clk_divisor is decided (either by the current logic in i2c-aspeed driver or manually set in device tree), clk_high_width and clk_low_width will be calculated by i2c-aspeed driver to meet the specified I2C bus speed. For example, by setting I2C bus frequency to 100KHz on AST2500 platform, (base_clock_divisor, clk_high_width, clk_low_width) is set to (3, 15, 14) by our driver. But some slave devices (on CMM i2c-8 and Minipack i2c-0) NACK byte transactions with the default timing setting: the issue can be resolved by setting base_clk_divisor to 4, and (clk_high_width, clk_low_width) will be set to (7, 7) by our i2c-aspeed driver to achieve similar I2C bus speed. Not sure if my answer helps to address your concerns, but kindly let me know if you have further questions/suggestions. Thanks, Tao
On 6/20/19 12:29 AM, Ryan Chen wrote: > Hello Tao, > Our recommend about clk divider setting is follow the datasheet clock setting table for clock divisor. > > Ryan Thanks Ryan for the response. Could you also share some recommendations/hints on how to solve the intermittent i2c transaction failures on Facebook AST2500 BMC platforms? BTW, the patch is not aimed at modifying the existing formula of calculating clock settings in i2c-aspeed driver: people still get the recommended settings by default. The goal of the patch is to allow people to customize clock settings in case the default/recommended one doesn't work. Cheers, Tao
Hello Tao, Let me more clear. When you set (3, 15, 14) the device sometimes response nack. but when you set (4, 7, 7), the device always ack. Am I right? Ryan -----Original Message----- From: Tao Ren [mailto:taoren@fb.com] Sent: Thursday, June 20, 2019 3:57 PM To: Ryan Chen <ryan_chen@aspeedtech.com>; Brendan Higgins <brendanhiggins@google.com> Cc: Mark Rutland <mark.rutland@arm.com>; devicetree <devicetree@vger.kernel.org>; linux-aspeed@lists.ozlabs.org; OpenBMC Maillist <openbmc@lists.ozlabs.org>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Rob Herring <robh+dt@kernel.org>; Linux ARM <linux-arm-kernel@lists.infradead.org>; linux-i2c@vger.kernel.org Subject: Re: [PATCH 1/2] i2c: aspeed: allow to customize base clock divisor On 6/20/19 12:29 AM, Ryan Chen wrote: > Hello Tao, > Our recommend about clk divider setting is follow the datasheet clock setting table for clock divisor. > > Ryan Thanks Ryan for the response. Could you also share some recommendations/hints on how to solve the intermittent i2c transaction failures on Facebook AST2500 BMC platforms? BTW, the patch is not aimed at modifying the existing formula of calculating clock settings in i2c-aspeed driver: people still get the recommended settings by default. The goal of the patch is to allow people to customize clock settings in case the default/recommended one doesn't work. Cheers, Tao
On 6/20/19 1:01 AM, Ryan Chen wrote: > Hello Tao, > Let me more clear. When you set (3, 15, 14) the device sometimes response nack. > but when you set (4, 7, 7), the device always ack. Am I right? > Ryan Hello Ryan, It's correct. We have seen the problem on 2 Facebook BMC platforms so far. Given the other ~10 Facebook BMC platforms are still running kernel 4.1 (with (4, 7, 7) settings), I'd assume more platforms will be impacted after upgrading to the latest kernel. Thank you for spending time on this! Cheers, Tao
On 6/20/19 1:13 AM, Tao Ren wrote: > On 6/20/19 1:01 AM, Ryan Chen wrote: >> Hello Tao, >> Let me more clear. When you set (3, 15, 14) the device sometimes response nack. >> but when you set (4, 7, 7), the device always ack. Am I right? >> Ryan > > Hello Ryan, > > It's correct. We have seen the problem on 2 Facebook BMC platforms so far. Given the other ~10 Facebook BMC platforms are still running kernel 4.1 (with (4, 7, 7) settings), I'd assume more platforms will be impacted after upgrading to the latest kernel. > > Thank you for spending time on this! Just heads up Ryan and I are working with ODM vendors to collect scope output; will update back when we have new findings. Thank you all for spending time on this. Cheers, Tao
diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c index 6c8b38fd6e64..e4b1c4c71b62 100644 --- a/drivers/i2c/busses/i2c-aspeed.c +++ b/drivers/i2c/busses/i2c-aspeed.c @@ -145,7 +145,8 @@ struct aspeed_i2c_bus { spinlock_t lock; struct completion cmd_complete; u32 (*get_clk_reg_val)(struct device *dev, - u32 divisor); + u32 divisor, + u32 base_clk_div); unsigned long parent_clk_frequency; u32 bus_frequency; /* Transaction state. */ @@ -778,9 +779,10 @@ static const struct i2c_algorithm aspeed_i2c_algo = { static u32 aspeed_i2c_get_clk_reg_val(struct device *dev, u32 clk_high_low_mask, - u32 divisor) + u32 divisor, + u32 base_clk_divisor) { - u32 base_clk_divisor, clk_high_low_max, clk_high, clk_low, tmp; + u32 clk_high_low_max, clk_high, clk_low, tmp; /* * SCL_high and SCL_low represent a value 1 greater than what is stored @@ -809,10 +811,12 @@ static u32 aspeed_i2c_get_clk_reg_val(struct device *dev, * ((1 << base_clk_divisor) * (clk_high + 1 + clk_low + 1)) * The documentation recommends clk_high >= clk_high_max / 2 and * clk_low >= clk_low_max / 2 - 1 when possible; this last constraint - * gives us the following solution: + * gives us the following solution (unless base_clk_divisor is manually + * configured in device tree): */ - base_clk_divisor = divisor > clk_high_low_max ? - ilog2((divisor - 1) / clk_high_low_max) + 1 : 0; + if (base_clk_divisor > ASPEED_I2CD_TIME_BASE_DIVISOR_MASK) + base_clk_divisor = divisor > clk_high_low_max ? + ilog2((divisor - 1) / clk_high_low_max) + 1 : 0; if (base_clk_divisor > ASPEED_I2CD_TIME_BASE_DIVISOR_MASK) { base_clk_divisor = ASPEED_I2CD_TIME_BASE_DIVISOR_MASK; @@ -843,35 +847,49 @@ static u32 aspeed_i2c_get_clk_reg_val(struct device *dev, & ASPEED_I2CD_TIME_BASE_DIVISOR_MASK); } -static u32 aspeed_i2c_24xx_get_clk_reg_val(struct device *dev, u32 divisor) +static u32 aspeed_i2c_24xx_get_clk_reg_val(struct device *dev, + u32 divisor, + u32 base_clk_divisor) { /* * clk_high and clk_low are each 3 bits wide, so each can hold a max * value of 8 giving a clk_high_low_max of 16. */ - return aspeed_i2c_get_clk_reg_val(dev, GENMASK(2, 0), divisor); + return aspeed_i2c_get_clk_reg_val(dev, GENMASK(2, 0), divisor, + base_clk_divisor); } -static u32 aspeed_i2c_25xx_get_clk_reg_val(struct device *dev, u32 divisor) +static u32 aspeed_i2c_25xx_get_clk_reg_val(struct device *dev, + u32 divisor, + u32 base_clk_divisor) { /* * clk_high and clk_low are each 4 bits wide, so each can hold a max * value of 16 giving a clk_high_low_max of 32. */ - return aspeed_i2c_get_clk_reg_val(dev, GENMASK(3, 0), divisor); + return aspeed_i2c_get_clk_reg_val(dev, GENMASK(3, 0), divisor, + base_clk_divisor); } /* precondition: bus.lock has been acquired. */ -static int aspeed_i2c_init_clk(struct aspeed_i2c_bus *bus) +static int aspeed_i2c_init_clk(struct aspeed_i2c_bus *bus, + struct platform_device *pdev) { - u32 divisor, clk_reg_val; + int ret; + u32 divisor, clk_reg_val, base_clk_divisor; + + ret = of_property_read_u32(pdev->dev.of_node, "base-clock-divisor", + &base_clk_divisor); + if (ret < 0) + base_clk_divisor = (u32)-1; divisor = DIV_ROUND_UP(bus->parent_clk_frequency, bus->bus_frequency); clk_reg_val = readl(bus->base + ASPEED_I2C_AC_TIMING_REG1); clk_reg_val &= (ASPEED_I2CD_TIME_TBUF_MASK | ASPEED_I2CD_TIME_THDSTA_MASK | ASPEED_I2CD_TIME_TACST_MASK); - clk_reg_val |= bus->get_clk_reg_val(bus->dev, divisor); + clk_reg_val |= bus->get_clk_reg_val(bus->dev, divisor, + base_clk_divisor); writel(clk_reg_val, bus->base + ASPEED_I2C_AC_TIMING_REG1); writel(ASPEED_NO_TIMEOUT_CTRL, bus->base + ASPEED_I2C_AC_TIMING_REG2); @@ -888,7 +906,7 @@ static int aspeed_i2c_init(struct aspeed_i2c_bus *bus, /* Disable everything. */ writel(0, bus->base + ASPEED_I2C_FUN_CTRL_REG); - ret = aspeed_i2c_init_clk(bus); + ret = aspeed_i2c_init_clk(bus, pdev); if (ret < 0) return ret; @@ -989,7 +1007,7 @@ static int aspeed_i2c_probe_bus(struct platform_device *pdev) if (!match) bus->get_clk_reg_val = aspeed_i2c_24xx_get_clk_reg_val; else - bus->get_clk_reg_val = (u32 (*)(struct device *, u32)) + bus->get_clk_reg_val = (u32 (*)(struct device *, u32, u32)) match->data; /* Initialize the I2C adapter */
Some intermittent I2C transaction failures are observed on Facebook CMM and Minipack (ast2500) BMC platforms, because slave devices (such as CPLD, BIC and etc.) NACK the address byte sometimes. The issue can be resolved by increasing base clock divisor which affects ASPEED I2C Controller's base clock and other AC timing parameters. This patch allows to customize ASPEED I2C Controller's base clock divisor in device tree. Signed-off-by: Tao Ren <taoren@fb.com> --- drivers/i2c/busses/i2c-aspeed.c | 48 ++++++++++++++++++++++----------- 1 file changed, 33 insertions(+), 15 deletions(-)