lkml.org 
[lkml]   [2005]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH][help?] Radeonfb acpi resume
    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

    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2005-07-13 07:35    [W:0.029 / U:30.800 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site