Thread (70 messages) 70 messages, 13 authors, 2015-10-29

Re: [PATCH v6 22/22] of/platform: Defer probes of registered devices

From: Scott Wood <hidden>
Date: 2015-10-29 16:06:34
Also in: linux-acpi, linux-arm-kernel, linuxppc-dev, lkml

On Wed, 2015-10-28 at 15:40 +0100, Tomeu Vizoso wrote:
On 22 October 2015 at 23:27, Scott Wood [off-list ref] wrote:
quoted
On Thu, 2015-10-22 at 15:04 +0200, Tomeu Vizoso wrote:
quoted
On 22 October 2015 at 00:51, Scott Wood [off-list ref] wrote:
quoted
On Wed, 2015-10-21 at 08:44 -0500, Rob Herring wrote:
quoted
On Wed, Oct 21, 2015 at 12:54 AM, Scott Wood <
scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
wrote:
quoted
On Mon, 2015-09-21 at 16:03 +0200, Tomeu Vizoso wrote:
quoted
Instead of trying to match and probe platform and AMBA devices 
right
after each is registered, delay their probes until
device_initcall_sync.

This means that devices will start probing once all built-in 
drivers
have registered, and after all platform and AMBA devices from 
the DT
have been registered already.

This allows us to prevent deferred probes by probing 
dependencies on
demand.

Signed-off-by: Tomeu Vizoso <tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
---

Changes in v4:
- Also defer probes of AMBA devices registered from the DT as 
they
can
  also request resources.

 drivers/of/platform.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)
This breaks arch/powerpc/sysdev/fsl_pci.c.  The PCI bus is an OF
platform
device, and it must be probed before pcibios_init() which is a
subsys_initcall(), or else the PCI bus never gets scanned.
Thanks for the report. This is probably getting dropped, but it 
could
be disabled for PPC.
I don't think that adding another arbitrary arch difference would be 
the
right solution.
I think Rob meant temporarily disable it while things get fixed. At
least,
So, what is the permanent fix for the swiotlb issue (or more generally, 
the
inability to have a late_initcall that runs after non-module, non-hotplug
platform devices have been probed)?
If the code in pcibios_init() depends on the PCI bus device having
probed, then I would recommend making that dependency explicit by
calling of_device_probe() on the OF node of the PCI controller when
looking it up.
"when looking it up"?  pcibios_init() doesn't do anything with the OF node or 
know any details about the particular PCI bus host implementation.
quoted
quoted
I don't see any reason why PPC wouldn't benefit from this
series.
It's not clear to me what the benefit of this is at all, much less for 
PPC.
What is the fundamental problem with deferred probes?  In the cover letter
you say this change saves 2.3 seconds, but where is that time being 
consumed?
 Are the drivers taking too long in their probe function trying to 
initialize
and then deferring, rather than checking for dependencies up front?  Or 
are
there really so many devices and such a pessimal ordering that most of the
time is spent iterating through and reordering the list, with each defer
happening quickly?
The problem is that a device that defers its probe is currently sent
to the back of the queue, and that's undesired in some use cases in
which there's a device that should be up as soon as possible during
boot (and boot takes a long time). So the goal is to change the order
in which devices with dependencies end up probing.
That doesn't answer my question about where the time is being spent.  Did you 
profile?

-Scott


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help