From: Scott Wood <scottwood@freescale.com>
To: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Rob Herring <robh+dt@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Stephen Warren <swarren@wwwdotorg.org>,
Javier Martinez Canillas <javier@osg.samsung.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mark Brown <broonie@kernel.org>,
"Thierry Reding" <thierry.reding@gmail.com>,
Alan Stern <stern@rowland.harvard.edu>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
"Hu Mingkai-B21284" <Mingkai.Hu@freescale.com>
Subject: Re: [PATCH v6 22/22] of/platform: Defer probes of registered devices
Date: Thu, 22 Oct 2015 16:27:10 -0500 [thread overview]
Message-ID: <1445549230.701.116.camel@freescale.com> (raw)
In-Reply-To: <CAAObsKAfufBe_SycibUN3ZsE3fOkBfUjZRx1SWEMwVtM6t7inQ@mail.gmail.com>
On Thu, 2015-10-22 at 15:04 +0200, Tomeu Vizoso wrote:
> On 22 October 2015 at 00:51, Scott Wood <scottwood@freescale.com> wrote:
> > On Wed, 2015-10-21 at 08:44 -0500, Rob Herring wrote:
> > > On Wed, Oct 21, 2015 at 12:54 AM, Scott Wood <scottwood@freescale.com>
> > > wrote:
> > > > On Mon, 2015-09-21 at 16:03 +0200, Tomeu Vizoso wrote:
> > > > > 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@collabora.com>
> > > > > ---
> > > > >
> > > > > 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)?
> 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?
Even if something different does need to be done at this level, forcing all
OF platform devices to be probed at the late_initcall level seems quite
intrusive. You limited it to OF because people complained that other things
will break. Things still broke. Surely there's a better way to address the
problem. Can't the delay be requested by drivers that might otherwise need
to defer (which could be done incrementally, focusing on the worst
performance problems), rather than enabling it for everything?
-Scott
next prev parent reply other threads:[~2015-10-22 21:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1442844182-27787-1-git-send-email-tomeu.vizoso@collabora.com>
[not found] ` <1442844182-27787-23-git-send-email-tomeu.vizoso@collabora.com>
2015-10-21 5:54 ` [PATCH v6 22/22] of/platform: Defer probes of registered devices Scott Wood
2015-10-21 13:44 ` Rob Herring
2015-10-21 22:51 ` Scott Wood
2015-10-22 13:04 ` Tomeu Vizoso
2015-10-22 21:27 ` Scott Wood [this message]
2015-10-24 13:51 ` Rafael J. Wysocki
2015-10-28 14:40 ` Tomeu Vizoso
2015-10-29 4:17 ` Rob Herring
2015-10-29 16:06 ` Scott Wood
2015-10-22 0:34 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1445549230.701.116.camel@freescale.com \
--to=scottwood@freescale.com \
--cc=Mingkai.Hu@freescale.com \
--cc=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=javier@osg.samsung.com \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=swarren@wwwdotorg.org \
--cc=thierry.reding@gmail.com \
--cc=tomeu.vizoso@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).