On Thursday 28 August 2008 18:21:09 Greg KH wrote:
> On Thu, Aug 28, 2008 at 11:37:24AM +0200, Marcel Janssen wrote:
> > Hello Greg,
> >
> > I've got me a bit confused there :-)
> >
> > We currently only use the suspend/resume in our device which works on a
> > received request from the PC.
> > Basically sending suspend will make the device enter this mode. When the
> > PC enters this mode, it's also clear it will send a resume when resuming
> > from standby. But, how is this supposed to work when the PC is not in
> > sleep mode.....how will the device wake up ?
>
> It should "automatically" wake up if something happens to it. The USB
> spec calls this out as to how this should work. If the devices don't
> support this, we don't have to add support for it :)
Actually this is a good point.
The USB spec mentions that the device should suspend when a constant idle
state is detected for more than 3.0ms.
I either have not seen that happening before or I missed something when
writing my firmware. I'll keep an eye on my USB analyzer though :-)
Although it's a good thing to keep to the spec, I also believe that in the
case of a test and measurement device suspending the device may be an
unwanted behaviour but perhaps I do misinterpret this part of the spec here.
Anyway, this is no issue for self-powered devices, which is probably the
majority in this class because most test & measurement devices need a good
power supply and USB just isn't fit for that unless you're able to make a
clean power from that (which is possible of course).
Our device is both USB and self powered, but when in USB powered mode it will
only suspend when the host goes in sleep mode.
To be honest I would put suspend mode far down on the priority list :-)
regards,
Marcel
On Thu, Aug 28, 2008 at 08:22:53PM +0200, Marcel Janssen wrote:
> On Thursday 28 August 2008 18:21:09 Greg KH wrote:
> > On Thu, Aug 28, 2008 at 11:37:24AM +0200, Marcel Janssen wrote:
> > > Hello Greg,
> > >
> > > I've got me a bit confused there :-)
> > >
> > > We currently only use the suspend/resume in our device which works on a
> > > received request from the PC.
> > > Basically sending suspend will make the device enter this mode. When the
> > > PC enters this mode, it's also clear it will send a resume when resuming
> > > from standby. But, how is this supposed to work when the PC is not in
> > > sleep mode.....how will the device wake up ?
> >
> > It should "automatically" wake up if something happens to it. The USB
> > spec calls this out as to how this should work. If the devices don't
> > support this, we don't have to add support for it :)
>
> Actually this is a good point.
>
> The USB spec mentions that the device should suspend when a constant idle
> state is detected for more than 3.0ms.
>
> I either have not seen that happening before or I missed something when
> writing my firmware. I'll keep an eye on my USB analyzer though :-)
> Although it's a good thing to keep to the spec, I also believe that in the
> case of a test and measurement device suspending the device may be an
> unwanted behaviour but perhaps I do misinterpret this part of the spec here.
>
> Anyway, this is no issue for self-powered devices, which is probably the
> majority in this class because most test & measurement devices need a good
> power supply and USB just isn't fit for that unless you're able to make a
> clean power from that (which is possible of course).
> Our device is both USB and self powered, but when in USB powered mode it will
> only suspend when the host goes in sleep mode.
>
> To be honest I would put suspend mode far down on the priority list :-)
Ok, thanks for letting us know, if they are self-powered, this shouldn't
be much of an issue. Let's focus on getting the current driver working
again :)
thanks,
greg k-h
> > I either have not seen that happening before or I missed something when
> > writing my firmware. I'll keep an eye on my USB analyzer though :-)
> > Although it's a good thing to keep to the spec, I also believe that in the
> > case of a test and measurement device suspending the device may be an
> > unwanted behaviour but perhaps I do misinterpret this part of the spec here.
For the record, the "gadgetfs" interface was originally developed with
userspace USB TMC implementations in mind. I don't recall whether that
effort got out of the lab though.
The issue of suspend/resume explicitly came up. The scenario which
stuck in my mind was that when the TMC device was in USB-level suspend
state, the code on the peripheral would need to know about that so
it could re-enable manual controls. The host could no longer be
issuing commands. (Some of these folk were on the TMC design team.)
One of the customers didn't seem to like the notion of not being able
to turn off stress tests on a $US 20,000 engine ... and watching the
device(s) under test blow up. Accidental destruction == bad, it seems!
So I think you probably do misinterpret the spec. That issue was not
only discussed, but proper handling for it was identified.
- Dave