radeon vs radeonfb Mobility quirks (Thinkpad X32)

My Thinkpad X32 (r100, Mobility M6) can't suspend or hibernate
with KMS using the "radeon" driver.  "radeonfb" and the VESA
fallback (no KMS) are both fine.

It seems to be the same bug as:
https://bugs.freedesktop.org/show_bug.cgi?id8554
http://bugs.debian.org/cgi-bin/bugreport.cgi?bugX3120

The problem manifests in the console and inside X11,
and with 0 or 3 in /proc/sys/kernel/acpi_video_flags.
"radeontool light off" to disable the backlight doesn't
help, either (no VGA plugged in)

Looking at drivers/video/fbdev/aty/radeon_pm.c, I notice it sets
a D2 sleep mode for my X32:

	BUGFIX("IBM Thinkpad X31/X32",
	       PCI_VENDOR_ID_IBM, 0x052f,
	       radeon_pm_d2, NULL),

Which I suspect is what allows "radeonfb" to work for me

But I can't find the corresponding quirk in drivers/gpu/drm/radeon/,
so I now believe a missing quirk is the cause of this problem
with the "radeon" driver.

I poked around but couldn't figure out what changes to make to
the "radeon" driver to enable the corresponding, but I'm willing
to test patches.

Setting "dynpm" in /sys/**/power_method didn't seem to change
things, either.

Help greatly appreaciated.  Thanks


I've mainly been using the X32 as a server this decade so didn't
use suspend/hibernate so I didn't investigate until recently
(because my netbook died).

On Sun, 2018-11-04 at 04:23 +0000, Eric Wong wrote:

Looking at drivers/video/fbdev/aty/radeon_pm.c, I notice it sets
a D2 sleep mode for my X32:

        BUGFIX("IBM Thinkpad X31/X32",
               PCI_VENDOR_ID_IBM, 0x052f,
               radeon_pm_d2, NULL),

Which I suspect is what allows "radeonfb" to work for me

But I can't find the corresponding quirk in drivers/gpu/drm/radeon/,
so I now believe a missing quirk is the cause of this problem
with the "radeon" driver.

I poked around but couldn't figure out what changes to make to
the "radeon" driver to enable the corresponding, but I'm willing
to test patches.

Setting "dynpm" in /sys/**/power_method didn't seem to change
things, either.

Help greatly appreaciated.  Thanks


I've mainly been using the X32 as a server this decade so didn't
use suspend/hibernate so I didn't investigate until recently
(because my netbook died).

There's a whole pile of power management stuff for ancient laptops that
never quite made it from radeonfb to the radeon DRM driver... sadly it
also prevents sleep on old PowerBooks but I haven't had many complaints
so...

The code for D2 and D3 on those old things is reasonably self
contained, it shouldn't be that hard to move it over I suppose.

Cheers,
Ben.

Benjamin Herrenschmidt [off-list ref] wrote:

There's a whole pile of power management stuff for ancient laptops that
never quite made it from radeonfb to the radeon DRM driver... sadly it
also prevents sleep on old PowerBooks but I haven't had many complaints
so...

Thanks for the confirmation that stuff is missing from the DRM driver.

The code for D2 and D3 on those old things is reasonably self
contained, it shouldn't be that hard to move it over I suppose.

I started working on the following (dirty) patch for my X32,
but hasn't made a difference with just PCI_D2:

diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c
index 59c8a6647ff2..acc587b18ad2 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c

@@ -1548,6 +1548,23 @@ void radeon_device_fini(struct radeon_device *rdev)
 		radeon_doorbell_fini(rdev);
 }
 
+/* XXX copy of radeonfb_whack_power_state */
+static void radeon_whack_power_state(struct pci_dev *pdev, pci_power_t state)
+{
+	u16 pwr_cmd;
+
+	for (;;) {
+		pci_read_config_word(pdev, pdev->pm_cap + PCI_PM_CTRL,
+				     &pwr_cmd);
+		if (pwr_cmd & state)
+			break;
+		pwr_cmd = (pwr_cmd & ~PCI_PM_CTRL_STATE_MASK) | state;
+		pci_write_config_word(pdev, pdev->pm_cap + PCI_PM_CTRL,
+				      pwr_cmd);
+		msleep(500);
+	}
+	pdev->current_state = state;
+}
 
 /*
  * Suspend & resume.

@@ -1596,6 +1613,7 @@ int radeon_suspend_kms(struct drm_device *dev, bool suspend,
 
 		if (radeon_crtc->cursor_bo) {
 			struct radeon_bo *robj = gem_to_radeon_bo(radeon_crtc->cursor_bo);
+
 			r = radeon_bo_reserve(robj, false);
 			if (r = 0) {
 				radeon_bo_unpin(robj);

@@ -1647,7 +1665,13 @@ int radeon_suspend_kms(struct drm_device *dev, bool suspend,
 	} else if (suspend) {
 		/* Shut down the device */
 		pci_disable_device(dev->pdev);
-		pci_set_power_state(dev->pdev, PCI_D3hot);
+
+		if ("X32") {
+			radeon_whack_power_state(dev->pdev, PCI_D2);
+			__pci_complete_power_transition(dev->pdev, PCI_D2);
+		} else {
+			pci_set_power_state(dev->pdev, PCI_D3hot);
+		}
 	}
 
 	if (fbcon) {

I suppose some of the mobility stuff from
drivers/video/fbdev/aty/radeon_pm.c is necessary, but I haven't
figured it out for the DRM driver.  Not sure when/if I'll have
time to figure it out, or if I'll stick to the radeonfb driver
for now.

		/* Prepare mobility chips for suspend.
		 */
		if (rinfo->is_mobility) {
			/* Program V2CLK */
			radeon_pm_program_v2clk(rinfo);
		
			/* Disable IO PADs */
			radeon_pm_disable_iopad(rinfo);

			/* Set low current */
			radeon_pm_low_current(rinfo);

			/* Prepare chip for power management */
			radeon_pm_setup_for_suspend(rinfo);

On Thu, 2018-11-08 at 00:03 +0000, Eric Wong wrote:

Benjamin Herrenschmidt [off-list ref] wrote:

quoted

There's a whole pile of power management stuff for ancient laptops that
never quite made it from radeonfb to the radeon DRM driver... sadly it
also prevents sleep on old PowerBooks but I haven't had many complaints
so...

Thanks for the confirmation that stuff is missing from the DRM driver.

quoted

The code for D2 and D3 on those old things is reasonably self
contained, it shouldn't be that hard to move it over I suppose.

I started working on the following (dirty) patch for my X32,
but hasn't made a difference with just PCI_D2:

Yes, as you noticed below, you need the rest of the stuff. If you stick
to D2 and avoid the Mac "D3 cold" stuff, it's easier. You also need to
look at some of the dynamic clock stuff.

Cheers,
Ben.