* Re: Alternative approach to solve the deferred probe
From: Russell King - ARM Linux @ 2015-10-21 8:18 UTC (permalink / raw)
To: Frank Rowand
Cc: Geert Uytterhoeven, Tomeu Vizoso, Mark Brown, Greg Kroah-Hartman,
Rob Herring, Michael Turquette, Stephen Boyd, Vinod Koul,
Dan Williams, Linus Walleij, Alexandre Courbot, Thierry Reding,
David Airlie, Terje Bergström, Stephen Warren, Wolfram Sang,
Grant Likely, Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse
In-Reply-To: <56270D5B.5010902@gmail.com>
On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> > On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> >> Hi Russell,
> >>
> >> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >>>>> What you can do is print those devices which have failed to probe at
> >>>>> late_initcall() time - possibly augmenting that with reports from
> >>>>> subsystems showing what resources are not available, but that's only
> >>>>> a guide, because of the "it might or might not be in a kernel module"
> >>>>> problem.
> >>>>
> >>>> Well, adding those reports would give you a changelog similar to the
> >>>> one in this series...
> >>>
> >>> I'm not sure about that, because what I was thinking of is adding
> >>> a flag which would be set at late_initcall() time prior to running
> >>> a final round of deferred device probing.
> >>
> >> Which round is the final round?
> >> That's the one which didn't manage to bind any new devices to drivers,
> >> which is something you only know _after_ the round has been run.
> >>
> >> So I think we need one extra round to handle this.
> >>
> >>> This flag would then be used in a deferred_warn() printk function
> >>> which would normally be silent, but when this flag is set, it would
> >>> print the reason for the deferral - and this would replace (or be
> >>> added) to the subsystems and drivers which return -EPROBE_DEFER.
> >>>
> >>> That has the effect of hiding all the deferrals up until just before
> >>> launching into userspace, which should then acomplish two things -
> >>> firstly, getting rid of the rather useless deferred messages up to
> >>> that point, and secondly printing the reason why the remaining
> >>> deferrals are happening.
> >>>
> >>> That should be a small number of new lines plus a one-line change
> >>> in subsystems and drivers.
> >>
> >> Apart from the extra round we probably can't get rid of, that sounds OK to me.
> >
> > Something like this. I haven't put a lot of effort into it to change all
> > the places which return an -EPROBE_DEFER, and it also looks like we need
> > some helpers to report when we have only an device_node (or should that
> > be fwnode?) See the commented out of_warn_deferred() in
> > drivers/gpio/gpiolib-of.c. Adding this stuff in the subsystems searching
> > for resources should make debugging why things are getting deferred easier.
> >
> > We could make driver_deferred_probe_report something that can be
> > deactivated again after the last deferred probe run, and provide the
> > user with a knob that they can turn it back on again.
> >
> > I've tried this out on two of my platforms, including forcing
> > driver_deferred_probe_report to be enabled, and I get exactly one
> > deferred probe, so not a particularly good test.
> >
> > The patch won't apply as-is to mainline for all files; it's based on my
> > tree which has some 360 additional patches (which seems to be about
> > normal for my tree now.)
>
> I like the concept (I have been thinking along similar lines lately).
> But I think this might make the console messages more confusing than
> they are now.
If messages end up being given from the subsystem rather than the driver,
surely they become more consistent?
> The problem is that debug, warn, and error messages
> come from a somewhat random set of locations at the moment. Some
> come from the driver probe routines and some come from the subsystems
> that the probe routines call. So the patch is suppressing some
> messages, but not others.
The patch is not complete (read the description above).
> > +void dev_warn_deferred(struct device *dev, const char *fmt, ...)
> > +{
> > + if (driver_deferred_probe_report) {
> > + struct va_format vaf;
> > + va_list ap;
> > +
> > + va_start(ap, fmt);
> > + vaf.fmt = fmt;
> > + vaf.va = ≈
> > +
> > + dev_warn(dev, "deferring probe: %pV", &vaf);
> > + va_end(ap);
> > + }
> > +}
> > +EXPORT_SYMBOL_GPL(dev_warn_deferred);
>
> The places where dev_warn_deferred() replaces dev_dbg(), we lose the
> ability to turn on debugging and observe the driver reporting the
> specific reason the deferral is occurring. So it would be useful to
> add an "else dev_dbg()" in dev_warn_deferred() to retain that capability.
That's a possibility.
>
> > +
> > static bool driver_deferred_probe_enable = false;
> > +
> > /**
> > * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
> > *
> > @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
> > driver_deferred_probe_trigger();
>
> Couldn't you put the "driver_deferred_probe_report = true" here? And then
> not add another round of probes.
The idea is not to report anything for drivers that were deferred
during the normal bootup. The above is part of the normal bootup,
and the deferred activity should not be warned about.
If we have any devices still deferring after _this_ round, that must
indicate that some resource they want is not available, and that
should be warned about.
Of course, modules can defer too - and I made some suggestions in my
waffle above the patch about that.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Geert Uytterhoeven @ 2015-10-21 8:55 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rob Herring, David Woodhouse, Mark Brown, Greg Kroah-Hartman,
Tomeu Vizoso, Russell King, Michael Turquette, Stephen Boyd,
Vinod Koul, Dan Williams, Linus Walleij, Alexandre Courbot,
Thierry Reding, David Airlie, Terje Bergström,
Stephen Warren, Wolfram Sang, Frank Rowand, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov
In-Reply-To: <4903022.NtioyRkmbB@vostro.rjw.lan>
Hi Rafael,
On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
>> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> > ACPI uses platform devices too. In fact, ACPI device objects are enumerated as
>> > platform devices by default now.
>>
>> Okay, I should have grepped for that:
>> drivers/base/platform.c: ACPI_COMPANION_SET(&pdev->dev, NULL);
>> drivers/base/platform.c: len = acpi_device_modalias(dev, buf,
>> PAGE_SIZE -1);
>> drivers/base/platform.c: rc = acpi_device_uevent_modalias(dev, env);
>> drivers/base/platform.c: /* Then try ACPI style match */
>> drivers/base/platform.c: if (acpi_driver_match_device(dev, drv))
>>
>> These are all cases which have DT version as well, so we're not really
>> all that different here. There's a few more for DT, but that probably
>> means you have just not hit the problems we have yet. For example,
>> what happens if you have an interrupt line in which the controller is
>> probed after the device connected to the interrupt line? That required
>> resolving irqs in platform_get_irq rather than using static resources
>> to support deferred probe.
>
> We don't have this particular problem, because the IRQ controllers are
> enumerated in a special way.
What does "in a special way" mean? Can you please be more specific?
Can you have interrupt controllers that depend on clocks, pin controllers,
and PM domains?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Alternative approach to solve the deferred probe
From: Frank Rowand @ 2015-10-21 15:36 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Geert Uytterhoeven, Tomeu Vizoso, Mark Brown, Greg Kroah-Hartman,
Rob Herring, Michael Turquette, Stephen Boyd, Vinod Koul,
Dan Williams, Linus Walleij, Alexandre Courbot, Thierry Reding,
David Airlie, Terje Bergström, Stephen Warren, Wolfram Sang,
Grant Likely, Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse
In-Reply-To: <20151021081847.GB32532@n2100.arm.linux.org.uk>
On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
< snip >
>>> +
>>> static bool driver_deferred_probe_enable = false;
>>> +
>>> /**
>>> * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>> *
>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>> driver_deferred_probe_trigger();
>>
>> Couldn't you put the "driver_deferred_probe_report = true" here? And then
>> not add another round of probes.
>
> The idea is not to report anything for drivers that were deferred
> during the normal bootup. The above is part of the normal bootup,
> and the deferred activity should not be warned about.
The above is currently the last point for probe to succeed or defer
(until possibly, as you mentioned, module loading resolves the defer).
If a probe defers above, it will defer again below. The set of defers
should be exactly the same above and below.
>
> If we have any devices still deferring after _this_ round, that must
> indicate that some resource they want is not available, and that
> should be warned about.
>
> Of course, modules can defer too - and I made some suggestions in my
> waffle above the patch about that.
>
< adding back trimmed, for fuller context >
>>> /* Sort as many dependencies as possible before exiting initcalls */
>>> flush_workqueue(deferred_wq);
>>> +
>>> + /* Now one final round, reporting any devices that remain deferred */
>>> + driver_deferred_probe_report = true;
>>> + driver_deferred_probe_trigger();
>>> + /* Sort as many dependencies as possible before exiting initcalls */
>>> + flush_workqueue(deferred_wq);
>>> +
>>> return 0;
>>> }
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Frank Rowand @ 2015-10-21 15:59 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: Mark Brown, Greg Kroah-Hartman, Rob Herring, Russell King,
Michael Turquette, Stephen Boyd, Vinod Koul, Dan Williams,
Linus Walleij, Alexandre Courbot, Thierry Reding, David Airlie,
Terje Bergström, Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, Liam Girdwood,
Felipe Balbi
In-Reply-To: <CAAObsKB2BUZ-smid45wOdAQw6h2yNqCydk+azAFNk69ewHJtZQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> On 18 October 2015 at 21:53, Mark Brown <broonie@kernel.org> wrote:
>> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>>> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
>>>> On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
< snip >
> hope you don't mind I summarize the points taken instead of replying
> to the individual emails. I tried to address all the concerns that
> have been raised again in the cover letter, but I guess I did a bad
> job at explaining myself, so here's another (more in-depth) go at it.
< snip >
> 3) Regarding total boot time, I don't expect this series to make much
> of a difference because though we would save a lot of matching and
> querying for resources, that's little time compared with how long we
> wait for hardware to react during probing. Async probing is more
> likely to help with drivers that take a long time to probe.
And then in your reply to Russell's reply to your email you say:
> To be clear, I was saying that this series should NOT affect total
> boot times much.
I'm confused. If I understood correctly, improving boot time was
the key justification for accepting this patch set. For example,
from "[PATCH v7 0/20] On-demand device probing":
I have a problem with the panel on my Tegra Chromebook taking longer
than expected to be ready during boot (Stéphane Marchesin reported what
is basically the same issue in [0]), and have looked into ordered
probing as a better way of solving this than moving nodes around in the
DT or playing with initcall levels and linking order.
...
With this series I get the kernel to output to the panel in 0.5s,
instead of 2.8s.
Alexander Holler reported improved boot times for his patch set
in August, which is another approach to ordering probes
(http://article.gmane.org/gmane.linux.drivers.devicetree/133010).
His results for 5 boards was four booted faster, one slightly
slower:
Some numbers (5 boots on each board, without and with ordering drivers),
all times are seconds.
Kirkwood (dockstar, armv5):
Boot to "Freeing unused kernel memory" (includes mounting the rootfs),
unordered:
4.456016 3.937801 4.114788 4.114526 3.949480 (average 4.1145222)
ordered:
3.173054 3.164045 3.141418 3.480679 3.459298 (3.2836988)
Time needed to sort (of_init_build_order()):
0.003024
Time needed to match drivers to the order (without calling them):
0.002884
Beagleboard (rev C4, armv7):
unordered:
6.706024 6.821746 6.696014 6.673675 6.769866 (6.733465)
ordered:
5.544860 5.514160 5.505859 5.527374 5.496795 (5.5178096)
sorting: 0.021209
matching: 0.006165
Beaglebone Black (rev A5, armv7):
unordered:
3.826531 3.825662 3.826648 3.825434 3.825263 (3.8259076)
ordered:
2.838554 2.838322 2.839459 2.838467 2.838421 (2.8386446)
sorting: 0.004769
matching: 0.004860
imx6q (armv7):
unordered:
3.451998 3.418864 3.446952 3.429974 3.440996 (3.4377568)
ordered:
3.538312 3.549019 3.538105 3.515916 3.555715 (3.5394134)
sorting: 0.004622
matching: 0.003868
While not as dramatic as your results, they are somewhat supportive.
What has changed your assessment that the on-demand device probing
patches will give a big boot performance increase? Do you have
new data or analysis?
-Frank
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Mark Brown @ 2015-10-21 16:27 UTC (permalink / raw)
To: Frank Rowand
Cc: Tomeu Vizoso, Greg Kroah-Hartman, Rob Herring, Russell King,
Michael Turquette, Stephen Boyd, Vinod Koul, Dan Williams,
Linus Walleij, Alexandre Courbot, Thierry Reding, David Airlie,
Terje Bergström, Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, Liam Girdwood,
Felipe Balbi
In-Reply-To: <5627B677.5090109@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]
On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> > To be clear, I was saying that this series should NOT affect total
> > boot times much.
> I'm confused. If I understood correctly, improving boot time was
> the key justification for accepting this patch set. For example,
> from "[PATCH v7 0/20] On-demand device probing":
>
> I have a problem with the panel on my Tegra Chromebook taking longer
> than expected to be ready during boot (Stéphane Marchesin reported what
> is basically the same issue in [0]), and have looked into ordered
> probing as a better way of solving this than moving nodes around in the
> DT or playing with initcall levels and linking order.
>
> ...
>
> With this series I get the kernel to output to the panel in 0.5s,
> instead of 2.8s.
Overall boot time and time to get some individual built in component up
and running aren't the same thing - what this'll do is get things up
more in the link order of the leaf consumers rather than deferring those
leaf consumers when their dependencies aren't ready yet.
> While not as dramatic as your results, they are somewhat supportive.
> What has changed your assessment that the on-demand device probing
> patches will give a big boot performance increase? Do you have
> new data or analysis?
See above, my understanding was that the performance improvements were
more around improved control/predictability/handwave of the boot
ordering rather than total time.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: Alternative approach to solve the deferred probe
From: Grygorii Strashko @ 2015-10-21 16:55 UTC (permalink / raw)
To: frowand.list, Russell King - ARM Linux
Cc: Geert Uytterhoeven, Tomeu Vizoso, Mark Brown, Greg Kroah-Hartman,
Rob Herring, Michael Turquette, Stephen Boyd, Vinod Koul,
Dan Williams, Linus Walleij, Alexandre Courbot, Thierry Reding,
David Airlie, Terje Bergström, Stephen Warren, Wolfram Sang,
Grant Likely, Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse
In-Reply-To: <5627B0F7.7010600@gmail.com>
On 10/21/2015 06:36 PM, Frank Rowand wrote:
> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>
> < snip >
>
>>>> +
>>>> static bool driver_deferred_probe_enable = false;
>>>> +
>>>> /**
>>>> * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>> *
>>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>> driver_deferred_probe_trigger();
>>>
>>> Couldn't you put the "driver_deferred_probe_report = true" here? And then
>>> not add another round of probes.
>>
>> The idea is not to report anything for drivers that were deferred
>> during the normal bootup. The above is part of the normal bootup,
>> and the deferred activity should not be warned about.
>
> The above is currently the last point for probe to succeed or defer
> (until possibly, as you mentioned, module loading resolves the defer).
> If a probe defers above, it will defer again below. The set of defers
> should be exactly the same above and below.
>
Unfortunately this is not "the last point for probe to succeed or defer".
There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
(like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);
Yes - they probably need to be updated to use module_init(), but that's what
we have now). Those drivers will re-trigger deferred device probing if their
probe succeeded.
As result, it is impossible to say when will it happen the
"final round of deferred device probing" :( and final list of drivers which
was "deferred forever" will be know only when kernel exits to User space
("deferred forever" - before loading modules).
May be, we also can consider adding debug_fs entry which can be used to display
actual state of deferred_probe_pending_list?
>>
>> If we have any devices still deferring after _this_ round, that must
>> indicate that some resource they want is not available, and that
>> should be warned about.
>>
>> Of course, modules can defer too - and I made some suggestions in my
>> waffle above the patch about that.
>>
>
> < adding back trimmed, for fuller context >
>
>>>> /* Sort as many dependencies as possible before exiting initcalls */
>>>> flush_workqueue(deferred_wq);
>>>> +
>>>> + /* Now one final round, reporting any devices that remain deferred */
>>>> + driver_deferred_probe_report = true;
>>>> + driver_deferred_probe_trigger();
>>>> + /* Sort as many dependencies as possible before exiting initcalls */
>>>> + flush_workqueue(deferred_wq);
>>>> +
>>>> return 0;
>>>> }
--
regards,
-grygorii
^ permalink raw reply
* Re: Alternative approach to solve the deferred probe
From: Russell King - ARM Linux @ 2015-10-21 17:20 UTC (permalink / raw)
To: Grygorii Strashko
Cc: frowand.list, Geert Uytterhoeven, Tomeu Vizoso, Mark Brown,
Greg Kroah-Hartman, Rob Herring, Michael Turquette, Stephen Boyd,
Vinod Koul, Dan Williams, Linus Walleij, Alexandre Courbot,
Thierry Reding, David Airlie, Terje Bergström,
Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse
In-Reply-To: <5627C381.60602@ti.com>
On Wed, Oct 21, 2015 at 07:55:29PM +0300, Grygorii Strashko wrote:
> On 10/21/2015 06:36 PM, Frank Rowand wrote:
> > The above is currently the last point for probe to succeed or defer
> > (until possibly, as you mentioned, module loading resolves the defer).
> > If a probe defers above, it will defer again below. The set of defers
> > should be exactly the same above and below.
> >
>
> Unfortunately this is not "the last point for probe to succeed or defer".
Of course it isn't. Being pedantic, there's actually no such thing,
because the point that the kernel as finished booting can never actually
be determined with things like modules being present. That's something
I've acknowledged from the start of this.
> There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);
> Yes - they probably need to be updated to use module_init(), but that's what
> we have now). Those drivers will re-trigger deferred device probing if their
> probe succeeded.
Maybe this particular late_initcall() which triggers off the deferred
probing should be moved to its own really_late_initcall() which happens
as the very last thing - I think this is intended to run after everything
else has had a chance to probe once.
> As result, it is impossible to say when will it happen the
> "final round of deferred device probing" :( and final list of drivers
> which was "deferred forever" will be know only when kernel exits to
> User space ("deferred forever" - before loading modules).
>
> May be, we also can consider adding debug_fs entry which can be used to
> display actual state of deferred_probe_pending_list?
There are complaints in this thread about the existing deferred probing
implementation being hard to debug - where it's known that a device
has deferred, but it's not known why that happened.
That would be solved by my proposal, as this final round of probing
before entering userspace after _all_ normal device probes have been
attempted once and then we've tried to satisfy the deferred probe
(okay, that's what it's _supposed_ to be - and as it takes three lines
to write it, you'll excuse me if I just use the abbreviated "final
round of deferred probe" which is much shorter - but remember that
the long version is what I actually mean) would produce a list of
not only the devices that failed to probe, but also the cause of the
deferred probes.
My proposal would ensure that subsystems are happier to add these
prints, because in the normal scenario where we have deferred probing,
we're not littering the console log with lots of useless failure
messages which make people stop and think "now did device X probe?"
It also means scripts in our boot farms can more effectively analyse
the log and determine whether the boot was actually successful and
contained no errors.
Merely printing the list of devices which have been deferred is next
to useless. The next question will always be "why did device X defer?"
and if that can't be answered, it means people having to spend a long
time adding lots of printks to the kernel at lots of -EPROBE_DEFER
returning sites or in the relevant drivers, tracing through the code
back towards the -EPROBE_DEFER sites to try and track it down.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: Alternative approach to solve the deferred probe
From: Frank Rowand @ 2015-10-21 18:02 UTC (permalink / raw)
To: Grygorii Strashko
Cc: Russell King - ARM Linux, Geert Uytterhoeven, Tomeu Vizoso,
Mark Brown, Greg Kroah-Hartman, Rob Herring, Michael Turquette,
Stephen Boyd, Vinod Koul, Dan Williams, Linus Walleij,
Alexandre Courbot, Thierry Reding, David Airlie,
Terje Bergström, Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov
In-Reply-To: <5627C381.60602@ti.com>
On 10/21/2015 9:55 AM, Grygorii Strashko wrote:
> On 10/21/2015 06:36 PM, Frank Rowand wrote:
>> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>>
>> < snip >
>>
>>>>> +
>>>>> static bool driver_deferred_probe_enable = false;
>>>>> +
>>>>> /**
>>>>> * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>>> *
>>>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>>> driver_deferred_probe_trigger();
>>>>
>>>> Couldn't you put the "driver_deferred_probe_report = true" here? And then
>>>> not add another round of probes.
>>>
>>> The idea is not to report anything for drivers that were deferred
>>> during the normal bootup. The above is part of the normal bootup,
>>> and the deferred activity should not be warned about.
>>
>> The above is currently the last point for probe to succeed or defer
>> (until possibly, as you mentioned, module loading resolves the defer).
>> If a probe defers above, it will defer again below. The set of defers
>> should be exactly the same above and below.
>>
>
> Unfortunately this is not "the last point for probe to succeed or defer".
> There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);
Yes, cpsw_init() should _not_ be a late_initcall. This is yet another
example of playing games with ordering probes that we have been trying
to eliminate.
Thanks for pointing out one of the resulting problems this causes for the
deferred probe mechanism.
> Yes - they probably need to be updated to use module_init(), but that's what
> we have now). Those drivers will re-trigger deferred device probing if their
> probe succeeded.
Yes, if cpsw_init() leads to a successful probe, then deferred device probing
will be re-triggered. I do not know if cpsw_init() will be called before or
after deferred_probe_initcall(). The general initcall mechanism does not
provide any ordering guarantees between the two functions because they are
at the same initcall level.
>
> As result, it is impossible to say when will it happen the
> "final round of deferred device probing" :( and final list of drivers which
> was "deferred forever" will be know only when kernel exits to User space
> ("deferred forever" - before loading modules).
>
> May be, we also can consider adding debug_fs entry which can be used to display
> actual state of deferred_probe_pending_list?
>
>>>
>>> If we have any devices still deferring after _this_ round, that must
>>> indicate that some resource they want is not available, and that
>>> should be warned about.
>>>
>>> Of course, modules can defer too - and I made some suggestions in my
>>> waffle above the patch about that.
>>>
>>
>> < adding back trimmed, for fuller context >
>>
>>>>> /* Sort as many dependencies as possible before exiting initcalls */
>>>>> flush_workqueue(deferred_wq);
>>>>> +
>>>>> + /* Now one final round, reporting any devices that remain deferred */
>>>>> + driver_deferred_probe_report = true;
>>>>> + driver_deferred_probe_trigger();
>>>>> + /* Sort as many dependencies as possible before exiting initcalls */
>>>>> + flush_workqueue(deferred_wq);
>>>>> +
>>>>> return 0;
>>>>> }
>
>
^ permalink raw reply
* Re: Alternative approach to solve the deferred probe
From: Grygorii Strashko @ 2015-10-21 18:13 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: frowand.list, Geert Uytterhoeven, Tomeu Vizoso, Mark Brown,
Greg Kroah-Hartman, Rob Herring, Michael Turquette, Stephen Boyd,
Vinod Koul, Dan Williams, Linus Walleij, Alexandre Courbot,
Thierry Reding, David Airlie, Terje Bergström,
Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse
In-Reply-To: <20151021172042.GJ32532@n2100.arm.linux.org.uk>
Hi Russell,
On 10/21/2015 08:20 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 07:55:29PM +0300, Grygorii Strashko wrote:
>> On 10/21/2015 06:36 PM, Frank Rowand wrote:
>>> The above is currently the last point for probe to succeed or defer
>>> (until possibly, as you mentioned, module loading resolves the defer).
>>> If a probe defers above, it will defer again below. The set of defers
>>> should be exactly the same above and below.
>>>
>>
>> Unfortunately this is not "the last point for probe to succeed or defer".
>
> Of course it isn't. Being pedantic, there's actually no such thing,
> because the point that the kernel as finished booting can never actually
> be determined with things like modules being present. That's something
> I've acknowledged from the start of this.
>
>> There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
>> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);
>> Yes - they probably need to be updated to use module_init(), but that's what
>> we have now). Those drivers will re-trigger deferred device probing if their
>> probe succeeded.
>
> Maybe this particular late_initcall() which triggers off the deferred
> probing should be moved to its own really_late_initcall() which happens
> as the very last thing - I think this is intended to run after everything
> else has had a chance to probe once.
>
>> As result, it is impossible to say when will it happen the
>> "final round of deferred device probing" :( and final list of drivers
>> which was "deferred forever" will be know only when kernel exits to
>> User space ("deferred forever" - before loading modules).
>>
>> May be, we also can consider adding debug_fs entry which can be used to
>> display actual state of deferred_probe_pending_list?
>
> There are complaints in this thread about the existing deferred probing
> implementation being hard to debug - where it's known that a device
> has deferred, but it's not known why that happened.
>
> That would be solved by my proposal, as this final round of probing
> before entering userspace after _all_ normal device probes have been
> attempted once and then we've tried to satisfy the deferred probe
> (okay, that's what it's _supposed_ to be - and as it takes three lines
> to write it, you'll excuse me if I just use the abbreviated "final
> round of deferred probe" which is much shorter - but remember that
> the long version is what I actually mean) would produce a list of
> not only the devices that failed to probe, but also the cause of the
> deferred probes.
>
> My proposal would ensure that subsystems are happier to add these
> prints, because in the normal scenario where we have deferred probing,
> we're not littering the console log with lots of useless failure
> messages which make people stop and think "now did device X probe?"
> It also means scripts in our boot farms can more effectively analyse
> the log and determine whether the boot was actually successful and
> contained no errors.
>
> Merely printing the list of devices which have been deferred is next
> to useless. The next question will always be "why did device X defer?"
> and if that can't be answered, it means people having to spend a long
> time adding lots of printks to the kernel at lots of -EPROBE_DEFER
> returning sites or in the relevant drivers, tracing through the code
> back towards the -EPROBE_DEFER sites to try and track it down.
>
I perfectly understand your proposal and spent a lot of time trying to
debug such kind issues also (and using printks).
But I worry a bit (and that my main point) about these few additional
rounds of deferred device probing which I have right now and which allows
some of drivers to finish, finally, their probes successfully.
With proposed change I'll get more messages in boot log, but some of
them will belong to drivers which have been probed successfully and so,
they will be not really useful.
As result, I think, the most important thing is to identify (or create)
some point during kernel boot when it will be possible to say that all
built-in drivers (at least) finish their probes 100% (done or defer).
Might be do_initcalls() can be updated (smth like this):
static void __init do_initcalls(void)
{
int level;
for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
do_initcall_level(level);
+ wait_for_device_probe();
+ /* Now one final round, reporting any devices that remain deferred */
+ driver_deferred_probe_report = true;
+ driver_deferred_probe_trigger();
+ wait_for_device_probe();
}
Also, in my opinion, it will be useful if this debugging feature will be optional.
Thanks.
--
regards,
-grygorii
S/ILKP
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Frank Rowand @ 2015-10-21 18:18 UTC (permalink / raw)
To: Mark Brown
Cc: Tomeu Vizoso, Greg Kroah-Hartman, Rob Herring, Russell King,
Michael Turquette, Stephen Boyd, Vinod Koul, Dan Williams,
Linus Walleij, Alexandre Courbot, Thierry Reding, David Airlie,
Terje Bergström, Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, Liam Girdwood,
Felipe Balbi
In-Reply-To: <20151021162758.GP32054@sirena.org.uk>
On 10/21/2015 9:27 AM, Mark Brown wrote:
> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
>
>>> To be clear, I was saying that this series should NOT affect total
>>> boot times much.
>
>> I'm confused. If I understood correctly, improving boot time was
>> the key justification for accepting this patch set. For example,
>> from "[PATCH v7 0/20] On-demand device probing":
>>
>> I have a problem with the panel on my Tegra Chromebook taking longer
>> than expected to be ready during boot (Stéphane Marchesin reported what
>> is basically the same issue in [0]), and have looked into ordered
>> probing as a better way of solving this than moving nodes around in the
>> DT or playing with initcall levels and linking order.
>>
>> ...
>>
>> With this series I get the kernel to output to the panel in 0.5s,
>> instead of 2.8s.
>
> Overall boot time and time to get some individual built in component up
> and running aren't the same thing - what this'll do is get things up
> more in the link order of the leaf consumers rather than deferring those
> leaf consumers when their dependencies aren't ready yet.
Thanks! I read too much into what was being improved.
So this patch series, which on other merits may be a good idea, is as
a by product solving a specific ordering issue, moving successful panel
initialization to an earlier point in the boot sequence, if I now
understand more correctly.
In that context, this seems like yet another ad hoc way of causing the
probe order to change in a way to solves one specific issue? Could
it just as likely move the boot order of some other driver on some
other board later, to the detriment of somebody else?
>
>> While not as dramatic as your results, they are somewhat supportive.
>> What has changed your assessment that the on-demand device probing
>> patches will give a big boot performance increase? Do you have
>> new data or analysis?
>
> See above, my understanding was that the performance improvements were
> more around improved control/predictability/handwave of the boot
> ordering rather than total time.
>
^ permalink raw reply
* Re: Alternative approach to solve the deferred probe
From: Russell King - ARM Linux @ 2015-10-21 18:28 UTC (permalink / raw)
To: Grygorii Strashko
Cc: frowand.list, Geert Uytterhoeven, Tomeu Vizoso, Mark Brown,
Greg Kroah-Hartman, Rob Herring, Michael Turquette, Stephen Boyd,
Vinod Koul, Dan Williams, Linus Walleij, Alexandre Courbot,
Thierry Reding, David Airlie, Terje Bergström,
Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse
In-Reply-To: <5627D5DC.1040708@ti.com>
On Wed, Oct 21, 2015 at 09:13:48PM +0300, Grygorii Strashko wrote:
> But I worry a bit (and that my main point) about these few additional
> rounds of deferred device probing which I have right now and which allows
> some of drivers to finish, finally, their probes successfully.
> With proposed change I'll get more messages in boot log, but some of
> them will belong to drivers which have been probed successfully and so,
> they will be not really useful.
Then you haven't properly understood my proposal.
I want to get rid of all the "X deferred its probing" messages up until
the point that we set the "please report deferred probes" flag.
That _should_ mean that all the deferred probing that goes on becomes
_totally_ silent and becomes hidden (unless you really want to see it,
in which case we can make a debug option which turns it on) up until
we're at the point where we want to enter userspace.
At that point, we then report into the kernel log which devices are
still deferring and, via appropriately placed dev_warn_deferred(),
the reasons why the devices are being deferred.
So, gone will be all the messages earlier in the log about device X
not having a GPIO/clock/whatever because the device providing the
GPIO/clock/whatever hasn't been probed.
If everything is satisfied by the time we run this last round (again,
I'm not using a three line sentence to describe exactly what I mean,
I'm sure you know by now... oops, I just did) then the kernel will
report nothing about any deferrals. That's _got_ to be an improvement.
>
> As result, I think, the most important thing is to identify (or create)
> some point during kernel boot when it will be possible to say that all
> built-in drivers (at least) finish their probes 100% (done or defer).
>
> Might be do_initcalls() can be updated (smth like this):
> static void __init do_initcalls(void)
> {
> int level;
>
> for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
> do_initcall_level(level);
>
> + wait_for_device_probe();
> + /* Now one final round, reporting any devices that remain deferred */
> + driver_deferred_probe_report = true;
> + driver_deferred_probe_trigger();
> + wait_for_device_probe();
> }
>
> Also, in my opinion, it will be useful if this debugging feature will be
> optional.
I wonder why you want it optional... so I'm going to guess and cover
both cases I can think of below to head off another round of reply on
this point (sorry if this sucks eggs.)
I don't see it as being optional, because it's going to be cheap to run
in the case of a system which has very few or no errors - which is what
you should have for production systems, right?
Remember, only devices and drivers that are present and have been
probed once get added to the deferred probe list, not devices for
which their drivers are modules.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: Alternative approach to solve the deferred probe
From: Grygorii Strashko @ 2015-10-21 18:29 UTC (permalink / raw)
To: frowand.list
Cc: Russell King - ARM Linux, Geert Uytterhoeven, Tomeu Vizoso,
Mark Brown, Greg Kroah-Hartman, Rob Herring, Michael Turquette,
Stephen Boyd, Vinod Koul, Dan Williams, Linus Walleij,
Alexandre Courbot, Thierry Reding, David Airlie,
Terje Bergström, Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov
In-Reply-To: <5627D353.2040007@gmail.com>
On 10/21/2015 09:02 PM, Frank Rowand wrote:
> On 10/21/2015 9:55 AM, Grygorii Strashko wrote:
>> On 10/21/2015 06:36 PM, Frank Rowand wrote:
>>> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>>>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>>>
>>> < snip >
>>>
>>>>>> +
>>>>>> static bool driver_deferred_probe_enable = false;
>>>>>> +
>>>>>> /**
>>>>>> * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>>>> *
>>>>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>>>> driver_deferred_probe_trigger();
>>>>>
>>>>> Couldn't you put the "driver_deferred_probe_report = true" here? And then
>>>>> not add another round of probes.
>>>>
>>>> The idea is not to report anything for drivers that were deferred
>>>> during the normal bootup. The above is part of the normal bootup,
>>>> and the deferred activity should not be warned about.
>>>
>>> The above is currently the last point for probe to succeed or defer
>>> (until possibly, as you mentioned, module loading resolves the defer).
>>> If a probe defers above, it will defer again below. The set of defers
>>> should be exactly the same above and below.
>>>
>>
>> Unfortunately this is not "the last point for probe to succeed or defer".
>> There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
>> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);
>
> Yes, cpsw_init() should _not_ be a late_initcall. This is yet another
> example of playing games with ordering probes that we have been trying
> to eliminate.
yes, we're trying to solve such issues and have all TI's drivers initialized
from module_init() level, but as usual this process is not so fast.
You know, some times ago there was no other way to solve boot ordering issues,
but only to play with init levels :) And, as result, right now in drivers/
and sound/ folders there are >77 occurrences of late_initcall().
>
> Thanks for pointing out one of the resulting problems this causes for the
> deferred probe mechanism.
>
>> Yes - they probably need to be updated to use module_init(), but that's what
>> we have now). Those drivers will re-trigger deferred device probing if their
>> probe succeeded.
>
> Yes, if cpsw_init() leads to a successful probe, then deferred device probing
> will be re-triggered. I do not know if cpsw_init() will be called before or
> after deferred_probe_initcall(). The general initcall mechanism does not
> provide any ordering guarantees between the two functions because they are
> at the same initcall level.
It will be called after and it will re-triggered deferred device probing.
Now ordering of init calls will be specified by drivers/Makefile
which itself is funny thing.
>
>>
>> As result, it is impossible to say when will it happen the
>> "final round of deferred device probing" :( and final list of drivers which
>> was "deferred forever" will be know only when kernel exits to User space
>> ("deferred forever" - before loading modules).
>>
>> May be, we also can consider adding debug_fs entry which can be used to display
>> actual state of deferred_probe_pending_list?
>>
>>>>
>>>> If we have any devices still deferring after _this_ round, that must
>>>> indicate that some resource they want is not available, and that
>>>> should be warned about.
>>>>
>>>> Of course, modules can defer too - and I made some suggestions in my
>>>> waffle above the patch about that.
>>>>
>>>
>>> < adding back trimmed, for fuller context >
>>>
>>>>>> /* Sort as many dependencies as possible before exiting initcalls */
>>>>>> flush_workqueue(deferred_wq);
>>>>>> +
>>>>>> + /* Now one final round, reporting any devices that remain deferred */
>>>>>> + driver_deferred_probe_report = true;
>>>>>> + driver_deferred_probe_trigger();
>>>>>> + /* Sort as many dependencies as possible before exiting initcalls */
>>>>>> + flush_workqueue(deferred_wq);
>>>>>> +
>>>>>> return 0;
>>>>>> }
>>
>>
>
--
regards,
-grygorii
^ permalink raw reply
* Re: Alternative approach to solve the deferred probe
From: Russell King - ARM Linux @ 2015-10-21 20:35 UTC (permalink / raw)
To: Frank Rowand
Cc: Geert Uytterhoeven, Tomeu Vizoso, Mark Brown, Greg Kroah-Hartman,
Rob Herring, Michael Turquette, Stephen Boyd, Vinod Koul,
Dan Williams, Linus Walleij, Alexandre Courbot, Thierry Reding,
David Airlie, Terje Bergström, Stephen Warren, Wolfram Sang,
Grant Likely, Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse
In-Reply-To: <5627B0F7.7010600@gmail.com>
On Wed, Oct 21, 2015 at 08:36:23AM -0700, Frank Rowand wrote:
> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
> > On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
> >> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>
> < snip >
>
> >>> +
> >>> static bool driver_deferred_probe_enable = false;
> >>> +
> >>> /**
> >>> * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
> >>> *
> >>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
> >>> driver_deferred_probe_trigger();
> >>
> >> Couldn't you put the "driver_deferred_probe_report = true" here? And then
> >> not add another round of probes.
> >
> > The idea is not to report anything for drivers that were deferred
> > during the normal bootup. The above is part of the normal bootup,
> > and the deferred activity should not be warned about.
>
> The above is currently the last point for probe to succeed or defer
> (until possibly, as you mentioned, module loading resolves the defer).
> If a probe defers above, it will defer again below. The set of defers
> should be exactly the same above and below.
Why should it? Isn't this late_initcall() the first opportunity that
deferred devices get to be re-probed from their first set of attempts
via the drivers having their initcalls called?
If what you're saying is true, what's the point of this late_initcall()?
<re-cut again, I've no idea why you keep adding it back>
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Mark Brown @ 2015-10-21 21:03 UTC (permalink / raw)
To: Frank Rowand
Cc: Tomeu Vizoso, Greg Kroah-Hartman, Rob Herring, Russell King,
Michael Turquette, Stephen Boyd, Vinod Koul, Dan Williams,
Linus Walleij, Alexandre Courbot, Thierry Reding, David Airlie,
Terje Bergström, Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, Liam Girdwood,
Felipe Balbi
In-Reply-To: <5627D6E0.5020708@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]
On Wed, Oct 21, 2015 at 11:18:08AM -0700, Frank Rowand wrote:
> On 10/21/2015 9:27 AM, Mark Brown wrote:
> > Overall boot time and time to get some individual built in component up
> > and running aren't the same thing - what this'll do is get things up
> > more in the link order of the leaf consumers rather than deferring those
> > leaf consumers when their dependencies aren't ready yet.
> Thanks! I read too much into what was being improved.
> So this patch series, which on other merits may be a good idea, is as
> a by product solving a specific ordering issue, moving successful panel
> initialization to an earlier point in the boot sequence, if I now
> understand more correctly.
Yeah, that's my understanding.
> In that context, this seems like yet another ad hoc way of causing the
> probe order to change in a way to solves one specific issue? Could
> it just as likely move the boot order of some other driver on some
> other board later, to the detriment of somebody else?
Indeed. My general feeling is that it does make the link order stuff
more predictable and easier to work with and it does have other merits
(in terms of the error reporting, though there's other ways to address
that like the one Russell is proposing).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Rob Herring @ 2015-10-21 21:12 UTC (permalink / raw)
To: Frank Rowand
Cc: Mark Brown, Tomeu Vizoso, Greg Kroah-Hartman, Russell King,
Michael Turquette, Stephen Boyd, Vinod Koul, Dan Williams,
Linus Walleij, Alexandre Courbot, Thierry Reding, David Airlie,
Terje Bergström, Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, Liam Girdwood,
Felipe Balbi
In-Reply-To: <5627D6E0.5020708@gmail.com>
On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> On 10/21/2015 9:27 AM, Mark Brown wrote:
>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
>>
>>>> To be clear, I was saying that this series should NOT affect total
>>>> boot times much.
>>
>>> I'm confused. If I understood correctly, improving boot time was
>>> the key justification for accepting this patch set. For example,
>>> from "[PATCH v7 0/20] On-demand device probing":
>>>
>>> I have a problem with the panel on my Tegra Chromebook taking longer
>>> than expected to be ready during boot (Stéphane Marchesin reported what
>>> is basically the same issue in [0]), and have looked into ordered
>>> probing as a better way of solving this than moving nodes around in the
>>> DT or playing with initcall levels and linking order.
>>>
>>> ...
>>>
>>> With this series I get the kernel to output to the panel in 0.5s,
>>> instead of 2.8s.
>>
>> Overall boot time and time to get some individual built in component up
>> and running aren't the same thing - what this'll do is get things up
>> more in the link order of the leaf consumers rather than deferring those
>> leaf consumers when their dependencies aren't ready yet.
>
> Thanks! I read too much into what was being improved.
>
> So this patch series, which on other merits may be a good idea, is as
> a by product solving a specific ordering issue, moving successful panel
> initialization to an earlier point in the boot sequence, if I now
> understand more correctly.
>
> In that context, this seems like yet another ad hoc way of causing the
> probe order to change in a way to solves one specific issue? Could
> it just as likely move the boot order of some other driver on some
> other board later, to the detriment of somebody else?
Time to display on is important for many products. Having the console
up as early as possible is another case. CAN bus is another. This is a
real problem that is not just bad drivers.
I don't think it is completely ad hoc. Given all devices are
registered after drivers, drivers will still probe first in initcall
level order and then link order AFAIK. We may not take (more) initcall
level tweak hacks, but that is a much more simple change for
downstream. Don't get me wrong, I'd really like to see a way to
control order independent of initcall level.
Rob
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Frank Rowand @ 2015-10-21 21:50 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Brown, Tomeu Vizoso, Greg Kroah-Hartman, Russell King,
Michael Turquette, Stephen Boyd, Vinod Koul, Dan Williams,
Linus Walleij, Alexandre Courbot, Thierry Reding, David Airlie,
Terje Bergström, Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, Liam Girdwood,
Felipe Balbi
In-Reply-To: <CAL_Jsq+FPtCuBnte2HTgbdpNYM=v_kLaCRcOC1kMaCQwVC=5Kw@mail.gmail.com>
On 10/21/2015 2:12 PM, Rob Herring wrote:
> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> On 10/21/2015 9:27 AM, Mark Brown wrote:
>>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
>>>
>>>>> To be clear, I was saying that this series should NOT affect total
>>>>> boot times much.
>>>
>>>> I'm confused. If I understood correctly, improving boot time was
>>>> the key justification for accepting this patch set. For example,
>>>> from "[PATCH v7 0/20] On-demand device probing":
>>>>
>>>> I have a problem with the panel on my Tegra Chromebook taking longer
>>>> than expected to be ready during boot (Stéphane Marchesin reported what
>>>> is basically the same issue in [0]), and have looked into ordered
>>>> probing as a better way of solving this than moving nodes around in the
>>>> DT or playing with initcall levels and linking order.
>>>>
>>>> ...
>>>>
>>>> With this series I get the kernel to output to the panel in 0.5s,
>>>> instead of 2.8s.
>>>
>>> Overall boot time and time to get some individual built in component up
>>> and running aren't the same thing - what this'll do is get things up
>>> more in the link order of the leaf consumers rather than deferring those
>>> leaf consumers when their dependencies aren't ready yet.
>>
>> Thanks! I read too much into what was being improved.
>>
>> So this patch series, which on other merits may be a good idea, is as
>> a by product solving a specific ordering issue, moving successful panel
>> initialization to an earlier point in the boot sequence, if I now
>> understand more correctly.
>>
>> In that context, this seems like yet another ad hoc way of causing the
>> probe order to change in a way to solves one specific issue? Could
>> it just as likely move the boot order of some other driver on some
>> other board later, to the detriment of somebody else?
>
> Time to display on is important for many products. Having the console
> up as early as possible is another case. CAN bus is another. This is a
> real problem that is not just bad drivers.
Yes, I agree.
What I am seeing is that there continues to be a need for the ability
to explicitly order at least some driver initialization (at some
granularity), despite the push back against explicit ordering that
has been present in the past.
> I don't think it is completely ad hoc. Given all devices are
> registered after drivers, drivers will still probe first in initcall
> level order and then link order AFAIK. We may not take (more) initcall
> level tweak hacks, but that is a much more simple change for
> downstream. Don't get me wrong, I'd really like to see a way to
> control order independent of initcall level.
>
> Rob
Yep, it is not directly ad hoc, just a fortunate side effect in
this case. So just accidently ad hoc. :-)
-Frank
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Rafael J. Wysocki @ 2015-10-21 23:39 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, David Woodhouse, Mark Brown, Greg Kroah-Hartman,
Tomeu Vizoso, Russell King, Michael Turquette, Stephen Boyd,
Vinod Koul, Dan Williams, Linus Walleij, Alexandre Courbot,
Thierry Reding, David Airlie, Terje Bergström,
Stephen Warren, Wolfram Sang, Frank Rowand, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov
In-Reply-To: <CAMuHMdWoSdoT1p0e+Bc9ucrykxO7ESLKYHRzackpVjQAs_XaDg@mail.gmail.com>
On Wednesday, October 21, 2015 10:55:14 AM Geert Uytterhoeven wrote:
> Hi Rafael,
>
> On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
> >> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >> > ACPI uses platform devices too. In fact, ACPI device objects are enumerated as
> >> > platform devices by default now.
> >>
> >> Okay, I should have grepped for that:
> >> drivers/base/platform.c: ACPI_COMPANION_SET(&pdev->dev, NULL);
> >> drivers/base/platform.c: len = acpi_device_modalias(dev, buf,
> >> PAGE_SIZE -1);
> >> drivers/base/platform.c: rc = acpi_device_uevent_modalias(dev, env);
> >> drivers/base/platform.c: /* Then try ACPI style match */
> >> drivers/base/platform.c: if (acpi_driver_match_device(dev, drv))
> >>
> >> These are all cases which have DT version as well, so we're not really
> >> all that different here. There's a few more for DT, but that probably
> >> means you have just not hit the problems we have yet. For example,
> >> what happens if you have an interrupt line in which the controller is
> >> probed after the device connected to the interrupt line? That required
> >> resolving irqs in platform_get_irq rather than using static resources
> >> to support deferred probe.
> >
> > We don't have this particular problem, because the IRQ controllers are
> > enumerated in a special way.
>
> What does "in a special way" mean? Can you please be more specific?
>
> Can you have interrupt controllers that depend on clocks, pin controllers,
> and PM domains?
Currently, there's no native way to represent those dependencies in ACPI.
Thanks,
Rafael
^ permalink raw reply
* Re: Alternative approach to solve the deferred probe
From: Frank Rowand @ 2015-10-22 0:05 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Geert Uytterhoeven, Tomeu Vizoso, Mark Brown, Greg Kroah-Hartman,
Rob Herring, Michael Turquette, Stephen Boyd, Vinod Koul,
Dan Williams, Linus Walleij, Alexandre Courbot, Thierry Reding,
David Airlie, Terje Bergström, Stephen Warren, Wolfram Sang,
Grant Likely, Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse
In-Reply-To: <20151021203519.GO32532@n2100.arm.linux.org.uk>
On 10/21/2015 1:35 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 08:36:23AM -0700, Frank Rowand wrote:
>> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>>
>> < snip >
>>
>>>>> +
>>>>> static bool driver_deferred_probe_enable = false;
>>>>> +
>>>>> /**
>>>>> * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>>> *
>>>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>>> driver_deferred_probe_trigger();
>>>>
>>>> Couldn't you put the "driver_deferred_probe_report = true" here? And then
>>>> not add another round of probes.
>>>
>>> The idea is not to report anything for drivers that were deferred
>>> during the normal bootup. The above is part of the normal bootup,
>>> and the deferred activity should not be warned about.
>>
>> The above is currently the last point for probe to succeed or defer
>> (until possibly, as you mentioned, module loading resolves the defer).
>> If a probe defers above, it will defer again below. The set of defers
>> should be exactly the same above and below.
>
> Why should it?
My assertion was incorrect. A probe in the deferral processing can
result in the driver being placed on the new deferred list, then when
a later probe of another deferred driver succeeds, the first driver
will be moved to the active deferred list, and might succeed on
the second probe attempt (or with the current messages would result
in a second set of deferred messages). So yes, placing
"driver_deferred_probe_report = true" where your patch put it and
running through the deferred probe processing again is correct.
-Frank
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Rafael J. Wysocki @ 2015-10-22 0:54 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: Alan Stern, Mark Brown, Rob Herring, David Woodhouse,
Greg Kroah-Hartman, Russell King, Michael Turquette, Stephen Boyd,
Vinod Koul, Dan Williams, Linus Walleij, Alexandre Courbot,
Thierry Reding, David Airlie, Terje Bergström,
Stephen Warren, Wolfram Sang, Frank Rowand, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov
In-Reply-To: <CAAObsKChQN4gg91dCWJS_Co_MrYyBrB1J7gxgGo4hsPXNZRp3g@mail.gmail.com>
On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote:
> On 20 October 2015 at 18:04, Alan Stern <stern@rowland.harvard.edu> wrote:
> > On Tue, 20 Oct 2015, Mark Brown wrote:
> >
> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> >>
> >> > Furthermore, that applies only to devices that use synchronous suspend.
> >> > Async suspend is becoming common, and there the only restrictions are
> >> > parent-child relations plus whatever explicit requirements that drivers
> >> > impose by calling device_pm_wait_for_dev().
> >>
> >> Hrm, this is the first I'd noticed that feature though I see the initial
> >> commit dates from January.
> >
> > Async suspend and device_pm_wait_for_dev() were added in January 2010,
> > not 2015!
> >
> >> It looks like most of the users are PCs at
> >> the minute but we should be using it more widely for embedded things,
> >> there's definitely some cases I'm aware of where it will allow us to
> >> remove some open coding.
> >>
> >> It does seem like we want to be feeding dependency information we
> >> discover for probing way into the suspend dependencies...
> >
> > Rafael has been thinking about a way to do this systematically.
> > Nothing concrete has emerged yet.
>
> This iteration of the series would make this quite easy, as
> dependencies are calculated before probes are attempted:
>
> https://lkml.org/lkml/2015/6/17/311
Well, if you know how to represent "links" between devices, the mechanism
introduced here doesn't really add much value, because in that case the
core knows what the dependencies are in the first place and can only
defer the probes that have to be deferred.
Thanks,
Rafael
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Tomeu Vizoso @ 2015-10-22 9:05 UTC (permalink / raw)
To: Frank Rowand
Cc: Rob Herring, Mark Brown, Greg Kroah-Hartman, Russell King,
Michael Turquette, Stephen Boyd, Vinod Koul, Dan Williams,
Linus Walleij, Alexandre Courbot, Thierry Reding, David Airlie,
Terje Bergström, Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, Liam Girdwood,
Felipe Balbi
In-Reply-To: <562808AF.7090406@gmail.com>
On 21 October 2015 at 23:50, Frank Rowand <frowand.list@gmail.com> wrote:
> On 10/21/2015 2:12 PM, Rob Herring wrote:
>> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>>> On 10/21/2015 9:27 AM, Mark Brown wrote:
>>>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>>>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
>>>>
>>>>>> To be clear, I was saying that this series should NOT affect total
>>>>>> boot times much.
>>>>
>>>>> I'm confused. If I understood correctly, improving boot time was
>>>>> the key justification for accepting this patch set. For example,
>>>>> from "[PATCH v7 0/20] On-demand device probing":
>>>>>
>>>>> I have a problem with the panel on my Tegra Chromebook taking longer
>>>>> than expected to be ready during boot (Stéphane Marchesin reported what
>>>>> is basically the same issue in [0]), and have looked into ordered
>>>>> probing as a better way of solving this than moving nodes around in the
>>>>> DT or playing with initcall levels and linking order.
>>>>>
>>>>> ...
>>>>>
>>>>> With this series I get the kernel to output to the panel in 0.5s,
>>>>> instead of 2.8s.
>>>>
>>>> Overall boot time and time to get some individual built in component up
>>>> and running aren't the same thing - what this'll do is get things up
>>>> more in the link order of the leaf consumers rather than deferring those
>>>> leaf consumers when their dependencies aren't ready yet.
>>>
>>> Thanks! I read too much into what was being improved.
>>>
>>> So this patch series, which on other merits may be a good idea, is as
>>> a by product solving a specific ordering issue, moving successful panel
>>> initialization to an earlier point in the boot sequence, if I now
>>> understand more correctly.
>>>
>>> In that context, this seems like yet another ad hoc way of causing the
>>> probe order to change in a way to solves one specific issue? Could
>>> it just as likely move the boot order of some other driver on some
>>> other board later, to the detriment of somebody else?
>>
>> Time to display on is important for many products. Having the console
>> up as early as possible is another case. CAN bus is another. This is a
>> real problem that is not just bad drivers.
>
> Yes, I agree.
>
> What I am seeing is that there continues to be a need for the ability
> to explicitly order at least some driver initialization (at some
> granularity), despite the push back against explicit ordering that
> has been present in the past.
The important point that I have struggled to explain is that right now
for downstreams to influence the order in which devices are probed,
they have to carry a substantial amount of patches that cannot be ever
upstreamed. This fiddling with initcall levels and link order means
changing files that are very frequently changing, increasing the
amount of work when rebasing and increasing the probability of
regressions after a rebase.
This just adds up to other shortcomings of mainline and ends up with
the net result of vendors getting stuck with 3.4 kernels on SoCs that
start production in 2015. Another consequence is that vendors don't
have a chance to upstream their stuff even if they cared. The
overarching goal of the project I'm in is to reduce those shortcomings
that downstreams have to workaround, to facilitate their involvement
upstream.
With this series, the order in which devices are probed becomes the
order in which they were registered, which is the order in which the
devices appear in the FW description of the hw or in the board files
(much more predictable, which makes for a more robust process). For DT
and board files, which cover a good part of the consumer devices
shipped today with Linux, the downstream could just change the order
of device nodes and get their display or whatever to probe before any
other devices.
And even if downstream's hw has a SoC .dtsi that exists in mainline,
they could add a step to their build process that automatically
reorders the nodes to avoid carrying changes to that DT fragment.
But that's moot currently because Greg believes that the time spent
probing devices at boot time could be reduced enough so that the order
in which devices are probed becomes irrelevant. IME that would have to
be under 200ms so that the user doesn't notice and that's unicorn-far
from any bootlog I have ever seen.
Given that downstreams are already carrying as many hacks as they
could think of to speed total boot up, I think this is effectively
telling them to go away.
Sorry for the rant,
Tomeu
>> I don't think it is completely ad hoc. Given all devices are
>> registered after drivers, drivers will still probe first in initcall
>> level order and then link order AFAIK. We may not take (more) initcall
>> level tweak hacks, but that is a much more simple change for
>> downstream. Don't get me wrong, I'd really like to see a way to
>> control order independent of initcall level.
>>
>> Rob
>
> Yep, it is not directly ad hoc, just a fortunate side effect in
> this case. So just accidently ad hoc. :-)
>
> -Frank
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Tomeu Vizoso @ 2015-10-22 9:14 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Alan Stern, Mark Brown, Rob Herring, David Woodhouse,
Greg Kroah-Hartman, Russell King, Michael Turquette, Stephen Boyd,
Vinod Koul, Dan Williams, Linus Walleij, Alexandre Courbot,
Thierry Reding, David Airlie, Terje Bergström,
Stephen Warren, Wolfram Sang, Frank Rowand, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov
In-Reply-To: <1757126.NgBN1ISfc9@vostro.rjw.lan>
On 22 October 2015 at 02:54, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote:
>> On 20 October 2015 at 18:04, Alan Stern <stern@rowland.harvard.edu> wrote:
>> > On Tue, 20 Oct 2015, Mark Brown wrote:
>> >
>> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>> >>
>> >> > Furthermore, that applies only to devices that use synchronous suspend.
>> >> > Async suspend is becoming common, and there the only restrictions are
>> >> > parent-child relations plus whatever explicit requirements that drivers
>> >> > impose by calling device_pm_wait_for_dev().
>> >>
>> >> Hrm, this is the first I'd noticed that feature though I see the initial
>> >> commit dates from January.
>> >
>> > Async suspend and device_pm_wait_for_dev() were added in January 2010,
>> > not 2015!
>> >
>> >> It looks like most of the users are PCs at
>> >> the minute but we should be using it more widely for embedded things,
>> >> there's definitely some cases I'm aware of where it will allow us to
>> >> remove some open coding.
>> >>
>> >> It does seem like we want to be feeding dependency information we
>> >> discover for probing way into the suspend dependencies...
>> >
>> > Rafael has been thinking about a way to do this systematically.
>> > Nothing concrete has emerged yet.
>>
>> This iteration of the series would make this quite easy, as
>> dependencies are calculated before probes are attempted:
>>
>> https://lkml.org/lkml/2015/6/17/311
>
> Well, if you know how to represent "links" between devices, the mechanism
> introduced here doesn't really add much value, because in that case the
> core knows what the dependencies are in the first place and can only
> defer the probes that have to be deferred.
By "here" you mean what you are proposing for ordering device
suspends, or on-demand probing?
If you meant that probing on-demand is unneeded if we already have
dependency information, I agree with you and that's why I only pushed
forward on-demand, as the approach linked above introduced some
duplication when inferring the dependencies. Maybe that could be
avoided without too much refactoring.
In any case, Thierry mentioned the other day in #tegra that one could
also collect dependency information as a follow up to the on-demand
series by calling device_depend() or such instead of
of_device_probe().
Regards,
Tomeu
> Thanks,
> Rafael
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing)
From: Mark Brown @ 2015-10-22 13:20 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Geert Uytterhoeven, Tomeu Vizoso, Greg Kroah-Hartman, Rob Herring,
Michael Turquette, Stephen Boyd, Vinod Koul, Dan Williams,
Linus Walleij, Alexandre Courbot, Thierry Reding, David Airlie,
Terje Bergström, Stephen Warren, Wolfram Sang, Frank Rowand,
Grant Likely, Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse
In-Reply-To: <20151020154656.GY32532@n2100.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]
On Tue, Oct 20, 2015 at 04:46:56PM +0100, Russell King - ARM Linux wrote:
> Something like this. I haven't put a lot of effort into it to change all
> the places which return an -EPROBE_DEFER, and it also looks like we need
> some helpers to report when we have only an device_node (or should that
> be fwnode?) See the commented out of_warn_deferred() in
> drivers/gpio/gpiolib-of.c. Adding this stuff in the subsystems searching
> for resources should make debugging why things are getting deferred easier.
Yeah, plus I'd expect it to also result in better error reporting
overall if the subsystems are able to report when they fail to get
something rather than just returning an error to the driver.
> +/**
> + * dev_warn_deferred() - report why a probe has been deferred
> + */
> +void dev_warn_deferred(struct device *dev, const char *fmt, ...)
> +{
> + if (driver_deferred_probe_report) {
> + struct va_format vaf;
> + va_list ap;
> +
> + va_start(ap, fmt);
> + vaf.fmt = fmt;
> + vaf.va = ≈
> +
> + dev_warn(dev, "deferring probe: %pV", &vaf);
> + va_end(ap);
> + }
> +}
> +EXPORT_SYMBOL_GPL(dev_warn_deferred);
I'm not currently able to think of a nice way of writing this but I think
what I'd really like to see from a driver point of view is something
which decays into dev_err() if it's a non-deferral error. That way
drivers can have minimal log and return error handling code and we will
still get the output sensibly. The best I can think of is something
like
void dev_warn_deferred(struct device *dev, int err, const char *fmt, ...)
which requires the caller to pass in err twice to get it logged. That's
not a thing of beauty but it gets the job done... but perhaps your
original interface is better, it's a bit cleaner.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Greg Kroah-Hartman @ 2015-10-22 14:38 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: Frank Rowand, Rob Herring, Mark Brown, Russell King,
Michael Turquette, Stephen Boyd, Vinod Koul, Dan Williams,
Linus Walleij, Alexandre Courbot, Thierry Reding, David Airlie,
Terje Bergström, Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, Liam Girdwood,
Felipe Balbi
In-Reply-To: <CAAObsKAkyjdvNOS3+nuT0N9sudUFLsZXFtcm6Y038p+HSdsZsg@mail.gmail.com>
On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> On 21 October 2015 at 23:50, Frank Rowand <frowand.list@gmail.com> wrote:
> > On 10/21/2015 2:12 PM, Rob Herring wrote:
> >> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> >>> On 10/21/2015 9:27 AM, Mark Brown wrote:
> >>>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
> >>>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> >>>>
> >>>>>> To be clear, I was saying that this series should NOT affect total
> >>>>>> boot times much.
> >>>>
> >>>>> I'm confused. If I understood correctly, improving boot time was
> >>>>> the key justification for accepting this patch set. For example,
> >>>>> from "[PATCH v7 0/20] On-demand device probing":
> >>>>>
> >>>>> I have a problem with the panel on my Tegra Chromebook taking longer
> >>>>> than expected to be ready during boot (Stéphane Marchesin reported what
> >>>>> is basically the same issue in [0]), and have looked into ordered
> >>>>> probing as a better way of solving this than moving nodes around in the
> >>>>> DT or playing with initcall levels and linking order.
> >>>>>
> >>>>> ...
> >>>>>
> >>>>> With this series I get the kernel to output to the panel in 0.5s,
> >>>>> instead of 2.8s.
> >>>>
> >>>> Overall boot time and time to get some individual built in component up
> >>>> and running aren't the same thing - what this'll do is get things up
> >>>> more in the link order of the leaf consumers rather than deferring those
> >>>> leaf consumers when their dependencies aren't ready yet.
> >>>
> >>> Thanks! I read too much into what was being improved.
> >>>
> >>> So this patch series, which on other merits may be a good idea, is as
> >>> a by product solving a specific ordering issue, moving successful panel
> >>> initialization to an earlier point in the boot sequence, if I now
> >>> understand more correctly.
> >>>
> >>> In that context, this seems like yet another ad hoc way of causing the
> >>> probe order to change in a way to solves one specific issue? Could
> >>> it just as likely move the boot order of some other driver on some
> >>> other board later, to the detriment of somebody else?
> >>
> >> Time to display on is important for many products. Having the console
> >> up as early as possible is another case. CAN bus is another. This is a
> >> real problem that is not just bad drivers.
> >
> > Yes, I agree.
> >
> > What I am seeing is that there continues to be a need for the ability
> > to explicitly order at least some driver initialization (at some
> > granularity), despite the push back against explicit ordering that
> > has been present in the past.
>
> The important point that I have struggled to explain is that right now
> for downstreams to influence the order in which devices are probed,
> they have to carry a substantial amount of patches that cannot be ever
> upstreamed. This fiddling with initcall levels and link order means
> changing files that are very frequently changing, increasing the
> amount of work when rebasing and increasing the probability of
> regressions after a rebase.
>
> This just adds up to other shortcomings of mainline and ends up with
> the net result of vendors getting stuck with 3.4 kernels on SoCs that
> start production in 2015. Another consequence is that vendors don't
> have a chance to upstream their stuff even if they cared. The
> overarching goal of the project I'm in is to reduce those shortcomings
> that downstreams have to workaround, to facilitate their involvement
> upstream.
The init order of drivers has no influence at all on the ability for
companies to have their individual drivers merged upstream, please don't
be so dramatic about this.
Worst case, a vendor keeps a single patch to drivers/Makefile in their
tree that reorders things, yes it will get conflicts on every release,
but really, it's trivial to maintain if they wish to keep doing this
type of thing.
Again, it is _not_ the reason that we are living with 2million+ lines of
code in vendor kernels.
thanks,
greg k-h
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Greg Kroah-Hartman @ 2015-10-22 14:44 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: Frank Rowand, Rob Herring, Mark Brown, Russell King,
Michael Turquette, Stephen Boyd, Vinod Koul, Dan Williams,
Linus Walleij, Alexandre Courbot, Thierry Reding, David Airlie,
Terje Bergström, Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, Liam Girdwood,
Felipe Balbi
In-Reply-To: <CAAObsKAkyjdvNOS3+nuT0N9sudUFLsZXFtcm6Y038p+HSdsZsg@mail.gmail.com>
<oops, sent too early...>
On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> But that's moot currently because Greg believes that the time spent
> probing devices at boot time could be reduced enough so that the order
> in which devices are probed becomes irrelevant. IME that would have to
> be under 200ms so that the user doesn't notice and that's unicorn-far
> from any bootlog I have ever seen.
But as no one has actually produced a bootlog, how do you know that?
Where exactly is your time being spent? What driver is causing long
delays? Why is the long-delay-drivers not being done in their own
thread? And most importantly, why are you ignoring the work that people
did back in 2008 to solve the issue on other hardware platforms?
> Given that downstreams are already carrying as many hacks as they
> could think of to speed total boot up, I think this is effectively
> telling them to go away.
No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
solve-the-random-issue-i'm-having type patch by putting random calls in
semi-random subsystems all over the kernel.
And when I ask for real data, you respond with the fact that you aren't
trying to speed up boot time here at all, so what am I supposed to think
other than that you don't care enough to do the real work and are trying
to hack the driver core up instead.
> Sorry for the rant,
No apologies needed, it's cathartic at times :)
thanks,
greg k-h
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Russell King - ARM Linux @ 2015-10-22 15:02 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Tomeu Vizoso, Frank Rowand, Rob Herring, Mark Brown,
Michael Turquette, Stephen Boyd, Vinod Koul, Dan Williams,
Linus Walleij, Alexandre Courbot, Thierry Reding, David Airlie,
Terje Bergström, Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, Liam Girdwood,
Felipe Balbi
In-Reply-To: <20151022144405.GC21861-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Thu, Oct 22, 2015 at 07:44:05AM -0700, Greg Kroah-Hartman wrote:
> <oops, sent too early...>
>
> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> > Given that downstreams are already carrying as many hacks as they
> > could think of to speed total boot up, I think this is effectively
> > telling them to go away.
>
> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> solve-the-random-issue-i'm-having type patch by putting random calls in
> semi-random subsystems all over the kernel.
+100000000000, fully agree.
There's too much verbal diarrhoea going on in this thread and no facts.
I've been waiting for real data too, and there's not one shred of it, or
even a hint that it might appear. So, the conclusion I'm coming to is
that there isn't any data to back up the claims made in this thread.
If it was such a problem, then in the _eight_ days that this has been
discussed so far, _someone_ would have sent some data showing the
problem. I think the fact is, there is no data.
Someone prove me wrong. Someone post the verifiable data showing that
there is a problem to be solved here.
Someone show what the specific failure cases are that are hampering
vendors moving forwards. Someone show the long boot times by way of
kernel message log. Someone show some evidence of the problems that
have been alluded to.
If no one can show some evidence, there isn't a problem here. :)
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox