Re: [PATCH] PCI: Add pci shutdown ability

From: Pavel Machek (pavel_at_ucw.cz)
Date: 04/26/05

  • Next message: Miklos Szeredi: "Re: [PATCH] private mounts"
    Date:	Tue, 26 Apr 2005 11:16:03 +0200
    To: Adam Belay <ambx1@neo.rr.com>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Adam Belay <abelay@novell.com>, Dave Jones <davej@redhat.com>, Andrew Morton <akpm@osdl.org>, Alan Stern <stern@rowland.harvard.edu>, alexn@dsv.su.se, Greg KH <greg@kroah.com>, gud@eth.net, Linux Kernel list <linux-kernel@vger.kernel.org>, linux-pci@atrey.karlin.mff.cuni.cz, Jeff Garzik <jgarzik@pobox.com>, cramerj@intel.com, Linux-USB <linux-usb-devel@lists.sourceforge.net>, Linux-pm mailing list <linux-pm@lists.osdl.org>
    
    

    Hi!

    > > I don't like this notion of "stop" separated from power states anyway, I
    > > think it just doesn't work in practice.
    >
    > Yeah, after giving it some additional thought, I think there are better ways.
    >
    > >
    > > Ben.
    > >
    >
    > Ok, here's a new idea.
    >
    > For many devices "->suspend" and "->resume" with pm_message_t is exactly what
    > we need. However, as we support more advanced power management features, such
    > as runtime power management, or power containers, we need something a little
    > more specific. The exact power state must be specified among other
    > issues.

    Okay, maybe. But not by adding 3 new callbacks that mirror existing
    functionality.

    > We might do something like this:
    >
    > Keep "->suspend" and "->resume" around unchanged. (so the states would
    > probably remain as PMSG_FREEZE and PMSG_SUSPEND). If the driver doesn't
    > support the more advanced PM methods just use these. They work well enough
    > for system sleep states etc.
    >
    > Alternatively drivers could support a more rich power management interface
    > via the following methods:
    >
    >
    > change_state - changes a device's power state
    >
    > change_state(struct device * dev, pm_state_t state, struct system_state * sys_state, int reason);
    > @dev - the device
    > @state - the target device-specific power state
    > @sys_state - a data structure containing information about the intended global system power state
    > @reason - why the state must be changed (ex. RUNTIME_PM,
    > SYSTEM_SLEEP, SYSTEM_RESUME, etc.)

    If drivers really need to know system state and reason, just put it
    into pm_message_t. I wanted to add "flags" there from the begining,
    serving similar purpose as your "reason".

    > halt - acts somewhat like PMSG_FREEZE, stops device activity, doesn't change power state
    >
    > halt(struct device * dev, struct system_state * sys_state, int reason);
    > @dev - the device
    > @sys_state - a data structure containing information about the intended global system power state
    > @reason - why we are halting operation (ex. RUNTIME_CHANGES (like cpufreq), SYSTEM_SLEEP, SHUTDOWN, REBOOT)

    If it is similar to PMSG_FREEZE, just pass PMSG_FREEZE and put
    * sys_state and reason into pm_message_t.

    > contine - resumes from a "halt"
    >
    > continue(struct device * dev, struct system_state * sys_state, int reason);
    > @dev - the device
    > @sys_state - a data structure containing information about the intended global system power state
    > @reason - why we are resuming operation (ex. RUNTIME_CHANGES (like cpufreq), SYSTEM_RESUME)

    Now, here you have a point. resume() should get pm_message_t,
    too. This should be rather easy to change (simple matter of coding),
    and we have agreed before that it is good idea. Patches welcome.

                                                                    Pavel

    -- 
    Boycott Kodak -- for their patent abuse against Java.
    -
    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/
    

  • Next message: Miklos Szeredi: "Re: [PATCH] private mounts"

    Relevant Pages

    • PROBLEM: high load average when idle
      ... My computer suffers from high load average when the system is idle, ... Power Management version 2 ... # Firmware Drivers ... # ACPI Support ...
      (Linux-Kernel)
    • PROBLEM: kernel 2.6.22.9-cfs-v22 compile warnings
      ... kernel versions, its just i didnt had courage to report them:) I'm ... cat /proc/version ... # Power management options ... # ACPI Support ...
      (Linux-Kernel)
    • Kernel panic: Machine check exception
      ... Kernel panic - not syncing: ... power management: ts fid vid ttp ... 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev ... # ACPI Support ...
      (Linux-Kernel)
    • Re: 2.6.7-rc2-mm2
      ... # ACPI Support ... # APM (Advanced Power Management) BIOS Support ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • PROBLEM: Linux-2.6.18 fails to boot
      ... After recompiling of a kernel booting failed with message: ... power management: ts fid vid ttp tm stc ... # ACPI Support ... # Device Drivers ...
      (Linux-Kernel)