Re: [GIT PULL] On-demand device probing
From: Frank Rowand <hidden>
Date: 2015-10-21 18:18:17
Also in:
dri-devel, linux-clk, linux-fbdev, linux-gpio, linux-i2c, linux-pm, linux-pwm, linux-tegra, lkml
On 10/21/2015 9:27 AM, Mark Brown wrote:
On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:quoted
On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:quoted
quoted
To be clear, I was saying that this series should NOT affect total boot times much.quoted
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?
quoted
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.