radeon vs radeonfb Mobility quirks (Thinkpad X32)

radeon vs radeonfb Mobility quirks (Thinkpad X32)

[Eric Wong]

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?id=38554
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583120

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).

radeon vs radeonfb Mobility quirks (Thinkpad X32)

[Eric Wong]

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).

Re: radeon vs radeonfb Mobility quirks (Thinkpad X32)

[Benjamin Herrenschmidt]

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.

Re: radeon vs radeonfb Mobility quirks (Thinkpad X32)

[Benjamin Herrenschmidt]

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.

Re: radeon vs radeonfb Mobility quirks (Thinkpad X32)

[Eric Wong]

Benjamin Herrenschmidt <benh@kernel.crashing.org> 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);

Re: radeon vs radeonfb Mobility quirks (Thinkpad X32)

[Eric Wong]

Benjamin Herrenschmidt <benh@kernel.crashing.org> 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);

Re: radeon vs radeonfb Mobility quirks (Thinkpad X32)

[Benjamin Herrenschmidt]

On Thu, 2018-11-08 at 00:03 +0000, Eric Wong wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> 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:

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.

> 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);

Re: radeon vs radeonfb Mobility quirks (Thinkpad X32)

[Benjamin Herrenschmidt]

On Thu, 2018-11-08 at 00:03 +0000, Eric Wong wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> 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:

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.

> 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);