On Fri, 29 Apr 2005, Oliver Neukum wrote:
> > "Provided that you know when you can safely autosuspend." If the driver
> > doesn't know when it can suspend its device, who else would know?
>
> Those who understand the semantics, which with scsi (sg) might be
> in user space.
Definitely we would
> Oliver, I don't understand your point. Which devices and drivers are you
> referring to?
Scsi and drivers that drive scsi cards or their equivalent.
> "Provided that you know when you can safely autosuspend." If the driver
> doesn't know when it can suspend its device, who else would know
On Thu, 28 Apr 2005, Oliver Neukum wrote:
> > > Please consider scsi. It has no idea about what is going on.
> >
> > In principle this shouldn't matter. If a device is autosuspended then it
> > should autoresume whenever a new request (such as a new SCSI command)
> > arrives.
>
> Provided tha
Am Donnerstag, 28. April 2005 23:14 schrieb David Brownell:
> On Thursday 28 April 2005 2:01 pm, Oliver Neukum wrote:
> > Am Donnerstag, 28. April 2005 17:40 schrieb David Brownell:
> > > On Thursday 28 April 2005 12:13 am, Oliver Neukum wrote:
> > > >
> > > > Please consider scsi. It has no idea
On Thursday 28 April 2005 2:01 pm, Oliver Neukum wrote:
> Am Donnerstag, 28. April 2005 17:40 schrieb David Brownell:
> > On Thursday 28 April 2005 12:13 am, Oliver Neukum wrote:
> > >
> > > Please consider scsi. It has no idea about what is going on.
> >
> > No more than for example an IDE disk
Am Donnerstag, 28. April 2005 17:40 schrieb David Brownell:
> On Thursday 28 April 2005 12:13 am, Oliver Neukum wrote:
> >
> > Please consider scsi. It has no idea about what is going on.
>
> No more than for example an IDE disk does. Yet somehow
> "hdparm -S" lets the drives themselves spin dow
Am Donnerstag, 28. April 2005 17:24 schrieb Alan Stern:
> On Thu, 28 Apr 2005, Oliver Neukum wrote:
>
> > Am Donnerstag, 28. April 2005 02:26 schrieb David Brownell:
> > > On Wednesday 27 April 2005 2:32 pm, Alan Stern wrote:
> > > >
> > > > That's not in question. The issue is: Out of all the d
On Thursday 28 April 2005 12:13 am, Oliver Neukum wrote:
>
> Please consider scsi. It has no idea about what is going on.
No more than for example an IDE disk does. Yet somehow
"hdparm -S" lets the drives themselves spin down when
they're idle for a while ... a kind of autosuspend.
--
On Thu, 28 Apr 2005, Oliver Neukum wrote:
> Am Donnerstag, 28. April 2005 02:26 schrieb David Brownell:
> > On Wednesday 27 April 2005 2:32 pm, Alan Stern wrote:
> > >
> > > That's not in question. The issue is: Out of all the drivers floating
> > > around, which one should decide when a partic
On Wed, 27 Apr 2005, David Brownell wrote:
> On Wednesday 27 April 2005 2:32 pm, Alan Stern wrote:
> >
> > That's not in question. The issue is: Out of all the drivers floating
> > around, which one should decide when a particular device can be suspended
> > for lack of activity?
>
> Erm, not
Am Donnerstag, 28. April 2005 02:26 schrieb David Brownell:
> On Wednesday 27 April 2005 2:32 pm, Alan Stern wrote:
> >
> > That's not in question. The issue is: Out of all the drivers floating
> > around, which one should decide when a particular device can be suspended
> > for lack of activit
On Wednesday 27 April 2005 2:32 pm, Alan Stern wrote:
>
> That's not in question. The issue is: Out of all the drivers floating
> around, which one should decide when a particular device can be suspended
> for lack of activity?
Erm, not just _one_ can do it. Certainly any interface's driver c
On Wed, 27 Apr 2005, David Brownell wrote:
> I see your point, but do you see mine? Namely, that any hub
> will _only_ autosuspend. It's in reaction to something else
> happening, to be sure, but any notion that software directly
> tells any hub to suspend itself is purely an illusion that must
On Wednesday 27 April 2005 12:14 pm, Alan Stern wrote:
> On Wed, 27 Apr 2005, David Brownell wrote:
>
> > The root hub autosuspend is different though; it turns off
> > the flow of SOF packets, just like setting the suspend bit
> > on the parent port of an external hub.
>
> Right again. And sett
On Wed, 27 Apr 2005, David Brownell wrote:
> Hmm, but external hubs DO autosuspend: as soon as SOFs stop flowing
> from the parent, they suspend themselves (and their children).
> That's analagous to what a root hub does when the HC itself gets
> suspended.
Right.
> The root hub autosuspend is
On Wednesday 27 April 2005 8:17 am, Alan Stern wrote:
> On Wed, 27 Apr 2005, David Brownell wrote:
>
> > > Why should USB core's auto-suspend depend on CONFIG_PM? In
> > > particular, if this results in (at least partial)
> > > duplication of the auto-suspend functionality in HCDs.
> >
> > It
On Wed, 27 Apr 2005, David Brownell wrote:
> > Why should USB core's auto-suspend depend on CONFIG_PM? In
> > particular, if this results in (at least partial)
> > duplication of the auto-suspend functionality in HCDs.
>
> It could be argued two different ways: that "hub autosuspend"
> should
On Tuesday 26 April 2005 11:55 pm, Olav Kongas wrote:
>
> On Tue, 26 Apr 2005, Alan Stern wrote:
> > Actually it probably will. That might be a good reason to keep a minimal
> > auto-suspend capability in the HCDs, for use when CONFIG_PM is off.
>
> Why should USB core's auto-suspend depend on
18 matches
Mail list logo
