On Friday, November 16, 2012 09:27:05 AM Huang Ying wrote:
> On Fri, 2012-11-16 at 02:29 +0100, Rafael J. Wysocki wrote:
> > On Friday, November 16, 2012 08:54:56 AM Huang Ying wrote:
> > > On Fri, 2012-11-16 at 01:55 +0100, Rafael J. Wysocki wrote:
> > > > On Friday, November 16, 2012 01:44:00 AM
On Friday, November 16, 2012 09:27:05 AM Huang Ying wrote:
On Fri, 2012-11-16 at 02:29 +0100, Rafael J. Wysocki wrote:
On Friday, November 16, 2012 08:54:56 AM Huang Ying wrote:
On Fri, 2012-11-16 at 01:55 +0100, Rafael J. Wysocki wrote:
On Friday, November 16, 2012 01:44:00 AM Rafael J.
On Thu, 2012-11-15 at 10:51 +0100, Rafael J. Wysocki wrote:
> On Thursday, November 15, 2012 09:03:44 AM Huang Ying wrote:
> > On Thu, 2012-11-15 at 00:10 +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, November 14, 2012 04:45:01 PM Alan Stern wrote:
> > > > On Wed, 14 Nov 2012, Rafael J.
On Fri, 2012-11-16 at 02:29 +0100, Rafael J. Wysocki wrote:
> On Friday, November 16, 2012 08:54:56 AM Huang Ying wrote:
> > On Fri, 2012-11-16 at 01:55 +0100, Rafael J. Wysocki wrote:
> > > On Friday, November 16, 2012 01:44:00 AM Rafael J. Wysocki wrote:
> > > > On Friday, November 16, 2012
On Friday, November 16, 2012 08:54:56 AM Huang Ying wrote:
> On Fri, 2012-11-16 at 01:55 +0100, Rafael J. Wysocki wrote:
> > On Friday, November 16, 2012 01:44:00 AM Rafael J. Wysocki wrote:
> > > On Friday, November 16, 2012 08:36:14 AM Huang Ying wrote:
> > > > On Thu, 2012-11-15 at 10:51 +0100,
On Fri, 2012-11-16 at 01:55 +0100, Rafael J. Wysocki wrote:
> On Friday, November 16, 2012 01:44:00 AM Rafael J. Wysocki wrote:
> > On Friday, November 16, 2012 08:36:14 AM Huang Ying wrote:
> > > On Thu, 2012-11-15 at 10:51 +0100, Rafael J. Wysocki wrote:
>
> [...]
>
> > >
> > > For this
On Friday, November 16, 2012 01:44:00 AM Rafael J. Wysocki wrote:
> On Friday, November 16, 2012 08:36:14 AM Huang Ying wrote:
> > On Thu, 2012-11-15 at 10:51 +0100, Rafael J. Wysocki wrote:
[...]
> >
> > For this situation, if user "echo auto > .../power/control" for the
> > device, the
On Fri, 2012-11-16 at 01:44 +0100, Rafael J. Wysocki wrote:
> On Friday, November 16, 2012 08:36:14 AM Huang Ying wrote:
> > On Thu, 2012-11-15 at 10:51 +0100, Rafael J. Wysocki wrote:
> > > On Thursday, November 15, 2012 09:03:44 AM Huang Ying wrote:
> > > > On Thu, 2012-11-15 at 00:10 +0100,
On Friday, November 16, 2012 08:36:14 AM Huang Ying wrote:
> On Thu, 2012-11-15 at 10:51 +0100, Rafael J. Wysocki wrote:
> > On Thursday, November 15, 2012 09:03:44 AM Huang Ying wrote:
> > > On Thu, 2012-11-15 at 00:10 +0100, Rafael J. Wysocki wrote:
> > > > On Wednesday, November 14, 2012
On Thu, 2012-11-15 at 10:51 +0100, Rafael J. Wysocki wrote:
> On Thursday, November 15, 2012 09:03:44 AM Huang Ying wrote:
> > On Thu, 2012-11-15 at 00:10 +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, November 14, 2012 04:45:01 PM Alan Stern wrote:
> > > > On Wed, 14 Nov 2012, Rafael J.
On Thu, 15 Nov 2012, Rafael J. Wysocki wrote:
> > So it looks like what we want to do is:
> >
> > (1) Enable runtime PM in pci_pm_init() and set the status to RPM_ACTIVE
> > right
> > before, so that it is in agreement with the pm_runtime_forbid() we do in
> > there.
> >
> > (2) If
On Thursday, November 15, 2012 10:51:42 AM Rafael J. Wysocki wrote:
> On Thursday, November 15, 2012 09:03:44 AM Huang Ying wrote:
> > On Thu, 2012-11-15 at 00:10 +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, November 14, 2012 04:45:01 PM Alan Stern wrote:
> > > > On Wed, 14 Nov 2012, Rafael
On Thursday, November 15, 2012 09:03:44 AM Huang Ying wrote:
> On Thu, 2012-11-15 at 00:10 +0100, Rafael J. Wysocki wrote:
> > On Wednesday, November 14, 2012 04:45:01 PM Alan Stern wrote:
> > > On Wed, 14 Nov 2012, Rafael J. Wysocki wrote:
> > >
> > > > > This has the side effect that when a
On Thursday, November 15, 2012 09:03:44 AM Huang Ying wrote:
On Thu, 2012-11-15 at 00:10 +0100, Rafael J. Wysocki wrote:
On Wednesday, November 14, 2012 04:45:01 PM Alan Stern wrote:
On Wed, 14 Nov 2012, Rafael J. Wysocki wrote:
This has the side effect that when a driver unbinds,
On Thursday, November 15, 2012 10:51:42 AM Rafael J. Wysocki wrote:
On Thursday, November 15, 2012 09:03:44 AM Huang Ying wrote:
On Thu, 2012-11-15 at 00:10 +0100, Rafael J. Wysocki wrote:
On Wednesday, November 14, 2012 04:45:01 PM Alan Stern wrote:
On Wed, 14 Nov 2012, Rafael J.
On Thu, 15 Nov 2012, Rafael J. Wysocki wrote:
So it looks like what we want to do is:
(1) Enable runtime PM in pci_pm_init() and set the status to RPM_ACTIVE
right
before, so that it is in agreement with the pm_runtime_forbid() we do in
there.
(2) If user space switches
On Thu, 2012-11-15 at 10:51 +0100, Rafael J. Wysocki wrote:
On Thursday, November 15, 2012 09:03:44 AM Huang Ying wrote:
On Thu, 2012-11-15 at 00:10 +0100, Rafael J. Wysocki wrote:
On Wednesday, November 14, 2012 04:45:01 PM Alan Stern wrote:
On Wed, 14 Nov 2012, Rafael J. Wysocki wrote:
On Friday, November 16, 2012 08:36:14 AM Huang Ying wrote:
On Thu, 2012-11-15 at 10:51 +0100, Rafael J. Wysocki wrote:
On Thursday, November 15, 2012 09:03:44 AM Huang Ying wrote:
On Thu, 2012-11-15 at 00:10 +0100, Rafael J. Wysocki wrote:
On Wednesday, November 14, 2012 04:45:01 PM Alan
On Fri, 2012-11-16 at 01:44 +0100, Rafael J. Wysocki wrote:
On Friday, November 16, 2012 08:36:14 AM Huang Ying wrote:
On Thu, 2012-11-15 at 10:51 +0100, Rafael J. Wysocki wrote:
On Thursday, November 15, 2012 09:03:44 AM Huang Ying wrote:
On Thu, 2012-11-15 at 00:10 +0100, Rafael J.
On Friday, November 16, 2012 01:44:00 AM Rafael J. Wysocki wrote:
On Friday, November 16, 2012 08:36:14 AM Huang Ying wrote:
On Thu, 2012-11-15 at 10:51 +0100, Rafael J. Wysocki wrote:
[...]
For this situation, if user echo auto .../power/control for the
device, the runtime PM
On Fri, 2012-11-16 at 01:55 +0100, Rafael J. Wysocki wrote:
On Friday, November 16, 2012 01:44:00 AM Rafael J. Wysocki wrote:
On Friday, November 16, 2012 08:36:14 AM Huang Ying wrote:
On Thu, 2012-11-15 at 10:51 +0100, Rafael J. Wysocki wrote:
[...]
For this situation, if user
On Friday, November 16, 2012 08:54:56 AM Huang Ying wrote:
On Fri, 2012-11-16 at 01:55 +0100, Rafael J. Wysocki wrote:
On Friday, November 16, 2012 01:44:00 AM Rafael J. Wysocki wrote:
On Friday, November 16, 2012 08:36:14 AM Huang Ying wrote:
On Thu, 2012-11-15 at 10:51 +0100, Rafael J.
On Fri, 2012-11-16 at 02:29 +0100, Rafael J. Wysocki wrote:
On Friday, November 16, 2012 08:54:56 AM Huang Ying wrote:
On Fri, 2012-11-16 at 01:55 +0100, Rafael J. Wysocki wrote:
On Friday, November 16, 2012 01:44:00 AM Rafael J. Wysocki wrote:
On Friday, November 16, 2012 08:36:14 AM
On Thu, 2012-11-15 at 10:51 +0100, Rafael J. Wysocki wrote:
On Thursday, November 15, 2012 09:03:44 AM Huang Ying wrote:
On Thu, 2012-11-15 at 00:10 +0100, Rafael J. Wysocki wrote:
On Wednesday, November 14, 2012 04:45:01 PM Alan Stern wrote:
On Wed, 14 Nov 2012, Rafael J. Wysocki wrote:
On Thu, 2012-11-15 at 00:10 +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 14, 2012 04:45:01 PM Alan Stern wrote:
> > On Wed, 14 Nov 2012, Rafael J. Wysocki wrote:
> >
> > > > This has the side effect that when a driver unbinds, it can't leave the
> > > > device in a special low-power
On Wednesday, November 14, 2012 04:45:01 PM Alan Stern wrote:
> On Wed, 14 Nov 2012, Rafael J. Wysocki wrote:
>
> > > This has the side effect that when a driver unbinds, it can't leave the
> > > device in a special low-power state. The device will always end up in
> > > the generic low-power
On Wed, 14 Nov 2012, Rafael J. Wysocki wrote:
> > This has the side effect that when a driver unbinds, it can't leave the
> > device in a special low-power state. The device will always end up in
> > the generic low-power state supported by the PCI core.
>
> Well, I'm not sure I'd like that.
On Wednesday, November 14, 2012 11:42:33 AM Alan Stern wrote:
> On Wed, 14 Nov 2012, Rafael J. Wysocki wrote:
>
> > On Thursday, November 08, 2012 12:07:54 PM Alan Stern wrote:
> > > On Thu, 8 Nov 2012, Rafael J. Wysocki wrote:
> >
> > [...]
> >
> > I'd like to revisit this for a while if you
On Wed, 14 Nov 2012, Rafael J. Wysocki wrote:
> On Thursday, November 08, 2012 12:07:54 PM Alan Stern wrote:
> > On Thu, 8 Nov 2012, Rafael J. Wysocki wrote:
>
> [...]
>
> I'd like to revisit this for a while if you don't mind.
Not at all.
> > Your revised patch does do the job, except for a
On Wed, 14 Nov 2012, Huang Ying wrote:
> > What changes specifically do you mean to be precise?
>
> I mean the following changes from Alan's email.
>
> pm_runtime_set_suspended should fail if dev->power.runtime_auto
> is clear.
>
> pm_runtime_forbid should call
On Wed, 2012-11-14 at 10:52 +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 14, 2012 09:08:28 AM Huang Ying wrote:
> > On Tue, 2012-11-13 at 11:10 -0500, Alan Stern wrote:
> > > On Tue, 13 Nov 2012, Huang Ying wrote:
> > >
> > > > > This is not quite right. Consider a device that is in
On Thursday, November 08, 2012 12:07:54 PM Alan Stern wrote:
> On Thu, 8 Nov 2012, Rafael J. Wysocki wrote:
[...]
I'd like to revisit this for a while if you don't mind.
> Your revised patch does do the job, except for a few problems.
> Namely, while local_pci_probe() and pci_device_remove()
On Wednesday, November 14, 2012 09:08:28 AM Huang Ying wrote:
> On Tue, 2012-11-13 at 11:10 -0500, Alan Stern wrote:
> > On Tue, 13 Nov 2012, Huang Ying wrote:
> >
> > > > This is not quite right. Consider a device that is in runtime suspend
> > > > when a system sleep starts. When the system
On Wednesday, November 14, 2012 09:08:28 AM Huang Ying wrote:
On Tue, 2012-11-13 at 11:10 -0500, Alan Stern wrote:
On Tue, 13 Nov 2012, Huang Ying wrote:
This is not quite right. Consider a device that is in runtime suspend
when a system sleep starts. When the system sleep ends,
On Thursday, November 08, 2012 12:07:54 PM Alan Stern wrote:
On Thu, 8 Nov 2012, Rafael J. Wysocki wrote:
[...]
I'd like to revisit this for a while if you don't mind.
Your revised patch does do the job, except for a few problems.
Namely, while local_pci_probe() and pci_device_remove() are
On Wed, 2012-11-14 at 10:52 +0100, Rafael J. Wysocki wrote:
On Wednesday, November 14, 2012 09:08:28 AM Huang Ying wrote:
On Tue, 2012-11-13 at 11:10 -0500, Alan Stern wrote:
On Tue, 13 Nov 2012, Huang Ying wrote:
This is not quite right. Consider a device that is in runtime
On Wed, 14 Nov 2012, Huang Ying wrote:
What changes specifically do you mean to be precise?
I mean the following changes from Alan's email.
pm_runtime_set_suspended should fail if dev-power.runtime_auto
is clear.
pm_runtime_forbid should call
On Wed, 14 Nov 2012, Rafael J. Wysocki wrote:
On Thursday, November 08, 2012 12:07:54 PM Alan Stern wrote:
On Thu, 8 Nov 2012, Rafael J. Wysocki wrote:
[...]
I'd like to revisit this for a while if you don't mind.
Not at all.
Your revised patch does do the job, except for a few
On Wednesday, November 14, 2012 11:42:33 AM Alan Stern wrote:
On Wed, 14 Nov 2012, Rafael J. Wysocki wrote:
On Thursday, November 08, 2012 12:07:54 PM Alan Stern wrote:
On Thu, 8 Nov 2012, Rafael J. Wysocki wrote:
[...]
I'd like to revisit this for a while if you don't mind.
On Wed, 14 Nov 2012, Rafael J. Wysocki wrote:
This has the side effect that when a driver unbinds, it can't leave the
device in a special low-power state. The device will always end up in
the generic low-power state supported by the PCI core.
Well, I'm not sure I'd like that.
Let's
On Wednesday, November 14, 2012 04:45:01 PM Alan Stern wrote:
On Wed, 14 Nov 2012, Rafael J. Wysocki wrote:
This has the side effect that when a driver unbinds, it can't leave the
device in a special low-power state. The device will always end up in
the generic low-power state
On Thu, 2012-11-15 at 00:10 +0100, Rafael J. Wysocki wrote:
On Wednesday, November 14, 2012 04:45:01 PM Alan Stern wrote:
On Wed, 14 Nov 2012, Rafael J. Wysocki wrote:
This has the side effect that when a driver unbinds, it can't leave the
device in a special low-power state. The
On Tue, 2012-11-13 at 11:10 -0500, Alan Stern wrote:
> On Tue, 13 Nov 2012, Huang Ying wrote:
>
> > > This is not quite right. Consider a device that is in runtime suspend
> > > when a system sleep starts. When the system sleep ends, the device
> > > will be resumed but the PM core will still
On Monday, November 12, 2012 11:32:26 AM Alan Stern wrote:
> On Mon, 12 Nov 2012, Huang Ying wrote:
>
> > > > Is it absolute necessary to call pm_runtime_set_suspended? If the
> > > > device is disabled, the transition to SUSPENDED state will not be
> > > > triggered even if the device is
On Tue, 13 Nov 2012, Huang Ying wrote:
> > This is not quite right. Consider a device that is in runtime suspend
> > when a system sleep starts. When the system sleep ends, the device
> > will be resumed but the PM core will still think its state is
> > SUSPENDED. The subsystem has to tell
On Tue, 13 Nov 2012, Huang Ying wrote:
This is not quite right. Consider a device that is in runtime suspend
when a system sleep starts. When the system sleep ends, the device
will be resumed but the PM core will still think its state is
SUSPENDED. The subsystem has to tell the PM
On Monday, November 12, 2012 11:32:26 AM Alan Stern wrote:
On Mon, 12 Nov 2012, Huang Ying wrote:
Is it absolute necessary to call pm_runtime_set_suspended? If the
device is disabled, the transition to SUSPENDED state will not be
triggered even if the device is ACTIVE.
It's
On Tue, 2012-11-13 at 11:10 -0500, Alan Stern wrote:
On Tue, 13 Nov 2012, Huang Ying wrote:
This is not quite right. Consider a device that is in runtime suspend
when a system sleep starts. When the system sleep ends, the device
will be resumed but the PM core will still think its
On Mon, 2012-11-12 at 21:32 -0500, Alan Stern wrote:
> On Tue, 13 Nov 2012, Huang Ying wrote:
>
> > Sorry, my original idea is:
> >
> > pm_runtime_disable will put device into SUSPENDED state if
> > dev->power.runtime_auto is clear. pm_runtime_allow will put
> > device into
On Tue, 13 Nov 2012, Huang Ying wrote:
> Sorry, my original idea is:
>
> pm_runtime_disable will put device into SUSPENDED state if
> dev->power.runtime_auto is clear. pm_runtime_allow will put
> device into SUSPENDED state if dev->power.disable_depth > 0.
That's close to
On Mon, 2012-11-12 at 11:32 -0500, Alan Stern wrote:
> On Mon, 12 Nov 2012, Huang Ying wrote:
>
> > > > Is it absolute necessary to call pm_runtime_set_suspended? If the
> > > > device is disabled, the transition to SUSPENDED state will not be
> > > > triggered even if the device is ACTIVE.
> >
On Mon, 12 Nov 2012, Huang Ying wrote:
> > > Is it absolute necessary to call pm_runtime_set_suspended? If the
> > > device is disabled, the transition to SUSPENDED state will not be
> > > triggered even if the device is ACTIVE.
> >
> > It's not absolutely necessary to do this, but we ought to
On Mon, 12 Nov 2012, Huang Ying wrote:
Is it absolute necessary to call pm_runtime_set_suspended? If the
device is disabled, the transition to SUSPENDED state will not be
triggered even if the device is ACTIVE.
It's not absolutely necessary to do this, but we ought to because it
On Mon, 2012-11-12 at 11:32 -0500, Alan Stern wrote:
On Mon, 12 Nov 2012, Huang Ying wrote:
Is it absolute necessary to call pm_runtime_set_suspended? If the
device is disabled, the transition to SUSPENDED state will not be
triggered even if the device is ACTIVE.
It's not
On Tue, 13 Nov 2012, Huang Ying wrote:
Sorry, my original idea is:
pm_runtime_disable will put device into SUSPENDED state if
dev-power.runtime_auto is clear. pm_runtime_allow will put
device into SUSPENDED state if dev-power.disable_depth 0.
That's close to what I
On Mon, 2012-11-12 at 21:32 -0500, Alan Stern wrote:
On Tue, 13 Nov 2012, Huang Ying wrote:
Sorry, my original idea is:
pm_runtime_disable will put device into SUSPENDED state if
dev-power.runtime_auto is clear. pm_runtime_allow will put
device into SUSPENDED state if
On Sun, 2012-11-11 at 21:36 -0500, Alan Stern wrote:
> On Mon, 12 Nov 2012, Huang Ying wrote:
>
> > > The first question: How should the PCI subsystem prevent the parents of
> > > driverless VGA devices from being runtime suspended while userspace is
> > > accessing them?
> >
> > I think
On Mon, 12 Nov 2012, Huang Ying wrote:
> > The first question: How should the PCI subsystem prevent the parents of
> > driverless VGA devices from being runtime suspended while userspace is
> > accessing them?
>
> I think Rafael's patch is good for that.
But his patch isn't needed if we make
On Fri, 2012-11-09 at 11:41 -0500, Alan Stern wrote:
> On Fri, 9 Nov 2012, Huang Ying wrote:
>
> > On Thu, 2012-11-08 at 12:07 -0500, Alan Stern wrote:
> > > On Thu, 8 Nov 2012, Rafael J. Wysocki wrote:
> > >
> > > > > > > is it a good idea to allow to set device state to SUSPENDED if
> > > > >
On Fri, 2012-11-09 at 11:41 -0500, Alan Stern wrote:
On Fri, 9 Nov 2012, Huang Ying wrote:
On Thu, 2012-11-08 at 12:07 -0500, Alan Stern wrote:
On Thu, 8 Nov 2012, Rafael J. Wysocki wrote:
is it a good idea to allow to set device state to SUSPENDED if
the device
On Mon, 12 Nov 2012, Huang Ying wrote:
The first question: How should the PCI subsystem prevent the parents of
driverless VGA devices from being runtime suspended while userspace is
accessing them?
I think Rafael's patch is good for that.
But his patch isn't needed if we make these
On Sun, 2012-11-11 at 21:36 -0500, Alan Stern wrote:
On Mon, 12 Nov 2012, Huang Ying wrote:
The first question: How should the PCI subsystem prevent the parents of
driverless VGA devices from being runtime suspended while userspace is
accessing them?
I think Rafael's patch is
On Fri, 9 Nov 2012, Huang Ying wrote:
> On Thu, 2012-11-08 at 12:07 -0500, Alan Stern wrote:
> > On Thu, 8 Nov 2012, Rafael J. Wysocki wrote:
> >
> > > > > > is it a good idea to allow to set device state to SUSPENDED if the
> > > > > > device
> > > > > > is disabled?
> > > > >
> > > > > No,
On Fri, 9 Nov 2012, Huang Ying wrote:
On Thu, 2012-11-08 at 12:07 -0500, Alan Stern wrote:
On Thu, 8 Nov 2012, Rafael J. Wysocki wrote:
is it a good idea to allow to set device state to SUSPENDED if the
device
is disabled?
No, it is not. The status should
On Thu, 2012-11-08 at 12:07 -0500, Alan Stern wrote:
> On Thu, 8 Nov 2012, Rafael J. Wysocki wrote:
>
> > > > > is it a good idea to allow to set device state to SUSPENDED if the
> > > > > device
> > > > > is disabled?
> > > >
> > > > No, it is not. The status should always be ACTIVE as long
On Thu, 8 Nov 2012, Rafael J. Wysocki wrote:
> > > > is it a good idea to allow to set device state to SUSPENDED if the
> > > > device
> > > > is disabled?
> > >
> > > No, it is not. The status should always be ACTIVE as long as usage_count
> > > > 0.
That isn't strictly true, because
On Thursday, November 08, 2012 10:04:36 AM Huang Ying wrote:
> On Thu, 2012-11-08 at 02:35 +0100, Rafael J. Wysocki wrote:
> > On Thursday, November 08, 2012 09:15:08 AM Huang Ying wrote:
> > > On Thu, 2012-11-08 at 00:09 +0100, Rafael J. Wysocki wrote:
[...]
> > > I think the patch can fix the
On Thursday, November 08, 2012 10:04:36 AM Huang Ying wrote:
On Thu, 2012-11-08 at 02:35 +0100, Rafael J. Wysocki wrote:
On Thursday, November 08, 2012 09:15:08 AM Huang Ying wrote:
On Thu, 2012-11-08 at 00:09 +0100, Rafael J. Wysocki wrote:
[...]
I think the patch can fix the issue in
On Thu, 8 Nov 2012, Rafael J. Wysocki wrote:
is it a good idea to allow to set device state to SUSPENDED if the
device
is disabled?
No, it is not. The status should always be ACTIVE as long as usage_count
0.
That isn't strictly true, because pm_runtime_get_noresume
On Thu, 2012-11-08 at 12:07 -0500, Alan Stern wrote:
On Thu, 8 Nov 2012, Rafael J. Wysocki wrote:
is it a good idea to allow to set device state to SUSPENDED if the
device
is disabled?
No, it is not. The status should always be ACTIVE as long as
usage_count 0.
On Thu, 2012-11-08 at 02:35 +0100, Rafael J. Wysocki wrote:
> On Thursday, November 08, 2012 09:15:08 AM Huang Ying wrote:
> > On Thu, 2012-11-08 at 00:09 +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, November 07, 2012 11:51:15 PM Rafael J. Wysocki wrote:
> > > > On Wednesday, November 07,
On Thursday, November 08, 2012 09:15:08 AM Huang Ying wrote:
> On Thu, 2012-11-08 at 00:09 +0100, Rafael J. Wysocki wrote:
> > On Wednesday, November 07, 2012 11:51:15 PM Rafael J. Wysocki wrote:
> > > On Wednesday, November 07, 2012 04:56:49 PM Alan Stern wrote:
> > > > On Wed, 7 Nov 2012, Rafael
On Thu, 2012-11-08 at 00:09 +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 07, 2012 11:51:15 PM Rafael J. Wysocki wrote:
> > On Wednesday, November 07, 2012 04:56:49 PM Alan Stern wrote:
> > > On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
> > >
> > > > > Right. The reasoning behind my
On Wednesday, November 07, 2012 11:51:15 PM Rafael J. Wysocki wrote:
> On Wednesday, November 07, 2012 04:56:49 PM Alan Stern wrote:
> > On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
> >
> > > > Right. The reasoning behind my proposal goes like this: When there's
> > > > no driver, the subsystem
On Wednesday, November 07, 2012 04:56:49 PM Alan Stern wrote:
> On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
>
> > > Right. The reasoning behind my proposal goes like this: When there's
> > > no driver, the subsystem can let userspace directly control the
> > > device's power level through the
On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
> > Right. The reasoning behind my proposal goes like this: When there's
> > no driver, the subsystem can let userspace directly control the
> > device's power level through the power/control attribute.
>
> Well, we might as well just leave the
On Wednesday, November 07, 2012 03:47:02 PM Alan Stern wrote:
> On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
>
> > On Wednesday, November 07, 2012 12:17:02 PM Alan Stern wrote:
> > > On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
> > >
> > > > > The PCI subsystem assumes that
> > > > > driverless
On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
> On Wednesday, November 07, 2012 12:17:02 PM Alan Stern wrote:
> > On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
> >
> > > > The PCI subsystem assumes that
> > > > driverless devices are not in use, so they are disabled for runtime PM
> > > > and
On Wednesday, November 07, 2012 12:17:02 PM Alan Stern wrote:
> On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
>
> > > The PCI subsystem assumes that
> > > driverless devices are not in use, so they are disabled for runtime PM
> > > and marked as suspended. This is not appropriate for VGA
On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
> > The PCI subsystem assumes that
> > driverless devices are not in use, so they are disabled for runtime PM
> > and marked as suspended. This is not appropriate for VGA devices,
> > which can indeed be used without a driver.
> >
> > I'm not sure
On Wednesday, November 07, 2012 10:49:04 AM Alan Stern wrote:
> On Wed, 7 Nov 2012, Huang Ying wrote:
>
> > > > Devices will be disabled if the PCI driver is unbound from the PCI
> > > > device.
> > >
> > > Yes. But without a PCI driver, nothing will call
> > > pm_runtime_set_suspended.
> >
>
On Wed, 7 Nov 2012, Huang Ying wrote:
> > > Devices will be disabled if the PCI driver is unbound from the PCI
> > > device.
> >
> > Yes. But without a PCI driver, nothing will call
> > pm_runtime_set_suspended.
>
> pm_runtime_set_suspended will be called in pci_device_remove or error
> path
On Wed, 7 Nov 2012, Huang Ying wrote:
Devices will be disabled if the PCI driver is unbound from the PCI
device.
Yes. But without a PCI driver, nothing will call
pm_runtime_set_suspended.
pm_runtime_set_suspended will be called in pci_device_remove or error
path of
On Wednesday, November 07, 2012 10:49:04 AM Alan Stern wrote:
On Wed, 7 Nov 2012, Huang Ying wrote:
Devices will be disabled if the PCI driver is unbound from the PCI
device.
Yes. But without a PCI driver, nothing will call
pm_runtime_set_suspended.
On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
The PCI subsystem assumes that
driverless devices are not in use, so they are disabled for runtime PM
and marked as suspended. This is not appropriate for VGA devices,
which can indeed be used without a driver.
I'm not sure what the
On Wednesday, November 07, 2012 12:17:02 PM Alan Stern wrote:
On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
The PCI subsystem assumes that
driverless devices are not in use, so they are disabled for runtime PM
and marked as suspended. This is not appropriate for VGA devices,
On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
On Wednesday, November 07, 2012 12:17:02 PM Alan Stern wrote:
On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
The PCI subsystem assumes that
driverless devices are not in use, so they are disabled for runtime PM
and marked as
On Wednesday, November 07, 2012 03:47:02 PM Alan Stern wrote:
On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
On Wednesday, November 07, 2012 12:17:02 PM Alan Stern wrote:
On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
The PCI subsystem assumes that
driverless devices are not in
On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
Right. The reasoning behind my proposal goes like this: When there's
no driver, the subsystem can let userspace directly control the
device's power level through the power/control attribute.
Well, we might as well just leave the runtime PM of
On Wednesday, November 07, 2012 04:56:49 PM Alan Stern wrote:
On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
Right. The reasoning behind my proposal goes like this: When there's
no driver, the subsystem can let userspace directly control the
device's power level through the
On Wednesday, November 07, 2012 11:51:15 PM Rafael J. Wysocki wrote:
On Wednesday, November 07, 2012 04:56:49 PM Alan Stern wrote:
On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
Right. The reasoning behind my proposal goes like this: When there's
no driver, the subsystem can let
On Thu, 2012-11-08 at 00:09 +0100, Rafael J. Wysocki wrote:
On Wednesday, November 07, 2012 11:51:15 PM Rafael J. Wysocki wrote:
On Wednesday, November 07, 2012 04:56:49 PM Alan Stern wrote:
On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
Right. The reasoning behind my proposal goes
On Thursday, November 08, 2012 09:15:08 AM Huang Ying wrote:
On Thu, 2012-11-08 at 00:09 +0100, Rafael J. Wysocki wrote:
On Wednesday, November 07, 2012 11:51:15 PM Rafael J. Wysocki wrote:
On Wednesday, November 07, 2012 04:56:49 PM Alan Stern wrote:
On Wed, 7 Nov 2012, Rafael J.
On Thu, 2012-11-08 at 02:35 +0100, Rafael J. Wysocki wrote:
On Thursday, November 08, 2012 09:15:08 AM Huang Ying wrote:
On Thu, 2012-11-08 at 00:09 +0100, Rafael J. Wysocki wrote:
On Wednesday, November 07, 2012 11:51:15 PM Rafael J. Wysocki wrote:
On Wednesday, November 07, 2012
On Tue, 2012-11-06 at 10:17 -0500, Alan Stern wrote:
> On Tue, 6 Nov 2012, Huang Ying wrote:
>
> > On Sun, 2012-11-04 at 20:56 -0500, Alan Stern wrote:
> > > On Mon, 5 Nov 2012, Huang Ying wrote:
> > >
> > > > In current runtime PM implementation, the active child count of the
> > > > parent
On Tue, 6 Nov 2012, Huang Ying wrote:
> On Sun, 2012-11-04 at 20:56 -0500, Alan Stern wrote:
> > On Mon, 5 Nov 2012, Huang Ying wrote:
> >
> > > In current runtime PM implementation, the active child count of the
> > > parent device may be decreased if the runtime PM of the child device
> > > is
On Tue, 6 Nov 2012, Huang Ying wrote:
On Sun, 2012-11-04 at 20:56 -0500, Alan Stern wrote:
On Mon, 5 Nov 2012, Huang Ying wrote:
In current runtime PM implementation, the active child count of the
parent device may be decreased if the runtime PM of the child device
is disabled and
On Tue, 2012-11-06 at 10:17 -0500, Alan Stern wrote:
On Tue, 6 Nov 2012, Huang Ying wrote:
On Sun, 2012-11-04 at 20:56 -0500, Alan Stern wrote:
On Mon, 5 Nov 2012, Huang Ying wrote:
In current runtime PM implementation, the active child count of the
parent device may be
On Sun, 2012-11-04 at 20:56 -0500, Alan Stern wrote:
> On Mon, 5 Nov 2012, Huang Ying wrote:
>
> > In current runtime PM implementation, the active child count of the
> > parent device may be decreased if the runtime PM of the child device
> > is disabled and forbidden. For example, to unbind a
On Sun, 2012-11-04 at 20:56 -0500, Alan Stern wrote:
On Mon, 5 Nov 2012, Huang Ying wrote:
In current runtime PM implementation, the active child count of the
parent device may be decreased if the runtime PM of the child device
is disabled and forbidden. For example, to unbind a PCI
1 - 100 of 104 matches
Mail list logo
