On Mon, 28 Jan 2013, Aaron Lu wrote:
> On Sat, Jan 19, 2013 at 01:11:45PM -0500, Alan Stern wrote:
> > On Sat, 19 Jan 2013, Aaron Lu wrote:
> > > Considering ODD's use case, I was thinking of moving the
> > > blk_pm_runtime_init call to sd.c, as sr will not use request based auto
> > > suspend.
On Sat, Jan 19, 2013 at 01:11:45PM -0500, Alan Stern wrote:
> On Sat, 19 Jan 2013, Aaron Lu wrote:
> > Considering ODD's use case, I was thinking of moving the
> > blk_pm_runtime_init call to sd.c, as sr will not use request based auto
> > suspend. Probably right before we decrease usage count for
On Sat, Jan 19, 2013 at 01:11:45PM -0500, Alan Stern wrote:
On Sat, 19 Jan 2013, Aaron Lu wrote:
Considering ODD's use case, I was thinking of moving the
blk_pm_runtime_init call to sd.c, as sr will not use request based auto
suspend. Probably right before we decrease usage count for the
On Mon, 28 Jan 2013, Aaron Lu wrote:
On Sat, Jan 19, 2013 at 01:11:45PM -0500, Alan Stern wrote:
On Sat, 19 Jan 2013, Aaron Lu wrote:
Considering ODD's use case, I was thinking of moving the
blk_pm_runtime_init call to sd.c, as sr will not use request based auto
suspend. Probably
On Sat, 19 Jan 2013, Aaron Lu wrote:
> > Okay. I think you can add (in parentheses) that in most cases drivers
> > should call the routine before any I/O has taken place.
>
> The reason I put it that way is, in patch 4, the blk_pm_runtime_init is
> called after a request is
On Sat, 19 Jan 2013, Aaron Lu wrote:
Okay. I think you can add (in parentheses) that in most cases drivers
should call the routine before any I/O has taken place.
The reason I put it that way is, in patch 4, the blk_pm_runtime_init is
called after a request is executed(scsi_probe_lun). I
On 01/18/2013 11:26 PM, Alan Stern wrote:
On Fri, 18 Jan 2013, Aaron Lu wrote:
Either you have to make sure the q->nr_pending is always correct, even
when runtime PM isn't being used, or else the caller has to make sure
that no I/O takes place before blk_pm_runtime_init is called.
I think we
On Fri, 18 Jan 2013, Aaron Lu wrote:
> > Either you have to make sure the q->nr_pending is always correct, even
> > when runtime PM isn't being used, or else the caller has to make sure
> > that no I/O takes place before blk_pm_runtime_init is called.
>
> I think we can say:
>
On Thu, Jan 17, 2013 at 10:11:31AM -0500, Alan Stern wrote:
> On Thu, 17 Jan 2013, Aaron Lu wrote:
>
> > > > @@ -515,6 +516,27 @@ void elv_bio_merged(struct request_queue *q,
> > > > struct request *rq,
> > > > e->type->ops.elevator_bio_merged_fn(q, rq, bio);
> > > > }
> > > >
On Thu, Jan 17, 2013 at 10:11:31AM -0500, Alan Stern wrote:
On Thu, 17 Jan 2013, Aaron Lu wrote:
@@ -515,6 +516,27 @@ void elv_bio_merged(struct request_queue *q,
struct request *rq,
e-type-ops.elevator_bio_merged_fn(q, rq, bio);
}
+#ifdef
On Fri, 18 Jan 2013, Aaron Lu wrote:
Either you have to make sure the q-nr_pending is always correct, even
when runtime PM isn't being used, or else the caller has to make sure
that no I/O takes place before blk_pm_runtime_init is called.
I think we can say:
blk_pm_runtime_init can't
On 01/18/2013 11:26 PM, Alan Stern wrote:
On Fri, 18 Jan 2013, Aaron Lu wrote:
Either you have to make sure the q-nr_pending is always correct, even
when runtime PM isn't being used, or else the caller has to make sure
that no I/O takes place before blk_pm_runtime_init is called.
I think we
On Thu, 17 Jan 2013, Aaron Lu wrote:
> > > @@ -515,6 +516,27 @@ void elv_bio_merged(struct request_queue *q, struct
> > > request *rq,
> > > e->type->ops.elevator_bio_merged_fn(q, rq, bio);
> > > }
> > >
> > > +#ifdef CONFIG_PM_RUNTIME
> > > +static void
On Thu, 17 Jan 2013, Aaron Lu wrote:
@@ -515,6 +516,27 @@ void elv_bio_merged(struct request_queue *q, struct
request *rq,
e-type-ops.elevator_bio_merged_fn(q, rq, bio);
}
+#ifdef CONFIG_PM_RUNTIME
+static void blk_pm_requeue_request(struct request *rq)
+{
On Wed, Jan 16, 2013 at 10:30:45AM -0500, Alan Stern wrote:
> On Wed, 16 Jan 2013, Aaron Lu wrote:
>
> > From: Lin Ming
> >
> > When a request is added:
> > If device is suspended or is suspending and the request is not a
> > PM request, resume the device.
> >
> > When the last request
On Wed, Jan 16, 2013 at 10:30:45AM -0500, Alan Stern wrote:
> On Wed, 16 Jan 2013, Aaron Lu wrote:
>
> > From: Lin Ming
> >
> > When a request is added:
> > If device is suspended or is suspending and the request is not a
> > PM request, resume the device.
> >
> > When the last request
On Wed, 16 Jan 2013, Aaron Lu wrote:
> From: Lin Ming
>
> When a request is added:
> If device is suspended or is suspending and the request is not a
> PM request, resume the device.
>
> When the last request finishes:
> Call pm_runtime_mark_last_busy().
>
> When pick a request:
>
From: Lin Ming
When a request is added:
If device is suspended or is suspending and the request is not a
PM request, resume the device.
When the last request finishes:
Call pm_runtime_mark_last_busy().
When pick a request:
If device is resuming/suspending, then only PM request
From: Lin Ming ming.m@intel.com
When a request is added:
If device is suspended or is suspending and the request is not a
PM request, resume the device.
When the last request finishes:
Call pm_runtime_mark_last_busy().
When pick a request:
If device is resuming/suspending,
On Wed, 16 Jan 2013, Aaron Lu wrote:
From: Lin Ming ming.m@intel.com
When a request is added:
If device is suspended or is suspending and the request is not a
PM request, resume the device.
When the last request finishes:
Call pm_runtime_mark_last_busy().
When pick a
On Wed, Jan 16, 2013 at 10:30:45AM -0500, Alan Stern wrote:
On Wed, 16 Jan 2013, Aaron Lu wrote:
From: Lin Ming ming.m@intel.com
When a request is added:
If device is suspended or is suspending and the request is not a
PM request, resume the device.
When the last
On Wed, Jan 16, 2013 at 10:30:45AM -0500, Alan Stern wrote:
On Wed, 16 Jan 2013, Aaron Lu wrote:
From: Lin Ming ming.m@intel.com
When a request is added:
If device is suspended or is suspending and the request is not a
PM request, resume the device.
When the last
22 matches
Mail list logo
