Re: [PATCH][help?] Radeonfb acpi resume
From: Micheal Marineau (marineam_at_engr.orst.edu)
Date: 07/13/05
- Previous message: Pete Zaitcev: "Re: USB bugs in 2.6.11.8, 2.6.11.10 and 2.6.12.2"
- In reply to: Benjamin Herrenschmidt: "Re: [PATCH][help?] Radeonfb acpi resume"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 12 Jul 2005 22:31:42 -0700 To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Thanks for the input,
Benjamin Herrenschmidt wrote:
> 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.
>
> .../...
Yea, so it would seem. Hopefully that'll get fixed magicly once I
clean up the rest a little bit.
>
>
>>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)
Hrm, maybe it works now, but a few kernel versions back something broke
and I added that in as an easy fix. I'll try taking pci_save/restore out
again, hopefully all is well again.
>
>
>>+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.
>
ok, I haven't looked at the existing code very extensivly, I should check
it out :-)
-- Michael Marineau marineam@engr.orst.edu Oregon State University
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- application/pgp-signature attachment: OpenPGP digital signature
- Previous message: Pete Zaitcev: "Re: USB bugs in 2.6.11.8, 2.6.11.10 and 2.6.12.2"
- In reply to: Benjamin Herrenschmidt: "Re: [PATCH][help?] Radeonfb acpi resume"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
