I should have said I was talking about shutting down after
it gets the suspend request from PCI ... that is, when the
driver is told to stop activity so the system can suspend.
When OHCI is in the "UsbSuspend" state, it shouldn't
be accessing memory. And that's the state it enters
when it gets the suspend request ... from ACPI, via PCI.
Right? Those PCI calls mean entering S3 or S4 states
it seems ... it's not clear to me whether there are enough
APIs to let device drivers (PCI or USB!) support C3,
but I might well have missed some important ones.
- Dave
----- Original Message -----
From: "Brad Parker" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 07, 2001 3:38 AM
Subject: Re: [linux-usb-devel] BM_STS and usb
>
> David Brownell wrote:
> >> > ACPI defines processor power-saving states C0, C1, C2 and C3. We cannot
> >> > enter C3 if there is busmastering activity, and so we check BM_STS. If thi
> >s
> >> > is high when it should not be, and we are therefore not using C3, we are
> >> > losing battery life.
> >>
> >> USB causes continuous bus mastering.
> >
> >OHCI tries to shut everything down; EHCI too. If those are
> >continuously mastering, it's a bug of some kind. I don't know
> >about UHCI though -- those drivers just seem to reset the
> >chip on suspend.
>
> won't an ohci chip write the frame # into the hcca once every ms?
> (even when idle?)
>
> -brad
>
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
