> ... though FWIW I missed seeing anything that showed how
> those API summaries would place constraints on allocating
> memory, so I didn't assume there could be any.
It specified that there would be no valid assumptions on the
order of devices woken up. Thus the devices that would be paged
to
Hi!
> What did seem to be missing was anything saying whether
> those device methods would be called in_interrupt() or
> whether instead they could sleep. I'd hope all of them
> would be specified to allow blocking as needed, like their
> current analogues in PCI and USB.
Look better, it was th
> > All calls are made with interrupts enabled, except for the
> > SUSPEND_POWER_DOWN level.
>
> This is a slight problem for USB. We need to switch on interupts
> to send a message to the device.
For example, to enable remote wakeup (whenever we start to
support that). I understand that a
Hi!
> > > SUSPEND_DISABLE tells the device to stop I/O transactions. When it
> > > stops transactions, or what it should do with unfinished transactions
> > > is a policy of the driver. After this call, the driver should not
> > > accept any other I/O requests.
> >
> > Does this mean that memory
> IIRC, USB device state won't be saved across power transitions. It will
> look like a "disconnect", and "reconnect" on resume. (Forgive me if that's
> not the right USB terminology; I'm just guessing). In that case, when the
> controller gets the SUSPEND_DISABLE call, it can shutdown all the
>
Am Mittwoch, 5. Juni 2002 21:11 schrieb Patrick Mochel:
> On Wed, 5 Jun 2002, Oliver Neukum wrote:
> > > SUSPEND_DISABLE tells the device to stop I/O transactions. When it
> > > stops transactions, or what it should do with unfinished transactions
> > > is a policy of the driver. After this call,
On Wed, 5 Jun 2002, Oliver Neukum wrote:
>
> > SUSPEND_DISABLE tells the device to stop I/O transactions. When it
> > stops transactions, or what it should do with unfinished transactions
> > is a policy of the driver. After this call, the driver should not
> > accept any other I/O requests.
>
On Wed, 5 Jun 2002, Oliver Neukum wrote:
>
> > Whether suspend is called with a given level is a policy of the
> > platform. Some levels may be omitted; drivers must not assume the
> > reception of any level. However, all levels must be called in the
> > order above; i.e. notification will alwa
> SUSPEND_DISABLE tells the device to stop I/O transactions. When it
> stops transactions, or what it should do with unfinished transactions
> is a policy of the driver. After this call, the driver should not
> accept any other I/O requests.
Does this mean that memory allocations in the suspend/
> Whether suspend is called with a given level is a policy of the
> platform. Some levels may be omitted; drivers must not assume the
> reception of any level. However, all levels must be called in the
> order above; i.e. notification will always come before disabling;
> disabling the device will
10 matches
Mail list logo
