This largely reverts commit 5a7b95fb993ec399c8a685552aa6a8fc995c40bd. It
breaks suspend with AMD GPUs, and we couldn't incrementally fix it. So,
let's remove the code and go back to the drawing board. We keep the
header extension to not break drivers already populating the regulator.
We expect to re-add the code handling it soon.
Reported-by: "Tareque Md.Hanif" <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reported-by: Konstantin Kharlamov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1850
Signed-off-by: Wolfram Sang <[email protected]>
---
So far, I tested it on a Renesas R-Car M3-N board verifying that I2C
still works. I'll apply it to my for-next branch right away to get the
buildbots involved as well. But I am still open for comments until I
apply it to my for-current branch, probably tomorrow.
drivers/i2c/i2c-core-base.c | 95 -------------------------------------
1 file changed, 95 deletions(-)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index f193f9058584..73253e667de1 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -466,14 +466,12 @@ static int i2c_smbus_host_notify_to_irq(const struct i2c_client *client)
static int i2c_device_probe(struct device *dev)
{
struct i2c_client *client = i2c_verify_client(dev);
- struct i2c_adapter *adap;
struct i2c_driver *driver;
int status;
if (!client)
return 0;
- adap = client->adapter;
client->irq = client->init_irq;
if (!client->irq) {
@@ -539,14 +537,6 @@ static int i2c_device_probe(struct device *dev)
dev_dbg(dev, "probe\n");
- if (adap->bus_regulator) {
- status = regulator_enable(adap->bus_regulator);
- if (status < 0) {
- dev_err(&adap->dev, "Failed to enable bus regulator\n");
- goto err_clear_wakeup_irq;
- }
- }
-
status = of_clk_set_defaults(dev->of_node, false);
if (status < 0)
goto err_clear_wakeup_irq;
@@ -605,10 +595,8 @@ static int i2c_device_probe(struct device *dev)
static void i2c_device_remove(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
- struct i2c_adapter *adap;
struct i2c_driver *driver;
- adap = client->adapter;
driver = to_i2c_driver(dev->driver);
if (driver->remove) {
int status;
@@ -623,8 +611,6 @@ static void i2c_device_remove(struct device *dev)
devres_release_group(&client->dev, client->devres_group_id);
dev_pm_domain_detach(&client->dev, !i2c_acpi_waive_d0_probe(dev));
- if (!pm_runtime_status_suspended(&client->dev) && adap->bus_regulator)
- regulator_disable(adap->bus_regulator);
dev_pm_clear_wake_irq(&client->dev);
device_init_wakeup(&client->dev, false);
@@ -634,86 +620,6 @@ static void i2c_device_remove(struct device *dev)
pm_runtime_put(&client->adapter->dev);
}
-#ifdef CONFIG_PM_SLEEP
-static int i2c_resume_early(struct device *dev)
-{
- struct i2c_client *client = i2c_verify_client(dev);
- int err;
-
- if (!client)
- return 0;
-
- if (pm_runtime_status_suspended(&client->dev) &&
- client->adapter->bus_regulator) {
- err = regulator_enable(client->adapter->bus_regulator);
- if (err)
- return err;
- }
-
- return pm_generic_resume_early(&client->dev);
-}
-
-static int i2c_suspend_late(struct device *dev)
-{
- struct i2c_client *client = i2c_verify_client(dev);
- int err;
-
- if (!client)
- return 0;
-
- err = pm_generic_suspend_late(&client->dev);
- if (err)
- return err;
-
- if (!pm_runtime_status_suspended(&client->dev) &&
- client->adapter->bus_regulator)
- return regulator_disable(client->adapter->bus_regulator);
-
- return 0;
-}
-#endif
-
-#ifdef CONFIG_PM
-static int i2c_runtime_resume(struct device *dev)
-{
- struct i2c_client *client = i2c_verify_client(dev);
- int err;
-
- if (!client)
- return 0;
-
- if (client->adapter->bus_regulator) {
- err = regulator_enable(client->adapter->bus_regulator);
- if (err)
- return err;
- }
-
- return pm_generic_runtime_resume(&client->dev);
-}
-
-static int i2c_runtime_suspend(struct device *dev)
-{
- struct i2c_client *client = i2c_verify_client(dev);
- int err;
-
- if (!client)
- return 0;
-
- err = pm_generic_runtime_suspend(&client->dev);
- if (err)
- return err;
-
- if (client->adapter->bus_regulator)
- return regulator_disable(client->adapter->bus_regulator);
- return 0;
-}
-#endif
-
-static const struct dev_pm_ops i2c_device_pm = {
- SET_LATE_SYSTEM_SLEEP_PM_OPS(i2c_suspend_late, i2c_resume_early)
- SET_RUNTIME_PM_OPS(i2c_runtime_suspend, i2c_runtime_resume, NULL)
-};
-
static void i2c_device_shutdown(struct device *dev)
{
struct i2c_client *client = i2c_verify_client(dev);
@@ -773,7 +679,6 @@ struct bus_type i2c_bus_type = {
.probe = i2c_device_probe,
.remove = i2c_device_remove,
.shutdown = i2c_device_shutdown,
- .pm = &i2c_device_pm,
};
EXPORT_SYMBOL_GPL(i2c_bus_type);
--
2.30.2
On Fri, 2022-01-07 at 21:20 +0300, Konstantin Kharlamov wrote:
> Thank you! I tested it (had to resolve a small conflict), works for me. So, in
> case you need it, the patch is
>
> Tested-by: Konstantin Kharlamov <[email protected]>
>
> By the way, shouldn't the patch include a field
>
> Cc: <[email protected]> # 5.14+
>
> ?
>
> P.S.: sorry, for all mangled up CC fields. For some reason I didn't get your
> email, I found this patch in the archive. And the mbox that archive provides
> breaks all TO and CC fields, so I manually restored addresses that I have.
Restored the fields now, sorry, I found the mail, it was moved to another folder by a filter
On Thu, Jan 06, 2022 at 01:24:52PM +0100, Wolfram Sang wrote:
> This largely reverts commit 5a7b95fb993ec399c8a685552aa6a8fc995c40bd. It
> breaks suspend with AMD GPUs, and we couldn't incrementally fix it. So,
> let's remove the code and go back to the drawing board. We keep the
> header extension to not break drivers already populating the regulator.
> We expect to re-add the code handling it soon.
>
> Reported-by: "Tareque Md.Hanif" <[email protected]>
> Link: https://lore.kernel.org/r/[email protected]
> Reported-by: Konstantin Kharlamov <[email protected]>
> Link: https://lore.kernel.org/r/[email protected]
> BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1850
> Signed-off-by: Wolfram Sang <[email protected]>
Applied to for-current, thanks!
Hi everyone,
On Thu, Jan 06, 2022 at 01:24:52PM +0100, Wolfram Sang wrote:
> This largely reverts commit 5a7b95fb993ec399c8a685552aa6a8fc995c40bd. It
> breaks suspend with AMD GPUs, and we couldn't incrementally fix it. So,
> let's remove the code and go back to the drawing board. We keep the
> header extension to not break drivers already populating the regulator.
> We expect to re-add the code handling it soon.
>
> Reported-by: "Tareque Md.Hanif" <[email protected]>
> Link: https://lore.kernel.org/r/[email protected]
> Reported-by: Konstantin Kharlamov <[email protected]>
> Link: https://lore.kernel.org/r/[email protected]
> BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1850
> Signed-off-by: Wolfram Sang <[email protected]>
So, it has been reverted now. Is someone of the original patch
submitters interested in re-adding it? And would the reporters of the
regression be available for further testing?
Thanks and happy hacking,
Wolfram
On Wed, 2022-01-12 at 10:32 +0100, Wolfram Sang wrote:
> Hi everyone,
>
> On Thu, Jan 06, 2022 at 01:24:52PM +0100, Wolfram Sang wrote:
> > This largely reverts commit 5a7b95fb993ec399c8a685552aa6a8fc995c40bd. It
> > breaks suspend with AMD GPUs, and we couldn't incrementally fix it. So,
> > let's remove the code and go back to the drawing board. We keep the
> > header extension to not break drivers already populating the regulator.
> > We expect to re-add the code handling it soon.
> >
> > Reported-by: "Tareque Md.Hanif" <[email protected]>
> > Link:
> > https://lore.kernel.org/r/[email protected]
> > Reported-by: Konstantin Kharlamov <[email protected]>
> > Link:
> > https://lore.kernel.org/r/[email protected]
> > BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1850
> > Signed-off-by: Wolfram Sang <[email protected]>
>
> So, it has been reverted now. Is someone of the original patch
> submitters interested in re-adding it? And would the reporters of the
> regression be available for further testing?
I am available for further testing.
> Thanks and happy hacking,
>
> Wolfram
>
hi Konstantin and Tareque,
Can you help provide logs if we apply
5a7b95fb993ec399c8a685552aa6a8fc995c40bd but revert
8d35a2596164c1c9d34d4656fd42b445cd1e247f?
Thanks
On Wed, Jan 12, 2022 at 6:02 PM Tareque Md Hanif
<[email protected]> wrote:
>
>
> On 1/12/22 15:51, Wolfram Sang wrote:
> > would the reporters of the
> > regression be available for further testing?
> Sure. I am available.
On Wed, Jan 12, 2022 at 6:58 PM Hsin-Yi Wang <[email protected]> wrote:
>
> hi Konstantin and Tareque,
>
> Can you help provide logs if we apply
> 5a7b95fb993ec399c8a685552aa6a8fc995c40bd but revert
> 8d35a2596164c1c9d34d4656fd42b445cd1e247f?
>
Another thing might be helpful to test with:
after apply 5a7b95fb993ec399c8a685552aa6a8fc995c40bd
1. delete SET_LATE_SYSTEM_SLEEP_PM_OPS(i2c_suspend_late,
i2c_resume_early) and function i2c_suspend_late() and
i2c_resume_early().
2. delete SET_RUNTIME_PM_OPS(i2c_runtime_suspend, i2c_runtime_resume,
NULL) and function i2c_runtime_suspend() and i2c_runtime_resume().
Does it still fail if we do 1 or 2?
Sorry that we don't have a platform with intel CPU and amd GPU
combination to test with.
> Thanks
>
> On Wed, Jan 12, 2022 at 6:02 PM Tareque Md Hanif
> <[email protected]> wrote:
> >
> >
> > On 1/12/22 15:51, Wolfram Sang wrote:
> > > would the reporters of the
> > > regression be available for further testing?
> > Sure. I am available.
hi Tareque,
On Fri, Jan 14, 2022 at 6:09 PM Tareque Md Hanif
<[email protected]> wrote:
>
> Hi Hsin-Yi,
>
> On 1/12/22 16:58, Hsin-Yi Wang wrote:
>
> Can you help provide logs if we apply
> 5a7b95fb993ec399c8a685552aa6a8fc995c40bd but revert
> 8d35a2596164c1c9d34d4656fd42b445cd1e247f?
>
> Issue still exists. journalctl log attached in revert_8d.txt
>
>
> > after apply 5a7b95fb993ec399c8a685552aa6a8fc995c40bd
> > 1. delete SET_LATE_SYSTEM_SLEEP_PM_OPS(i2c_suspend_late,
> > i2c_resume_early) and function i2c_suspend_late() and
> > i2c_resume_early().
>
> No issues. journalctl log attached in test1.txt
>
>
> > 2. delete SET_RUNTIME_PM_OPS(i2c_runtime_suspend, i2c_runtime_resume,
> > NULL) and function i2c_runtime_suspend() and i2c_runtime_resume().
>
> Issue exists. journalctl log attached in test2.txt
Thanks for the testing.
Can you help us test if applying the following patch on top of
5a7b95fb993ec399c8a685552aa6a8fc995c40bd works? Thanks
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 9eb4009cb250..6b046012aa08 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -484,7 +484,7 @@ static int i2c_resume_early(struct device *dev)
struct i2c_client *client = i2c_verify_client(dev);
int err;
- if (!client)
+ if (!client || dev_pm_skip_resume(dev))
return 0;
if (pm_runtime_status_suspended(&client->dev) &&
@@ -502,7 +502,7 @@ static int i2c_suspend_late(struct device *dev)
struct i2c_client *client = i2c_verify_client(dev);
int err;
- if (!client)
+ if (!client || dev_pm_skip_suspend(dev))
return 0;
err = pm_generic_suspend_late(&client->dev);
On Sun, Jan 16, 2022 at 2:44 AM Tareque Md.Hanif
<[email protected]> wrote:
>
> Hi Hsin-Yi,
>
> The issue still exists. I reverted a19f75de73c220b4496d2aefb7a605dd032f7c01 (the commit that reverted 5a7b95fb993ec399c8a685552aa6a8fc995c40bd) and manually applied the patch (tags/v5.16). journalctl attached.
hi Tareque,
Can you apply the same setting[1] again and with this patch to see if
the issue is still there?
https://github.com/torvalds/linux/commit/6dc8265f9803ccb7e5da804e01601f0c14f270e0
[1] reverted a19f75de73c220b4496d2aefb7a605dd032f7c01 (the commit that
reverted 5a7b95fb993ec399c8a685552aa6a8fc995c40bd) and manually
applied the patch (tags/v5.16)
Thanks
>
> Regards,
>
> Tareque
>
> On Saturday, January 15, 2022, 11:27:07 PM GMT+6, Hsin-Yi Wang <[email protected]> wrote:
>
>
> hi Tareque,
>
>
> On Fri, Jan 14, 2022 at 6:09 PM Tareque Md Hanif
> <[email protected]> wrote:
> >
> > Hi Hsin-Yi,
> >
> > On 1/12/22 16:58, Hsin-Yi Wang wrote:
> >
> > Can you help provide logs if we apply
> > 5a7b95fb993ec399c8a685552aa6a8fc995c40bd but revert
> > 8d35a2596164c1c9d34d4656fd42b445cd1e247f?
> >
> > Issue still exists. journalctl log attached in revert_8d.txt
> >
> >
> > > after apply 5a7b95fb993ec399c8a685552aa6a8fc995c40bd
> > > 1. delete SET_LATE_SYSTEM_SLEEP_PM_OPS(i2c_suspend_late,
> > > i2c_resume_early) and function i2c_suspend_late() and
> > > i2c_resume_early().
> >
> > No issues. journalctl log attached in test1.txt
> >
> >
> > > 2. delete SET_RUNTIME_PM_OPS(i2c_runtime_suspend, i2c_runtime_resume,
> > > NULL) and function i2c_runtime_suspend() and i2c_runtime_resume().
> >
> > Issue exists. journalctl log attached in test2.txt
>
>
> Thanks for the testing.
> Can you help us test if applying the following patch on top of
> 5a7b95fb993ec399c8a685552aa6a8fc995c40bd works? Thanks
>
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index 9eb4009cb250..6b046012aa08 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -484,7 +484,7 @@ static int i2c_resume_early(struct device *dev)
> struct i2c_client *client = i2c_verify_client(dev);
> int err;
>
> - if (!client)
> + if (!client || dev_pm_skip_resume(dev))
> return 0;
>
> if (pm_runtime_status_suspended(&client->dev) &&
> @@ -502,7 +502,7 @@ static int i2c_suspend_late(struct device *dev)
> struct i2c_client *client = i2c_verify_client(dev);
> int err;
>
> - if (!client)
> + if (!client || dev_pm_skip_suspend(dev))
> return 0;
>
> err = pm_generic_suspend_late(&client->dev);
>
On Fri, Feb 04, 2022 at 07:22:44PM +0000, Tareque Md.Hanif wrote:
> The issue still exists. It takes very long time to suspend (10-12s). `DRI_PRIME=1 glxgears` is a black window.
>
> journalctl attached
> Looking forward to any testing.
Any new ideas which Tareque could test?
On Fri, Feb 11, 2022 at 12:51 PM Wolfram Sang <[email protected]> wrote:
>
> On Fri, Feb 04, 2022 at 07:22:44PM +0000, Tareque Md.Hanif wrote:
> > The issue still exists. It takes very long time to suspend (10-12s). `DRI_PRIME=1 glxgears` is a black window.
> >
> > journalctl attached
> > Looking forward to any testing.
>
> Any new ideas which Tareque could test?
For some background, the GPU has multiple i2c buses attached to it
which the driver uses for querying the EDID on monitors over i2c.
Although in this case, the i2c buses are not used because there is no
display controller on this particular GPU. I'm not even sure if the
gpu driver exposes any i2c buses in this case. The i2c buses present
are in a vbios table that the driver parses at load time. If there
are none on your platform, then it's probably not the AMD GPU driver.
Can you check if there are any i2c buses from the AMD GPU device in
sysfs? I don't really see why this patch would change anything off
hand on the GPU. Maybe the GPU is a red herring. No one reported any
regressions on systems with AMD CPUs or even other Intel CPUs. This
seems to be specific to a particular Intel CPU + AMD Topaz GPUs. The
dGPU power is controlled by the platform via ACPI (it's usually a GPIO
under the covers). I wonder if the issue is related to one of the i2c
buses or devices on the intel platform? E.g.,
00:15.0 Signal processing controller: Intel Corporation Sunrise
Point-LP Serial IO I2C Controller #0 (rev 21)
00:15.1 Signal processing controller: Intel Corporation Sunrise
Point-LP Serial IO I2C Controller #1 (rev 21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
I'm not sure what those do, but maybe that is something to look at?
Also there are some PCI AERs in the kernel log. Are those present
without the patch?
Alex