2020-06-23 02:55:27

by John Stultz

[permalink] [raw]
Subject: [PATCH] i2c: designware: Fix functionality in !CONFIG_ACPI case

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 <[email protected]>
Cc: Jarkko Nikula <[email protected]>
Cc: Wolfram Sang <[email protected]>
Cc: [email protected]
Fixes: f9288fcc5c615 ("i2c: designware: Move ACPI parts into common module")
Signed-off-by: John Stultz <[email protected]>
---
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


2020-06-23 08:04:01

by Jarkko Nikula

[permalink] [raw]
Subject: 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 <[email protected]>
> Cc: Jarkko Nikula <[email protected]>
> Cc: Wolfram Sang <[email protected]>
> Cc: [email protected]
> Fixes: f9288fcc5c615 ("i2c: designware: Move ACPI parts into common module")
> Signed-off-by: John Stultz <[email protected]>
> ---
> 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

2020-06-23 08:35:54

by Jarkko Nikula

[permalink] [raw]
Subject: 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

2020-06-23 08:49:49

by Andy Shevchenko

[permalink] [raw]
Subject: 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 <[email protected]>
> > Cc: Jarkko Nikula <[email protected]>
> > Cc: Wolfram Sang <[email protected]>
> > Cc: [email protected]
> > Fixes: f9288fcc5c615 ("i2c: designware: Move ACPI parts into common module")
> > Signed-off-by: John Stultz <[email protected]>
> > ---
> > 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