On Thu, 13 Oct 2011, Grant Likely wrote:
For the deferred case; here is an example of the additional
constraint. Consider the following hierarchy:
-A
+-B
| +-C
| +-D
|
+-E
+-F
+-G
dpm_list could be ordered in at least the following ways (depending on
exactly when
On Thu, 13 Oct 2011, Grant Likely wrote:
However it's worth pointing out right at the start that we already have
device_pm_move_before(), device_pm_move_after(), and
device_pm_move_last(). They are intended specifically to provide
drivers with a way of making sure that dpm_list is in the
On Fri, Oct 14, 2011 at 9:37 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 13 Oct 2011, Grant Likely wrote:
For the deferred case; here is an example of the additional
constraint. Consider the following hierarchy:
-A
+-B
| +-C
| +-D
|
+-E
+-F
+-G
dpm_list could
On Fri, 14 Oct 2011, Grant Likely wrote:
How can a device acquire children before it has a driver?
There are a few potential situations in embedded systems (or at least
nothing currently prevents it) where platform setup code constructs a
device hierarchy without the aid of device drivers,
On Fri, Oct 14, 2011 at 10:33 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 14 Oct 2011, Grant Likely wrote:
How can a device acquire children before it has a driver?
There are a few potential situations in embedded systems (or at least
nothing currently prevents it) where
On Fri, 14 Oct 2011, Grant Likely wrote:
I don't think the second part needs to be quite so invasive.
Certainly drivers that never defer probes shouldn't require anything to
be moved.
Think about that a minute. Consider a dpm_list of devices:
abcDefGh
Now assume that D has
On Fri, Oct 14, 2011 at 11:33 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 14 Oct 2011, Grant Likely wrote:
I don't think the second part needs to be quite so invasive.
Certainly drivers that never defer probes shouldn't require anything to
be moved.
Think about that a minute.
On Fri, 14 Oct 2011, Grant Likely wrote:
However D sometimes does defer probes. �Therefore the device always
needs to be moved, even though this particular probe wasn't deferred.
Yes, that's part of my point.
Okay, then we agree. :-)
So the argument is that if really_probe() called
On 10/14/2011 10:20 AM, Grant Likely wrote:
On Fri, Oct 14, 2011 at 10:33 AM, Alan Sternst...@rowland.harvard.edu wrote:
On Fri, 14 Oct 2011, Grant Likely wrote:
How can a device acquire children before it has a driver?
There are a few potential situations in embedded systems (or at least
...@nvidia.com, Mark Brown
broo...@opensource.wolfsonmicro.com, manjun...@jasper.es
Sent: Saturday, October 8, 2011 11:55:02 AM
Subject: Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
I'm a bit of a fly on the wall here, but I'm curious how this impacts
suspend/resume
On Thu, 13 Oct 2011, Ming Lei wrote:
Inside device_add(), device_pm_add is called before bus_probe_device,
so the patch can't change the device order in pm list, and just change
the driver probe order.
That's the way it works now, but can it be reworked? �It would be
IMO, it depends
Hi,
On Thu, Oct 13, 2011 at 10:31 PM, Alan Stern st...@rowland.harvard.edu
Maybe we should understand the correct model of the ordering constraints
for the multiple device dependancies first, could you give a description or
some examples about it?
The requirement is that devices must be
On Thu, 13 Oct 2011, Ming Lei wrote:
Hi,
On Thu, Oct 13, 2011 at 10:31 PM, Alan Stern st...@rowland.harvard.edu
Maybe we should understand the correct model of the ordering constraints
for the multiple device dependancies first, could you give a description or
some examples about it?
On Thu, Oct 13, 2011 at 10:31:45AM -0400, Alan Stern wrote:
On Thu, 13 Oct 2011, Ming Lei wrote:
Inside device_add(), device_pm_add is called before bus_probe_device,
so the patch can't change the device order in pm list, and just change
the driver probe order.
That's the way it
On Thu, 13 Oct 2011, Grant Likely wrote:
For the deferred case; here is an example of the additional
constraint. Consider the following hierarchy:
-A
+-B
| +-C
| +-D
|
+-E
+-F
+-G
dpm_list could be ordered in at least the following ways (depending on
exactly when
On Thu, Oct 13, 2011 at 02:16:42PM -0400, Alan Stern wrote:
On Thu, 13 Oct 2011, Grant Likely wrote:
For the deferred case; here is an example of the additional
constraint. Consider the following hierarchy:
-A
+-B
| +-C
| +-D
|
+-E
+-F
+-G
dpm_list could
On Fri, Oct 14, 2011 at 12:04 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 13 Oct 2011, Ming Lei wrote:
Hi,
On Thu, Oct 13, 2011 at 10:31 PM, Alan Stern st...@rowland.harvard.edu
Maybe we should understand the correct model of the ordering constraints
for the multiple device
...@secretlab.ca, linux-o...@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-ker...@vger.kernel.org,
Dilan Lee di...@nvidia.com, Mark Brown
broo...@opensource.wolfsonmicro.com, manjun...@jasper.es
Sent: Saturday, October 8, 2011 11:55:02 AM
Subject: Re: [PATCH 2/5] drivercore: Add driver probe
, 2011 11:55:02 AM
Subject: Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
I'm a bit of a fly on the wall here, but I'm curious how this impacts
suspend/resume.
device_initialize-device_pm_init are called from device_register, so
certainly this
patch doesn't also
...@secretlab.ca, linux-o...@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-ker...@vger.kernel.org,
Dilan Lee di...@nvidia.com, Mark Brown
broo...@opensource.wolfsonmicro.com, manjun...@jasper.es
Sent: Saturday, October 8, 2011 11:55:02 AM
Subject: Re: [PATCH 2/5] drivercore: Add driver probe
...@vger.kernel.org,
Dilan Lee di...@nvidia.com, Mark Brown
broo...@opensource.wolfsonmicro.com, manjun...@jasper.es
Sent: Saturday, October 8, 2011 11:55:02 AM
Subject: Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
I'm a bit of a fly on the wall here, but I'm curious how
On Fri, Oct 07, 2011 at 09:03:51PM -0700, Josh Triplett wrote:
On Fri, Oct 07, 2011 at 02:23:26PM -0700, Greg KH wrote:
On Fri, Oct 07, 2011 at 01:57:15PM -0700, Josh Triplett wrote:
On Thu, Oct 06, 2011 at 11:49:28PM -0700, Greg KH wrote:
On Fri, Oct 07, 2011 at 10:33:07AM +0500, G,
On Sat, Oct 08, 2011 at 08:55:02AM -0700, Greg KH wrote:
On Fri, Oct 07, 2011 at 09:03:51PM -0700, Josh Triplett wrote:
On Fri, Oct 07, 2011 at 02:23:26PM -0700, Greg KH wrote:
On Fri, Oct 07, 2011 at 01:57:15PM -0700, Josh Triplett wrote:
On Thu, Oct 06, 2011 at 11:49:28PM -0700, Greg
On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
From: Grant Likely grant.lik...@secretlab.ca
Allow drivers to report at probe time that they cannot get all the
resources required by the device, and should be retried at a
later time.
This should completely solve
On Thu, Oct 06, 2011 at 11:49:28PM -0700, Greg KH wrote:
On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
+config PROBE_DEFER
+ bool Deferred Driver Probe
+ default y
+ help
+ This option provides deferring driver probe if it has dependency on
+
On Fri, Oct 07, 2011 at 01:57:15PM -0700, Josh Triplett wrote:
On Thu, Oct 06, 2011 at 11:49:28PM -0700, Greg KH wrote:
On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
+config PROBE_DEFER
+ bool Deferred Driver Probe
+ default y
+ help
+ This option
On Fri, Oct 7, 2011 at 12:49 AM, Greg KH g...@kroah.com wrote:
On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
+config PROBE_DEFER
+ bool Deferred Driver Probe
+ default y
+ help
+ This option provides deferring driver probe if it has dependency on
+
On Fri, Oct 07, 2011 at 02:23:26PM -0700, Greg KH wrote:
On Fri, Oct 07, 2011 at 01:57:15PM -0700, Josh Triplett wrote:
On Thu, Oct 06, 2011 at 11:49:28PM -0700, Greg KH wrote:
On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
+config PROBE_DEFER
+ bool
From: Grant Likely grant.lik...@secretlab.ca
Allow drivers to report at probe time that they cannot get all the
resources required by the device, and should be retried at a
later time.
This should completely solve the problem of getting devices
initialized in the right order. Right now this
From: Grant Likely grant.lik...@secretlab.ca
Allow drivers to report at probe time that they cannot get all the
resources required by the device, and should be retried at a
later time.
This should completely solve the problem of getting devices
initialized in the right order. Right now this
30 matches
Mail list logo
