* Re: [PATCH v2] pwm-backlight: fix the panel power sequence
From: Philipp Zabel @ 2015-10-16 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1444987060-48202-1-git-send-email-yh.huang@mediatek.com>
Am Freitag, den 16.10.2015, 17:17 +0800 schrieb YH Huang:
> In order to match the panel power sequence, disable the enable_gpio
> in the probe function. Also, reorder the code in the power_on and
> power_off function to match the timing.
Could you also have a look at the "pwm-backlight: Avoid backlight
flicker when probed from DT" patch?
I think in case of a panel left enabled by the bootloader, your patch
will disable the backlight for a short time.
best regards
Philipp
^ permalink raw reply
* Re: [PATCHv4 3/3] devicetree: Add led-backlight binding
From: Tomi Valkeinen @ 2015-10-16 11:42 UTC (permalink / raw)
To: Rob Herring
Cc: Jacek Anaszewski, Jingoo Han, Lee Jones, Linux LED Subsystem,
linux-fbdev@vger.kernel.org, Andrew Lunn,
devicetree@vger.kernel.org
In-Reply-To: <CAL_JsqJ0JUuwkVKtWbzqEWemx7wME61KYxgvv=vNUT8FiMtGYw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7177 bytes --]
Hi Rob,
On 15/10/15 21:55, Rob Herring wrote:
>> True, but those child nodes are very limited. As I see it, those child
>> nodes really describe the outputs of the LED chip, not what's on the
>> other end of the lines.
>
> The child nodes are supposed to be the other end. In the flash case,
> the properties are constraints on the flash LED (i.e. different flash
> LEDs will have different max currents).
Right, but what I meant is that the max current is applied to the LED
controller hardware, so in that sense it can be considered as a property
of the LED controller.
If there was, say, a flash that supports changing the color of the
light, that property would be applied to the flash HW so it'd be a
property of the "other end".
>> If on the other end of the lines is a more complex device, we need a
>> proper device driver for it, with a proper DT node with compatible
>> property etc.
>>
>> Now, one could argue that a "backlight" that gets the LED signal from a
>> LED chip is really just a simple LED. But there are complications:
>
> I would say backlights are a complex example of LEDs. Of course, there
> are backlights not based on LEDs, but we're not talking about those
> here.
I like the GPIO/PWM binding model, as it doesn't force any
node-hierarchy to the consumer of the GPIO/PWM. I don't see LED
controller output being any different than PWM, but the current LED
bindings still force the consumers of the LED signal to be a child of
the LED controller.
How about an LCD module, controlled via i2c, which takes a LED PWM
signal as an input, but needs i2c commands to enable the actual
backlight? So kind of i2c controlled smart LED. Or if the LCD module
takes two LED PWM signal inputs to achieve some fancy backlight effects.
Yes, it's theoretical HW, and I know some people don't like to discuss
such things... But the above example is easily accomplished with the
GPIO/PWM style bindings, but I don't have any idea how it could be done
with the current LED bindings.
>> - Our board needs a GPIO to enable the backlight. I can't say what
>> exactly the GPIO does as my HW skills don't go far enough, but all this
>> is after the LED chip. I also see the circuitry using powers, which in
>> our case happen to be always on so we don't need to enable them explicitly.
>
> The GPIO is probably controlling a transistor to connect the LED anode
> to ground and therefore turn it on. These have nothing to do with
> backlights really, but really are common to LEDs. Every LED needs a
> supply rail too. This may come for a regulator or directly from an LED
> driver IC.
There's something a bit more complex there. The gpio controls TI
TPS6108x (http://www.ti.com/lit/ds/symlink/tps61081.pdf "High-Voltage
DC-DC Boost Converter").
But possibly all that can still be considered as you described.
> If the flash LED binding doesn't have these, then it is only a matter of time.
>
>>
>> - We need a backlight device/driver (because of the Linux SW stack).
>
> From a binding perspective, not my problem. The problem with the
> driver needs driving the binding definition is the drivers can change
> over time. IIRC there has been some discussion of combining the 2
> subsystems in the kernel, so we don't want to create something defined
> by current kernel needs.
True. But on the other hand I would also not want to force new drivers
to use the current binding model, if it doesn't quite fit.
So if the PWM/GPIO model is fine, and LED controllers are really very
similar, shouldn't we extend the LED bindings towards PWM/GPIO model
rather than trying to fit everything into the current LED bindings?
Of course, even if everybody would agree with the above, this particular
backlight binding is rather simple, and I think we can fit it in the
current model. But that then raises the question, if led-backlight and
pwm-backlight are about the same, why are the binding model different.
>> So, maybe it would be possible to construct all that in a LED child
>> node, and the LED driver would create a child device for the nodes which
>> have 'compatible' property. But then, that would be very different from
>> pwm-backlight, and the parent-child relationships are usually used to
>> indicate a control relationship, right?
>
> This is along the lines I was thinking, but don't see how it is very
> different at the binding level. The parent-child relationship is
In my experience, the relationship between the nodes is usually the most
difficult part with bindings, both in the design side and the driver
implementation side.
So if pwm-backlight links to the pwm source using a phandle, and
led-backlight links by child-parent relationship, I see them as quite
different, even if the rest of the properties are the same.
> typically control path or just what is downstream from the parent
> device. Some bindings like GPIO and PWM don't follow this, but that is
> often because they are just additional sideband interfaces on top of
> the main control interface. I think simply making the "backlight" node
> from the pwm-backlight binding a child works. We probably need a
> different compatible string though (led-backlight is as good as
So hmm... You mean using the pwm-backlight node, without the "pwms"
property, as the source is implicit? So:
/* tlc59108 is an i2c device */
tlc59116@40 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "ti,tlc59108";
reg = <0x40>;
wan@0 {
label = "wrt1900ac:amber:wan";
reg = <0x0>;
};
bl@2 {
label = "backlight";
reg = <0x2>;
compatible = "led-backlight";
brightness-levels = <0 243 245 247 248 249 251 252 255>;
default-brightness-level = <8>;
enable-gpios = <&pcf_lcd 13 GPIO_ACTIVE_LOW>;
};
};
At the moment each LED controller driver does its own DT parsing, and
there's no common code for anything related to DT in the LED framework
and the LED framework is not even aware of DT nodes or such (which is
why I needed a bit hackish approach in my patches to find the nodes).
I have a gut feeling that going into this direction will require quite a
bit of restructuring in the LED drivers, so I think I need to leave this
task for others due to lack of time.
> anything). I also think we should require child nodes to have a
> compatible string which we didn't do for flash devices. It's probably
> not too late to fix that.
That is probably a good idea.
> I think there are 2 cases of PWM connection to LEDs to consider. The
> PWM is an input to a LED driver chip or the PWM directly controls the
> LED (attached to the anode). The current pwm-backlight binding covers
> the latter. In the former case, pwms should probably be in the parent
> (LED driver IC node). Of course, if the driver IC has no s/w
> controllable interface beyond PWM, then it probably doesn't need to be
> modeled at all in DT.
I guess one option would also be to create an MFD of the LED controller,
so that it would offer some of the outputs as plain PWMs. Then
pwm-backlight could be used directly.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Olof Johansson @ 2015-10-16 21:23 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: Rob Herring, Russell King, Greg Kroah-Hartman, 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, Liam Girdwood,
Mark Brown
In-Reply-To: <1444909328-24761-1-git-send-email-tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Hi,
I've bisected boot failures in next-20151016 down to patches in this branch:
On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso
<tomeu.vizoso@collabora.com> wrote:
> Tomeu Vizoso (20):
> driver core: handle -EPROBE_DEFER from bus_type.match()
The machine it happened on was OMAP5UEVM:
http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html
But I've also seen it on tegra2, that one bisected down to:
> regulator: core: Probe regulators on demand
http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html
-Olof
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Greg Kroah-Hartman @ 2015-10-17 6:57 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: 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, Frank Rowand, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, Liam Girdwood,
Mark Brown, Felipe Balbi
In-Reply-To: <561E1378.6000906@collabora.com>
On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
> Hi Rob,
>
> here is the pull request you asked for, with no changes from the version
> that I posted last to the list.
>
> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
>
> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
>
> are available in the git repository at:
>
> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> on-demand-probes-for-next
That's not a signed tag :(
Anyway, I REALLY don't like this series (sorry for the delay in
reviewing them, normally I trust Rob's judgement...)
I can't see adding calls like this all over the tree just to solve a
bus-specific problem, you are adding of_* calls where they aren't
needed, or wanted, at all.
What is the root-problem of your delay in device probing? I read your
last patch series and I can't seem to figure out what the issue is that
this is solving in any "better" way from the existing deferred probing.
thanks,
greg k-h
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Rob Herring @ 2015-10-17 15:04 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: 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, David Woodhouse, Liam Girdwood,
Mark Brown, Felipe Balbi
In-Reply-To: <20151017065750.GA18607@kroah.com>
On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
>> Hi Rob,
>>
>> here is the pull request you asked for, with no changes from the version
>> that I posted last to the list.
>>
>> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
>>
>> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
>>
>> are available in the git repository at:
>>
>> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
>> on-demand-probes-for-next
>
> That's not a signed tag :(
>
> Anyway, I REALLY don't like this series (sorry for the delay in
> reviewing them, normally I trust Rob's judgement...)
We've seen a lot of attempts here. This is really the best solution so
far in that it is simple, uses existing data from DT, and was low risk
for breaking platforms (at least I thought it would be). Anyway,
getting more exposure is why I've put it into -next.
> I can't see adding calls like this all over the tree just to solve a
> bus-specific problem, you are adding of_* calls where they aren't
> needed, or wanted, at all.
I think Linus W, Mark B, and I all said a similar thing initially in
that dependencies should be handled in the driver core. We went down
the path of making this not firmware (aka bus) specific and an earlier
version had just that (with fwnode_* calls). That turned out to be
pointless as the calling locations were almost always in DT specific
code anyway. If you notice, the calls are next to other DT specific
calls generally (usually a "get"). So yes, I'd prefer not to have to
touch every subsystem, but we had to do that anyway to add DT support.
We've generally split the DT code into the core (in drivers/of) and
the binding specific (in subsystems). Extracting dependency
information the DT is going to require binding specific knowledge, so
subsystem changes are probably unavoidable.
The alternative is we put binding specific knowledge into the core DT
code to parse dependencies.
> What is the root-problem of your delay in device probing? I read your
> last patch series and I can't seem to figure out what the issue is that
> this is solving in any "better" way from the existing deferred probing.
It saves 2 seconds in the boot time as re-probing takes time. That
alone seems compelling to me.
Another downside to deferred probing is you have to touch every driver
and subsystem to support it. This contains the problem to the
subsystems.
Rob
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Rob Herring @ 2015-10-17 15:19 UTC (permalink / raw)
To: Olof Johansson
Cc: Tomeu Vizoso, Russell King, Greg Kroah-Hartman, 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, Liam Girdwood
In-Reply-To: <CAOesGMj44N3Xfv_D_iLEzXBrkN6LXBa-uh6m3fi_F2xDenDhMg@mail.gmail.com>
On Fri, Oct 16, 2015 at 4:23 PM, Olof Johansson <olof@lixom.net> wrote:
> Hi,
>
> I've bisected boot failures in next-20151016 down to patches in this branch:
>
> On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso
> <tomeu.vizoso@collabora.com> wrote:
>> Tomeu Vizoso (20):
>> driver core: handle -EPROBE_DEFER from bus_type.match()
>
> The machine it happened on was OMAP5UEVM:
>
> http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html
So this one is because the MMC node numbering changed. I don't know
how to fix that other than with aliases, but that doesn't solve
backwards compatibility.
> But I've also seen it on tegra2, that one bisected down to:
>
>> regulator: core: Probe regulators on demand
>
> http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html
This one you need a rootwait I think. The MMC scanning is not
guaranteed to be done before the rootfs mounting AFAIK. There may be
other problems, but we can't see them since it panics.
Rob
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Greg Kroah-Hartman @ 2015-10-17 15:47 UTC (permalink / raw)
To: Rob Herring
Cc: 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, David Woodhouse, Liam Girdwood,
Mark Brown, Felipe Balbi
In-Reply-To: <CAL_Jsq+Due3CgV0Z_m4vYQsa+X30DSxgmqz_r=26OrBV7v+H2g@mail.gmail.com>
On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:
> On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
> >> Hi Rob,
> >>
> >> here is the pull request you asked for, with no changes from the version
> >> that I posted last to the list.
> >>
> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> >>
> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> >>
> >> are available in the git repository at:
> >>
> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> >> on-demand-probes-for-next
> >
> > That's not a signed tag :(
> >
> > Anyway, I REALLY don't like this series (sorry for the delay in
> > reviewing them, normally I trust Rob's judgement...)
>
> We've seen a lot of attempts here. This is really the best solution so
> far in that it is simple, uses existing data from DT, and was low risk
> for breaking platforms (at least I thought it would be). Anyway,
> getting more exposure is why I've put it into -next.
Exposure is good, now we know it breaks some builds, which was useful :)
> > I can't see adding calls like this all over the tree just to solve a
> > bus-specific problem, you are adding of_* calls where they aren't
> > needed, or wanted, at all.
>
> I think Linus W, Mark B, and I all said a similar thing initially in
> that dependencies should be handled in the driver core. We went down
> the path of making this not firmware (aka bus) specific and an earlier
> version had just that (with fwnode_* calls). That turned out to be
> pointless as the calling locations were almost always in DT specific
> code anyway. If you notice, the calls are next to other DT specific
> calls generally (usually a "get"). So yes, I'd prefer not to have to
> touch every subsystem, but we had to do that anyway to add DT support.
If they are "next" to a call like that, why not put it in that call? I
really object to having to "sprinkle" this all over the kernel, for no
obvious reason why that is happening at all (look at the USB patch for
one such example.)
> We've generally split the DT code into the core (in drivers/of) and
> the binding specific (in subsystems). Extracting dependency
> information the DT is going to require binding specific knowledge, so
> subsystem changes are probably unavoidable.
>
> The alternative is we put binding specific knowledge into the core DT
> code to parse dependencies.
>
> > What is the root-problem of your delay in device probing? I read your
> > last patch series and I can't seem to figure out what the issue is that
> > this is solving in any "better" way from the existing deferred probing.
>
> It saves 2 seconds in the boot time as re-probing takes time. That
> alone seems compelling to me.
2 seconds is _forever_, and really seems like some other driver is
sleeping and causing this problem. What does the bootlog time-chart say
is really causing this long delay? There's no way we are stuck in some
sort of logic loop for that long (i.e. having to walk the list of
devices somehow.) This sounds like a driver-specific problem that is
being worked around by having to touch all subsystems, which isn't nice.
Hint, we didn't have to do this type of thing to solve boot delays on
x86 when we had hardware that was slow to initialize, why should DT be
special? :)
> Another downside to deferred probing is you have to touch every driver
> and subsystem to support it. This contains the problem to the
> subsystems.
But we have deferred probing already, only those drivers that need/want
it have to do anything, why create yet-another model here?
thanks,
greg k-h
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Rob Herring @ 2015-10-17 16:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: 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, David Woodhouse, Liam Girdwood,
Mark Brown, Felipe Balbi
In-Reply-To: <20151017154709.GE4059@kroah.com>
On Sat, Oct 17, 2015 at 10:47 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:
>> On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
>> >> Hi Rob,
>> >>
>> >> here is the pull request you asked for, with no changes from the version
>> >> that I posted last to the list.
>> >>
>> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
>> >>
>> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
>> >>
>> >> are available in the git repository at:
>> >>
>> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
>> >> on-demand-probes-for-next
>> >
>> > That's not a signed tag :(
>> >
>> > Anyway, I REALLY don't like this series (sorry for the delay in
>> > reviewing them, normally I trust Rob's judgement...)
>>
>> We've seen a lot of attempts here. This is really the best solution so
>> far in that it is simple, uses existing data from DT, and was low risk
>> for breaking platforms (at least I thought it would be). Anyway,
>> getting more exposure is why I've put it into -next.
>
> Exposure is good, now we know it breaks some builds, which was useful :)
Now that I've looked at them, they are somewhat questionable failures.
They do show the fragile nature of probe ordering and the implicit
dependencies we have.
>> > I can't see adding calls like this all over the tree just to solve a
>> > bus-specific problem, you are adding of_* calls where they aren't
>> > needed, or wanted, at all.
>>
>> I think Linus W, Mark B, and I all said a similar thing initially in
>> that dependencies should be handled in the driver core. We went down
>> the path of making this not firmware (aka bus) specific and an earlier
>> version had just that (with fwnode_* calls). That turned out to be
>> pointless as the calling locations were almost always in DT specific
>> code anyway. If you notice, the calls are next to other DT specific
>> calls generally (usually a "get"). So yes, I'd prefer not to have to
>> touch every subsystem, but we had to do that anyway to add DT support.
>
> If they are "next" to a call like that, why not put it in that call? I
> really object to having to "sprinkle" this all over the kernel, for no
> obvious reason why that is happening at all (look at the USB patch for
> one such example.)
Looking at it again, they are in DT specific code already. The USB one
is in devm_usb_get_phy_by_node() which is a DT specific call.
>> We've generally split the DT code into the core (in drivers/of) and
>> the binding specific (in subsystems). Extracting dependency
>> information the DT is going to require binding specific knowledge, so
>> subsystem changes are probably unavoidable.
>>
>> The alternative is we put binding specific knowledge into the core DT
>> code to parse dependencies.
>>
>> > What is the root-problem of your delay in device probing? I read your
>> > last patch series and I can't seem to figure out what the issue is that
>> > this is solving in any "better" way from the existing deferred probing.
>>
>> It saves 2 seconds in the boot time as re-probing takes time. That
>> alone seems compelling to me.
>
> 2 seconds is _forever_, and really seems like some other driver is
> sleeping and causing this problem. What does the bootlog time-chart say
> is really causing this long delay? There's no way we are stuck in some
> sort of logic loop for that long (i.e. having to walk the list of
> devices somehow.) This sounds like a driver-specific problem that is
> being worked around by having to touch all subsystems, which isn't nice.
I don't think it is one driver as the improvement is seen on multiple
platforms. I'll let Tomeu comment further on where the time was spent.
> Hint, we didn't have to do this type of thing to solve boot delays on
> x86 when we had hardware that was slow to initialize, why should DT be
> special? :)
x86 did not need deferred probe either (though we probably can find
some initcall ordering hacks). This is an embedded problem, not a DT
problem.
I'm guessing the time is a matter of probing and undoing the probes
rather than slow h/w. We could maybe improve things by making sure
drivers move what they defer on to the beginning of probe, but that
seems like a horrible, fragile hack.
>> Another downside to deferred probing is you have to touch every driver
>> and subsystem to support it. This contains the problem to the
>> subsystems.
>
> But we have deferred probing already, only those drivers that need/want
> it have to do anything, why create yet-another model here?
Yes, the only ones needing it are drivers dependent on clocks, gpio,
regulators, pwm, pin-ctrl, dma, etc. That's not a small number. This
is a side benefit and wouldn't take this series for that reason alone.
I've used the deferred probing is good enough argument myself on
previous attempts. The boot time improvements convinced me it is not
good enough except for simple cases.
Rob
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Greg Kroah-Hartman @ 2015-10-17 16:56 UTC (permalink / raw)
To: Rob Herring
Cc: 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, David Woodhouse, Liam Girdwood,
Mark Brown, Felipe Balbi
In-Reply-To: <CAL_JsqJvtKt6FpZgnYcsEm_opr9gK_a013BVpZGvnB=51oSUXg@mail.gmail.com>
On Sat, Oct 17, 2015 at 11:28:29AM -0500, Rob Herring wrote:
> On Sat, Oct 17, 2015 at 10:47 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:
> >> On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
> >> >> Hi Rob,
> >> >>
> >> >> here is the pull request you asked for, with no changes from the version
> >> >> that I posted last to the list.
> >> >>
> >> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> >> >>
> >> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> >> >>
> >> >> are available in the git repository at:
> >> >>
> >> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> >> >> on-demand-probes-for-next
> >> >
> >> > That's not a signed tag :(
> >> >
> >> > Anyway, I REALLY don't like this series (sorry for the delay in
> >> > reviewing them, normally I trust Rob's judgement...)
> >>
> >> We've seen a lot of attempts here. This is really the best solution so
> >> far in that it is simple, uses existing data from DT, and was low risk
> >> for breaking platforms (at least I thought it would be). Anyway,
> >> getting more exposure is why I've put it into -next.
> >
> > Exposure is good, now we know it breaks some builds, which was useful :)
>
> Now that I've looked at them, they are somewhat questionable failures.
> They do show the fragile nature of probe ordering and the implicit
> dependencies we have.
>
> >> > I can't see adding calls like this all over the tree just to solve a
> >> > bus-specific problem, you are adding of_* calls where they aren't
> >> > needed, or wanted, at all.
> >>
> >> I think Linus W, Mark B, and I all said a similar thing initially in
> >> that dependencies should be handled in the driver core. We went down
> >> the path of making this not firmware (aka bus) specific and an earlier
> >> version had just that (with fwnode_* calls). That turned out to be
> >> pointless as the calling locations were almost always in DT specific
> >> code anyway. If you notice, the calls are next to other DT specific
> >> calls generally (usually a "get"). So yes, I'd prefer not to have to
> >> touch every subsystem, but we had to do that anyway to add DT support.
> >
> > If they are "next" to a call like that, why not put it in that call? I
> > really object to having to "sprinkle" this all over the kernel, for no
> > obvious reason why that is happening at all (look at the USB patch for
> > one such example.)
>
> Looking at it again, they are in DT specific code already. The USB one
> is in devm_usb_get_phy_by_node() which is a DT specific call.
But that's not very obvious, right? Especially given that you now have
to add a new .h file, which implies that suddenly this file is now
touching a new subsystem.
> >> We've generally split the DT code into the core (in drivers/of) and
> >> the binding specific (in subsystems). Extracting dependency
> >> information the DT is going to require binding specific knowledge, so
> >> subsystem changes are probably unavoidable.
> >>
> >> The alternative is we put binding specific knowledge into the core DT
> >> code to parse dependencies.
> >>
> >> > What is the root-problem of your delay in device probing? I read your
> >> > last patch series and I can't seem to figure out what the issue is that
> >> > this is solving in any "better" way from the existing deferred probing.
> >>
> >> It saves 2 seconds in the boot time as re-probing takes time. That
> >> alone seems compelling to me.
> >
> > 2 seconds is _forever_, and really seems like some other driver is
> > sleeping and causing this problem. What does the bootlog time-chart say
> > is really causing this long delay? There's no way we are stuck in some
> > sort of logic loop for that long (i.e. having to walk the list of
> > devices somehow.) This sounds like a driver-specific problem that is
> > being worked around by having to touch all subsystems, which isn't nice.
>
> I don't think it is one driver as the improvement is seen on multiple
> platforms. I'll let Tomeu comment further on where the time was spent.
That would be good to know, as 2 seconds is forever (my whole machine
boots to a gnome login faster than that.)
> > Hint, we didn't have to do this type of thing to solve boot delays on
> > x86 when we had hardware that was slow to initialize, why should DT be
> > special? :)
>
> x86 did not need deferred probe either (though we probably can find
> some initcall ordering hacks). This is an embedded problem, not a DT
> problem.
x86 is embedded :)
> I'm guessing the time is a matter of probing and undoing the probes
> rather than slow h/w. We could maybe improve things by making sure
> drivers move what they defer on to the beginning of probe, but that
> seems like a horrible, fragile hack.
How can calling probe and failing cause 2 seconds? How many different
probe calls are failing here? Again, a boot log graph would be great to
see as it will show the root cause, not just guessing at this.
> >> Another downside to deferred probing is you have to touch every driver
> >> and subsystem to support it. This contains the problem to the
> >> subsystems.
> >
> > But we have deferred probing already, only those drivers that need/want
> > it have to do anything, why create yet-another model here?
>
> Yes, the only ones needing it are drivers dependent on clocks, gpio,
> regulators, pwm, pin-ctrl, dma, etc. That's not a small number. This
> is a side benefit and wouldn't take this series for that reason alone.
>
> I've used the deferred probing is good enough argument myself on
> previous attempts. The boot time improvements convinced me it is not
> good enough except for simple cases.
Then let's fix deferred probing to do it "correctly", let's not add
yet-another-way-to-probe instead please, as we will be forever
sprinkling these calls around subsystems in a cargo-cult-like manner for
forever.
thanks,
greg k-h
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Rob Clark @ 2015-10-17 17:54 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rob Herring, 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, David Woodhouse, Liam Girdwood,
Mark Brown
In-Reply-To: <20151017165617.GC25156@kroah.com>
On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>> I'm guessing the time is a matter of probing and undoing the probes
>> rather than slow h/w. We could maybe improve things by making sure
>> drivers move what they defer on to the beginning of probe, but that
>> seems like a horrible, fragile hack.
>
> How can calling probe and failing cause 2 seconds? How many different
> probe calls are failing here? Again, a boot log graph would be great to
> see as it will show the root cause, not just guessing at this.
just fwiw, but when you have a driver that depends on several other
drivers (which in turn depend on other drivers and so on), the amount
of probe-defer we end up seeing is pretty comical. Yeah, there
probably is some room to optimize by juggling around order drivers do
things in probe. But that doesn't solve the fundamental problem with
the current state, about probe order having no clue about
dependencies..
BR,
-R
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Greg Kroah-Hartman @ 2015-10-17 18:27 UTC (permalink / raw)
To: Rob Clark
Cc: Rob Herring, 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, David Woodhouse, Liam Girdwood,
Mark Brown
In-Reply-To: <CAF6AEGvbYYeZx=YVCv9r5K0xjtLf3gN69gX5DyQ3j0S1qT0Yog@mail.gmail.com>
On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >> I'm guessing the time is a matter of probing and undoing the probes
> >> rather than slow h/w. We could maybe improve things by making sure
> >> drivers move what they defer on to the beginning of probe, but that
> >> seems like a horrible, fragile hack.
> >
> > How can calling probe and failing cause 2 seconds? How many different
> > probe calls are failing here? Again, a boot log graph would be great to
> > see as it will show the root cause, not just guessing at this.
>
>
> just fwiw, but when you have a driver that depends on several other
> drivers (which in turn depend on other drivers and so on), the amount
> of probe-defer we end up seeing is pretty comical. Yeah, there
> probably is some room to optimize by juggling around order drivers do
> things in probe. But that doesn't solve the fundamental problem with
> the current state, about probe order having no clue about
> dependencies..
I can imagine it is a lot of iterations, but how long does it really
take? How many different devices are involved that it takes multiple
loops in order to finally work out the correct order? Where is the time
delays here, just calling probe() and having it instantly return
shouldn't take all that long.
thanks,
greg k-h
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Rob Clark @ 2015-10-17 18:45 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rob Herring, 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, David Woodhouse, Liam Girdwood,
Mark Brown
In-Reply-To: <20151017182755.GA28072@kroah.com>
On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> >> I'm guessing the time is a matter of probing and undoing the probes
>> >> rather than slow h/w. We could maybe improve things by making sure
>> >> drivers move what they defer on to the beginning of probe, but that
>> >> seems like a horrible, fragile hack.
>> >
>> > How can calling probe and failing cause 2 seconds? How many different
>> > probe calls are failing here? Again, a boot log graph would be great to
>> > see as it will show the root cause, not just guessing at this.
>>
>>
>> just fwiw, but when you have a driver that depends on several other
>> drivers (which in turn depend on other drivers and so on), the amount
>> of probe-defer we end up seeing is pretty comical. Yeah, there
>> probably is some room to optimize by juggling around order drivers do
>> things in probe. But that doesn't solve the fundamental problem with
>> the current state, about probe order having no clue about
>> dependencies..
>
> I can imagine it is a lot of iterations, but how long does it really
> take? How many different devices are involved that it takes multiple
> loops in order to finally work out the correct order? Where is the time
> delays here, just calling probe() and having it instantly return
> shouldn't take all that long.
offhand, I think the dependencies go at *least* three levels deep..
I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
get all the way through requesting it's various different
regulators/clks/gpios. I hadn't really paid attention to how many
tries the drivers I depend on go through. (Of those, I take clks from
two different clk drivers (which have dependency on a 3rd clk driver),
and regulators and gpio's come from at least two places, which in turn
have dependencies on clks, etc.) I don't have really good hard
numbers handy (since my observations of this are w/ console over uart
which effects timings, and so I see it taking much longer than 2sec)..
but the 2sec figure that Tomeu mentioned seemed pretty plausible to
me.
I can try to get better #'s... I should have my kernel hat on at least
some of the time next week.. but the 2sec figure didn't seem
unrealistic to me.
Just as an aside, the amount of probe-defer adds quite a lot of noise
when you are trying to debug why some driver doesn't probe
successfully. Which itself would be a nice reason to do something
more clever..
BR,
-R
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Greg Kroah-Hartman @ 2015-10-17 18:59 UTC (permalink / raw)
To: Rob Clark
Cc: Rob Herring, 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, David Woodhouse, Liam Girdwood,
Mark Brown
In-Reply-To: <CAF6AEGuvr6XMMufY0iDCSkp2BNcWa2=xUxjN66+FtQ6ygS-nyQ@mail.gmail.com>
On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote:
> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> >> I'm guessing the time is a matter of probing and undoing the probes
> >> >> rather than slow h/w. We could maybe improve things by making sure
> >> >> drivers move what they defer on to the beginning of probe, but that
> >> >> seems like a horrible, fragile hack.
> >> >
> >> > How can calling probe and failing cause 2 seconds? How many different
> >> > probe calls are failing here? Again, a boot log graph would be great to
> >> > see as it will show the root cause, not just guessing at this.
> >>
> >>
> >> just fwiw, but when you have a driver that depends on several other
> >> drivers (which in turn depend on other drivers and so on), the amount
> >> of probe-defer we end up seeing is pretty comical. Yeah, there
> >> probably is some room to optimize by juggling around order drivers do
> >> things in probe. But that doesn't solve the fundamental problem with
> >> the current state, about probe order having no clue about
> >> dependencies..
> >
> > I can imagine it is a lot of iterations, but how long does it really
> > take? How many different devices are involved that it takes multiple
> > loops in order to finally work out the correct order? Where is the time
> > delays here, just calling probe() and having it instantly return
> > shouldn't take all that long.
>
> offhand, I think the dependencies go at *least* three levels deep..
> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
> get all the way through requesting it's various different
> regulators/clks/gpios.
And how long does that really take? Numbers please :)
> I hadn't really paid attention to how many
> tries the drivers I depend on go through. (Of those, I take clks from
> two different clk drivers (which have dependency on a 3rd clk driver),
> and regulators and gpio's come from at least two places, which in turn
> have dependencies on clks, etc.) I don't have really good hard
> numbers handy (since my observations of this are w/ console over uart
> which effects timings, and so I see it taking much longer than 2sec)..
> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
> me.
>
> I can try to get better #'s... I should have my kernel hat on at least
> some of the time next week.. but the 2sec figure didn't seem
> unrealistic to me.
Based on the time it takes a modern laptop to boot, 2 seconds is
forever, there has to be something else going on here other than just
calling probe() a bunch of times. Please use the tools we have to
determine this before trying to change the driver core.
> Just as an aside, the amount of probe-defer adds quite a lot of noise
> when you are trying to debug why some driver doesn't probe
> successfully. Which itself would be a nice reason to do something
> more clever..
People seem to not like the noise, so let's turn off those messages,
that should speed things up :)
thanks,
greg k-h
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Noralf Trønnes @ 2015-10-17 19:04 UTC (permalink / raw)
To: Rob Clark, Greg Kroah-Hartman
Cc: Rob Herring, 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, David Woodhouse, Liam Girdwood,
Mark Brown
In-Reply-To: <CAF6AEGuvr6XMMufY0iDCSkp2BNcWa2=xUxjN66+FtQ6ygS-nyQ@mail.gmail.com>
Den 17.10.2015 20:45, skrev Rob Clark:
> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>>> <gregkh@linuxfoundation.org> wrote:
>>>>> I'm guessing the time is a matter of probing and undoing the probes
>>>>> rather than slow h/w. We could maybe improve things by making sure
>>>>> drivers move what they defer on to the beginning of probe, but that
>>>>> seems like a horrible, fragile hack.
>>>> How can calling probe and failing cause 2 seconds? How many different
>>>> probe calls are failing here? Again, a boot log graph would be great to
>>>> see as it will show the root cause, not just guessing at this.
>>>
>>> just fwiw, but when you have a driver that depends on several other
>>> drivers (which in turn depend on other drivers and so on), the amount
>>> of probe-defer we end up seeing is pretty comical. Yeah, there
>>> probably is some room to optimize by juggling around order drivers do
>>> things in probe. But that doesn't solve the fundamental problem with
>>> the current state, about probe order having no clue about
>>> dependencies..
>> I can imagine it is a lot of iterations, but how long does it really
>> take? How many different devices are involved that it takes multiple
>> loops in order to finally work out the correct order? Where is the time
>> delays here, just calling probe() and having it instantly return
>> shouldn't take all that long.
> offhand, I think the dependencies go at *least* three levels deep..
> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
> get all the way through requesting it's various different
> regulators/clks/gpios. I hadn't really paid attention to how many
> tries the drivers I depend on go through. (Of those, I take clks from
> two different clk drivers (which have dependency on a 3rd clk driver),
> and regulators and gpio's come from at least two places, which in turn
> have dependencies on clks, etc.) I don't have really good hard
> numbers handy (since my observations of this are w/ console over uart
> which effects timings, and so I see it taking much longer than 2sec)..
> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
> me.
>
> I can try to get better #'s... I should have my kernel hat on at least
> some of the time next week.. but the 2sec figure didn't seem
> unrealistic to me.
Are you saying that the total boot time is increased by 2 sec due to
deferred probing, or that display initialization is happening 2 sec
after it's first try?
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Rob Clark @ 2015-10-17 19:39 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rob Herring, 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, David Woodhouse, Liam Girdwood,
Mark Brown
In-Reply-To: <20151017185915.GA28826@kroah.com>
On Sat, Oct 17, 2015 at 2:59 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote:
>> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>> >> <gregkh@linuxfoundation.org> wrote:
>> >> >> I'm guessing the time is a matter of probing and undoing the probes
>> >> >> rather than slow h/w. We could maybe improve things by making sure
>> >> >> drivers move what they defer on to the beginning of probe, but that
>> >> >> seems like a horrible, fragile hack.
>> >> >
>> >> > How can calling probe and failing cause 2 seconds? How many different
>> >> > probe calls are failing here? Again, a boot log graph would be great to
>> >> > see as it will show the root cause, not just guessing at this.
>> >>
>> >>
>> >> just fwiw, but when you have a driver that depends on several other
>> >> drivers (which in turn depend on other drivers and so on), the amount
>> >> of probe-defer we end up seeing is pretty comical. Yeah, there
>> >> probably is some room to optimize by juggling around order drivers do
>> >> things in probe. But that doesn't solve the fundamental problem with
>> >> the current state, about probe order having no clue about
>> >> dependencies..
>> >
>> > I can imagine it is a lot of iterations, but how long does it really
>> > take? How many different devices are involved that it takes multiple
>> > loops in order to finally work out the correct order? Where is the time
>> > delays here, just calling probe() and having it instantly return
>> > shouldn't take all that long.
>>
>> offhand, I think the dependencies go at *least* three levels deep..
>> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
>> get all the way through requesting it's various different
>> regulators/clks/gpios.
>
> And how long does that really take? Numbers please :)
>
>> I hadn't really paid attention to how many
>> tries the drivers I depend on go through. (Of those, I take clks from
>> two different clk drivers (which have dependency on a 3rd clk driver),
>> and regulators and gpio's come from at least two places, which in turn
>> have dependencies on clks, etc.) I don't have really good hard
>> numbers handy (since my observations of this are w/ console over uart
>> which effects timings, and so I see it taking much longer than 2sec)..
>> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
>> me.
>>
>> I can try to get better #'s... I should have my kernel hat on at least
>> some of the time next week.. but the 2sec figure didn't seem
>> unrealistic to me.
>
> Based on the time it takes a modern laptop to boot, 2 seconds is
> forever, there has to be something else going on here other than just
> calling probe() a bunch of times. Please use the tools we have to
> determine this before trying to change the driver core.
yes, I am aware of the tools.. although so far I spend most of my time
just trying to get things working in the first place ;-)
All I was trying to point out was that Tomeu's figures didn't really
seem unrealistic. I mean, given that the average SoC driver probably
depends on at least one clock and at least one regulator, having to
probe each driver at least twice seems plausible. And that having a
noticeable effect on boot time doesn't seem surprising. I'm not sure
that saying 'modern laptop can boot in 2sec' adds much to the
discussion since I don't think you have quite so much interdependency
between devices vs random probe order. I have seen arm devices boot
to UI in similar times, but that was pre-devicetree days.
I expect Tomeu has some better number.. if not I can collect some.
>> Just as an aside, the amount of probe-defer adds quite a lot of noise
>> when you are trying to debug why some driver doesn't probe
>> successfully. Which itself would be a nice reason to do something
>> more clever..
>
> People seem to not like the noise, so let's turn off those messages,
> that should speed things up :)
heh, except for when you are trying to debug what is missing
preventing the driver you depend on from probing ;-)
BR,
-R
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Rob Clark @ 2015-10-17 19:48 UTC (permalink / raw)
To: Noralf Trønnes
Cc: Greg Kroah-Hartman, Rob Herring, 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, David Woodhouse
In-Reply-To: <56229BCC.9050603@tronnes.org>
On Sat, Oct 17, 2015 at 3:04 PM, Noralf Trønnes <noralf@tronnes.org> wrote:
>
> Den 17.10.2015 20:45, skrev Rob Clark:
>>
>> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>>>
>>> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>>>>
>>>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>>>> <gregkh@linuxfoundation.org> wrote:
>>>>>>
>>>>>> I'm guessing the time is a matter of probing and undoing the probes
>>>>>> rather than slow h/w. We could maybe improve things by making sure
>>>>>> drivers move what they defer on to the beginning of probe, but that
>>>>>> seems like a horrible, fragile hack.
>>>>>
>>>>> How can calling probe and failing cause 2 seconds? How many different
>>>>> probe calls are failing here? Again, a boot log graph would be great
>>>>> to
>>>>> see as it will show the root cause, not just guessing at this.
>>>>
>>>>
>>>> just fwiw, but when you have a driver that depends on several other
>>>> drivers (which in turn depend on other drivers and so on), the amount
>>>> of probe-defer we end up seeing is pretty comical. Yeah, there
>>>> probably is some room to optimize by juggling around order drivers do
>>>> things in probe. But that doesn't solve the fundamental problem with
>>>> the current state, about probe order having no clue about
>>>> dependencies..
>>>
>>> I can imagine it is a lot of iterations, but how long does it really
>>> take? How many different devices are involved that it takes multiple
>>> loops in order to finally work out the correct order? Where is the time
>>> delays here, just calling probe() and having it instantly return
>>> shouldn't take all that long.
>>
>> offhand, I think the dependencies go at *least* three levels deep..
>> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
>> get all the way through requesting it's various different
>> regulators/clks/gpios. I hadn't really paid attention to how many
>> tries the drivers I depend on go through. (Of those, I take clks from
>> two different clk drivers (which have dependency on a 3rd clk driver),
>> and regulators and gpio's come from at least two places, which in turn
>> have dependencies on clks, etc.) I don't have really good hard
>> numbers handy (since my observations of this are w/ console over uart
>> which effects timings, and so I see it taking much longer than 2sec)..
>> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
>> me.
>>
>> I can try to get better #'s... I should have my kernel hat on at least
>> some of the time next week.. but the 2sec figure didn't seem
>> unrealistic to me.
>
>
> Are you saying that the total boot time is increased by 2 sec due to
> deferred probing, or that display initialization is happening 2 sec
> after it's first try?
>
The 2sec figure was from Tomeu, but I guess display should be probed
in first pass through list of devices (and ofc deferring the first
time), I'll say "probably both"..
BR,
-R
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Greg Kroah-Hartman @ 2015-10-17 20:22 UTC (permalink / raw)
To: Rob Clark
Cc: Rob Herring, 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, David Woodhouse, Liam Girdwood,
Mark Brown
In-Reply-To: <CAF6AEGtqiMv6WSk_NVZqu8tMmVvyZQMK=Ta2dr0c=11ebmPJVw@mail.gmail.com>
On Sat, Oct 17, 2015 at 03:39:20PM -0400, Rob Clark wrote:
> On Sat, Oct 17, 2015 at 2:59 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote:
> >> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
> >> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
> >> >> <gregkh@linuxfoundation.org> wrote:
> >> >> >> I'm guessing the time is a matter of probing and undoing the probes
> >> >> >> rather than slow h/w. We could maybe improve things by making sure
> >> >> >> drivers move what they defer on to the beginning of probe, but that
> >> >> >> seems like a horrible, fragile hack.
> >> >> >
> >> >> > How can calling probe and failing cause 2 seconds? How many different
> >> >> > probe calls are failing here? Again, a boot log graph would be great to
> >> >> > see as it will show the root cause, not just guessing at this.
> >> >>
> >> >>
> >> >> just fwiw, but when you have a driver that depends on several other
> >> >> drivers (which in turn depend on other drivers and so on), the amount
> >> >> of probe-defer we end up seeing is pretty comical. Yeah, there
> >> >> probably is some room to optimize by juggling around order drivers do
> >> >> things in probe. But that doesn't solve the fundamental problem with
> >> >> the current state, about probe order having no clue about
> >> >> dependencies..
> >> >
> >> > I can imagine it is a lot of iterations, but how long does it really
> >> > take? How many different devices are involved that it takes multiple
> >> > loops in order to finally work out the correct order? Where is the time
> >> > delays here, just calling probe() and having it instantly return
> >> > shouldn't take all that long.
> >>
> >> offhand, I think the dependencies go at *least* three levels deep..
> >> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
> >> get all the way through requesting it's various different
> >> regulators/clks/gpios.
> >
> > And how long does that really take? Numbers please :)
> >
> >> I hadn't really paid attention to how many
> >> tries the drivers I depend on go through. (Of those, I take clks from
> >> two different clk drivers (which have dependency on a 3rd clk driver),
> >> and regulators and gpio's come from at least two places, which in turn
> >> have dependencies on clks, etc.) I don't have really good hard
> >> numbers handy (since my observations of this are w/ console over uart
> >> which effects timings, and so I see it taking much longer than 2sec)..
> >> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
> >> me.
> >>
> >> I can try to get better #'s... I should have my kernel hat on at least
> >> some of the time next week.. but the 2sec figure didn't seem
> >> unrealistic to me.
> >
> > Based on the time it takes a modern laptop to boot, 2 seconds is
> > forever, there has to be something else going on here other than just
> > calling probe() a bunch of times. Please use the tools we have to
> > determine this before trying to change the driver core.
>
> yes, I am aware of the tools.. although so far I spend most of my time
> just trying to get things working in the first place ;-)
And that's where most people stop, if you want to make it fast, you have
to put in more effort, sorry. Don't expect the driver core to work
around driver bugs for you.
> All I was trying to point out was that Tomeu's figures didn't really
> seem unrealistic. I mean, given that the average SoC driver probably
> depends on at least one clock and at least one regulator, having to
> probe each driver at least twice seems plausible. And that having a
> noticeable effect on boot time doesn't seem surprising. I'm not sure
> that saying 'modern laptop can boot in 2sec' adds much to the
> discussion since I don't think you have quite so much interdependency
> between devices vs random probe order. I have seen arm devices boot
> to UI in similar times, but that was pre-devicetree days.
2 extra probes add a second to the boot time? Those sound like really
broken drivers to me :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] video: fbdev: fsl: Split DIU initialization entry
From: Timur Tabi @ 2015-10-18 3:53 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1444709355-8905-1-git-send-email-dongsheng.wang@freescale.com>
On Mon, Oct 12, 2015 at 11:09 PM, Dongsheng Wang
<dongsheng.wang@freescale.com> wrote:
> + ret = fsl_diu_perpare();
> + if (ret)
> + goto out_diu_perpare;
I think you mean "prepare"
Thanks for posting this patch. I will try to review it more thoroughly later.
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Mark Brown @ 2015-10-18 19:29 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Tomeu Vizoso, 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, Frank Rowand,
Grant Likely, Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, Liam Girdwood,
Felipe Balbi
In-Reply-To: <20151017065750.GA18607@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]
On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
> I can't see adding calls like this all over the tree just to solve a
> bus-specific problem, you are adding of_* calls where they aren't
> needed, or wanted, at all.
This isn't bus specific, I'm not sure what makes you say that?
> What is the root-problem of your delay in device probing? I read your
> last patch series and I can't seem to figure out what the issue is that
> this is solving in any "better" way from the existing deferred probing.
So, I don't actually have any platforms that are especially bothered by
this (at least not for my use cases) so there's a bit of educated
guessing going on here but there's two broad things I'm aware of.
One is that regardless of the actual performance of the system when
deferred probe goes off it splats errors all over the console which
makes it look like something is going wrong even if everything is fine
in the end. If lots of deferred probing happens then the volume gets
big too. People find this distracting, noisy and ugly - it obscures
actual issues and trains people to ignore errors. I do think this is a
reasonable concern and that it's worth trying to mitigate against
deferral for this reason alone. We don't want to just ignore the errors
and not print anything either since if the resource doesn't appear the
user needs to know what is preventing the driver from instantiating so
they can try to fix it.
The other is that if you're printing to a serial console then that's not
an especially fast operation so if you're getting lots of messages being
printed simply physically outputting them takes measurable time. I'm
not aware of any performance concerns outside of that, but like I say
I'm not affected by this myself in any great way. Obviously this can be
configured but not having actual errors on the console isn't super
awesome either for systems that make use of the logging there and we
don't have a good way of telling what's from deferral and what's not.
[-- 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-18 19:37 UTC (permalink / raw)
To: Mark Brown
Cc: Tomeu Vizoso, 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, Frank Rowand,
Grant Likely, Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, Liam Girdwood,
Felipe Balbi
In-Reply-To: <20151018192931.GY14956@sirena.org.uk>
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:
>
> > I can't see adding calls like this all over the tree just to solve a
> > bus-specific problem, you are adding of_* calls where they aren't
> > needed, or wanted, at all.
>
> This isn't bus specific, I'm not sure what makes you say that?
You are making it bus-specific by putting these calls all over the tree
in different bus subsystems semi-randomly for all I can determine.
> > What is the root-problem of your delay in device probing? I read your
> > last patch series and I can't seem to figure out what the issue is that
> > this is solving in any "better" way from the existing deferred probing.
>
> So, I don't actually have any platforms that are especially bothered by
> this (at least not for my use cases) so there's a bit of educated
> guessing going on here but there's two broad things I'm aware of.
>
> One is that regardless of the actual performance of the system when
> deferred probe goes off it splats errors all over the console which
> makes it look like something is going wrong even if everything is fine
> in the end. If lots of deferred probing happens then the volume gets
> big too. People find this distracting, noisy and ugly - it obscures
> actual issues and trains people to ignore errors. I do think this is a
> reasonable concern and that it's worth trying to mitigate against
> deferral for this reason alone. We don't want to just ignore the errors
> and not print anything either since if the resource doesn't appear the
> user needs to know what is preventing the driver from instantiating so
> they can try to fix it.
This has come up many times, I have no objection to just turning that
message into a debug message that can be dynamically enabled for those
people wanting to debug their systems for boot time issues.
Please send a patch to do so.
thanks,
greg k-h
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Mark Brown @ 2015-10-18 19:41 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rob Herring, 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, David Woodhouse, Liam Girdwood,
Felipe Balbi
In-Reply-To: <20151017154709.GE4059@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]
On Sat, Oct 17, 2015 at 08:47:09AM -0700, Greg Kroah-Hartman wrote:
> On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:
> > I think Linus W, Mark B, and I all said a similar thing initially in
> > that dependencies should be handled in the driver core. We went down
> > the path of making this not firmware (aka bus) specific and an earlier
> > version had just that (with fwnode_* calls). That turned out to be
> > pointless as the calling locations were almost always in DT specific
> > code anyway. If you notice, the calls are next to other DT specific
> > calls generally (usually a "get"). So yes, I'd prefer not to have to
> > touch every subsystem, but we had to do that anyway to add DT support.
> If they are "next" to a call like that, why not put it in that call? I
> really object to having to "sprinkle" this all over the kernel, for no
> obvious reason why that is happening at all (look at the USB patch for
> one such example.)
I did ask that question myself IIRC - we could probably get a long way
by trying to instantiate anything that looks probable when we do a
phandle lookup on it.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Mark Brown @ 2015-10-18 19:53 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Tomeu Vizoso, 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, Frank Rowand,
Grant Likely, Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, Liam Girdwood,
Felipe Balbi
In-Reply-To: <20151018193757.GA9147@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]
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:
> > > I can't see adding calls like this all over the tree just to solve a
> > > bus-specific problem, you are adding of_* calls where they aren't
> > > needed, or wanted, at all.
> > This isn't bus specific, I'm not sure what makes you say that?
> You are making it bus-specific by putting these calls all over the tree
> in different bus subsystems semi-randomly for all I can determine.
Do you mean firmware rather than bus here? I think that's the confusion
I have...
> > One is that regardless of the actual performance of the system when
> > deferred probe goes off it splats errors all over the console which
> > makes it look like something is going wrong even if everything is fine
> > in the end. If lots of deferred probing happens then the volume gets
> > big too. People find this distracting, noisy and ugly - it obscures
> > actual issues and trains people to ignore errors. I do think this is a
> > reasonable concern and that it's worth trying to mitigate against
> > deferral for this reason alone. We don't want to just ignore the errors
> > and not print anything either since if the resource doesn't appear the
> > user needs to know what is preventing the driver from instantiating so
> > they can try to fix it.
> This has come up many times, I have no objection to just turning that
> message into a debug message that can be dynamically enabled for those
> people wanting to debug their systems for boot time issues.
It's not just the driver core logging, it's also all the individual
drivers logging that they failed to get whatever resource since silently
failing is not a great user experience. Many, hopefully most, of the
drivers don't actually have special handling for probe deferral since
half the beauty of probe deferral is that the subsystem supplying the
resource can just return -EPROBE_DEFER when it notices something is
missing but might appear and then the drivers will do the right thing so
long as they have error handling code that they really should have
anyway.
We'd need to have a special dev_err() that handled probe deferral
errors for drivers to use during probe or some other smarts in the
logging infrastructure. Which isn't a totally horrible idea.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 0/2] simplefb: Add regulator handling support
From: Mark Brown @ 2015-10-18 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <561E3D28.2090901@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]
On Wed, Oct 14, 2015 at 01:31:52PM +0200, Hans de Goede wrote:
> I like your idea in your other mail where you suggest to actually
> use foo-supply and bar-supply names in the simplefb node, and then have
> some code simple iterate over all the properties and check for *-supply
> properties, so that the proper, schematic matching names can be used.
> But surely if we go this way having a helper for this so that others
> can re-use that likely not entirely trivial code is a good idea ?
Yeah. It's trying to come up with a way to do this that is easy to
avoid abuse that's tricky.
> One user which comes to mind immediately here is the generic mmc-pwrseq
> driver.
> I agree that we need to be careful to not use a helper like this too
> much, but I do believe it will make sense to have it in some rare cases.
> We can put a big warning in both the header declaring it and above
> the implementation to use it scarcely.
I'd rather have something that was visible in the code, not everyone
reads the documentation especially not subsystem maintainers reviewing
drivers that use APIs they're not familiar with.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 0/2] simplefb: Add regulator handling support
From: Hans de Goede @ 2015-10-19 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20151018195719.GC14956@sirena.org.uk>
Hi,
On 18-10-15 21:57, Mark Brown wrote:
> On Wed, Oct 14, 2015 at 01:31:52PM +0200, Hans de Goede wrote:
>
>> I like your idea in your other mail where you suggest to actually
>> use foo-supply and bar-supply names in the simplefb node, and then have
>> some code simple iterate over all the properties and check for *-supply
>> properties, so that the proper, schematic matching names can be used.
>
>> But surely if we go this way having a helper for this so that others
>> can re-use that likely not entirely trivial code is a good idea ?
>
> Yeah. It's trying to come up with a way to do this that is easy to
> avoid abuse that's tricky.
>
>> One user which comes to mind immediately here is the generic mmc-pwrseq
>> driver.
>
>> I agree that we need to be careful to not use a helper like this too
>> much, but I do believe it will make sense to have it in some rare cases.
>> We can put a big warning in both the header declaring it and above
>> the implementation to use it scarcely.
>
> I'd rather have something that was visible in the code, not everyone
> reads the documentation especially not subsystem maintainers reviewing
> drivers that use APIs they're not familiar with.
I'm afraid there is not really a good way to do this though, so a big fat
warning in the header declaring the function is really the bets we can
do IMHO.
Regards,
Hans
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: David Woodhouse @ 2015-10-19 9:44 UTC (permalink / raw)
To: Mark Brown, Greg Kroah-Hartman
Cc: Tomeu Vizoso, 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, Frank Rowand,
Grant Likely, Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, Liam Girdwood, Felipe Balbi, Jingoo Han
In-Reply-To: <20151018195330.GB14956@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]
On Sun, 2015-10-18 at 20:53 +0100, Mark Brown 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:
>
> > > > I can't see adding calls like this all over the tree just to solve a
> > > > bus-specific problem, you are adding of_* calls where they aren't
> > > > needed, or wanted, at all.
>
> > > This isn't bus specific, I'm not sure what makes you say that?
>
> > You are making it bus-specific by putting these calls all over the tree
> > in different bus subsystems semi-randomly for all I can determine.
>
> Do you mean firmware rather than bus here? I think that's the confusion
> I have...
Certainly, if it literally is adding of_* calls then that would seem to
be gratuitously firmware-specific. Nothing should be using those these
days; any new code should be using the generic device property APIs
(except in special cases).
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]
^ 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