Re: [PATCH] i2c: designware: Fix functionality in !CONFIG_ACPI case
On Tue, Jun 23, 2020 at 10:59:40AM +0300, Jarkko Nikula wrote: > Hi > > On 6/23/20 5:51 AM, John Stultz wrote: > > On the HiKey board, where CONFIG_ACPI is not set, we started > > to see a graphics regression where the adv7511 HDMI bridge driver > > wasn't probing. This was due to the i2c bus failing to start up. > > > > I bisected the problem down to commit f9288fcc5c615 ("i2c: > > designware: Move ACPI parts into common module") and after > > looking at it a bit, I realized that change moved some > > initialization into i2c_dw_acpi_adjust_bus_speed(). However, > > i2c_dw_acpi_adjust_bus_speed() is only functional if CONFIG_ACPI > > is set. > > > > This patch pulls i2c_dw_acpi_adjust_bus_speed() out of the > > ifdef CONFIG_ACPI conditional, and gets the board working again. > > > > Cc: Andy Shevchenko > > Cc: Jarkko Nikula > > Cc: Wolfram Sang > > Cc: linux-...@vger.kernel.org > > Fixes: f9288fcc5c615 ("i2c: designware: Move ACPI parts into common module") > > Signed-off-by: John Stultz > > --- > > drivers/i2c/busses/i2c-designware-common.c | 4 ++-- > > drivers/i2c/busses/i2c-designware-core.h | 3 +-- > > 2 files changed, 3 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/i2c/busses/i2c-designware-common.c > > b/drivers/i2c/busses/i2c-designware-common.c > > index e3a8640db7da..33de185e15f2 100644 > > --- a/drivers/i2c/busses/i2c-designware-common.c > > +++ b/drivers/i2c/busses/i2c-designware-common.c > > @@ -286,6 +286,8 @@ int i2c_dw_acpi_configure(struct device *device) > > } > > EXPORT_SYMBOL_GPL(i2c_dw_acpi_configure); > > +#endif /* CONFIG_ACPI */ > > + > > I think the regression is in these lines below that were moved from probe to > i2c_dw_acpi_adjust_bus_speed() and cause that neither "cloock-frequency" > device property or I2C_MAX_FAST_MODE_FREQ affect the bus speed when > CONFIG_ACPI is not set. > > + /* > +* Find bus speed from the "clock-frequency" device property, ACPI > +* or by using fast mode if neither is set. > +*/ > + if (acpi_speed && t->bus_freq_hz) > + t->bus_freq_hz = min(t->bus_freq_hz, acpi_speed); > + else if (acpi_speed || t->bus_freq_hz) > + t->bus_freq_hz = max(t->bus_freq_hz, acpi_speed); > + else > + t->bus_freq_hz = I2C_MAX_FAST_MODE_FREQ; > > Andy: what you think should the i2c_dw_acpi_adjust_bus_speed() fixed to > return adjusted speed or zero if not found (also for !CONFIG_ACPI) and move > above lines back to probe? It looks more clear to me that way and should fix > the regression I think. I have split it to two functions and renamed accordingly. Will send patch soon, after some testing. -- With Best Regards, Andy Shevchenko
Re: [PATCH] i2c: designware: Fix functionality in !CONFIG_ACPI case
On 6/23/20 10:59 AM, Jarkko Nikula wrote: Hi On 6/23/20 5:51 AM, John Stultz wrote: On the HiKey board, where CONFIG_ACPI is not set, we started to see a graphics regression where the adv7511 HDMI bridge driver wasn't probing. This was due to the i2c bus failing to start up. I bisected the problem down to commit f9288fcc5c615 ("i2c: designware: Move ACPI parts into common module") and after looking at it a bit, I realized that change moved some initialization into i2c_dw_acpi_adjust_bus_speed(). However, i2c_dw_acpi_adjust_bus_speed() is only functional if CONFIG_ACPI is set. This patch pulls i2c_dw_acpi_adjust_bus_speed() out of the ifdef CONFIG_ACPI conditional, and gets the board working again. Andy: what you think should the i2c_dw_acpi_adjust_bus_speed() fixed to return adjusted speed or zero if not found (also for !CONFIG_ACPI) and move above lines back to probe? It looks more clear to me that way and should fix the regression I think. Ok, I sent a patch what I was thinking. Care to test John does it fix the regression you are seeing? -- Jarkko
Re: [PATCH] i2c: designware: Fix functionality in !CONFIG_ACPI case
Hi On 6/23/20 5:51 AM, John Stultz wrote: On the HiKey board, where CONFIG_ACPI is not set, we started to see a graphics regression where the adv7511 HDMI bridge driver wasn't probing. This was due to the i2c bus failing to start up. I bisected the problem down to commit f9288fcc5c615 ("i2c: designware: Move ACPI parts into common module") and after looking at it a bit, I realized that change moved some initialization into i2c_dw_acpi_adjust_bus_speed(). However, i2c_dw_acpi_adjust_bus_speed() is only functional if CONFIG_ACPI is set. This patch pulls i2c_dw_acpi_adjust_bus_speed() out of the ifdef CONFIG_ACPI conditional, and gets the board working again. Cc: Andy Shevchenko Cc: Jarkko Nikula Cc: Wolfram Sang Cc: linux-...@vger.kernel.org Fixes: f9288fcc5c615 ("i2c: designware: Move ACPI parts into common module") Signed-off-by: John Stultz --- drivers/i2c/busses/i2c-designware-common.c | 4 ++-- drivers/i2c/busses/i2c-designware-core.h | 3 +-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/busses/i2c-designware-common.c b/drivers/i2c/busses/i2c-designware-common.c index e3a8640db7da..33de185e15f2 100644 --- a/drivers/i2c/busses/i2c-designware-common.c +++ b/drivers/i2c/busses/i2c-designware-common.c @@ -286,6 +286,8 @@ int i2c_dw_acpi_configure(struct device *device) } EXPORT_SYMBOL_GPL(i2c_dw_acpi_configure); +#endif /* CONFIG_ACPI */ + I think the regression is in these lines below that were moved from probe to i2c_dw_acpi_adjust_bus_speed() and cause that neither "cloock-frequency" device property or I2C_MAX_FAST_MODE_FREQ affect the bus speed when CONFIG_ACPI is not set. + /* +* Find bus speed from the "clock-frequency" device property, ACPI +* or by using fast mode if neither is set. +*/ + if (acpi_speed && t->bus_freq_hz) + t->bus_freq_hz = min(t->bus_freq_hz, acpi_speed); + else if (acpi_speed || t->bus_freq_hz) + t->bus_freq_hz = max(t->bus_freq_hz, acpi_speed); + else + t->bus_freq_hz = I2C_MAX_FAST_MODE_FREQ; Andy: what you think should the i2c_dw_acpi_adjust_bus_speed() fixed to return adjusted speed or zero if not found (also for !CONFIG_ACPI) and move above lines back to probe? It looks more clear to me that way and should fix the regression I think. -- Jarkko