>
> On Fri, Mar 09, 2001, Grover, Andrew <[EMAIL PROTECTED]> wrote:
> > > This wouldn't work for systems with builtin hubs (not the
> > > root hub) and
> > > just doesn't seem very intuitive to me.
> > >
> > > I'm not super familiar with the steps ACPI goes through to
> > > suspend, but
> > > don't we have a warning that a suspend is about to happen and
> > > we can do
> > > things?
> > >
> > > Wouldn't this be a better time to suspend the HC?
> >
> > I am not talking about suspending the HC when the system is
> suspended, I am
> > talking about suspending the HC when *the system is
> running* and no devices
> > are attached.
> >
> > Why bother? Because running the HC even with nothing
> attached prevents ACPI
> > from putting the CPU into deep sleep (C3) when idle. The HC
> is not only
> > wasting power, it is causing the CPU to waste power.
> >
> > We will also want to suspend the HC (even with devices
> attached) when the
> > system goes to sleep, but I was focussing on the other issue first.
>
> Ahh, then this is tricky. This sounds like the best we can do for now
> then.
>
> It's unfortunately not perfect.
>
> > I am not a USB expert -- how would builtin hubs complicate things?
>
> It's just like any other device, it would generate traffic.
> This is not
> the same as the root hub (which all HC's have are not a "real" device)
> and not all HC's have builtin hub's, but I'm seeing them more
> often now.
>
> JE
>
my understanding of c3 is that the process of gettting the cpu into c3 is
completely independent of the system state (actually, usually performed when
the system is full on). so the user thinks that the system is full-on (an
has certain, reasonable expectations for responsivness) but the cpu can be
cycling in an out of c3 with significant power savings while in c3.
if the only devices connected are hubs, then you can enable all the hubs for
remote wakeup and then suspend everyone, including putting the o/uhci hc
into global suspend. for power-sucking reasons on resume, you also want to
selectively suspend all ports as you suspend your bus. when the hc is
suspended, he stays out of memory. once the bus is suspended (and builtin or
external hubs enabled for remote wakeup), any connect (or disconnect) will
cause resume signaling, which will propagate to the hc, which will cause an
interrupt and the cpu will be brought out of C3. you could probably
generalize this approach to include other devices attached (but not in use).
for example a printer or camera that is not currently being used. if none of
the connected devices are currently in use, the only events you really need
to be sensitive to are connects and disconnects. you can easily manage
timely detection of these events from the suspended state.
if you have a 'busy' device like a video camera which is currently in use,
then the cpu is gonna be busy and you are not getting into c3 anyway (not a
interesting case).
if you have a 'sometimes busy' device, like a hid device (like a mouse or
keyboard), suspending the usb to get the cpu into c3 won't work. the reason
is kind of complicated to describe. basically, (as described above) when the
cpu is in c3, the rest of the system is full-on and the user has an
expectation for system responsiveness. for example, I'm typing in this email
response; as I get interrupted by my wife...(gee that was opportune) the
system is by my perception still full-on, but it was reasonably idle waiting
for me to type the next thing in... an opportunity to save significant power
and get into c3. If we suspend the bus, then go into c3, when I resume
typing, that would initiate resume signaling, and there would be a
significant delay (probably a second or more) before the system starting
taking keystrokes. a bigger problem than the time lag is the fact that you
are almost guaranteed to lose characters. the hid spec does not require that
a button or key push on a remote-wakeup device do anything more than
initiate remote wakeup, so you are almost guaranteed to lose the first
characters or two (to initiate the remote wakeup) than possibly more,
depending on the amount of time it takes to actually resume the bus and the
amount of buffering on the device. keyboard is the real killer. mice losing
data could result in worst case a jump in the mouse position. keyboard loss
of data is really annoying. an aggressive c3 algorithm would result in lots
of lost data and really annoy users.
so, what is needed is a mechanism that keeps the device 'alive' i.e. SOFs
happening, but stays out of main memory. you can build a macro-poll of your
hid devices (with a longer than 8ms pollrate, that would allow you to get
into c3 more often and still offer reasonable service to the hid devices,
without loss of data. it's my understanding that neither o or u hci support
this kind of operation. I think you can tell the ohci to not service its
schedules, but it still has a requirement to update the frame counter in
main memory before sending the next sof, so you still get the 1ms access to
main memory (I'm not an expert on ohci, this was described to me by a fellow
who implemented one). ehci added such a feature specifically for this
purpose, but you are still somewhat slaved to the legacy component in the
system (the companion controllers). the ohci companions may have been
enhanced to inhibit the write-back of the frame number when the schedules
are disabled. I've not see a spec for a feature to be added to the uhci to
allow shutting off the schedule.
btw, I don't think anyone has performed any real experiments to determine
the optimum time for the macro poll. but it needs to be tightly coupled to
the c3 algorithm.
just my perspective on this issue.
Regards
John H.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
