question on flushing buffers and spinning down disk

question on flushing buffers and spinning down disk

[Oliver Neukum]

Hi,

which function should a lldd call to make the scsi layer flush
a device's buffers and spin it down? Which kind of locking is
required?

	Regards
		Oliver

Re: question on flushing buffers and spinning down disk

[James Bottomley]

On Tue, 2007-09-18 at 10:32 +0200, Oliver Neukum wrote:
> which function should a lldd call to make the scsi layer flush
> a device's buffers and spin it down? Which kind of locking is
> required?

Depends on the context. Is this for suspend? If so it's done
automatically by the sd driver, but the device has to be marked for it
in the manage_start_stop attributes.

James

Re: question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Dienstag 18 September 2007 schrieb James Bottomley:
> On Tue, 2007-09-18 at 10:32 +0200, Oliver Neukum wrote:
> > which function should a lldd call to make the scsi layer flush
> > a device's buffers and spin it down? Which kind of locking is
> > required?
> 
> Depends on the context. Is this for suspend? If so it's done
> automatically by the sd driver, but the device has to be marked for it
> in the manage_start_stop attributes.

It is for runtime power management. We've gotten a bug report about
a drive enclosure that doesn't properly park heads if the usb device is
simply suspended. Apparently it simply cuts power so the cache can
be lost, too.

	Regards
		Oliver

Re: question on flushing buffers and spinning down disk

[James Bottomley]

On Tue, 2007-09-18 at 16:15 +0200, Oliver Neukum wrote:
> Am Dienstag 18 September 2007 schrieb James Bottomley:
> > On Tue, 2007-09-18 at 10:32 +0200, Oliver Neukum wrote:
> > > which function should a lldd call to make the scsi layer flush
> > > a device's buffers and spin it down? Which kind of locking is
> > > required?
> > 
> > Depends on the context. Is this for suspend? If so it's done
> > automatically by the sd driver, but the device has to be marked for it
> > in the manage_start_stop attributes.
> 
> It is for runtime power management. We've gotten a bug report about
> a drive enclosure that doesn't properly park heads if the usb device is
> simply suspended. Apparently it simply cuts power so the cache can
> be lost, too.

But even for runtime, if you want to suspend the device, shouldn't you
be calling the suspend methods in the device tree?

James

Re: question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Dienstag 18 September 2007 schrieb James Bottomley:
> On Tue, 2007-09-18 at 16:15 +0200, Oliver Neukum wrote:
> > Am Dienstag 18 September 2007 schrieb James Bottomley:
> > > On Tue, 2007-09-18 at 10:32 +0200, Oliver Neukum wrote:
> > > > which function should a lldd call to make the scsi layer flush
> > > > a device's buffers and spin it down? Which kind of locking is
> > > > required?
> > > 
> > > Depends on the context. Is this for suspend? If so it's done
> > > automatically by the sd driver, but the device has to be marked for it
> > > in the manage_start_stop attributes.
> > 
> > It is for runtime power management. We've gotten a bug report about
> > a drive enclosure that doesn't properly park heads if the usb device is
> > simply suspended. Apparently it simply cuts power so the cache can
> > be lost, too.
> 
> But even for runtime, if you want to suspend the device, shouldn't you
> be calling the suspend methods in the device tree?

Very good question. It seems to that yes indeed, we should. But we don't
in case of autosuspend. We simply suspend the interfaces:

static int usb_suspend_both(struct usb_device *udev, pm_message_t msg)

[..]
	/* Suspend all the interfaces and then udev itself */
	if (udev->actconfig) {
		for (; i < udev->actconfig->desc.bNumInterfaces; i++) {
			intf = udev->actconfig->interface[i];
			status = usb_suspend_interface(intf, msg);
			if (status != 0)
				break;
		}
	}

without involving the driver core.

Is this a design bug?

	Regards
		Oliver

Re: question on flushing buffers and spinning down disk

[Alan Stern]

On Mon, 24 Sep 2007, Oliver Neukum wrote:

> Am Dienstag 18 September 2007 schrieb James Bottomley:
> > On Tue, 2007-09-18 at 16:15 +0200, Oliver Neukum wrote:

> > > It is for runtime power management. We've gotten a bug report about
> > > a drive enclosure that doesn't properly park heads if the usb device is
> > > simply suspended. Apparently it simply cuts power so the cache can
> > > be lost, too.
> > 
> > But even for runtime, if you want to suspend the device, shouldn't you
> > be calling the suspend methods in the device tree?
> 
> Very good question. It seems to that yes indeed, we should. But we don't
> in case of autosuspend. We simply suspend the interfaces:

It's a loaded question.  The fact is, the existing suspend methods in
the device tree are intended for system-wide suspend, not for runtime
suspend.  The PM and driver cores don't include _any_ provision for
runtime suspend; it has to be managed separately by each subsystem.

And that means we need a method of communication between the SCSI and 
USB subsystems.  The SCSI core has to tell usb-storage when it's okay 
to do a runtime suspend.  More generally, every host adapter driver 
should have a method in its driver template which the SCSI core can 
invoke when it is safe to suspend the adapter (and thus the entire 
bus).

Alan Stern

Re: question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Montag 24 September 2007 schrieb Alan Stern:
> On Mon, 24 Sep 2007, Oliver Neukum wrote:
> 
> > Am Dienstag 18 September 2007 schrieb James Bottomley:
> > > On Tue, 2007-09-18 at 16:15 +0200, Oliver Neukum wrote:
> 
> > > > It is for runtime power management. We've gotten a bug report about
> > > > a drive enclosure that doesn't properly park heads if the usb device is
> > > > simply suspended. Apparently it simply cuts power so the cache can
> > > > be lost, too.
> > > 
> > > But even for runtime, if you want to suspend the device, shouldn't you
> > > be calling the suspend methods in the device tree?
> > 
> > Very good question. It seems to that yes indeed, we should. But we don't
> > in case of autosuspend. We simply suspend the interfaces:
> 
> It's a loaded question.  The fact is, the existing suspend methods in
> the device tree are intended for system-wide suspend, not for runtime

Unfortunately true.

> suspend.  The PM and driver cores don't include _any_ provision for
> runtime suspend; it has to be managed separately by each subsystem.

There we have a problem. We'd have to solve it for each subsystem transition.
Storage has this type of children, other devices will have to care for other
types of child devices. If we have a device tree, we should use it.
 
	Regards
		Oliver

Re: question on flushing buffers and spinning down disk

[Alan Stern]

On Mon, 24 Sep 2007, Oliver Neukum wrote:

> > suspend.  The PM and driver cores don't include _any_ provision for
> > runtime suspend; it has to be managed separately by each subsystem.
> 
> There we have a problem. We'd have to solve it for each subsystem transition.
> Storage has this type of children, other devices will have to care for other
> types of child devices. If we have a device tree, we should use it.

It sounds like you want to add the equivalent of
usb_autopm_get/set_device() and usb_autopm_get/set_interface() into the
driver model.  But it would not be appropriate, since other subsystems
don't have the same kinds of runtime power levels as USB does.

There may be no way of getting around the need for specialized 
communication methods between subsystems for runtime PM.

Alan Stern

Re: question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Montag 24 September 2007 schrieb Alan Stern:
> On Mon, 24 Sep 2007, Oliver Neukum wrote:
> 
> > > suspend.  The PM and driver cores don't include _any_ provision for
> > > runtime suspend; it has to be managed separately by each subsystem.
> > 
> > There we have a problem. We'd have to solve it for each subsystem transition.
> > Storage has this type of children, other devices will have to care for other
> > types of child devices. If we have a device tree, we should use it.
> 
> It sounds like you want to add the equivalent of
> usb_autopm_get/set_device() and usb_autopm_get/set_interface() into the

That would be an ideal solution, but it is not necessary to solve this
problem.

> driver model.  But it would not be appropriate, since other subsystems
> don't have the same kinds of runtime power levels as USB does.

But we don't bother when suspending the whole system. So why not simply
walk the subtrees under a USB device? Let the subsystem choose what
depth of sleep to use.
 
> There may be no way of getting around the need for specialized 
> communication methods between subsystems for runtime PM.

That's a lot of code duplication and should be a solution of last resort.

	Regards
		Oliver

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: question on flushing buffers and spinning down disk

[Alan Stern]

On Mon, 24 Sep 2007, Oliver Neukum wrote:

> > It sounds like you want to add the equivalent of
> > usb_autopm_get/set_device() and usb_autopm_get/set_interface() into the
> 
> That would be an ideal solution, but it is not necessary to solve this
> problem.
> 
> > driver model.  But it would not be appropriate, since other subsystems
> > don't have the same kinds of runtime power levels as USB does.
> 
> But we don't bother when suspending the whole system. So why not simply
> walk the subtrees under a USB device? Let the subsystem choose what
> depth of sleep to use.

Because by doing so you are effectively telling the drivers in the
subtree that the entire system is going to be suspended, which isn't
correct.  It may also turn out that the user wants to keep the
subsystem active, even though the USB driver isn't aware of it.  Last
but not least, the subsystem will need to have some form of autoresume.  

The way it should work is for the lower subsystem to tell the USB
driver when suspending is okay, not the other way around.  When the
subsystem implements its own form of runtime PM support, then you'll be
able to use it properly.  But until then, there isn't anything much you
can do.

> > There may be no way of getting around the need for specialized 
> > communication methods between subsystems for runtime PM.
> 
> That's a lot of code duplication and should be a solution of last resort.

Would it really be a lot of duplication?  That's hard to say at this
point, since I know of only one implementation.  It's still far too
early to say what the common features will be that all subsystems can
share.  Until we do have at least a rough idea, trying to set up a 
runtime PM core would be a waste of time.

For example, if we had runtime PM implemented in USB, SCSI, and PCI --
and we knew what sort of communication was needed between them -- then
we'd be ready to change the PM or driver core.  I don't think we're 
there yet.

Alan Stern

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Montag 24 September 2007 schrieb Alan Stern:
> On Mon, 24 Sep 2007, Oliver Neukum wrote:

> > But we don't bother when suspending the whole system. So why not simply
> > walk the subtrees under a USB device? Let the subsystem choose what
> > depth of sleep to use.
> 
> Because by doing so you are effectively telling the drivers in the
> subtree that the entire system is going to be suspended, which isn't

Unfortunately, that is correct.

> correct.  It may also turn out that the user wants to keep the
> subsystem active, even though the USB driver isn't aware of it.  Last
> but not least, the subsystem will need to have some form of autoresume.  

Not necessarily.
 
> The way it should work is for the lower subsystem to tell the USB
> driver when suspending is okay, not the other way around.  When the

Absolutely.

> subsystem implements its own form of runtime PM support, then you'll be
> able to use it properly.  But until then, there isn't anything much you
> can do.

Well, we can't simply cut power. Buffers must be flushed and the disk
spun down. The suspend() method of the storage driver will have to become
complex.
 
	Regards
		Oliver

Re: question on flushing buffers and spinning down disk

[Alan Stern]

On Mon, 24 Sep 2007, Oliver Neukum wrote:

> > subsystem implements its own form of runtime PM support, then you'll be
> > able to use it properly.  But until then, there isn't anything much you
> > can do.
> 
> Well, we can't simply cut power. Buffers must be flushed and the disk
> spun down. The suspend() method of the storage driver will have to become
> complex.

That's right, if the device is a real disk.  If it's a flash memory
device then of course these issues don't arise.  Unfortunately the
driver isn't able to tell one from the other; the user will have to
do that for us.

So for now we can simply rely on the defaults being set right: USB
autosuspend is normally disabled, but the user can enable it if desired
(and if the device can handle it).  It would be nice if we had some way 
to warn people that enabling autosuspend for real disk drives might be 
a bad idea...  Maybe a section in the linux-usb.org FAQ would help, 
plus a file under Documentation/usb.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Montag 24 September 2007 schrieb Alan Stern:
> On Mon, 24 Sep 2007, Oliver Neukum wrote:
> 
> > > subsystem implements its own form of runtime PM support, then you'll be
> > > able to use it properly.  But until then, there isn't anything much you
> > > can do.
> > 
> > Well, we can't simply cut power. Buffers must be flushed and the disk
> > spun down. The suspend() method of the storage driver will have to become
> > complex.
> 
> That's right, if the device is a real disk.  If it's a flash memory
> device then of course these issues don't arise.  Unfortunately the
> driver isn't able to tell one from the other; the user will have to
> do that for us.

So those devices which draw most power we don't suspend :-(
Furthermore for many devices it will take real user intervention to
determine what is in the enclosure. This isn't very good. I think
we can do better.

	Regards
		Oliver

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Montag 24 September 2007 schrieb Alan Stern:
> On Mon, 24 Sep 2007, Oliver Neukum wrote:
> 
> > > subsystem implements its own form of runtime PM support, then you'll be
> > > able to use it properly.  But until then, there isn't anything much you
> > > can do.
> > 
> > Well, we can't simply cut power. Buffers must be flushed and the disk
> > spun down. The suspend() method of the storage driver will have to become
> > complex.
> 
> That's right, if the device is a real disk.  If it's a flash memory
> device then of course these issues don't arise.  Unfortunately the

With respect to buffers how sure are you about that?

> driver isn't able to tell one from the other; the user will have to
> do that for us.

Code for what we need is in sd_suspend(). The only trouble is locking.
We need to make sure no commands that dirty buffers are issued after
flushing the buffers.

	Regards
		Oliver

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Alan Stern]

On Mon, 24 Sep 2007, Oliver Neukum wrote:

> Am Montag 24 September 2007 schrieb Alan Stern:
> > On Mon, 24 Sep 2007, Oliver Neukum wrote:
> > 
> > > > subsystem implements its own form of runtime PM support, then you'll be
> > > > able to use it properly.  But until then, there isn't anything much you
> > > > can do.
> > > 
> > > Well, we can't simply cut power. Buffers must be flushed and the disk
> > > spun down. The suspend() method of the storage driver will have to become
> > > complex.
> > 
> > That's right, if the device is a real disk.  If it's a flash memory
> > device then of course these issues don't arise.  Unfortunately the
> > driver isn't able to tell one from the other; the user will have to
> > do that for us.
> 
> So those devices which draw most power we don't suspend :-(
> Furthermore for many devices it will take real user intervention to
> determine what is in the enclosure. This isn't very good. I think
> we can do better.

If by "we" you mean the Linux kernel in general, then I agree.  If by
"we" you mean the USB developers, then I disagree.  Help is needed from
the SCSI people.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Alan Stern]

On Tue, 25 Sep 2007, Oliver Neukum wrote:

> Am Montag 24 September 2007 schrieb Alan Stern:
> > On Mon, 24 Sep 2007, Oliver Neukum wrote:
> > 
> > > > subsystem implements its own form of runtime PM support, then you'll be
> > > > able to use it properly.  But until then, there isn't anything much you
> > > > can do.
> > > 
> > > Well, we can't simply cut power. Buffers must be flushed and the disk
> > > spun down. The suspend() method of the storage driver will have to become
> > > complex.
> > 
> > That's right, if the device is a real disk.  If it's a flash memory
> > device then of course these issues don't arise.  Unfortunately the
> 
> With respect to buffers how sure are you about that?

Well, I'm not intimately familiar with the design of these chips.  But 
as long as the device remains powered, internally-buffered data 
shouldn't be lost.  It should be written out to flash storage when the 
device is resumed.

Are you worried about what might happen if the device is unplugged 
while it is still suspended?  Then yes, there is a risk of data loss.  
But that's also true if the device isn't suspended -- unplugging it 
without flushing its buffers could lose some data.

> > driver isn't able to tell one from the other; the user will have to
> > do that for us.
> 
> Code for what we need is in sd_suspend(). The only trouble is locking.
> We need to make sure no commands that dirty buffers are issued after
> flushing the buffers.

No -- _we_ don't need to do that.  The sd driver needs to, by making 
sure that once the buffers have been flushed, any new commands will 
cause sd_resume() to be called.

That's what I meant when I said that sd has to support autoresume.

In addition, sd_suspend() and sd_resume() have to pass information up
the stack.  sd_suspend() has to let the SCSI core know that there is
one less active device on the bus, and when there are no active devices
left then the SCSI core has to call the LLD (in this case, usb-storage)  
to tell it the host adapter can be suspended.

Likewise, before sd_resume() runs it has to tell the SCSI core that the
bus needs to be active, and if the bus is suspended then the SCSI core
has to tell the LLD that the host adapter must be resumed.

The same reasoning applies to sr and any other high-level SCSI drivers
that might get written.  sg and SG_IO might present problems, since
they effectively are additional interfaces to the same devices already
managed by sd and sr -- they could be treated more or less the way we
treat access through usbfs.

Getting all this to work will be tricky, because sd is a block device
driven by requests issued through the block layer in atomic context,
whereas suspend and resume require a process context.  Probably the 
SCSI core would have to get involved in managing the synchronization.

Alan Stern

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Dienstag 25 September 2007 schrieb Alan Stern:
> > Furthermore for many devices it will take real user intervention to
> > determine what is in the enclosure. This isn't very good. I think
> > we can do better.
> 
> If by "we" you mean the Linux kernel in general, then I agree.  If by
> "we" you mean the USB developers, then I disagree.  Help is needed from
> the SCSI people.

I am working on it. It seems to me that all necessary functions exist.

	Regards
		Oliver

PS: Whoever designed klists is suffering from a case of overengineeringosis.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Dienstag 25 September 2007 schrieb Alan Stern:
> Getting all this to work will be tricky, because sd is a block device
> driven by requests issued through the block layer in atomic context,
> whereas suspend and resume require a process context.  Probably the 
> SCSI core would have to get involved in managing the synchronization.


Well,

here's a patch that seems to do what needs to be done to make it work.

	Regards
		Oliver

----

--- a/drivers/usb/storage/usb.c	2007-09-27 13:33:31.000000000 +0200
+++ b/drivers/usb/storage/usb.c	2007-09-27 13:30:21.000000000 +0200
@@ -182,33 +182,100 @@ static struct us_unusual_dev us_unusual_
 
 static int storage_suspend(struct usb_interface *iface, pm_message_t message)
 {
+	struct device *child;
 	struct us_data *us = usb_get_intfdata(iface);
+	struct Scsi_Host *host = us_to_host(us);
+	struct scsi_device *sdev, *sdev2 = NULL;
+	int err = 0;
+
+	/* In case of autosuspend we need to do extra work to flush
+	 * buffers and spin down disks. */
+	if (us->pusb_dev->auto_pm) {
+		US_DEBUGP("Autosuspend code path.\n");
+		/* block all devices against block and user space io */
+		shost_for_each_device(sdev, host) {
+			US_DEBUGP("Quiescing device.\n");
+			err = scsi_device_quiesce(sdev);
+			US_DEBUGP("Quiesced device with result %d.\n", err);
+			if (err < 0) {
+				sdev2 = sdev;
+				err = -EIO;
+				scsi_device_put(sdev);
+				goto err_unblock;
+			}
+			child = &sdev->sdev_gendev;
+			if (!child->driver || !child->driver->suspend)
+				continue;
+			US_DEBUGP("About to suspend disk.\n");
+			/* flush the buffers and spin down */
+			err = (child->driver->suspend)(child, message);
+			if (err < 0) {
+				US_DEBUGP("Could not suspend disk.\n");
+				sdev2 = sdev;
+				shost_for_each_device(sdev, host) {
+					if (sdev == sdev2) {
+						scsi_device_put(sdev);
+						break;
+					}
+					child = &sdev->sdev_gendev;
+					if (!child->driver || !child->driver->resume)
+						continue;
+					(child->driver->resume)(child);
+				}
+				err = -EIO;
+				sdev2 = NULL;
+				scsi_device_put(sdev);
+				goto err_unblock;
+			}
+		}
+	}
+
+	US_DEBUGP("%s\n", __FUNCTION__);
 
 	/* Wait until no command is running */
 	mutex_lock(&us->dev_mutex);
 
-	US_DEBUGP("%s\n", __FUNCTION__);
 	if (us->suspend_resume_hook)
 		(us->suspend_resume_hook)(us, US_SUSPEND);
 
-	/* When runtime PM is working, we'll set a flag to indicate
-	 * whether we should autoresume when a SCSI request arrives. */
-
 	mutex_unlock(&us->dev_mutex);
-	return 0;
+
+	/* In case of autosuspend device must be unblocked again */
+	if (us->pusb_dev->auto_pm) {
+err_unblock:
+		shost_for_each_device(sdev, host) {
+			if (sdev == sdev2) {
+				scsi_device_put(sdev);
+				break;
+			}
+			scsi_device_resume(sdev);
+		}
+	}
+	return err;
 }
 
 static int storage_resume(struct usb_interface *iface)
 {
 	struct us_data *us = usb_get_intfdata(iface);
+	struct Scsi_Host *host;
+	struct scsi_device *sdev;
+	struct device *child;
 
-	mutex_lock(&us->dev_mutex);
+	if (us->pusb_dev->auto_pm) {
+		host = us_to_host(us);
+		shost_for_each_device(sdev, host) {
+			child = &sdev->sdev_gendev;
+			if (!child->driver || !child->driver->resume)
+				continue;
+			(child->driver->resume)(child);
+		}
+	}
 
 	US_DEBUGP("%s\n", __FUNCTION__);
+
 	if (us->suspend_resume_hook)
 		(us->suspend_resume_hook)(us, US_RESUME);
 
-	mutex_unlock(&us->dev_mutex);
 	return 0;
 }
 
@@ -306,6 +373,7 @@ static int usb_stor_control_thread(void 
 {
 	struct us_data *us = (struct us_data *)__us;
 	struct Scsi_Host *host = us_to_host(us);
+	int autopm_rc;
 
 	for(;;) {
 		US_DEBUGP("*** thread sleeping.\n");
@@ -314,6 +382,9 @@ static int usb_stor_control_thread(void 
 			
 		US_DEBUGP("*** thread awakened.\n");
 
+		/* Autoresume the device */
+		autopm_rc = usb_autopm_get_interface(us->pusb_intf);
+
 		/* lock the device pointers */
 		mutex_lock(&(us->dev_mutex));
 
@@ -372,6 +443,12 @@ static int usb_stor_control_thread(void 
 			us->srb->result = SAM_STAT_GOOD;
 		}
 
+		/* Did the autoresume fail? */
+		else if (autopm_rc < 0) {
+			US_DEBUGP("Could not wake device\n");
+			us->srb->result = DID_ERROR << 16;
+		}
+
 		/* we've got a command, let's do it! */
 		else {
 			US_DEBUG(usb_stor_show_command(us->srb));
@@ -414,6 +491,10 @@ SkipForAbort:
 
 		/* unlock the device pointers */
 		mutex_unlock(&us->dev_mutex);
+
+		/* Start an autosuspend */
+		if (autopm_rc == 0)
+			usb_autopm_put_interface(us->pusb_intf);
 	} /* for (;;) */
 
 	/* Wait until we are told to stop */
@@ -931,6 +1012,7 @@ retry:
 		/* Should we unbind if no devices were detected? */
 	}
 
+	usb_autopm_put_interface(us->pusb_intf);
 	complete_and_exit(&us->scanning_done, 0);
 }
 
@@ -1016,6 +1098,7 @@ static int storage_probe(struct usb_inte
 		goto BadDevice;
 	}
 
+	usb_autopm_get_interface(intf); /* dropped in the scanning thread */
 	wake_up_process(th);
 
 	return 0;
@@ -1053,6 +1136,7 @@ static struct usb_driver usb_storage_dri
 	.pre_reset =	storage_pre_reset,
 	.post_reset =	storage_post_reset,
 	.id_table =	storage_usb_ids,
+	.supports_autosuspend = 1,
 };
 
 static int __init usb_stor_init(void)
--- a/drivers/usb/storage/scsiglue.c	2007-09-27 13:33:31.000000000 +0200
+++ b/drivers/usb/storage/scsiglue.c	2007-09-25 13:24:20.000000000 +0200
@@ -285,10 +285,15 @@ static int device_reset(struct scsi_cmnd
 
 	US_DEBUGP("%s called\n", __FUNCTION__);
 
-	/* lock the device pointers and do the reset */
-	mutex_lock(&(us->dev_mutex));
-	result = us->transport_reset(us);
-	mutex_unlock(&us->dev_mutex);
+	result = usb_autopm_get_interface(us->pusb_intf);
+	if (result == 0) {
+
+		/* lock the device pointers and do the reset */
+		mutex_lock(&(us->dev_mutex));
+		result = us->transport_reset(us);
+		mutex_unlock(&us->dev_mutex);
+		usb_autopm_put_interface(us->pusb_intf);
+	}
 
 	return result < 0 ? FAILED : SUCCESS;
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Alan Stern]

On Thu, 27 Sep 2007, Oliver Neukum wrote:

> Am Dienstag 25 September 2007 schrieb Alan Stern:
> > Getting all this to work will be tricky, because sd is a block device
> > driven by requests issued through the block layer in atomic context,
> > whereas suspend and resume require a process context.  Probably the 
> > SCSI core would have to get involved in managing the synchronization.
> 
> 
> Well,
> 
> here's a patch that seems to do what needs to be done to make it work.

Oliver, I'm surprised at you!  This patch is a big hack, not to mention 
a layering violation and an inversion of the proper calling sequence.

Alan Stern


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Donnerstag 27 September 2007 schrieb Alan Stern:
> On Thu, 27 Sep 2007, Oliver Neukum wrote:
> 
> > Am Dienstag 25 September 2007 schrieb Alan Stern:
> > > Getting all this to work will be tricky, because sd is a block device
> > > driven by requests issued through the block layer in atomic context,
> > > whereas suspend and resume require a process context.  Probably the 
> > > SCSI core would have to get involved in managing the synchronization.
> > 
> > 
> > Well,
> > 
> > here's a patch that seems to do what needs to be done to make it work.
> 
> Oliver, I'm surprised at you!  This patch is a big hack, not to mention 
> a layering violation and an inversion of the proper calling sequence.

Well,

1. autosuspend should not be specific to USB
2. I like to view the generic SCSI code as a library
3. The low level drivers will have to decide whether to suspend devices,
as the generic code doesn't know whether the bus is shared.

	Regards
		Oliver

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Alan Stern]

On Thu, 27 Sep 2007, Oliver Neukum wrote:

> > Oliver, I'm surprised at you!  This patch is a big hack, not to mention 
> > a layering violation and an inversion of the proper calling sequence.
> 
> Well,
> 
> 1. autosuspend should not be specific to USB

Correct.  Which means support for it should be added to the SCSI
drivers.  SCSI autosuspend shouldn't be kluged into usb-storage in a
way that basically ignores what the SCSI layer is doing.

> 2. I like to view the generic SCSI code as a library

That viewpoint might work out okay in some cases, but I don't think 
it's tenable when dealing with high-level drivers like sd and sr.

> 3. The low level drivers will have to decide whether to suspend devices,
> as the generic code doesn't know whether the bus is shared.

I'm having trouble understanding this; it's a bit ambiguous.  Does
"devices" mean "SCSI devices", "host adapter devices", or both?  Does
"generic code" refer to the SCSI core, the high-level SCSI drivers, or
something else?  When you say the bus is "shared", do you mean there
are multiple SCSI devices attached to it or do you mean something else?  
(I assume you mean something else, as the SCSI core certainly does know
when multiple SCSI devices are attached to a SCSI bus.)

In any case, that's not how I would put it.  The SCSI core and
high-level drivers will have to decide when they are not using SCSI
devices and the devices can be suspended.  When all the devices the
SCSI core knows about are suspended, it should tell the LLD.  Then the
LLD can suspend the bus and the host adapter, whatever is appropriate,
based on its own private knowledge.

Alan Stern

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Donnerstag 27 September 2007 schrieb Alan Stern:
> On Thu, 27 Sep 2007, Oliver Neukum wrote:
> 
> > > Oliver, I'm surprised at you!  This patch is a big hack, not to mention 
> > > a layering violation and an inversion of the proper calling sequence.
> > 
> > Well,
> > 
> > 1. autosuspend should not be specific to USB
> 
> Correct.  Which means support for it should be added to the SCSI
> drivers.  SCSI autosuspend shouldn't be kluged into usb-storage in a
> way that basically ignores what the SCSI layer is doing.

It isn't. The decision to autosuspend is based on activity on the bus.
Now you might argue that the decision to do an autosuspend should
always propagate upwards from the lowest level of the device tree.
Then I ask why?

> > 2. I like to view the generic SCSI code as a library
> 
> That viewpoint might work out okay in some cases, but I don't think 
> it's tenable when dealing with high-level drivers like sd and sr.

sg worries me.
 
> > 3. The low level drivers will have to decide whether to suspend devices,
> > as the generic code doesn't know whether the bus is shared.
> 
> I'm having trouble understanding this; it's a bit ambiguous.  Does
> "devices" mean "SCSI devices", "host adapter devices", or both?  Does

SCSI devices

> "generic code" refer to the SCSI core, the high-level SCSI drivers, or
> something else?  When you say the bus is "shared", do you mean there
> are multiple SCSI devices attached to it or do you mean something else?

No multiple hosts. Think Firewire or FibreChannel. We certainly cannot
spin down a Firewire disk some other host is using just because we
are done with it.

> (I assume you mean something else, as the SCSI core certainly does know
> when multiple SCSI devices are attached to a SCSI bus.)
> 
> In any case, that's not how I would put it.  The SCSI core and
> high-level drivers will have to decide when they are not using SCSI
> devices and the devices can be suspended.  When all the devices the

Err, why? After all, there's a central instance in userspace that decides
that the whole system isn't used right now. I see no reason to not use
this model for parts of the device tree.

	Regards
		Oliver

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Alan Stern]

On Thu, 27 Sep 2007, Oliver Neukum wrote:

> > > 1. autosuspend should not be specific to USB
> > 
> > Correct.  Which means support for it should be added to the SCSI
> > drivers.  SCSI autosuspend shouldn't be kluged into usb-storage in a
> > way that basically ignores what the SCSI layer is doing.
> 
> It isn't. The decision to autosuspend is based on activity on the bus.
> Now you might argue that the decision to do an autosuspend should
> always propagate upwards from the lowest level of the device tree.
> Then I ask why?

Because that's how I have always thought of it...  :-)

You're right; there's no showstopping reason particular subsystems like
SCSI can't use a different approach.  However bus activity alone isn't
a sufficient criterion.  For example, suppose somebody sends a PLAY
AUDIO command to a SCSI cdrom drive.  There won't be any bus activity
while the music is playing, but the device will be active and so it
shouldn't be suspended.  Thus the sr driver would want to fail an
autosuspend call.

Anyway, if we do end up going this route then there should be a routine
added to the SCSI core which would call the suspend methods for all the
attached devices.  This doesn't belong in usb-storage (and even worse, 
it shouldn't be duplicated in all the other low-level drivers); rather,
usb-storage should simply be able to call the new routine.

Have you thought about how autoresume would fit into this picture?  I
don't think you can rely on usb-storage telling the SCSI core to resume
devices when it gets handed a command, because the commands to spin-up
the drives would have to be transmitted first.  (The sample patch you
posted will deadlock: The other command can't begin until the spin-up
command completes, and the spin-up command won't get sent to
usb-storage until the original command completes.)  In other words,
autoresume must be handled at the level of the SCSI core.

What happens if you want to autosuspend some of the devices on a SCSI
bus but not all of them?  Obviously usb-storage wouldn't be able to
handle that, since all it knows about is overall bus activity.

> > > 2. I like to view the generic SCSI code as a library
> > 
> > That viewpoint might work out okay in some cases, but I don't think 
> > it's tenable when dealing with high-level drivers like sd and sr.
> 
> sg worries me.

Let's not worry about it for now.

> > > 3. The low level drivers will have to decide whether to suspend devices,
> > > as the generic code doesn't know whether the bus is shared.
> > 
> > I'm having trouble understanding this; it's a bit ambiguous.  Does
> > "devices" mean "SCSI devices", "host adapter devices", or both?  Does
> 
> SCSI devices
> 
> > "generic code" refer to the SCSI core, the high-level SCSI drivers, or
> > something else?  When you say the bus is "shared", do you mean there
> > are multiple SCSI devices attached to it or do you mean something else?
> 
> No multiple hosts. Think Firewire or FibreChannel. We certainly cannot
> spin down a Firewire disk some other host is using just because we
> are done with it.

But what if no other hosts are attached?  Would you still want to avoid 
spinning down the disk?  Would the disk somehow have to become 
responsible for spinning itself down?  Anyway, this isn't usb-storage's 
problem.

(For that matter, do the Firewire or FibreChannel drivers know when
other hosts are sharing the bus?)

> > In any case, that's not how I would put it.  The SCSI core and
> > high-level drivers will have to decide when they are not using SCSI
> > devices and the devices can be suspended.  When all the devices the
> 
> Err, why? After all, there's a central instance in userspace that decides
> that the whole system isn't used right now. I see no reason to not use
> this model for parts of the device tree.

Autoresume is the major complication.

There's also a philosophical objection.  Who is in a better position to
judge when a device like a SCSI drive should be autosuspended: its own
driver (sd) or someone else (usb-storage)?

Alan Stern

RE: [linux-usb-devel] question on flushing buffers and spinning down disk

[Steve Calfee]

> Date: Thu, 27 Sep 2007 16:26:56 -0400
> From: stern@rowland.harvard.edu
> To: oliver@neukum.org
> CC: James.Bottomley@steeleye.com; linux-usb-devel@lists.sourceforge.net; linux-scsi@vger.kernel.org
> Subject: Re: [linux-usb-devel] question on flushing buffers and spinning down disk
>
> On Thu, 27 Sep 2007, Oliver Neukum wrote:
>
>>>> 1. autosuspend should not be specific to USB
>>>
>>> Correct. Which means support for it should be added to the SCSI
>>> drivers. SCSI autosuspend shouldn't be kluged into usb-storage in a
>>> way that basically ignores what the SCSI layer is doing.
>>
>> It isn't. The decision to autosuspend is based on activity on the bus.
>> Now you might argue that the decision to do an autosuspend should
>> always propagate upwards from the lowest level of the device tree.
>> Then I ask why?



>> Err, why? After all, there's a central instance in userspace that decides
>> that the whole system isn't used right now. I see no reason to not use
>> this model for parts of the device tree.
>
> Autoresume is the major complication.
>
> There's also a philosophical objection. Who is in a better position to
> judge when a device like a SCSI drive should be autosuspended: its own
> driver (sd) or someone else (usb-storage)?
>

Isn't power saving a policy decision? Should it not be left to userspace to control?

Doesn't userspace decide to blank the video based on user preferences? Userspace could jump through all sorts of hoops to wait for disks to spin down, etc on the way to powersaving.

If we really need the capability to suspend a mouse/keyboard etc after 2-n seconds of no use, shouldn't it be userspace that enables the "autosuspend"? Has the battery life impact of the various device shutdowns been measured and found useful?

Just a bunch of questions, but it seems to me that what is really needed is a mechanism for userspace to do fine grained power control.

Regards, Steve
_________________________________________________________________
Connect to the next generation of MSN Messenger 
http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: question on flushing buffers and spinning down disk

[Alan Stern]

On Thu, 27 Sep 2007, Steve Calfee wrote:

> Isn't power saving a policy decision?

Whether or not power saving should be implemented and under what 
conditions it should occur are indeed policy decisions.  However the 
decision to actually power-down a device (because the specified 
conditions have occurred) is not a policy decision -- it is an action 
to carry out a policy.

>  Should it not be left to
> userspace to control?

No.  You shouldn't expect users to run a program that would notice a 
particular disk drive hasn't been used in X minutes and then power it 
down.  (Although they could if they wanted to... except that there's no 
way for userspace to know when the drive was most recently used.)

> Doesn't userspace decide to blank the video based on user
> preferences?

The X server runs in userspace, yes.  However VT console blanking is 
part of the kernel.  So it works both ways.

> Userspace could jump through all sorts of hoops to wait
> for disks to spin down, etc on the way to powersaving.

I'm not sure what you mean here.  What I have described is the way
Windows works, for example.  You tell the system how long you want it
to wait before spinning down an idle drive and it takes care of
everything else; you don't have to tell it each time you want the drive
spun down.

> If we really need the capability to suspend a mouse/keyboard etc
> after 2-n seconds of no use, shouldn't it be userspace that enables
> the "autosuspend"?

If by "enables" you mean that userspace tells the system the value of 
n, then yes.  If you mean that userspace waits until the mouse/keyboard 
has been inactive for n seconds and tells the system to suspend it, 
then no.  (That wouldn't be an autosuspend anyway -- it would be a 
manual suspend.)

> Has the battery life impact of the various device
> shutdowns been measured and found useful?

Yes.

> Just a bunch of questions, but it seems to me that what is really
> needed is a mechanism for userspace to do fine grained power control.

There is such a mechanism, for USB at least.  (Not well documented yet;  
I'm working on it.)  If userspace wants to, it can disable autosuspend
and do everything manually.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: question on flushing buffers and spinning down disk

[U. George]

> No.  You shouldn't expect users to run a program that would notice a 
> particular disk drive hasn't been used in X minutes and then power it 
> down.  (Although they could if they wanted to... except that there's no 
> way for userspace to know when the drive was most recently used.)

I use noflushd to do userspace powerdowns for internal (ide) drives.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Greg KH]

On Tue, Sep 25, 2007 at 05:11:00PM +0200, Oliver Neukum wrote:
> 
> PS: Whoever designed klists is suffering from a case of overengineeringosis.

No objection from me there.  If you can think of a way to do list
traversal without taking locks, please, feel free to redo the whole
klist stuff.

As it was, Pat emerged out of nowhere, threw the code at us, it fixed
some locking issues I was trying to solve at the time, so I added it.
Then he ran away to a different continent :(

Oh well...

greg k-h

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Freitag 28 September 2007 schrieb Greg KH:
> On Tue, Sep 25, 2007 at 05:11:00PM +0200, Oliver Neukum wrote:
> > 
> > PS: Whoever designed klists is suffering from a case of overengineeringosis.
> 
> No objection from me there.  If you can think of a way to do list
> traversal without taking locks, please, feel free to redo the whole
> klist stuff.

No, I just was happy to be able to avoid using them.

But it is not just overengineered, it is also underengineered:

int bus_for_each_dev(struct bus_type * bus, struct device * start,
		     void * data, int (*fn)(struct device *, void *))

An interface should be designed to note where it fails, thus:

int bus_for_each_dev(struct bus_type * bus, struct device ** current,
		     void * data, int (*fn)(struct device *, void *))

	Regards
		Oliver

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Donnerstag 27 September 2007 schrieb Alan Stern:
> On Thu, 27 Sep 2007, Oliver Neukum wrote:
> 
> > > > 1. autosuspend should not be specific to USB
> > > 
> > > Correct.  Which means support for it should be added to the SCSI
> > > drivers.  SCSI autosuspend shouldn't be kluged into usb-storage in a
> > > way that basically ignores what the SCSI layer is doing.
> > 
> > It isn't. The decision to autosuspend is based on activity on the bus.
> > Now you might argue that the decision to do an autosuspend should
> > always propagate upwards from the lowest level of the device tree.
> > Then I ask why?
> 
> Because that's how I have always thought of it...  :-)
> 
> You're right; there's no showstopping reason particular subsystems like
> SCSI can't use a different approach.  However bus activity alone isn't
> a sufficient criterion.  For example, suppose somebody sends a PLAY
> AUDIO command to a SCSI cdrom drive.  There won't be any bus activity
> while the music is playing, but the device will be active and so it
> shouldn't be suspended.  Thus the sr driver would want to fail an
> autosuspend call.

sr isn't a device driver. Furthermore it is generic. It can't know whether
any power saving measure would prevent some activity from being carried
out. It seems to me that we need to be conservative. Any device that
is opened by user space must not be autosuspended. But how to fit this
into SCSI?

> Anyway, if we do end up going this route then there should be a routine
> added to the SCSI core which would call the suspend methods for all the
> attached devices.  This doesn't belong in usb-storage (and even worse, 
> it shouldn't be duplicated in all the other low-level drivers); rather,
> usb-storage should simply be able to call the new routine.

We are moving in circles. In an earlier thread you argued that a suspend
call should not walk the device tree in case of runtime power management.
 
> Have you thought about how autoresume would fit into this picture?  I
> don't think you can rely on usb-storage telling the SCSI core to resume
> devices when it gets handed a command, because the commands to spin-up
> the drives would have to be transmitted first.  (The sample patch you
> posted will deadlock: The other command can't begin until the spin-up
> command completes, and the spin-up command won't get sent to
> usb-storage until the original command completes.)  In other words,
> autoresume must be handled at the level of the SCSI core.

That's a difficult one. I need to ponder this a bit.
 
[..]

> There's also a philosophical objection.  Who is in a better position to
> judge when a device like a SCSI drive should be autosuspended: its own
> driver (sd) or someone else (usb-storage)?

SCSI doesn't know about power management. It cannot, it is not a notion
native to SCSI. It just knows how to safely put drives into a state other
than fully active (flushing buffers/spin down)
You are expecting too much of SCSI core.

	Regards
		Oliver

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Donnerstag 27 September 2007 schrieb Alan Stern:
> Have you thought about how autoresume would fit into this picture?  I
> don't think you can rely on usb-storage telling the SCSI core to resume
> devices when it gets handed a command, because the commands to spin-up
> the drives would have to be transmitted first.  (The sample patch you

Actually, it is not a big question. By default sd_resume() is a nop.
Usually the first SCSI command would return NOT_READY and SCSI core
do a START_STOP_UNIT only then in response.

	Regards
		Oliver

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Donnerstag 27 September 2007 schrieb Alan Stern:
> There's also a philosophical objection.  Who is in a better position to
> judge when a device like a SCSI drive should be autosuspended: its own
> driver (sd) or someone else (usb-storage)?

Then a philosophical answer. The highest entity which understands what
it is doing when using power management. Highest here to be understood
not as a position in the device tree, but in the flow of information.

That is in our case usb-storage. Sr or sd can't do it because they don't
and can't understand power management.
Now they might be asked to provide some helpers. An open count and
notifications about the state of the queue would be obvious. Other
suggestions?

	Regards
		Oliver

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: question on flushing buffers and spinning down disk

[Alan Stern]

On Fri, 28 Sep 2007, Oliver Neukum wrote:

> > You're right; there's no showstopping reason particular subsystems like
> > SCSI can't use a different approach.  However bus activity alone isn't
> > a sufficient criterion.  For example, suppose somebody sends a PLAY
> > AUDIO command to a SCSI cdrom drive.  There won't be any bus activity
> > while the music is playing, but the device will be active and so it
> > shouldn't be suspended.  Thus the sr driver would want to fail an
> > autosuspend call.
> 
> sr isn't a device driver.

That's a very surprising statement.  How do you justify it?

Certainly sr is much more of a device driver than something like the 
gendisk layer, which manages logical disks and partitions.  These 
things don't have an independent physical existence, but they show up 
in the device tree anyway.

>  Furthermore it is generic. It can't know whether
> any power saving measure would prevent some activity from being carried
> out.

It might not know in all cases, but it definitely does know in some 
cases.  We must not ignore that knowledge.

The example of suspending the USB transport to a cdrom device playing
music is an interesting one.  We really don't know whether suspending
the link would suspend the device, i.e., whether it would allow the
music to continue playing or not.  The behavior will vary from one
device to another, so we would have to be conservative and avoid
autosuspending the drive.

> It seems to me that we need to be conservative. Any device that
> is opened by user space must not be autosuspended. But how to fit this
> into SCSI?

"Opened by user space" is too strong.  It would include any device with 
a mounted filesystem, I think.  Also it doesn't handle the "cd drive 
playing music" example; once the PLAY AUDIO command has been sent, the 
device file can be closed and the music will continue autonomously.

> We are moving in circles. In an earlier thread you argued that a suspend
> call should not walk the device tree in case of runtime power management.

Shouldn't go down the device tree, yes.  (Runtime PM notifications do 
go up the tree.)  You are claiming that my earlier opinion was wrong; 
I'm not so sure it was.  Even if things could be done another way, my 
approach is the most straightforward.

> > Have you thought about how autoresume would fit into this picture?  I
> > don't think you can rely on usb-storage telling the SCSI core to resume
> > devices when it gets handed a command, because the commands to spin-up
> > the drives would have to be transmitted first.  (The sample patch you
> > posted will deadlock: The other command can't begin until the spin-up
> > command completes, and the spin-up command won't get sent to
> > usb-storage until the original command completes.)  In other words,
> > autoresume must be handled at the level of the SCSI core.
> 
> That's a difficult one. I need to ponder this a bit.

> Actually, it is not a big question. By default sd_resume() is a nop.
> Usually the first SCSI command would return NOT_READY and SCSI core
> do a START_STOP_UNIT only then in response.

Yes, but what about non-default situations where sd_resume() isn't a 
nop?

> > There's also a philosophical objection.  Who is in a better position to
> > judge when a device like a SCSI drive should be autosuspended: its own
> > driver (sd) or someone else (usb-storage)?
> 
> SCSI doesn't know about power management. It cannot, it is not a notion
> native to SCSI. It just knows how to safely put drives into a state other
> than fully active (flushing buffers/spin down)
> You are expecting too much of SCSI core.

I disagree.  While it's true that SCSI isn't cognizant of actual power
levels, Power Management includes several other attributes which _are_
relevant to SCSI, including special states, functionality, and latency.  
To this extent it makes sense for the SCSI drivers to be involved in PM
decisions.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: question on flushing buffers and spinning down disk

[Alan Stern]

On Fri, 28 Sep 2007, Oliver Neukum wrote:

> Am Donnerstag 27 September 2007 schrieb Alan Stern:
> > There's also a philosophical objection.  Who is in a better position to
> > judge when a device like a SCSI drive should be autosuspended: its own
> > driver (sd) or someone else (usb-storage)?
> 
> Then a philosophical answer. The highest entity which understands what
> it is doing when using power management. Highest here to be understood
> not as a position in the device tree, but in the flow of information.

In this sense, sd is higher than usb-storage, right?  Because I/O 
requests pass through sd first, then usb-storage, on their way to the 
device.

My point is that when dealing with SCSI disks, sd understands the 
implications of Power Management better than usb-storage does.  
Similarly, when dealing with SCSI cd drives, sr understands the 
implications of Power Management better than usb-storage.

Hence by your own argument, the SCSI high-level drivers should be 
responsible for autosuspending their respective devices.  usb-storage, 
on the other hand, should be responsible only for suspending the 
transport, since that's what it does understand.

> That is in our case usb-storage. Sr or sd can't do it because they don't
> and can't understand power management.

That's simply not true.  If sd didn't understand Power Management then 
sd_suspend() and sd_resume() would be empty.

> Now they might be asked to provide some helpers. An open count and
> notifications about the state of the queue would be obvious. Other
> suggestions?

I still think you're trying to go about it all backwards.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Greg KH]

On Fri, Sep 28, 2007 at 09:02:45AM +0200, Oliver Neukum wrote:
> Am Freitag 28 September 2007 schrieb Greg KH:
> > On Tue, Sep 25, 2007 at 05:11:00PM +0200, Oliver Neukum wrote:
> > > 
> > > PS: Whoever designed klists is suffering from a case of overengineeringosis.
> > 
> > No objection from me there. ?If you can think of a way to do list
> > traversal without taking locks, please, feel free to redo the whole
> > klist stuff.
> 
> No, I just was happy to be able to avoid using them.
> 
> But it is not just overengineered, it is also underengineered:
> 
> int bus_for_each_dev(struct bus_type * bus, struct device * start,
> 		     void * data, int (*fn)(struct device *, void *))
> 
> An interface should be designed to note where it fails, thus:
> 
> int bus_for_each_dev(struct bus_type * bus, struct device ** current,
> 		     void * data, int (*fn)(struct device *, void *))

You know that patches are always gladly accepted :)

thanks,

greg k-h

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Alan Stern]

On Fri, 28 Sep 2007, Oliver Neukum wrote:

> Am Donnerstag 27 September 2007 schrieb Alan Stern:
> > Have you thought about how autoresume would fit into this picture?  I
> > don't think you can rely on usb-storage telling the SCSI core to resume
> > devices when it gets handed a command, because the commands to spin-up
> > the drives would have to be transmitted first.  (The sample patch you

I had another look at your patch.  It calls scsi_device_quiesce(), 
which causes all normal requests to be deferred.  Hence under normal 
operation the device would never autoresume -- user requests would be 
deferred and never sent to usb-storage.

It will be necessary to modify scsi_prep_fn(), so that if the device is
in the SDEV_QUIESCE state because of autosuspend when a request
arrives, a workqueue routine initiates an autoresume.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Freitag 28 September 2007 schrieb Alan Stern:
> On Fri, 28 Sep 2007, Oliver Neukum wrote:
> 
> > Am Donnerstag 27 September 2007 schrieb Alan Stern:
> > > There's also a philosophical objection.  Who is in a better position to
> > > judge when a device like a SCSI drive should be autosuspended: its own
> > > driver (sd) or someone else (usb-storage)?
> > 
> > Then a philosophical answer. The highest entity which understands what
> > it is doing when using power management. Highest here to be understood
> > not as a position in the device tree, but in the flow of information.
> 
> In this sense, sd is higher than usb-storage, right?  Because I/O
> requests pass through sd first, then usb-storage, on their way to the 
> device.

Yes, but sr doesn't know hardware.

> My point is that when dealing with SCSI disks, sd understands the 
> implications of Power Management better than usb-storage does.  
> Similarly, when dealing with SCSI cd drives, sr understands the 
> implications of Power Management better than usb-storage.

No. The capabilities of the hardware are determined by USB.
USB imposes two strict rules.

1. The host cannot talk to a suspended device (keeping it suspended)
2. Power consumption is very limited

It makes no sense to talk about power management of devices as
such. You need to talk about devices on the bus type they are connected
to.
 
> Hence by your own argument, the SCSI high-level drivers should be 
> responsible for autosuspending their respective devices.  usb-storage, 
> on the other hand, should be responsible only for suspending the 
> transport, since that's what it does understand.

The weakest link of the chain determines the whole.
 
> > That is in our case usb-storage. Sr or sd can't do it because they don't
> > and can't understand power management.
> 
> That's simply not true.  If sd didn't understand Power Management then 
> sd_suspend() and sd_resume() would be empty.

It understands on and off. The methods simply do what is to be done
to safely switch off a disk.
 
> > Now they might be asked to provide some helpers. An open count and
> > notifications about the state of the queue would be obvious. Other
> > suggestions?
> 
> I still think you're trying to go about it all backwards.

I am using the point where the logical flow of information and the device
tree diverge.

	Regards
		Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Freitag 28 September 2007 schrieb Alan Stern:
> On Fri, 28 Sep 2007, Oliver Neukum wrote:
> 
> > Am Donnerstag 27 September 2007 schrieb Alan Stern:
> > > Have you thought about how autoresume would fit into this picture?  I
> > > don't think you can rely on usb-storage telling the SCSI core to resume
> > > devices when it gets handed a command, because the commands to spin-up
> > > the drives would have to be transmitted first.  (The sample patch you
> 
> I had another look at your patch.  It calls scsi_device_quiesce(), 
> which causes all normal requests to be deferred.  Hence under normal 
> operation the device would never autoresume -- user requests would be 
> deferred and never sent to usb-storage.

Unless I am very mistaken, further down in storage_suspend, I call

+	/* In case of autosuspend device must be unblocked again */
+	if (us->pusb_dev->auto_pm) {
+err_unblock:
+		shost_for_each_device(sdev, host) {
+			if (sdev == sdev2) {
+				scsi_device_put(sdev);
+				break;
+			}
+			scsi_device_resume(sdev);

which again allows normal io, so the autoresume is triggered.
It may deadlock, you are right about that, but it is definitely triggered.
I verified that experimentally.

	Regards
		Oliver


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: question on flushing buffers and spinning down disk

[Alan Stern]

On Fri, 28 Sep 2007, Oliver Neukum wrote:

> Unless I am very mistaken, further down in storage_suspend, I call
> 
> +	/* In case of autosuspend device must be unblocked again */
> +	if (us->pusb_dev->auto_pm) {
> +err_unblock:
> +		shost_for_each_device(sdev, host) {
> +			if (sdev == sdev2) {
> +				scsi_device_put(sdev);
> +				break;
> +			}
> +			scsi_device_resume(sdev);
> 
> which again allows normal io, so the autoresume is triggered.
> It may deadlock, you are right about that, but it is definitely triggered.
> I verified that experimentally.

Yes, okay, sorry, I didn't read far enough into the patch.

Still, doesn't it seem peculiar that to implement autosuspend you have 
to quiesce the device and then reactivate it?  In fact, it's not clear 
why you want to call scsi_device_quiesce() in the first place.  The 
fact that scsi_bus_suspend() does it isn't a good reason.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Samstag 29 September 2007 schrieb Alan Stern:
> On Fri, 28 Sep 2007, Oliver Neukum wrote:
> 
> > Unless I am very mistaken, further down in storage_suspend, I call
> > 
> > +	/* In case of autosuspend device must be unblocked again */
> > +	if (us->pusb_dev->auto_pm) {
> > +err_unblock:
> > +		shost_for_each_device(sdev, host) {
> > +			if (sdev == sdev2) {
> > +				scsi_device_put(sdev);
> > +				break;
> > +			}
> > +			scsi_device_resume(sdev);
> > 
> > which again allows normal io, so the autoresume is triggered.
> > It may deadlock, you are right about that, but it is definitely triggered.
> > I verified that experimentally.
> 
> Yes, okay, sorry, I didn't read far enough into the patch.
> 
> Still, doesn't it seem peculiar that to implement autosuspend you have 
> to quiesce the device and then reactivate it?  In fact, it's not clear 
> why you want to call scsi_device_quiesce() in the first place.  The 
> fact that scsi_bus_suspend() does it isn't a good reason.

I can't have the buffers be dirtied after flushing them.

	Regards
		Oliver

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Alan Stern]

On Fri, 28 Sep 2007, Oliver Neukum wrote:

> Am Freitag 28 September 2007 schrieb Alan Stern:
> > On Fri, 28 Sep 2007, Oliver Neukum wrote:
> > 
> > > Am Donnerstag 27 September 2007 schrieb Alan Stern:
> > > > There's also a philosophical objection.  Who is in a better position to
> > > > judge when a device like a SCSI drive should be autosuspended: its own
> > > > driver (sd) or someone else (usb-storage)?
> > > 
> > > Then a philosophical answer. The highest entity which understands what
> > > it is doing when using power management. Highest here to be understood
> > > not as a position in the device tree, but in the flow of information.
> > 
> > In this sense, sd is higher than usb-storage, right?  Because I/O
> > requests pass through sd first, then usb-storage, on their way to the 
> > device.
> 
> Yes, but sr doesn't know hardware.

I don't know what that's supposed to mean.  And whatever that means, it
must be equally true that usb-storage doesn't know CD drives.  Or disk
drives, or flash memories, or SCSI tape drives, or ...  On the whole,
I'd say that usb-storage's lack of knowledge about SCSI devices greatly
outweighs sr's lack of knowledge about hardware.


> > My point is that when dealing with SCSI disks, sd understands the 
> > implications of Power Management better than usb-storage does.  
> > Similarly, when dealing with SCSI cd drives, sr understands the 
> > implications of Power Management better than usb-storage.
> 
> No. The capabilities of the hardware are determined by USB.
> USB imposes two strict rules.
> 
> 1. The host cannot talk to a suspended device (keeping it suspended)
> 2. Power consumption is very limited
> 
> It makes no sense to talk about power management of devices as
> such. You need to talk about devices on the bus type they are connected
> to.

You forget that the USB bus ends at the USB interface chip on the
device.  From there on it's a different sort of bus.  It might be ATA,
as in commonly-available USB-ATA converter boxes.  It might be a
genuine SCSI bus, as in some USB-SCSI bridges.  It might be an internal
flash-memory "bus".  It might be a full-blown Linux gadget.  And so on.

The suspend done by usb-storage suspends only the USB part of the link.  
It might or might not affect anything beyond the device's USB chip, 
depending on how the device was designed.

Your (1) is correct, since all communication must take place over the
USB link.  Your (2) is wrong -- the _link_'s power consumption is
indeed limited, but the _device_ could be self-powered and so its power
consumption need not be affected by the link state.  For instance in
the case of a USB-ATA drive enclosure, power consumption is affected
more by whether or not the disk is spinning than anything else.

> > Hence by your own argument, the SCSI high-level drivers should be 
> > responsible for autosuspending their respective devices.  usb-storage, 
> > on the other hand, should be responsible only for suspending the 
> > transport, since that's what it does understand.
> 
> The weakest link of the chain determines the whole.

We're talking about conserving energy, not destroying chains.  :-)

> > > That is in our case usb-storage. Sr or sd can't do it because they don't
> > > and can't understand power management.
> > 
> > That's simply not true.  If sd didn't understand Power Management then 
> > sd_suspend() and sd_resume() would be empty.
> 
> It understands on and off. The methods simply do what is to be done
> to safely switch off a disk.

That's arguable, at least as regards START-STOP UNIT.  Spinning down a
disk is more than just preparation; it is itself a power-saving
measure.

And anyway, that's beside the point.  The SCSI drivers do what they can
or what they must -- it's none of usb-storage's business.  All
usb-storage cares about is whether the link will be needed, and the
only code that can tell it is the code that uses the link -- i.e., the 
SCSI drivers.


> > > Now they might be asked to provide some helpers. An open count and
> > > notifications about the state of the queue would be obvious. Other
> > > suggestions?
> > 
> > I still think you're trying to go about it all backwards.
> 
> I am using the point where the logical flow of information and the device
> tree diverge.

I don't understand that.

Suppose we have devices A1 and A2, where A1 is the parent and A2 is the 
child.  In order to pass between the CPU and A2, data must flow through 
A1.  Let D1 and D2 be the drivers for A1 and A2.

It may be that for D2 to communicate with A2, it has to ask D1 to send 
or receive the data for it.  Or it may be that once D1 has configured 
A1, data can flow automatically through A1 with no need for further 
involvement on D1's part.  Would you say that in either case the flow 
of information has diverged from the device tree?

Suppose D1 decides that it wants to suspend A1, thus breaking the data
link to A2.  Shouldn't it get D2's permission first?  Better yet,
shouldn't it wait until D2 tells it: "Okay, A2 is safely suspended and
I'm not going to talk to it for a while, you can suspend the link"?

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Samstag 29 September 2007 schrieb Alan Stern:
> On Fri, 28 Sep 2007, Oliver Neukum wrote:
> 
> > Am Freitag 28 September 2007 schrieb Alan Stern:
> > > On Fri, 28 Sep 2007, Oliver Neukum wrote:

> I don't know what that's supposed to mean.  And whatever that means, it
> must be equally true that usb-storage doesn't know CD drives.  Or disk
> drives, or flash memories, or SCSI tape drives, or ...  On the whole,
> I'd say that usb-storage's lack of knowledge about SCSI devices greatly
> outweighs sr's lack of knowledge about hardware.

Neither driver knows enough to completely do power management.

> > > My point is that when dealing with SCSI disks, sd understands the 
> > > implications of Power Management better than usb-storage does.  
> > > Similarly, when dealing with SCSI cd drives, sr understands the 
> > > implications of Power Management better than usb-storage.
> > 
> > No. The capabilities of the hardware are determined by USB.
> > USB imposes two strict rules.
> > 
> > 1. The host cannot talk to a suspended device (keeping it suspended)
> > 2. Power consumption is very limited
> > 
> > It makes no sense to talk about power management of devices as
> > such. You need to talk about devices on the bus type they are connected
> > to.
> 
> You forget that the USB bus ends at the USB interface chip on the
> device.  From there on it's a different sort of bus.  It might be ATA,
> as in commonly-available USB-ATA converter boxes.  It might be a
> genuine SCSI bus, as in some USB-SCSI bridges.  It might be an internal
> flash-memory "bus".  It might be a full-blown Linux gadget.  And so on.
> 
> The suspend done by usb-storage suspends only the USB part of the link.  
> It might or might not affect anything beyond the device's USB chip, 
> depending on how the device was designed.

Yes, but do we care about we don't see anyway?

> Your (1) is correct, since all communication must take place over the
> USB link.  Your (2) is wrong -- the _link_'s power consumption is
> indeed limited, but the _device_ could be self-powered and so its power
> consumption need not be affected by the link state.  For instance in
> the case of a USB-ATA drive enclosure, power consumption is affected
> more by whether or not the disk is spinning than anything else.

OK, yes, it is true only for bus powered devices. Do we really want
to differentiate that far? I suggest we assume the worst case.
 
[..]
> Suppose we have devices A1 and A2, where A1 is the parent and A2 is the 
> child.  In order to pass between the CPU and A2, data must flow through 
> A1.  Let D1 and D2 be the drivers for A1 and A2.
> 
> It may be that for D2 to communicate with A2, it has to ask D1 to send 
> or receive the data for it.  Or it may be that once D1 has configured 
> A1, data can flow automatically through A1 with no need for further 
> involvement on D1's part.  Would you say that in either case the flow 
> of information has diverged from the device tree?

In the latter case it diverges.

> Suppose D1 decides that it wants to suspend A1, thus breaking the data
> link to A2.  Shouldn't it get D2's permission first?  Better yet,
> shouldn't it wait until D2 tells it: "Okay, A2 is safely suspended and
> I'm not going to talk to it for a while, you can suspend the link"?

Ok, I should be much more explicit and try to to explain very clearly.

In short:
D1 should definitely get D2's permission. But waiting is not enough.

Suppose we have all child devices in a suspended state. Then we might ask
whether this is enough to be sure that you can the suspend the parent.
Unfortunately it is not, as the bug report about the drive enclosure cutting
power when suspended shows.

Suspension in a higher layer can have effects that are different to suspension
of all devices on a lower level. Therefore the higher level must ask the lower
level to prepare itself.
Ideally it would ask the lower level for permission to do an autosuspend. I'd
like to change the API so that you can do that. But I don't think that the
lower levels have to implement autosuspend on their own to have levels
above them support autosuspend. Can you summarize your requirements
for supporting autosuspend in the higher levels?

	Regards
		Oliver

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Alan Stern]

On Sat, 29 Sep 2007, Oliver Neukum wrote:

> > I don't know what that's supposed to mean.  And whatever that means, it
> > must be equally true that usb-storage doesn't know CD drives.  Or disk
> > drives, or flash memories, or SCSI tape drives, or ...  On the whole,
> > I'd say that usb-storage's lack of knowledge about SCSI devices greatly
> > outweighs sr's lack of knowledge about hardware.
> 
> Neither driver knows enough to completely do power management.

Right.  So each should do what it can, and neither should try to do the 
other's job.

> > The suspend done by usb-storage suspends only the USB part of the link.  
> > It might or might not affect anything beyond the device's USB chip, 
> > depending on how the device was designed.
> 
> Yes, but do we care about we don't see anyway?

Sure we do.  If the user tells the kernel to suspend a device, the
kernel should do its best to carry out the order -- even if the kernel
doesn't know exactly what's happening inside the device.

> > Your (1) is correct, since all communication must take place over the
> > USB link.  Your (2) is wrong -- the _link_'s power consumption is
> > indeed limited, but the _device_ could be self-powered and so its power
> > consumption need not be affected by the link state.  For instance in
> > the case of a USB-ATA drive enclosure, power consumption is affected
> > more by whether or not the disk is spinning than anything else.
> 
> OK, yes, it is true only for bus powered devices. Do we really want
> to differentiate that far? I suggest we assume the worst case.

It's not clear which case you think is worst, but it doesn't matter.  
We don't have to assume anything; all we have to do is send the right
commands at the right time.  Then it won't make any difference whether
the device is bus-powered or self-powered.


> > Suppose D1 decides that it wants to suspend A1, thus breaking the data
> > link to A2.  Shouldn't it get D2's permission first?  Better yet,
> > shouldn't it wait until D2 tells it: "Okay, A2 is safely suspended and
> > I'm not going to talk to it for a while, you can suspend the link"?
> 
> Ok, I should be much more explicit and try to to explain very clearly.
> 
> In short:
> D1 should definitely get D2's permission. But waiting is not enough.
> 
> Suppose we have all child devices in a suspended state. Then we might ask
> whether this is enough to be sure that you can the suspend the parent.
> Unfortunately it is not, as the bug report about the drive enclosure cutting
> power when suspended shows.

I disagree.  That bug report shows that problems arise when we try to
suspend a parent without making sure the children are suspended first.  
If the sd suspend method had already run then it would have been okay
for the enclosure to cut power.

> Suspension in a higher layer can have effects that are different to suspension
> of all devices on a lower level. Therefore the higher level must ask the lower
> level to prepare itself.

When the lower level is suspended then it is supposed to be prepared 
for the higher layer to suspend.  No additional preparation should be 
needed.

(That's true for USB and SCSI.  Other buses can have additional 
complications, like PCI with its multiple D states.  But the principle 
remains the same.)

> Ideally it would ask the lower level for permission to do an autosuspend. I'd
> like to change the API so that you can do that. But I don't think that the
> lower levels have to implement autosuspend on their own to have levels
> above them support autosuspend. Can you summarize your requirements
> for supporting autosuspend in the higher levels?

It's very simple: The higher level can't autosuspend if doing so would 
cause harm to the lower level.

There are two ways to avoid harm.  One is for the lower level to be 
such that it can never be harmed, no matter what the higher level does.  
For example, a purely logical entity like a partition won't be harmed 
if the drive it belongs to is suspended.  In fact we don't try to 
suspend partitions, and they don't even have drivers.

The other way is for the lower level to be suspended already.  That's
how the autosuspend framework operates: the lower level autosuspends
and tells the higher level that it is now safe for the higher level to
autosuspend.  It's not supposed to work by the higher level announcing:  
"I want to autosuspend now, so all you lower guys had better get
ready."

Even in the case of system suspend things don't work that way.  We
don't have higher-level drivers telling lower-level drivers to suspend.  
Rather, the PM core (acting on behalf of the user) tells _every_ driver
to suspend -- in the correct order, of course.

Now, how much extra work is involved in having the lower-level drivers 
implement autosuspend as opposed to having the higher-level driver ask 
permission?  Not much more than adding the autosuspend timers.  
Everything else is needed anyway for supporting manual runtime suspend.

Alan Stern

Re: [linux-usb-devel] question on flushing buffers and spinning down disk

[Oliver Neukum]

Am Samstag 29 September 2007 schrieb Alan Stern:
> I disagree.  That bug report shows that problems arise when we try to
> suspend a parent without making sure the children are suspended first.  
> If the sd suspend method had already run then it would have been okay
> for the enclosure to cut power.

That is true. The question is who is to call the suspend method.

> > Suspension in a higher layer can have effects that are different to suspension
> > of all devices on a lower level. Therefore the higher level must ask the lower
> > level to prepare itself.
> 
> When the lower level is suspended then it is supposed to be prepared 
> for the higher layer to suspend.  No additional preparation should be 
> needed.

Yes.
If it returns from suspend without error a driver must keep that guarantee.

> (That's true for USB and SCSI.  Other buses can have additional 
> complications, like PCI with its multiple D states.  But the principle 
> remains the same.)
> 
> > Ideally it would ask the lower level for permission to do an autosuspend. I'd
> > like to change the API so that you can do that. But I don't think that the
> > lower levels have to implement autosuspend on their own to have levels
> > above them support autosuspend. Can you summarize your requirements
> > for supporting autosuspend in the higher levels?
> 
> It's very simple: The higher level can't autosuspend if doing so would 
> cause harm to the lower level.
> 
> There are two ways to avoid harm.  One is for the lower level to be 
> such that it can never be harmed, no matter what the higher level does.  
> For example, a purely logical entity like a partition won't be harmed 
> if the drive it belongs to is suspended.  In fact we don't try to 
> suspend partitions, and they don't even have drivers.
> 
> The other way is for the lower level to be suspended already.  That's
> how the autosuspend framework operates: the lower level autosuspends
> and tells the higher level that it is now safe for the higher level to

This is how the hub driver works.

> autosuspend.  It's not supposed to work by the higher level announcing:  
> "I want to autosuspend now, so all you lower guys had better get
> ready."

I see. And there's an appealing simplicity to it. But why insist that
this is the one true way?
 
> Even in the case of system suspend things don't work that way.  We
> don't have higher-level drivers telling lower-level drivers to suspend.  
> Rather, the PM core (acting on behalf of the user) tells _every_ driver
> to suspend -- in the correct order, of course.

True. And putting the notification into a driver is a kludge at best.
It simply was the only way I could come up with without moving
autosuspend into generic code.
Nevertheless, I am not convinced that autosuspend has to work
on the device level only.
 
> Now, how much extra work is involved in having the lower-level drivers 
> implement autosuspend as opposed to having the higher-level driver ask 
> permission?  Not much more than adding the autosuspend timers.  
> Everything else is needed anyway for supporting manual runtime suspend.

Move autosuspend into generic code and I'll certainly try to come up with
something better than what I wrote.

	Regards
		Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: question on flushing buffers and spinning down disk

[Alan Stern]

On Sat, 29 Sep 2007, Oliver Neukum wrote:

> > autosuspend.  It's not supposed to work by the higher level announcing:  
> > "I want to autosuspend now, so all you lower guys had better get
> > ready."
> 
> I see. And there's an appealing simplicity to it. But why insist that
> this is the one true way?

Well, I don't really insist on it.  But keeping things unidirectional 
makes life easier and helps prevent deadlock issues.

Another thing to consider is this: If SCSI autosuspend is initiated by
the host adapter driver, then it won't be possible for different
devices on a SCSI bus to autosuspend at different times.  With
usb-storage this doesn't matter much, because there's almost always
only one target.  But for other buses it could matter.

> > Even in the case of system suspend things don't work that way.  We
> > don't have higher-level drivers telling lower-level drivers to suspend.  
> > Rather, the PM core (acting on behalf of the user) tells _every_ driver
> > to suspend -- in the correct order, of course.
> 
> True. And putting the notification into a driver is a kludge at best.
> It simply was the only way I could come up with without moving
> autosuspend into generic code.
> Nevertheless, I am not convinced that autosuspend has to work
> on the device level only.

Well, suppose usb-storage decides it is ready to autosuspend and it 
asks sd for permission.  What if sd says "No"?  How long should 
usb-storage wait before asking again?  Why should usb-storage have to 
poll sd, instead of being notified just once when sd is ready?

Another thing: I haven't followed the current work in new SCSI
development, but it wouldn't be at all surprising to learn that Power
Management is one of the topics they are focused on.  We should expect
that it will eventually become part of the standard, with associated
special commands and other requirements.  When that happens, Linux's
SCSI stack should be ready to implement the new specs.  Basing our SCSI
autosuspend on hacky code in usb-storage doesn't seem like a good way
to prepare.

> > Now, how much extra work is involved in having the lower-level drivers 
> > implement autosuspend as opposed to having the higher-level driver ask 
> > permission?  Not much more than adding the autosuspend timers.  
> > Everything else is needed anyway for supporting manual runtime suspend.
> 
> Move autosuspend into generic code and I'll certainly try to come up with
> something better than what I wrote.

It's hard to make something generic when there's only one example to 
work from!  Suppose we do it the other way: Add autosuspend support 
into the SCSI drivers and then see what common features it shares with 
USB.  Those common parts can be moved into generic code.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: question on flushing buffers and spinning down disk

[David Brownell]

> > autosuspend.  It's not supposed to work by the higher level announcing:  
> > "I want to autosuspend now, so all you lower guys had better get
> > ready."
>
> I see. And there's an appealing simplicity to it. But why insist that
> this is the one true way?

I was unaware there was another definition of autosuspend; that's how
we've always discussed it.  It's a bottom-up power management strategy
leveraging localized knowledge that isn't knowable by other modules.
(Maintainable systems use information hiding/separation all over...)

It's a software version of what some smarter hardware does automatically.
by automatically gating chunks of the clock tree when they're not needed,
leaving the chip in a "retention" mode, to minimize active wastage.
Doing that consistently over a whole OS can lead to significant power
savings not just by shrinking per-module power consumption, but also by
letting various PLLs and oscillators be powered off.

Software can of course know about more power-relevant resources than just
clocks ...

If someone else has directed a module to suspend, it's hardly "automatic"
from the perspective of that module.  It'd have to decide what to do
with activities that the "higher level" code wouldn't have known about.
After all, the reason those layers exist is to hide information like that!

- Dave


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel