* [PATCH] i2c: designware: Fix functionality in !CONFIG_ACPI case
@ 2020-06-23 2:51 John Stultz
2020-06-23 7:59 ` Jarkko Nikula
0 siblings, 1 reply; 4+ messages in thread
From: John Stultz @ 2020-06-23 2:51 UTC (permalink / raw)
To: lkml; +Cc: John Stultz, Andy Shevchenko, Jarkko Nikula, Wolfram Sang, linux-i2c
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 <andriy.shevchenko@linux.intel.com>
Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Cc: Wolfram Sang <wsa@kernel.org>
Cc: linux-i2c@vger.kernel.org
Fixes: f9288fcc5c615 ("i2c: designware: Move ACPI parts into common module")
Signed-off-by: John Stultz <john.stultz@linaro.org>
---
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 */
+
void i2c_dw_acpi_adjust_bus_speed(struct device *device)
{
struct dw_i2c_dev *dev = dev_get_drvdata(device);
@@ -317,8 +319,6 @@ void i2c_dw_acpi_adjust_bus_speed(struct device *device)
}
EXPORT_SYMBOL_GPL(i2c_dw_acpi_adjust_bus_speed);
-#endif /* CONFIG_ACPI */
-
u32 i2c_dw_scl_hcnt(u32 ic_clk, u32 tSYMBOL, u32 tf, int cond, int offset)
{
/*
diff --git a/drivers/i2c/busses/i2c-designware-core.h b/drivers/i2c/busses/i2c-designware-core.h
index 556673a1f61b..ea2485872cab 100644
--- a/drivers/i2c/busses/i2c-designware-core.h
+++ b/drivers/i2c/busses/i2c-designware-core.h
@@ -364,8 +364,7 @@ int i2c_dw_validate_speed(struct dw_i2c_dev *dev);
#if IS_ENABLED(CONFIG_ACPI)
int i2c_dw_acpi_configure(struct device *device);
-void i2c_dw_acpi_adjust_bus_speed(struct device *device);
#else
static inline int i2c_dw_acpi_configure(struct device *device) { return -ENODEV; }
-static inline void i2c_dw_acpi_adjust_bus_speed(struct device *device) {}
#endif
+void i2c_dw_acpi_adjust_bus_speed(struct device *device);
--
2.17.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] i2c: designware: Fix functionality in !CONFIG_ACPI case
2020-06-23 2:51 [PATCH] i2c: designware: Fix functionality in !CONFIG_ACPI case John Stultz
@ 2020-06-23 7:59 ` Jarkko Nikula
2020-06-23 8:33 ` Jarkko Nikula
2020-06-23 8:45 ` Andy Shevchenko
0 siblings, 2 replies; 4+ messages in thread
From: Jarkko Nikula @ 2020-06-23 7:59 UTC (permalink / raw)
To: John Stultz, lkml; +Cc: Andy Shevchenko, Wolfram Sang, linux-i2c
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 <andriy.shevchenko@linux.intel.com>
> Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>
> Cc: Wolfram Sang <wsa@kernel.org>
> Cc: linux-i2c@vger.kernel.org
> Fixes: f9288fcc5c615 ("i2c: designware: Move ACPI parts into common module")
> Signed-off-by: John Stultz <john.stultz@linaro.org>
> ---
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] i2c: designware: Fix functionality in !CONFIG_ACPI case
2020-06-23 7:59 ` Jarkko Nikula
@ 2020-06-23 8:33 ` Jarkko Nikula
2020-06-23 8:45 ` Andy Shevchenko
1 sibling, 0 replies; 4+ messages in thread
From: Jarkko Nikula @ 2020-06-23 8:33 UTC (permalink / raw)
To: John Stultz, lkml; +Cc: Andy Shevchenko, Wolfram Sang, linux-i2c
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] i2c: designware: Fix functionality in !CONFIG_ACPI case
2020-06-23 7:59 ` Jarkko Nikula
2020-06-23 8:33 ` Jarkko Nikula
@ 2020-06-23 8:45 ` Andy Shevchenko
1 sibling, 0 replies; 4+ messages in thread
From: Andy Shevchenko @ 2020-06-23 8:45 UTC (permalink / raw)
To: Jarkko Nikula; +Cc: John Stultz, lkml, Wolfram Sang, linux-i2c
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 <andriy.shevchenko@linux.intel.com>
> > Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>
> > Cc: Wolfram Sang <wsa@kernel.org>
> > Cc: linux-i2c@vger.kernel.org
> > Fixes: f9288fcc5c615 ("i2c: designware: Move ACPI parts into common module")
> > Signed-off-by: John Stultz <john.stultz@linaro.org>
> > ---
> > 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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-06-23 8:45 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-23 2:51 [PATCH] i2c: designware: Fix functionality in !CONFIG_ACPI case John Stultz
2020-06-23 7:59 ` Jarkko Nikula
2020-06-23 8:33 ` Jarkko Nikula
2020-06-23 8:45 ` Andy Shevchenko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).