Re: [linux-usb-devel] Re: OHCI problems with suspend/resume

From: David Brownell (david-b_at_pacbell.net)
Date: 07/31/03

  • Next message: Ricardo Galli: "HELP: cpufreq on HT and/or SMP systems" 
    Date:	Thu, 31 Jul 2003 14:55:53 -0700
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>

    Benjamin Herrenschmidt wrote:
    >
    > You should look at Patrick Mochel's stuff that shall be getting in
    > the official tree this month hopefully. It does that (among others)

    OK, thanks for the update. It was puzzling to see this stuff
    in such a state ... I've got a few patches for USB PM that are
    worth putting back in advance of that, but it seems like real
    testing will need to wait until "next month". (Tomorrow!)

    > The USB "device" drivers shall just rely on the Device Model
    > infrastructure to have their suspend/resume callbacks be called at the
    > appropriate time.

    Yes, that's no problem. It looks like:

       static int my_suspend(struct device *_intf, u32 state, u32 level)
       {
           struct usb_interface *intf;
           int retval = 0;

           intf = to_usb_interface(_intf);
           switch (level) {
           ... cases are yet to stabilize ...
           }
           return retval;
       }

       ... similar for resume()

       static struct usb_driver my_driver {
            .owner = THIS_MODULE,
            .name = "MyFirstDriver",
            .probe = my_probe,
            .disconnect = my_disconnect,
            .id_table = my_id_table,
            .driver = {
                  .suspend = my_suspend,
                  .resume = my_resume,
             },
        };

    But until the suspend()/resume() callback API stabilizes, it's
    mostly useful to know that it'll be exactly that simple, and
    that usbcore doesn't get in the way.

    I suspect that USB should do some non-global PM stuff too.
    Hub ports can be suspended when the devices connected to them
    are idle for long enough ... that's not something I'd expect
    system-wide PM policies to address.

    - Dave

    -
    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: Ricardo Galli: "HELP: cpufreq on HT and/or SMP systems"

    Relevant Pages

    • Re: Totally broken PCI PM calls
      ... I'm thinking of the case of Cardbus with hotpluggable PCI buses. ... to being inappropriately setup. ... problem is present with USB, and USB is far more liable to have this ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: more files with licenses that arent GPL-compatible
      ... strange license text) we got that solved easily. ... If one of you usb guys want to convert it that's fine, ... get the files relicensed under a GPL-compatible license that's fine aswell, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.0-mm1
      ... working on console and under XFree86 as well. ... as for me it seems gpm interprets ... reads data replicated by gpm via gpmdata can't handle the USB mouse ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.9-mm1: NForce3 problem (IRQ sharing issue?)
      ... > stopped working along with the USB (as you can see above, ... > registered, assigned bus number 2 ... That's probably the nforce3 audio device which is an intel part. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • USB making time drift [was Re: dynamic-hz]
      ... > I'm not using hpet because it's an old hardware, ... How much drift do you see? ... I have machine with UHCI here, and am using usb most of the time ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)