Re: [PATCH][help?] Radeonfb acpi resume

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Sun, 2005-07-10 at 15:19 -0700, Micheal Marineau wrote:
> I've been forward porting this patch for a while now and need
> some input on it. You can see the last time someone posted it
> to the list here:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0410.0/0600.html
> 
> The big issue mentioned in that thread, that it reqires a key
> press during the resume process to keep going still exists and
> I have been unable to understand why.  The issue is in radeon_pm.c
> in this block that follows the last hunk of the diff:
> 
>         if (rinfo->no_schedule) {
>                 if (try_acquire_console_sem())
>                         return 0;
>         } else
>                 acquire_console_sem();
> 
> Specificly it's acquire_console_sem(); where the resume stops waiting
> for a key press.  What could be stopping things?

I don't see any reason for that. That definitely shouldn't happen.

   .../...

> diff -ru linux-2.6.12.orig/drivers/video/aty/radeon_pm.c
> linux-2.6.12/drivers/video/aty/radeon_pm.c
> --- linux-2.6.12.orig/drivers/video/aty/radeon_pm.c	2005-06-17
> 12:48:29.000000000 -0700
> +++ linux-2.6.12/drivers/video/aty/radeon_pm.c	2005-07-03
> 19:55:36.000000000 -0700
> @@ -2606,10 +2606,13 @@
> 
>   done:
>  	pdev->dev.power.power_state = state;
> +	pci_save_state (pdev);
> 
>  	return 0;
>  }

Hrm... radeonfb already saves the config space elsewhere. Note that it
could maybe be converted to pci_save_state() / pci_restore_state() but
currently, I do my own as I use that for "testing" if the card is still
in it's previous state or was shut down. (I could probably use the
content of a register instead, like CLK_PIN_CNTL)

> +extern void acpi_vgapost (unsigned long slot);
> +
>  int radeonfb_pci_resume(struct pci_dev *pdev)
>  {
>          struct fb_info *info = pci_get_drvdata(pdev);
> @@ -2619,6 +2622,12 @@
>  	if (pdev->dev.power.power_state == 0)
>  		return 0;
> 
> +	if (pdev->dev.power.power_state != 4)
> +	{
> +		pci_restore_state (pdev);
> +		acpi_vgapost (pdev->devfn);
> +	}
> +
>  	if (rinfo->no_schedule) {
>  		if (try_acquire_console_sem())
>  			return 0;

The above will probably blow up anything that is not an x86 with ACPI.
Besides there is already a mecanism in that file for calling functions
for re-posting cards (since I have code to explicitely re-post rv280 and
rv350 mobility on macs), you should hook into that existing mecanism
when you detect ACPI.

Ben.