From: Marcelo Tosatti <mtosatti@redhat.com>
To: Paul Brook <paul@codesourcery.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>, kvm <kvm@vger.kernel.org>,
qemu-devel@nongnu.org,
Glauber de Oliveira Costa <gcosta@redhat.com>,
Adam Jackson <ajax@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [patch 0/2] USB UHCI global suspend / remote wakeup
Date: Fri, 26 Nov 2010 00:15:12 -0200 [thread overview]
Message-ID: <20101126021512.GA18020@amt.cnet> (raw)
In-Reply-To: <201011260038.29290.paul@codesourcery.com>
On Fri, Nov 26, 2010 at 12:38:28AM +0000, Paul Brook wrote:
> > This patch enables USB UHCI global suspend/resume feature. The OS will
> > stop the HC once all ports are suspended. If there is activity on the
> > port(s), an interrupt signalling remote wakeup will be triggered.
>
> I'm pretty sure this is wrong. Suspend/resume works based on physical
> topology, i.e. the resume notification should go to the the port/hub to which
> the device is connected, not directly to the host controller.
If the host controller is in global suspend state, and resume is
received on any of its root hub ports (given that remote wakeup is
enabled for the given port), the system will be interrupted if interrupt
enable bit is set.
2.1.2 USB STATUS REGISTER
I/O Address: Base + (02-03h)
Default Value: 0000h
Attribute: Read/Write Clear
size: 16 bits
This register indicates pending interrupts and various states of the
Host Controller
Resume Detect. The Host Controller sets this bit to 1 when it receives
a “RESUME” signal from a USB device. This is only valid if the Host
Controller is in a global suspend state (bit 3 of Command register = 1).
2.1.7.1 Behavior Under Global or Selective Suspend Scenarios
Resume will be recognized in the USBSTS register (bit 2) if resume is
received on a suspended or enabled port when the Host Controller is in
the global suspend state (USBCMD register bit 3 is set).
4.2.1 RESUME RECEIVED
This event indicates that the HC received a RESUME signal from a device
on the USB during a global suspend. If
this interrupt is enabled in the HC Interrupt Enable register, a
hardware interrupt will be signaled to the system
allowing the USB to be brought out of the suspend state and returned to
normal operation.
You are correct in that USB HUB emulation does not propagate resume, but
this does not make this patch incorrect.
next prev parent reply other threads:[~2010-11-26 2:16 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-25 15:34 [Qemu-devel] PATCH: QEMU support for UHCI suspend / remote wake up Marcelo Tosatti
2010-11-25 16:15 ` [Qemu-devel] " Gerd Hoffmann
2010-11-25 17:04 ` [Qemu-devel] [patch 0/2] USB UHCI global suspend / remote wakeup Marcelo Tosatti
2010-11-25 17:04 ` [Qemu-devel] [patch 1/2] add USBBusOps to USBBus Marcelo Tosatti
2010-11-25 17:04 ` [Qemu-devel] [patch 2/2] support for UHCI suspend / remote wake up Marcelo Tosatti
2010-12-01 15:12 ` [Qemu-devel] " Gerd Hoffmann
2010-12-01 16:58 ` Marcelo Tosatti
2010-12-01 17:17 ` Gerd Hoffmann
2010-11-26 0:38 ` [Qemu-devel] [patch 0/2] USB UHCI global suspend / remote wakeup Paul Brook
2010-11-26 2:15 ` Marcelo Tosatti [this message]
2010-11-26 8:49 ` Gerd Hoffmann
2010-11-26 12:09 ` Paul Brook
2010-12-01 16:47 ` [Qemu-devel] [patch 0/3] QEMU support for UHCI suspend / remote wake up (v3) Marcelo Tosatti
2010-12-01 16:47 ` [Qemu-devel] [patch 1/3] add USBPortOps to USBPort Marcelo Tosatti
2010-12-01 17:10 ` [Qemu-devel] " Gerd Hoffmann
2010-12-01 16:47 ` [Qemu-devel] [patch 2/3] support for UHCI suspend / remote wake up Marcelo Tosatti
2010-12-01 17:12 ` [Qemu-devel] " Gerd Hoffmann
2010-12-01 16:47 ` [Qemu-devel] [patch 3/3] UHCI: Substate section for migration of remote wakeup feature Marcelo Tosatti
2010-12-01 17:16 ` [Qemu-devel] " Gerd Hoffmann
2010-12-01 19:14 ` Juan Quintela
2010-12-01 20:56 ` Marcelo Tosatti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101126021512.GA18020@amt.cnet \
--to=mtosatti@redhat.com \
--cc=ajax@redhat.com \
--cc=gcosta@redhat.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).